ロジカルシンキングが大事だということは、みんなわかっています。

研修で学んだ。本も読んだ。5W1HもMECEもピラミッドストラクチャーも、知識としては頭に入っている。

でも、いざ仕事で使おうとすると、こうなりがちです。

「で、結局なにが言いたいの？」と言われる
資料を作ったけど、相手の反応が薄い
フレームワークに当てはめたけど、なんかしっくりこない

知っているのに、使えない。

「もっと論理的に考えなきゃ」と思うほど、逆に頭がこんがらがっていく。そんな経験はないでしょうか？

実はこれ、ロジカルシンキングの「使い方」ではなく、「目的」の捉え方がズレていることが原因です。

この記事では、ロジカルシンキングの本当の目的を再定義した上で、現場で再現できる実践的なやり方を解説します。

この記事でわかること

ロジカルシンキングの本当の目的（なぜ必要なのか）
現場で使える実践3ステップ（わける・つなげる）
「これもフレームワークだったのか」という気づき

ロジカルシンキングとは何か

目的は「論理的に考えること」ではない

そもそも、ロジカルシンキングは何のためにやるのでしょうか？

「論理的に考えるため」と答えたくなりますが、これは手段の話です。

ロジカルシンキングの本当の目的は、人を動かすことです。

論理的に考えて、情報を整理し、それを伝えて、伝えた相手に動いてもらう。ここまでがロジカルシンキングの守備範囲です。

つまり、どれだけきれいに論理を組み立てても、相手が動かなければ意味がありません。

ロジカルシンキングの目的
相手を動かすこと！
(論理的に考えること自体ではない)

人はどうすれば動くのか？

では、人はどうすれば動くのでしょうか。大きく分けると、2つのパターンがあります。

① 感情が動いたとき

熱狂、感動、危機感。なんらかの感情が揺さぶられたときに、人は動きます。

ただ、これはロジカルシンキングの領域ではありません。プレゼンの話術やストーリーテリングの世界です。ちなみに、相手の感情を動かすことができれば、ロジカルシンキングなんて不要です。

② 納得感を持ったとき

「なるほど、たしかにそうだな」と腹落ちしたとき。人は納得感を持つと、自分から動きやすくなります。

ロジカルシンキングが対処するのは、こちらです。

情報を論理的に整理し、相手の納得感を引き出す。納得感があるから、相手は自分の意思で動ける。そのために、ロジカルシンキングを使うというわけです。

論理＝つながり

ここで「論理」という言葉を整理しておきます。

論理と聞くと、なんだか難しく感じるかもしれません。でも、やっていることはシンプルです。

論理とは、情報のつながりのことです。

「Aだから、B」「Bだから、C」。このように、情報と情報がつながっている状態が、論理的な状態です。

逆に、AとBとCがバラバラに並んでいるだけだと、相手は「で、結局なにが言いたいの？」となります。つながりがないからです。

つまり、論理的とは、相手にとってわかりやすく、納得感のある情報のつながりがある状態のことです。

ロジカルシンキングの定義

ここまでを整理すると、ロジカルシンキングはこう定義できます。

ロジカルシンキングとは、人を動かすために、納得感のある情報のつながりを作る思考法

「論理的に考える」こと自体がゴールではなく、相手が納得して動ける状態を作ることがゴールです。

この目的を見失うと、フレームワークに当てはめること自体が目的になったり、きれいな資料を作ること自体が目的になったりします。

ロジカルシンキングの実践3ステップ

ここからは、具体的なやり方を解説します。

ロジカルシンキングでやることは、大きく3つのステップです。

誰をどう動かすかを決める
情報をわける
情報をつなげる

この3ステップを、具体例を使いながら説明していきます。

例として使うケース

今回は、こんなケースを使います。

あなたは既存システムの改修案件を担当しているPMです。
企画部門からの要望が次々と追加され、スコープが膨らみ、プロジェクトが遅延し始めています。このままでは納期に間に合わない。先輩PMに相談して、アドバイスをもらいたい。

