経営チーム全員をPO研修に送り込む グロービスは経営層のアジャイルマインドをどう高めたか：開発生産性向上、それぞれの取り組み（1）

多様なオンライン教育コンテンツの充実を図っているグロービスは、重要課題として、開発生産性の向上に取り組んできた。この取り組みに経営層をどうやって巻き込んでいるのか。

[谷崎朋子，＠IT]

　エンジニアリング組織における開発生産性の向上は、現場にも経営層にもメリットのある取り組みだ。だが実際には、視点や言語の異なる経営層やビジネスサイドとの意識のすり合わせと合意形成に大きな課題がある。

　そうした難題に真正面から取り組み、成果を出しているのがグロービスだ。2023年7月13日、ファインディ主催「開発生産性Conference」のパネルディスカッションで、グロービスのVP of Engineeringを務める末永昌也氏と同社エンジニアリングマネージャーの大沼和也氏が、最近の取り組み状況を紹介。「エンジニアリング組織論への招待」の著者であるレクター代表取締役の広木大地氏とともに、課題解決に向けて実施すべきことや開発生産性の考え方などについて議論した。

　なお、ファインディは開発生産性の可視化・分析ツールを提供している。

2年がかりで段階的に開発生産性の向上を図るグロービス

　オンライン教育コンテンツの充実により、事業拡大を続けているグロービス。エンジニア数はこの6年間で0人から100人強に増えた。そうした同社において、開発生産性の向上は重要課題だった。開発現場では、2022年よりデプロイ頻度とリードタイムの計測、改善を進めてきた。

　「当時はデプロイを週1回行うのが通常だったが、どうしても変更するファイルの量や行数がたまってしまい、1回のリリースで複数の変更を実施しなければならなかった。その結果、障害が起きてもどこでエラーが発生しているのか特定が難しくなってしまっていた」（大沼氏）

　そこで大沼氏たちは、都度デプロイする方針に変更。1週間当たりのデプロイ数は約30回となった。コミットしてからプルリクエストを作成、マージされるまでのリードタイムは127時間、つまりおよそ5日かかっていたものを、32時間にまで短縮することに成功した。

グロービスの大沼和也氏

　2023年現在、同社は次のステップとして障害周りの品質の担保に向けた取り組みを進めている。まずは、障害時に迷わず対応できるようにするための対応フローの整備だ。障害対応フローを決めて、最終的にはボット（自動化）などに落とし込み、誰でも迷わず的確な対応ができる状態を目指しているという。また、エラー発生時の影響が数年前よりも拡大傾向にあるため、MTTR（Mean Time To Recovery）の短縮と変更失敗率の低減に向けて計測を開始。さらに、課題感の強いSRE（Site Reliability Engineering）チームが中心になって、500ミリ秒以下でレスポンスを返すことのできる割合を8割と定義し、これをサービスにおける重要なアクションの指標に設定して運用改善を進めているという。

現場における開発生産性向上の取り組み

PO研修に経営層が参加、開発現場への理解を深める

　もう1つ、重要課題として取り組んだのは経営層に開発現場の取り組みの成果をうまく伝えることだ。

グロービスの末永昌也氏

　「経営層と話をするときによく言われるのは、『開発が遅い』『計画が見えにくくなるから小さく作ってほしくない』『デプロイ頻度を高めることの経営上の意味が分からない』の3つ。開発チームには優秀なメンバーがそろっているし、開発が遅いということは全くない。ただし、優先度を落としたものがいつまでたってもリリースされないということは結構あった。そこを理解してもらえるように説明するのが難しい」（末永氏）

　そこで末永氏は3つの施策を実行した。

　1つめは、ナレッジが横に伝播（でんぱ）する仕組みの構築だ。スクラムチームが出した実績のナレッジを、他のチームに横展開することで、全体的なレベルの底上げが実現した。経営層にも改善が分かりやすく伝わったという。具体的には、Scrum@Scaleを取り入れて、スクラムマスター同士が情報共有して展開する。

　2つめは、経営チームのアジャイルマインド強化だ。プロダクトオーナー（PO）研修に経営チーム全員を送り込んだり、広木氏の著書「エンジニアリング組織論への招待」の読書会に参加してもらったりと、エンジニアチームとの知識や意識の距離感を少しでも縮めるために末永氏は奔走した。

　そして3つめは、対外的に評価されていることを示すことだ。グロービスはファインディがユーザーの優秀な取り組みに与える賞である「Findy Team+ Award 2022」を受賞した。

　「経営陣に分かりやすく説明しているつもりでも、本当に理解してもらえているか不安だった。それがアワードを受賞したことで、これまでの取り組みの価値がようやく伝わったと感じた」（末永氏）

