なぜ我々は開発生産性を高めるのか
vonxai合同会社の夏目です。先日開発生産性について友人のエンジニアが以下のようなポストをしているのを見かけました(ご本人に掲載許可を得ています)。
開発生産性でIssueの消化速度とか測定して「改善」していくの、最近ネット記事でよく見るんだけど、そんなに嬉々として語ることなのか、、？
— はやぶさ (@8yabusa) April 24, 2024
もっと蛇口ひねれば水出ますよみたいな、そういうモデルで捉えられるのが若干しんどいわ
開発生産性を考える際、指標の導入や改善事例に焦点を当てる記事では、背景や本質に触れることがないことがあり、導入時に十分な説明がなくプレッシャーを感じることがあります。そこで、開発生産性の歴史や背景についてまとめ、一般的な問題やその解決策としても本記事が役立てばと考えて執筆しました(本記事では各指標の詳細な解説はしません)。
開発生産性とは
開発生産性という言葉は開発者の生産性を上げることのみを指す狭義な意味と、効率的で高品質なソフトウェアデリバリーを実現する組織づくりを指す広義な意味の２つがあります(ここではソフトウェアデリバリーにおける開発生産性を扱い、インプットとアウトプットの定量的な計測を期待する労働生産性については扱いません)。AWS re:Invent 2021のDevOps and Developer Productivityトラックで使用されている生産性という言葉は前者を指しており、Google Cloudの2023 年の State of DevOps Report: 組織文化の重要性で使用されている生産性という言葉は後者を指しています。
開発生産性を組織や個人のパフォーマンスを測るベンチマークとして使用すると、最初のX(旧Twitter)の投稿にあったように組織のメンバーにプレッシャーをかける可能性があります。そのため、狭義の開発生産性を指標として導入しようとするとコンテキストが欠落しやすく、メンバーとの摩擦を招く可能性があるため注意が必要です。
開発生産性の歴史と普及
ソフトウェアデリバリーにおける開発生産性はアジャイルやDevOpsが基になっており、インフラ管理自動化のOSSであるPuppetを開発しているPuppet Labsが、2014年にソフトウェアの提供パフォーマンスや組織に与える影響を調査するためのレポート『2014 State of DevOps Report』を発表しています。これが後にFour Keys(またはDORA指標)として知られるようになるメジャーな開発生産性指標を作成したDORA(DevOps Research and Assessment)チームの元となる著者が集まったレポートになります。本レポートの著者はDORAのCEOとなったNicole ForsgrenやPuppet LabsのCIO、Chef SoftwareのVPといったDevOps勃興期の関係者が揃っています。DORAは2018年にGoogle Cloudによって買収された後、毎年のState of DevOps ReportをGoogle Cloudのブログでも公開しています。
2020年にGitHubのVP of Research & StrategyとなったNicole ForsgrenはMicrosoft Researchのメンバーと共著で『The SPACE of Developer Productivity(2021年)』というものを発表しており、SPACEという新たなフレームワークを打ち出しています。その流れもあり、GitHubやMicrosoftはSPACEを利用して『GitHub Copilotが開発者の生産性と満足度に与える影響を数値化(2022年)』や『Navigating the SPACE between productivity and developer happiness(2023年)』といった生産性と開発者の幸福度についての記事を公開しています。
代表的な開発生産性の指標
ということで現在よく取り上げられる開発生産性のルーツは、元をたどるとアジャイルとDevOpsの研究からの派生になります。
しかしいざ開発生産性の指標を導入しようとしても、導入の目的や用途を誤るとチームの生産性が下がってしまいかねません。指標の解説や導入事例を紹介する記事は多くてもバックグラウンドについてまで触れられない事もあるので、ここではそれぞれの思想や目的をベースに紹介をしたいと思います。
Four Keys
DORAが発表した指標です。ソフトウェアの提供パフォーマンスや組織に与える影響を調査するために作成した『State of DevOps Report』から生まれた指標で、効率的で高品質なソフトウェアデリバリーを行う組織づくりをするための指標として提示されました。具体的な指標とそれらを実際に集計しダッシュボード化するためのツールが公開されているため、気軽に導入できることが魅力の一つです。
DORAはソフトウェアの迅速で確実なデリバリには熟練度ではなくケイパビリティ(組織全体やグループとして保持する機能や能力)が重要であるとし、技術的・プロセス的・文化的ないくつかのケイパビリティを定義しています。
これらのケイパビリティを元にパフォーマンスを計測することで、アウトカムが得られるというモデルをDORA Core modelとして公開しています。現在のモデルはv1.2.2で、v2にむけてのプロポーザルがGitHub上で話し合われています。
このモデルは、セキュリティ対策のシフトレフト・Continuous Delivery・創造的な組織文化・変更管理プロセスの合理化といったケイパビリティがソフトウェアデリバリーのパフォーマンスに直結し、それらがアウトカムとして組織のパフォーマンスや個人の幸福度に繋がり、結果としてデリバリーパフォーマンスの向上に寄与するといったものを表しています。注目すべきは幸福度が組織のパフォーマンスに寄与するという点で、幸福度が低い組織はパフォーマンスも劣化すると結論付けていることです(ここでいう幸福度とはデプロイ時の恐怖・緊急対応など予想外の作業・燃え尽き症候群の少なさを表しています)。Four Keysを計測することでこれらのパフォーマンスが計測でき、幸福度の向上に繋げられると考えられています。
またNicole Forsgrenは2023年の開発生産性カンファレンスにて「DORAは組織や個人を評価するためのベンチマークではなく、パフォーマンスを計測し改善するためにどのケイパビリティを向上させるかのアクションにつなげるために利用する」と発表しています。
少し古いですが、DORAのメンバーが出版した『LeanとDevOpsの科学』という著書が、これらの指標の決定づけや組織づくりについての詳細をまとめているので読んでみると良いかもしれません。
SPACE
DORA元CEOのNicole ForsgrenがMicrosoft Researchのメンバーと共に発表したフレームワークです。このフレームワークはFour Keysを補完し、ソフトウェア開発者だけでなく、より広い範囲で適用できるようになっています。SPACEは既存の開発生産性指標における個人のパフォーマンス測定に利用されやすいという問題や、コミット数のような開発者のアクティビティのみで生産性を捉えるだけでは不完全といった課題を解決するために生み出されました。Four Keysで改善したいケイパビリティを選び、SPACEで計測方法を決定するといった使い方もできます。
ただしSPACEはあくまでもフレームワークであり、組織ごとに指標や計測方法を決める必要があります。以下の指標は一例になりますが、Four Keysと違い、定量的な指標以外に定性的な指標も多く導入されています。
GSM
GoogleのEngineering Productivity ResearchチームのFounderであるCiera Jaspanが提唱しているフレームワークです。GSM自体がいつから用いられていたのかは不明ですが、GSMに関する詳細はO’Reillyから出版された『Software Engineering at Google(2020年)』の第七章に記載されています。
GSMでは、生産性を計測することの目的や価値、そしてその結果に基づいて行動することの重要性を強調しています。ここで重要な点は、定量的な分析だけでなく定性的な分析も必要であり、両者が一致していることです。そのためには、Goals→Signals→Metricsの順番で決定し、目的を見失わないようにすることが重要と説明しています。
開発生産性の現時点での評価
LeadDev社が2023年に行った600を超えるエンジニアリングマネージャーを対象とした調査レポート『Engineering Team Performance Report 2023』では、Four Keysが効果的だと答えたのは全体の64%、SPACEが効果的だと答えたのは全体の41%でした。Dont' know/unsureを除くとFour KyesとSPACEのどちらも効果的でないと答えたのは10人に1人未満でした。
パフォーマンス指標を計測する理由として一番に挙げられているものは「エンジニアのベロシティ向上」で37%でした。また6%が「昇進、昇格、解雇の決定のため」に利用しているという結果も得られました。
正確な数値は確認できませんでしたが
Interestingly, only a fifth of engineering leaders identified team resistance to being measured as one of their main challenges.興味深いことに、エンジニアリング・リーダーの5分の1だけが、測定されることに対するチームの抵抗を主な課題の1つとして挙げている。
という記述があり、20%程度が計測されることをチームの課題として捉えています。
開発生産性のこれから
Four KeysやSPACEを打ち出したNicole Forsgrenは、2023年にGitHub時代の同僚であるAbi Noda率いるDX社とMicrosoft Researchメンバーの共著で『DevEx: What Actually Drives Productivity』を発表しています。これは既存のFour Keysのような機械的な計測には限界があり、DevEx(開発者体験)の向上こそ生産性の向上につながるという考えです。ちなみにDX社がこれを元にモデル化したDX25というものを公開しています。
またAbi NodaはGSMの提唱者であるCiera JaspanとPodcastをしており、そこでCiera Jaspanが2023年にEngineering Productivity Researchチームのメンバーと共著で公開した『A Human-Centered Approach to Developer Productivity』という記事について議論しています。
Four KeysとSPACEを提唱したNicole Forsgrenが2023年に開発者中心のアプローチに関する論文を出し、GSMを提唱したCiera Jaspanも2023年に人間中心のアプローチに関する記事を出しているという点で共通しており、今後の流れとしては組織づくりから個を意識した開発生産性にシフトしていくのかが注目です。
おわりに
本記事で頻出しているNicole Forsgrenが2024年6月28〜29日にFindy主催の開発生産性 Conference 2024に登壇するので参加してみると面白いかもしれません。彼女は2024年にもDevExに関する論文を出しているので、今回はそれに関する話が中心になると思われます。もしかしたら開発生産性の組織から個へといったポイントについても触れられるかもしれません。
開発生産性を向上させるために指標を導入する際や、最初のX（旧Twitter）の投稿にあるような摩擦を生まないために、少なくとも以下のポイントが重要になります。
計測する目的をはっきりさせる
指標を計測した結果どうするのかを決める
マネージャーやメンバー含めて上記認識のすり合わせをする
本記事を執筆するにあたり、執筆のきっかけを与えてくださり、さらにはレビューまでしていただいた @8yabusa に感謝します。
※開発生産性の指標はあくまで開発の生産性を高めるためのものであり、顧客に価値を届けられているかは別の話です。
この記事が気に入ったらサポートをしてみませんか？