目標を設定したら、その達成状況を追跡することは必然です。これはすべてのプロジェクトマネージャーの主要な責務の一つであり、ソフトウェア開発マネージャーも例外ではありません。
プロジェクトマネージャーは、ソフトウェア開発プロジェクトを効率的に管理するために、特定のKPIを活用しています。開発速度、サイクルタイム、リードタイムなどは、ソフトウェアプロジェクトの進捗を追跡するために活用できるKPIの一例です。
これらのソフトウェア開発用KPIは、ソフトウェア開発ライフサイクルのあらゆるステップを追跡し、ボトルネックを特定して継続的な改善に取り組むための、客観的なデータツールキットとなります。
ソフトウェア開発チームが、意思決定を後押しするトップ25のソフトウェア開発KPI（主要業績評価指標）を活用して、開発プロセスを最適化する方法を見ていきましょう。
ソフトウェア開発のための25のKPIメトリクス
特定のビジネス目標や進行中のプロジェクトに合わせて設計されたKPIは数え切れないほど存在します。ここでは、開発チームがターゲットを確実に達成できるよう、あらゆる分野に共通して適用できるトップ25のKPIをご紹介します。
視覚的な情報の方が理解しやすいという方へ。最も重要なKPIをまとめたビデオもご用意しています：
以下で、それらについて詳しく見ていきましょう。
1. 開発ベロシティ
開発ベロシティを用いて、ソフトウェア開発チームのパフォーマンスを測定しましょう。これは、スプリント（タスクを完了させるための固定期間）中にチームが達成できる総作業量を示します。
スプリント内では、ストーリーポイントを用いて、タスクを完了するために必要な工数を1から10のスケールで算出します。1が最も短時間で完了できるタスク、10が最も複雑なタスクとなります。各スプリントとストーリーポイントを測定することで、3スプリントにおける開発チームの平均ベロシティを把握することができます。
このメトリクスがなければ、将来のプロジェクトのプラン立案、優先順位付け、リソース配分、そして現実的な目標設定を行うことは困難でしょう。
開発ベロシティ = スプリント中に完了したストーリーポイントの合計
2. サイクルタイム
サイクルタイムは、特定のタスクを完了するのに要した時間を測定するDevOps Research and Assessment（DORA）のメトリクスです。これにより、チームのパフォーマンスを数値化し、将来のタスクを完了するために必要な時間を推定することができます。
例えば、ソフトウェア開発において「サイクルタイム」とは、バグが開発者に割り当てられ、コードの安定性確認やテストを経て、修正され品質保証部門によって承認されるまでの所要時間を指します。
このメトリクスは、開発チームの生産性を評価し、改善すべき点を特定するのに役立ちます。各タスクのサイクルタイムを目標期間と比較することで、チームの課題を分析することができます。
サイクルタイム = 終了時刻 – 開始時刻
3. コードカバレッジ
コードカバレッジ（テストカバレッジとも呼ばれる）は、テスト対象となったコードの割合を測定する指標です。このDevOpsメトリクスは、本番環境およびテスト環境におけるソフトウェアの品質を測定します。
テスト駆動開発（TDD）を重視し、コード内のバグを特定します。コードカバレッジが高ければ高いほど、バグが発生する可能性は低くなります。
コードカバレッジ = (テストによって実行されたコード行数 / コードの総行数) × 100
4. デプロイ頻度
アジャイル手法を導入すると、開発サイクル全体を通じてチーム全体がアジャイルメトリクスを追跡する必要があるため、企業のパフォーマンス測定が難しくなることがあります。このようなプロセス下でソフトウェア開発ツールやプロセスのパフォーマンスを追跡する際は、「デプロイ頻度」というKPIを活用すると良いでしょう。
これは、デプロイチームがステージング環境、テスト環境、本番環境などの各部門へコードをデプロイする速度を測定する指標です。このKPIはDORAの4つのメトリクスの一つであり、変更失敗率、変更リードタイム、平均復旧時間などの他のメトリクスと相互に関連しています。
このソフトウェアKPIは、開発チームの効率性と俊敏性を可視化し、デプロイメント手法の改善に向けたベンチマークを設定し、継続的な改善を支援します。
デプロイ頻度 = デプロイ総数 ÷ 期間
5. ネットプロモータースコア（NPS）
ネットプロモータースコア（NPS）は、0から10のスケールで顧客満足度を測定する指標です。0は最悪のユーザー体験を、10は最高のユーザー体験を表します。
ソフトウェアを0～6点と評価する人は「批判者」、7～8点と評価する人は「中立層」、9～10点と評価する人は「推奨者」と呼ばれます。推奨者の数が批判者の数を上回っている場合、そのソフトウェアは良好なパフォーマンスを発揮していると言えます。
ネットプロモータースコア（NPS）＝（推奨者の割合）－（批判者の割合）
6. 平均故障間隔（MTBF）
ソフトウェアの信頼性を評価する際、MTBF（平均故障間隔）というメトリクスは、2回のソフトウェア障害が発生するまでの平均時間を数値化します。
失敗が避けられないソフトウェア開発において、MTBF（平均故障間隔）というメトリクスは、ソフトウェアタスクの評価や修復戦略の策定に不可欠です。
平均故障間隔（MTBF）＝ 総稼働時間 ÷ 総故障回数
7. 変更失敗率
ソフトウェアの品質測定は、その主観的な性質ゆえに複雑です。「変更失敗率」というメトリクスは、本番環境でのデプロイのうち、失敗に終わったものの割合を算出することで、ソフトウェアの品質に関する洞察を提供します。
変更時の失敗率が低いということは、バグが少なく品質が高いことを示しています。逆に、失敗率が高い場合はバグが多く、チームがコードを見直す必要があることを意味します。
CFR = (失敗した変更数 / 変更総数) / 100
8. プルリクエスト（PR）のサイズ
プルリクエストのサイズは、1つのプルリクエストに含まれるコード変更の数を測定するソフトウェア開発のメトリクスであり、開発者が導入する変更の規模や範囲を反映しています。
小規模なプルリクエストはレビューや処理が容易であり、統合の迅速化、より具体的なフィードバックの提供、バグ発生リスクの低減につながります。対照的に、大規模なプルリクエストは、内容を把握し、レビューし、修正するのに時間がかかります。
9. 欠陥検出率（DDR）
DDR比率は、リリース前に発見された不具合の数と、リリース後に発見された不具合の数を比較して測定する指標です。
DDRメトリクスを活用して、テストチームが見逃し、顧客が遭遇した欠陥の数を評価しましょう。これらは顧客体験に悪影響を及ぼします。
欠陥検出率 = (当該フェーズで発見された欠陥数 + 欠陥総数) × 100
10. コードの変更率
ソフトウェアのアップグレードや新機能の導入に伴い、コードの修正が必要になることはよくあります。「コードチャーン」というメトリクスは、特定の期間内にソフトウェアのコードが何回修正（反復）されたかを測定するものです。コードチャーンが高いほど、メンテナンスの負担やリスクが高くなります。
例えば、DevOpsチームのコードの入れ替え率は平均25％であり、これはコードの75％が効率的であることを示しています。
コード変更率 = 開始時の総行数 – (追加された行数 + 削除された行数 + 変更された行数) / 総行数 × 100
11. コードの簡潔さ
単純なコードが成功して実行されることは、絶え間ない修正を必要とする複雑なコードよりも優れています。コードの単純さは、サイクロマティック複雑度、コードの重複、コードの変更率などのメトリクスを用いて測定することができます。
コードの簡潔性は、開発時間の短縮、反復回数の減少、そしてバグの減少につながることを示しています。
サイクロマティック複雑度のように、コードの簡潔さを測定する直接的な式は存在しません。これは定量的ではなく、定性的なメトリクスだからです。
12. 累積フロー
ソフトウェア開発マネージャーは、プロジェクトの進捗状況を把握したいと考えることがよくあります。累積フローは、視覚的な図表を用いて、タスクが承認済みか、進行中か、あるいはバックログフェーズにあるかを示します。
色によってステータスが異なります。また、帯の幅はサイクルタイムを示しています。このソフトウェア開発KPIを活用することで、開発の進捗状況を把握し、ボトルネックを特定し、バックログアイテムの完了に必要な工数を算出することができます。
関連記事：ソフトウェア開発者の1日の流れ
13. バグ発生率
バグ発生率は、ソフトウェアのテスト中に発見されたバグの数を示します。多くのソフトウェア開発チームは、このメトリクスを用いてプロジェクト間、チーム間、および期間ごとのバグ発生率を比較し、ベンチマークを確立し、バグを削減するための現実的な目標を設定しています。
これらを2つの観点から検討することができます。1つは検出されたバグの総数、もう1つは特定されたバグの深刻度です。
バグ率 = (検出されたバグの数 / 総コード行数) × 100
14. スプリント・バーンダウン
スプリントバーンダウン指標を用いて、スプリント内で実行されたタスクの総数を測定しましょう。これは、スプリント中に完了した仕事量を把握する上で重要なソフトウェアエンジニアリングKPIの一つです。結果が期待通りにいかない場合は、チームのパフォーマンスを見直してください。
企業では、スプリント・バーンダウン・チャートを活用し、ストーリーポイントで表された完了までの時間や作業量を測定することで、理想的な進捗からの乖離を確認することがよくあります。
15. リリース・バーンダウン
リリース・バーンダウンKPIは、製品リリースの進捗状況を測定し、過去のスプリント実績に基づいて、バージョン完了までに要するスプリント数を予測する指標です。
リリース・バーンダウン・チャートを活用して、作業が予定通り進んでいるか、あるいは遅れているかを把握し、ステークホルダーにプロジェクトの進捗状況を明確に示しましょう。
16. フロー効率
「フロー効率」というKPIメトリクスは、総稼働時間とアクティブ時間の比率を追跡することで、作業が停滞している期間を把握し、ワークフローを最適化します。
フロー効率 = (価値時間 / リードタイム) × 100
付加価値時間 = コードの作成やテストなど、顧客のニーズに直接貢献する活動に費やされた時間。
総リードタイム = 仕事アイテムがカンバンシステムに入力されてから、顧客に納品されるまでの時間。
17. 平均修復時間（MTTR）
平均修復時間（MTTR）とは、システムの問題や障害を修復するのにかかる合計時間を指します。これには、修復およびテストの時間に加え、ソフトウェアが完全に機能するようになるまでの全工程にかかる時間が含まれます。
ソフトウェア開発プロジェクトにおいてMTTR（平均修復時間）が長くなると、予期せぬダウンタイムにつながる可能性があります。
MTTRは、システムや機器の信頼性と可用性を評価し、改善すべき点や障害の傾向を特定することで、ソフトウェア開発者が保守戦略を最適化できるようにします。
MTTR = 総メンテナンス時間 ÷ 修理件数
18. 待ち時間
キュー時間は、チケットが発行されてから解決されるまでの処理時間を指します。これは、チケットがまだキューに残っており、問題や解決が行われていない期間を指します。
待ち時間が長くなる原因は、QA担当者の不足、社内のコミュニケーション不足、あるいはツールやサポートの不備などです。このKPIはパイプラインの最適化度合いを示すものであり、数値が低いほど良好であることを意味します。
19. スコープ完了率
チケットの完了プロセスが速ければ速いほど、ソフトウェア開発チームの効率性が高いことを示すメトリクスとなります。スコープ完了率は、スプリント内で完了したチケットの総数を測定するメトリクスです。
スコープ達成率が低い場合は、プロセスの最適化が不十分である、ターゲットが非現実的である、あるいは人員が不足していることを示唆しています。
20. スコープの追加
「追加されたスコープ」は、スプリント開始後に追加されたストーリーポイントの総数を表すため、すべてのソフトウェア開発マネージャーにとって極めて重要なメトリクスです。
スコープ追加の割合が高いということは、今後の課題を見極めるためのプランが不十分であることを示しています。これにより、新しい仕事をこなす可能性が低くなり、sprint計画に支障をきたします。
追加されるスコープを縮小するには、チームが割ける時間よりも多くの時間を要する機能を削除しましょう。また、その機能を長期的に稼働させ続けるために必要な時間と努力を明記した保守予測を作成することも有効です。
21. リードタイム
リードタイムとは、タスクの依頼から完了までの総所要時間を測定する指標です。ソフトウェア開発チームのサイクルタイムとは異なり、タスクが完了するまでに必要な待機時間、承認、およびレビューの時間も考慮に入れます。
リードタイムが短縮されることは、市場投入までの期間の短縮、俊敏性の向上、そしてリソースの効率的な活用を意味します。これらの要素が相まって、顧客満足度の向上につながります。
リードタイム = デプロイ時刻 – コミット時刻
22. 無駄な努力
「無駄な努力」というメトリクスは、最終的なプロジェクトやビジネス目標に貢献しないタスクに費やされた時間とリソースを測定するものです。
例えば、チームが2週間かけて開発したソフトウェア機能が、その後無関係であると判断された場合、その無駄になった努力は、その2週間の仕事に対して全開発者に支払われた金額に相当します。
生産性を高め、市場投入までの時間を短縮するためには、無駄な努力などのソフトウェア開発KPIを測定し、プロジェクトを成功させるためにそれを削減する方法を見つけましょう。
無駄な努力 = (無駄な努力の合計 / 総努力) × 100
23. 作業の妨げ
「中断メトリクス」は、特定の期間内に中断されたタスクの総数を測定するものです。また、タスク内の中断の総数を測定することで、状況をより明確に把握することもできます。
中断はパフォーマンスに直接影響を与えるため、現実的なタイムラインを維持するためには、その測定が不可欠です。中断の例としては、技術的な問題、システム障害、個人的な中断、あるいはリソースの不足による中断などが挙げられます。
中断率 = (中断の総回数 / 総労働時間) × 100
24. 採用と戦力化までの期間
ソフトウェア開発ライフサイクルを遂行するには、十分なリソースが必要です。熟練した開発者チームを編成するには時間がかかる場合もあり、そのため、タスクの達成目標を現実的な水準に設定することが重要となります。
採用期間とは、候補者が求人に応募してから内定を受け入れるまでの期間を指します。これに加え、オンボーディング期間も考慮する必要があります。オンボーディング期間とは、候補者が採用されてから、その役割において完全に生産性を発揮できるようになるまでの期間を指します。
ソフトウェア開発ライフサイクルを見積もる際には、これら2つの指標を併せて考慮してください。
25. 予定リリース日
ステークホルダーからは、ソフトウェアの完了見込み納期を求められることがよくありますが、このKPIは部門横断的なチームが仕事のプランを立てる上で役立ちます。
プロジェクトの進捗に伴い納期は変更される可能性があり、状況の変化に応じて調整される場合があります。
関連記事：OKRとKPIの違いとは？
ソフトウェア開発KPIの導入における課題と、それを克服するためのヒント
適切なKPIの選定
ソフトウェア開発のKPIを設定する際、プロジェクトに最も適した指標を見極めるのは難しい場合があります。数ある選択肢の中から、最も重要なKPIをどのように選べばよいのでしょうか？
まずは、戦略的イニシアチブを支える組織目標とKPIから検討することをお勧めします。例えば、ソフトウェア開発が大きな影響を与える主な分野としては、製品品質の向上、顧客満足度の向上、市場投入までの期間の短縮などが挙げられます。
ビジネス価値を高めるKPIとしては、コードカバレッジ、サイクルタイム、コード品質、製品品質向上のためのMTTR、顧客満足度を測るNPS、市場投入のためのデプロイ頻度などが挙げられます。
エンジニア、テスター、開発者、プロジェクト管理者、プロダクト開発者から意見を収集し、全員で協力して取り組むことで、導入を成功させる可能性を高めましょう。
KPIの定期的な見直しと追跡
KPIは固定されたものではなく、変化する要件やビジネス目標に合わせて定期的に調整する必要があります。スプレッドシートで追跡することも可能ですが、バージョン管理、データの自動更新機能の欠如、および役割ベースのアクセス制御といった理由から、その拡張性にはリミットがあります。
プロジェクトを成功裏に完了させるためには、ソフトウェア開発のKPIを追跡・調整するためのソフトウェアやテンプレートが必要です。
チーム内の連携不足
開発チームがNPSスコアを測定し、優先順位を付けているものの、カスタマーサポートチームへの共有を忘れてしまったというシナリオを想定してみてください。こうした連携が欠如していると、サポートチームは顧客体験よりもスピードを優先してしまい、ビジネス目標の達成を妨げる恐れがあります。
関連するKPIメトリクスを測定するだけでなく、その重要性と会社の目標との整合性をチームメンバーが理解できるよう、適切なメンバーと共有する必要があります。
共通のダッシュボードやソフトウェアを使わずに、どうすれば全員がKPIについて認識を一致させ、その達成に向けて主体的に貢献できるようになるでしょうか？
データの品質と正確性
スプレッドシートを使ったデータ追跡には、エントリーの重複、手入力によるエラー、情報の古さなど、いくつかの欠点があり、これらが意思決定を誤らせる原因となります。
多くの企業では、各部門が独自のデータや手法を用いて孤立して仕事を行うため、データのサイロ化が生じてしまいます。
例えば、組織内のサイバーセキュリティチームは、異なるデータソースを扱っている場合があります。一方、開発チームは独自の方法論を採用しているかもしれませんが、これらのチームには「サイバー攻撃を受けやすいソフトウェアの脆弱性を低減する」という共通の目標があります。
その結果、唯一の「真実の源」が存在しない、断片化された状況が生じてしまいます。組織は、特に部門横断的なチームが共通の目標に向かって協働する場合、適切な意思決定を行うためのデータ管理の徹底と適時性の重要性を過小評価してはなりません。すべてのチームが同じ一元化されたデータにアクセスできる、唯一の「真実の源」を持つことが不可欠です。
ClickUpのダッシュボードでソフトウェア開発KPIを追跡・導入する
主要なソフトウェア開発KPIを把握したら、次はそれらをどのように追跡し、導入するかという点が課題となります。
明確かつ実用的な形で具体的なデータポイントを提供する効果的なツールがなければ、ソフトウェアKPIの追跡は時間がかかり、誤りが生じやすくなります。
ClickUpは、ソフトウェアプロジェクトに関連するすべての主要業績評価指標（KPI）を追跡し、それらがビジネス目標や戦略的目標と整合していることを確認するための包括的なプラットフォームです。
ClickUpのダッシュボードをカスタムすれば、リアルタイムのデータを用いて最も関連性の高いKPIを追跡し、効果的かつタイムリーな意思決定を行うことができます。ダッシュボードには、ベロシティカード、バーンダウンカード、バーンアップカード、累積フロー、サイクルタイム、リードタイムなどのスプリントレポートカードを追加してカスタム可能です。
これらのカードはすべて（ベロシティを除く）、KPIの追跡を簡素化し、開発の努力を測定するために定期的に更新されます。これらのカードには、ソース、期間、サンプリング期間、仕事量、タスクフィルターなど、さまざまなカスタマイズオプションが用意されています。
ClickUpのダッシュボードは、さまざまなデータソースからの貴重なデータを統合し、ソフトウェア開発プロジェクトのメトリクスやパフォーマンスを包括的に把握できるようにします。このデータを活用することで、ソフトウェア開発プロセスに関するデータに基づいた意思決定を行い、リソース配分や開発プロセス全体を最適化することができます。
ClickUp KPIテンプレート
成功の鍵はKPIを常に把握しておくことにあり、マネージャーとして、ソフトウェア開発チームにおいて何が機能し、何が機能していないかを測定する必要があります。
ClickUpのソフトウェア開発テンプレートは、高品質なソフトウェア開発を実現するために設計されています。すぐに使える、完全にカスタマイズ可能なサブカテゴリが備わっており、カスタムビュー、ステータス、フィールドを活用してプロジェクト管理のKPIを追跡するのに役立ちます。
ClickUp KPIテンプレートを使えば、スタートアップ企業でも老舗ビジネスでも、KPIの測定が簡単に行えます。このテンプレートを使えば、以下のことが可能です：
- 最も重要なデータポイントを常に把握しましょう。すべてのソフトウェア開発者が、一箇所で情報を確認できます。
- 目標に対する進捗状況を追跡することで、開発チームの努力を可視化しましょう
- 視覚的な図表を使って、傾向を把握し、主要業績評価指標（KPI）の進捗状況を追跡・測定しましょう
「ClickUp for Software Development Teams」がKPIの測定をいかに簡素化するかを紹介します：
- 目標の設定：長期的および短期的な目標に沿った、測定可能で達成可能な目標を策定しましょう
- ClickUpダッシュボード：ニーズに最適なメトリクスを特定し、ダッシュボードを使ってその進捗を追跡しましょう
- マイルストーンを設定する：メトリクスを自ら追跡するか、自動化された分析ツールを活用してリアルタイムのパフォーマンスを把握しましょう
- 結果の分析：ClickUpのガントチャートビューまたはボードビューを使用して結果を分析し、必要に応じてターゲットを修正しましょう
関連記事：プロダクトマネジメントのKPI 🎯
品質保証がソフトウェア開発のKPIに与える影響
セキュリティ上の欠陥の特定から、バグ発見のためのソフトウェアテストに至るまで、品質保証はソフトウェア開発のメトリクスを測定する上で中心的な役割を果たさなければなりません。
体系化され、信頼性の高いテストプロセスにより、開発チームは顧客が製品やソフトウェアを使用する前に、すべてのバグや問題を確実に修正することができます。
さらに、最適な品質で成果物を納品することで、コードの修正時間が短縮され、バグ発生率や欠陥検出率が低下します。そのため、迅速かつ円滑なソフトウェア開発プロセスを実現するために、品質保証の最適化をお勧めします。
ソフトウェア開発のKPIを測定し、プロジェクトの成功確率を最大化しましょう
ソフトウェア開発は反復的なプロセスであり、プロジェクトを成功させるためには頻繁なモニタリングと調整が必要です。ソフトウェア開発のKPIを設定することで、全関係者の責任を明確にし、開発努力がビジネス目標に確実に集中するようになります。
これらはソフトウェア開発チームにとっての「北極星」のような存在であり、日々の進捗を測定し、経営陣やマネージャーが全体像をより深く理解するのに役立ちます。
ClickUpのプロジェクト管理ソフトウェアをソフトウェアデリバリープロセスと連携させ、進捗を測定し、KPIを追跡し、必要に応じて調整し、開発プロセスを最適化しましょう。
ClickUpに無料で登録して、ソフトウェア開発のKPIを設定・追跡しましょう。