よくありそうな状況ですよね。

この「先輩PMに相談する」というシーンを通して、ロジカルシンキングの3ステップを実践していきます。

STEP1：誰をどう動かすかを決める

ロジカルシンキングの目的は、人を動かすことです。だから、最初にやることは 「誰を」「どう動かすか」を明確にすること です。

これを決めないまま情報を整理し始めると、「で、何のための整理だっけ？」と迷子になります。

「誰をどう動かすか」を言い換えると、「誰に、どう動いてほしいか」 です。

例えば、仕事でよくあるパターンはこの3つです。

パターン	誰に	どう動いてほしいか
承認	上位者（上司・決裁者）	提案を承認してもらう
共有	メンバー・関係者	内容を理解して動いてもらう
相談	相談相手（先輩・有識者）	状況を理解してアドバイスをくれる

今回のケースだと、こうなります。

誰に：先輩PM
どう動いてほしいか：プロジェクトの状況を理解した上で、具体的なアドバイスをくれる

ここが曖昧なまま相談に行くと、「で、俺に何をしてほしいの？」と言われがちです。

逆に、ここが明確だと、「じゃあ、そのためにどんな情報を伝えればいいか？」が自然と見えてきます。

STEP2：情報をわける

動かしたい相手と、動いてほしい方向が決まりました。次は、そのために必要な情報を整理していきます。

ここでやることは、情報をわけることです。

「わける」とは、相手を動かすために必要な情報を、意味のあるかたまりに分類することです。

やりがちなNG：頭にあることを、思いついた順にそのまま伝える

思いついた順に話すと、相手は「結局、何が言いたいの？」となります。なぜなら、情報がわけられていないからです。独立した情報を次々に投げられても、相手は整理が追いつかず、混乱するだけです。

では、今回のケースで考えてみましょう。先輩PMから的確なアドバイスをもらうためには、どんな情報が必要でしょうか？

相手の立場になって考えてみます。先輩PMがアドバイスするためには、最低限こういう情報が欲しいはずです。

プロジェクトの状況：今、何が起きているのか？
困っていること：何が問題なのか？
相談したいこと：何についてアドバイスがほしいのか？

こうやって情報をわけてみると、伝えるべきことの輪郭が見えてきます。

さらにもう一段、わけてみましょう。「プロジェクトの状況」をもう少し具体化すると、こんな感じです。

プロジェクトの概要（何の案件か）
現在のフェーズ（今どこにいるか）
遅延の原因（なぜ遅れているか）

このように、大きなかたまりをさらに小さくわけていくことで、情報がどんどん具体的になっていきます。

「わける」のコツ

まずは大きく3〜4つにわける
足りなければ、もう一段わける
相手の立場で「これがあればわかる」を考える

STEP3：情報をつなげる

情報をわけたら、次はつなげる作業です。

「つなげる」とは、わけた情報を相手が理解しやすい順番で並べることです。

情報をわけただけでは、まだ「点の集まり」です。これを線にして、相手の頭の中にストーリーを作ります。言い換えると、論理的なつながりを作るということです。

今回のケースで、わけた情報を並べてみましょう。

先輩PMの立場で考えると、こんな順番で聞けると理解しやすいはずです。

1. プロジェクトの状況（前提を共有する）

既存システムの改修案件を担当している
現在、要件定義フェーズ

2. 困っていること（問題を明確にする）

企画部門から要望が次々追加されている
スコープが膨らみ、遅延し始めている
このままでは納期に間に合わない

3. 相談したいこと（期待するアクションを伝える）

スコープの絞り込み方について、アドバイスがほしい
企画部門との調整の進め方についても意見を聞きたい

この順番が大事です。

もし「スコープの絞り込み方を教えてください」からいきなり始めたら、先輩PMは「え、なんの案件？」「なんで絞り込みが必要なの？」となりますよね。

状況 → 問題 → 相談 という流れにすることで、相手は自然と文脈を理解し、的確なアドバイスがしやすくなります。

