スクラム KPI: 主要なスクラム指標と例

スクラム KPI は管理を連想させます。そしてまさにそこから問題が始まります。多くのチームは「kpi in scrum」「scrum performance metrics」や「scrum kpi metrics」を検索し、チームをコントロールするための簡単な一覧を期待します。Velocity、Burndown、スループット、スプリントゴール達成率、もしかするとチーム満足度まで。

不都合な真実: Scrum KPI は、より良い会話と改善のための行動を引き起こす場合にのみ有用です。チームを比較したり、プレッシャーをかけたり、「生産性」を証明したりするためだけに使うなら、スクラムをたいていは悪くします。

この記事では、スクラム指標の例だけでなく、どの指標を本当に使うべきか、どの指標に注意すべきか、そしてレトロスペクティブやチームヘルスチェックで Scrum KPI をどう意味ある形で組み込むかについて、明確な見解も示します。

要約

良い Scrum KPI は人ではなく、チームの仕事の仕組みを測る。
重要な Scrum パフォーマンスメトリクスは、スプリント目標達成率、フロー、品質、チームヘルス、施策の実行、そして顧客価値である。
Velocity は会話のきっかけとしては問題ないが、パフォーマンス目標としては危険である。
KPI は、定期的にレトロスペクティブと改善施策に落とし込まれて初めて価値を持つ。

Scrum KPI とは何か？

Scrum KPI は、Scrum チームがより効果的になっているかを可視化する指標です。良い Scrum KPI は「誰が十分に働いているか？」ではなく、次の問いに答えます:

私たちは安定して価値を届けているか？
私たちはより速く学べているか？
ブロッカーはより早く見えるようになっているか？
品質は良くなっているのか、それとも悪くなっているのか？
チーム内の協働は改善しているか？
レトロスペクティブから出た施策を本当に実行できているか？

つまり Scrum KPI は、従来の報告用指標とは異なります。診断ツールなのです。チームがどこをより注意深く見るべきかを示します。

特に Scrum Master のパフォーマンス評価のための指標を探していますか？それならこちらへ:

記事へ: Scrum Master Performance

最も重要なルール: 会話のない KPI はない

Scrum は経験主義的なフレームワークです。Inspection と Adaptation は、完璧な計測よりも重要です。だからこそ、どの Scrum KPI も振り返りの問いと結び付けるべきです。

Scrum KPI	良い振り返りの問い
スプリント目標の達成	スプリント目標の達成に何が役立ち、何が妨げになったか？
サイクルタイム	仕事が長く滞留しているのはどこか？
Work in Progress	同時に始めすぎていなかったか？
Defect Rate	どのような品質問題が体系的に発生しているか？
チームヘルス	どの協働上の課題が私たちの足を引っ張っているか？
施策の実行	どの改善を本当に実行できているか？

ある KPI が良い問いを生み出さないなら、それはたいてい良い Scrum KPI ではありません。もし今、特定の指標をただ測定したいだけで、その指標をチームと透明に共有したり話し合ったりするつもりがないと気づいたなら、その Scrum 指標をそもそも測るべきかどうかを見直すべきです。

この記事からひとつだけ持ち帰るとしたら、これです: Scrum KPI はすべてのチームメンバーに透明であり、客観的な対話の土台として機能すべきです。秘密はありません。トップダウンのみの管理だという印象が生まれれば、最悪の場合、リーダーとしてのあなたの信頼性を失います。少なくとも、チームは（当然ながら）経験的でアジャイルな働き方に対するあなたの理解を疑うでしょう。

Scrum パフォーマンスメトリクス: 6つの重要なカテゴリ

1. スプリント目標達成率

スプリント目標達成率は、完了したチケット数そのものよりも役立つことがよくあります。チームは多くのチケットをクローズしても、肝心のスプリント目標から外れた仕事をしていることがあります。

したがって、Output だけでなく、目標の明確さも測りましょう:

明確なスプリント目標は設定されたか？
その目標は Product Owner と開発チームの双方にとって関連性があったか？
目標は達成されたか、一部達成だったか、未達だったか？
主な理由は何だったか？

この Scrum KPI は、計画、フォーカス、依存関係、そして協働を可視化するので、特に価値があります。

2. フローメトリクス: Cycle Time、Throughput、Work in Progress

