スクラムにおけるメトリクスの扱い

みなさんこんにちは。@ryuzeeです。

最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。

スクラムでよく登場する数値データ

スクラムでよく登場する数値データとしては、プロダクトバックログアイテムのビジネス価値や見積り、スプリントバックログのタスクの理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積りポイント（相対見積りの場合）の合計がベロシティ、全プロダクトバックログアイテムの未完了分の合計見積り値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。

最新のスクラムガイドでは見積りを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかについては定義されていませんが、これらのデータはとっておけばチーム状況の可視化や改善の役にたつので、必要に応じて各スプリント毎に更新しておくとよいでしょう。

完成の定義とメトリクス

一方スクラムプロセス自体ではなく、作っている製品に目を向けると、「完成の定義」をステークホルダー、プロダクトオーナー、チーム等の間で合意して、その定義に合致するものを「出荷可能な製品」とよび、各スプリントの成果物ではその基準を満たしている必要があります。この「完成の定義」をもとに、内部品質に関するメトリクスを考えると分かりやすいと言えます。一般的には、完成の定義に含まれるのは

ユニットテストが書かれている
カバレージN%
結合テストが書かれている
コードレビュー済
セキュリティや性能
自動化できない箇所は手動でテスト済
コーディング規約準拠
複雑度がN以上のものがない
CPDによる検査で重複コードがないこと
必要なドキュメントが更新されたり作成されている

といったあたりになることが多いと思います。（もちろんプロジェクトによって当然違います）これらのうち自動で取得できるデータについては、常時確認可能にしておくと良いでしょう。手動でデータを作成するのは継続性に問題があり、毎回作業のムダが発生するので、継続的インテグレーションサーバに組み込んだり、夜間バッチ処理をする等の工夫が必須です。

メトリクスの間違った活用方法

スプリントの中ではチームは自己組織的に仕事をしているべきであり、外部から監視目的でメトリクスを取ることはありません（そういう用途で使ってはダメです）。あくまでもチームが自分達自身がうまく製品を届けるため、そして改善のためにメトリクスを使うことになります。

例えばスクラムチーム外から監視や人事評価やプロジェクト評価のために、チームのためのデータを使うと、必ず以下のようなことが発生します。

ベロシティの数値そのものの大小が評価される

スプリントプランニングで、見積りが上振れする（インフレを起こす）ことにつながります。

あくまでベロシティは、このプロジェクトがこのペースでいくついつ終わるのか、もしくはスプリント数が限られている場合は上からどのくらいまでのプロダクトバックログアイテムができそうか、という予測のツールでしかない点に注意してください。

スプリントのタスクで残り時間だけでなく、見積り時間と実時間の乖離が測定され評価される

バッファを積んだ安全な見積りを行い、早くタスクが完了しても、予実の差を発生させないように、時間が来るまで完了にさせないようになったりします。

そもそも知りたいのはそのスプリントプランニングで選択したプロダクトバックログアイテムを完了にできるかどうかであって、かかった時間を追跡しても仕方ありません。今後同じ作業をする場合に参考になるから、という話を聞くこともよくありますが、スプリントの回数をこなせば見積りの精度は徐々にあがりますし、ふりかえり等で改善活動も行えます。かかった時間を測定する時間はムダではないのか？をよく考えてください。もしかしたら使うかも！の作業は本当にやるべきでしょうか？