■ 1. マネージャーの役割
- フィールドに集中する選手:
- ゲームに勝つのはフィールドに集中する選手であり、スコアボードに釘付けの選手ではない（ウォーレン・バフェット）
- PdM・EMの重要なつとめ:
- プロダクトチームや開発チームがゲームに勝てるようにする
- チームが「スコアボード」ではなく「フィールド」に集中できるようにする
■ 2. 「開発生産性」が流行する理由
- 立場ごとに異なる動機:
- 経営者や幹部は、高額の投資に見合っているかを明らかにしたい
- エンジニアやEMは、自分たちの存在意義を証明したい
- EMは、開発者の従業員満足度を向上したい
- PdMは、エンジニアの採用が難しい一方でやりたいことが多い
- 流行が流行を呼んでいる面もある
- 関係者間のすれ違い:
- 動機が多様なため、さまざまなところですれ違いが起きている
■ 3. 「生産性」の定義
- 生産性の基本式:
- 生産性は産出を投入で割ったものであり、数字で表せる
- 生産性の2分類:
- 物的生産性は、生産したものの数や量を元にしたもの
- 付加価値生産性は、生産したものが生み出した付加価値（金銭など）を元にしたもの
- ひとことで「生産性」というと誤解を招く
- 「開発生産性」の曖昧さ:
- チームが所定の期間内に作れるモノの量（物的生産性、効率）を指す場合がある
- チームが所定の期間内に生み出せる価値の量（付加価値生産性、効果）を指す場合がある
- どちらなのか、両方なのか、文脈によるのかが不明確
- 海外ではDeveloper Productivity（開発者生産性）が主流に見えるが、開発生産性との違いも不明確
■ 4. 開発生産性の文脈で語られる指標
- Four Keys:
- DORAが「開発組織のパフォーマンス」を計測する尺度として提唱したもの
- 現在は5つめの指標として「信頼性」が追加されている
- デプロイの頻度は、本番環境への正常なリリースの頻度
- 変更のリードタイムは、commitから本番環境稼働までの所要時間
- 変更障害率は、デプロイが原因で本番環境に障害が発生する割合
- サービス復元時間は、本番環境の障害から回復するまでの時間
- 焦点はデリバリーに当てられている
- 『LeanとDevOpsの科学』では「生産性」ではなく「パフォーマンス」と表現している
- SPACEフレームワーク:
- 『LeanとDevOpsの科学』の著者の1人Nicole Forsgren氏らが論文で公表
- 「開発者の生産性」の計測にあたり、5つのカテゴリから複数のメトリクスを選ぶことを提唱
- 5カテゴリはSatisfaction、Performance、Activity、Communication and Collaboration、Efficiency and Flow
- 複数カテゴリから指標を選ぶことを推奨している
- システム由来ではなく感覚や感情に由来する指標を含めることも推奨している
- SPACEの指標例:
- Sは従業員満足度、チームへの推薦意向、ツールやリソースの充足、燃え尽きやストレスの有無など
- Pは信頼性、バグのなさ、サービスの健全性、顧客満足度、顧客増加やリテンション、機能の利用状況、コスト削減など
- Aはプルリクエストやコミット数、コードレビュー回数、ビルド・テスト・リリース回数、インシデント対応数など
- Cはドキュメントや専門知識の見つけやすさ、レビューの質、人同士のつながり、オンボーディングの時間や質など
- Eは受け渡し回数、フローを維持する能力、割り込みの回数やタイミングやインパクト、付加価値時間、待ち時間など
- McKinseyの指標:
- 「Yes, you can measure software developer productivity」でDORAとSPACEに指標を追加
- 追加指標はInner Loop（コーディング、ビルド、ユニットテスト）に使う時間の割合
- バックログに対する個人の貢献度スコアも追加
- 同業他社との比較、タレントケイパビリティスコアも追加
- 個人的にはまったく勧めない
- これが「開発者生産性」と呼べるのかは疑問
- マイクロソフトの社内調査:
- 開発者とマネージャーの間で、生産的であることの意味の考え方が一致していない
- 開発者は、コードを書く、プルリクエストを発行するなどのアクティビティの観点で生産性を考える傾向が強い
- マネージャーは、チームの生産性を活動よりもパフォーマンスや効率性の観点で定義する傾向が強い
■ 5. 開発生産性の定義の現状
- 確固たる定義の不在:
- 確固たる「開発生産性」の定義はない
- 狭義の開発生産性:
- 現場で取り組めるため、物的生産性（アウトプット、物量、効率）を指して使うことが多い
- 広義の開発生産性:
- 昨今は「開発生産性」を分類して考えようという流れがある
- SPACEフレームワークはアウトカムに注目している
- 用語の混乱:
- 「開発者生産性」と「開発生産性」が混同されている
- 「生産性」「開発生産性」「開発者生産性」「パフォーマンス」の使い方や意図がまちまち
- 「開発生産性」の意味の認識の違いが問題を生み出す
- 外から降ってきた取り組みへの注意:
- 開発生産性の取り組みが開発チームの外側から降ってきた場合は要注意
- 「アジャイル」「ビッグデータ」「MVP」「DX」と同じ構図
- ふわっとした単語をふわっと使うと意図しない結果になる
- 最初にやるべきは言葉の意味をはっきりさせること
■ 6. 数字だけでは比較できない
- Four Keysによるチーム比較:
- チームAはデプロイ週15回、リードタイム0.5時間、変更障害率7%、復元時間2時間
- チームBはデプロイ週5回、リードタイム4時間、変更障害率2%、復元時間0.5時間
- 「同じチームが同じものを作っているか」という前提が抜けているため比べられない
- 同一チームの変化の比較は容易であり、改善に役立つ
- ゴミを高速に開発するチームと、価値あるものを普通の速度で作るチームのどちらがよいかは自明ではない
- 時間の使い方の比較:
- 設計・開発・テストの時間が70%のチームと50%のチームの良し悪しは時間の使い方だけではわからない
- 計画づくり、教育や学習、仮説検証やインタビュー、実験、調査に時間を使うことは悪いことではない
- 「スクラムだと開発に使える時間が少なくなる」と言われることもある
- 「開発時間が増えれば成果が出る」は単なる仮説
■ 7. コンテキストが先、数字が後
- コンテキスト優先の手順:
- 自分たちが置かれているコンテキストを明確にする
- 解決したい課題を明確にする
- 関係者の間でこれらについて合意する
- そのうえで意味のある数字を使う
- 測定に関する格言:
- 何も測らないより何か測った方がいいわけではない
- 重要でないものの正確な尺度より、価値あるもののあいまいな尺度の方がよい（ジム・ハイスミス）
- 測定できないものは管理できないという考えは代償の大きい誤解（エドワーズ・デミング）
■ 8. 個人単位の計測の弊害
- 誤ったインセンティブ:
- 個人の評価に使えば誤ったインセンティブを与える
- 会社が評価に使わないと言っても、開発者は評価に使われるのではないかと疑う
- 結果として正しい行動を阻害し、間違った行動を誘発する
- 組織単位でも同じことが起こる
- グッドハートの法則:
- 管理のために用いられる測定はすべて信頼できない
- ゴールドラットの言葉:
- どう評価するかを教えてくれれば、どう行動するかを教えられる
- ケント・ベックの事例:
- McKinseyへの反論記事で、計測による弊害の事例を示している
- 計測と数字の扱い:
- 計測できるからといって計測すべきとは限らない
- 計測できたからといって他と比較すべきとは限らない
- 数字は考える材料に過ぎない
- 数字を使うと論理的に見えてしまい、誤った行動を誘発する危険がある
- SMARTの「関連性」:
- SMARTはSpecific、Measurable、Achievable、Related、Time-boundedの頭文字
- Measurable（計測可能）ばかり強調されるが、重要なのはRelated（関連性）
- 問うべきは何と関連性があればよいのか
■ 9. 価値創造を最優先にする
- 顧客との価値交換システム:
- 企業が存続するには顧客との価値交換システムを維持しなければならない（ビルドトラップ本）
- 顧客のペインや仕事を解決し、それによって対価を得る
- 価値創造と開発生産性では、何よりもまず価値創造が重要
- 最初に計測すべきもの:
- まず計測すべきは「価値を創造できているか」
- これがなければプロダクトは持続できず、会社も持続できない可能性がある
- 価値の定義と共有:
- 「価値とは何か」は自分たちで定義する
- PdMなどが中心となり、ステークホルダーと協力して定義する
- 計画セッション、レビュー、報告会、定例会などで全員に何度でも伝える
- うまくいっていない組織やチームほど理解がバラバラ
- そのうえで価値を提供できていることを示す指標を考える
- 価値創造を示す指標:
- NSMなどプロダクトに関する指標を見る
- プロダクト関連の指標は遅行指標になりがちなので、プロダクト開発を時間で区切る工夫が必要
- 組織やチームごとに別の指標を中心に据えると、個別最適化とコンフリクトが起こる
- NSMの例:
- Netflixは月間N時間以上視聴しているユーザー数（Attention）
- Spotifyは有償顧客の月間楽曲再生時間の合計（Attention）
- Amazonはプライムユーザーあたりの購入金額の合計（Transaction）
- Walmartは顧客の1回あたりの購入点数（Transaction）
- Salesforceはアカウントあたりの平均レコード作成数（Productivity）
- Adobeはエンゲージメントが高いサブスク購入者数（Productivity）
■ 10. ゴールの設定と達成
- ゴールを定める:
- ある期間内に何にフォーカスすべきかを、プロダクトチームとステークホルダーが協力して決める
- スクラムのプロダクトゴール、シェイプアップのベッティング、ビルドトラップ本のオプション目標に相当
- 達成基準:
- ゴールの達成可否を判断する定量・定性の基準を決める
- 基準はCVR、離脱率、応答速度など具体的な数字で示せることが多い
- ゴールの達成状況は頻繁に検査する
- 1つのゴールを達成または破棄したら次のゴールに取り組む
- 効果が先、効率が後:
- ゴールが達成できればタスクがすべて終わらなくてもよく、アウトプットの量も気にしなくてよい
- ゴールが達成できなければ、速さも量も関係ない
- まずは効果を達成し、その後に効率を考える
- 効率ばかり重視するとビルドトラップに陥る
■ 11. 何を作り何を作らないか
- 機能開発のコスト:
- ソフトウェアの機能を作るにはお金と時間がかかり、不発率も高い
- 何を作るか（作らないか）を雑に決めると、お金と時間がどんどん失われる
- 機能追加によってコストが非線形に増えやすく、だんだん身動きが取れなくなる
- 不要な機能の削除:
- 不要な機能はどんどん消すべきであり、それは「開発生産性」より重要
- 検証の時間:
- 「何を作るか」を検証する時間にはコードをあまり書かないかもしれない
- それは本質に集中しているためであり、問題ではない
■ 12. 開発生産性の前に問うべき質問
- PdMやEMがチームに問う質問:
- 自分たちのプロダクトのビジョンは何か
- プロダクトは顧客に価値を提供しているか、その根拠は何か
- 今どんなゴールを目指していて、それはビジョンや顧客とどう関係するか
- ゴールを達成できたかどうかはどうすればわかるか
- 今やっている作業はゴールの達成にどう役立つか
- ゴール達成の上での問題は何で、なぜそれが問題か
- これらを踏まえて今何を改善するとよいか
- 効率を語る条件:
- チームがこれらの質問に答えられたら「効率」の話をしてよい
■ 13. プロダクトのフェーズと関心度合い
- プロブレムソリューションフィット:
- 課題の存在と、ソリューションが課題を解決することを重視する
- 作業はプロトタイプとインタビューが中心
- 狭義の開発生産性は関心外
- プロダクトマーケットフィット:
- 検証可能なプロダクトを作り、市場に投入し、効果を計測する
- 顧客の火がついた問題を解決するバーニングニーズの特定に注力する
- リテンションとチャーンレートを重視する
- ここで狭義の開発生産性を気にしすぎるとビルドトラップに陥る
- 成長フェーズ:
- プロダクトが成功し始め、やりたいことは多いが人や時間が足りない
- 投資が大きくなり妥当性が気になり、ステークホルダーからの要求も増える
- 物的生産性が重視され、狭義・広義の開発生産性が話題になりやすい
- いきなり開発生産性の話にせず、本当に解決したい問題を明らかにするところから始める
- 衰退フェーズ:
- 新たに開発しても焼け石に水であり、狭義・広義の開発生産性は関心外
- フェーズに応じた取り組み:
- 自分たちのプロダクトの状況を踏まえて開発生産性に取り組むべき
■ 14. 結論と提言
- 多様な理由と定義:
- 開発生産性に関心を持つ理由も定義もさまざまであり、重要なのはコンテキスト
- 数字の限界:
- 数字だけですべてを表せるわけではない
- 個人単位や部門単位で定量化しても恣意的で、余計な分断を生むだけ
- その努力はもっと本質的なところに向けるべき
- 目的そのものを考える:
- 開発生産性に取り組む目的そのものを考えるべき
- 顧客に価値を届けなければビジネスは存続しないため、全員がそこを気にすべき
- 全員がビジネス上の成果を出すことにフォーカスする
- 効果が出てから効率を考える