処方する前に診断する

私はIT企業に所属していてお客様のセキュリティ改革をお手伝いさせて頂いています。お客様のお悩みを理解し解決する策をご提案して、その策の対価として月額Feeをお支払い頂くことに合意頂くことが基本的なミッションです。この記事はお客様にFeeをお支払い頂くことに合意頂くまでの最も重要なプロセスであるTechnical Discovery(診断)について、私個人の過去の失敗を交えながらまとめたものです。お気づきなどコメント欄に頂けると幸いです。

悩みの原因が何なのか理解しているお客様は稀

お客様はビジネスのプロでITテクノロジやサイバーセキュリティのプロではないので、自社のITにまつわる悩みの原因が何で解決するための策が何なのか理解できないことは自然かと思います。お客様といっしょになって、ITにまつわる悩みの原因を突き止める(ように務める)ことは、全てのITサービス提供者に求められるかと思います。

原因を理解していないと処方にならない

何となく当てずっぽうでSolutionを適用しても、たまたまそれがSolutionになることはあっても根本的な問題の解決にはならないと思います。当てずっぽうでSolutionを次から次へと投げられたお客様は、"何でこのSolutionを提案してくるのかなぁ。そもそもうちの悩みについて質問されていないんだけど。。。"となってフラストレーションが溜まってしまいます。お腹が痛い人にかぜ薬を処方しても腹痛は治りません。

質問を構造化して体系的に聴く

お客様とのミーティングの前にヒアリングできている情報や外部情報から、ミーティングで質問する内容を予め体系化して整理しておくことが肝要と思います。何も準備せずにミーティングに臨んでしまっては、その場で思いついた質問をただ断片的に聴くしかなく、質問されたお客様は"何を確かめたくてこんなこと聴いているのかぁ。。。"と不安感が募ってしまいます。

2次情報に騙されない

事前に他の人から聞いた内容や、お客様のWebサイトやITサービスの導入事例等は重要な情報ですが、あくまで2次情報のため参考程度に留めておくべきかと思います。誰がどうみても事実と言える財務情報やIR情報を確認してなるべく精度の高い仮説を立てる、立てた仮説が正しいか否かをお客様の脳に負担をかけずに質問できるように準備しておくことが重要です。

今から約15年前ぐらいだったかと記憶していますがとあるお客様との商談で、初回のミーティングの序盤数十分で聞いた内容をもとに、"お客様が探しているSolutionはxxですね。私共はxxのリーダー企業で他社ができないことを沢山持っています。是非ご提案させて下さい!"と言ってそのミーティングを終えました。以降、"デモ"と言う名の製品ツアーや"提案書"と言う名の製品紹介資料の説明を何回も延々と行って、最終的にお客様から、"この話は無かったことにして欲しい。何が本当に適切なSolutionなのかもう一回考えたい。そもそもxxさん(当時私が所属していた会社)に質問された覚えもないし。"と言われて商談が破断になったことがあります。この失敗は今も教訓にしています。