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