顧客の要求を聞くと、システム開発は失敗するってこと・・・

　いま、ハーバードビジネスレビューの２００２年５月号１３５ページからの
「真の顧客ニーズを製品開発に結びつける法」を見ていたんだけど、

そこに書かれているのは、

・顧客は、製品ソリューションを持っていない。なぜなら、

　　　・顧客は自分が経験したことしか知らない
　　　　　→新しいテクノロジーなど自分が知らないことまで考慮できない
　　　・顧客の要望を鵜呑みにしすぎると、単に
　　　　　　追随製品を作成して終わる結果になる
　　　・先進ユーザーの勧めに従って誕生した商品は、アピール力に限界
　　　　　→新しく改良された特徴や機能を、実は顧客は望んでいない

・つまり、「顧客は自分が何を望んでいるか、本当はわかっていない」

ってことで、だから、顧客に要望をきいてはいけず、アウトカム（どうなっていれば良いという
結果）を聞くべきだとある。その聞き方は５ステップで、

●１ステップ：アウトカム中心の顧客インタビューを計画

　・製品・サービスに関連する根本的なプロセスや作業を

　　分解して、各ステップに落とし込む

　

　・どの顧客にインタビューするかを慎重に選択する

　



●２ステップ：インタビュー

　→望ましいアウトカムを得るには、

　　　アウトカムとソリューションが区別でき

　　　あいまいな発言やエピソード、無関係なコメントを取り除ける

　　モデレーターが必要

　→顧客がソリューションめいたものを思いついたときは、モデレーターは

　　必ず質問して、その基になるプロセスについて考えさせる。

　→ぼんやりと表現、形容詞を並び立てる

　　　→アウトカムを引き出す出発点

　→当て推量の部分を取り去るために、参加者と合同で確認作業



●３ステップ：アウトカムを系統だててまとめる

　→アウトカムをプロセスの各ステップに対応するカテゴリーに分ける



●４ステップ：重要性と満足度でアウトカムを点数化する

　・定量調査を実施し、別の種類の顧客にそのアウトカムが本当に望ましい

　　ものであるかを評価



●５ステップ：アウトカムを使ってイノベーションを推進する

だそうな

---

ということは、同じ理屈で、ユーザーに要求を聞きに行っても、彼等は、
技術を知らないし、ヒアリングにいった人以外の人は、望んでいないような
ことをいうかもしれない。ユーザーは、本当は自分が何を望んでいるか判らない
ということになる。

そんな要求を基に開発してしまっては、システム開発は失敗してしまうだろう・・


そこで、ヒアリングを実施して、要求を得る場合は、

・まず、ざっくりとユースケースをわけ、そのユースケースにかかわる

　アクター(そのユースケース実施にかかわる人）に対してヒアリング

　をかけ、



・どうなればいいのかのアウトカム(状態）を聞き出し



・そのアウトカムをユースケースに分けて書き出し



・その内容が正しいか、優先順位としてどうなのかをオーナー

　（本当はそのユースケースの所有者という意味。便宜的に

　　アクターに指示を出す人、上司などと考えてもさほど問題ない）

　に確認する



・その結果をもとに、アウトカムをまとめ、要求を抽出する

ということになる。つまり、顧客に要求を聞いてはいけないことになる。

これは、ゴール指向分析などで、ゴールは、状態（何々に「なっている」）
という話に通じていて、妥当性を持っているように思う。