フローメトリクスは、仕事がどのようにシステム内を流れるかを示します。見積もりの儀式への依存が少ないため、Velocity よりも堅牢であることが多いです。

Cycle Time: 仕事の一要素が開始してから完了するまでに、どれくらい時間がかかるか？
Throughput: 一定期間にいくつの作業項目が完了するか？
Work in Progress: 同時に進行中の仕事はどれくらいあるか？

私見: 技術的な Scrum パフォーマンスメトリクスを 1 つだけ導入するなら、Cycle Time から始めてください。ボトルネック、待ち時間、そして並行作業のしすぎを、しばしば容赦なく可視化してくれます。

3. 品質: Defects、Rework、escaped bugs

スクラムのKPIは速度だけを測ってはいけません。そうしないと、チームはすぐにアウトプット最適化に走り、後でより多くの手戻りを生みます。

意味のある品質指標の例は次のとおりです：

スプリントあたりの欠陥数
リリース後に漏れたバグ
未計画のバグ修正作業の割合
手戻りの割合
プルリクエストごとのレビュー回数

これらの数値は、責任追及に使うべきではありません。むしろ、システム的な原因を見つける助けになります。たとえば、要件の不明確さ、テスト自動化の不足、ストーリーの大きさが大きすぎること、時間的な圧迫、あるいは共通の品質基準が欠けていることです。

4. レトロスペクティブの有効性と施策の実行

多くのスクラムチームはレトロスペクティブを実施していますが、そこから本当の改善が生まれているかは測っていません。まさにここに、最も重要なスクラムKPIの一つがあります。

例：

前回のレトロで完了した施策の割合
再発するブロッカーの数
レトロスペクティブのROTIスコア
アクションアイテムの質
次のレトロで未完了施策を再取り上げすること

それも、ツールが有効になるポイントです。Echometer はこの KPI カテゴリーを直接カバーします。レトロスペクティブで生まれたアクションは記録され、後続のレトロで再び取り上げられ、チームヘルスのトレンドと結びつけることができます。これにより、レトロスペクティブが単に良い会話を生むだけなのか、それとも実際に実行された改善につながっているのかが見えるようになります。

それに関連するツールカテゴリーが知りたいなら、こちらを読み進めてください: スクラムマスター向けツール：ソフトウェア、技術、選定基準.

5. チームの健康状態と心理的安全性

チームヘルスは「ソフト」な副次指標ではありません。むしろ、後のデリバリー問題の早期兆候であることが多いです。

典型的なチームヘルスKPIは次のとおりです：

チーム内の信頼
心理的安全性
役割と目標の明確さ
焦点
意思決定力
認識されている仕事量
ステークホルダーとの協働の質

これらの指標は、定期的なパルスチェックやヘルスチェックとして実施し、その後レトロスペクティブで話し合うのが最も効果的です。Echometer はまさにその用途に強みがあります。チームヘルスチェックを定期的に収集し、トレンドとして可視化し、レトロの議論やアクションと直接結びつけることができます。こうしてチームヘルスは抽象的な雰囲気調査ではなく、継続的改善プロセスの一部になります。

数値だけではほとんど意味がありません。重要なのは、チームがその結果から具体的な改善を導き出せるかどうかです。

6. 顧客価値とアウトカム

最も重要なスクラムKPIは、しばしばスクラムボードの外側にあります。チームは本当の価値を届けているのでしょうか？

考えられるアウトカム指標：

機能の起動率または利用率
顧客満足度
サポート問い合わせ
コンバージョンまたはリテンション
フィードバックまでの時間
検証済み仮説の割合

これらの指標は、スクラムマスターだけの責任ではありません。しかし、優れたスクラムチームであれば把握しておくべきです。そうでないと、影響ではなくスプリントの稼働率を最適化してしまいます。

スクラムのメトリクス例：コンパクトなダッシュボード

優れたスクラムKPIダッシュボードは、大きい必要はありません。多くのチームには、次のような軽量な組み合わせで十分です：

