目標の設定には、それがどのように実現されたかを追跡することが必然的につきまとう。これは、すべてのプロジェクト管理者の中心的な責任のひとつであり、ソフトウェア開発マネージャーも同様である。
プロジェクト管理者は、特定のKPIを使用して、次のことを行います。 ソフトウェア開発プロジェクトの管理 を効率的に行う。開発ベロシティ、サイクルタイム、リードタイムはすべて、開発プロジェクトを効率的に管理するための重要な要素です。 KPIの例である。 ソフトウェア・プロジェクトの追跡に使えるKPIの例。
ソフトウェア開発のためのこれらのKPIは、ボトルネックを特定し、継続的な改善に取り組むために、ソフトウェア開発ライフサイクルのすべてのステップを追跡するための客観的なデータのツールキットです。
ソフトウェア開発チームが、意思決定を促進するためのソフトウェア開発KPI(主要業績評価指標)トップ25の助けを借りて、開発プロセスをどのように最適化できるかを見てみましょう。
25のソフトウェア開発KPI
特定のビジネスオブジェクトや進行中のプロジェクトに合わせたKPIは無数に存在する。ここでは、開発者チームをターゲットより前に進めるための、ボードを横断するトップ25を紹介する。
1.開発速度
ClickUpで正確で視覚的に魅力的なベロシティレポートを作成することで、今後のスプリントの見積もりを改善します。
開発ベロシティでソフトウェア開発チームのパフォーマンスを測定します。これは、スプリント(タスクを完了する一定期間)中にチームが達成できる総仕事を示します。
スプリント内では、以下を使用します。 ストーリーポイント を使用して、タスクを完了するのに必要な努力を1から10までの尺度で計算する。各スプリントとストーリーポイントを測定することで、3スプリント内の開発チームの平均速度を理解することができる。
このメトリクスがなければ、プランニング、優先順位付け、リソースの割り当て、将来のプロジェクトに対する現実的な期待値の設定が難しくなる。
開発ベロシティ = 1スプリントで完了したストーリーポイントの合計_(英語
2.サイクルタイム
クリックアップでサイクルタイムを追跡する サイクルタイム 開発サイクル全体を通して。アジャイルのパフォーマンスを追跡するとき ソフトウェア開発ツール といったプロセスでは、デプロイメント頻度のKPIに依存することができます。
このKPIは、デプロイメントチームがコードをステージング、テスト、本番などの異なる部門にデプロイするスピードを決定します。この KPI は、DORA の 4 つのメトリクスの 1 つであり、変更失敗率、変更のリードタイム、平均回復時間などの他のメトリクスと相互にリンクしています。
このソフトウェア KPI は、開発チームの効率と俊敏性についての洞察を提供し、デプロイプラクティスを改善するためのベンチマークを設定し、継続的な改善を支援する。
デプロイメントの頻度 = デプロイメントの総数 / 期間。
5.ネットプロモータースコア
ネット・プロモーター・スコア(NPS)は、ゼロから10までのスケールでユーザー満足度を測定します。
ソフトウェアを0から6の間でランク付けする人は「デトラクター」、7と8は「パッシブ」、9または10の人は「プロモーター」と呼ばれる。プロモーターの数がデトラクターを上回れば、そのソフトウェアのパフォーマンスは高いということになります。
ネット・プロモーター・スコア = (%プロモーター) - (%デトラクター)_。
6.平均故障間隔(MTBF)
ソフトウェアの信頼性を測定しようとするとき、MTBFメトリクスは2つのソフトウェア故障間の平均時間を定量化します。
故障が避けられないソフトウェア開発では、MTBFメトリクスはソフトウェアタスクの評価と修復戦略の策定に不可欠である。
平均故障間隔(MTBF)=総稼働時間/総故障番号
7.故障率の変更
ソフトウェア品質の測定は、その主観性のために複雑である。変更失敗率メトリクスは、本番環境での失敗につながったデプロイメントのパーセンテージを計算することで、ソフトウェア品質を洞察します。
変更失敗率が低ければ、バグが少なく、品質が高いことを示す。逆に、変更失敗率が高い場合は、バグが多く、チームがコードを見直す必要があることを意味する。
CFR=(失敗した変更数/変更数)/100(失敗した変更数/変更数)/100(失敗した変更数/変更数)/100_(失敗した変更数/変更数)
/画像 https://clickup.com/blog/wp-content/uploads/2023/04/ClickUp-Pull-Request-Via-Git-Integration-1400x970.png Git 統合による ClickUp プルリクエスト /%img/
プルリクエストなどのためにClickUpをGitインテグレーションで接続するのは簡単です。
8.プルリクエスト (PR) サイズ
プルリクエストサイズはソフトウェア開発のメトリクスで、一つのプルリクエストのコード変更数を測定し、開発者が導入する変更のサイズや範囲を反映します。
小さなプルリクエストはレビューと処理が簡単で、より迅速な統合を促進し、より具体的なフィードバックを提供し、バグのリスクを低減します。対照的に、大規模なプルリクエストは理解、レビュー、修正に時間がかかります。
9.欠陥検出率 (DDR)
DDR比率は、リリース前に発見された欠陥の数とリリース後に発見された欠陥の数を比較する。
DDRメトリクスを使用して、テストチームが見逃し、カスタマが遭遇し、カスタマのエクスペリエンスに悪影響を与える欠陥の数を評価します。
不具合検出率 = (あるフェーズで見つかった不具合数 + 不具合総数) X 100_ (あるフェーズで見つかった不具合数 + 不具合総数
10.コードチャーン
コードは、ソフトウェアのアップグレードや新機能の導入に伴い、頻繁に改訂が必要になります。コード・チャーンのメトリクスは、特定の期間中にソフトウェア・コードが反復を必要とする回数を測定する。コード・チャーンが高いほど、メンテナンスとリスクが高いことを示す。
例えば、DevOpチームは通常平均25%のコード解約率で機能しており、これはコードが75%効率的であることを示している。
コード解約率 = 当初のコード総行数 - (追加された行数 + 削除された行数 + 修正された行数)/ コード総行数 X 100_。
11.コードの単純性
成功裏に実行される単純なコードは、絶え間ない反復を要求する複雑なコードより優れている。コードの単純さは、循環的複雑度、コードの重複、コード・チャーンなど、いくつかのメトリクスを使って測定できる。
コードが単純であるということは、コードの消費時間が短く、繰り返しが少なく、バグが少ないということである。
コードの単純性は定量的なメトリクスではなく定性的なメトリクスであるため、サイクロマティック複雑度のような直接的な測定式はない。
12.累積フロー
累積フローやバーンアウトチャートなどのレポート作成で、スプリントの進捗を把握しましょう。
ソフトウェア開発プロジェクト管理者は、ソフトウェア開発プロジェクトのフェーズを知りたいことがよくあります。累積フローは、タスクが承認されたのか、進行中なのか、バックログステージにあるのかを視覚的なダイアグラムで示します。
色によってステータスが異なります。さらに、帯の幅はサイクルタイムを示します。このソフトウェア開発 KPI により、ソフトウェア開発ステータスを測定し、ボトルネックを特定し、バックログ項目を完了するために必要な努力を計算することができます。
こちらもお読みください。 *ソフトウェア開発者の一日とは?*
13.バグ評価
バグ率は、ソフトウェアテスト中に特定されたバグの数を示す。ほとんどのソフトウェア開発チームは、この評価メトリクスを使用して、プロジェクト間、チーム間、期間間のバグ率を比較し、ベンチマークを設定し、バグを減らすための現実的な目標を設定します。
バグ率は、検出されたバグの総数と、特定されたバグの深刻度の 2 つの角度から見ることができます。
バグ率 = (検出されたバグの数/コードの総行数) X 100 バグ率 = (検出されたバグの数/コードの総行数) X 100 バグ率 = (検出されたバグの数/コードの総行数) X 100_ バグ率 = (検出されたバグの数/コードの総行数) X 100
14.スプリント・バーンダウン
バーンアップとバーンダウンチャートでClickUpのスプリントレポートを可視化する
スプリントのバーンダウン指標で、スプリント内で実行されたタスクの総数を測定します。これは、スプリント中に完了した仕事を決定する、ソフトウェアエンジニアリングKPIの鍵のひとつです。結果が期待にそぐわない場合は、チームのパフォーマンスを再調整します。
企業はしばしばスプリントバーンダウンチャートを使用し、理想的な進捗からの逸脱をチェックするために、ストーリーポイントで完了するまでの時間と作業量を測定する。
15.リリースバーンダウン
リリースバーンダウン KPIメトリクス は、製品リリースの進捗を測定し、以前のスプリントを基にバージョンを完了するまでに何スプリントかかるかを予測します。
リリースのバーンダウンチャートを使用して、業務が予定通りに進んでいるか遅れているかを測定し、プロジェクトの進捗を利害関係者に示す。
16.フロー効率
フロー効率の主要業績評価指標メトリクスは、合計時間とアクティブ時間の比率を追跡して、停止期間を把握し、ワークフローを最適化します。
フロー効率 = (価値付加時間 / リードタイム) X 100 フロー効率 = (価値付加時間 / リードタイム) X 100 フロー効率 = (価値付加時間 / リードタイム) X 100 _フロー効率 = (価値付加時間 / リードタイム) X 100
付加価値時間 = ソースコード/テストなど、顧客のニーズに直接貢献する活動に費やされた時間。
総リードタイム=仕事アイテムがカンバンシステムに入ってから顧客に納品されるまでのタイム。
17.平均修理時間(MTTR)
平均修理時間とは、システムが問題や故障を修理するのにかかる総時間を指す。これには、ソフトウェアが完全に機能するまでにかかるすべての時間を組み込むための、修理とテストの時間が含まれる。
ソフトウェア開発プロジェクトにおいてMTTRが高いと、計画外のダウンタイムが発生する可能性がある。
MTTRは、システムや機器の信頼性と可用性を評価し、改善すべき領域や障害の傾向を特定することで、ソフトウェア開発者がメンテナンス戦略を最適化できるようにします。
MTTR = 総メンテナンス時間 / 修理番号
18.キュー時間
キュータイムは、チケットが発行されてから解決されるまでの処理時間です。チケットがまだキューにあり、未対応または未解決の期間を指します。
キュータイムが長い原因は、QAスペシャリストの不足、社内コミュニケーションの不足、ツールやサポートの不足などが考えられます。このKPIは、パイプラインがどの程度最適化されているかを示すものであり、したがって、低ければ低いほどよい。
19.スコープ完了率
チケット完了プロセスが速ければ速いほど、ソフトウェア開発チームの効率にプラスに反映される。スコープ完了率は、スプリント内で完了したチケットの総数を決定するメトリクスである。
スコープ完了率が低い場合は、プロセスが最適化されていない、ターゲットが非現実的、またはメンバー数が少なすぎることを示唆します。
20.スコープ追加
追加されたスコープは、スプリント開始後に追加されたストーリーポイントの総数をアカウントするため、すべてのソフトウェア開発マネージャにとって重要なメトリクスである。
スコープ追加率が高いということは、今後の課題を決定するプランニングが不足していることを示す。新しい仕事を行う可能性を減らすことで、スプリントプランニングを混乱させる。
スコープ追加率を下げるには、チームが割ける以上の時間を必要とする機能を排除する。また、長期的に機能を稼働させ続けるために必要な時間と努力を記したメンテナンス予測を立てることもできる。
21.リードタイム
ClickUpでリードタイム・グラフをカスタマイズし、重要なプロジェクト・メトリクスを追跡しましょう。
リードタイムは、リクエストから完了するまでのタスクの合計時間を測定します。ソフトウェア開発チームのサイクルタイムとは異なり、タスク完了までに必要な待ち時間、承認、レビューも考慮します。
リードタイムが短いほど、市場投入までの時間が短縮され、敏捷性が向上し、リソースを効率的に活用できる。これらの要素が相まって、顧客満足度の向上に貢献する。
リードタイム = デプロイメントのタイムスタンプ - コミットのタイムスタンプ
22.無駄な努力
無駄な努力メトリクスは、最終的なプロジェクトやビジネスオブジェクトに貢献しないタスクに費やされた時間とリソースを測定します。
例えば、チームがソフトウェア機能に取り組んだが、2週間後には無関係とみなされた場合、無駄な努力は、その2週間の仕事に対してすべての開発者に支払われた金額となる。
生産性を高め、市場投入までの時間を短縮する、 KPIを測定する 無駄な努力など、ソフトウェア開発のKPIを測定し、プロジェクトの成功のためにそれを削減する方法を見つける。
無駄な努力 = (無駄な努力の合計 / 総努力) X 100_ (無駄な努力の合計 / 総努力
23.中断
中断メトリクスは、ある期間内に中断されたタスクの総数を測定します。より明確なアイデアを得るために、タスク内の割り込みの合計数を測定することもできます。
中断はパフォーマンスに直接影響するため、現実的なタイムラインを維持するために測定する必要があります。中断の例としては、技術的な問題、システム障害、個人的な中断、リソースが利用できないことによる中断などがあります。
中断率 = (中断の合計数 / 総仕事時間) X 100_ (中断の合計数 / 総仕事時間
24.雇用とランプタイム
ソフトウェア開発ライフサイクルを実行するには、十分なリソースが必要である。熟練した開発者のチームを雇うには時間がかかることがあり、現実的なタスク達成見込みを設定する必要性が強調されます。
採用期間とは、候補者が応募してから採用されるまでの期間を指します。これとともに、候補者がその役割に採用されてから、その役割で完全に生産性を発揮するようになるまでの時間を指すランプタイムもアカウントに入れます。
ソフトウェア開発ライフサイクルを見積もる際には、これら両方の指標を考慮してください。
25.予測出荷日
利害関係者は、ソフトウェアが完了する出荷予定日を要求することが多く、この KPI は、部門横断的な仕事のプランニングを支援する。
出荷予定日は、作業の進捗に伴って変更される可能性があり、変更が発生した場合は変更できる。
もお読みください:の違いは何ですか? *OKRとKPIの違いとは?* ?
ソフトウェア開発KPIを導入する際の課題と克服するためのヒント
正しいKPIの選択
ソフトウェア開発のKPIを設定するとき、プロジェクトに最も関連性の高いものを見つけ出すのは難しいことです。いくつかの選択肢の中から最も重要なKPIを選ぶには、どうやることでしょうか?
戦略的イニシアチブをサポートする組織目標とKPIから始めることをお勧めします。例えば、ソフトウェア開発が大きな影響を与えることができる重要な分野には、製品品質の向上、顧客満足度の向上、市場投入期間の短縮などがあります。
これに対応するビジネス価値を高めるKPIには、コードカバレッジ、サイクルタイム、コード品質、製品品質向上のためのMTTR、顧客満足度のためのNPS、市場投入のための展開頻度などがある。
エンジニア、テスター、開発者、プロジェクト管理者、製品開発者から意見を集め、これを共同努力とし、導入成功の可能性を高める。
KPIの定期的な調整と追跡
KPIは固定的なものではなく、変化する要件やビジネス目標に合わせて定期的に調整する必要がある。KPIをスプレッドシートで追跡することもできるが、バージョン管理、自動化されたデータ変更の欠如、役割ベースのアクセスのために、この方法ではスケーラビリティに限界がある。
プロジェクトを成功完了するためには、ソフトウェア開発KPIを追跡・調整するソフトウェアやテンプレートが必要です。
チーム内の連携不足
開発チームがNPSスコアを測定し、優先順位をつけているにもかかわらず、カスタマーサポートチームにそれを伝え忘れているシナリオを想定してください。このような連携がなければ、サポートチームはカスタマーエクスペリエンスよりもスピードを優先し、ビジネスオブジェクトを損なう可能性があります。
関連するKPIメトリクスを測定すると同時に、関連するチームメンバーにそれを伝え、その重要性と企業目標との整合性を理解してもらう必要があります。
共通のダッシュボードやソフトウェアを使用せずに、全員がKPIについて足並みをそろえ、その達成に貢献する権限を与えられていることを確認するためには、やることがあるでしょうか?
データの質と正確さ
スプレッドシートベースのデータ追跡には、重複エントリー、手作業によるデータ入力エラー、意思決定を誤らせる古い情報など、いくつかの欠点がある。
多くの企業では、各部門が独自のデータと方法論で孤立した仕事をしているため、*データサイロが形成されている。
例えば、組織内のサイバーセキュリティチームは、異なるデータソースで仕事をするかもしれない。一方、開発チームは、サイバー攻撃を受けやすいソフトウェアの脆弱性を減らすという共通の目標を持ちながら、別々の方法論を持っている可能性がある。
その結果、単一の真実のソースを持たない断片的な状況になってしまう。組織は、特に部門を超えたチームが共有目標に向かって協力する場合、健全な意思決定のためのデータ衛生と適時性の重要性を過小評価することはできません。すべてのチームが同じ一元化されたデータにアクセスできる単一の真実のソースを持つことは不可欠です。
ソフトウェア開発KPIの追跡と実施方法
重要なソフトウェア開発KPIがわかったら、次の問題はどのように追跡し、実施するかである。
ソフトウェアKPIの追跡は、明確で実用的な方法で明確なデータポイントを提供する効果的なツールなしでは、時間がかかり、間違いが生じます。
ClickUpは、ソフトウェアプロジェクトに関連するすべての重要業績評価指標を追跡し、それらがビジネスや戦略的オブジェクトと整合していることを確認するための包括的なプラットフォームです。
カスタマイズ可能 ClickUpダッシュボード リアルタイムのデータで最も関連性の高いKPIを追跡し、効果的でタイムリーな意思決定を行います。ダッシュボードは、ベロシティカード、バーンダウンカード、バーンアップカード、累積フロー、サイクルタイム、リードタイムなどのスプリントレポートカードでカスタマイズできます。
ClickUpダッシュボードで、あらゆるプロジェクトの完璧なミッションコントロールセンターを構築しましょう。
これらのカードはすべて定期的に更新され(ベロシティを除く)、KPIの追跡を簡素化し、開発努力を測定します。これらのカードには、ソース、期間、サンプル期間、仕事量、タスクフィルターなど、様々なカスタムオプションがあります。
クリックアップダッシュボードは、異なるソースからの貴重なデータを統合し、ソフトウェア開発の全体像を提供します。 プロジェクト・メトリクス とパフォーマンス。このデータは、ソフトウェア開発プロセスに関するデータ駆動型の意思決定、リソース割り当ての最適化、および開発プロセス全体の最適化に使用できます。
ClickUp KPI テンプレート
サクセスマネージャーとして、ソフトウェア開発チームにとって何が仕事で何がそうでないかを測定する必要があります。
ClickUp ソフトウェア開発テンプレート は、高品質のソフトウェア開発のために設計されています。これらは、すぐに使用でき、完全にカスタマイズ可能なサブカテゴリとヘルプ追跡が付属しています。 プロジェクト管理KPI をカスタムビュー、カスタムステータス、カスタムフィールドで作成することができます。
ClickUp KPIテンプレート を使えば、新興企業でも既存ビジネスでも、KPI測定を簡単に行うことができます。このテンプレートを使用すると、次のことが可能になります:
- 最も重要なデータポイントの最新情報を、ソフトウェア開発者全員が一箇所で確認できます。
- 目標に対する進捗を追跡することで、開発チームの努力を可視化します。
- トレンドを特定し、KPI の進捗を視覚的な図で追跡・測定します。
以下はその方法です。 ソフトウェア開発チームのためのClickUp は、KPIの測定を簡素化します:
- 目標を作成する:目標の作成:長期および短期のオブジェクトに沿った、測定可能で達成可能な目標を作成します。
- クリックUpダッシュボード:ダッシュボード:ニーズに最も適したメトリクスを特定し、ダッシュボードを使用してそれらを追跡します。
- マイルストーンを作成する:マイルストーンの作成:メトリクスを自分で追跡するか、自動化された分析ツールを使用してリアルタイムのパフォーマンスを追跡する。
- 結果を分析する:クリックアップのガントチャートビューまたはボードビューを使用して結果を分析し、必要に応じてターゲットを修正します。
Related: 商品管理KPIについて 🎯
品質保証がソフトウェア開発のKPIに与える影響
品質保証は、セキュリティ上の欠陥の特定からバグを特定するためのソフトウェアのテストに至るまで、ソフトウェア開発のメトリクスを測定する上で中心的な役割を果たさなければならない。
構造化された信頼できるテストプロセスにより、開発チームは、顧客が製品/ソフトウェアを使用する前に、すべてのバグや問題を修正することができます。
さらに、最適な品質で納品することで、コードの手直し時間が短縮され、バグ率や不具合発見率が低下します。これが、迅速かつ円滑なソフトウェア開発プロセスのために品質保証の最適化を推奨する理由です。
ソフトウェア開発のKPIを測定し、プロジェクト達成の可能性を最大化しよう。
ソフトウェア開発は反復プロセスであり、プロジェクトの成功を確実にするためには、頻繁なモニタリングと調整が必要です。ソフトウェア開発のKPIを設定することで、全員が責任を負い、ソフトウェア開発の努力がビジネスオブジェクトに集中するようになります。
KPIは、ソフトウェア開発チームの北極星の役割を果たし、日々の進捗を測定し、リーダーシップとマネージャーが全体像をよりよく理解するのに役立ちます。
ClickUpのプロジェクト管理ソフトウェアをソフトウェア提供プロセスに統合することで、進捗を測定し、KPIを追跡し、必要に応じて調整し、開発プロセスを最適化することができます。 ClickUpに無料登録する に登録し、ソフトウェア開発のKPIを設定・追跡しましょう。