従来の開発手法には、確かな評価指標があった。例えば、品質指標 (リリースごとの障害数など)、スケジュール指標 (実際の人日と見積の差、納品までのマイルストーンの達成度など)、コスト指標 (予算と実際のコスト) などである。
しかし、多くのアジャイル開発組織が、指標を収集したり、それらをプロジェクト全体に報告したりすることを苦手としていることはよく知られている。アジャイル開発組織は、チェックスタイルエラー、テストコードカバレッジ、NCSSなどの技術的な開発指標は持っているが、こうした指標は、顧客にとってはほとんど意味がない。
顧客視点での成功の測定が重要となってきている理由は、チームが正しいプロセスに従っているのにも関わらず、その結果が、顧客が求めるものと一致しないことがあるからである。実際に、大きくずれる場合もある。
Mike Dwyer氏は、次のように述べている(source)。
これは、外科医の場合の質問と同じです。すべてのステップを踏めば、適切な仕事をしていることになりますか？患者が回復するか、死亡するかは関係ないですか？私からの答えは、目的は何かという問いになります。患者の回復ですか、それともプロセスの成功ですか？
この例では、最終的な結果が、私達が論理的に期待しているとおりになった場合 (つまり、患者が回復した場合)、プロセスは成功であり、プロジェクト自体も成功だったと判断することになる。
Vikrama Dhiman氏は、別の例を挙げている(source)。
私のプロジェクトは、国際連合に販売するために、1000階建てのビルを建てることだとします。チーム自体はすばらしく機能し、私のビジョンを時間どおりに実現するのに有効です。しかし、国連はそれを買いません。私は、他の人に売るつもりはありません。プロジェクトがとったプロセスは成功でしょうか？私は、Yesと考えます。最終的な製品は、成功でしょうか？これは、Noです。ここで責任のあるのは誰でしょうか？もちろん、プロダクトオーナー (顧客側の責任者) です。
この場合、チームはすべてのプロセスを正しく実行したかもしれないが、おそらく、間違った製品を作り上げたのである。プロダクトオーナーは責められるべきだろうか？Yesである。チームは責められるべきだろうか？Yesである。顧客は満足しているだろうか？これは、完全にNoだ。
では、顧客はどのような方法でアジャイルプロジェクトの成功を測定できるだろうか？この答えは、上記のユーザの記述から明らかであるように、優れたプロセスを調べても見つからない。
一部では、顧客は、自分が満足すればそのアジャイルプロジェクトを成功だと判断するとも言われている。しかし「満足」を、定量化し、評価するのは難しい。アジャイルのインド(source)のユーザグループでの同様の議論では、顧客満足を測定するいくつかの主観的な指標が提案されている。顧客は、以下のようであれば満足している。
-
想定していた業務価値をプロジェクトから得た。
-
業務要求に従って方向性を変更したり、現状により適した機能を実現したりできるようになった。
-
フィードバックをすばやくできるようになった。
-
機能やストーリーの開発を優先できるようになったので、適切なときに、適切な機能を得られるようになった。
-
すべての機能が実装される前でも、残りの機能は使用することがないという理由で開発を停止できるようになった。
-
開発チームと双方向の信頼関係をうまく築き上げた。
-
プロジェクトの中で驚くようなことがなかった。
-
金額に見合う価値を得た。
この他には、チームがプロジェクトを開始する前に「完了」を定義しておくことが重要だという提言がある。顧客およびチームは、ストーリーがいつ「完了」するのかについて合意しておかなければならない。チームが、何を「完了」とするかを決定すれば、そこから顧客満足および残りの指標も導かれる。
Mike Dwyer氏は、次のように続けている(source)。
「完了」の定義では、単純に、スプリントの最後に顧客がチームの作業を受け入れることで、作業は「完了」となるとされています。この時点で、すべての労力および関連のコストが消耗から価値に変わります。これを利用すれば、いくつかの問いに答えることができます。例えば、「計画からどれくらいずれているか」(作業の一覧 – 受け入れられた作業の累積)、「予算はどのようになっているか」(計画されている総予算 – 実際のコスト) などの問いに答えられます。さらに、「どの程度効率的か」(実際の総コスト / 完了した作業の計画コスト)、「消費率はどれくらいか」(受け入れられた要素、または完了した要素の平均コスト) というような問いにも答えられます。
Scott Ambler氏(source)は、客観的指標と主観的指標(source)を組み合わせることを提案している。彼は、次のような基本的テータの収集から始めることをチームに勧めている。
- 実際のコスト (時間、費用 ...)
- 実現された機能性の何らかの一覧 (ユースケースポイント、ユーザストーリーポイント ...)
- 障害の傾向
- 関係者の満足度
チームは、ビジネス側とは、彼らが使用する言葉 (基本的には、金額とシステム機能) で話をしながら、一方で開発の成功に重要な意味を持つ品質などの指標も管理することができる。顧客満足度の指標は、チームがアジャイルであるかどうかに関わらず、導入すべき最も重要な指標の1つである。欠陥のないコードを納品しても、価値のあるコードを納品したことにならない場合もあるのだ。
基準には、顧客満足、顧客の考えのような主観的基準と、ストーリーの完了、コストと障害の傾向などの客観的基準の両方が存在するようであるが、これらは、アジャイルプロジェクトの成功を顧客視点で測定するのに有効になるだろう。
議論の結果としては、単に正しいプロセスに従うことが重要なわけではない、ということになるようだ。正しいプロセスだけでなく、プロジェクトの成功と顧客の満足を確認できる客観的チェックと主観的チェックが必要である。開発チームは、それぞれのシナリオに合わせて、最も意味のあるものだけを選択しても良いし、いくつかを組み合わせても良いだろう。
原文はこちらです：http://www.infoq.com/news/2008/02/agile-customer-success