自律的な改善を促す組織文化の形成へ。生成AI時代を見据えたKDDIアジャイル開発センターの組織づくり
アジャイル開発でDX開発支援を行うKDDIアジャイル開発センター株式会社では、エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。
今回は、開発戦略本部長でVPoEを務める岡澤さん、スクラムマスターの吉村さんにインタビュー。開発生産性の可視化への取り組みを始めた背景や、「Findy Team+」を今後どのように活用していきたいかなどについて、お話をうかがいました。
目次
社内の部門から会社へ。アジャイル開発でDXを推進
――まず最初に、お二人の主な経歴や現在の役割について教えてください。
岡澤：ソフトウェアエンジニアを経てKDDIに入社し、認証系サービス、セキュリティサービス、IoTサービス、海外スタートアップ企業との新規事業立ち上げなどいろいろとプロジェクトをリードしました。KDDIでアジャイル開発の立ち上げをスクラムマスターとして行った後は、エンジニアリングマネージャーとしてエンジニア育成やビジネスモデル、プロセス、企業文化の変革などを推進してきました。
2022年7月からKDDIアジャイル開発センターの事業開始に伴い、VPoEと開発戦略本部長に就任しました。もともとKDDIのアジャイル推進をしてきた背景もあり、いろいろな役割を担っておりますが、社内の組織をどうしたらより良くしていけるかというところも担っています。まだできたばかりの会社なので、実際に各案件のコンサルにも入るなど、幅広く動いています。
今回の話題に関するところでは、組織をより良くしていき、いかにエンジニアが楽しく働けるかを、きちんと仕組みとして取り入れていくこと。これを振り返りも含めて進めていくところが大きいですね。
吉村：メーカーで新規事業担当としてB2Bサービスの開発を行い、企画から開発までの一連のプロセスを経験した後、KDDIアジャイル開発センターに転職しました。
現在は、スマートシティの開発で3つのスクラムチームがあり、その支援をしています。ロールはスクラムマスターですが、一般的に定義されている動き方とは少し違うかもしれません。具体的には、最初期のアーキテクチャを描いたり、先行的な調査をしたり、各チームで解決できない課題に対応したりしています。加えて、顧客との各種調整やエンジニアの採用など、幅広く行っています。
――アジャイル開発センターの開発組織について教えていただけますか？
岡澤：もともとアジャイル開発センターは、KDDI社内の1つの部門だったのですが、それがそのまま会社になった背景があります。開発組織は5部門あり、パートナーも含めると400人くらいの規模。さまざまなプロダクト、チーム規模のスクラムチームが、40チームほどあります。
そのなかに高輪ゲートウェイスマートシティ開発チームと、auでんきチームの2つがあり、まずはその2チームから「Findy Team+」を導入しています。
――御社の開発組織では、どのようなミッションを掲げていますか？
岡澤：我々がミッションとして掲げているのは、国内のお客様のDX推進です。そのなかでも大きく2つあって、この両方に取り組んでいます。
1つは内製支援のような形で、実際にアジャイル開発センターのメンバーがチームに入って、育成しながらサービスをつくり上げていく。それが終わったころには、お客様の中でエンジニア組織やアジャイルなマインドができあがっているという流れで、その企業のDXを推進していくものです。
もう1つは、今までウォーターフォールなどのやり方をされてきて、新しいサービスがつくれないお客様がいらっしゃるので、UXデザイナーを含めてビジネス変化に対応しながら開発を進めていくものです。
2つの大規模プロジェクトで「Findy Team+」を導入
――「Findy Team+」導入前にあった課題感や、開発生産性の計測に取り組まれた背景について教えてください。
岡澤：いくつかありますが、エンジニアの働き方をより理解したうえで、1on1に取り組んだり、フォローしたりできるようにしたいというのが、まず1つ。なので、生産性を計測したいというよりは、見える化を進めたいというイメージですね。
また、スクラムは良くも悪くもスクラムのなかで完結してしまえば問題なく、40チームあるので各チームで最適化が進んでいます。ですが、より一層良くしていくために、横との比較ではなく、メンバー同士でお互いに気づきが得られるものがあるといいなと。実際に今、横のチームのベロシティなどは見れるのですが、それとはまた違う気づきが生まれるきっかけをつくりたいと考えていました。
それから、スクラムチームでは、メンバーが固定されてずっと同じチームでいることが理想ですが、実際にはそれは難しく、人が入れ替わるタイミングがきます。そのタイミングでより適切に、エンジニアが働きやすい状態のままメンバーを入れ替えたり、新しいチームをつくったりしたい。そういう場面で、定性的な情報だけでなく定量的な情報まで、今見えている観点以外にも見れたらいいなと思っていました。
吉村：「Findy Team+」導入に関しては、岡澤さんから話をもらったのが最初のきっかけでした。ただ、個人的にはもともと可視化にはすごく興味があって。製造業にいたときに、その会社で「測定なくしてコントロールなし」という標語があったんです。それがずっと頭に残っていて、生産性の可視化にはずっと興味を持っていました。
スクラムやアジャイルをやっていくなかで、お互いの不理解もあって、生産性という言葉を頭ごなしに使ってしまうケースがあると思います。生産性という言葉は、過剰に反応されたり嫌われたりしがちな面もありますが、それで終わらせてしまうと、ベロシティで一方的に評価される状況から次のステップに進まないと感じています。
以前はGitHubやJIRAのAPIからデータを取ってきて、ElasticSearchに入れてKibanaで見たりしていたのですが、各チームのブランチ戦略やチケットのワークフローの違いなどがあり、面倒な部分が多くありました。そこはあまり時間をかけるところではないと考えていたので、その部分をカバーしてくれるツールがあるなら、ぜひ入れてみたいと思っていました。
――現時点では、各チームで開発生産性をどのように可視化していますか？
岡澤：「Findy Team+」を入れていないチームでは、ベロシティがメインで、リードタイムを取ったりしていることが多いですね。基本的には、JIRAやGitHubをベースに見ています。
――「Findy Team+」を導入している2チームは、どういった理由から計測を始められたのでしょうか？
岡澤：高輪ゲートウェイスマートシティ開発チームは、新しく立ち上がったチームで、まずはそこから計測を始めました。2つ目のauでんきチームは、電気自由化のタイミングで立ち上がった、2016年ごろから長く続いているチーム。連携チームは3〜4つほどあります。なので、新たに始める大規模プロジェクトと、もとからあった大規模プロジェクト、この2つに入れて進めてみようという考えですね。
それから、auでんきチームは安定してリリースしているチームでもあります。スクラムでは開発生産性のほかに、振り返りで幸福度を測ったりするんですね。生産性と幸福度はチームビルドにとても影響するものなので、単一なプロダクトで、チームがどういう状況であればベストなのかを知りたいというのが、大きな目的の1つでもありました。
定量面と定性面の両方を見ていくバランス感が重要
――最近はFour Keysのほかに、SPACEなどのフレームワークも注目を集めています。御社としても定量面だけでなく、定性面も重視する意識が強いですか？
岡澤：スクラムやアジャイルは、心理的安全性があるうえで、チームで働くことによって安定して開発ができるものです。なぜスクラムマスターがいるかというと、エンジニアが開発に集中できるように、障害物を取り除くため。つまり、エンジニアがエンジニアらしく働けるようにするためなんですよね。これは先ほどお話しした幸福度もそうですが、かなりSPACEの考えに近いところがあります。
ただ、そこってなかなか表現しにくい部分ではあると思うんですよ。チーム開発をしたことがない人は、個別に開発した方が速いと思うかもしれません。でも、もちろん不満やモヤモヤを抱えた状態だと仕事は進みませんが、そういったものがまったくない状態でチーム開発をしていくと、生産性は最も高くなると考えているんです。
「Findy Team+」は、そういったところの一部を見やすくできるものだと思っています。なので、一人ひとりのコミット量を見て、メンバーを監視するような使い方は、まったく想定していません。
吉村：幸福度などを測ることも重要な一方で、定性的な指標だけに偏ってしまうと、外から見たときに、ただ仲良くやっているだけに見えてしまう可能性もあります。なので、そういった定性的な指標を追う活動が、定量的にどう効いているのか、不確実性を下げるエンジニアリングにどう寄与しているのかは、開発者として責任を持つ必要がある。そこのバランスが重要だと思っています。
事業部では売り上げなどの数字を、責任を持って追っているじゃないですか。それに対して、開発は何を追っているのかというときに、一例として、我々は開発生産性やリードタイムなど、そういったところに責任を持っていると言えるといいのかなと考えています。
――今後OKRやKPIとして、定量的な数値を設定することは検討されていますか？
吉村：高輪ゲートウェイスマートシティ開発チームでは、そういった目標の設定を目指したいと思っています。ただ、現状はようやく人が固定化してきて、やっとチームの型ができてきたところなので、各数値の定義はまだこれからですね。
例えばプルリク数などは、そこにコミットするというほどではなくとも、いったん目標を置いて振り返っていくことは、自分たちをコントロールする意味でもやっていきたいなと思っています。
――現在は、新しくジョインした方がスムーズにオンボーディングできているかなどを、「Findy Team+」で追っていると伺いました。それ以外にも、何か活用されている例はありますか？
吉村：それ以外では、主に1on1で活用しています。1on1をするときに、スクラムマスターとして定量的な情報を把握したうえで、メンバーと会話したりとか。メンバーによっては直接ダッシュボードを見せて、前週との違いを実感と合っているか確かめたりなど、1on1の話題として使っています。
“チームの良い状態”をトータルで可視化することを目指す
――今後「Findy Team+」をどのように活用していきたいと考えていますか？
岡澤：アジャイル開発センターは、ずっとKDDIのなかでエンジニアを育成してきた背景があり、毎年グループ会社のエンジニアを受け入れて育成しています。そういった際に、メンバーがどれくらい成長したかを定量的に示してあげられると、本人自身が成長実感を得やすくなると考えています。
吉村さんのチームにも1年目のメンバーが入っていますが、そういうメンバーにとっては、自分がどれだけチームに貢献できているかわかりにくく、不安を感じやすいですよね。チームに貢献していることが見えれば、成長実感が得やすいと思うので、そういった教育的な観点での活用を進めていきたいと思っています。
吉村：直近は導入したばかりで、これからデータが溜まっていく段階です。理想を言えば、せっかく可視化できているので、今後はダッシュボードなどをもっとオープンにしていけるといいのかなと思います。ただ、そこは少し注意も必要なので、ゆっくりとやっていきたいですね。
まだまだ入口の段階なので、「自分たちの生産性って何だろう」とか、そういう会話をするきっかけにできたらいいなと思っています。今求められているのは、スループットなのか、リードタイムなのかとか。「Findy Team+」ではいろいろな数字が取れているので、「この期間はこれを追っていこう」といった、前向きな議論につなげていきたいです。
――そのほかにも、開発生産性の計測に関して今後トライしていきたいことがあれば教えてください。
岡澤：アジャイル開発センターでは今、生成AIをかなり活用しています。Copilotもそうですし、それ以外の開発ツールの導入も検証したり、いろいろな生成AIを活用したサービスもつくったりもしています。我々としては、ずっとスクラムやアジャイルをやってきたなかで、そこにAIが入ったらどうなるのかをすごく考えているんですね。Copilotを入れれば働き方が変わるし、それによってどう変わったのかを、定量的に見ていきたいと思っています。
エンジニアリングのなかで、例えばCursorを使ったり、もしくはSourceGraphを使ったり、Copilot以外を試してみたり、我々の組織、開発スタイルにフィットしたものを色々試している状況です。そういった開発ツールの導入を推進して開発が楽しくかつ先進的な働き方ができると、すごくいいなと思いますね。
ただ、やはり最も目指したいのは、チームの良い状態をトータルで可視化すること。例えば、切羽詰まって頑張っているチームは、一時期の生産性は高くても、メンバーは幸せではなくて、その後が続かないというケースがありますよね。社員エンゲージメントが低くなることは一番の問題で、成長実感があって楽しい状態が組織として健全だと考えています。
そして、我々は感覚として、アジャイルがすごく良い方法で、結果的にビジネスにも貢献できていると思っています。それはやってみればわかることなのですが、やったことがない人たちには伝わりにくい。そのあたりが可視化できて、今我々が進めていることの裏付けになると、お客様にとってもメリットがありそうだと感じています。
――それでは最後に、御社の組織のアピールポイントや、一緒に働きたいエンジニア像を教えてください。
お客様と共に新たなビジネス創出に乗り出し、自らの専門知識をフルに活かして共に高みを目指す挑戦を楽しむ。そんな情熱を共有できる方と一緒に働けることを心から楽しみにしています！
――岡澤さん、吉村さん、ありがとうございました！
※KDDIアジャイル開発センターでは、エンジニアを募集しています。
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
