スクラムチームのパフォーマンスを測定したいと思ったら

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

スクラムチームのパフォーマンスを測定したいとステークホルダーに言われて悩んでいるスクラムマスターは多いと思います。今回は、スクラムチームのパフォーマンスはどうやって測ればいいのか、何を気をつけるといいのか考えてみましょう。具体的なメトリクスについては、別の記事で触れる予定です。

測定には目的が必要

ソフトウェア開発に限らず、何かを測定しようとするときには目的が必要です。目的がないと、リソースがムダになったり、意思決定が難しくなったり、データをめぐって混乱が発生したりするリスクが高まります。やりたいこと、やらなければいけないことは、だいたいやれる量よりも多いですが、そんな状況で限られた時間や資源を有効に活用するためには、測定が意図する目標とその結果の具体的な活用方法を明確に設定しなければいけません。

「いや、でもいずれ使うかもしれないので、何でもデータを集めておいた方がいいのでは？」と言われることもありますが、それにはコスト（入力のコスト、ストレージの容量、それを見る時間などなど）がかかります。大したことがないコストでも長期間に渡ると大きなコストになってしまうことを認識しておかなければいけません。

言い換えると、目的を設定すると以下のような利点があります。

目的に応じて必要なデータのみを集め、ムダを防ぐ
測定結果をもとに、具体的な改善策やアクションを計画しやすくなる
測定の目的と結果が明確であれば、チームメンバーやステークホルダーとのコミュニケーションがスムーズになる

ということで、スクラムチームのパフォーマンスを測定したいのであれば、なぜそうしたいのか、集めたデータをどう使うのかという点を明確にしてください。「ステークホルダーに言われたので」ということであれば、ステークホルダーと会話する時間を取る必要があります（そして、想像以上にステークホルダーが何も考えずに依頼していることがわかることもあります）。

単一の指標だけでは意味がない

ソフトウェア開発において、チームのパフォーマンスを評価する際に単一の指標だけを使用することは困難です。これはアジャイルだろうがウォーターフォールだろうが同じです。ソフトウェア開発は、さまざまなスキルやタスク、そして動的な要因が組み合わさった複雑なプロセスです。この再現性のない、一度限りの特性から、単一の指標だけでは、チームの多面的な能力や、その環境下での実際のパフォーマンスを正確に捉えることはできません。それぞれのプロダクト/プロジェクトとチームが独自の課題と目標を抱えているため、評価は複数の指標を用いて多角的に行うべきと言えます。

また単一の指標の利用は別の問題もあります。単一の指標を使うと、他の重要なことを犠牲にしがちだということです。これは指標が評価や報酬、管理に使われる場合に顕著です。たとえば、ある特定の指標を最適化するプレッシャーがかかると、品質、長期的な成果、持続可能性などを損なう可能性があります。

また「管理のために用いられる測定はすべて、信頼できない」というグッドハートの法則がここでもあてはまります。つまり、測定され、報酬が与えられるものはすべて改ざんされます。改ざんは言い過ぎにしても、他を犠牲にしてでも数値を最適化するようにハックします。したがって数値には信頼性がなくなります（詳しく知りたい方は、書籍『測りすぎ――なぜパフォーマンス評価は失敗するのか？』を読むことをお勧めします）。

これらを防ぐためにも、さまざまな角度から複数の指標を選ぶ必要があるわけです（一般的に、複数の指標のあいだには相関関係が存在し、一つの指標が不自然に改ざんやハックされた場合、他の指標にもその影響が現れます。そのため、1つの指標だけを操作しても、それが他の指標との一貫性を損ない、不自然な動きとして容易に検出可能です）。

測定すべき指標は変化する

ソフトウェア開発は動的であり、そのフェーズや目標、技術的な課題は常に変化します。したがって、測定する指標もプロダクト/プロジェクトの状況や目標に応じて柔軟に変更しなければいけません。

初期フェーズで重要だった指標が、進行に伴ってその重要性を失ってしまいムダになることは多々あります。例えば、開発中はコードの品質やテストカバレッジが重要かもしれませんが、開発とリリースを繰り返すフェーズ（そしてチームが十分に開発できるようになったあと）だとリードタイムやサイクルタイムの方が重要になるかもしれません。

冒頭で説明したように「目的」に立ち返って、どの指標を見ると良いかを考えなければいけません。往々にして、指標の収集がルールのようなものになってしまい、目的や背景を知らないまま測定を続けることになりがちです。そうならないようにある程度の期間ごとに目的や指標を見直すことをお勧めします。

定量的な指標だけを重視しない

人事評価にせよ何にせよ、（偉い人たちは）定量的にしろと言ってきます。もちろん定量的な指標は重要なのですが、それだけにしてしまうと大事なことを見落としがちです。そのため、定性的なデータもあわせて活用しましょう。定量的なデータが「何が起こっているか」を示すのに対し、定性的なデータは「なぜそれが起こっているか」を理解する手助けになります。

例えば、定量的なデータがバグの数やコードの開発生産性を示していても、それだけではそれが発生する背後の理由やコンテキストを完全には捉えられません（そもそも、それらの指標に問題があったとしても、原因がチームに由来しているかどうかすらわかりません）。定性的なデータ、特にチームメンバーの意見やフィードバックは、何らかの問題がある場合に、その原因や解決策を探る上で非常に役立ちます。

定性的なデータは、チームのモチベーションやコミュニケーション、協力関係、組織文化など、数値で直接測定するのが困難な要素を評価するのに役立ちます。これらの要素は、チームの開発生産性や品質に大きな影響を与えるため、無視するわけにはいきません。また、ユーザーや顧客のフィードバックや感想も定性的なデータです。プロダクトの満足度や使い勝手を深く理解するのにとても役立ちます。こういった情報があれば、チームはユーザーや顧客の期待に応えるための改善策を立てられます。