アジャイルメトリクス〜良い指標・悪い指標・酷い指標

再訪ありがとうございます！

なんどもご来訪くださりありがとうございます。わたしたちにお手伝いできることはありませんか？ぜひご意見やフィードバックをいただければ幸いです。

翻訳記事

本記事は、Stefan Wolpers さんの「Agile Metrics — The Good, the Bad, and the Ugly」の翻訳です。翻訳・公開にあたって、Stefan さんの快諾をいただいております。
誤字脱字、誤訳がありましたら、ご指摘ください。

TL;DR: アジャイルメトリクス
良いアジャイルメトリクス
悪いアジャイルメトリクス
1. チーム内におけるスプリントでの比較でも難しいとされる主な要因
酷いアジャイルメトリクス
まとめ
関連記事
本記事の翻訳者:

TL;DR: アジャイルメトリクス

適切なアジャイルメトリクスは、チームが「アジャイルになる」ための状況もしくは、組織が「学習する組織になる」ための状況のいずれかを反映したものになります。

チームレベルでは、アジャイルメトリクスは、定性的な方が定量的な方より、機能することが多いです。組織レベルでは、これが逆になります。定量的なアジャイルメトリクスは、定性的な方よりもより良いインサイトを与えてくれます。

26,000人が登録する「Food for Agile Thought」ニュースレターに登録しませんか？または、「アジャイルメトリクスサーベイ（Agile Metrics Survey 2020）」への貢献を検討してください。

良いアジャイルメトリクス

一般的にメトリクスは、現場をより良く理解するのに役に立ちます。また、時間経過とともに、変化に対するインサイトを得ることができるようになります。メトリクスがなければ、どのような努力の結果や開発を評価しても、直感やバイアスに基づいた解釈に左右されてしまいます。

したがって、指標（metric）は、パターンの変化のための先行指標となるべきです（※太字は訳者によるもの）。また、指標は、時間内に原因を分析する機会を提供するものである必要があります。

アジャイルメトリクスのための有用性が示されている3つの一般的なルール

意味のあるメトリクスのルールは以下の3つです。

チームに関するものだけを追跡する。個人に関する測定は無視する。
パラメーターが追跡しやすいという理由だけでパラメーターを測定しないこと。
よくあるのは、すぐに使えるレポートを提供するいろいろなアジャイルプロジェクト管理ツールを使った結果である。
コンテキスト（文脈）も記録すること。
コンテキストのないデータは、ノイズ以外の何物でもないことがわかるかもしれない。
例: 動けるチームメンバーの数、スプリント中でのインシデントの激しさ

意味のあるメトリクスの例としては、技術的負債の指標（※下記参照）の（平均の）センチメントがゆっくりではあるが着実に減少している場合は、以下を示唆している可能性があります：

チームが、（恣意的に）期日を守るためにコードの品質を犠牲にし始めたのかもしれない
チームが、実験の速度をあげるために、意図的に一時的な解決策を作り上げたのかもしれない

後者は、およらく、良いことだと思います。前者の解釈は懸念があります。これについては、スプリントレトロスペクティブ（ふりかえり）にて、チームで分析する必要があるでしょう。

良い定性的なチームのメトリクス：自己評価テスト

アジャイルのテクニックやプロセスを採用しているチームの進捗状況を追跡したい場合、自己評価テストは、その目的に適っています。例えば、私は、Henrik Kniberg のスクラムチェックリストをよく使います。

スクラムチェックリスト

やり方としては、4〜6週間ごとに、レトロスペクティブでアンケートを実施します。その結果を記録して、収集します：

この例では、チームは見積もりポーカーの類を用いて、グリーン、オレンジ、レッドの3つの値のうちから1つを各質問に対して出し合いました。色の意味は以下です：

グリーン: チームのために機能している
オレンジ: チームのために機能しているが、改善の余地がある
レッド: 当てはまらない

例えば、項目「Team has a sprint burndown chart（チームがスプリントバーンダウンチャートを使っている）」に対して、バーンダウンチャートを使っていないか、まだうまく使いこなせていない場合はレッドです。

結果として、このスクラムプラクティスマップが時間と共にグリーンになっていくならば、このスクラムチームは正しい道を歩んでいることになります。そうでなければ、継続的に改善できない理由を深く掘り下げて理解し、それに応じて適応していかなければなりません。このフォームのデータは、スプリントレトロスペクティブでの貴重な情報となります。またマネジメントとのディスカッションの貴重な情報にもなるでしょう。それによって例えば、さらなるトレーニングの機会の必要性について示すなどができます。

