前回からちょっと時間が空いてしまいましたが、「顧客の望むものは何か？(1)」では、システム開発の現場における要件定義とはなかなかに難しいものであり、「顧客が本当に望んでいるものが何なのか」を把握し損ねて、 望むものではないものを作ってしまうケースがあるというご紹介でした。

今回はこの話を少し具体的に説明していこうと思います。「Project Cartoon」の図を参照しながら読み解いていきますが、まず初めに全体の絵を示します。

左上の絵は「顧客が説明した要件」。つまりこんなものが欲しいんだ！という意思表示です。
板とロープで作ったブランコが欲しいんだな、と理解できそうですが、この依頼…おかしくないですか？本当にこんなブランコが欲しいのでしょうか？
3枚も板があれば逆に座ることもままならないように思いませんか…？

そうなんです、実は顧客自身さえも本当に欲しいものが何なのかわかっていないというケースは実は大変多いのです。
スタートからしてピントがずれていますからシステム開発（要件定義）はうまく動き出しません。そしてシステム開発を始めるその出発点はビジネスの効率化や売り上げの拡大であったはずなのに、その目的も達成しきれなくなるリスクが生じてきます。

上段真ん中の絵は「プロジェクトリーダーの理解」を示す絵です。木にぶら下がったブランコが欲しい、というところまでは理解できても「3枚は不要なはずだ！」「枝1本では折れるリスクがある」という（適切な？）意訳を施せても独りよがりな振る舞いが、妥当な検証を阻みます。

次の絵は「アナリストの設計」と言われますが、ブランコが動かないことに気づいて改良されていますが、別な脆弱さが漂っています。

つづいて「プログラマの書いたプログラム」。
仕様書に書かれた、“木にブランコを括りつけて設置する”という仕様を満たしている…ということでしょうか。

「テスト担当者の検証」。
“木から垂れ下がるロープで、ゆらゆらとした挙動を楽しめること”というテスト実施要領は満たしているということなのでしょう。。。

「営業担当者の示した、顧客への報告」。
もう初めのころの面影はありません。過剰で、本質的でない、ビジネスに活かされるのかどうかなどまったくもって蚊帳の外の報告がなされます。

「プロジェクトに残された記録」。
面影はありますが、そこに何があったのか、どんなものが要求され、どんなものが構築されたのか、もはや知る由もない状態になっています。

「実際の運用」。
揺られて遊ぶことはできるという最低限の状態が構築（？）されたのです。

「プロジェクトの請求額」。
ブランコで遊びたいという欲求はいったいどれほどの費用をかけて満たされるのでしょうか？

顧客が本当に欲しかったものは何なのでしょう？前回示した「オレゴン大学の実験」でも書かれていた通り、この程度のものでよかったのです。

振返ると前回も書いた通り、お客様の本当に欲するところは周囲の誰も理解していないという事態を引き起こしていたのです。つまり（システムを作るときに限りませんが）自身が発注者であるならば、我々は今何を成すべきなのか？を問い直して誰かに依頼しなければなりませんし、自身がお客様の要望に応じていく立場ならば、本当にお客様が望んでいらっしゃることは何なのか？を熟考する必要があるということになるでしょう。

事業の本質は顧客の満足を引き出すことにあるのです。