私たちは、Problem-solvingの初期のステップとしてインタビューをすることが多いです。対象は社内外の様々なクライアントです。このステップで集めた情報の質は、その後建てる仮説の良し悪しを左右します。その意味では、インタビューをうまく行うスキルは、私たちProblem-solverにとって必須のものと言えると思います。
（もし、社内でのあなたの役割が、問題解決者（コンサルタント、経営企画、海外駐在員など）であるなら、問題解決をする上で”質の良い質問”をすることは必須です。さらに、”質の良い質問”をするためには、”質のよい仮説”が必要です。これら、「仮説→質問→問題解決」にご興味があれば、是非、このLinkをCheckしてみて下さい！）
まず、Interviewを３つのStepに分けて考えます。
あなたがProblem-solverとしてClientをInterviewする場合、これはかなりActive（能動的／前のめり）な行為です。これが、一般の会話での質問と最も大きく異なる部分です。一般の会話での質問は、Passive（受動的： 完全に聞き手になって相手が話したいことをはなさせる）でも全く問題ありません。なぜなら、“Socialization“が目的だからです。特に、初対面の場合、もしかしたらAnthropological（人類学的）な興味で会話する場合もあるかも知れないですね。
一方、Problem-solverがClientに質問する場合、文字通りProblem-solvingが目的なので（笑）、問題解決に役立てなくてはなりません。つまり、Interviewの現場に行ってから全くゼロの状態で質問するのは効率的ではありません。（←これは極端な例ですが！）あなたが予め準備したHypothesesをVerifyすることがConsultingにおけるInterviewの本質です。それは、質問することによって情報を集め、穴ぼこが空いている地図（問題解決のための解説図）をできるだけ完全なものにして行くプロセスです。そして、一旦、ある程度Usefulな（助けになりそうな）地図が出来上がったら、それを使って前に進みます。（プロジェクトを進めてClientの問題を解決をします。）そうです！Clientの問題を解決することが一義的な目的だということを、いつも頭においておく必要があります。（つまり、Interviewして答えをもらうこと自体が最終目的ではありません。）
もし“How to ask questions as a problem-solver”（Problem-solverの質問のしかた）についてご興味があれば、リンクをチェックしてみて下さい。
実は、インタビューは、実際にクライアントと話をする前から始まります！
というわけで、Pre-interviewのStageでは、あなた自身のHypothesesを組み立てましょう。もしあなたが比較的最近Problem-solverになったとしたら“仮説”と言われても、何を考えていいのかすぐにはひらめかないかも知れないですね。全く問題ありません。Trainingをすればいいだけですから。
ここで使えるのがProblem-solver formatです。非常に広く使えるProblem-solverの武器としては強力なものです。
詳細は他の機会（TiffanyのCaseなど）で説明することとしますが、要するにCause-Effectの関係を的確につかむということです。もう少し情報を加えます。Clientが持っている／陥っている①Problem、②Cause、③Solution（Problem-solvingのための最低限のFactors）をHypothesize（想定）してみましょう。
例えば、こんな具合にScenario（シナリオ）を考えます： ①Problem：駅の近くのスポーツシューズ店は収入が減っている、②Cause：アマゾンに客を取られている、③Solution：来年からWebマーケターを雇ってE-commerceも積極的に始めるらしい
もちろんこれは例として話を単純化しており現実の世界はもっと複雑です。また、上記の３つのElementsだけではなく、ビジネス環境、競合、二次的なProblem、Solution実施の際のPitfalls and obstaclesを考える必要もあります。
実際のInterviewでは、あなた自身の仮説をClientに質問しながら確認（Verify）します。次に、そのためのTechniquesをいくつかご紹介しましょう。
さて、いよいよ実際のインタビュー、開始です！
せっかく時間をかけた「しこみ」を十分に活用しましょう！
個々の“テクニック”について説明する前に、「これが無いとInterviewとしてなり立たない！」というポイントをご紹介したいと思います。Rapportを生む力は非常に重要です。辞書で調べると、Rapportは「調和した人間関係を築く」と説明してあります。ちょっとピンときませんが、“同調する”、“波長が合う”、“信頼に足る”、“心地よい関係”、辺りが直感的、右脳的なKeywordsだと思います。
「Build rapportのためには何をすれば良いのか？」を示しているのがこのListです。ただ、これはExhaustiveな（完璧な）Listではありません。なぜなら、私の経験則だからです！ただ、ある程度の実績のあるManagement consultantsの方々に伺っても同様のことをおっしゃるので、大きくはハズしていないと思います。（笑）
a) Problem-solverとして、このSkillはかなり重要です。これができないと、IntervieweesはいつまでもDefensive＝心を開いてくれないので、表面的な情報しか提供してくれません。せっかくの“一次情報を得る機会”、“そこでしか聞けない話を聞ける機会”、“ホンネを探れる機会”を無駄にしてしまいます。
b) ただ、生まれつきBuilding rapportがうまい人はないです。う～ん、やっぱり、いるかも知れません（笑）。ただ、「ConsultingのためのClient interviewにおいてBuilding rapportが生まれつきうまい人」はいないです。量の違いはありますが、やはり勘どころを理解した上でPracticeが必要です。
c) 「Building rapportのためには、信頼関係を築くのと同じことだ！」その通りです。では、そのためには具体的に何をすれば良いでしょうか。一つのFirst stepは、心理的なConnectionを作ること、そしてそのためには・・・
d) ・・・authenticでいること。Authenticは、「本物の、正真正銘の、偽物でない」と説明されます。つまり、Intervieweesが、ちょっとでも“ウソっぽさ／ウサン臭さ”を感じたら終わりです。例えば、すぐにバレるようなウソをつく、安っぽいハッタリを使う、心にもないようなこと美辞を言う、知らないのに知っているフリをする、など。悪気があるか無いかは関係ありません。Clientsは私たちが考える以上に敏感です。
e) 時として私たち（自戒！）が取ってしまう態度、その中にarrogantがあります。「これまで数々の企業のConsultingをやってきたから、自分はたっぷり経験がある。だから、私の言うことを聞け！」という意識です。それは、心の奥底の小さなつぶやきとしてのみ存在する場合もあるし、Clientに伝わるほど明確に態度に現れる場合もあります。どちらであってもアウト！です。そんな人を信頼できるわけはありません。
f) 相手に心を開かせる一つの方法として、「自分について話す」があります。もちろん、自分の経歴を自慢することではありません。どちらかと言うと、自分の弱い／至らないところを例に出すという感じです。あるいは、比較的個人的な話を挿入します。日本では、「公私を分ける」ことがNorm（一般的）なようですが、InterviewはもうちょっとPrivate感を出した方がうまく行く場合多いと感じます。
ちょっと余談的になりますが、こうしてListを眺めると、私たちがお医者さんに接する時の気持ちと似ていますね？
“穴ぼこだらけの地図”（あなたが前もって立てた仮説）の上を行ったり来たりしながら、その内容の確かさを確認します。まずは、Interviewの中でも、最も基本的な動きをClientにしてもらうための質問です。言ってみれば、Basic navigation questionsです。
まずは、前に進んでもらう。“So…?”は、「それで・・・」のようなニュアンスです。もっと分かりやすく、“Then….?“という言い方でもOKです。前者は、話を論理的に前に進める感覚、後者は、時間的に前に進める感覚です。Thenを使った例を見て下さい：
クライアント: I know fatigue made him slothful, but I couldn’t stand his attitude…. （疲れていてなまけていたんだとは思うんだが、あいつの態度には我慢がならなかった） You: Then, you did….? （で・・・その後どうしたんですか？）
それでは、逆に、クライアントが先走ってしまい話を引き戻したいときには何と言いましょうか？
例えば、Wait a minuteと言って、一旦話を止めます。その後、あなたの意図によって異なる表現を使います。単にRewindしたいなら、”Let’s back up a little bit”でいいです。もちろん繰り返して欲しければ、Can you repeat that again?です、が、きっと同じことを同じよう表現で繰り返すので、もし、「さっき言ったことと矛盾してませんか？」のように、論理上の話のつながりを指摘をする場合には、”Earlier you said… but now you say…”のような表現も使えます。但し、このような指摘を仏頂面で行うとOffensiveになるので（まあ、日本語でもそうですね！）、amicable（好かれるような）表情の方をして言ってみましょう！（笑）
では、話が抽象的過ぎる場合はどうしましょうか？そうです！率直に、”For example…?”です。
反対に、例をたくさん出してくるけれど、究極的にには何を言いたいのか分かりにくい場合はどうしましょう？そうです！あまり難しく考えなくて大丈夫です。”What do you mean by that?”「結局、どういうこと？／何が言いたいの？」と言えばいいです。日本語を直訳すると”What is your point?”となりますが、ものすごく気を付けたDelivery（表情、イントネーションなどを含んだ伝え方）をしない限り、「結局、ナニィ？！」という半ばケンカをうるような（little too harsh）（笑）ニュアンスで伝わることが多いので、あまりお勧めできません。（学生同士がディベートで良く使います。”So what?”も要注意です！）
最後に、全体に関することです。ちょっとしたコツなんですが、Navigation questionsとは言うものの、本格的な（学校で習うような）（Full sentenceの）「疑問文」（例：”What did you do after you shut down your department?”）である必要はありません。わざと”Then, you did…..?”のように「ト書き」のような数語を挿入することもあります。これは、話の流れの中にその一部として入り込むことで、相手の話の流れをさえぎらずに済むため、相手を話しやすくする意図があります。 「相手にどれだけ多く自分が聞きたい分野のことを話させるか」がインタビューの究極の目的ですね。
クライアントにもう少し深く考えて欲しいときには、どうすれば良いでしょうか？
一つ目のSituationは、クライアントがあまりに現実的過ぎて、アイデアを口から出す前に否定してしまうセルフ・ブレーキ（注意！和製英語 笑）タイプ。制約条件を取っ払って上げるといいですね。そんなときは、What if?という表現が便利です。”What if there is no constraint? What if you have all the resources you need? What would you do?”・・・という具合です。
クライアントとWorkshop形式で事業計画を立てる場合を想定してみます。きっと３Cなどを使うかも知れません。クライアントの経営者などに競合について聞くと、「う～ん。他社のことは分からないなぁ・・・」なんておっしゃる方もいらっしゃいます。ただ、実際にはExecutiveなら競合や業界のTrendに関して何のIdeaも持っていないことはまずありません。これもセルフ・ブレーキタイプというか、とても真面目な方で、「経営者たるもの、間違ったことを言うのは恥ずかしい」と思っている場合もあります。そんなときは、”You are right. I agree it’s very difficult to be 100% right about your competitors’ moves”などと前置きした後、”Ok. So if you were in their shoes, what actions would you take?”などと、“無責任なこと”を言えるシチュエーションを作って上げると彼らが口を開きやすいかも知れません。
採れるアクションのアイデアを出して行くときの表現です。そのまんまですが、”What alternative actions / solutions would you take?”となります。このWouldが微妙なニュアンス（もし、例えば、ちなみに）を出していますね！
ここまで現状について話して来たので、Next stepについては比較的容易に話が出てくると思います。
これは一般的なTechniqueで私が良く使うものです。簡単な割には（笑）非常にどこでもいつでも使いデがあります！”Let’s brainstorm little bit here”「ちょっとブレスト的に話したいんですが・・・」と前置きするのです。例えば、クライアントの比較的年配の幹部社員が、”Retail is dying. Maybe we got to shut down the shop and move it to online. But we have no clue how to start…”などと口走るとします。この発言自体、その通りなのですが、これに対してうなづいてばかりでは、私たちProblem-solverとしての名が廃ります。そこで、”Right. It’s the e-commerce giant that’s eating everybody’s lunch.”などと同情した(sympathize)した後、例えば、このように言うのはどうでしょうか？”Ok. So, why don’t we spend the next 10 min for brainstorming what we can do about the current situation. Let us all bring some ideas to the table.” きっと、「何を言ってもいいんだ」という気持ちになって、CreativeなIdeaも出てくるかも知れません！
最後に、ちょっと難易度の高いTechniqueをご紹介します。ただ、うまく行くと非常に効果が高いです。相手の思考も広がるし、そのため、多くのケースではクライアントの信頼を得ることができると思います。その方法は、「反論」です。クライアントに自分の考えを見直す機会を与えることが目的です。もちろん、反論すること自体が目的ではありません。彼／彼女が自分では考えてもみなかった方向の考えに目を向けさせること（揺さぶる）が目的なので、「反論」あるいはそれに近い形（代替案を提示する）を採ることが多くなります。
例えば、ガバナンス体制、役員報酬について論議している際、クライアントが「うちの役員の給与は、ベンチマーク結果よりも低いから上げるべきだ」と言ったとします。もちろん、それは間違いではありません。ただ、これでは「ベンチマークデータに振り回されている」ことになります。ベンチマークデータは（他のデータと同じ様に）、情報の収集結果でしかありません。戦略性も論理性も含んでいません。ですので、このクライアントのように盲目的にベンチマークに従って施策を講じ続ければ、やがてつじつまが合わない産物（product）が出来上がってしまうでしょう。この場合は、「ベンチマークの使用をもう少し控えましょう。なぜなら・・・」という言い方になるかも知れません。目的は、クライアントが一人で考えても出て来ない方向に思考を（一次的に）向けさせることですが、現時点でのクライアントの思考とは完全に一致しないたため、相手によっては、これを「反論」と感じる場合も多くあります。
このTechniqueを使う際留意して頂きたい重要なポイントがあります。反論をする場合、あなたは自分自身の確固とした仮説あるいはシナリオを持っていることが必須です。インタビューの前に十分自分の頭で考え、「もう考えていない点は残っていいない」と言えるくらい広く、深く考えておく必要があります。なぜなら、こちらから「反論」しておいて、その根拠や合理性についてクライアントが納得するまで答えられなければ、完全に信頼を失ってしまうからです。それではProblem-solverとしては、ちょっと心もとないかも知れません。
前のセクションで、セルフブレーキをかけてしまう人のために、Think ahead questionsをご紹介しました。ただ、これらのQuestionsを使ってもImaginationが動きにくい方々もいらっしゃいます。どうしましょうか？ずばり、Storificationです！・・・と言っても、意味不明だと思います。なぜなら、多くの英和辞書には載っていない単語だからです。その時点までに伺った話をこちらがドラマ仕立てにしてFeed backし、その中でRe-liveして頂こうとする方法です。
例えば、先ほど出て来たこんなセリフ：”Retail is dying. Maybe we got to shut down our shop and move it to online. But we have no clue how to start…”を思い出してみて下さい。このまま尻つぼみ思考にはまっていては、本当にDead-end（イッカンの終わり）になってしまいそうです。そこで、その時点までに聞いた話をまるで映画でも見るようにVivid（鮮明に、リアルに）話し返します。そして、彼／彼女はそのドラマをRe-live（再体験）するわけです。そして・・・「きっと、失敗も成功もたくさんあった。でも、会社が今日までやってこれたのは、苦労しながらも競合より良い製品を生み続けお客様に信頼され続けたからだ。これまで２０年もそうやって幾多の困難を乗り越えてこれたのに、今回の戦いに負けるハズがない・・・」こんなState of mindに到達してくれたら、ここから先のActionsも自然と見えてきて、語り始めてくれるかも知れません。
このようにしてクライアントは自分のこれまでの経験を映画を見るように客観的に見直すことで、視点が変わったり、それまでには思いつかななったアイデアが生まれたりすることもあります。また、場合によっては、彼／彼女の精神にも影響しやる気を出して頂けるケースもあります。（この効果は、上記の“再体験効果“や、“打ち明け効果”によるところもあると思います。クライアントインタビューの経験のあるProblem-solverのあなたは思い当たるかも知れませんね。
あなた自身もインタビューを受けたとき、「どう思いますか？」と聞かれて答えに困ったことはないですか？経営者が皆Eloquent（饒舌）であるはずがないし、トピックによっては話にくいこともあるだろうし・・・反対に、話し手が持論をどんどん話そうと意気込んでいるのに、Yes/No questionでDemotivateするのも避けたいです。また、Yes/No questionsはクライアントの答えを引き出しやすい一方、あまり矢継ぎ早にやると尋問（Interrogation）のようになってしまったり、Leading question（誘導）のようにもなりえるので注意が必要です。というわけで、相手の口の開き方に合わせて質問の方法／難易度を変えることが必要です。
総じて言えば、できるだけOpen question（WhyとかWhat）を使ってInterviewを進められると理想的です。クライアントがこのタイプの質問に答えにくそうに見えたときだけ、助け舟的にYes/No questionを使うと理想的です。また、YesかNoかの返事によってその後の施策が大きく左右される場合には、Wh questionsでFollowし、しっかりと根拠や意思を確認すべきです。
特にProblem-solvingが目的である場合、Why questionは非常に重要です。なぜなら、Cause-effectをつかむ直接的な鍵になりえるからです。日常では、日本では（アメリカと比べて）「なぜですか？」が使われる頻度が低いように感じますが、プロジェクトのインタビューなので納得が行くまで（仮説の検証が十分できるまで）Why questionを使いましょう。もちろん、Yes/No questionと同様、あまり立て続けに使い過ぎると単なるRhetorical question（形の上では質問文だが意図は否定するニュアンス）と取られかねないのでここでも注意が必要です。
一見すると、Open questionの方がこちら（Interviewer）にとって“楽”に見えますが、ツールが異なるだけで、実はどのタイプの質問もこちらにとっての負担は同じかも知れません。ほとんどどんな質問をする場合も、こちらで仮説を持って臨むことが必要だからです。
クライアントが高い離職率（Attrition rate）について嘆いていたら、“Oh, my god!”と、真剣な顔をして言ってみましょう。 相手から見れば、あなたの方がInterviewにEngageしているように見えます。ただ、これは“相互作用“で、あなたがEngageしていれば、相手もEngageしやすくなります。わざわざ私がここで改めて取り上げなくともあなたはほぼ毎日経験していることでしょう。例えば、ボーイフレンドに、今日会社であったイヤな経験を話しても上の空。部下に、あなたがヒラだった頃の苦労を話しても「すごいですねぇ」とテキトーに表面的な相槌。これでは、その先を続ける気力を失ってしまいますよね。
Problem-solverとしてのあなたの仕事は、相手から本心を聞き出すこと。このPPTの最初で説明したように、もちろんあなたは十分時間をかけて仮説を立てて来ていることが前提です。ただ、どんなケースであっても、クライアントがあなたを信頼し、できる限り多くの有用な情報を提供してくれた方がプロジェクトとして成功する確率は高いです。
Show emotionの場合、大抵は相手の言っていることに賛同する場合が多いです。ただ、こればかりをやっていると受け答えが薄っぺらくなるので、”Disagree”のTechniqueを適度に併せて使うことをお勧めします。
インタビューが終わりに近づいています。この時点では、きっとあなたの手元に残っているのは、自分でも読めないような達筆で書きなぐってあるメモでしょう。少なくとも私の場合は、そういう惨事が多いです。（笑）
さて、欲しい情報を全て手に入れたかどうかを確かめるにはどうすればよいでしょうか。そうです！一つの方法として、昔懐かしい５W2Hを使いましょう。これだけのパーツが揃っていれば、とりあえずは「誰が、いつ、どこで、何をした・・・」くらいのBasicなストーリーは語れます。
さて、それだけでは単なる国語の問題。次の確認方法がProblem-solverをProblem-solverとします。そうです！Problem-solvingの全てのパーツが揃っているかを確かめましょう。これは、あなたが事前に構築したHypothetical storyをベースにすればいいですね。つまり、どんなProblemがあって、それはどんな（Business）環境の下、どんなCauseによって起こされたのか？そして、Clientは、本来どんなTo be stateとなりたかったのか？さらに、上記のCauseに対してClientはどんなSolutionを打ったのか？それはなぜうまく行かなかったのか？（うまく行かなかったからこそ、Problem-solverであるあなたを呼んだのだと思います・・・）もしかしたら、Problemから派生した2ndary Problemもあったかも知れないですね。このようにして、国語的な見地とProblem-solving的な立場から、入手した情報の量と質をReviewしてみましょう。
話を聞き終わった後は・・・
さて、やっとInterviewが終わりました。おおよそ、自分の仮説を検証するだけの情報を得ることができました。ただ、聞き逃しがあるかも知れません。また、クライアントは、後になって言い残した答えを思いつくかも知れません。そういった場合に“取りこぼし”がないように、Follow-upのコメントをしてWrap upするようにしましょう。こちらにとっても、先方に取っても利があります。
まとめ
インタビューを成功裏に実施するためには、ArtとScienceをちょうどいい割合で混ぜて使うことをお勧めします。
Problem-solvingに関する他の活動同様、Prepは非常に重要です。主には、仮説を作っておくStageです。
仮説検証、情報収集のための重要な機会であるインタビューですが、インタビュィーがどれくらい状況を客観的に把握しているか、どれくらいEloquentかなどを考慮しながらツール（質問の形）を選ぶ必要があります。
また、インタビュィーには（当然ですが！）感情があるので、話しやすい“気持ち”になってもらうことも大切です。ここは、Logicalityだけでは解決できないです！（笑）
そして、時には、“反論”などのTechniqueを使い相手を揺さぶります。インタビュー前には相手が考えていなかった発想に至ってもらえれば、私たちProblem-solverの価値も認めてもらえると思います。
ご質問やコメントなど、お持ちでしたらどうぞお気軽に！