つまり、情報のつなげ方（＝並べる順番）によって、相手の理解のしやすさが変わるということです。

「つなげる」のコツ

相手の頭の中で「なるほど → なるほど → だからこう動けばいいんだな」となる順番を考える
前提や背景を先に伝え、結論や依頼は後に置く（相談の場合）
「この情報があるから、次のこの情報が理解できる」という依存関係を意識する

フレームワーク＝「わける」と「つなげる」のパッケージ

ここまで、「わける」と「つなげる」を実践してきました。

ところで、フレームワークってよく聞きますよね。MECE、ピラミッドストラクチャー、5W1H……。

フレームワークとは何かを一言でいうと、「わける」と「つなげる」のパッケージです。

どのように情報をわけるか
どの順番でつなげるか

この2つをセットにして、再利用しやすい形にまとめたものがフレームワークです。

実は、PMが日常的に使っているものの中にも、フレームワークはたくさんあります。

① 背景 → 課題 → 対応方針

上司への報告や関係者への提案でよく使う流れです。

順番	内容	役割
背景	なぜこの話をしているのか	前提を揃える
課題	何が問題なのか	問題を明確にする
対応方針	どうするのか	アクションを示す

さっきの先輩PMへの相談も、実はこの構造に近いです。

背景：既存システム改修案件で企画要望が止まらない
課題：スコープ膨張で遅延している
対応方針：スコープ絞り込みの方法を相談したい

「背景→課題→対応方針」と聞くと、あらためてフレームワークだと意識する人は少ないかもしれません。でも、これは立派なフレームワークです。情報を「背景・課題・対応方針」にわけて、この順番でつなげる。まさに「わける＋つなげる」のパッケージです。

② プロジェクト工程

要件定義 → 設計 → 開発 → テスト → リリース。

PMなら毎日のように使っている、おなじみの分類です。

進捗報告のとき、工程ごとに状況を整理して報告しますよね。あれも実は、プロジェクト工程というフレームワークで情報をわけて、つなげているのです。

例えば、プロジェクト全体の進捗を報告するとき：

要件定義：完了。要件一覧は確定済み
設計：詳細設計が80%完了。残りはバッチ処理部分
開発：来週から着手予定
テスト：テスト計画を作成中

工程ごとにわけることで、「今どこまで進んでいて、どこに課題があるか」が一目でわかります。

フレームワークは、難しいものだけではない。

PMが日常的にやっている「工程ごとに整理する」「背景→課題→方針で報告する」も、立派なフレームワーク。「あ、これもフレームワークだったのか」と気づけると、意識的に使い分けられるようになります。

フレームワークというと、3Cとか4PとかSWOTとか、コンサルタントがよく使ってるものと思いがちです。でも、実は身近なところにたくさんあります。例えば他にも、過去・現在・未来や背景・目的・目標、メリット・デメリットなんかもフレームワークと言えます。

もやもやした情報を整理するための切り口と、情報のつなぎ方をパッケージにしたものは、なんでもフレームワークと言えます。

実体験：機能削減を了承してもらえた話

ここで、私自身の体験を共有します。

ある営業系システムの案件で、セキュリティ上の理由から特定の機能を削減しなければならなくなりました。

ただ、この機能は営業部門にとって重要な機能です。簡単に「なくしていいですよ」とは言ってもらえない。

Before：シンプルに聞いたらNG

最初は、ストレートに聞きに行きました。

「セキュリティの都合で、この機能は使えなくなりますが、大丈夫ですか？」

結果は、NG。当然です。

営業からすれば、自分たちが使っている機能を「なくなるけどいいですか？」と聞かれても、「いいですよ」とは言えません。判断するための材料がないからです。

After：情報を構造化して持っていった

そこで、アプローチを変えました。

まず、誰をどう動かすかを明確にしました。

誰に：営業部門の責任者
どう動いてほしいか：機能削減を了承してもらう

次に、了承してもらうために必要な情報をわけて、相手が判断しやすい順番につなげました。

1. 背景：セキュリティ監査でNGが出た事実