匿名による投票調査

上記で紹介した方法に加えて、私は、毎回のスプリントの終盤に匿名の投票調査を行うようにしています。投票調査は、4つの質問で構成しています。それぞれに対して1〜10段階で回答するものです：

このスプリントでチームはどのような価値を提供したか？
1: 何も価値を提供していない
10: 可能な限り最大限の価値を提供した
このスプリントで技術的負債のレベル感としてどこまで返済できたか？
1: スクラッチからアプリケーションを書き直した
10: 技術的負債はまったくない
アジャイルマインドセットを持ち合わせた知人に対して、この組織での仕事を勧めるか？
1: いいえ、この組織より友情を大切にしたい
10: 躊躇なく！
チームメイトと仕事をすることが幸せか？
1: いいえ、既に次の仕事を探している
10: もちろん、月曜日の朝が待ち遠しい

投票調査は、各チームメンバーに60秒以内で答えてもらいましょう。そして、結果はもちろん誰にでも見れるようにしましょう。繰り返しになりますが、4つの定性的な指標（質問）を追跡することで、他の方法では気づかないかもしれない傾向へのインサイトが得られるでしょう。また、このデータはスプリントレトリスペクティブのための良い情報の提供になります。

良い定性的なチームのメトリクス：スクラムの価値基準の状態

定期的な匿名による投票調査のもう一つの使い方は、スクラムチームでのスクラムの価値基準の状態を見ることです。スクラムの価値基準である5つ（確約、勇気、集中、公開、尊敬）に対して、リッカート尺度で質問します。1段階目は、「スクラムチームはスクラムの価値基準がまったく実践できていない」であり、5段階目は、「スクラムチームは、[スクラムの価値基準の一つ]について完璧である」（例: スクラムチームは、確約について完璧である）などです。

何度か投票調査を実施してスパイダー図でデータを可視化することで、スクラムの価値基準に対してスクラムチームの浸透状況を簡単に把握することができるようになります。

C: Commitment - 確約
C: Courage - 勇気
F: Focus - 集中
O: Openness - 公開
R: Respect - 尊敬

良い定性的なチームのメトリクス：リードタイムとサイクルタイム

あらゆるアジャイルへの移行は、最終的には学習する組織になることです。そして、ライバルに対して競合優位性を得ることにもなります。

以下のメトリクスは、（ソフトウェア）プロダクトデリバリープロセスに適用できます。また用途に応じてさまざまなプロセスにも適用できます。

長期的には、機能的なサイロから機能横断的な自己組織化チームへの組織を再構築することだけではありません。また、価値創造を阻害する不用な待ち行列を特定するなど、仕組み自体の分析も必要となるでしょう。

プロダクトデリバリープロセスにおける既存の待ち行列を特定するために、5つの日付を記録し始めましょう：

前回に検証済みのアイデアの日付
例: 新しいフィーチャーのためのユーザーストーリーがプロダクトバックログアイテムになった日付
プロダクトバックログアイテムからスプリントバックログアイテムになった日付
スプリントバックログアイテムの開発を開始した日付
スプリントバックログアイテムがチームの完成の定義（DoD）を満たした日付
スプリントバックログアイテムが顧客にリリース済みになった日付

リードタイムは、上図の「1」の日付から「5」の日付までの経過時間です。サイクルタイムは、「3」の日付から「4」の日付までの経過時間です。

目標は、リードタイムとサイクルタイムの両方を短縮して、顧客に価値を提供する組織の能力を向上することです。この目的は、プロダクトデリバリープロセスでのチーム間の依存関係や引継ぎを取り除くことで達成できます。

この目的に対して有用なプラクティスは以下です：

機能横断的なチームをつくる
フィーチャーチームにする（コンポーネントチームの代わりに）
チームメンバー全員の間で、全体的、プロダクト全体の視点とシステム思考を促進する

リードタイムとサイクルタイムの測定には、派手なアジャイルツールやビジネスインテリジェンス（BI）ソフトウェアは必要ありません。簡単なスプレッドシートで行えます。すべてのチームが単純なルールで行えます。チケットを移動した日付に着目してください。この方法なら、後述するインデックスカード（※訳注: 付箋紙なども）でも機能します。

