グループワークしていたら画期的なツールが生まれた。これって、そういうことですよね？素晴らしいです！こういうの、ほんと理想的です！！

インサイトとは「ジレンマ」を定義すること。すなわち、叶うことを望んでいることがあるのに、それが叶わない「実態」と「原因」を定めること。

叶えたいこと、それがゲイン。でもそれが叶わない実態、それがペイン。

いわゆる「ペイン」だけに囚われないほうがいい。なぜなら、それをやっても、プロセス全体に散在する局所的なペインをモグラ叩きにように際限なく潰し続けることに終始し、それは必ずしも、「長期的顧客関係性の構築」や「プレミアム対価の持続的獲得」に結びつくとは限らないから。

VOC(Voice of Customers)の取り扱いは要注意。顧客が実際に口にすることは「要望」の体は成しているが、それがなにより優先して満たすべきニーズとは限らない。口に出せば、そういう「ニーズらしき内容(Position)」なのであって、その背後には口ではうまく説明できない意図(Interest)が存在すると考えた方がいい。その要領は、ハーバード流交渉術で言うところの「Position」と「interest」の関係に相当。

それは、

好きな女の子に「ラーメンが食べたい」と言われて、美味しいラーメン屋をしこたま調べて、そこへ連れていく、ということと、

「なぜ、この子はよりによってラーメンを食べたいと言っているのか？普段はどういうデートをしていて、「ラーメンを食べたい」というのは、その深層で何を叶えたいと言っていることを意味するのか？」と考えて考えて、その上で、普段の贅沢なデートにちょっと飽き気味ゆえ、いつもと違う過ごし方をしたいということなのではないか？ならば！こんなのどうだ！？」という方策提案。

彼女からしたら、どちらがディライトをもたらす可能性があるか？という話に似てる（←えー－っと、、、引合いに出したたとえ話がなんともショボくてすみません。。汗汗）　PositionとInterestの違いを言いたかっただけなのですが、両者の違いは伝わりましたでしょうか？

要は

VOCを真に受けるんじゃない！ということです。洞察せんかいっ！ちゅーことです。

洞察するゆえ、大ハズレのリスクは、、そりゃま、あります。でもまあ、そのリスクを下げるために、対話を重ねてinterestの推察精度を高めることが賢明なわけですよね。それは、ほとんどすべての誰もが、青少年時代から日常生活で自ら経験してきたことのはずなんです。別にこれといってエキセントリックなことを言ってるわけではないです。

そして極め付けは、

以下にご紹介するフォーマットが、あのDo展開表パートも含む点です。

ということで、以下お付き合いくださいませ。

↓

↓

まず、以下のインサイト表現フォーマットが姿を現したのですが、これはまだ序の口でした。高速PDCAで試運転していたら、あれよあれよと短時間のうちに、ver2→ver3とフォーマット構成が進化して、あっという間にバージョンアップしました。今後もさらに更新されていくことでしょう。このあとの展開が楽しみです！

【Ver.1】

一番大事にしようとしたことは、「ゲイン」と「ペイン」の取り扱い方。顧客との対話において、先方が実際に口にしたことは「ニーズ」と決めつけるのではなく、あくまで口に出しただけの「Position」。そのPositionに関する現状をしっかり観察。前者を「Position」、後者を「Situation」と置けば、これら二つ合わせて「ファクツ・ファインディング」。ファクツファインディングはあくまで事実情報を単に集めただけのことなので、インサイト（洞察）でもなんでもない。単なる速記・転記にすぎない。「ヒヤリング内容≠インサイト」です。ヒヤリング内容はあくまで「ヒヤリング内容=ファクツ・ファインディング」。

そこで、ファクツファインディング情報をもとに、その背後にある「意図（Interest）」を推察。推察・・・そう、ここで初めて「インサイト(洞察)」です、これがハーバード流交渉術でいうところの「PositionとInterestの関係」。

次にペイン。ここで注意したいことは、「ゲイン抜きのペインのみ着目」にならぬようにすること。ゲインが何かというインサイト抜きに、単に「現行プロセスにおけるペインは何か？」という発想で臨むと、それを解決したところで、散発的ペインの解決に留まり、それはつまり、プロセスにおける部分最適を繰り返すだけ。ポイントは、「ゲインがそうだというなら、叶えりゃええやん。ところが、そう簡単には叶わないわけね？なるほど、、で、なんで叶わんの？ゲインを叶えたくても叶えることができていないのはなんで？」・・・・この答えをペインとして捉えてみたい。そうすることで、左記の「ゲイン」とペアにしたものが、「ジレンマ（Hope gain, but pain）」として定義されることになる。この要領は、結構画期的なんじゃないかしら。

