顧客がほしがっていない製品や市場がない製品を作ってしまうのは無駄だ。アジャイルは効率的に製品を開発できるが、何をビルドするかは理解しておかなければならない。どのようにして顧客の製品に対するニーズを見つけることができるだろうか。
David Hussman氏はhow often are you wrongという記事を書き、開発するべき製品を知る上での不確実性について説明している。
正しい製品を開発していることをどのようにして確かめることができるでしょうか。次の投資として何が最適なのかどのように決めたらようでしょうか。その意思決定の妥当性はどのように検証すればいいでしょう。(…) 確信の要因と不安の要因はチームが価値提供の障害を取り除こうと懸命に働いているときに直面する領域についての思考と学習なのです。
Definition of Doneはチームがソフトウェアがリリースできる状態かどうかをチェックするのに役立つ。しかし、Definition of Doneは氏が説明するように、確実性に対して間違った感覚を与えてしまう可能性もある。
不幸なことに、製品は使われ始めたときに完成するのです。ユーザを見ることでチームは自分たちが確信していたことを理解できるのです。“私は顧客が何をほしがっているかわかっている…”というのはわかっていることにはなりません。それはひとりの人物の傲慢にすぎないのです。または、“優秀ではないプロダクトオーナ”が問題なのです。単に製品のアイディアが正しくマーケットが変わってしまったという場合もあるでしょう。傲慢さを除外し根拠を受け入れるということこそ、間違ったものを作らないようにする最高のツールなのです。
the problem with building products in an agile worldというブログ記事でPaul Young氏はプロダクトマネジメントの観点からアジャイルのいくつかの問題領域について書いている。アジャイルに顧客からのフィードバックを評価できるが、そのフィードバックはマーケットのニーズにあった正しい製品を開発していることを常に保証してくれるわけではない。
私の経験では、ほとんどのチームはコンスタントにフィードバックをくれるつもりの4人から5人の顧客とともに、残りのリリースや複数のリリースのために働きます。
同じ顧客からのフィードバックをもらうことには二重の問題が存在します。第一にその4人なり5人の顧客は本当にマーケットセグメント全体を代表しているのでしょうか。“20%のノイズ”を代表しているのではないでしょうか。私の経験では、定期ミーティングに参加してフィードバックを提供する意志のある顧客のタイプは平均的なユーザを表していないでしょう。そのような顧客はパワーユーザや専門家を代表しているのです。
次に、顧客は物が言えないわけではありません。4人なり5人の顧客が製品の方向に不釣り合いな量の影響を与えるようになるまでにそう時間はかかりません。そして、彼らのフィードバックが彼らの特殊なニーズのためのカスタマイズ開発に化けていることに気づくのです。これはマーケット駆動ではなく顧客駆動なのです。
また氏はプロダクトマネージャの役割を実装することで企業がマーケット駆動になることを妨げる可能性があると指摘する。
残念なことに、プロダクトオーナの役割は極端にやかましく戦略的でデイリースタンドアップ、スプリントの計画懐疑、振り返りで毎日開発者と大量のやりとりをしなければなりません。アジャイルチームを効率的にすることには何も失敗していなくても、アジャイルチームを効率的にすることに強迫観念を抱くあまり、本来プロダクトマネジメントがするべきことが犠牲にされ始めてしまうのです。つまり、マーケットに時間を使うということがないがしろにされるのです。
Paul氏はアジャイルの実践や儀式に注力しすぎることによって間違った製品が生まれてしまう可能性を指摘している。
アジャイルは素早く開発できることように開発者を支援します。しかし、始めから正しいものを作ることについては何も約束してくれません。それはプロダクトマネジメントの仕事なのです。私はアジャイルのたくらみに追い込まれてしまって、世界一効率的な企業になり得るのに、誰もほしがらない製品を作ってしまえば台無しだということを忘れてしまうのです。
Dr.Dobbに掲載されたScrum's flawed notion of product ownerという記事でAllen Holub氏はオンサイトの顧客を持つこととプロダクトオーナと働くことの違いを説明している。
スクラムの概念の中で気持ち悪いのはプロダクトオーナという概念、正確に言えば、オンサイトの顧客の不在です。プロダクトオーナの仕事は顧客の代理人とマーケティング部門、開発部門の代表を混ぜたものです。プロダクトオーナはプロダクトを"所有"しますが、それは、プロダクトのコンテンツ、ビジネスのストーリーの価値などについての意思決定ができるという意味です。
ほとんどのスクラムがXPから引き出されていますが、XPの場合はチームに新鮮で血の通った濃く開くが必要です。いったいどこからプロダクトオーナの概念が現れたのかよくわかりませんし、プロダクトオーナの概念が生み出すかもしれない被害にうろたえてしまうのです。
Allen氏はオンサイトの顧客ではなくプロダクトオーナを持つことは開発するべきプロダクトを効率的に知ることにはならない、という考えを支持する。
プロダクトオーナはプロダクトの実際のユーザではありません。それゆえ、デザイン上の問題に対して答えることはできません。事実よりも当て推量に頼ることになります。プロダクトオーナの示唆によって間違ったものを作ってしまうのです。回答を得るためにはプロダクトオーナは1日以上費やしてしまいます。そして開発者は1日(間違った示唆に従って動いてしまい、やり直しをしなければならなくなったとしたら1日以上)の仕事を失うのです。チームに顧客を招き入れる時間はありません。プロダクトオーナが顧客を代表していると間違った製品が生まれる確立が高まります。会社が傾くような失敗になってしまうかもしれません。
Joel Amoussou氏はbuilding business sustainabilityというブログ記事でリーンスタートアップがアジャイルの補完して開発するべき製品についての知識を増やしてくれると説明している。アジャイルはチームがソフトウェア開発に成功するのを支援するが、形式的なアプローチは最高の結果を生み出さない、と氏は言う。
(…) 町で一番のソフトウェア開発者を抱え、しっかり設計され、しっかりテストされたソフトバンクをスケジュール通りに予算内で開発することは市場での成功やビジネスの成長、持続性を保証しません。では何が足りないのでしょうか。どうすれば、アジャイルがユーザが買いたいと思う製品を開発することを保証できるでしょうか。どのようにすれば、ソフトウェアそのものと毎回のスプリントで一生懸命作った機能が必要なもので、お金をもらえて、ユーザに使われるかどうかを判断できるでしょうか。
アジャイルのプロジェクトが失敗する理由は間違った製品が開発されてしまうからだ。
問題は、プロダクトオーナもビジネスユーザも実際に自分でお金を使って製品を購入する人々ではないということです。プロダクトがマーケティングされ、自由に売られる場合にこのような状況になります。間違った設計、間違った製品開発は企業にとって大変な損失になります。結果、開発チームが実装したデザインや機能は単なる未検証の仮説や仮定にすぎないと(いわゆるエクスペリエンスの専門家やプロダクトビジョナリー)言われてしまいます。多くのアジャイルプロジェクトが壮大な実験プロジェクトになってしまうのは驚くべきことではありません。
リーンスタートアップの原則は顧客が必要とする製品の開発に必要な知識を増やしてくれる。
リーンスタートアップのレシピは初期段階で将来の製品の顧客と一緒にテストされたMinimum Viable Products (MVP)を開発します。MVPは素早いプロトタイピングと継続的デリバリを通じた反復的な機能開発によって実現されます。リーンを維持するためにPlatform as a Service (PaaS)のようなクラウド技術を活用します。MVPをテストするにはチーム(ソフトウェア開発者を含む)は席からはなれて濃く開くに向き合う必要があります。直接的なフィードバックと検証を得るためです。アナリティクス、A/Bテスト、エンドユーザによるユーザビリティのテストによってMVPをテストすることもできます。このような実験期間にはSystem Usability Scale (SUS)のようなメトリクスを収集するのがいいでしょう。