それでいくら儲けるの？ 狩野分析法だけではうまくいかないよ

狩野分析法の記事はCertified Scrum Product Owner Trainingで一番印象に残った要件分類手法だったので真っ先に書いてみたが、あれほどの反響があるとは...

ブックマークのコメントを見ても「使えそう」という声が多い。

でも、「狩野分析法」は利用者の声をもとに要件（フィーチャ）の優先度をつけるのには役立つかもしれないが、それだけでAgile開発につなげるのは正解とはいえない。利用者が要求するフィーチャ＝事業として儲かるフィーチャ、とは限らないからだ。

基本は「そのフィーチャでいくら儲けるのか」「そのフィーチャ開発にいくらかかるのか」の分析であろう。

それでいくら儲けるの？

フィーチャ毎に「それでいくら儲けるのか」を考える。

簡単なようで、難しい。

自分がお世話になっている日本の某お客さんのところでは以前から実行している。経営層の人が「この要件を書いたのは誰？　お、○○さん？　で、これでいくら儲けるの？」と一件一件「詰めて」いくのである。答えられなければ、その要件はボツ。開発対象には残らない。すごいときは開発案件が丸々消えてしまうこともある。

でも、この「ふるい」ってお客さんにとっても重要だと思う。「ふるい」をかけることで初めて、システムを投資としてまじめに考えることができる。「ふるい」のない要件聴取なんてのは、現場部門のご機嫌取りにもならない。使えない・必要のないシステムが出来上がって、現場部門とシステム部門の間に埋めようのない溝が広がっていくだけだ。

そのフィーチャ開発にいくらかかるの？

こちらはSCRUM見積もり技術が活きる過程である。SCRUM見積もりについては参考書やWebサイトでの解説がいろいろあるはず。なので、ここでは略。適当にぐぐってみる。

あとは収益（いくらかけて開発し、いくら儲けるか）を基準に開発優先度を決めて行き、迷うようなら狩野法を併用するというのが現実的であろう。

どうでも良いこと

本当に良心的なSI屋なら、上記「ふるい」かけを手伝ってあげるべきなんだろうけどね。それで目先の開発量（すなわち売上げ）は減るかもしれないけれど、使われないシステム・役に立たないシステムを作るのって、開発担当からするとすごく虚しいのだよ。