「物は言いよう」とはよく言ったもので、あるひとつの事象から、別の結論を引き出すことはそれほど難しいことはありません。政治家や思想家がよくやってますので、例はそれこそ枚挙にいとまがない状態ですね。
何か話をしようとしたり、メールなど書き物をしようとしたりするときも、「物は言いよう」でどのような結論にももっていけます。ところが時々、話し始めてから結論を考える事があるようで、そうすると話しているうちに「あれ、自分は結局何がいいたんだっけ?」というのがわからなくなってしまうことがあります。
そうならないためにも、心がけているのが
トップダウンアプローチ
これは、バーバラ ミントの名著「考える技術・書く技術」
考える技術・書く技術―問題解決力を伸ばすピラミッド原則
という本で読んだのですが、考えるプロセスというのは2通りあるそうです。
ひとつが、いろいろな事例を集めて、そこから結論を導き出す「ボトムアップアプローチ」。
そしてもうひとつが、まずゴールを考えて、そこからその命題に合うようにものごとを解釈していくトップダウンアプローチです。
本書ではトップダウンアプローチの方が優しいと書かれていますが、実際、この考え方で説明してもらったほうが納得感があります。つまり、説得しやすい。
ほとんどの方は、ビジネスの進め方はよくご存知でしょうが、まずゴール(目標)があって、それに対して様々なアプローチを考えて、それを時系列に並べ直して活動されていると思います。
■まず答えを作る
何かを考えだすにしても同じ事なのですが、これが結構やれてない人が多い(自分も若い頃はそうだったような気がします)。もちろん、人に説明するときにはいきなり結論から話すのではなく、ちゃんと前提を話さないといけないのですが、考えるときには逆に、まず目標を定めて、それに必要な論理を上から順に組み立てていくと筋道の通った説明になります。
この記事も、まず書きたいこと有りきで、そこからいろいろな情報をふくらませて書いています。
「考える技術・書く技術」はこれを「ピラミッドを上から埋める」という表現をしていて、最初に考えるべきこととして
1.主題(伝えたいメインテーマ)は何か?
2.主題について読み手のどんな疑問に答えようとしているのか?
3.答えは何か?
が最初に考えるべきこととして提示されています。
■導入部を作る
次にやるべきは、どのような事実を取り上げるのかを考えること。
今起きていること、答えに行き着いた最初の取っ掛かりを見つけます。
それをリストアップします。
多くの人は、ここで1つだけの事象や取っ掛かりしか用意してません。
そうすると、それを否定する事象などが簡単に提示できるので、相手の結論を否定するのもそれほど難しくありません。
ですので、これをしっかり用意することは、自分の議論したい課題とその結論を通しやすくするためにとても重要です。
特に、話をする相手やメールを送る相手が、「何に興味があるか」によって適切な導入部は変わってきます。ここを間違うと結論は受け入れてもらえませんので、しっかり考える必要があります。
例えば、営業の担当者に新しいサービスを理解してもらうために、「クラウド技術が世の中に広まっている」という事を強調しても響かないですが、「顧客がクラウドを使ったコストダウンに興味があるというアンケート結果」なら興味を持ってもらえるでしょう。
逆に技術屋に「顧客の業務の効率化」をといても響きませんが、「クラウドとスマホの連携技術」なら興味を持ってもらえるでしょう。
同様に、役員に「生産品質の向上」について話をするより、「生産コストの削減」の方が興味を持ってくれるわけです。
■導入部と答えを一致させる
そこから、どういう結論に導くかは、首記の「物も言いよう」というやつです。
それぞれに出した導入部から結論に導くルートを作ります。
出した導入部から、「風が吹けば桶屋が儲かる」というつながりを作ります。
つなげ方も多種多様にあるので、いろいろなつなげ方をしてみます。
風が吹く
↓
ホコリが目に入る
↓
メクラが増える
↓
三味線が売れる
↓
猫が減る
↓
ネズミが増える
↓
桶がかじられる
↓
桶屋が儲かる
というルートでもいいですし、
風が吹く
↓
火事が起きやすくなる
↓
防火用水の需要が増える
↓
桶が必要になる
↓
桶屋が儲かる
でもいいわけです。何度も出てきますが、どういう方法でも論理付けられるものです。
これをあるひとつの論理に固執してしまうと、話が硬直し、一点が否定されると論理が崩壊してしまいます。
■キーラインを見つける
色々出したたくさんの「ピラミッドの底辺」とたった一つの「ピラミッドの頂点」を結ぶ、たくさんの論理の線から、今の状況と相手にとって最もふさわしいものを見つけます。
これを「考える技術・書く技術」ではキーラインと呼んでます。
これを見つける方法は、私はあまり知りません。
私の場合は、経験と勘に頼ってます。
ですので、たくさん失敗をして、「あの時、こういう風に論理を組み立てていればよかったな」と反省することで洗練されていくものだと思ってます。
■まとめ
まず結論ありきです。
どのような結論に持って行きたいかを決定し、それを補強するための事象を相手に合わせて考えだす。そして、相手が納得しやすいような論理構成を考え、そこからキーラインを見つけて、やっと話ができるようになります。
会議でも、まず喋り出すのではなく、これを頭のなかで、ガーッと一気に回して、そこから喋り出しましょう。
話をする、文章を書く時には、
結論→事象→キーライン
でも
事象→キーライン→結論
その状況にそって話をすればいいです。
文章の場合は前者(結論が先)が、話の場合は後者(結論が後)が好まれるようですが。
これは組織によっても差異があるかもしれません。
■参考図書
★アマゾン
考える技術・書く技術―問題解決力を伸ばすピラミッド原則★楽天
入門考える技術・書く技術
著者:山崎康司
価格:1,575円(税込、送料込)
楽天ブックスで詳細を見る
■同じテーマの記事
●期限はローリングで解釈する
よく「今週中にやります」とか言ってません?私は過去にこれでよく失敗しました。今週中はあと何日?多分、今日が金曜日なら、きっと「今週中に…」とかは言わないでしょう。金曜日の午後5時は、今週中が終わるまでにあと1時間しかありませんから。ただ、水曜日や木曜日だと、意外と軽く「今週中…」と言っちゃうかもしれません。木曜日で「今週中」と言っちゃうと、「明日中に」と言っているのと同じなのですが、言い換えると結構「やばい…」と思..●読書のアウトプットの増やし方
「インプットをしたらアウトプットしないといけない」過去記事でもこういうことを書いていますし、多くのビジネス書にも書いてあります。おそらく何かに習熟するためには普遍的に必用なことかと思いますが、ビジネス書などに取り上げられているのは、たとえば、「本を読んだら読書感想文を書きなさい」とか「人に教えなさい」とか、結構ハードルが高いことが書かれてます。私も本を読んだら、殆どの場合は読書記録(感想文ではない!)を書いてますし、本ブログに自分のコメントを付けて公開したりしてます。..●タスクリストには2つの目標を併記する
タスクリストって作ってますか?もし作っていない人は、作ったほうがいいと思いますが、この記事は読んでもあまりメリットはありません。作っている人は、ちょっと参考になるかも。タスクリストの目標あなたの作っているタスクリストって、どんな項目がありますか?私の場合、・名称・目標1・目標2・着手期限・完了期限::こんなのがリスト化されています。本日は、この目標1と目標2の2つ目標がある理由について。「企画書を作れ!」上司に「来週中にの企画書を作れ!」..●予定したタスクがなくなった時に消せますか?
私は基本的に仕事はゴールから考えて、それを分割してタスクリストを作ります。ピクニックに行くアウトプットから始めるトップダウンアプローチ長期計画は決めないなどで書いたように、最初にゴールがあって、それをいろんな軸で分割して計画を立てます。分割される基本単位がいわゆる「タスク」です(私は最小単位をToDoと呼んでます)。ところが、こういう計画法だとうまくいかないことがあります。たとえば、タスクAがうまく行っ..●業務改革の教科書1
あなたがもし、何かのプロジェクトのリーダーをやっていたり、組織を率いる管理職なのであれば、この本は絶対に読んでおいて欲しい本です。私は、この本の目次をマインドマップに書き出して、時々見返しています。管理職やリーダーに要求されることは、すごく簡単に言ってしまえば、組織力を使って会社に直接貢献できる成果を出すことです。そして、組織を改革して、常に効率を改善し続けることです。本書は、社内の結構大きな業務改革をするときに、必要なことが過不足なくリストアップされていますので..●Astah
UMLって御存知ですか?またいつものようにWikipediaから引用統一モデリング言語(とういつモデリングげんご、UML、英: Unified Modeling Language)はソフトウェア工学におけるオブジェクトモデリングのために標準化した仕様記述言語であり、グラフィカルな記述で抽象化したシステムのモデル(UMLモデル)を生成する汎用モデリング言語である。最初期の版はラショナルにおいて、グラディ・ブーチ、イヴ..