開発生産性は測定すべき？マッキンゼーへの痛烈な批判とGitHub社の事例
こんにちは、vonxai合同会社の夏目です。近年、経営層からはソフトウェア開発チームのアウトプットを可視化し、定量的に評価したいという要求が高まっています。そんな中、コンサルティング大手マッキンゼーが「開発生産性は測定可能」という主張を掲げ、独自の指標を提唱したことは記憶に新しいでしょう。
しかし、本当にそんな簡単な話なのでしょうか？ 本記事では、マッキンゼーの主張に対する著名エンジニアからの痛烈な批判を皮切りに、GitHubにおける先進的な取り組み事例を紹介します。そして、真に意味のある生産性の向上について考察していきたいと思います。
マッキンゼーの主張と幻想
2023年、マッキンゼーは『Yes, you can measure software developer productivity』という記事を発表し、ソフトウェア開発者の生産性を測定する独自の手法を提唱しました。この手法は、20社近い企業ですでに導入されているとしており、多くの注目を集めました。
しかし、この主張に対して、テスト駆動開発(TDD)の考案者であるKent Beck氏をはじめとする多くの著名エンジニアから痛烈な批判が浴びせられました。彼らの主張の根底にあるのは、「ソフトウェア開発は、単純な指標で測れるほど単純ではない」 という強い信念です。
一体、マッキンゼーの指標にはどんな問題点があるというのでしょうか？
努力とアウトプットの計測は逆効果？
マッキンゼーの指標の多くは、開発者の「努力」や「アウトプット」といった、目に見える部分の定量的な計測に偏っています。しかし、ソフトウェア開発の価値は本当にそんな単純な指標で測れるのでしょうか？
Kent Beck氏と、Uberの元エンジニアリングマネージャーであるGergely Orosz氏は、ソフトウェア開発の価値を正しく捉えるためには、もう少し広い視野を持つ必要があると主張しています。
彼らは、ソフトウェア開発における価値の創出を、「努力→アウトプット→成果→インパクト」という4つの段階からなるサイクルとして捉えています。
そして、このサイクル全体を考慮することで、「なぜ努力やアウトプットだけの計測では不十分なのか」 が明確になると説明しています。
努力(Effort): 顧客のペインポイントを見つける、解決策のブレインストーミング、計画を立てる、コードを書いてリリースする
アウトプット: デザインドキュメント、ソースコード、本番環境の機能
成果(Outcome): 顧客行動の変化
インパクト: 生み出された価値(収益の増加、解約率の低下等)
この図が示すように、ソフトウェアエンジニアリングの価値は、開発者の努力によって具体的なアウトプットが生まれ、それが最終的にはビジネス上の成果に繋がります。さらに、その成果が、顧客満足度の向上や社会全体への貢献といった、より広範な「インパクト」をもたらすこともあります。
しかし、ソフトウェア開発の「成果」と「インパクト」を明確に区別し、特に「インパクト」を正確に計測することは非常に困難です。なぜなら、ソフトウェア開発は、単純なインプットとアウトプットの関係で説明できるものではなく、「組織」「顧客」「製品」といった様々な要素が複雑に絡み合って成果が生まれているからです。
マッキンゼーの指標の多くは開発者の努力やアウトプットを定量的に計測することに重きを置いています。しかし、Kent Beck氏はこのような指標を用いた評価は、エンジニアの行動を歪め、質の低い仕事を生み出すリスクがあると指摘しています。
例えば、コードのコミット数を評価指標に設定した場合、エンジニアは無駄に小さいコミットを量産するようになり、結果としてパフォーマンスが劣化する可能性があります。これは、経済学者チャールズ・グッドハートが提唱した「グッドハートの法則」を体現したものでもあります。グッドハートの法則とは、「ある指標が目標になると、それはもはや良い指標ではなくなる」というものです。
GitHubの現場主義：生産性を高めるチームづくり
では、開発生産性を向上させるために、私たちは何を指標とすれば良いのでしょうか？
ソフトウェア開発プラットフォームを提供するGitHub社では、この課題に対して、独自の取り組みを行っています。GitHub社が重視するのは、開発者の「熱意」です。GitHubのエンジニアリング担当VPであるNeha Batra氏は、開発生産性を高めるための鍵は、開発者自身が「生産性向上」に情熱を燃やせる環境作りにあると語っています。
定量データよりも、チームの「雰囲気」を重視
GitHub社は、開発生産性を高めるために、開発者満足度調査など、定性的なデータも活用しています。しかし、Batra氏は、生産性の高いチームには、数値化できない共通点があると指摘します。それは、チームの「雰囲気」です。
GitHub社では、チームメンバーがお互いを尊重し、積極的に知識やスキルを共有し、共通の目標に向かって一体感を持ちながら開発に取り組むことができるチーム作りを目指しています。
スキルを共有し、スタートアップのように協働する
GitHub社は、大企業でありながらも、スタートアップのような柔軟な組織文化を維持しています。Batra氏は、組織全体で開発者のスキルを共有し、部門を超えて協力し合うことの重要性を強調しています。
例えば、GitHub社では、毎月「Day of Learning (DOL)」というイベントを開催し、社内のエンジニアが講師となって、様々な技術的なトピックについて講義を行っています。このような取り組みを通して、開発者は常に新しい知識やスキルを身につけることができます。
意思決定を迅速化する「DRIモデル」
GitHub社では、チームのダイナミクスにおいて、誰が指揮を執るかが生産性に大きく影響すると考えています。そして、その考えに基づき、AppleのDRIモデルに着想を得て、各プロジェクトに「直接責任者(Directly Responsible Individual)」を配置しています。DRIは、技術的な専門知識を持ち、関係者からの信頼が厚い人物が選ばれ、プロジェクトにおける最終決定権を持つ役割を担います。
DRIモデルを導入することで、進捗を妨げる「合意による意思決定」を回避しています。
真の生産性向上は、組織全体で取り組むべき課題
GitHub社の事例からもわかるように、開発生産性を向上させるためには、単純な指標による管理ではなく、開発者のモチベーションと創造性を最大限に引き出す環境作りが不可欠です。それは、個々のエンジニアだけの努力に委ねられるものではなく、組織全体で取り組むべき課題と言えるでしょう。
Kent Beck氏やGergely Orosz氏が強く警鐘を鳴らしているように、安易な指標の導入は、開発者の行動を歪め、組織文化を悪化させるリスクをはらんでいます。真に意味のある開発生産性向上を目指すのであれば、彼らが提示する以下の視点を、組織全体で共有することが重要です。
測定はあくまでも手段であり、目的ではない:
何のために開発生産性を向上させるのか？
測定によって得られたデータは、どのように活用するのか？
組織全体の目標と、測定指標が一致しているか？
測定行為自体が、開発チームに影響を与えることを認識する:
測定によって、開発者の行動やチームのコミュニケーションに、どのような変化が起きるのか？
意図しない結果を招かないために、どのような対策が必要か？
数値指標だけに頼らず、現場の声に耳を傾ける:
開発者との対話を重ね、信頼関係を構築する。
現場の意見を尊重し、柔軟に測定方法や評価制度を見直す。
まとめ：より良いソフトウェア開発を目指して
開発生産性向上は、複雑な課題であり、唯一の正解はありません。重要なのは、組織全体で問題意識を共有し、対話を重ねながら、より良い方向へと進んでいくことではないでしょうか。
開発生産性の議論は、単なる「測定」の議論に留まらず、「エンジニアが働きがいを感じ、創造性を発揮できる組織を、いかに構築していくか」という、より本質的な問いを私たちに投げかけていると言えるでしょう。
この記事が気に入ったらサポートをしてみませんか？