yfj2’s Automatic Web Test Related Blog

yfj2のWEBテスト自動化に関わるブログ

ロジカルシンキングについて再考する

著者:ふじさわゆうき

更新日:2016/07/27

システムエンジニアになって、かなりの年月がたちました。

最近は、Webの世界からアプリに世界が広がったことで、多くのことを業務で扱いますが、毎日覚えることが沢山あって大変です(そもそも何を勉強したらよいのかわからないときも・・・)。

そういう状況では、基礎的な学習しておくことで、業務での能力向上が見込めると考え、基礎的な勉強に1日1時間くらい時間を作ることにしました。

まずは、システムエンジニアの基礎である「ロジカルシンキング」について再考してみることにします。

以下、何回かに分けて「ロジカル・シンキングー論理的な思考と構成のスキル」を要約します。

本書は、私が大学院のときにコンサル会社に勤めていた友人から勧められたもので、修士論文を作成したり、レポートを作成するのにとても役に立った非常に良い本です。

対象書籍

ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)

ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)

第1章 相手に「伝える」ということ

  • ビジネスの世界では世界では、自分の考えや提案が、
    • 相手の頭に正しくインプットされ、
    • 思考回路の中で正しく理解され
    • 自分が望む反応が出てくる
  • までの時間が勝負になる
  • 大事なことは「あなた」が大切だと思っていることではない。それが相手にとって期待されている「メッセージ」になっているかどうかである
  • 自分の考えを論理的に伝える第一歩。それは「いきなり伝える中身について考え無いこと」

相手に伝えるべきメッセージとは?

  • メッセージとは何か。以下3つの条件を満たしているものだ
  1. 答えるべき課題(テーマ)が明確であること
  2. その課題に対して、必要な要素を満たした答えがあること
  3. そのコミュニケーションの後に、相手にどのような反応をしたもらいたいのか、つまり相手に期待する反応が明らかであること
  • 「課題」「答え」「相手に期待する反応」の3点セットが、本書で定義するメッセージである
  • つまり、人の話を聞いたときに、「課題」はこれで、それに対する相手の「答え」はこれで、「自分にこれをしてほしい」ということが頭に明確に残ることをクリアして初めてメッセージとなる。
  • 重要なことは、①課題(テーマ)を確認する②相手に期待する反応を確認する、という2つの確認作業をすることだ
確認1:課題(テーマ)を確認する
  • 自分が相手に答えるべき課題は、何なのか、確認しよう
  • 相手が「今検討すべき課題」と認識していなければ、議論の土俵にすら登れない
確認2:相手に期待する反応を確認する
  • 相手にどのようにしてもらいたいのか、どんな反応を引き出したいのか、という期待成果の無いコミュニケーションは「独り言」でしかない
  • 伝えることによって、相手に理解してもらったり、相手のニーズや意見を引き出したり、あるいは相手に何かのアクションを取ってもらうなど、相手になんらかの「反応」をとってもらうことが最終目的であるはずだ。伝えることは手段であり、目的ではない!
  • ビジネスにおいて、相手に期待する反応は以下、3つにまとめることができる
  1. 相手に理解してもらう
    • 業務連絡、事務連絡はこのケースに当てはまる
  2. 相手に「意見や助言、判断などをフィードバック」してもらう
    • ヒヤリングやテストマーケティングで顧客のニーズを引き出す場合がこれにあたる。社内での会議や報告なども該当する
  3. 相手に行動してもらう
    • キャンペーンへの参加依頼などを実施する場合、アンケートに答えてもらう場合はこのケースに当てはまる
  • 同じ課題であっても、相手に「理解」してもらいたいのか、「意見や助言、判断をフィードバック」してもらいたいのか、「アクション」を取ってもらいたいのか、という相手に期待する反応を確認することによって、答えとして伝えるべき深さや広がりは大きくことなることは想像できるだろう

何を言えば「答え」になるのか?

  • 以下の質問にイエスと答えられるかどうかが、課題に対する答えの要素があるのか、無いのかのチェックポイントである
    1. 課題に対して、伝え手が、どのようなアクションを取るべきだと言っているのか?
    2. イエスなのか?ノーなのか?
    3. 結論に至った根拠に納得感があるか?
    4. 結論がアクションの場合、具体的なやり方が示されているか?
    5. 自分がそのアクションについて部下に指示を出す場面を想定した時、指示の中身が具体的にイメージできるか?
  • 「結論」 -> 「根拠」 -> 「方法」
    • 結論: 課題に対する答えの核をなすもの。何かのアクションを提示する場合と、評価や判断を表すものの2つがある
    • 根拠: その結論にどうして至ったのかという理由。事実と判断の2つがある
    • 方法: 結論がアクションの場合、相手がそのアクションを取れるよう、具体的なやり方を提示するもの

なぜ、相手に自分の「答え」が通じ無いのか?

理由1. 結論が「自分の言いたいことの要約」になってしまっている
  • 「要するに、どっちなの?」という発言が相手から出てしまっては、コミュニケーションは失敗
  • 本当に答えるべき課題に対する答えの核になっているかを常に見直すべき
  • いかなる場合も、課題と答え、答えの核となる結論は整合していなければならない
理由2. 「状況に応じて」「場合によっては」の基準が曖昧
  • 相手に結論が明確に伝わる、という点で留意すべきなのは、どうにでも解釈できるような曖昧さを排除する、ということだ
  • 「状況によっては」「場合によっては」と曖昧なな言葉ではなく、「売り上げが前年度比105%を上回ったら」など定量的な言葉にしたり、定性的な中身を具体的に伝えるかによって、明確にすることである

根拠が伝わらない時の3つの落とし穴

  • 結論が正しくてもなぜそれが正しいのか、すなわち根拠が正しいと説明できなければ相手を納得させることはできない
  • 以下、3点を留意するだけでも、その精度は高まる
    1. 「Aが必要だ、なぜならAが無いからだ」では、相手は納得しない
    2. 「それは事実なのか?それとも判断仮説なのか?」と思わせた途端に信ぴょう性は半減する
      • 例えば、「当社の売り上げ不振の原因は、時代の空気をうまくとらえていないからだ」と言われた場合に「うまくとらえていない」は「事実なのか判断なのか」が聞き手が判断できない。もし、事実だとすれば、具体的にどのような現象をさしているのか示すべきだし、そう判断したのであれば、根拠を明快に示さなければ根拠を説明したことにならない
    3. 与えられた課題に、答えを出すに上で事実に対してどうみるのか、という判断軸、もしくは前提条件が示されていない。

方法が伝わらないときの2つの落とし穴

  1. 他の会社、10年前でも通用するような公理では人は動かない
    • 教科書に書かれているような公理をいうのではなく、公理を自分の企業に当てはめて、具体的に何をすべきかを伝えなければ意味が無い
  2. 修飾語で物事が具体的になることはない
    • 自分で方法を書いてみて、どうも具体的ではないと思ったら、それは問題が具体的に解けていないということである
    • 具体的に書くためにはどうすればよいのか。そのためにはなぜなぜすることが重要である
      1. 客からのクレームが多い > なぜ?
      2. 商品の故障そのものより対応の仕方に不満が高い > なぜ?
      3. 販売員は、販売には熱心でも修理対応には関心が無い
    • 以上のように「なぜそうなっているのか」の質問を繰り返すことで初めて具体的な方法がみえてくる
    • 具体性があるかどうかをチェックするときにおすすめなのは、「自分がその実施者の立場だったら、何を知っていれば具体的に動けるのかと自問自答してみることだ」
    • どうやって?どの程度?いつからいつまでに?誰が主体で? etc