この記事はNishi Grover Gargによるゲスト投稿です。

アジャイルチームは常にゴールに向かっており、絶え間なく計画、モニタリング、再計画を繰り返す必要があります。メトリクスはプロジェクトの状態と進捗について有用な情報をもたらし、チームの活動に役立ちます。

アジャイルチームでよく使われるメトリクスには、スプリントバーンダウンチャート、リリースバーンアップチャート、チームベロシティがあります。これらのメトリクスは実用的な情報を与えてくれるため、よく使われていますが、これがすべてではありません。

簡単に計測できてアジャイルチームに非常に役立つ3つのメトリクスがあります。

欠陥の状態

欠陥の数は、アジャイルチームにとってもそうでないチームにとっても、よいメトリクスではないかもしれません。見つかった欠陥を数え、その数に基づいてメンバーを褒めたり責めたりし、欠陥の数によって製品の品質を判断するなら、行く手に破滅が待っているかもしれません。いっぽう、本当の意味で役に立つのは、常に欠陥の状態を追跡することです。

そうすることで、欠陥に関するいくつかの重要な疑問に答えるグラフを作成できます。

• 見つかった欠陥はどれくらいすばやく解決されているか？（ターンアラウンドタイム）
• 欠陥はどれくらいの頻度で（「設計どおり」、「再現せず」、「重複」などの理由で）リジェクトされているか？
• どれくらい多くの欠陥が優先順位付けされず、修正予定日が決定されていないか？（欠陥が長い間後回しにされていることを意味する）

これらのファクターは、欠陥トラッキングツールで普通のフィルターを使って容易に追跡できます。これらの欠陥の状態を表すメトリクスの結果から、システムだけでなくチームの中で何が起きているかに関して多くの情報が得られます。この情報は、メンバーを管理するメトリクスではなく、品質への道筋に向けてチームの足並みを揃え、逸脱に対しては具体的に対処可能な項目を提示する強力なツールとして役に立ちます。

テスト進捗

プロジェクト全体の進捗を測るのに一番良い方法は、テストの進捗に着目することです。

厳密に進捗を記録するには、リリースやスプリントが始まる時点で、しっかりしたテスト計画を作成する必要があります。計画に照らしてアクティビティを完了、作業中、保留中としてマークすることは、作成/実行/成功または失敗したテストの数という表面的な指標よりも正確な進捗の指標になります。

計画済みのタスクに対する実行済みのタスクの数ではなくパーセンテージを使うこともできます。視覚的な指標は、チームの作業への理解を深め、遅れがあればその理由にまで導くことができます。

たとえば、8月1日の月曜日にスプリントが開始したとしましょう。8月1日から5日の週では、実行されるテストより作成されるテストのほうが多かったのですが、スプリントの最初ではテストできるものはそれほどないため、これは不思議ではありません。8月5日には最初のビルドがテストできるようになり、次の週にはテストが実行され、レポートされた欠陥の数が多くなるのと並行して修正された欠陥の数も増えており、順調でした。

ところがその次の週では、修正された欠陥の数が減るとともに、テストの進捗も滞ってしまいました。

この状況を分析すると、次のような理由が見つかるでしょう。

• 開発者の焦点が次のユーザーストーリーの開発に移った。
• テスターがより多くのテストの設計に着手し始め、再テストとレグレッションテストは後に回された。
• 週に祝日があり、多くのメンバーが何日か余分に休暇を取ったため、人員が不足していた。

根底にある理由が何であれ、メトリクスはチームの作業に対する偏りのない洞察を提供し、日々のアクティビティを分析する手段を与えてくれます。ここでは、状況は深刻なものではないかもしれません。テストタスクに重点が戻れば―あるいはメンバーが休暇から戻れば、状況は改善するかもしれません。懸念すべき理由があるなら、それを認識し、軌道を外れないようにするのをメトリクスが助けてくれるでしょう。

ビルドの失敗

このメトリクスは、成果物を頻繁に統合し、定期的にビルドを行うDevOpsや継続的インテグレーションなどの環境で意味を持ちます。ビルドの頻度はコンテキストに依存しますが、肝心なのは、自動実行ビルドがコンパイルまたはビルドに失敗した回数です。

失敗の多くは、不完全なコードや誤りのあるコードがチェックインされたこと、依存先ライブラリがないこと、あるいは変更や欠陥が原因で自動テストが失敗したことなどによります。ビルドの失敗の原因が何であれ、チームは失敗を分析し、ビルドが成功するよう修正するのに時間を取られることになります。

この作業は大変な労力を要し、何度もメールでのやり取りや警報を発生させる可能性もあるため、このような意図しないアクティビティにどれだけ追加の作業が必要だったかを記録しておくのは有益でしょう。

1時間あるいは1日に何回ビルドするかはチームによって大幅に異なる可能性があるため、数自体よりも時間の経過に伴う相対的な増減のほうが意味があるかもしれません。スプリントを繰り返すにつれてビルドの失敗の回数が減っているなら、作業が改善されていることがわかります。

このメトリクスを改善する方法としては、いつどのようにビルドがトリガーされるかを開発者に教育する、依存関係を更新する共通の場を確立する、ビルドがトリガーされる前に確認するべきことの簡潔なリストを作って維持する、ビルドプロセスごとに1人オーナーを決め、失敗を追究して適切なメンバーにコードを修正させる、といったことがあります。上のグラフからわかるように、４つのスプリントを経て、スプリントあたりのビルドの失敗メトリクスは確実に改善されています。

これまで検討されていなかったかもしれないこれら3つのメトリクスが、高品質なソフトウェアに向けたアジャイルチームの道のりに役立つことを願っています。

Nishiは企業トレーナー、アジャイルの信奉者、そして根っからのテスターです。業界で11年以上の経験を持ち、現在はSahi Proでエバンジェリスト兼トレーニングヘッドとして働いています。トレーニングに情熱を注ぎ、テストコミュニティイベントやミートアップを主催したり、多数のテストイベントやカンファレンスで講演を行っています。アジャイルおよびテスト分野での最近のトピックを取り上げたブログをご覧ください。

（この記事は、開発元Gurock社の Blog 「Three Uncommon Metrics Your Agile Team Should Be Tracking」2019年11月27日の翻訳記事です。）