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

メトリクスは、プロジェクトの状態と進捗に関する有益な情報を提供し、アジャイルチームを支援するものです。ただし、すべてのメトリクスが必ずしも有益ではありません。使いすぎは益よりも害のほうが多いこともあります。

これから挙げる3つのメトリクスは、やる気を向上させるどころか、アジャイルチームの妨げになる可能性があります。

欠陥の数

アジャイルチームにとって役に立たないメトリクスの筆頭にして最も明白なものは、欠陥の数です。スプリントごとの欠陥の合計であれ、個人別の欠陥の数であれ、製品の品質や進捗を測る数値として欠陥の数を使用するのはまったく良い考えではありません。

メンバーを競争に追い込み、本当の、重要なバグを見つけることに集中する代わりに、より多くのバグをレポートするようなインセンティブをテスターに与えます。自分の名前に多数の欠陥が関連付けられるのを開発者が嫌がるために、欠陥が却下される率が高まる可能性もあります。このメトリクスは、チームワーク全般によくない影響を与え、アジャイルチームの意識を低下させます。

時間

アジャイルチームは、有効なソフトウェアを提供することに集中する、バリュードリブンで自律的かつ統制の取れた組織であることが期待されます。短い時間枠とイテレーションごとのゴールを意識し、自身のタスクやユーザーストーリーを見積り、毎日のアップデートで情報を共有します。これ以外には、時間計測の必要はないように思われます。

実際の時間と見積もり時間を追加することで、ユーザーストーリーにかけられた時間をモニターする必要はあるとしても、ミーティング、ディスカッション、コラボレーション、レビューなど、明確にできない時間も相当にあります。古い体質のマネージャーは、個人の毎日のスケジュールや消費時間をチェックしなければならない、あるいは特定の業務時間を記録しなければならないという衝動を克服する必要があるかもしれません。

また、アクティビティを逐一トラッカーで記録する必要をなくすべきです。コラボレーションやコミュニケーションの大半は個人対個人の間で非公式なやり方で発生する可能性がある(そして実際そうなる)ものだからです。アジャイルチームは、チームがセルフドリブンでモチベーションが高く、結果を出すことを任されているときに最も効果的に働きます。

開発者ごとのコード行数または欠陥修正数

作成したコードの行数や修正した欠陥の数で開発者のパフォーマンスを測ろうとすると、開発者の作業のやり方に影響を与えます。たとえば、ユーザーストーリーを実装するとき、優れた設計コンセプトのほうが、簡単だが粗雑な方法よりもコード行数が少なくなる場合、開発者はどちらの方法を選ぶでしょうか？

同様に、開発者が修正した欠陥の数に注目するなら、欠陥はどれも同じような作業量だとみなしていることになります。開発者は修正に時間がかからない簡単な問題を選びたくなるいっぽうで、本当に対処が必要な重大な欠陥は、より時間がかかるために長く残ることになるでしょう。

プロジェクトの進捗を測り、チームのボトルネックを解決するためには、全体的なコード行数や欠陥の修正率のメトリクスを見る必要はあるかもしれません。しかし、これらを個人のパフォーマンスを測るのに使用するべきではありません。使用すれば、メンバーの作業や思考に影響を与えることになります。自分のいいように数を調整しようとし、製品の全体的な品質がおろそかになったり、正確に評価するのが不可能になったりする可能性があります。

メトリクスはあらゆるプロジェクトの管理に役立つツールになりえますが、それには品質と作業ペースを促進するメトリクスを選び、妨げになるメトリクスの使用を避ける必要があります。

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

（この記事は、開発元Gurock社の Blog 「Three Metrics Your Agile Team Should Stop Using」2019年12月3日の翻訳記事です。）