アジャイルコミュニティは、アジャイルチームの成功を測る方法を変える必要があります。メトリクスを定め、その結果から情報を得る方法は、実際には、動くソフトウェアを作るというもっとも大切なことを妨げています。それぞれのメトリクスを強要することで、他人のことを気にしすぎて、協力できなくなることがあります。その結果、測定しようとした作業そのものができずに、目的を達せられなくなるのです。
私が考えたところ、そこには2つの大きな問題があります。
オブザーバー効果: オブザーバー効果とは、プロセスを観察することによって、その結果に影響を与えることです。例えば、チームに対し、ベロシティに目を光らせると伝えると、チームはベロシティを増やすために、アイテムのベロシティを多く見積もろうとします。ストーリーポイントを使っている時は、見積もりの妥当性を比較する方法がないので、これは特に危険です。
このイメージはこちらを参照しています。
おそらくこのようなことはあると思いますが、仕事でのオブザーバー効果の例として、私は好きではありません。ここでは、私がずっと前に知り合いだったサポートの人について話します。彼を「Jason」と呼びましょう。Jasonは優れた技術者であり、特に難しい電話の対応を担当していました。大抵、彼は最初の電話で正確に問題を解決し、顧客からよいフィードバックを得ていました。問題は、Jasonの通話時間がとても長かったことです。マネージャにとって、通話時間というメトリクスはとても重要でした。何度かミーティングを実施し、レビューした結果、Jasonは通話時間を短縮するか、さもなければ他の仕事を探さなければならなくなりました。2、3週間経って、Jasonは通話時間に関して、サポートグループのトップ5に入るようになりました。彼はどうやって通話時間を短くしたのでしょうか? 彼はその方法をずっと誰にも言いませんでしたが、ある日、私はいつもより早く出社して、その方法を見てしまいました。Jasonは自分のシフトの1時間も前に出社し、電話をとっては、すぐに切っていたのです。
ここで注目したいのは、Jaxonが実際のパフォーマンスよりも通話時間が重要でなかったら、そんなことはしなかったことです。通話時間を測ることは、結果的にマイナスに働きました。さらに、Jasonのような極端な例でなくても、このようなメトリクスを使うのはよくありません。通話をすぐに終わらせようとするテクニカルサポートを誰でも経験したことがあるでしょう。問題は、通話時間を短くしようとして切った電話が、どんな電話であったかということです。
街灯の効果: 街灯の効果とは、人には、実際の情報ではなく、見やすいところに答えを求める傾向があることです。例えば、作ったコードのライン数を数えるのは簡単ですが、アプリケーションの品質、提供される機能、有効性などはライン数からは分かりません。
このイメージはこちらを参照しています。
私は、以前、複数の製品を開発するチームで、製品ごとに異なる品質基準があったことを思い出しました。「製品A」は、｢製品B」、｢製品C」、｢製品D」よりもずっと厳しい品質基準を持っていました。このことは、マネージャが次のレビューで品質が重要だと言い出すまで、大した問題ではありませんでした。
ここで問題なのは、「品質」が漠然としたコンセプトであり、簡単に測定できないことです。エラー発生率はもっと簡単に測定できます。そのため、高い品質基準で「製品A」に携わっているチームメンバは、レビューでは非常に不利になります。そうなると、「製品A」の仕事を誰がするでしょうか? 大抵はインターンで、他には派遣や契約で来ている人たちになります。
結局のところ、エラー発生率は簡単に測定できても、役に立ちませんでした。エラーが発生した数は、人よりも製品次第だったからです。代わりに、私たちは優れた新人たちを追いたて、クライアントを失うことになり、作ることよりもエラーを避けることがチームの仕事になったため、チーム全体のモラルが下がりました。
これらの例はソフトウェア開発以外のところで起きましたが、これらのコンセプトをあなたが知っている共通の「アジャイル」メトリクスに当てはめてみましょう。簡単に測定できるのはどれでしょうか?
ユニットテストを書く: アジャイル開発者は、ユニットテストを沢山書きます。テスト駆動開発では、さらに多くのテストを書きます。そして、両者ともより品質の高いコードを生み出します。そのため、テスト数で開発者の生産性を測定するのは、よいに違いありません! しかし、実際にはオブザーバー効果がこれをダメにします。開発者にテスト数で測定すると言うと、テストの品質に関わらず、沢山のテストを書こうとします。私たちの目的は、テストをリリースすることではありません。動くコードをリリースすることです。私だったら、使えないテストよりも、数は少なくても優れたテストを選ぶでしょう。
個人別ベロシティ: ここでも、個人別ベロシティは、オブザーバー効果によって悪いメトリクスとなります。開発者が自分のパフォーマンスによって個別に評価されると知っていて、特に自分がやったことに対してのみ功績が認められるならば、その開発者はグループに貢献しようとはしないでしょう。チームに貢献するのではなく、チーム内で競い合って、まったくアジャイルではない状況に置かれるのです。
理想的な世界では、アジャイルチームは協力し、お互いに影響を与え、チームですることすべてを議論して、検討します。このようなことは、高い品質を持つソフトウェアを構築し、素早く問題を解決するのに向いています。このくらい影響し合うレベルになると、グループから個人の生産性を分けるのはほぼ不可能です。だから、そのようなことはしないでください。グループから個人の生産性を分けようとすれば、よいソフトウェアを作ろうとするチームの開発力を傷つけるだけです。
チームベロシティ: チームベロシティは、スクラムの中で最も誤解されているメトリクスの1つです。チームのベロシティは、チーム毎に異なります。単に、別のチームとは比べられません。例えば、チームAは、あるスプリントの作業を50ポイントと見積もるとしましょう。チームBでは、同じ作業を150ポイントと見積もります。ここで、両チーム共、スプリントを無事に終わらせたなら、チームAのベロシティは50ポイントで、チームBのベロシティは150ポイントになります。それでは、生産性が高いのはどちらのチームでしょうか? どちらでもありません。両チームとも同じ作業をしました。ポイント数をメトリクスにすると、チームはポイントをごまかして見積もろうとするので、次のスプリントの計画に悪い影響を与えます。チームで適切にスプリントを計画しなければ、納期に遅れるリスクが増すでしょう。スクラムのチームベロシティに関するさらなる情報は、私が以前書いたブログの投稿で参照できます。
それでは、どんなメトリクスを使うべきでしょうか?
よく聞いてくれてました。私たちは、リリースする動くソフトウェアで生産性を測ります。何をしたかではなく、実際に出来たもので測定します。このアプローチによって、チームはよりアジャイルになります。チームは、メトリクスの結果をよくすることよりも、うまくいくようにチームに貢献して、ソフトウェアを作ろうとするからです。このメトリクスは、ずっと論理的だと言えます。動くソフトウェアは、私たちが文字通りに銀行へ持っていけるものだからです。(もちろんソフトウェアを販売した後ですが)
実際に使う新しいメトリクスは何?
納品される価値: 納品される価値をメトリクスにするには、プロダクトオーナーが必要でしょう。プロダクトオーナーには、ユーザストーリーに対して、ステークホルダへ与える影響がどれだけかを示す価値を決めてもらいます。実際の金額か、何かしら適当な数値でその価値を数えます。スプリントの終わりには、プロダクトオーナーの目を通して、顧客にどれだけの価値を納品したかという数値を手に入れられます。
このメトリクスではパフォーマンスは測れません。代わりに、影響を測ります。理想を言えば、プロダクトオーナーは、バックログの上から高い価値を持つアイテムを並べるので、そのスプリントで最大の価値を提供することになります。終わりが決まっているプロジェクトに取り組んでいる場合、スプリントは非常に高い価値を持つアイテムから始めて、次第にバックログのアイテムを進めて行くと、より価値の低いアイテムを納品するようになります。ある時点で、次のスプリントで提供すべき価値を生み出すのに必要な開発コストを使い始めるでしょう。そうしたら、チームは新しい製品の開発に取り掛かるべきです。
期日通りの納品: 顧客に対して明確な納品日を提示できなかったために、会社でアジャイルの導入に失敗したと言う人がいます。私はこの話が信じられません。アジャイルチームが必ずできることは、決まった日までにソフトウェアを納品することです。終わっていないストーリーはあるかもしれませんが、通常、それらは価値の低いストーリーであり、顧客にもっとも影響しない部分です。そうは言っても、チームのベロシティは、ほどよく安定していて、速かったり、遅かったりしても、ゆっくり変化していなければなりません。スプリントからスプリントでベロシティが大きく変わると、長期的な計画を立てるのが難しくなります。
次のメトリクスを使いましょう。チームで、次のスプリントのストーリーを5つだと予想し、5つのストーリーを納品した場合、2ポイントを獲得します。4つのストーリを納品したり、納品日の2日前から納品日までの間に納品した場合(日数は自分で決める)、1ポイントを獲得します。2日以上前に納品したり、5ストーリーのうち3ストーリーだけ納品した場合、ポイントは獲得できません。四半期の終わり、リリースの終わり、または、1年の終わりなどに、チームはどれだけ正確にスプリントを予想できたかを判定します。
つまり、私たちが測定するものは顧客に納品する価値であり、ソフトウェアを納期通りに納品することです。これらが、文字通りお金に換えられる2つだけの本当のメトリクスなのです。
著者について
Sean McHugh氏は、Axosoftのスクラムマスタの1人です。McHugh氏は、アジャイル開発ツールのOnTimeの作成者です。初めてスクラムに取り組む顧客や、スクラムの経験はあるけれども、開発チームでスクラムプロジェクト管理ツールを使い始めようとしている顧客の手助けをしています。また、今までに、それぞれユニークな挑戦と解決策を持つ世界中のチームと働いてきました。McHugh氏は、自分の考えとスクラムコミュニティとの経験を自社のブログに書いて、共有しています。