私たちProblem-solverにとって、Client interviewはProblem-solvingのための情報を集める非常に貴重で重要な機会です。その後のProjectの成功を左右します。
もちろん、このことは社外のConsultantsだけではなく、社内のProblem-solverにとっても同じです。
そいうわけで、今回は、In client interviews, how do we ask good questionsを考えたいと思います。
このコンテンツに関連するものとして、「Client interview全般のプロセス」や「英語での雑談」について解説したものがあります。このコンテンツの最後の方にLinkがあります。是非、チェックしてみて下さい。
こんにちは！
ちょっと唐突なんですが、こんなとき（↓）Problem-solverとして、あなたならどうしますか？
あるファッション・ブランドのCEO (Founder) があなたに電話をかけてきました。何か困っているようです。相当悩んでいるのに相談できる人がいないので、ちょっと頭がオーバーヒートしてしまっているようです・・・（あなたがこの方と話をするのは初めてです）
“Hello… Oh, my God, our brand is finally over! We are one of the best-known brands in the US fashion industry. But we have been struggling in this market for the past few years. Customers stopped coming though our competitors are doing well. This kind of thing has never happened before. I don’t know what to do. How can you help us?”
というわけです。その後、続けて話を聞いていると、気になっているいろいろなことについて口走ります。
“New factories in China, competitors, brand history, past strategy, hiring policy, declining sales, declining profit, recent recession, demographic shift, overseas partners, suppliers, etc.”
結局、「明日、MexicoからNYに戻るので、その時に改めてあなたとまた話したい」そうです。ただ、”I’m very sorry, but I got to take a red eye to LA that evening, so we have about half an hour.”だそうです。
ずいぶん勝手なことを言うCEOですが（笑）、さて、どんな準備をしましょうか？
この例に限らず、Executiveの方々はかなりお忙しいので、重要なのは、Interviewでは的を得た質問をしかも効率的にすることです。それができないと、私たちは必要な情報を入手できないだけではなく、Clientは、”１時間以上も使って一体何を聞きたかったんだ？”とFrustrationを貯めてしまいます。当然、このような始まり方をしたProjectは先が思いやられます（I feel something ominous will happen…）・・・（涙）
さて、Problem-solverとして、Good questions、つまり”的を得た質問”を”効率的に”して、必要な情報を入手するにはどうすればよいのでしょうか？
ちょっとここで確認です！冒頭のApparel makerのCEOのCaseであなたが準備するのは（もちろん！）Confirmatory questionsです。
Confirmatory questionsとは何か？読んで字のごとく、Confirmatory questionsとは”確認のための質問”です。何を確認するのかと言えば、（あなたが）取り組もうとしているProblemに関して持っている仮説などについて確認します。他の表現をすれば、”Verification of assumptions”、”Hypothesis testing”です。つまり、Client interviewでConfirmatory questionをするということは、Verify your assumptions / hypotheses about the problemをするということです。
（そうです。Exploratory questionsで得られる種類の情報なら、WebsiteやPublic informationからでも十分入手することが可能そうですね・・・）
Confirmatory questionsとExploratory questionsの違いについてご興味があれば、、このLinkをCheckしてみて下さい！例を挙げて詳しく説明しています。
ここで改めて、“なぜAsk good questionsをする必要があるのか”と、”Ask good questionsとAssumption / hypothesisがどんな関係にあるか“を確認しておきましょう・・・
- Client interviewで意味のある答えをしてもらう必要がある＝役に立つ情報を入手する必要がある
そのためには・・・
- 的を得た質問を効率的にしなくてはならない
そのためには・・・
- 質の良いAssumption / hypothesisを考えておく必要がある！
違う言い方をすると：：：
- 質の良いAssumption / hypothesisを考えておけば
↓
- 的を得た質問を効率的にすることができる
- 的を得た質問を効率的にできれば
↓
- Client interviewで意味のある答えをしてもらう必要がある＝役に立つ情報を入手する必要がある
ということになります！
それでは、さっそくGood assumptions / hypothesesを考えてみましょう！
・・・と言いたいところですが、一旦これを考え出すと、かなりDeepな思考の海にどっぷり浸かり（fall down the rabbit hole）しばらく戻ってこられないことになるので（笑）、その前に、「Hypothesisとは何か（定義）」について念のため確認しておきましょう。（もしかしたら、既にあたなはご存知かも知れないんですが、ちょっとだけお付き合い下さい）
”Hypothesis”（仮説）という言葉は、多くのビジネス本で使われていて馴染みがあり、私たちProblem-solverにとってはEveryday termの一つとなっています。ただ、その意味は多様な解釈をされています。
Hypothesisは、Guessに他ならないです。ただ、Baseless（無根拠）なWild guessではありません。いくらかのInformationがあった上でAssumeしています。つまり、端的には、HypothesisはInformed guessあるいは、Educated guessです。
ここで２つの示唆（Implications）があります。
1つは、HypothesisはGuessなので、唯一の”正解”は存在しないということです。
では、正しいHypothesize / assumeとはどんな方法なのか？
その答えが、もう一つの示唆です。それは、Reasonableであることです。そして、ReasonableにAssumeするための確立された方法論があります。Inductive reasoning（帰納法）とDeductive reasoning（演繹法）、そしてAbductive reasoning（アブダクション≒推論）です。
３つのReasoningの詳細についてご興味があれば、このLinkをCheckしてみて下さい。例を挙げて説明しています。
ここで、Consulting projectにおけるAssumptionとHypothesisに関してもう少しイメージを膨らませてみましょう！
Assumptions / Hypothesisは、”Indiana Jones”のMapに似ています。（ちょっとWildな例えかも知れませんが、ガマンして読んでみて下さい！笑）
映画”Indiana Jones”をご存知ですか？Dr. Henry Walton “Indiana” Jones, Jr.というA professor of archaeologyが、未知の場所を冒険するアドベンチャー映画シリーズ（Franchise）です！
Indiana Jonesが行くような場所の地図は市販されていません。地図が売っていないなら、取りあえずはGoogleなどを使って（当時は無かったかも！）、断片的な情報でもいいので仕入れてお手製の地図を作ってみます。出発前にできる限りのリサーチをして精度を高めておきます。１００％完全にはできないことは分かっています。でも、無いよりはマシです。
そして、目的の場所に近づいたら現地の人に話を聞いたり、歩き回ったりしながら地図を加筆、修正してUpdateします。もし、チームメンバーがいれば、貴重な彼らの知恵や知識も地図上に加えて行きます。そして、またちょっと進んではまた修正を繰り返します。次第にその地域の全貌がはっきり見えてきます。そうすると、例えば、危ないTribeが住む地域や落ちたら一巻の終わりという谷を避けることができます。これで秘宝にた無事どり着く確率が高まります。
どうですか？Indiana JonesのMapと、私たちProblem-solverのGood assumptions / hypothesesとは似ていませんか？
ちょっと“おまけ情報”です・・・
おそらく、あなたは気づかれたかも知れないですね。実は、ちょっと前に出て来たExploratoryやConfirmatoryという単語、他の分野でも盛んに使われます。そうです。Scienceなどの分野です。元々は、AristotleやBaconなどが使っていました。現代ではMarketing researchなどでも使われますね。
Indiana JonesのMapみたいなものだとお伝えしましたが、実は、Hypothesis自体は特別なものではなく、私たちも日常的によく使っています。
２つの例をご紹介しましょう！
例えば、お母さん／お父さんが家族のために夕飯を準備するときにAssumption / hypothesisを使います・・・
＜Observationで情報を得る＞
- 年末に入って、配偶者も子供たちも忘年会やホリデーパーティーが続き、外食でGreasy（脂っこい）なものを食べる機会が多いようだ
＜その時（までに）持っている知識＞
- 配偶者も子供たちも麺類が好きだ
＜Assumption＞
- だから、きっと、家で食事するときくらいは、あっさりした麺類などが食べたいだろう
＜Verification of assumption＞
- 夕方帰宅した家族に聞いてみると、まさに「蕎麦が食べたい」と！
＜Solution/Conclusion＞
- 夕食はみんなでざる蕎麦を楽しむことに！
一歩外に出ても、Hypothesisはこんなところで使われています・・・
例えば、お腹が痛いので近所の病院に行きます。そこでは、医師がAssumption / hypothesisを使っています・・・
＜Observationで情報を得る＞
- 診察室に入ってイスに座ると、Medical doctorはいくつかの質問をします：「痛みは、いつから始まりましたか？」、「どれくらい痛いですか？」、「どんな痛みですか？」、「お腹のどの部分が特に痛いですか？」、「体の中で他に具合の悪いところはありますか？」、「食欲はどうですか？」、「これまで大きな病気をしたことはありますか？」、「ご家族で大きな病気をした方はいらっしゃいますか？」。
- そんな質問をしながら、同時にあなたを観察しています：体格（physique）、元気さ（check an energy level）。その後、簡単にチェックするのは：熱（take a temperature）、血圧（check/measure a blood pressure）、聴診（stethoscope 聴診器）、などです。
＜その時（までに）持っている知識＞
- そして、Doctorは自分の観察とあなたの答えを考え合わせながら、「うん、うん」と何か考えているような、納得しているような・・・きっと、これまでの自分の経験などに照らして、あなたのお腹の痛みがどこから来ているのか、検討をつけてようとしているのでしょう。
＜Assumption＞
- そして、おもむろに口を開きます：「今診た限りでは、おそらく、特に緊急を要する疾患の疑いはないようですね。ただ、『最近急に痛みが始まった』、『特に食事をした３０分くらい後から痛みが増す』ということなので、わずかですが、XXXXの疑いもあります。」更に、「まあ、すぐにどうこうという話ではないんですが、悪化するのは良くないので念のため詳しく調べておきましょう・・・」
＜Verification of assumption＞
- というわけで、Colonoscopyを受けることになってしまいました！結局は、「年齢にしてはちょっとポリープの数が多い」という検査結果でした。
＜Solution>
- で、改善策としては、「運動ともうちょっと野菜を食べた方がいい」ということに・・・
- でも、もし最初の”観察”や”問診”をしないで、いきなりCT、MRI、血液検査から始めたら、数えきれないほどの無駄な検査を受けることになっていたかも知れないですね！（笑）Assumption / hypothesisの重要さを感じます・・・
私たち（少なくとも私は！笑）がリサーチをするときにも、この”Analysis paralysis”に陥ってしまうことは避けなくてはなりません。貴重な時間とコストを無駄にしてしてしまいます。もちろん、他の分野ではその限りでない場合もあるかも知れませんが、私たちProblem-solvingがProjectなどのためにリサーチをする場合に限っては、”凡その検討をつける→検証する”を繰り返す”Agile的な進め方”が適切だと思います。
私たちProblem-solverがProjectに関して立てるHypothesisとかAssumptionとも、Doctorたちが最初に検討を付けるのと非常に似た行為で、目的も同じだ（詳細な検査／リサーチのために検討をつける）ということが分かります。
それでは、いずれかのReasoning方法を使い、ReasonableなHypothesis / assumptionを導き出すためにはどうすれば良いでしょうか。私たちProblem-solverの助けになるToolsを２つご紹介しましょう。
冒頭で出て来たFashion makerのCEOの例を使って説明します。
彼からもらった機会を最大限に活用して有効な情報を入手しなくてはなりません。ただ、タイミングが明日ですし、超多忙な彼がくれた時間は（取りあえず今回は）３０分に限定されています。もし、彼のScheduleに余裕があったとしても、CEOからもらえる時間は、一般的にもせいぜい１時間だと考えられます。
さて、どうやってAssumption / hypothesisを考えましょうか？
取りあえず、CEOが口にしていたことをベースに思いつくままにランダムに考えてみましょう。彼の頭痛の種にはこんなItemsが含まれていたように記憶しています。とりあえず、明日はこの辺りについて彼に質問を投げてみましょうか・・・？
どう思いますか？ん～、とんでもなく間違ったことをしているという訳ではないのですが・・・何だかピンときません。これらの情報に関する質問をして、その後どうインタビューを展開するのでしょうか？話はどんなふうに拡散して、どんなふうに収束するのでしょうか。そして第一に、どのように解決に近づくのでしょうか？見えてきません。ちょっと不安が残ります。
・・・という具合に、AssumptionをFormulateする際、RandomなApproachで行なうと、Interviewの展開のイメージが明確に把握できません。そのため、「何かの視点を見落としているかも知れない」、「余計なもの（Irrelevant items）が含まれているような気がする」という不安が残ります。“プロフェッショナルな仕事”とは言い難いですね・・・
さて、このProcessをもう少し効率的、効果的、Systematicに進める方法はないものでしょうか。
ここで２つのToolの紹介です・・・
一つ目は、Problem-solving MapというToolです。Problemを取り巻き、Problemに影響を与える様々なFactorsを網羅的に俯瞰するのにとても有用なToolです。「正確に問題を理解できれば、問題解決は半分は終わったも同然」とよく言われますが、まさにこのToolは、私たちのReasoningを助け、”原因 – 結果の関係の正確な理解”に役立ちます。
どんなふうに進めるかご説明しましょう。
Step 1
いきなり詳細に目を向ける前に、一歩さがってBig pictureをつかんでおきましょう。
具体的には、Problemに関するCore情報である”Cause-effect”構造を把握します。つまり、「何がCausesとなってProblemを生み出したか」ですね。
このStepは、できるだけ、今現在あなたの頭の中にある情報だけで進めることを強くお勧めします。２つ理由があります:
一つは、Problem-solverとしてある程度ご経験のあるあなたなら、多くの分野について一通りの知識をお持ちだと思うからです。（You know more than you realize…ご自分で認識しているよりもあなたは知識を持っています！）
もう一つの理由は、一旦Googleを開いたら最後、Chaotic abys of informationに引っ張りこまれてしまい、Analysis paralysis的状況に陥ってしまう可能性が大だからです！（経験談 笑）
それでは、ProblemとCauseを見つけてみましょう。
それをする時に役立つTrick（ハック／技）があります。”Sketch technique”です。Visual派の私はこれを行うことでそのProblemに関係するAll parties involvedを漏らさず認識することができるので非常に助かっています。また、”空中戦”や”堂々巡り”を避けることができ、情報が扱いやすくなります。Team membersやClientとBrainstormingする際にも非常に効果的です。
Management consultingの経験が長いあなたなら、このSketchを見た瞬間的にもっと分かりやすいChartやgraphicが思い浮かんだかも知れないですね！それらを使うチャンスは、後で出てきますので、save them for later！
Step 2a
それでは、ProblemとCauseの検討をつけてみましょう。Problem-solverとして経験のあるあなたには、ナン無く見つけられた／思いついたと思います。例を挙げておきましょう。
念のためですが、これはあくまでも例です。あなたのHypothesisがこれと同じである必要はありません。とりあえずは、Dropping salesとCustomerとCompetitorのことくらいが触れられていればOkです。
確認するまでないかも知れないですが、「顧客側、競合側、その他の（環境）要因が変化の結果、Salesが落ちた」ということですね。Big pictureを掴もうとしている段階なので、このくらいの粗さで大丈夫です。
Step 3-a
大抵のCaseには、Problem – CauseというCore structure以外のFactorsが存在します。それらのFactorsを考慮しながら、このProblem-solving mapをもう少し進化させてみましょう。
ProblemやCauseの発生には、多くの場合、”環境”の変化が何らかの役割を果たしています（Play a role）。そういうわけで、ここにEnvironmentというFactorも考慮したいと思います。ただ、電話をくれたCEOは、特に環境については何も言っていませんでした。なので、ここでは私たちの”常識”＝通常から鍛えている”マクロ感覚”を働かせてEducated guessを試してみましょう。
こんな感じになるでしょうか・・・
様々な分野でDigitizationが進んでいます。はっきりとしたDemographic shiftが起きています。そして、Work styleにも変化が見られます。
更に進化を進めましょう！
Step 3-b
問題が引き起こす更なる問題、つまり”二次災害”的なFactorも考え合わせます。ここでは、Brandの棄損やStock priceの下落などが考えられるでしょうか。
一方で、Viewpointも考慮しておく必要があります。ちょっとピンと来にくいかも知れませんね。「（この問題は）誰の視点から見て”問題”か」という情報です。このCaseで言えば、この企業のRevenueが落ちたことは、当然、この会社自身にとってはProblemなのですが、世間一般、あるいは多くのConsumersからすれば、特にProblemではありません。更に、Competitorの目にはAdvantageとも映るでしょう。
この例はそうではありませんが、Caseによっては、ProblemsやCauses、その他の情報が複数の異なる視点から書かれている場合があるので、Case全体の構造を正しく把握するためにもViewpointに留意しておくことは意味があります。
一つReal-worldの例を説明しましょう。Oil & Gas業界の話です。（ちょっと唐突ですが、私の以前のClientがこの業界にいたので思い出しました 笑）Fracking*を禁止する法律ができた場合など、Frackingの中止が生産高の低下につながります。Frackingを使っていたOil companiesにとっては重大なProblemなのですが、他の方法でOilを入手できるConsumersから見ればIrrelevantです。更に、Fracking以外のTechniqueを採っているCompetitorsにとっては、Benefitにさえなりえます。
こんなふうに、Viewpoint（立場）を固定しないとProblemを特定できないことがあるため、Viewpointを意識する必要があります。
（* Fracking = Hydraulic fracturing：岩盤に液体（水が多い）を高圧で流し込んで亀裂をつくってOilを採掘する工法）
Step 3-c
その他、TOBE（本来あるべき好ましい状態）やSolutionを加えましょう。
前者は、”何がProblemか”を明確に意識するための助けになります。Problemとは、To-Be（望まれる状態）とAs-Is（現状）の差だからです。
Solutionは、「新たなValue propositionに基づく、新たなMarketing strategy」としておきました。
Step 3-d
Solution周辺の情報に関してもう少し考えておきましょう。
あるSolutionを実施した際、元々は予期していなかったBenefitsが生まれることがあります。一方、障害（Obstacles）、また落とし穴（Pitfalls）が発生する可能性もあります。Solutionを成功裏に実施しようと思ったら、これらを考慮した方がいいですね。
例えば、この例では、Solutionとして、“新たなMarketing戦略を実施する”があります。この時、短期成果に集中し過ぎると巻き込まれかねないPrice warは、要注意点（Pitfall）です。あるいは、もしかしたらこの会社はこれまでFounder, CEOが全てをコントロールしてきたためその下の執行者が全く育っていなかも知れません。（いわゆる“文鎮構造”の組織 笑）その場合、この”戦略実行部隊の不在”は、Obstacleということになります。
「何の根拠でそこまで言う？」（笑）と思われたかも知れませんね。当然だと思います。ただ、この段階は、仮説を作るStepなので、その方法がReasonableであれば（つまり、このセクション３の最初に挙げた３つのReasoningsのいずれかで導き出したものなら、”妥当”だと言えます。そして、もちろん、”引き出しの数”（≒Problem-solverとしてこれまでどんな経験をして来たか）も、大いにMatters（モノを言う）と思います。
さて、AssumptionをFormulateするために役立つFormatの一つ目、Problem-solving mapを使った結果、このようなOutputにまとまりました。あなたのVersionはどうなりましたか？
Problem-solving mapのまとめです：
Point #1
最終的には、こんなに（一つ前のSlide参照）”にぎやかな”（with bells and whistles）mapになってしまいましたが、最も大切なのは、Core structureであるCause – Effect、つまり、Problemとそれを引き起こしているCauseを突き止めることです。
Point #2
この時点（Assumption / hypothesisのFormulationの段階）では“正解”にはこだわりません（唯一の”正解”は存在しません）。Clientからもらった限られた情報とあなたがこれまでに蓄積してきたあらゆる分野に関するVariousな知識やカンに基づいてFormulateしたAssumption / hypothesisです。Reasonableである限り、自信をもって頂きたいと思います！
Point #3
この時点でのAssumption / hypothesisで大切なのは、More & Wilderです。彫刻に例えて言うなら、この時点では“粗めに、大きめに作っておく”ということです。余計な部分を削ぎ落したり詳細を彫り出したりするのは、後のStepで行います。他の言い方をするなら、“拡散”ぎみの発想です。同時に、この時点では、少々想像力を働かせすぎくらいまで働かせ、「もらった情報はたったこれだけなのに、そこまで言っちゃっていいのか？」というくらい大胆に発想することも役立ちます。あらゆる方向に創造の枝を展開しておき、後のInterviewなどで余分な／役に立たない枝を剪定する（Eliminate）して頂ければと思います。
Point #4
Problem-solving mapは、”ProblemとCauseの構造に着目して、Problem＝Big pictureを論理性に注目しながら（Using the power of reasoning）俯瞰するTool”です。ですので、使える分野は非常に広いです。例えば、以下のようなときに威力を発揮します：
– Client interviewなどで、もれなく必要項目を落とすことなく網羅したいとき、はもちろん、
– 自分の主張をReasonableに構成して、説得力のあるPresentationを作りたいとき
そして、
– 他人（Team members, clients, suppliers, etc）のOpinionやargument、PresentationのReasonability（論理的か否か）を確認したいとき（そして、論理の穴があれば反論したいとき）
さて、ここまでProblem-solving mapをEvolveさせておけば、例のCEOとのinterviewを行なうには十分のように見えます。これに沿って質問すれば良さそうです。
ただ、Problem-solvingの最も重要なCore factorsであるProblemとCauseの関係、特にCauseのMechanism（どんなしくみでProblemを引き起こしているか）については、もう少し詳しく分析／分解（Anatomize）しておいても良いかも知れません。Assumption / Hypothesisは詳しい方が、その後Solutionを考える際に効率よく、精度も高くなります。（もちろんバランス（SpecificityとPracticalityの）も大切なんですが・・・）
またまた医者の例えですが、できるだけSpecificな”見立て”ができた方が、検査、検証（Verification）を効率的にでき（つまり、まさに”We can ask good questions as a problem-solver”です！）、究極的には真のCausesを突き止めるのに役に立ちます。つまりそれだけ、効果の高いSolutionを導き出せるというわけです！
それでは、”CauseのMechanismを分析する”とはどんなことか、２人の医師の“見立て”を比較してご説明しましょう。
あなたは、２人の異なる医師に症状の“見立て”（formulating an assumption / a hypothesis）をしてもらいました。どちらの方が、より精度が高く効率的な治療（Problem-solving）により役立つでしょうか？
医師X：
＜Observationや質問によるSymptomsの発見）＞
症状としては、みぞおちの辺りに痛みを感じられると。ときどき鋭い痛みもありますか・・・この不快感が1ヶ月以上続いているんですね。今は食事の直後に膨満感を感じられることもある・・・
この２月で４３歳になられる。お仕事は、主にデスクワークですね。財務系の部署の責任のある職に就かれていて、常にかなり高いストレスを感じられている。そのストレスを発散するために飲みに行かれることも多い。それは、長時間労働の後、ですね。つまり、深夜近くに食事をされることも珍しくない、ということでしょうか。そうでね。ビールと一緒に採る食事は、どうしても脂っこいものが多くなるでしょうね。
そうですか。お若いときから胃炎のご経験があったということですね。真面目なお人柄もあって、会社を一歩出ればスパッと仕事のことは忘れる、という訳には行かないのは理解できます。
＜その時（までに）持っている知識を活用する＞
（口には出していないが、主に消火器内科の知識と経験）
＜Assumption / hypothesisを立てる＞
胃適応性弛緩障害、胃排出障害などが起きていると思います。
２カ月まえに受けた胃の内視鏡検査では炎症などの器質的な異常が見当たらなかったということなので、胃がんや胃潰瘍、十二指腸潰瘍などの可能性は低いです。現時点では、機能性ディスペプシアが考えられます。
＜AssumptionをVerifyする＞
血液検査と超音波検査でちょっと詳しく調べましょう。必要によっては、後日CTを受けて頂きます。
＜Action / Solutionを創出する＞
検査の結果が出てから改めて考えましょう・・・
医師Xとはこんなやり取りがありました。これをTree状にまとめたのがこのSlideです。
他方、医師Yとはどんなやり取りがあったでしょう・・・
- 「全体の感じからして、FDだと思います。私を信じて！」
たったこれだけです！（笑）
ポイントを分かって頂くために、ちょっと極端な例を作りましたが・・・
医師Xは、Cause – effectの関連づけ、そしてCauseのMechanismの把握が明確です。この“Map”のそれぞれのItemを検証していけば、Problemとその原因が明確になり、より正しい治療を導き出すことができます。
それに対して、医師Yがやったのは、Assumption / hypothesisというレベルのものではなく、単なる”あてずっぽう”に聞こえます。もしかしたら、単にCommunication能力が極端に低いだけかも知れませんが（笑）、彼／彼女のAssumption / hypothesisは、検証も困難です。つまり、Not usefulということになります。
例がすごく長くなりましたが（大切なことだからいいですね！笑）、CauseのMechanismまで分析を深めるとAssumption / hypothesis全体の質が高まることが分かって頂けたでしょうか。
さて、さっきのFashion company例を使ってCauseのMechanismを見てみましょう。
Step 1
Grasp the big picture
というわけで、ProblemとCauseの関係の部分をDig deeperします。
ただ、いきなり詳細な分析に入ると出て来れなくなる可能性があるので（笑）、（Don‘t miss the forest for the trees）Problem-solving mapでやったようにBig pictureを思い浮かべてみましょう。今回は、ProblemとCauseにFocusします。
再び”Sketch technique”の登場です。
Tip ( = key point ) #をつけておきましょう。
Tip #1: Sketch technique
Step 2
ProblemからCauseへ分解する過程をVisualizeします。Tree状にして見やすくします。その形態からIssue treeとかLogic treeと呼ばれることがあります。
余談ですが・・・
Issue treeやLogic treeという呼び方が一般的に使われています。どう呼ぶかはあまり神経質になる必要はありません。ただ、Problem-solverのあなたは、今後も類似のTermsに遭遇する確率が高いと推測されるので呼称を確認しておきましょう。
Issue (= important topics or problems for a debate or a discussion）を扱うからIssue treeと呼びます。同時に、Logic treeと呼ばれることもあります。理由は、Logic (= reasoning)を使って構築するから、あるいは、Treeに含まれるElementsがLogicalにつながっているからです。つまり、Treeで扱う”対象”（Issue）に注目しているのか、Treeの”機能”（Logic）に注目しているかの違いです。
また、Treeと一緒に使われる単語として、WhyとかSo what、Howという単語を見ることが多いです。（書籍やWebsiteの場合）Authorによって異なる使われ方がされていることもありますが、実はかなりSimpleで、総合するとこのSlideのような事情です！
つまり・・・
Issue tree or logic treeは、目的によって２つに分類されます。Diagnosis treeとSolution treeです。
前者は、ProblemをCauseに分解するときに使います。他方、Solution treeは、一旦Problemを分析した後に、Solutionを分解して具体的なActionsを考えるときに使います。この２つのTreeを別々に作ると、Confusionが無くていいと思います。ただ、合体させて（途中までDiagnosis treeで途中からSolution treeになっている）いる例もありますね。Team memberやClientsと共有することもあると思うので、Caseに応じて最適な方法を選んで下さい。
話を元に戻しましょう！（このPhrase、このコンテンツに何回出て来たでしょう！どれほどDigress（脱線）しているかが分かりますね！笑）
こんなふうにTree構造化してみました。もちろん、唯一の正解はありません。ただ、Treeを作る際に押さえるべきポイントがあるので、ちょっと確認してみましょう。
（一覧性を最大にするために１ページに収めたため、文字が小さくなってすみません！）
２番めのTip = key pointです。
Tip #２: Eliminate unlikely factors/causes at as an early stage as possible
Customersが自社の製品を買わなくなったしまった場合、主に２つの原因が考えられます。１つは、Customers buy competitors’ products（他社／他社の製品を（もっと）好きになった）、もう１つは、Customers stopped buying fashion clothes all together（Fashion clothesというもの自体買わなくなってしまった）です。（ちょっと人間関係みたいですね！笑）
このFork（分岐）のポイントは、Probabilityの低い選択肢を早い段階でEliminate（排除）したことです。これは非常に重要です。理由は、こうすることで本当にSolutionに結びつく、検証する価値のある”Causes”だけにFocusでき、時間を効率的に使えるからです。
３つめのTipに移りましょう。
Tip #３: Keep potential solutions in mind
このようなForkにしたのは次のような理由があります：
Treeの選択肢は、末端になればなるほど（このChartで言えば、右側に行けば行くほど）、最終的に取るであろうActionsをより強く示唆している（Implying）／結びついている（Associated）必要があります。
この理由で、第２Layerの3aでは、“Still like us but more attracted to competitors”と“Don‘t like us anymore”（涙）に分けました。それぞれのケースに関して、異なる、採るべきPotential action optionsがイメージできます。３bも同様です。
Tip #４: Mutually Exclusive and Collectively Exhaustive
これは、Issue treeのどのBranchも満たしているべき条件です。
Issue treeは、仮説を構造化、Visual化するためのToolです。Interviewなどを通してその検証を行ない精度を上げます。ですので、もし分岐した２つの選択肢がはっきり区別がつかないほど似通っている、あるいは内容がオーバーラップしていると、分岐自体に意味が無くなってしまい、原因を絞りこむことができません。同時に、この２つの選択肢は、全てのOptionsをカバーしている必要があります。
どうだったですか？Treeの構成、Reasonableだなと感じて頂けたでしょうか？
あなたはお気づきかも知れないですが、各分岐（Fork, break-down）で意識しているのは単独のKey point（上記のTip #2と＃3のいずれか）とは限りません。むしろ複数の条件を考慮しています。例えば、Tip #2で説明した分岐点では、主に”Eliminate unlikely factors/causes at as an early stage as possible”ということを念頭に置いていますが、同時にTip #3で触れた”Keep potential solutions in mind”も意識しています。同じことは、Tip #3でも言えることです。
上記、Fashion company caseを使ってご紹介した３つのKey points以外にも、Treeを作るときのコツをいくつかご紹介しましょう！
Tip #5: Inductive Method
今回Treeを作る前にSketch techniqueを使ってBig pictureを描きました。これをもう少し発展させたやり方があります。”Inductive method”（帰納的アプローチ）と呼びましょう。
Step 1:
Problemに対して、原因を思いつくままにどんどん書き出します。これは、Sketch techniqueをやった後がいいかも知れません。
Step 2:
「もう出し切った」と思えるところまで来たら、今度はそれらをグルーピングします。ちょっとIshikawa Fishboneの方法に似ていますね。（だた、Ishikawa Fishboneは、最初に６M（Methods (and Processes), Materials, Measurements, Machines (and Equipment), Manpower (People) and Mother Nature (Environment)）などを設定してから行うので完全にInductiveではありませんが・・・）
Step 3:
Initial trialが何となくピンと来なければ、グルーピングを何度もやり直します。ですのでMind map appを使うとやりやすいかも知れません。（この例では私はFreemindを使いました。他の用途でも良く使います）
どうやら、Inductive methodだけでもここまでは来れました。更に、経験のあるProblem-solverであるあなたなら、この例のような単純なCaseは、Piece of cake（朝飯前）の可能性大ですね！
ただ、あなたならお気づきかも知れません・・・そうです！Randomに思いついたものをRe-arrangeしただけなので、単なるグループ分け（あまりLogicalではない）になってしまう可能性がぬぐい切れません。例えば、First layer（Red dotted circle）がMECEでないかも知れませんし、Second layer（Blue dotted circle）は、Solutionを想起させないかも知れません。
そう考えると、もう少しシステマティックなアプローチが欲しいところです。それでは、その助けとなるTipをご紹介しましょう！
Tip #6: Suitable Types of Trees
Issue treeの適材適所です。Issue Treeは、IssueのTypeの数だけ存在します。（何だか、一休さんのようになってしまいましたが、続けて読んでみて下さい！笑）
目的の数だけ様々なProjectsが存在します：Revenue increase、Market entry、Increasing attrition rate、Cost hike…..異なるTypeのProject = Issueには、それに適したIssueのTypeのTreeを使った方が、適切なSolutionを得やすいです。
というわけで、多様なTreeのTypeをいくつかに分類してみました。以下のSlideでは、全体的な特徴（Overview）に続いて、Tips & Tricks、つまり、そのApproachの特性や使う場合のコツなども説明しています。
Treesは、まずは大きく、Quantitative（定量）とQualitative（定性）に分けられます。そして、Quantitativeの方は、Mathというか計算式系のTreeです。（おっと、当然なことを言ってしまいました！笑）一方、Qualitativeの方には、Process系やSegmentation系、あるいはopposite concepts系があります。それぞれに、Pre-madeのFramework（世間で広く使われている比較的汎用性の高いもの）とOriginalのFrameworkが含まれます。
何とも抽象的で、ピンと来るような来ないような（笑）・・・
例を使って説明した方がいいですね・・・！
Quantitative – Math
Overview
IndustryやBusiness modelが異なれば変化するものがある一方で、IndustryやBusiness modelが異なっても変わらないものがあります。例えば、Revenueの計算の仕方です。”単価×数量”という基本は同様です。Problem-solverのあなたは、この他にも”良く見る”Formulaをご存知かも知れませんね。例えば、Break even point、Inventory management、Customer acquisition、ROEなどが思い起こされます。
Tips & Tricks
これらは全てMath（実際Algebraレベルですね！笑）に従うので構造は単純で、誰がやっても同じようなFormulaになります。（１＋１＝２みたいに・・・）
ちなみに、非常に頻繁に多くの人々によって使われるものをProven formulaとかPre-made formulaと呼んでいます。ProvenとNon-proven (customize)の間には明確なLineはありません。違いは一般化している度合いです。（英語のIdiomみたいなものですね！）
Treeを１から作ろうとするとそれぞれの分岐先にどんなFactorを持ってこようか迷うこともあります。これを考えるには方法があります。ちょっとご説明しましょう。
両方の数値（Branches）を同時に思いつかない場合でも、どちらか片方なら何となくイメージが沸くことも多いです。
単純な例として食品会社のSalesを考えてみましょう。（もしかしたら、Tree作りになれたあなたにはちょっと易し過ぎるかも知れませんが、確認だと思ってお付き合い下さい・・・）
Salesの分解はどうするか？「できるだけたくさん買ってくれれば、Salesは伸びそう！」こんな直感はすぐに浮かびます。つまり、一方のFactorは、“Number of products sold”かな、となります。すると、もう一つのFactorは何になるでしょうか？もう一方は、Unit priceです。こんな具合に、少なくとも片方のElementを思いつくことは可能なことが多いので、そこからしつこく（Persistently）がんばれば、かなりの場合、次のLayerを作ることができそうです。
ここまで読んで、もしかしたら、あなたはこう思ったかも知れないですね・・・「最初のExample caseで出て来たFashion brandのCEOのIssueも、Math（Quantitative）でイケるのではないか？」だって、”Our sales are declining”というわけですから・・・
答えは、「その通り！」（Right on the money）です！MathのFormulaで表現できます。実は（←隠していた訳ではありませんが！笑）1つのCaseは、何種類ものTree patternにTranslate（表現）することができます。Fashion brand CEOの例で説明しましょう。
Fashion brand CEOのCaseを、Math (Quantitative）のTreeで表現するとこうなります。
すると、「両方で作れるなら、どっちを使うべきなんだ？」と聞きたくなりましたか？当然の質問です。
経験則的には（The rule of thumb）、Qualitative treeの方はLonger-term strategyに関するIssueを扱う際により多く使われます。それに対して、Quantitative（Math）treeの方は、Shorter-term strategyというかOperational plans / planningに使われることが多いです。前者と比べると、後者は数値で構成されている分、より具体的な直近の計画を表わすのに適しています。
Pre-made examples
（日本で”フレームワーク”と呼ばれているものです。Pre-madeでないものとの間に明確なLineはありません。正確に言えば、”非常に頻繁に広く使われているので一般的になっている”分岐方法です。）
Revenue, Profit, Financial statement、Break even point、ROI、ROE、ROICE、Inventory level, etc.
次は、Process, Steps and Orderに関するTreeです。
Overview
読んで字のごとく（笑）、Problemを分解する際、Process、Steps、Orderなどの概念を使って説明できるCasesに適しています。
このSlideの例は、Customer journeyから発想したものです。ですので、もちろんMarketing funnelから発想することも可能です。Visual派（笑）の私にとっては、この発想法は非常にやりやすいです。もしあなたもVisual派なら是非お試し下さい！Marketing funnelなので、「XXスキーリゾートの客を増やすにはどうすればよいか」などのIssueにもそのまま使えます！（See next slide)
Tips & Tricks
上記のFunnelの考え方は、Ven diagramでも表現することができます。Visual派のあなたと私には更に嬉しいです！（笑）
また、Funnelの考え方は、”How many piano tuners in Chicago?”（超有名！）などのFermi estimateを解く際にも非常に有用です。
Pre-made examples
良く知られている／使われるBread-downの方法には、こんなものがあります：
Product Life Cycle（Raymond Vernon）、Value Chain（Michael Porter）、Segmentation-Targeting-Positioning、Balance Score Card（Robert Kaplan and David Norton）、Hierarchy of Needs（Abraham Maslow), etc.
Marketing funnelについてご興味があれば、このLinkをCheckしてみて下さい。例を挙げて説明しています。Good funnels and bad funnelsなども解説しています。
次は、Qualitative – Segmentation Treeです。
Overview
あるFactorをSegments（Parts）に分けるのがこのMethodです。例えば、食品会社のRevenue declineの原因を調べる際に典型的に使う分け方です。この例は、Channel別に分岐させていますが、その他、Region, zip code（USではいろいろな用途で使われます：例：Income分布、学区）, time period, branch, consumer demography, gender, income tyer, price range, SKU, sales assistantなどが使われます。
Tips & Tricks
SegmentationというTermはMarketingで良く使いますね。
Marketing projectで使うことを考えてみましょう。対象のMarketを分ける（Dissect）こと自体が目的になってしまい、“Segmentation game”のようになってしまうこともあります。（特に初期は、Segmentation自体が楽しいですから！）ただ、let‘s go back to the basics（基本に立ち戻って）、”その分岐に（どんな）意味があるのか”を考えながら行ないましょう。
例えば、すごく極端な例ですが、Blood typeやZodiac signをSegmentationの軸として思いついたとしても、CustomerのBlood typeやZodiac signを調べるスベはありません。また、Blood typeをBaseにPromotion戦略を構成するのは、ちょっとムリがあります。（笑）
実践的にIssue treeを作る場合には、Segmentation時にこのような配慮をすると役立つと思います。
Pre-made examples
良く知られている／使われるBread-downの方法には、こんなものがあります。すごい数ですね！：（ ）の中の名前は、創造者（Creator）です。
3C (Kenichi Ohmae), SWOT (Albert Humphrey), 5 Forces (Michael Porter), PESTL (Francis Aguilar), VRIO (Barney, J. B.), 4P (E. Jerome McCarthy), The Ansoff Matrix (H. Igor Ansoff), Balance Score Card (Robert Kaplan and David Norton), 7S (McKinsey & Co), 6M (Fishbone diagram): Materials, Methods, Machines, Measurements, Manpower, Mother Nature (Ishikawa), 6Ps (Fishbone diagram): People, Process, Product, Policy, Plant, Program (Ishikawa), Hierarchy of Needs (Abraham Maslow), Intrinsic vs. extrinsic motivations, Quality vs. quality, Cause-effect, Cost-return, Personal vs. corporate, BtoB vs. BtoC, individual vs. household…goes on….
Opposite Concepts
Overview
２つの相対する概念に分岐する方法です。ここであなたは気づかれたかも知れないですね。そうです！Segmentの方法とかなり似ていますね？それもそのはず、Segmentは、１つの要素を３つ以上に分ける（Segment）ことが多いのですが、この方法は、通常１つの要素を２つの相対する概念に分岐します。ですので、例えば、全人口（The whole population）を”Older generation” vs. “Younger generation”に分けることは、「２つのSegmentsに分けた」とも言え、「Opposite Conceptsに分けた」とも言えます。
Examples
Segmentsに含まれている下記の例などは、Opposite Conceptsです。
intrinsic vs. extrinsic motivations, quality vs. quality, cause-effect, cost-return, personal vs. corporate, internal vs. external factors
更には、このような概念もOpposite Conceptsに含まれます。
Carrot vs. stick (=reward vs. punishment), input vs. output, new (customers) vs. existing (customers), push (sales) vs. pull (marketing)
Tip #6はかなり長く、内容も豊富だったので再度簡単にまとめをしておきましょう。
General
多くの場合、分岐のさせ方は複数通りあります。また、Mathでイケて同時に他の方法も使える場合があります。Mathは比較的短期のProblemを扱うことが多いです。それに対して、Qualitativeは、比較的長期の戦略に向いていることが多いです。
Math
分岐に必要な次のLayerの２つ（あるいはそれ以上）の数値（Drivers）を同時に思いつかない場合でも、まずどちらか片方（どれか一つ）を考え、その後、残りを考える（逆算するような感覚）と前に進めます。
Process, steps and order
Visual thinkerには非常に親しみやすいです。Fermi estimateに便利なFunnel approachもこのグループに含まれます。
Segments
Segmentに分けるのはあまりにもたやすく楽しいいので（笑）、分けること自体が目的になってしまい、Segmentation gameのようになってしまうこともあるので注意です。「分けて意味があるのか？」にも留意。
Opposite Concepts
Segmentsに近い概念です。ただし、２つのBranchesで構成されることが多いです。
Pre-made frameworks
カップ麺のような便利さがあるのでつい多用しがちですが用心が必要です。Problem-solver的には、できればOriginal treeを作りたいものですが、Pre-madeの便利さも否定できません。ですので、そのまま使わず、あくまでも”取り組んでいるProblemを解決するために使う”という視点を持って使ってみて下さい。すると、Customizeしたくなりますよ！
Tip #7: Use analogy
Treesを作る場合、Analogyも非常に助けになります。もしかしたら、Tree作りをいくつも経験済のあたなは自然と感覚が身についているかも知れません。つまり、「Analogous（類似する）Business modelを使っているBusinesses間では、同様のIssue treeを使えることが多い」ということです。多少のModificationを行えば、その応用範囲は更に広がるでしょう。
同類、あるいはBusiness modelに共通点があるBusinessを比べてみましょう：
このChartは、例えば・・・
- HP Printer, Nespresso, iPhone, FitbitなどのコアになっているBusinesses Modelは: “Razor and blades” modelというふうに読みます。
- （例示していませんが、もちろん上記以外の企業もあります！）
- Uber, Airbnb and ArtsyなどのコアになっているBusinesses Modelは: “Peer-to-peer” model
- Google and FacebookなどのコアになっているBusinesses Modelは: “Advertisement” model
- McDonald’s, Gold’s Gym, Hilton H&R and KumonなどのコアになっているBusinesses Modelは: “Franchise” model
- LinkedIn, Google, Facebook and banksなどのコアになっているBusinesses Modelは: “Multi-sided platform” model
- Zoom, LinkedIn, Bizreach and SpotifyなどのコアになっているBusinesses Modelは: “Freemium” model
- Newspaper, Dollar Shave Club, Amazon Prime and SaasなどのコアになっているBusinesses Modelは: “Subscription” model
- Consultants, private trainers and website developersなどのコアになっているBusinesses Modelは: “Consulting” model
- Youtube, Twitter and TabelogなどのコアになっているBusinesses Modelは: “User-generated contents” model
単純な例（Razor and blades model）を使ってもう少し詳しくご説明しましょう。
HP PrinterのRevenueは、Printer自体を売って得られる収入、その後売れるInk cartridgeから得られる収入、その他の収入の合計です。更に、Ink cartridgeから得られる収入は、Unit priceと売れた個数の積でできています。
NespressoもiPhoneもFitbitも、最初にHardwareを購入し、その後、付随するサービスや商品を購入します。基本になっているBusiness modelが共通しているため、ほぼ同じTreeが使いまわせるというわけです。（You don’t need to reinvent the wheel!）
Tip #8: Keep updating
最後の２つTipsは全体に関する考慮点です。
Problem-solving mapもIssue treeも、一度作ったら終わりではありません。追加情報を得るごとにあなたのAssumption / hypothesisをUpdateし、より”正確な”ものにします。これもこのコンテンツの最初の方で使った地図の例えがピッタリかも知れません。
例えば、海外旅行では、日本から持って行った地図が必ずしも１００％現実を反映しているという保証はありません。それをそのまま信じて使うと目的地に行きつかない、あるいはかなり遠回りをしてしまう可能性があります。ですので、その国に到着してから追加して情報を集めることが非常に重要です。これは、海外赴任に。
２つの”地図”（Problem-solving mapとIssue tree）にも同様なことが言えます。このSlideの図のように、時間の経過＝追加情報の入手が進めば進むほど、地図の精度は増します。その結果、Problem-solvingの効果と効率が上がり、あなたとあなたのTeam members、そしてClientへのBenefitsとして現れます。
Tip #9: Take it easy!
最後のTipです。
ProblemをMECEに分けてその要素であるCauseに分解する。その通りなのですが、MECEがあまりにも前に出過ぎてしまい、”No MECE, No Tree”のような半ば脅迫観念になってしまっています！（笑）
そこで提言しておきたいと思います。Quantitativeでは数字の性質上MECEになりやすいですが、Qualitativeでは完全にMECEにならないことも多いです。目的を忘れないようにしましょう。このProcessはひとえに、あなたがProblem-solverとして（Problem-solvingの前準備としての）仮説を立てることが目的です。ですので必要以上に神経質になって仔細（Minor details）に時間と努力を費やしても、あたながClientに提供するValueの増加には直結しないこともあるということを心に留めておきましょう。（自戒）
ここまででご初回した９つのTipsをおさらいしておきましょう。
Tip #1：Treeを創り始める前に、Sketch techniqueを試してみましょう
Tip #2：可能性の低い原因は、できるだけ早い時期に削除する
Tip #3：（Treeを創る過程では）いつもSolutionを意識して
Tip #4：BranchesはMECEになるように（オーバーラップさせない、かつ、包括的になるように）
Tip #5：始め方に迷ったら、Inductive methodを試してみましょう
Tip #6：Problemに合った種類のTreeを使いましょう：例えば、定量のMath、定性のプロセス、ステップ、順番とセグメンテーション
Tip #7：アナロジーを使いましょう
Tip #8：何度も改良を続けることが必要です
Tip #9：Take it easy!（笑）
ここまで見て頂いたように、私たちProblem-solverはProjectの最中やその前後で、Hypothesisを使うことによってものすごく多くのBenefitsを得ています。ProjectのTimelineをベースにそのいつくかをご紹介しましょう。
まず、Client interviewではどんないいことがあるでしょうか？
a) 意味のある、要点をついた質問ができるようになります（もちろん、効果の高いQuestionnaireを作成する際にも大いに役立ちます）
b) インタビューする相手とVisualに考えを共有することができるのでMisunderstandingやconfusionのRiskが最小限になります
次に、Client interviewで得た情報を基にAnalysisを深めます。Brainstormingなどを通して・・・
c) Graphicalで直感的なので、容易にProblemを俯瞰することができます
d) なので、issuesの優先順位づけができ、Key issueに意識をFocusすることができます
e) また、（もしこれらのToolを使わないでいたら発見できなかったポイントも）発見することができます
f) 更に、Team memberもClient側のMembersも、誤解なく現状を共有できるのでDiscussionに積極的に参加することができます
g) 必要があれば、Fermi estimateにも便利です
Characteristics and benefits of problem-solving maps and issue treesの例をIssue treeの上に図示してみました。
Solution actionsを考えるStepではどんなBenefitsがあるでしょう？
h) Problem-solvingの過程でどんなことが起きそうかを予想できます
i) 大きな問題を小さなTasksに分解するのでManageable（扱いやすく）なります
Solution actionsを実行する際のBenefitsは？
j) もしあなたに時間が無ければ、他の人にTaskをDelegateすることができます。そうすることで、Project leaderとして、あなたはProjectの全体感を見失わずに済みます。これは大きなBenefitですね！Project leaderがやらなくてもいいような些細なTaskに捕まって、Project全体が見渡せないと、どんな大きな事故につながるか分かりませんね！
かなり長いコンテンツだったですが、いかがでしたか？How do you ask good questions in client interviews?あなたなりのこの質問への答え、見つかったでしょうか？
最後にこのコンテンツをReviewしておきましょう・・・
1) 私たちProblem-solverは、Client interviewを最大限活用して、有用な情報を入手する必要があります
2) Client interviewというのは、私たちProblem-solverが立てたAssumption / hypothesisをVerifyする機会です
3) なので、良い質問ができるかどうかは、どれだけ良いAssumption / hypothesisを準備できるかにかかっています
4) HypothesisとはInformed / educated guess（根拠のある推論）を指します。実は私たちは毎日使っているものです
5) Assumption / hypothesisを作るには２つのToolsがあります：Problem-solving mapとIssue treeです
6) Problem-solving mapは、Problem-Causeの構造を明確にするのに有効です。一方、Issue treeは、ProblemをBreak downして一口サイズの解決可能なPiecesにするのに使います
7) Issue treeを作るには主に３つのMethodsがあります：Math, Process/Step/Order and Segmentationです
8) 多くのProblemsは一つ以上の方法で解くことができます
9) Problem-solving mapとIssue treeを使えば、あなたやあなたのTeam membersそしてClientsは、Problem-solving journeyを通して、数えられないほどのBenefitsを得ることができるでしょう
ここでは主に、Problem-solverがClient interviewをやるときに必要となるAssumptionやHypothesisの組み立て方について説明しました。
もし、Interviewの方法全般についてご興味があれば、このコンテンツをチェックしてみて下さい。Interviewの前、最中、後に何をすればいいのか、Interviewの中でClientをどう誘導すればいいのか、などについて説明していいます！
このコンテンツでは、How to ask good questions as a problem-solverについて説明しました。Problem solvingを目的とする場合には、Effective and efficientなInteractionをする必要があります。一方、私たちProblem-solversは、Effective and efficientでないCommunication skillも持ち合わている必要があります。
「えっ？どういうこと？」と思われたと思います。答えは、“雑談”です！InterviewではClientに心を開いてもらい、直接対話でしか得られない貴重な情報を提供して頂く必要がります。そのためには、信頼を得る必要があります。さもないと、表面的なやり取りで終わってしまう可能性が大です。Intervieweeの信頼を得、こちら（Interviewer）を知ってもらうために有用なのが“雑談”Skillです。もちろん、あなたがManager（管理職）として海外に赴任した時にも、雑談力は威力を発揮します。大抵の部下は、ドライな仕事の話しかできない上司よりも、くだけた雑談もできる上司に心を開きやすいです。また、Presentationを行った後のカジュアルな場でも雑談は非常に重要なネットワーキングの場となります。
雑談の目的は、Socializingです。つまり、このコンテンツでお伝えした質問の目的とは対極的に、InteractionのProcess自体が目的です。ですので、雑談の“成功”は、「どれだけ相手に安心して口を開いてもらえるように会話をCreateするか」にかかっていると言えます。
英語で雑談をするよ方法にご興味をお持ちであれば、このリンクをチェックしてみて下さい。https://absolutegambit.com/gambit/gambit-link
ご質問やコメント、アイデアなど、お持ちでしたらどうぞお気軽に！