> ## Documentation Index
> Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.
# 開発生産性とは — 定義・3つのレベル・計測方法
> 開発生産性の定義、生産性の3段階とレベルごとの計測・取り組み、向上が必要とされる背景と得られるもの、推進するうえでの注意点を解説します。
## 概要
開発生産性とは、開発に投入した生産要素（インプット）に対して、得られた成果物（アウトプット）の比率です。ただし「開発生産性」という言葉が指す範囲は広く、聞いた人が思い浮かべるものは、開発チームの作業効率からプロダクト全体の価値提供までさまざまです。そのため、開発生産性の議論は言葉の定義を明確にすることから始まります。
まず、開発生産性とは何か、なぜ向上が必要かを整理します。そして、前提となるプロダクトのゴール、アウトプットとインプットの定義、生産性の3段階とレベルごとの計測・取り組み、向上によって得られるもの、最後に推進するうえでの注意点を扱います。
## 開発生産性について話す前に
### プロダクトのゴールを前提にする
事業会社で作られるプロダクトの多くは、プロダクトを作ること自体がゴールではなく、プロダクトを通じて得られる結果がゴールです。プロダクトを使ってもらうことで達成されるKPI、そこから得られる売上や利益が重要であり、事業を支えられないプロダクトは続けられません。開発生産性の向上は、このゴールへの貢献を前提として考えます。
### 取り組むべき箇所を見極める
プロダクトは、課題発見・企画・デザイン・エンジニアリング・QAといった一連の流れから作られます。開発生産性はエンジニアリングだけでなく、プロダクト全体の生産性を指すこともあります。どこかの工程の生産性が低かったり工程間の連携が不十分だったりすると、エンジニアリングの生産性が高くてもプロダクト全体の生産性は低くなります。
一方で、小さく始める場合にコントロールしやすいのは、エンジニアリングに特化した部分です。組織を横断する取り組みは情報共有や課題感のすり合わせに時間がかかるため、まず自分や自分のチームに限定して生産性を上げることから始め、そこから範囲を広げていきます。
## 開発生産性の定義
生産性は`得られた成果物（アウトプット）÷投入した生産要素（インプット）`で表されます。このアウトプットとインプットには、次のようにさまざまな種類があります。
| 種別 | 主な項目 |
| ------ | ---------------------------------------------------------------------------------------------------------- |
| アウトプット | リリースされた機能や修正の数
開発されたコードの行数
解決されたバグやイシューの数
提供された価値（ユーザー満足度や売上への貢献）
開発されたドキュメントの量と質 |
| インプット | 開発に費やされた時間
開発に投入された人的リソース（エンジニア数）
開発に使用された予算
開発に必要なインフラやツールのコスト
開発チームの教育や育成に投資された時間と予算 |
何をアウトプットにし、何をインプットにするかは、組織や開発チームの特性、プロジェクトの性質によって異なります。重要なのは、自分たちの組織や開発チームにとって何がアウトプットであり、何がインプットであるか、そして何を開発生産性と呼ぶのかを明確にすることです。
開発生産性の定義とその測定方法を組織全体で共有し、継続的に改善に取り組むことが、プロダクトの成功につながります。逆に、定義を組織で共有しない場合はずれが生じ、取り組みを理解してもらえなくなります。
## 開発生産性の3段階
開発生産性は、何を「成果」と見なすかによって3つの段階（レベル1〜3）に分けて捉えられます。
| レベル | 測っている成果 | 評価の観点の例 |
| ---------------- | -------------------- | -------------------------------------------------------------- |
| レベル1: 仕事量の生産性 | 特定の作業量をどれだけ効率的にこなせたか | 効率的な開発環境を構築できているか
必要なスキルを習得できているか
サービス自体が良い構造を持っているか |
| レベル2: 期待付加価値の生産性 | 期待される価値をどの程度リリースできたか | プロダクトの目的達成に寄与する正しいタスクを選択できているか
タスクに優先順位を適切につけられているか |
| レベル3: 実現付加価値の生産性 | 実際のサービスへの具体的な貢献 | プロダクトにより売上がどれだけ変化したか
KPIをどれだけ達成できたか |
### レベル1: 仕事量の生産性
レベル1は、価値や売上への貢献は考慮せず、純粋に作業量の観点で生産性を評価します。エンジニアリングにダイレクトに関わり、エンジニアのみでコントロールできるため、取り組みやすく、目に見えて成果につながりやすいレベルです。
#### 計測
エンジニア個人やチームの日常の活動を定量的に把握することから始めます。たとえば次のようなメトリクスを定点観測し、時系列でグラフ化すると、仕事量とそのトレンドが明らかになります。
* 1日あたりのコミット数、プルリクエスト数
* プルリクエストの平均オープン時間
* コードレビューに要する時間
* バグ修正に要する平均時間
* 実装の手戻り率（レビュー指摘の修正など、実装内で完結する手戻り）
* 自動テストのカバレッジ
* ビルドの成功率と所要時間
#### 向上の取り組み
* メンテナンス性の向上（ドキュメントの充実、ユニットテストの強化、リファクタリングの定期実施）
* ビルドやデプロイなど繰り返しタスクの自動化
* コードレビューの効率化（リンターやCI/CDによる些細なエラーの事前検出）
* ペアプログラミングや技術共有の場によるチームワークの強化
### レベル2: 期待付加価値の生産性
レベル2は、仕事量だけでなく、各施策がプロダクトにどれだけの価値をもたらすかを考慮します。実際の価値への影響はリリース後一定の時間を経て現れるため、「期待される価値がどの程度リリースできたか」に焦点を当てます。多くの場合、スクラムやアジャイル開発のフレームワークを用いて、価値あるタスクをどれだけ実現できたかを測定します。
#### 計測
正しいタスクを選択し、期待した価値を滞りなくリリースにつなげられているかを把握します。たとえば次のような指標が使えます。
* 価値のあるフィーチャーの割合（開発した機能のうち、顧客や事業に実際に価値をもたらすものの割合）
* アイデアから価値提供までのリードタイム（着想から実際に顧客に価値が届くまでの時間）
* 仕様の手戻り率（要件の曖昧さ・変更、工程間の連携不足による手戻り）
* 要件定義の網羅率と、開発中の要件変更の頻度
#### 向上の取り組み
* 提供価値と優先度を明確にする戦略ロードマップの策定（加重スコアリングやRICEスコアによる優先度付け）
* 市場とユーザーインタビューによる価値の検証
* 対応しなかった場合の損失を見積もるリスクの管理
### レベル3: 実現付加価値の生産性
レベル3は、売上やKPIなど、実際のサービスに対する具体的な貢献を評価する段階です。最終的な目標はこのレベルの生産性を上げることですが、エンジニアリングという投資に対して因果関係が明確ではないことがあるため、評価が最も難しいレベルです。
#### 計測
プロダクトのKPIに沿って、開発した機能がビジネス成果にどうつながったかを把握します。たとえば次のような指標が使えます。
* プロダクトKPI（アクティブユーザー数、コンバージョン率など）
* プロダクトによる売上や顧客数の変化
* 営業利益率やインフラ費用の削減率（コスト面の貢献）
* ユーザー満足度
#### 向上の取り組み
レベル3の向上は、エンジニアリングだけでは完結せず、プロダクトの性質や組織の構成によって適切な取り組みが異なります。そのうえで、たとえば次のような取り組みがあります。
* プロダクトのKPIツリーを定義し、開発する機能や施策がどのKPIに貢献するかを企画段階で紐づける
* リリースした機能の利用状況や効果を測定する仕組みを整え、施策とビジネス成果のつながりを検証する
* 営業やカスタマーサクセスが得た顧客の声を開発に還元する、職種を超えたフィードバックループを作る
* エンジニアが企画や課題発見に参加し、機能の必要性やターゲットを開発側からも検証する
いずれの取り組みも、プロダクトマネージャー、デザイナー、QA、営業、カスタマーサクセスなど、プロダクトに関わるすべての人を巻き込む必要があります。職種を超えてお互いに深く入り込むことが求められるため、アジャイル開発の習熟によってレベル2まで到達したチームでも、レベル3の改善では苦労することが多くあります。
いずれのレベルでも、可視化した結果を「なんとなく」で定性的に理解することと、実際にどれくらいの数値で推移しているかを定量的に把握することの両方が大切です。定量的なデータと、日々の仕事で感じる定性的な気付きを組み合わせることで、生産性を多角的に捉えられます。
## なぜ開発生産性の向上が必要か
### 社会的な背景
日本では人口減少と高齢化によって労働人口が減少しており、限られた人数で成果を出すために、テクノロジーの力で効率良く仕事をすることが求められています。長時間労働を前提としない働き方改革の推進や、デジタル化によって業務プロセスを改善するDX（デジタルトランスフォーメーション）の広がりも、生産性向上を求める背景になっています。
### エンジニアリングにおける背景
エンジニアリングの現場でも、生産性向上が求められる変化が起きています。
見えないプロセスへの不安から、成果への貢献を重視するチームや会社が増え、個人個人が効率良く業務を進める必要が出てきました。
海外の先進的な製品との競争により、使いやすく高機能な製品をユーザーの求めに応じてより早く提供する必要が出てきました。
OSSや外部SaaSの活用が増え、多数の技術を取捨選択して組み合わせる力が求められるようになりました。
「推測するな、計測せよ」という言葉の通り、計測にもとづくファクトを組み合わせ、エンジニアリング自体の生産性も可視化しながら開発することが求められています。
### 向上によって得られるもの
開発生産性の向上は、組織の成長や成功に直結する要因になります。
| 得られるもの | 概要 |
| -------------- | ----------------------------------------------------------------------------- |
| 少ない投資でより多くの成果 | エンジニアの採用には時間がかかり、入社後のキャッチアップ期間も必要です。既存のリソースを最大限に活用して生産性を向上させることが、競争力を保つ鍵になります |
| 可視化による課題の明確化 | 生産性が具体的な数値として定量化されると、作業の流れと課題が明確になり、組織の弱点や機会を早期に見つけて的確に対応できます |
| 改善のサイクル | 生産性の高いチームは、日常業務の中に継続的な改善を行う文化を持ちます。この改善のサイクルが、さらなる生産性の向上を生みます |
| プロダクトのサイクルへの貢献 | 開発生産性が向上すればリリースサイクルも短縮され、市場の変化に素早く対応できるようになります |
| 採用への好影響 | 技術的負債が少なく改善が進む組織は、エンジニアにとって成長できる魅力的な環境であり、採用広報にも良い影響を与えます |
## 推進するうえでの注意点
### 過剰に追求しない
開発生産性を過剰に追求すると、オーバーワークや品質の低下といった問題が生じます。また、「指標を下げたくないのでレビューを適当に済ませた」「手元で開発が終わってからプルリクエストを作った」など、指標を守ること自体が目的になり、開発生産性向上の本質から逸れる行動も起こります。盲目的にならず、組織のコンディションを見ながら実施します。
指標は組織やチームの改善のためのものであり、個人の評価のためのものではありません。指標が評価の対象になると、数値の最適化そのものが優先され、指標が実態を反映しなくなります。この現象はグッドハートの法則として知られています。
### 作るべきものを間違えない
開発生産性をどれだけ高めて効率的に開発を進めても、作るべきものを間違えてしまえば提供価値は0になります。生産性向上以上に大切なのは、本当に価値のあるものを提供することです。提供価値を上げるために、次の点を考慮します。
機能の必要性、使用タイミング、ターゲットユーザーをエンジニアの視点からも検討し、依頼者やプロダクトマネージャーからの情報を鵜呑みにしません。
既存機能の組み合わせや外部サービス・ライブラリの活用で、提供価値を維持しつつ投入リソースを最小限に抑えます。
目的の異なる機能の混在や処理の分岐を減らし、メンテナンスや改修の手間を増大させません。
最も重要な部分から順次リリースして早期にフィードバックを得て、方向の修正や中止の判断を速やかに行います。
エンジニアは単なる実装者ではなく、ビジネス価値につながる開発を主体的に考える存在です。開発生産性の向上は、正しい方向性と組み合わせてこそ意味を持ちます。
## 関連ページ
本ページでレベル1の施策として挙げたビルドとデプロイの自動化を、具体的なパイプラインとして扱います。
レビューの時間が実際にどこで使われているか、ツールで確認できる部分をどう減らすかを扱います。
レベル1の指標であるテストカバレッジについて、その数字の裏側にあるテストをどう書くかを扱います。