それから、当初はペインの右列に「ハードあるいはソフトが担うべき機能」を置いていたのですが、ペインから直接的にそれを出そうとすると無理がありました。ワンクッション置きたい。ジレンマから、いきなり解決策アイディアを書くと、聞き手はその解決策アイデアの何がポイントなのかわかりづらい場合がある。論理の飛躍を感じずにいられない。そこで、解決策を考案するにあたり、「ジレンマを解決する上で与件は何か」「ジレンマに対し、どういう切り口からアプローチすることが肝要か」という、『方策立案上のポイント』を記述する列をワンクッションとして設けてみた。

↓

【ver.2】

上記Ver1を試してみたところ、「ペイン列」から「方策立案上のポイント列」を導くのはこれまた難しいことがわかった。「ペインの原因を記す列があったほうがいい」という声をふまえ、ペイン列の右に「原因」を設け、さらに、「原因がそういうことなら、では、何を達成すればよいか？」という目標設定列も設けよう。こうして「原因と目標」を記載する黄色ブロックが追加された。

↓

【ver.3】

ここでさらに問題が発生。それは、「ペイン列」の右に「原因列」を設けたが、「ペインを引き起こす原因」ということになってしまい、そうなると、その右の「目標列」は、「ペインの原因を解決すべく、何を達成すればよいか？」という問いの答えになり、せっかく定めたゲインをほっぽらかすことになりかねない。つまり、ゲインに何を書こうが、そんなことは関係なく、【ペイン→原因→目標設定】という流れになってしまい、ゲイン記載内容は蚊帳の外になるだろう。それは、「目標は達成されたのに、ゲインは未達」というワケのわからない本末転倒を招く。

解決策としては、「原因」は、「ペインを引き起こす原因」ではなく、「そのようなゲインを叶えたいのに、ペインに阻まれてしまう原因は何か」という問いのほうがよかろう。そうだとすると、原因列は、目標列とセットにして「インサイトのブロック」から独立させるのではなく、インサイトブロックの列に引っ越しさせたい。それが、以下のピンク色の３列表現。で、「ジレンマの原因（≠ペインの原因）を解決すべく何を達成すべきか？」という問いの答えを、目標として設定したい。目標の表現形式は「Do結果」であり、これがKPIである。

注目すべきは、「目標列」から「ハード・ソフトが担うべき機能列」のゾーン。これがDo典型表に相当する。Do展開は、要素の因数分解（ロジックツリー）ではない。演繹推論である。演繹推論にはルール（演繹推論ルール）が必要。この演繹推論ルールに相当するのが「方策立案上のポイント」。つまり、「(1)目標」と「(2)方策立案上のポイント」と「(3)ハード・ソフトが担うべき機能」の関係は、、、

(1)目標は、Do結果。それは、Do展開表の左端列に相当。

(3)は、自社Do。それは、Do展開表の右端列に相当。

Do展開表は、(1)と(3)の間を複数レイヤで順繰りと展開表現したものであるが、それをギュッと圧縮して、そのかわり、(3)を導く根拠となる演繹推論ルールとして、(2)方策立案上のポイントを記載したもの。

以上、インサイト表のフォーマットは、

大きく、「ファクツ・ファインディング領域」、「インサイト領域」、「Do展開領域」から３ゾーンから構成される。

ハーバード流交渉術でいうところの「Position」から「Interest」を導く過程は、「ファクツファインディング領域からインサイト領域への移行」という要領で表現する。

UXストーリーを描くポイントは、着目点がペインだけに偏らないこと。最も重要なことは、ペインの解決ではなく、ゲインを叶えること。ゲインを叶えたいのに、ペインに邪魔されていることが問題なのであり、くれぐれもペイン除去のみに囚われないこと。

Hope gain, But pain.

これがジレンマ。そして、「このジレンマはなぜ発生するのか？＝原因」「ジレンマ原因を解決すべく、何を達成すればいいのか？＝目標」という検討を経て、Do展開左端列（＝目標＝Do結果＝KPI）がセットされる。

あとは、これをDo展開して、ハード・ソフトが担うべき機能（自社Do＝要求品質）を導出すればいい。

かくして

ハード・ソフトは導かれるべくして導かれる。めでたしめでたし。

よっしゃ！

これを試してみよう！！

インサイトとは「ジレンマ」を定義すること。換言すると「ゲイン」と「ペイン」の組を定めること。