小さな会議室から始まった「KDDIアジャイル開発センター」設立ストーリーとは？
KDDIアジャイル開発センターの前身は、2013年に設立されたKDDI内のアジャイル開発を推進する部門だ。迅速にビジネスが立ち上げられる中、開発組織の受発注関係の整理や内部のエンジニア育成が急務となっていたことが設立の背景にあるという。多くのアジャイル組織がそうであるように、当初は小さな組織からスタートした。岡澤氏は「小さな会議室を半分に区切ってのスタートだった。僕はその頃からスクラムマスターだったこともあって、アジャイル立ち上げに関与することになった」と振り返る。
アジャイル組織のテーマは「KDDIのソリューションサービスのコアとなる法人系の認証基盤開発」と「まったく新しいビジネスをリーンスタートで立ち上げること」の2つだった。エンタープライズテーマと新規事業テーマの2つを同時に追いかけたわけだ。
初期フェーズの開発プロセスについて、岡澤氏は「コア人材の育成が重要だった」と語る。2つのチームでエンジニアを専任化し、さらに両チーム共通で使う最低限のツールを選択した。そして最初に取り組んだのが「スクラムの守破離の“守”」だ。岡澤氏自身、以前独学でアジャイルを試みた時には失敗した経験があった。そのため、まずは地道にガイドラインやチェックリストのアジャイル向け調査・調整から開始した。そして、アジャイルコーチなど外部の力も積極的に活用し、アジャイル導入への推進力を高めていった。
2016年には組織の規模も大きくなり、対象となる事業領域を拡大するため「アジャイル開発センター」を発足した。さらにグループ会社でもアジャイルの展開を目指し、グループ会社のエンジニアが集まるコミュニティを作ってエンジニア同士の交流を深めていった。
そして、2019年頃には顧客企業から「アジャイル開発をやってほしい」「リーンスタートで新規事業を立ち上げたい」と依頼されるようになり、KDDIの一部門だった組織を「KDDIアジャイル開発センター」として2022年に会社化した。KDDI内部では、5G通信を軸にした「サテライトグロース戦略」の一環として、新たなDX事業の立ち上げが目標とされていたので、よりスピーディな事業開発が期待されていた。
岡澤氏が直面したチーム教育・運用におけるアジャイル組織の壁とは？
岡澤氏はこれまでの7年間を振り返り、「組織が初期から少し拡大し始めた頃に、チーム教育や運用に壁を感じることがたびたびあった」と語る。
その1つ「チーム教育」の壁には、以下のようなものがあった。
- 勉強会：最初は有意義だが、組織が大きくなってくると浸透しなかった。そこで、勉強会のコミュニティ化を進め、アジャイルに限らずAIやIoTなどさまざまなテーマを設定することで勉強会を活発化した。
- 技術スキル：DevOpsツールやIaCなどを固定化すると広がらないため、部門やグループごとに必要なスキルを見極め、必要なところに必要な分だけ広げていった。
- アジャイルの研修：テーマを固定して行っていたが、レイヤーによって考える目線が異なる。「経営層が考えるアジャイル」などレイヤーごとの研修を実施するようにした。
そして、もう1つが「チームの運用」の壁だ。
- メンバーローテーション：通常、メンバーは固定している方が望ましいが、チームが拡大していく中でメンバーをスプリットしてチームを拡大する必要がある。そのため、チーム間のエンジニア交流など推奨しチーム組成を推進した。また、ある程度組織が成熟したら一定期間チームを維持する運用へと変えていった。
- ツール：エンジニア主導でのツール選定を実現した。
- オフショア：途中から依頼するようになったが、依頼先のチームが外部にあるうちは上手くいかなかったため、アジャイルチーム内に入れ込んだ。
そして、岡澤氏の行動を大きく変えたのが採用活動だった。大きめの企業だと一般的にエンジニアが直接採用活動への提案などに関わることは少ない。しかし、岡澤氏は人事部へ積極的に協力し、採用フローや採用イベントを企画実施した。さらに評価にも関わるようになったという。
「スクラムマスターの視点がなければ、アジャイルの推進度合いは評価のしようがない。採用についても、人事はエンジニアをどう採用していいのかわからないので、積極的に関わることが大切。評価や人事の場に、エンジニアがどんどん顔を出すようにするべき」と岡澤氏は強調した。
佐藤氏も「チームが上手く作れていないと採用も外に任せたきりで、ミスマッチが起きやすくなる。しかし社内や人事との関係がうまくいっていると、社内からのリファラル採用がかなったり、通常の採用でもやりとりがスムーズになったりする」と語った。
マネージャーの“頑張りどころ”──組織体制とマインドセットにおける課題は？
続いて、「アジャイル推進をしていく過程での課題は？」という佐藤氏の質問に対し、岡澤氏は「紹介しきれないほどある」と答えた。その中でも「組織体制づくりについては、マネージャーの頑張りどころ。例えば、一般のWF案件では担当者が複数の案件を持っている場合が多いが、スクラムでは専任を推奨する。そのため1つの案件に集中できるように調整することが重要。その上で、人材不足については、教育や外部の活用を考えるべき」と語る。
そして、マインドセットの課題については、「アジャイルに特化したことではないが、当事者意識やビジネスマインド比率が重要。チームで取り組む中で、プロフェッショナルであるという意識は持ってほしい」と述べ、「ここについても、リーダーの役割が重要であり、組織やプロダクトがどこを目指すのか、ゴールを明確化することが大切」と語った。
組織のゴールを設定する際には、特に事業と開発を上手く融合させることが大事なポイントとなる。アジャイルやスクラムではゴールがビジネスに直結するために、技術とビジネスのつながりを意識しやすいのがメリットだ。岡澤氏は「チームメンバーには技術も磨いてほしいし、楽しく働いてほしい」と語り、今後について「楽しくエンジニアリングをすることで、それがビジネスに貢献していくという仕組みや風土づくりに取り組んでいきたい」と意欲を見せた。
アジャイルの推進役「オープンマインドなスクラムマスター」になるには？
アジャイルの推進において、リーダーの役割が鍵になってくるのは間違いない。それでは、リーダーにはどのような資質が求められるのだろうか。
岡澤氏は、かつてシリコンバレー系ベンチャーや元Googleメンバーと仕事をした経験からも、「多様性を受け入れスクラムマスターに似た感覚を常に持っていることが大切」と語る。つまり、オープンマインドで、メンバーやチームにどう貢献すべきかを考えながら、多角的な視点からビジネスマインドを醸成することが求められるわけだ。岡澤氏は特に、オープンマインドの重要性を実感しており、その実践により心理的安全性の担保やダイバーシティ実現など、さまざまな効果があったという。
さらに、「オープンマインドなふるまいはコーチングにも似ている」と語り、「フィードバックは上からの指揮命令ではなく、共通の認識を持ってもらうための手段。メッセージから必要なものだけを拾ってもらえればいい。そのためにも前提合わせが重要」と語った。例えば、アジャイルをやっていない隣の組織に問題があれば、そこにも介入して問題を解決するきっかけを作る。こうした越境を可能にするオープンマインドな姿勢ときっかけ作りを目指す姿勢が、アジャイル推進のリーダーには求められているというわけだ。
「ポジションが上がれば、見えてくる景色が変わる。チームだけを見ていた人が、その1つ2つ上の目線から組織を見られるようになると、自ずと行動が変わってくるだろう。その意味で、スクラムマスターという表現がふさわしいのではないか」と語った。
急激に拡大する組織で一人ひとり開発生産性を担保するには？
さらに、KDDIのアジャイル開発部門は急激な組織の拡大も経験した。組織のメンバーが増えていく中で、1人当たりの開発生産性はどのように担保したのか。
岡澤氏は「生産性の向上には、まずは『見える化』が不可欠。それによって組織自らの改善を推進できる。『ベロシティを生産性と見てはいけない』といわれるが、数値が見えることで改善が図られた結果、生産性が上がる」と語る。
この結論に至るまで岡澤氏は、数々のトライアルを実施してきた。失敗例では、チケット数で生産性を測定し、開発効率の低いオフショアメンバーのチケットを細かく区切ったところ、逆に生産性を下げる状況になってしまった。
佐藤氏はこの失敗を受けて「ダイエットのようなものではないか」と語る。現状を知って記録をつけるために毎日体重を計ることは大切だが、数字の増減よりも健康になるための指針や気づきの方が重要なわけだ。
実際、同社では40から50のスクラムチームが常に異なるプロジェクトを進行する。目標が異なるグループの生産性を比べても仕方がない。視座のレイヤーを上げるとチームの生産性に差が生じていることがわかるが、自分たちでその問題点に気づくことが重要だ。気づかせるためのツールとして可視化が有効なのである。
そして、開発生産性を向上するためのアクションの1つとして、アジャイル開発部門はFour Keysや開発リードタイム、レビュー状況を可視化する「Findy Team＋」を導入した。岡澤氏は「さまざま様々な数値がよく見えるようになり、透明性が増した」と評し、「ただし、その数値はチームに合わせて見る必要がある。エンジンかからないメンバーやフォローが必要なメンバーがいるときには、特に注意して見ている」とスクラムマスターとしての数値の見方について語った。
「Findy Team＋」では、一人ひとりのエンジニアの目線からも、コミット数やレビュー数で自分がどれだけ成長したかが可視化される。また、特定の誰かに負荷がかかっている場合は数値で状況を認識できるので、チーム内や他チームとの自律的な調整にも役立っているという。
また生産性向上のために、「Copilot」をはじめとする生成AIの活用も加速させているそうだ。「以前から、重複の排除や自動化は推進している。AIの有効性は、メンバー間でも共通認識を持ちながら、いっそう注目していきたい」と岡澤氏は語った。
エンジニア「楽しく働ける」環境づくりをするために
今後について、岡澤氏は「さまざまな課題があるが、組織が大きくなる中でチーム間の生産性の偏りが気になっている。チームで働くことは大切なだけに、体制を維持しながらベストサイクルを作っていくことが求められている」と語る。
かつての1on1を軸とした定性的な把握から、「Findy Team＋」の導入により生産性の数値化・可視化が可能になった。現在では、チームごとに「幸福度」の測定や振り返りの実施など、さまざまな現状測定がなされている。こうした複合的な指標から、今後のチーミングの方向性も固めたいという。
佐藤氏は「サーバーの感覚に近い」と評し、「オートスケール設定でそれを超えたらケアというより、さまざまな方法で状況を把握し対応していく。それによって楽しく働く環境が作れればいい」と語った。
エンジニアにとって「楽しく働ける」環境とは、成長を実感できたり、時間を忘れて集中できたりする場所だ。それがチームのどこにあるのかを見ながら、一人ひとりが働きやすいチームになっているかを考えていく。ある人にとっては働きやすくパフォーマンスを出しやすいチームが、他者にとってはそうでないこともある。そのマッチングやバランスこそ肝要といえるだろう。
リーダーである岡澤氏は、エンジニアに楽しく働いてもらうため、心理的安全性を前提として「もやもや」をお互いに吐き出せるチームづくりをベースにしているという。アジャイルの文化に慣れ親しんだ岡澤氏にとって「ズバズバ言うのが当たり前。しかし、こうした上司はアジャイルに慣れていない部下にとっては面倒くさいだろう」と反省する。そこで、それぞれの施策の意味を言葉で伝えるなど、共通意識を持てるコミュニケーションを心掛けているそうだ。
最後に今後について岡澤氏は、「エンジニアが楽しく働いて、ビジネスとしての成功につながる仕組み」を創出したいと語る。そして、「ビジネス側から見て『こうしよう』というよりも、一人ひとりのエンジニアが躍動することでビジネスにつながる仕組みができると、私たちの会社の在り方としてはベスト」と語り、「アジャイルをやるとビジネスが進む、という共通認識を醸成していきたい」と意欲的な言葉でセッションのまとめとした。
エンジニア組織の課題を解決！
「Findy Team+」は、開発組織のコーディングプロセスや、イシューマネジメントのデータを、GitHub / GitLabやJiraから自動で取得・集計・解析することで、Four Keysをはじめとした開発メトリクスを可視化し、開発チームの高速なパフォーマンス改善を支援するサービスです。
現在、全ての分析機能をご利用頂ける14日間の無料トライアルを実施中！
導入前のご相談・資料請求も承っておりますので、ご興味をお持ちいただいた方は、こちらからお気軽にお問い合わせください！