経営層の理解を高める3つの取り組み

　グロービスのこれまでの取り組みを聞いた広木氏は、ここ数年ファインディなどが開発生産性を可視化して指標を作るといった取り組みを続けてきたことで、ようやく共通言語での対話が始まった感があると述べた。この共通言語について、末永氏もここ数年の大きな進歩だと賛同した。ただし、「Googleが提唱する指標」といった、自社に合うのかどうかが分からない指標を持ち出したところで意味がなく、「何らかの指標を目安にきちんと現場で具体的な結果を出していくことが大切」と付け加えた。

開発生産性の指標の使いどころ

　パネルディスカッションの口火を切ったのはモデレーターでファインディの佐藤将高氏。経営チームをPO研修に連れ出すという発想に驚きを示した。これに対して末永氏は、経営チームも現場を理解したいと常日頃思っているので、提案したところすんなりと受け入れてもらえたと明かす。実際、参加した経営陣の1人が「経営チームもアジャイル化したらいいのではないか」と提案したという。これは末永氏が以前からもくろんでいたことだっただけに、理解者が増えたことに喜んだという。大沼氏も、「（この経営幹部は）普段から1on1で現場の状況や温度感を共有していた1人だったので、理解の感度がかなり高くなっていたのかもしれない」と述べつつ、経営チームからそうした提案が出ることに驚いたと述べた。

レクターの広木大地氏

　「上層部などに何かを説得したいとき、つい理屈を並べ立てた資料を用意しがちだが、実はもう少しウェットなところから相手の理解や信頼を積み重ねていく方が説得の近道なのかもしれない」。そう納得する広木氏は、自分とは異なる領域の人とコミュニケーションするときの大事なポイントだと強調した。

　では、プロダクトマネジャーやビジネスサイドとのコミュニケーションはどうだろうか。佐藤氏は「ビジネスサイドから機能開発をしたいと言われることはあっても、技術的負債を解消しようと言われることはあまりない。そういったリソース配分、技術的負債、機能開発などについてのコミュニケーションで工夫したことはあったか」と質問。これに対して大沼氏は、「以前は、20%ぐらいは技術的負債の解消のための時間に割り当てようと旗を振っていたが、スクラムチームのメンバーは今現在のスプリントゴール達成に向けて全力疾走しているので、ゴール達成を優先したい。何とかリファクタリングの時間を作ってやろうとしたが、あまりうまくいかなかった」と吐露した。

　そこで考えたのは、チームトポロジーでいうところのストリームアラインドチームとは別に、プラットフォームチームやイネイブリングチームのような「Dev Experience」チームを設置することだった。これにより、フィードバックサイクルは担保しつつ、リファクタリングする体制が整ったという。

　ここで広木氏は、「経営チームやビジネスサイドはデプロイ頻度の数値を本当に知りたいと思っているのだろうか」と疑問を述べた。

　「例えばセールス部門の人から『セールスポイントが0.8から16.2になった』と言われても、分野外の人にとってはピンとこない。おそらく経営チームは経営目標の計画や達成において意味のあるデータが欲しいだけで、それを『開発生産性』という単語で表現しているだけなのかもしれない」（広木氏）

　末永氏は考え込みながら、「うちのチームがイケてるのかイケていないのか」を知りたいだけで、開発生産性の数字など詳細を知りたいわけではないのかもしれない」と言及。広木氏もうなずき、そうした事情であれば解決は簡単で、外部の人が経営チームに「グロービスの開発チームって最近イケてるよね！」と言うだけで話は終わると笑いながら返した。

　「注意したいのは、経営チームからイケてるかどうかを示す数字を求められたり、どうなっているのかと質問されたとき。そういう行動に出るときは、イケてないのではないかと疑っているから。そういうときこそ、開発生産性の計測データが役に立つ。計測データはエンジニア側できちんと管理し、良いチームであると自信を持つためのデータ。常に誰かに説明し続けるものではないと思う」（広木氏）

　これに対して末永氏は、「どれだけ信頼される組織になるかということで、とても大事な課題」と述べた。大沼氏も、エンジニア側が自己管理できていることを証明するための手段として開発生産性の計測データがあると述べ、経営チームの安心材料としてきちんと管理することが大切とした。

　最後に末永氏は、エンジニアリング組織の健全性を計る指標「d/d/d」（deploys / a day / a developer：1日あたりのデプロイ回数を開発者数で割ったもの）が、健全と言われる0.1以上になるプロダクトが増えたと言及。「10人のチームであれば、1日3回ほどはデプロイしている状態。この取り組みは1つのチームで始めたが、少しずつ他のプロダクトにも広がり、中には0.3を超えるところも登場している。これからも開発生産性の高い組織を目指して頑張りたい」と述べた。