元コンサルタントのつぶやき（２）正しい考え方、伝え方の心得＜その２＞

目次

（長いので＜その１＞＜その２＞に分割しています）

＜その１＞（←リンク）
０．はじめに（正しい考え方、正確な伝え方は難しい）
１．考える、伝える以前の問題（使う言葉は考え方を左右する）
２．正しく考える（１）（事実、推論・予想、意見の切り分け）
３．正しく考える（２）（正確な論理展開）

＜その２＞今回
４．正しく考える（３）（課題解決アプローチと仮説検証）
５．正しく伝える（１）（結論よりも前提に時間をかける）
６．正しく伝える（２）（１度に多くを述べない）
７．さいごに（人格、人間性といった要素も極めて重要）

４．正しく考える（３）（課題解決アプローチと仮説検証）

（１）問題と課題の違い
問題（ problem / trouble ）と課題（ isuue ）は明確に異なります。

例．システム開発場面での顧客（C）とエンジニア（E）の会話
Ｃ「Ｅさん、今の入力システムは備考欄に和文字で12字しか入りません。
　　（顧客担当者の考える問題点）
　　もっと情報を入れたいので、備考フィールドを12ｰ>36字位に拡大して。
　　（顧客担当者の考える問題解決案）」
Ｅ「Ｃさん、その備考欄はどういう使い方をしているのですか？
　　（事実情報の収集ヒアリング）」
Ｃ「請求書に記載の支払条件、相手担当者名、特別条件など入れています」
Ｅ「それって、全て備考欄に入れなければだめですか？
　　どの請求書でも頻繁に発生する情報は別項目に分けた方が良いですよ。
　　（課題認識のすり合わせと確認）」

通常、きちんとしたプロジェクト管理をすると、「問題管理」と「課題管理」は別個のものとして扱います。

なぜか。
内容が全く違うから。
抽象的に言えば、
　「問題 ＝ 事象」
　「課題 ＝ 問題について原因を分析した結果、真に解決すべき内容」
となります。

前記の例は極めてシンプルですが、一般的には問題自体が何なのかもわかりにくいことがよくあります。
（例．PCが動かなくなったが、原因が分からない）
この場合は、
「問題切り分け」
を行って、何が悪いのか突き止めて、
「問題解決」
を行います。
（例．電源は入っているか、OSは起動可能か、アプリは最新か…）

こうした問題管理で対応できることもありますが、一般的には、
　問題　≠　課題
なので、問題として発生している事象（事実）の背景や周辺を分析して、真に解くべき課題を洗い出す必要があります。

例．Ａさんの作業ミスが発生した場合の原因追及
Ａ「睡眠不足の上、焦ってしまって、注意力散漫でミスしてしまいした。」
上司「どの程度睡眠不足なの？（事実確認）」
Ａ「ここのところ１日２時間ほどしか眠れていません（問題）」
上「なにか気になることや体調不良とかあるの？（原因追求で課題抽出）」

なんで？　周辺事実は何？　表面上見えないけど隠れていることは？
経験や知見から推測できる真の課題は？
と追及していって、はじめて課題にたどり着くのが通常です。

こうした課題の追求が、正しく考える上では極めて重要です。

（２）課題解決アプローチと解決仮説
ここまで述べたことで、問題解決のアプローチと課題解決のアプローチが、事実認識、背景認識・確認の点で大きく異なることは分かると思います。

次に、真の課題を解決する手法は、解決仮説の立案と仮説検証です。

真の課題が分かったら、こうすれば解けるのではないか？という仮説を立てます。この時点では大雑把なざっくりとした内容でも構いません。また、荒唐無稽に思える思い付き的なものでも構いません。

初期の仮説ではいきなり細かいことは考えられないのが普通です。
よって、大きな方向性が間違ってなければ、考えを進める過程で精緻化していけば良いです。
「この先の道を、北北西に向かって時速10ｋｍで進め」
といった精緻な内容よりも、
「南には決して向かうな」
「北の東寄りではなく西寄りに進め」
といった方向性をできるだけ早く見極めるのがコツです。

また、解決策が荒唐無稽に見えても、そうではなくても、思いついた策の精緻化には追加の事実情報収集が必要になります。

例．（　仮説　）新支店設立が必須
＜　追加必要事実　＞
支店要員は自社内で確保できるのか？　どこに出店可能か（用地や競合）？
どの程度の規模が妥当なのか？　集客は見込めるのか？
初期投資はどの程度か？　等々

こうした仮説立案ステップで、課題解決に向けてアプローチしていきます。

