2016年3月18日にエンタープライズアジャイル勉強会主催のイベント「エンタープライズアジャイルの集い」が開催されました。当日の参加者は100名前後と非常に盛況なイベントとなりました。講演ではアジャイル開発に取り組む私たちに刺激を与える大変貴重なお話を伺うことができました。本記事ではその講演内容をレポートします。
「エンタープライズアジャイルの集い」とは
「エンタープライズアジャイルの集い」はエンタープライズアジャイル勉強会が主催し、2016年3月18日（金）に東京都品川区の大崎ブライトコアホールで開催されたイベントです。主催者であるエンタープライズアジャイル勉強会は、日本の企業においてチームレベルを超えたアジャイル開発の活用に際する様々な障害とその解決策をより広範囲で共有するために2015年6月に発足した団体です。今回のイベントもエンタープライズ勉強会の主旨のもと、企業内でアジャイル開発をけん引する管理職層を主な対象として開催されました。当日は100名前後の方が参加され、大変盛り上がるイベントとなりました。
オージス総研は当イベントのタイトルスポンサーとして参加していますが、本記事では一聴講者として講演を聴いた内容を皆さまと共有したく、講演内容をレポートします。
基調講演「Agile Transformation & Leadership in Enterprise ~KDDIでの驚きと学び~」
講演者：KDDI株式会社 ソリューション事業企画本部 クラウドサービス企画部 部長 藤井 彰人様
（レポート執筆：オージス総研 藤井拓）
本レポートでは、藤井さんのご講演を筆者なりの理解で整理し直して報告します。特に記事中の見出しは筆者が勝手につけたものです。その点につきご了承下さるようにお願いします。
藤井さんのご講演の全体の流れは、以下のようなものでした。
- KDDIに転職されるまでのご経歴
- 改革を始める時点の状態
- 改革の戦略
- 改革の実行
- マネジメントとして意識されていること
KDDIに転職されるまでのご経歴
藤井さんが、当初勤務されたのは製造メーカーであり、そこは「気合と根性」で仕事をやり遂げるという世界だったそうです。藤井さんは、この「気合と根性」の世界に違和感を抱きました。
この違和感が本講演を通じて藤井さんが立ち向かったものだと筆者は感じました。
その後、藤井さんは製造メーカーからSun MicrosystemsやGoogleという外資系の企業に転職され、IPAの未踏プロジェクトやMashUp Awardsなどにも関わられました。この頃に、共感された言葉が平鍋さんの「Quality of Engineering Life」という言葉だったそうです。
おそらく、「気合と根性」の世界の対極にある「Quality of Engineering Life」こそが藤井さんにとって目指すべき理想を言い表した言葉として響いたのではないかと思います。
その後、2013年にKDDIさんからのお誘いを受けて、居心地の良い外資系でのお仕事から抜け出て改革の担い手になる決意をされました。藤井さんは、ご自身をペリー提督や黒船のようなものだと例えられていました。
改革を始める時点の状態
藤井さんが改革を始める時点でKDDIさんは、他の多くの日本の企業と同じように企画部門はIT（技術）をあまり理解しておらず、開発部門は開発をSI会社に外部委託するという状態だったそうです。その一方、大手通信キャリアとしての大きな社会的責任があり、システムトラブルが発生するとその影響が非常に大きいという厳しい状況だったそうです。
改革の戦略
藤井さんが講演された改革を進める上での戦略は、以下の3点に集約できるのではないかと思います。
- 日米のやり方の折衷を狙う
- プロダクトの企画から運用までの連携を良くする
- 1年1テーマで改革を進める
「日米のやり方の折衷を狙う」とは、雇用や人事制度を含めて米国のやり方にもメリットとデメリットがあるので日本のやり方と米国のやり方の折衷を考えた方がよいということです。
「プロダクトの企画から運用までの連携を良くする」とは、プロダクトマネージャーが中心となり、企画、開発、運用というような組織の壁を越えて連携を良くするということを目指すということです。
「1年1テーマで改革を進める」とは、1年目は「アジャイル手法」、2年目は「オフショア開発」、3年目は「企画」というように段階的な改革のテーマを設定していくということです。
改革の実行
藤井さんが講演された改革を実行するポイントは、以下の2点です。
- 教育よりも実践する
- 原理原則を設定する
「教育よりも実践する」の根底にあるのは、「社員の潜在的な力を信じて任せてみる」という考え方です。具体例としては、ペアプロの実践を通じた社員の方々のアジャイル開発の習得のお話や、企画部門にUMLを使うことを求めたら使えるようになったというお話をされました。
「原理原則を設定する」というのは、ツール等により進捗を可視化するというような守るべきことを定めることです。ご講演では、「明るく、楽しく仕事をする」ための原理原則として開発がうまくいったらクラッカーやバズーカでそれを祝うという例をお話され、その点がすごく印象的でした。やはり楽しく仕事する方がいいですよね！
事業としての成果として、これまでお話をされた2年間の改革によりKDDI Business IDや、KCPS (KDDI Cloud Platform Service) Admin Console をリリースされたことを挙げておられました。
マネジメントとして意識されていること
藤井さんが講演でお話をされたマネジメントとして意識されていることは、以下のようなものでした。
- 部下の潜在的な能力を解き放つ
- ワークスタイルを変える
- 困難に直面した際に、改革を一緒に進めている同僚を守る
- 自ら方向性を見出す人材を育成する（あるいは認める）
- アジャイルは企画側が提唱すべき
- 既存の企業理念を再評価する
- ビジョンと価値を提案する
- 活き活きと働けるようにする
この中で「アジャイルは企画側が提唱すべき」というのはかなり斬新ですが、企画の人達が自分達が尊敬する会社での企画の立案の方法等を見聞きすれば「おのずとアジャイル開発をやりたい」と思うはずであるということです。
所感
外資系の企業からKDDIさんのような日本の大企業に転職し、改革を主導するというのは並大抵の挑戦ではなく、こんな例えは不適切かもしれませんが、講演をお聞きしてまさにファーストペンギンのような方だと思いました。
本レポートを書きながら、改めて藤井さんの取り組みの成功要因として何が一番大きかったかを考えたのですが、おそらく一番大きな要因は「アジャイルは企画側が提唱すべき」ことを実践されたことではないかと思いました。つまり、アジャイルを実践した結果として生み出される事業上の成果が予測できるということが改革の大きな推進力だったのではないかということです。そうだとしたら、「アジャイルは企画側が提唱すべき」というのは非常に大切な示唆として受け止めるべきだと思いました。
さらにもう１つ大事だと感じた点は、改革を進めるうえで「原理原則を設定する」ということです。これは、所属のメンバーが目指すべき状態を理解し、組織として既存の風土を脱する上で非常に大事だと思いました。
事例紹介「小さく始める大規模スクラム」
講演者：株式会社リクルートライフスタイル 塚越啓介様、今井恵子様
（レポート執筆：オージス総研 木村めぐみ）
この講演ではリクルートライフスタイル社が海外版POSレジアプリ「AirREGI」を開発する際にスクラムを始めた理由、チームの構築、チームの歩みなどが紹介されました。
本レポートではこの講演内容のうち、
- 大規模スクラムで取り組まれた内容
- チームの歩み
についてのお話を中心にご紹介します。なお、本レポートでの見出しは筆者が勝手に付けたものであることをご了承ください。
当日の講演資料は https://www.slideshare.net/keisuketsukagoshi/ss-59705472 で公開されています。
はじめに
講演者の塚越さんはスクラムマスター、今井さんはプロダクトオーナー（以降、POと記します）という立場でプロジェクトを推進されました。プロジェクトは海外版POSレジアプリ「AirREGI」をスクラムで開発。開発者が40人超で複数チームで構成される大規模でのスクラム開発でした。
なぜアジャイル？
スプリントという一定の期間でフィードバックを受けながらプロダクトをユーザーニーズに近づけていくためにスクラムを始められました。このプロジェクトで開発するのは海外向けのプロダクトでマーケットニーズが見えにくいため、継続的な改善をしながら開発をする必要があると考えたためです。
大規模スクラムに取り組むときのポイント
複数チームで構成される大規模でのスクラム開発でどのようにスクラムを進めていったか、経験に基づいた以下のようなおすすめの方法をご紹介いただきました。
- 1チームずつスクラムを導入する
- 複数チームでスクラムを始めるときは、一斉に取り組むのではなく、1チームずつ成功体験を積み上げて横に展開する
- POはチーム毎に置かず、一人のPOが全チームを見る
- POがたくさんいると話がまとまらず、そこがボトルネックとなる。POを一人にしてスピードアップする。
- 職能（たとえば、iOS、Android、Web、インフラ）でチームを分けずに、1チームにメンバーを混ぜる
- iOSチーム、Webチーム、のようにチームを分けてしまうとチーム間で対立する。同じチームにiOSができる人、Webができる人を混ぜると対立せず手伝ってくれる。また、他の職能を習得することもできる。
- 増員するときは、新規メンバー受け入れ専用のチームを作って増員メンバーを集め、そこに既存チームから連れてきたメンターを置く
- 新規メンバーはコミュニケーションやサポートにコストがかかる。このため、新規メンバーを既存チームに入れると既存チームのベロシティが不安定になってリリース予測ができなくなる。そこで、新規メンバーは新規メンバー受け入れチームに入れることにして、そこに既存チームからメンターを置いた。そうすると既存チームはベロシティを維持することができる。
一人のPOが全チームを見ると言うのは、POの覚悟が必要であり負担も大きいように思いますが、講演者の今井さんは実践されました。他のスクラムチームが同じことをできるかは分かりませんが、それ以外の取り組みについては組織内で初めてスクラムに取り組むチームでも比較的取り組みやすい内容だと思いました。特に私が大きく頷いたのは、職能別にチームを分けないというところです。チームを分けるとチーム間で対立するというのは実際に私も感じたことがありました。チームを分けないだけで手伝い合えるならこれは取り入れるべきだと思いました。
チームの歩み ～受け身→自発的→顧客視点→多能工→スピードアップへ～
講演の後半は、「チームと歩んだ半年」と題していくつかの改善や取り組みによって、受け身だったチームが自律的なチームへと変化していった興味深い内容が紹介されました。
受け身から自発的なチームに
講演の中では「過保護なPO」と表現されていましたが、初めのうちはPOが開発チームにチケットを割り当て、仕様についてもPOがピクセルレベルまで細かく決めないと開発が進まない状態だったそうです。それではPOの負荷が大きく開発が回らなくなってきたので、それまでPOがやっていたチケットの割り当てや細かい仕様についての検討を開発チームに委譲することにしました。すると意外と開発チームがやってくれたそうです。
それでも開発チームはリーダーを欲しがったそうですが自律的にやってほしいのでリーダーは置きたくない・・・。そこで、メンターを置くことにしました。メンターは先生や相談役の立場で得意なことを教えてあげる人で、作業の成果の責任は取らない、承認者にはならないというのがポイントとのことでした。これらを行った結果、受け身なチームから自発的なチームになったそうです。
顧客視点で開発する
プロダクトのターゲットは海外かつ法人向けであるため誰が使っているか分からず、チームは要件通りに作ればよいだろうという雰囲気だったそうです。そこに問題を感じ、チームに顧客視点を持ってもらうため以下を実践されました。
- ターゲットと同業種である飲食店に行き業務観察とインタビューを実施。そのうえでユーザーストーリーマッピングをした。
- スプリントレビューでロールプレイをしてユーザーの気持ちを体感。
これらを実施することで誰のために何をやっているのかという意識が根付いたそうです。
多能工となる
スクラム開発ではPOがチケット（要求と同義で話されていました）とその優先度を決め、開発チームは優先度の高いものから開発するよう計画します。このように優先順位の高いチケットから作業するためにはどの分野でも開発できる多能工が必要となります。たとえば、Webができるメンバーの手が空いているが、優先度が高いチケットはiOSの開発しかない、というようなケースです。このようなケースでは、優先度の高いiOSの開発をWebの人ができればより早くユーザーに必要な機能を提供できます。このため、メンバーを多能工にしたいと考えました。
しかしいきなり多能工にはなることはできないので、まずはスキルマップを作ってメンバーの得意分野を見える化されました。
（ スキルマップ 「 講演資料 」より引用）
そしてメンターとなる人がライブコーディングをしながら教えたりすることでメンバーが習得していったそうです。POは職能で分割したチケットを作らないのもポイントとのことでした。
この結果、開発チームは多能工となりました。さらにプロジェクトはスピードアップを目指すための取り組みをされました。
スピードアップ
ムダマップを作って開発の無駄を見える化されました。
（ ムダマップ 「 講演資料 」より引用）
無駄と判断した開発のフローを変えた結果、開発コストが1/3になったそうです。
所感
講演を通じて、講演者のお二人がユーザーに価値のあるものを早く提供する、という一貫した思いのもとチームを運営されているのが伝わりました。
講演を聞いた後、開発を進めながら問題点や無駄を洗い出し、実際に改善までできたのはなぜだろう、と考えました。例えば多能工の話です。スクラムを進める上で多能工であることは求められるものの、多能工でないメンバーをプロジェクト期間中にスキルアップさせることは現実ではなかなかできないと私は感じていました。そこを踏ん張って改善できたのは、短い期間でユーザーに価値のあるものを提供するには開発チームの生産性を上げる必要があってそのためには多能工が必要だ、とチーム内で同じ思いを共有できたからではないか、と私は思いました。お手本のようにも思えたチームの変化でしたが、ユーザーに価値のあるものを早く提供するという明確な目的に対して実践された、必要な取り組みの結果なのだと再確認しました。
さいごに
本レポートでは「エンタープライズアジャイルの集い」の講演内容を共有するため概要をご紹介しました。今回の講演では実際にアジャイルを推進されている現場の方の生の熱い思いを聞くことができた貴重な時間でした。あらためて、講演者の方々にお礼を申し上げます。参加者の一人として、今後アジャイルを進めていく上で今回の講演の内容を少しでも糧にしていきたいと思いました。（木村めぐみ）
今回快くご講演を引き受けて下さったKDDIの藤井さん、リクルートライフスタイルの塚越さん、今井さんにこの場を借りて感謝致します。また、熱心な質問を下さった参加者の方々にも感謝致します。さらに、イベントの企画においてご支援下さったエンタープライズアジャイル勉強会の実行委員のアーキテクタスの細川さん、永和システムマネジメントの平鍋さん、さらにパネル討論に参加して下さったメソドロジックの山岸さん、楽天の川口さんにもこの場を借りて感謝致します。（藤井拓）