「外部委託中心、コードはほぼ書かない」開発部門がアジャイル内製開発組織に変貌できた理由――KDDIの実例に学ぶ、自律型組織の作り方：「組織の伝統」を変えるヒント
外的環境やニーズが目まぐるしく変わり、これまでの経験が通用しない予測不能な「VUCA」の時代といわれる今、企業として変化に適応するためどのような取り組みが重要なのか。そして、どう始めればよいのか。KDDIの法人向けサービスの企画、開発部門でアジャイル開発の推進に携わり、現在はKDDIアジャイル開発センターで開発部長を務める岡澤克暢氏に話を聞いた。
デジタルビジネスの推進、拡大に向けてクラウドネイティブを実践する企業は増えつつある。スキルなど成熟度も着実に上がりつつあり、実践している企業とそうでない企業の差は日々拡大している状況だ。外的環境やニーズが目まぐるしく変わる中、状況変化に機敏に対応できなければ、立ち行かなくなる状況にあるといえる。
では、企業としてこの状況変化に機敏に対応できる能力を持つためにはどのような取り組みが重要なのか。そしてどう始めればよいのか。2013年ごろからアジャイル開発導入に取り組み、アジャイル開発を組織内の開発手法として定着させたKDDIで、アジャイル開発導入時にスクラムマスターとして参加したKDDIアジャイル開発センターの岡澤克暢氏（開発1部 部長）に話を聞いた。
なお、本稿の内容は、岡澤氏が登壇したイベント「KDDIはどうやってアジャイル内製組織を創り上げてきたか〜変化を根付かせる、自走する組織への推進力〜」での講演内容と、岡澤氏に追加で取材した内容をもとに構成している。
開発部門が「ソースコードは書かない、外部委託が当たり前」に危機感
電話は5000万ユーザーに到達するまで75年、ラジオは38年、テレビは13年と次第に短くなっていき、スマートフォンゲームの「Pokemon GO」はわずか19日――通信の進化、デバイスのサイクル、アプリ開発の進化、さまざまな領域で変化が激しくなっている。
こうした状況を岡澤氏は「事業を継続することが難しい世界になっており、プロダクトのニーズも不確実です。こうした世の中になっていることを企業は再認識する必要があります」と話す。まさしく、VUCA（※）の時代といえる。
※：Volatility〈変動性〉、Uncertainty〈不確実性〉、Complexity〈複雑性〉、Ambiguity〈曖昧性〉の頭文字を合わせたもの
岡澤氏はもともと官公庁向けの通信SIerでWeb開発からインフラ領域と広く携わっていた。クラウドやモバイルに携わりたいという思いから2009年にKDDIに転職。その後は幾つかのプロジェクトを支援しつつ、2013年前後では法人向けサービスの企画、開発に取り組んでいた。
「当時はさまざまな企業がSaaSをリリースしており、登場しては消えていくという異常な盛り上がりを見せていました。Googleからスピンアウトしたスタートアップと共同でプロジェクトを進めていく中で、製品のサイクルスピードが非常に速くなっていることを体感した一方、私が当時所属していた部署は外部委託が中心で、仕様書を作成してベンダーに開発を依頼するスタイルがほとんどでした。担当者が複数のプロジェクトを兼務しており、開発というよりはベンダーマネジメントがメイン。コードを書くメンバーはほぼいない状況でした。さらに運用や監視部門も別のベンダーに任せていました」（岡澤氏）
「アジャイル開発がやりたい」のではなく「事業スピードを速めたい」ことを丁寧に説明
こうした文化の違いを肌で感じた岡澤氏は、企業としての優位性が失われていく危機感を持っていたという。
「AppleのiPhoneやAWS（Amazon Web Services）が登場してしばらくたった2013年当時は、SaaS企業が時価総額をどんどん上げている時期でした。このスピード感に適応できず、ソフトウェアが作れない会社は朽ちていく。事業ドメインが崩れるような状況も見てきて、そうした危機意識を持っていました」（岡澤氏）
その頃、Googleから藤井彰人氏（現在はKDDI Digital Divergence Holdingsの代表取締役）がKDDIに転職し、岡澤氏の上司になった。そして藤井氏、木暮圭一氏（現在はKDDIアジャイル開発センターの代表取締役）らとともに、変化に適応できる組織を目指すため、外部委託のスタイルを辞め、内製化を目指し、企画や開発の部門を統合した1つのチームを立ち上げた。
チームを立ち上げる際には、次の3つを軸として掲げたという。
- リーンスタートアップ
- デザインシンキング
- アジャイル
「藤井さんはトップダウン、私はボトムアップという立場で組織を変えていく取り組みを始めました。初期のころから一貫していたのは、周囲に説明する際は『アジャイル開発がやりたい』というわけではなく『いち早くビジネスを成長させていきたい』『顧客の要望をいち早くプロダクトに反映していきたい』と丁寧に説明することでした。最初からわれわれだけで進めるのでは難しいと感じていたので、外部のパートナーやスクラムマスターと協力し、都度取り組みを振り返りながら進めていきました」（岡澤氏）
取り組みを進めるに当たっては、アジャイル開発以外の取り組みも当然、進めていたという。
「『アジャイルソフトウェア開発宣言』（アジャイルマニフェスト）には『ドキュメントよりソフトウェアを』という言葉もありますが、必要なものは作るという方針でした。既存のドキュメントを見やすくしてあげたり『WordやExcelにまとめていたドキュメントをConfluenceにまとめるとリアルタイムに確認できます』と、ツールの導入を積極的に行ったりしました。開発フローにおいて、リードタイムが短縮できないとリリースサイクルは短くなりません。何がボトルネックになっているか調査して地道に改善した他、インフラのコード化、自動検知など、自分たちの労力を割かないようにするための仕組みづくりにも取り組みました」（岡澤氏）
2013年に法人向けサービスで初めてアジャイル開発を導入、実践したKDDIでは、その後、2015〜2016年にパーソナル系サービスの領域にもアジャイル開発の領域を拡大させた。そして2016年にアジャイル開発センターを発足した後、情報システムやセキュリティ、ネットワークなどさまざまな部門でもアジャイルを展開していく。その後もKDDI DIGITAL GATEやScrum incの設立など、アジャイル開発が全社的に広がっていった。2022年現在はアジャイル開発センターを分社化し、顧客のアジャイル開発を支援している。
さらに、取り組みの中ではコンテナやKubernetesなどクラウドネイティブ技術にも挑戦してきた。
「2013年当時と比べるとソフトウェアやツールも成熟してきて、事業スピードを速めるための取り組みはチャレンジしやすい状況ですね。『Docker』は正式リリース前のβ版から使おうかと議論していた覚えもあります。当時は、早すぎて無理でしたが……。事業スピードを速める上ではクラウド上のサービスを使った方が早いと判断して『AWS Amplify』『AWS Lambda』などサーバレスを活用しています。サービス開始時に利用していたクラウドサービスも、運用面、管理コストを意識し別のサービスを使おうと議論したり、状況や目的に応じて利用するサービスをどんどん変化させたりもしています」（岡澤氏）
だが、アジャイル開発を浸透させるまでの取り組みは、順風満帆というわけでもなかったという。
「振り返ってみると結構いろいろ失敗していた印象です。おそらくアジャイル開発の取り組みをしている企業がぶつかってきた壁にわれわれもぶつかっていたんじゃないかと。アジャイルやスクラムを独自に進めると儀式的になってしまったり、メンバー同士が対立してしまったり。本来の目的を見失ってしまうこともありました。ただ、失敗したから立ち止まるのではなく『ユーザーのニーズに適応していくためにはこれしかない』と改善する日々でした。スクラムマスター、チームで振り返りをしたり、他のチームの出来事を共有したりEngineering Manager(EM)も組織全体をフォローするのは意識してやっていました」（岡澤氏）
KDDI流、自律型組織のつくりかた
岡澤氏はKDDIでアジャイル開発を浸透させるに当たって、次の6つのステップを踏んできたと振り返った。
- 初期チーム立ち上げ
- 複数チーム立ち上げ
- 組織立ち上げ
- 全社展開
- 自走する組織の促進
- 社外展開、グループ展開
「『早く開発できますよ』とか、どうしてもよく聞こえてしまうのですが、『変われよ』って言われても、人は変わるのが難しい。組織の場合はなおさらで、ボトムアップで変えようとしても太刀打ちできません。アジャイル開発に限らず、できるだけ賛同してくれる上層部の人を見つけて協調することが重要です。上層部の人を見つけられたら、現場のメンバーは全力で結果を出していく」（岡澤氏）
岡澤氏のチームでは、スクラムレビュー中に訪れた本部長の意見を聞き、もらったアイデアやフィードバックを次のスプリントで選んで実装し、本部長に成果物を見せに行くという地道な取り組みや、他部門の人に社内見学ツアーという形で働き方を見てもらうこともしていたという。
「社内の人からは『同じ会社には見えない』というコメントをもらうこともありました。決裁権のある人に成果物を見せることで開発速度の差を体感してもらうことも重要でした。予算の取り方も変わっていきましたし、地道に社内の意識を変えていく取り組みをやっていったから、アジャイル開発が組織に浸透していったのだと考えます」（岡澤氏）
そして重要なのが、「5.自走する組織の促進」以降だ。KDDIのような大規模な組織でアジャイル開発を浸透させるには、岡澤氏のチームや部門だけでは限界があった。岡澤氏は「それぞれの組織で自律的に動いて、スクラムを広めてもらう、アジャイル開発に挑戦してもらうことが大切」と話す。
「社内に向けて啓発もしましたし、別部門のPO（プロジェクトオーナー）に対してアジャイル開発によるサービスのリリースパターンを説明したり、お互い助け合ったりしながら推進していきました」（岡澤氏）
自律型組織をつくるには、心理的安全性も重要だという。岡澤氏のいう心理的安全性とは「ゴールに向かってお互いがリスクを感じることなく、率直に会話を実施できる」ことだ。隣のチームとけんかをしているのではないかと感じさせるような言い合いがあったとしても、成し遂げたいプロダクトのゴールなどのために率直な意見をぶつけ合っているのであれば、心理的安全性があるといえる。
もし、議論の向き先が人であったり事象であったり、目指すものと違う方向なら、スクラムマスターやチームリーダーが「それは違う」と訂正する。岡澤氏は「マネジメント層が訂正していくことは自律型組織をつくるために大切なこと」と話した。
組織変革を社内に根付かせることが、ビジネスをより加速させる第一歩
岡澤氏はリーダーシップ論について語るジョン・コッターの『CHANGE 組織はなぜ変われないのか』を取り上げ、組織変革のためのサイクルも重要になると指摘する。
8つのアクセルの最初の3つは「変革の理由を明らかにする」段階だ。皆が現状に対する危機感を覚え、解決のためのゴールへ向かっていくことを優先的にやっていく。次の3つが「変革の実験を成功させる」段階だ。ここは「熱意のある人の存在が重要なフェーズ」（岡澤氏）という。そして残りの2つが「変革を広げ、アジャイルな組織を実現する」段階だ。このサイクルも組織に寄り添う形でカスタマイズしていく必要があると岡澤氏は指摘する。
そして、チーム内で行っていた啓発や育成を広げていく。情報の共有やメンバーの育成などを通して組織全体が成長し、ビジネスが加速していく。すると新しいチームが成長して、そのチームがまた情報共有するなどしていく……これを繰り返していくことで、組織全体への成長へとつながる。1つのチームだけが発信するのではなく、他のチームも情報発信の中に入ってくるようなモデルをつくることが大切だとした。
岡澤氏は最後に「2022年現在はデジタルトランスフォーメーションだ、アジャイル開発だ、っていうのが2周ぐらい回っている状況で、2013年当時と比較しても周囲が後押ししてくれる状況です。最初はチームから始めてみて、スケールが大きくなっていくときに、立ち止まらないで走り続けることが重要です。変化を根付かせる取り組みが社内のメンバーだけでは難しいと感じるのなら、伴走、共創してくれる外部パートナーと一緒にトライし、事業をつくっていくのがよいでしょう」とアドバイスした。
Copyright © ITmedia, Inc. All Rights Reserved.