次のグラフは、3つのスクラムチームのリードタイムとサイクルタイムの中央値を比較したものです：

この値は、3ヶ月間に、チケット（ユーザーストーリーのチケットとバグチケットの両方）を分析したものです。1スプリントの期間は2週間でした。

その他の良いメトリクス

Esther Derby 氏は、フィーチャーの作業に対する修正作業の比率や、開発を妨げる欠陥の数を測定することを提案しています。

実用的なアジャイルメトリクスのよい情報源としては、State of DevOps Report があります。

悪いアジャイルメトリクス

物議を醸していますが、伝統的なアジャイル指標にチームのベロシティがあります。チームのベロシティは、悪名高い変動性のある指標です。実際には経験豊富なチームのみが使いこなせるものです。

チーム内におけるスプリントでの比較でも難しいとされる主な要因

新メンバーのチームへのオンボーディング
ベテランのチームメンバーの離脱
シニアレベルのチームメンバーの変更
チームが未知の領域の仕事をしている
チームがレガシーコードを作業している
チームが予期せぬ技術的負債に追われている
祝日と病欠によってスプリントのキャパシティが減ってしまっている
食堂の料理が不味い
深刻なバグに対応しなけれならなくなった

事実、チームのパフォーマンスを各スプリントごとに正規化 (訳注: 日本語のウィキペティアへのリンクに変更) して、少なくともいくつかの比較可能な値を導き出す必要があるはずです。これは通常は行われません。

さらに、ベロシティは、容易に操作できる指標なのです。私は通常、新しいチームをコーチングするときには、「Cooking th Agile Books」(訳注: リンクは訳者により追加) 演習を行うようにしています。また、私は、ベロシティに基づいたレポートの要件を確実に満たす方法について、適切なアイデアを出すことができなかったチームと仕事をしたことがありません。これはホーソン効果 (訳注: 日本語のウィキペディアへのリンクに変更) と呼ばれています。

ホーソン効果（ホーソンこうか、英: Hawthorne effect）とは、治療を受ける者が信頼する治療者（医師など）に期待されていると感じることで、行動の変化を起すなどして、結果的に病気が良くなる（良くなったように感じる、良くなったと治療者に告げる）現象をいう。
ウィキべティア

さらに悪いことに、全てのチームがそれぞれ異なる見積もり基準をしているので、チーム間のベロシティを比較することはできません。もちろん、見積もりは単にレポートのために求められるわけではないので、このようなやり方は受け入れることができるものです。見積もりは、作業アイテムの「なぜ」、「どのように」、「何を」について、チームメンバーの間で共通理解を生み出す取り組みの副次効果に他なりません。

ベロシティについては以下も参考にしてください：

酷いアジャイルメトリクス

私がこれまでに遭遇した中で最も醜いアジャイル指標は、「時間あたりの開発者一人あたりのストーリーポイント」です。この指標は、従来のプロジェクトレポート手法における「コード行（LOC）」や「経過時間（hours spent）」のようなものです。この指標は、判断や比較のためのコンテキストを提供していないため、全く役に立ちません。

同様に役に立たない「アジャイル指標」としては、例えば、「認定XXの人数」、「アジャイルプラクティスのワークショップを履修した人数」が挙げられます。

まとめ

いくつかのデータポイントしか記録することができない場合は、リードタイムとサイクルタイムを測定するために、開始日と終了日を使いましょう。アジャイルジャーニーを歩み始めたばかりであれば、例えば、Henrik Kniberg による「スクラムテスト」のような自己評価テストに基づいた定性的なシグナルを測定することで、個々のチームでのアジャイルの導入度合いを追跡することを検討しましょう。

チームとして進捗を追跡するために何を測定していますか？あなたのアジャイルメトリクスをコメントで共有してください（訳注: コメントする場合は、英語の元の記事に英語でコメントしてください。日本語で共有する際は、この記事へのリンクをつけて Twitter などのソーシャルメディアにて共有してみてください）。または、「Hands-in Agile」の Slack に参加してください。Agile Metrics のチャンネルがあります。

✋ 8,000人以上が参加している「Hands-on Agile」Slack チームに参加して、アジャイルメトリクスについてもっと学びましょう（無料）。【詳しくはこちら】