クライアントの話を聞いていて、問題と原因の関係が明確に見えないこと、ありませんか？問題と原因がいくつもあって、スパゲティーのように絡み合っていること、ありませんか？
そんなとき、何が起きているんでしょう？私たちは、Problem-solverとして、どんなふうにアプローチすればいいのでしょうか？
私たちProblem-solverにとって、得た情報の中からCauseとProblemを探し出すスキルは非常に重要です。
なぜなら、Problem-solverのMissionは、「問題をはっきりさせ、その原因を特定し、そこにAddressするようなSolutionを明示する」ことだからです。
これは、問題を解決するときにはもちろん、クライアントの悩みを分析して解説するときや、チームメンバーと情報共有する際にも威力を発揮しいます。（It will benefit you big time!）
Problem（問題）は、Cause（原因）が起こしています。ですので、このCauseをAttackすればProblemも消えます。
私たちが日常経験しているものすごく簡単な例で言えば、「お腹が痛い」がProblem、「腐ったケーキを（昨日）食べた」がCause、「（病院に行って）解毒の薬をもらって飲んだ」がSolutionです。この場合、１７世紀なら痛いお腹をさする“手当て”でお茶を濁すこともできたかも知れませんが（笑）、やはり現在私たちがProblem-solverとしてProblemをSolveするためには、CauseまできちんとAddressする必要がありますね。
それでは、もうちょっとビジネス寄りのCaseを見てみましょう。
あなたが、ChicagoにあるClientの会社に呼ばれて行ってみると、そこのCFOが”We are losing money”と言っています。”We are making no profit!”これは問題だ、といいうわけです！
これが現実なら、「CFOのあなたがなぜ今まで何も手を打たなかった？」と攻めるところですが（笑）、（これはあくまでもSample caseなので）穏便に”Why？”と聞いていみると、”Customers don‘t buy our new products.”という答えが返って来るではありませんか！じゃあ、これがProfitが出ない問題だ！
ところが、続けて”Why don‘t customers buy them?”と聞いてみると、”The design is bad.”と自信無げに返して来ます。じゃあ、Customers don’t buyがProblemの原因は、それでなんですね？となります。
でも、まだ気になるので”Why is the design so bad？”と聞いてみると、”The designer had no experience.”というとんでもない答えを平気でします。それが、原因で”The design is bad.”というProblemが生み出されているということになる。
何だかちょっと分かりにくくなってきましたが（笑）、この一連のできごとの中で何が問題で何が原因でしょう？
そうです！ProblemとCauseが“数珠繋ぎ”（Cascade）になっています。一つの問題がその前の原因によって起こされている。そして、その原因を起こしているのは、更にその前に起きた原因・・・という具合です。
というわけで、Clientに出すPPTの分析／解説は、こんな感じになるでしょうか・・・”Unfortunately, you are (have been) hemorrhaging badly (for the last two quarters). We are still at the early stage of investigations but detected several probable causes including a) the hiring mistakes and b) the wrong instructions given to the product designers.
もちろん、相手の環境によって表現のし方は多少異なるかも知れませんが、keyになるポイントは：
①ProblemとCauseは数珠つなぎになっていることが多い
②Problemを解決するにはroot causesにaddressする必要がある
③ただし、Clientの現状によってはultimate root causeをattackできない場合がある。（例えば、特に日本の企業の場合、解雇を嫌う雇用主が多い）そういう場合は、現実的なcauseで最もroot causeに近い原因をattackすればいいです。また、二次的効果（benefits）を考えて他のcauseをtargetとするのもいいかも知れません。Change managementのような効果を狙ってです。例えば、このcaseの場合なら、”The design is bad.”というcauseを基に、「社内デザインアイデアコンテスト」のようなイベントを起こし、engagementを高める効果を狙ってもいいかも知れません。
まとめ
Problem（問題）は、Cause（原因）が起こしています。ものすごく単純化して言えば、このcauseをattackすればproblemも消えます。ですので、Problem-Causeの関係を明確にすることがProject成功の第一歩になります。
私たちProblem-solverが直面する問題は益々複雑になることが多いです。いくつものProblem-causeのセットがCascadeになっていることもめずらしくはありません。（Not uncommon）究極的には、Root causeをAttachする必要があります。但し、現実には様々な理由でそれができない場合もあるので、そういったケースでは、クライアントとじっくりDiscussionした後にBest possible actionsを採ります。
ご質問やコメントなど、お持ちでしたらどうぞお気軽に！