目的	KPI	頻度	会議
焦点	スプリント目標の達成	スプリントごと	スプリントレビューとレトロ
フロー	サイクルタイム	継続的に	レトロまたはフローレビュー
品質	漏れたバグ / 手戻り	スプリントまたはリリースごと	レトロ、レビュー、エンジニアリング同期
改善	完了したレトロ施策	スプリントごと	レトロ
チームヘルス	ヘルスチェックのスコアとコメント	2〜6週間ごと	レトロ
アウトカム	顧客価値メトリクス	製品による	レビュー、プロダクトディスカバリー

これは意図的にコンパクトです。5〜7個のメトリクスを定期的にしっかり振り返るチームは、40個のダッシュボードタイルがあっても誰も真剣に議論しないチームより、はるかに多くを学べます。

Scrum KPI 指標を測定するためのツール

Scrum KPI には、これさえあれば完璧という単一のツールはありません。多くの場合、必要なのは2つの視点です。作業システムからのデリバリーデータと、レトロスペクティブ、ヘルスチェック、アクションから得られるチーム開発データです。

Cycle Time、Throughput、WIP、フォーキャスティング、あるいは DORA に近いエンジニアリング指標のようなデリバリー KPI には、専門の Engineering-Intelligence プラットフォームが有効です:

Plandeck: Plandeck は、さまざまなツールやプロセスを使う多くの異なるチームがある複雑なセットアップのエンタープライズ環境に適しています。
LinearB: LinearB はより初心者向けで、手頃な導入のしやすさがあります。

これらは主に、ワークフロー内のパターンを見つけるのに役立ちます。どこで作業が滞っているのか？どのチケットタイプに特に時間がかかるのか？複数のスプリントにわたってデリバリーはどれほど安定しているのか？

Echometer は、純粋なデリバリー・ダッシュボードでは見落とされがちな次の観点を補完します。すなわち、継続的なチーム開発、チームヘルス、レトロスペクティブ、そしてアクションのトラッキングです。特にカテゴリ 4 と 5 の Scrum KPI は、これによってチームのリズムに実践的に組み込むことができます：

Health-Check の質問を定期的にレトロスペクティブや Pulse Check で活用する
複数スプリントにわたるチームヘルスのトレンドを可視化する
レトロのアクションを記録し、再度取り上げ、フォローアップする
ROTI とレトロの有効性をフィードバックループとして活用する
改善を単に測定するだけでなく、チーム内で直接話し合う

実践的な推奨：デリバリーツールと、Echometer のようなチーム開発ツールを組み合わせましょう。そうすることで全体像を把握でき、データがより良い施策とより良い協働につながることを নিশ্চিতにできます。

EchometerでHealth Check Retroを開く

どのスクラムKPIが危険ですか？

最も危険なスクラムKPIは、目標として使われるVelocityです。

Velocityは、社内で予測精度を高める助けにはなります。しかし、経営がそれを業績目標にしてしまうと、悪いインセンティブが生まれます：

チームは見積もりを高くします。
ストーリーポイントが政治化します。
品質は後回しにされます。
チーム同士が不公平に比較されます。
学習が正当化に置き換わります。

つまり、Velocityは禁止ではありません。ただし、経営ランキングに入れるべきではないのです。

AI時代のスクラムKPIメトリクス

AIによって、スクラムKPIは重要性が下がるのではなく、むしろ高まります。チームがコード、チケット、テスト、ドキュメントをより速く生み出せるようになるほど、アウトプット測定だけではますます不十分になります。

重要な問いは次のようになります：

より速いアウトプットは、より速く検証されているか？
レビューの負荷は増えているか？
バグは早く見つかるか、それとも遅く見つかるか？
共通理解は良くなるか、悪くなるか？
レトロスペクティブはより具体的になるか、それとも表面的になるか？

まさにそれが、私たちの「アジャイルチームにおけるAI」に関する記事でも扱っていることです。研究状況が示しているのは、AIはチームや組織のレベルよりも、個人レベルでより早く効果を発揮することが多いということです。優れたScrumパフォーマンス指標がなければ、局所的な生産性が、Delivery、品質、あるいはチームヘルスの悪化を覆い隠してしまうことさえあります。詳しくはこちら：アジャイルソフトウェア開発におけるAI：2026年の研究状況.

組織にとっては、それはさらに重要です。アジャイル変革においてAIの利用、ライセンス有効化、あるいはコーディング速度だけを測っていては、本当の成熟度を見逃してしまいます。意味のあるScrum KPIは、フィードバックループ、責任、協働が本当に改善しているかを可視化します。それに合う記事はこちら：アジャイル変革におけるAI：AIが真の進捗を明らかにする.