（３）仮説検証
解決仮説（Hypothesis）は検証して初めて解決策（Solution）となります。
よく、解決仮説段階で実行に移そう（結論としよう）とする人がいますが、それは危険なやり方です。失敗するリスクやその大きさが分からないまま、実行する（結論として説明する。実際に運用する）のは無謀です。

仮説の検証方法には、
●机上検証
　詰め将棋のように、このやり方をしたらこういう場合はこうなるはず、
　と考えられるパターンを網羅的に検討してみる（MECEの視点）。
　軍隊などでは机上演習（兵棋演習）として実践されます。
●実地検証
　実際にやってみる。
　全部門/全範囲ではなく部分的にやる方法と、全検証する方法がある。
等がありますが、一般的には机上検証または部分実地検証になります。
（システム開発などでは、検証するパターンを決めて、シナリオとして複数実施したりします）

この検証まで終えてやっと正しい考えの終了で、次は実行段階となります。

５．正しく伝える（１）（結論よりも前提に時間をかける）

経験上、人は自分の経験、知識から計り知れない新たな内容は、本能的に疑ってかかるものです。

また、前回「＜その１＞　３．正しく考える（２）（正確な論理展開）」でも述べたように、伝えるべき多くの場合は、その領域の専門家、責任者、関心が強い人々です。

我々が正しく伝えるべき人々は責任ある立場（偉い人）ですから、一般人以上に自分の守備領域に関しては疑り深いもの、と考えるべきです。

そこで、解決策の説明をするときは、
　どうやって（How）解決する、進めていく、考える
よりも、
　なぜ（Why）そのように考えるべきか、根拠は何か
に時間をかける方が、最終的な合意にかかる時間が短くて済みます（経験則です）。また納得感の観点でも、途中に疑義が生じにくいので重要と考えます。
（疑問は、質疑等で一杯出るはずです）

良くコンサルティングの本などでは、
　エレベーターテスト
（多忙なCEOにエレベーター乗車の数分で必要な内容を伝えきれるか？）
といったものが出ています。
この場合でも、Whyを必ず一言は入れないと、聞き流されるのがおちです。

なお、この記事ではプレゼンテクニックは煩雑になるので述べません。
ただ一言だけ述べると、いくらWhyの説明に時間を割くべきと言っても、説明の最初から、結論も述べずに、
「これがこうなります。そしてこれはこうです。なので、こうなるため…」
と延々続けていくと、
「早く結論言え」
となるので、プレゼンテクニック（説明順序や聴かせるための方法論）は疎かにはできません。
（機会があれば、別記事で書こうと思います）

６．正しく伝える（２）（１度に多くを述べない）

心理学的に、人が未整理の状態の内容を理解し記憶できるのは、３つ程度、多くて５つと言われます。また集中力の観点でも、15分程度が限界でそれ以上前のことは記憶からどんどん落ちていきます。

学習、ビジネス系 Youtube 動画などでは、多くは15分程度、長くても20分くらいのものが多いと思います。
また、最初に箇条書きで３点から５点の要点を述べて、各々の説明が終わったら、最後に箇条書きメモを見ながら復習する、というスタイルが主流だと思います。
これは、上記の観点から理にかなっています。
なお、どういう訳か、整理するポイントは偶数ではなく奇数項目（３とか５）が頭に残りやすいようです。

さらに１項目の説明には、原則として１枚の説明書というのが望ましいです。１要点を説明するのに、２枚３枚と枚数を重ねると、聞き手・読み手は混乱しますし、記憶保持ができなくなります。
（ひいては途中で飽きてしまって聞いてくれなくなります）

もちろん複雑な内容は１枚の説明では無理です。
よって、章・大項目・中項目という風に内容を細分化していきます。
ただ、余りにも長くするのも考えもので、この辺のバランス感覚は経験を積んで身に付けるしかありません。

ちなみに、トヨタ自動車の社内説明資料は、どんなに複雑なものであってもＡ３片面１枚のみ、と決められているようです。
（私もいくつかその内容を見せてもらったことがあります）

６．さいごに（人格、人間性といった要素も極めて重要）

考え方を精緻に積み上げる、正確に人に伝える、というのは才能ではなく、頭の良さでもなく、努力です。それも正しい方向性の、地道な努力です。

人は、真摯にかつ丁寧に積み上げられたロジックを、奢ることなく（上から目線とか、偉そうにしない）、正しいテクニックをもって語ってくれる人は間違いなく信頼します。
（もちろん内容が箸にも棒にも掛からないものでは馬鹿にされます）

この態度は一般的には、人格とか人間性とか言われる類だと思いますが、これが身について聴衆の信頼感を勝ち取れば、２回目以降の話は非常にしやすくなる、と心掛けるべきです。