アジャイルではメトリクスを取得し、その数値をもとに改善することが重要とされています。測定していない場合、改善しても効果があったかどうか分からず、その改善を続けるのか止めるのか判断できませんよね。じゃあ、メトリクスは何を取得すれば良いのか。どういったメトリクスがあるのか、調べてみました。
メトリクスを使う注意点
1. ゴールに関連するメトリクスをとろう
メトリクスが重要だからといって、なんでもかんでも取得すれば良いわけではありません。測定した数値を見て改善した結果、ゴールに近づくモノを取得したほうが良いです。ゴールは会社、プロジェクトやチームで立てた目標に影響するかどうかを考えるとよいと思っています。
2. 定期的に見直そう
一度決めたメトリクスはそのまま使い続けず、ゴールの変化に伴って更新したほうが良いです。頻度は多くなくても良いですが、定期的に見直すタイミングを持ちましょう。
3. その時の状況もあわせて記録しよう
特定の週の数値が急に悪化している結果に合わせて、「メンバーが一週間休んでいた」などメモがあると数値の扱い方が変わります。
メトリクスの種類
調べることで色々な種類のメトリクスがあることを知りました。調べた内容を「生産性」「品質」「ビジネス」「チーム」に分けてまとめたいと思います。
◆生産性
リードタイム
ひとつのタスクが開始されてから終了するまでの時間。改善するには作業を効率化するだけではなく、タスクの流れを把握し、ボトルネックを見つける必要があります。
ベロシティ
1スプリントで完了可能な数値です。ストーリーポイントを使われることが多いです。ベロシティは計画を立てるときの基準になります。
バーンダウン
スプリント中の進捗を表すグラフです。スプリント期間中に予定していたタスクが完了するかどうか予想を立てることが出来ます。
仕掛の数
仕掛はWIPと呼ばれることもあります。作業を開始したが、何らかの理由で次の工程に進められないタスクの数です。プロセスの中で仕掛りの数が多い部分はボトルネックになっている場所です。例えば、レビュー待ちが多くてテストが開始できていない！などです。
納期厳守率
納期や約束を守れたかどうかです。この指標だけでは改善ポイントを見つけることは難しそうですが、悪い状態になっていることに気づきやすい指標だと思います。
◆品質
平均修復時間(MTTR)
停止してから復旧するまでの時間です。
見つかった不具合の数
スプリント期間中に見つかった不具合の数です。不具合の数だけでなく、開発したタスクの難易度など組み合わせて見ることが重要です。
バグ修正を解決するまでの時間
MTTRと似ていますが、不具合が見つかってから修正するまでの時間です。未解決のバグ多い場合は開発が厳しい状態だと判断できます。
パフォーマンステスト
ボタンをクリックしてからの応答時間など、システムの性能の測ります。基準を設けて異常値かどうか監視する必要があります。定期的に確認していると、異常値の原因を見つけやすいですね。
◆ビジネス
価値要求と失敗要求の数
価値要求は新機能の開発や既存機能の改善です。失敗要求は不具合修正や仕様不具合の修正などです。失敗要求が多い場合は品質に問題があると考えられます。
破棄項目
開発途中に開発中止になった機能の数です。多い場合はパフォーマンスにもモチベーションにも影響するため改善が必要です。
NPS(ネットプロモータースコア)
「プロダクトを友人に薦めるか？」0～10で評価した結果です。
ユーザインタビューやアンケート
ユーザインタビューやアンケートで定量的、定性的な結果です。
まとめ
調べてみるとリードタイムやベロシティなど、多くのチームで使われているメトリクスがありました。定期的に取得する数値もありつつ、状況に合わせて取得する数値を選ぶという方法が良いのかなと思いました。
参考記事
ソフトウェア開発において最も重要なメトリクスは何か？
アジャイルメトリクス実践ガイド
リードタイム短縮のポイント～適切な生産計画に必要な考え方～ | ProSharing Consulting(プロシェアリングコンサルティング)
アジャイル開発のキーメトリクス｜suhahide｜note
アジャイルの車輪を使ってチームの共通認識を形成する | チームサプリ
5 つの役立つアジャイル指標 | Atlassian
アジャイル開発とメトリクス
アジャイルメトリクス 〜 良い指標・悪い指標・酷い指標 | サーバントワークス株式会社
カンバン仕事術 書籍 ブログ
SCRUMMASTER THE BOOK 書籍 ブログ
