まずは「Want Can’tの問題」とはどのような問題であったか、下記の図で振り返ってみましょう。


　前回お話しした「Must Can’tの問題」とは異なり、「Want Can’tの問題」はいきなり案件化していくのが困難な問題です。そこで、下記のような段階を踏んでいく必要があります。


1．潜在需要に着目する

　まずは顧客の潜在需要に着目します。潜在需要とはまだ現実の需要とならずに、いわば隠れた状態で存在する需要のことです。顧客自身も気付いていない要望であるため、残念ながら顧客にヒアリングしても、聴き出すことはできません。有名な例を挙げましょう。

ソニーのウォークマン。ウォークマンが登場した1979年までは、音楽は家庭内のステレオシステムやカーオーディオで聞くのが当たり前でした。それがウォークマンの登場により、‘いつでも’‘どこでも’手軽に音楽を楽しめるようになりました。（「個人で音楽を楽しむ文化を創造した“ウォークマン”　本日誕生20周年」　1999年 7月 1日）

　ウォークマンは、「いつでもどこでも自分1人で好きな音楽を聞けるような機械が欲しい」という利用者の明確な要求に基づいて開発されたわけではありません。ウォークマンという存在を認識するまでは、誰もそのようなことができるとは思いもしませんでした。

　しかし、ウォークマンが登場する以前の段階から、「外でも音楽が聞けたらいいな」とか、「周りの人に音楽を聞かれたくないな」という要望は世界中の多くの人に存在していたはずです。このような要望が“潜在需要”です。ウォークマンがユーザーの“潜在需要”を「顕在化」したのです。

2．潜在需要を掘り起こす

　それでは、潜在需要を掘り起こすにはどのようなことを行えばよいのでしょうか。その有効な手法の1つに、「仮説―検証のサイクル」があります。ここでも一例を出しましょう。

　ニワトリのヒナのオスとメス。素人目にはほとんど性別を区別することができないそうです。しかし、将来「鶏肉」として売られるオスと「鶏卵」を産むメスとでは餌の与え方が異なるため、生まれたばかりのヒナの性別を区別する必要があります。

　皆さんがこの区別を依頼されたらどうするでしょうか。まずは、多くのヒナを観察して、何らかの特徴を認識しようとするでしょう。そして、最初は、当たっていても間違っていても、着目した特徴に基づいて、オスかメスかを判断します。これが仮説です。

　そして、皆さんの出した仮説が正しいかどうかを、ベテランの判断、成長後の識別、性別検査などで確かめます。これが検証です。検証の結果、皆さんの仮説が誤っていれば、判断の根拠を別のものに変えて、再度仮説と検証を行います。そして、この仮説と検証を何度も繰り返すうちに、高い精度で性別を区別することができるようになるでしょう。

　このように、「仮説―検証のサイクル」は、未知の問題に直面した際に、打開策を見出す有効なアプローチです。それでは、実際の運用現場における「仮説－検証のサイクル」の事例を見ていきましょう。まず、第一のステップとして、顧客に仮説をぶつけてみます。


　この提案では、外部システムと連携することでリアルタイムにデータを更新したいという潜在需要を仮説しています。たとえ、この仮説が的外れであったとしても、具体的な提案を受ける人（つまり顧客）から、何らかの意見を期待することができます。そこで、もし反応が悪かったり、反論されたりしても、軌道を修正し、再度ぶつけてみるという「仮説―検証のサイクル」を繰り返しが行えます。たとえば以下のとおりです。


　ここまでヒアリングすれば、さらなる仮説をぶつけることができます。


　この「仮説―検証のサイクル」の過程で、顧客の潜在需要は徐々に要望として健在化します。これでWantがMustになったわけではありませんが、顧客は、皆さんとのディスカッションを通じて、要望が具体的になり、顧客自身もぜひこれを実現したいというMust感を持つようになります。

3．潜在需要から案件に結びつける

　この「仮説―検証のサイクル」の考え方を用いた場合のメリットは「先駆者優位性」にあります。潜在需要の刺激の段階から顧客に入り込むことで、顧客がRFP（提案依頼書）を発行する段階には、いち早く実効性のある具体的な提案ができ、結果的に採用される可能性が高くなるのです。

　たとえ、技術的な実現可能性の検証が必要な場合でも、潜在需要の段階であれば顧客の警戒感は小さいため、「一緒に検討しませんか」という言葉は受け入れやすいでしょう。顧客との関係が既にある運用・保守の担当者の場合は、なおさら認められやすいと思われます。