Scrum KPIを実践的に導入する方法

小さく始める：

好きな指標ではなく、実際の問題を選ぶ。
何が改善されるべきか、仮説を立てる。
開始時はKPIを最大3つに絞る。
それらをレトロスペクティブで定期的に話し合う。
具体的なアクションにつなげる。
より良い会話を生まない指標は हटす。

例：

問題：“うちのStoryはDoneの直前で長く滞っている。”

KPI：Cycle Time、Work in Progress、Rework比率。

レトロの問い：“どこで仕事が待たされているのか、そして次のスプリントでどのルールを変えるのか？”

こうしてKPIは実践的になる。レポーティングの見せかけとしてではなく、学習システムとして。

結論：Scrum KPIはチームではなく、システムを測る

優れたScrum KPIは、チームが自分たちの仕事の仕組みを改善する助けになります。何が良いか悪いかを示すのではありません。フォーカス、フロー、品質、協働、または顧客価値のどこに問題があるかを示します。

私からの明確なおすすめはこうです。Scrum KPI Metricsは控えめに、しかし一貫して使ってください。Delivery指標に、Team Healthとレトロスペクティブの有効性を組み合わせましょう。そして、改善が生まれうる場所、つまりチームで、すべての指標を議論してください。

さらに深く知りたいなら、次のステップとしてこの記事が合っています： Scrum Masterのパフォーマンス：評価のための重要な5つのKPI.

FAQ: Scrum KPIとScrum Performance Metrics

スクラムマスターのパフォーマンスにおいて、どのKPIが重要ですか？

スクラムマスターのパフォーマンスにおける重要なKPIには、スプリントゴールの達成、継続的改善、信頼、チームの満足度、そして価値の提供があります。

これらのKPIは総合的に判断されるべきです。ベロシティやバーンダウンチャートだけでは、スクラムマスターが良い仕事をしているかどうかを判断するには不十分です。決定的なのは、チームがより確実に成果を出し、より良く協力し、具体的な改善を一貫して実行できているかどうかです。

詳細：スクラムマスターのパフォーマンスレビュー

記事を開く

Velocity は Scrum Master のパフォーマンスにとって良い KPI ですか？

Velocity は有益な話し合いのきっかけにはなりますが、それだけで Scrum Master のパフォーマンスを測る良い KPI ではありません。これは主観的な見積もりに基づいており、誤って解釈されやすいからです。

より適切なのは、Velocity を Sprint 目標、施策の品質、チームヘルス、信頼、そして価値の提供とあわせて見ることです。Velocity が上がってもチームヘルスが低下したり品質が損なわれたりしているなら、それは良い兆候ではありません。

記事を開く

スクラムマスターのパフォーマンスはどう測るのが意味がありますか？

スクラムマスターのパフォーマンスは、単一のKPIで測るのではなく、デリバリーメトリクス、チームの健全性、レトロスペクティブの有効性、アクションの追跡、そして定性的な観察を組み合わせて測るのが意味があります。

重要なのは、数値を監視の手段として使わないことです。数値は対話のきっかけにすべきです。チームはどこで集中力を失っているのか？どのブロッカーが繰り返し発生しているのか？どの施策が本当により良い協働につながっているのか？

詳しい背景はこちらをご覧ください：スクラムマスターのパフォーマンスKPI

記事を開く

Scrum Masterのパフォーマンス測定に役立つツールは何ですか？

Scrum Masterのパフォーマンス測定には、JiraやLinearのようなスプリント追跡ツール、レトロスペクティブツール、チームヘルスチェック、アクショントラッキング、必要に応じて1対1ツールなど、複数のツールカテゴリが役立ちます。

Echometerは、Scrum Masterがチームヘルス、レトロスペクティブ、アクションを1つのワークフローで結びつけたい場合に特に適しています。プロジェクト管理ツールは、何が起きているかを示すことが主です。レトロスペクティブとヘルスチェックは、なぜそれが起きているのか、そしてチームが何を改善すべきかを理解するのに役立ちます。

より幅広い概要はこちらでご覧いただけます: Scrum Masterツールの概要

記事を開く