2. 課題と対応方針：このまま放置するとどうなるか、取りうる選択肢は何か

3. メリット・デメリットの比較：機能を残した場合と削減した場合、それぞれ何が起きるか

4. 選択肢の提示：最終的にどうするかは、営業部門に決めてもらう

結果、了承をもらえました。

なぜうまくいったのか

振り返ると、やったことはシンプルです。

誰をどう動かすかを決めた（STEP1）
相手が判断するために必要な情報をわけた（STEP2）
相手が納得しやすい順番でつなげた（STEP3）

最初の「大丈夫ですか？」は、STEP1しかやっていませんでした。情報をわけてもいないし、つなげてもいない。だから、相手は判断できなかった。

2回目は、3ステップを踏んだことで、相手が自分で判断できる状態を作れました。相手は「納得して、自分の意思で了承した」のです。

これが、ロジカルシンキングで人を動かすということです。

まとめ

この記事では、ロジカルシンキングの目的と実践方法を解説してきました。

まず、大前提として押さえておきたいのはこれです。

ロジカルシンキングの目的は、論理的に考えること自体ではない。人を動かすことが目的。

そして、人を動かすための実践3ステップはこちらです。

誰をどう動かすかを決める（ゴールを明確にする）
情報をわける（必要な情報を意味のあるかたまりに分類する）
情報をつなげる（相手が理解しやすい順番で並べる）

フレームワークは、この「わける」と「つなげる」のパッケージです。難しいものだけでなく、「背景→課題→対応方針」や「プロジェクト工程」のように、PMが日常的に使っているものもフレームワークです。

ロジカルシンキングは、特別なスキルではありません。「相手に動いてもらうために、情報をわけて、つなげる」。これだけです。

次に誰かに何かを伝えるとき、まず「誰をどう動かしたいか？」から考えてみてください。それだけで、伝わり方が変わるはずです。

おまけ：NGパターン

最後に、ロジカルシンキングでやりがちなNGパターンを紹介します。「あ、やってるかも」と思ったら、改善のチャンスです。

NG① 情報のつながりがない

情報はたくさん集めた。でも、点の集まりで、全体として何を言っているかわからない。

スライドごとに情報は書いてある
でも、スライド同士のつながりが見えない
「で、結局なにが言いたいの？」と言われる

これは、「わける」はできているが、「つなげる」ができていない状態です。

情報をわけた後に、「この順番で並べると、相手はどう理解するか？」を考えてみてください。前の情報が、次の情報を理解するための土台になっているか。この依存関係が、つながりです。

NG② 抽象度が高い

なんとなく整理されている気がする。でも、ふわっとしていて、具体的に何をすればいいかわからない。

「業務効率化を推進する」
「品質向上に取り組む」
「関係者と連携を強化する」

聞こえはいいけど、中身がない。これは、「わける」が足りていない状態です。

「業務効率化」をもう一段わけると何になるか。どの業務の、どの工程の、何を効率化するのか。わける回数が足りないと、抽象的なまま止まってしまいます。

対策：「具体的に言うと？」を自分に問いかける。
もう一段わけられないか、もう一段具体化できないかを繰り返すことで、抽象度を下げていきます。

NG③ フレームワークを使っているだけ

3CやSWOTなど、フレームワークに情報を当てはめた。でも、「それで何がわかったの？」と聞かれると答えられない。

フレームワークの枠は埋まっている
でも、そこから何を読み取るかが不明
フレームワークを埋めることが目的になっている

これは、「誰をどう動かすか」が決まっていない状態です。

フレームワークは手段であって、目的ではありません。「この人にこう動いてほしい」があって初めて、「じゃあ、どうやって情報をわけて、つなげようか」という問いが立ちます。

目的なくフレームワークを使うと、きれいに整理されているけど誰も動かない資料ができあがります。

対策：フレームワークを使う前に、必ず「誰をどう動かすか？」を言語化する。
それがないまま整理を始めると、整理のための整理になってしまいます。

関連記事