Googleが実践する開発生産性測定と実証的ソフトウェア工学の知見
公開日
開発生産性
ソフトウェア開発組織において、開発者の生産性や開発者体験（DevEx）をどのように測定し、改善につなげるかはマネジメント層や開発チームにとって大きな関心事です。定量的なログデータだけでは開発者の実感や背景が把握しづらく、アンケートやインタビューだけでは全社的な傾向を捉えにくいという課題は少なくありません。
この記事では、ACM SIGSOFT SEN-ESEコラムとして公開された取材記事「Empirical Software Engineering in Practice: Insights from Google」をもとに、Google社内で開発者の生産性や体験を専門に研究するチームの取り組みを紹介します。
Googleの開発者インテリジェンスチームが担う役割
本記事は、フィレンツェ大学のRoberto Verdecchia氏とアムステルダム自由大学のJustus Bogner氏が、GoogleのDeveloper Intelligenceチームに所属するCiera Jaspan氏（ソフトウェアエンジニア・リサーチャー）およびCollin Green氏（UXリサーチャー）へ実施したインタビューの記録です。
インタビューに応じたチームは、自ら開発ツールを直接開発するチームではありません。Google社内にある多数の開発ツールチームやインフラチームを横断し、ソフトウェアエンジニアが抱える大きな課題を特定して、ツールの導入やプロセスの改善効果を測定・評価するための研究を行っています。
チームにはソフトウェア工学の専門家だけでなく、認知心理学、行動経済学、社会学、政治学など多様な博士号を持つ人材が集まっており、Googleという大規模な社会技術システムを多角的に分析できる体制が整えられています。
定量ログと質的調査を組み合わせる「混合研究法」の重要性
取材の中で両氏が一貫して強調しているのが、定量的データと質的データの両方を組み合わせる混合研究法です。
ログデータは「何が起きたか」を示し、質的データは「なぜか」を示す
定量データは数値として現象を素早く示してくれますが、その数値が良い状態なのか悪い状態なのかを判断する基準は提供してくれません。
Jaspan氏は具体例として、Google社内でのコードレビュー完了時間の中央値が5分である事例を挙げています。単に「5分」というログの数値を提示されても、それがエンジニアにとって早すぎるのか、もっと短縮すべきなのか、あるいは十分なのかは判断できません。開発者に直接ヒアリングを行うことで初めて、その時間が業務上の負担になっているのかどうかが判明します。また、パンデミックなどの環境変化によって数値が変動した際にも、なぜその変化が生じたかを掘り下げるには開発者の声を聞く必要があります。
ログとアンケートの不一致から測定のずれを発見する
ログデータ、アンケート調査、インタビュー結果という異なる複数のデータソースを照合することで、結論の確度が高まります。
さらに、これらのデータソースが一致しない場合、ログ記録の予期せぬ不具合や、調査側が意図した質問内容と開発者の解釈との乖離を発見する契機になります。たとえば、開発者へのインタビューを通じて、アンケートの質問に対して想定と異なる前提で回答していたことが分かり、ログとアンケートが別々の事象を測定していたと判明するケースが報告されています。
大規模組織における生産性測定の課題とアプローチ
Googleのような大規模組織であっても、すべての課題に対して完全な統制実験（A/Bテストなど）を実施できるわけではありません。開発者が通常業務を行っている現場では、公衆衛生や経済学に近い観察研究や傾向スコアマッチング、事前事後比較などの手法が活用されています。
表1：Googleの研究チームにおける主要な測定対象と成果の状況
| 測定対象 | 採用されたアプローチ | 結果・現状 |
|---|---|---|
| フロー状態（没入感） | 質的・行動的調査で概念を定義し、ログから検知する数式モデルを構築 | 主観的アンケートデータと照合しながらモデル化に成功 |
| オンボーディング（立ち上がり） | 新規メンバーの主観的な完了状態を定義し、大規模ログで追跡可能な代替指標を策定 | 指標の確立に成功し、教育施策のA/Bテスト等に活用 |
| コード品質 | アンケート、インタビュー、日誌調査から高品質なデータセットを作成 | ログベースで客観的に測定できる汎用的な指標の確立には至らず |
| 技術的負債 | 経営層とエンジニア双方からの問題意識に基づき測定を試行 | ログベースの客観的指標の確立には至らず |
表1に示すように、エンジニアが集中して作業できているかを表す「フロー状態」や、入社後の「立ち上がり期間（ランプアップ）」については、質的調査で定義を固めたうえでログによる代替指標を導出することに成功しています。
一方で、「コード品質」や「技術的負債」をログデータだけで客観的かつ汎用的に測定する試みについては、現時点でも良好な指標の確立には至っていないと率直に報告されています。
意思決定につながらない調査は行わない優先順位付け
研究チームには、全社的なアンケートから集まる開発者の声や、経営陣が抱える組織構造の検討など、対応可能な件数を上回る課題が寄せられます。その中で研究対象を選定する基準として、以下の点が挙げられています。
- 調査結果によって変更される具体的な意思決定が実際に存在するか
- 結果が関係者の当初の計画や仮説と異なる場合でも、方針を見直す余地があるか
- 既に外部の学術文献などで答えが出ていないか
仮に調査を実施しても、結果にかかわらず予定通りの施策を進めることが決まっている場合、その調査は実施しないという判断基準が共有されています。
また、社内への結果共有にあたっては、ダッシュボードやレポート、集計スクリプトなどを広く公開し、透明性を確保している点も特徴です。これは、研究チームが従業員を一方的に監視する存在とみなされることを防ぎ、開発者の声を組織に届ける支援者として認知してもらうために配慮されています。
開発組織が自社の生産性評価を見直すための視点
本記事で語られている内容はGoogleという大規模かつ独自の技術基盤を持つ組織での実践ですが、一般的なWeb開発組織やマネジメント層にとっても参考になる視点が含まれています。
ツールやインフラ以外の外部要因に目を向ける
Green氏の指摘によると、開発者の生産性には使用しているツールやインフラの性能だけでなく、世界的なスポーツイベントや国政選挙、パンデミックといった外部環境の変化、さらにはチームの心理的安全性やコミュニケーション動態が大きく影響します。ログの推移を評価する際には、ツールの変更だけでなく組織内外の出来事も考慮して分析することが有用です。
確証バイアスに対して質的エピソードを活用する
データ分析の結果が関係者の直感や過去の成功体験と対立する場合、方法論そのものへの疑義が生じやすくなります。記事内の事例では、ログ分析で処理時間の中央値が「3分」と示された際に「20分はかかるはずだ」と受け入れなかった関係者に対し、開発者の作業日誌と該当ログを突合させた個別事例を複数提示することで、その関係者の認識が全体平均とは異なっていたことへの納得を得られたと説明されています。
自動化が進む環境におけるエンジニアの役割の再定義
対談の終盤では、生成AIや自動化技術の進展に伴い、開発者の役割が変化している点にも触れられています。
Google社内の観察事例として、ジュニアエンジニアが「どのように実装するか（How）」をAIに尋ねるようになり、シニアエンジニアに対しては「なぜこれを作るのか（Why）」という目的や戦略に関する質問をする割合が増えている兆候が紹介されています。自動化可能なタスクと人間が判断すべき領域を切り分け、チームの育成や協調体制を再設計していくことが、今後の開発組織における重要な検討事項となります。
まとめ
GoogleのDeveloper Intelligenceチームへのインタビューからは、開発生産性や開発者体験の測定において、ログデータ（何が起きたか）と質的データ（なぜ起きたか）を組み合わせるアプローチの重要性が示されました。フロー状態やオンボーディングのように代替指標の確立に成功した領域がある一方、コード品質や技術的負債のようにログだけでの客観測定が依然として困難な領域も存在します。
本報告はGoogle社内の特定の研究環境に基づくものであり、すべての組織規模や開発手法にそのまま当てはまるわけではありません。しかし、測定のための測定を避け、意思決定に直結する問いを立てること、そして開発者の実感とログの数値を丁寧に照らし合わせていく姿勢は、多くの開発現場において役立つ判断材料となります。
開発生産性やチームビルディングにお困りですか？ 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるためのさまざまなソリューションを提供しています。ぜひお気軽にご相談ください！
参考資料：