AIが論点をMECEに分解する時代に、人間にロジカルシンキングはまだ必要なのか

企業研修で「ロジカルシンキング」は、ほとんど必修科目のように扱われている。新卒研修でも、管理職研修でも、資料作成研修でも、MECE、ピラミッドストラクチャー、フローチャート、因果関係、仮説思考といった言葉が出てくる。

それ自体は悪いことではない。複雑な問題を分けて考えること、言いたいことを順序立てて話すこと、相手が迷子にならないように構造を示すことは、仕事の場面では確かに役に立つ。

ただ、いまは前提が変わっている。AIに頼めば、MECEな分解も、業務フロー図も、リスク一覧も、下書きとしては数秒で出てくる。きれいな箱を作るだけなら、それ自体の価値は以前より下がっている。

では、ロジカルシンキングの価値はどこに残るのか。

本質は、きれいに分けることではない。自分が置いた分け方を疑うことにある。

目次

論理は「もっともらしさ」ではない

論理というと、難しい言葉に聞こえる。だが、古典的な三段論法はとても素朴だ。

人はみな死ぬ。

ソクラテスは人である。

だから、ソクラテスは死ぬ。

この推論が成り立つのは、前提と結論の関係がはっきりしているからだ。結論だけを見ると「ソクラテスは死ぬ」という一文だが、その前には「人はみな死ぬ」「ソクラテスは人である」という二つの前提がある。

仕事の場で危ないのは、この前提が見えないまま結論だけが論理的に見えてしまうことだ。

たとえば、会議でこう言う人がいる。

「問い合わせが多い。だからFAQを整備すべきだ」

一見、筋が通っている。しかし、隠れている前提を出すと、すぐに揺らぐ。

  • 問い合わせが多い原因は、情報が見つからないことなのか
  • FAQを読めば解決できる種類の問い合わせなのか
  • 問い合わせる人は、そもそもFAQを見る状況にあるのか
  • 本当は、プロダクトの画面や業務ルールがわかりにくいだけではないのか

論理的に考えるとは、結論をきれいに言うことではない。結論を支えている前提を表に出し、それが本当に成り立つかを確かめることだ。

三段論法と仕事の結論の違い 古典的な三段論法は前提が明示される。仕事の雑な結論では前提が隠れやすい。 論理は「結論」ではなく、結論を支える前提を見る技術 三段論法の例 人はみな死ぬ ソクラテスは人である だから、ソクラテスは死ぬ 前提が見えているので、どこを疑うべきか分かる。 仕事で起きがちな例 問い合わせが多い だから、FAQを作る 隠れた前提 問い合わせの原因は情報不足なのか。 FAQを読む状況が本当にあるのか。

ロジカルシンキングはどこから来て、どう変わったのか

ロジカルシンキングは、ある日突然、企業研修の教室に現れたわけではない。ただし、ひとつの直線的な歴史として「ギリシャからMECEへ」とつなぐのも乱暴である。実際には、いくつかの流れが合流して、いま企業で教えられる「論理的に考える」「構造化する」「問題を分解する」という作法になっている。

ひとつ目の流れは、推論の形を確かめる流れである。

古代ギリシャでは、「その結論は、どの前提から出ているのか」が問題になった。人はみな死ぬ。ソクラテスは人である。だから、ソクラテスは死ぬ。この形では、結論の前に前提がある。前提が崩れれば、結論も崩れる。

二つ目の流れは、近代以降の「方法」への意識である。

デカルト的に言えば、複雑な問題を小さく分け、順序立てて考える。ベーコン的に言えば、頭の中だけで結論を作らず、観察から確かめる。細かい哲学史を追う必要はないが、ここで大事なのは、正しさが「権威がそう言ったから」ではなく、「分けて考え、観察し、確かめる」方向に移っていったことだ。

三つ目の流れは、論理を数学的・形式的に扱う流れである。

三段論法は、「人」「死ぬ」「ソクラテス」のような語の関係を見る。だが19世紀以降の論理は、ジョージ・ブールやゴットロープ・フレーゲらを経て、命題、関係、量化、記号操作を扱う方向へ進んだ。これは企業研修のロジカルシンキングそのものではない。しかし、論理を形式化し、計算可能なものとして扱う流れは、コンピュータやAIの背景にある。

四つ目の流れは、仕事を管理するための構造化である。

ここに、テイラーの科学的管理法のような考え方が入ってくる。これは古代と現代の間にある遠い中継点というより、むしろ現代企業のすぐ手前にある発想だ。工場の作業を観察し、時間を測り、標準化し、効率を上げようとする。職人の勘や現場の慣習をそのままにせず、作業を分け、測れる単位にし、改善できる対象にする。

ただし、この発想には危うさもある。測れるものを重視すると、測れないものが軽く見える。作業時間は測れる。だが、疲労、納得感、現場でしか分からない違和感、長期的な安全性は、同じようには測れない。

五つ目の流れは、品質管理や統計的な考え方である。

不良品を最後に見つけるだけでは遅い。工程の途中で変化を見つけ、安定しているのか、何かが起きているのかを見る必要がある。ここでは、問題は個人の努力不足ではなく、プロセスの状態として扱われる。現場で起きていることを、感覚だけでなく、ばらつきや変化として見る発想である。

六つ目の流れは、軍事、行政、企業経営の中で発達した意思決定の技術である。

作戦、物流、予算、組織、投資判断のような問題では、ひとつの部署やひとつの工程だけを見ても答えが出ない。全体をシステムとして見て、制約、リスク、選択肢、影響範囲を考える必要がある。オペレーションズ・リサーチやシステム分析の発想は、このあたりに近い。個人の頭のよさではなく、複数の専門知を組み合わせて判断する技術である。

そして、コンサルティングや経営の現場では、複雑な問題を意思決定者に伝える技術が発達した。MECEやピラミッドストラクチャーは、この文脈で強い。経営者は細部を全部読めない。だから、結論を先に置き、根拠を階層化し、論点を分ける必要がある。

そして今、AIがその構造化を一瞬で作るようになった。

この変遷を見ると、ロジカルシンキングは単なる「論理学の子孫」ではない。推論、方法、観察、形式化、管理、品質、意思決定、説明の技術が混ざり合っている。

変わったのは、何を相手にしているかだ。かつては概念や推論を相手にした。近代以降は観察や方法を相手にした。数理論理は記号と形式を相手にした。産業化の中では作業や工程を相手にした。経営の場では意思決定者を相手にした。今は、AIが作ったもっともらしい構造も相手にしている。

変わらなかったものもある。

どの時代でも、人間は現実をそのまま扱えない。だから分ける。名前を付ける。順序を作る。図にする。さらに、それが正しいかを観察し、確かめ、必要なら捨てる。

ロジカルシンキングの歴史は、整理の歴史であると同時に、整理によって落ちたものをどう見つけ直すかの歴史でもある。

ロジカルシンキングに至る複数の流れ 推論、方法、数理論理、管理、品質、意思決定、説明、AI時代の確認という複数の流れが合流していることを示す。 ロジカルシンキングは、複数の流れが合流した仕事の作法 一直線の歴史ではなく、推論・方法・形式化・観察・管理・説明が重なっている。 推論 前提と結論 矛盾を問う 方法 分ける 観察で確認 形式化 記号で扱う 計算へ近づく 管理 作業を分ける 測って改善 品質 ばらつき 工程で防ぐ 意思決定 全体を見る 制約を扱う 説明 結論を先に 論点を階層化 AI時代の課題 作られた構造を疑う 変わらない本質 分けたあとに、前提・観察・反証・落ちたものを見直す。

MECEは現実を整える道具ではなく、考えを点検する道具である

この流れを踏まえると、企業研修で語られるロジカルシンキングは、論理学そのものではない。科学的方法そのものでも、品質管理そのものでもない。それらの一部を、仕事で使いやすい形にまとめた実務上の作法である。

だからこそ、便利である一方で、雑にもなりやすい。

MECEは「重複なく、漏れなく」と説明される。売上なら、顧客数、購入頻度、単価に分ける。業務課題なら、人、プロセス、システム、制度に分ける。こうした分解は便利だ。会議で扱える単位に落ちるし、担当も決めやすい。

しかし、現実はいつもきれいに分かれない。

社員の不満は、人の問題でもあり、制度の問題でもあり、過去の失敗体験の問題でもある。顧客の離脱は、価格の問題でもあり、期待値の問題でもあり、サポート対応の記憶の問題でもある。

MECEに見える図は作れる。AIならもっと速く作れる。だが、図がきれいであることと、現実を正しく扱えていることは別である。

ここで起きる問題は、図に入らないものが「重要ではないもの」に見えてしまうことだ。分類できた瞬間に、問題が小さくなったような気がする。名前を付けた瞬間に、理解したような気がする。

ロジカルシンキングが危うくなるのは、感情を排除したときではない。感情を隠したまま、論理の形を与えたときである。

「これは合理的な判断です」と言いながら、実際には不安を避けているだけかもしれない。

「データ上はこうです」と言いながら、最初から見たいデータだけを集めているかもしれない。

「MECEに整理すると三つです」と言いながら、その三つに入らない声を切り捨てているかもしれない。

論理は、感想を消す道具ではない。感想を検査する道具である。

システム開発では、きれいな整理がリスクを小さく見せる

この問題は、システム開発の現場で特に危険になる。なぜなら、セキュリティや障害リスクは、そもそも見えにくいからだ。

たとえば、ある開発チームが新しい管理画面を作るとする。ロジカルに整理すると、タスクはこう分かれる。

  • ログイン機能
  • 権限管理
  • データ一覧
  • CSV出力
  • 操作ログ

ここまでは悪くない。問題は、この分け方だけで安心してしまうことだ。

「権限管理」という箱があると、権限の問題はそこに閉じ込められたように見える。しかし実際には、CSV出力にも権限は関係する。操作ログにも関係する。データ一覧の検索条件にも関係する。退職者のアカウント停止、外部委託先のアクセス、緊急時の代理操作にも関係する。

障害リスクも同じだ。

「ピーク時の負荷」「外部APIの失敗」「データ不整合」「リトライ」「監視」「復旧手順」と分けることはできる。しかし、本当に怖いのは、それらが同時に起きることだ。外部APIが遅くなり、リトライが増え、キューが詰まり、監視通知が多すぎて見落とされ、復旧手順が古いままになっている。こうした連鎖は、きれいな箇条書きの中では小さく見える。

システム開発でリスクが小さく見える流れ 機能別に分解すると管理しやすくなる一方、境界と連鎖が見えにくくなる。 きれいに分けるほど、境界と連鎖が見えにくくなる 機能別に分解 ログイン / CSV / ログ 担当を割り当てる 責任範囲が明確に見える リスクを表にする 確率 / 影響度 / 対策 安心する ここが危険 見落としやすいもの 境界のリスク CSV出力にも権限は関係する 連鎖のリスク API遅延がリトライ増加を招く 運用のリスク 通知疲れで異常を見落とす 事故は「箱の中」より、箱と箱の接続部分で起きやすい 分解したあとに、必ず境界と失敗の連鎖を見直す。

ロジカルシンキングによってリスクが低く見積もられる原因は、主に三つある。

一つ目は、分類すると独立して見えることだ。セキュリティ、性能、運用、障害対応と分けた瞬間、それぞれが別々に管理できるものに見える。だが、本番障害や情報漏えいは、たいてい境界で起きる。

二つ目は、数値化できるものが強く見えることだ。発生確率、影響度、優先度をつけると、判断した気になる。しかし、未知の攻撃手法、運用担当者の疲労、深夜対応の判断ミス、責任分界の曖昧さは、最初の表には入りにくい。

三つ目は、会議で扱いやすい形にした瞬間、扱いにくい現実が落ちることだ。「要件外」「別チームの範囲」「運用でカバー」という言葉は便利だが、事故はその境目から入ってくる。

では、どう考えるべきか

ロジカルシンキングを捨てる必要はない。むしろ、システム開発では必要である。要件を分ける。影響範囲を整理する。処理の流れを書く。責任範囲を明確にする。これらがなければ、複雑な開発は進まない。

ただし、型を使ったあとに、必ず逆向きに考える必要がある。

まず、前提を言葉にする。

「この機能は社内利用だけだからリスクは低い」と考えたなら、その前提をそのまま書く。社内利用とは誰までを含むのか。委託先は入るのか。VPN外からのアクセスはないのか。退職者のアカウントは即時停止されるのか。

次に、境界を見る。

権限管理だけを見るのではなく、権限が関係するすべての機能を見る。CSV出力、API、ログ、検索、通知、管理者操作、バッチ処理。リスクは箱の中ではなく、箱と箱の接続部分に現れやすい。

さらに、失敗が連鎖した状態を考える。

外部APIが落ちたらどうなるか。リトライは増えるか。ユーザーは再送するか。二重登録は起きるか。監視は鳴るか。誰が見るか。その人が不在なら誰が判断するか。

最後に、反対意見を先に入れる。

「この設計で問題ない」と言う前に、「この設計が破綻するとしたら、どこからか」を考える。セキュリティレビューや障害レビューの価値は、きれいな説明を確認することではない。説明から抜けたものを見つけることにある。

日本語で「論理的に話す」ことの難しさ

ビジネスの場では、「結論から話せ」とよく言われる。多くの場合、それは正しい。忙しい相手に報告するなら、最初に結論を置いたほうがよい。意思決定の場では、結論、根拠、選択肢、リスクが整理されていたほうがよい。

だが、「論理的に話すこと」と「わかりやすく話すこと」は同じではない。

話が論理的でも、相手がまだその問題を自分のものとして受け取れていなければ、伝わらない。構造が整っていても、言葉が相手の経験に接続していなければ、理解は進まない。

日本語のコミュニケーションでは、文脈、間、含み、関係性が大きな役割を持つ。主語を省略できること、語順に余地があること、敬語によって関係性を文の中に織り込むこと。こうした性質は、考え方や伝え方にも影響する。

だから、日本語の職場にロジカルシンキングを持ち込むときは、単に西欧式の型を移植するだけでは足りない。型を使いながら、相手がどの文脈でその言葉を聞くのかまで扱う必要がある。

「結論から言うと、これは却下です」と言えば論理的に見えるかもしれない。しかし、相手が何を心配して提案したのかを聞かないままなら、それはただの遮断である。

論理的であることは、冷たく話すことではない。相手の文脈を含めて、前提をそろえることである。

AI時代に残る価値は、問いの品質である

AIは、MECEな分解を作るのがうまい。フロー図も作れる。リスク一覧も出せる。もっともらしい結論も書ける。

だからこそ、人間が問うべきことは変わる。

  • この分け方で、何が見えなくなったか
  • この結論を支える前提は何か
  • 反対の事実はあるか
  • 数値にできないが重要なものは何か
  • 事故が起きるとしたら、どの境界か
  • 誰の経験や不安が、論点の外に追い出されているか

ロジカルシンキングの価値は、型を知っていることではない。型を疑えることにある。

AIが作ったMECEを見て、「きれいだ」と思うだけなら、そこで人間が加える価値は薄い。だが、「この分類は現実を切り落としていないか」「このフローは失敗時の動きを隠していないか」「この結論は誰にとって都合がよいのか」と問えるなら、ロジカルシンキングはまだ価値を持つ。

結論

ロジカルシンキングは、企業文化の中で奇妙な地位を得た。誰もが大事だと言う。だが、その中身はしばしば曖昧で、MECEな図を作ること、結論から話すこと、フレームワークに当てはめることに縮んでしまう。

論理的に考えるとは、本来、自分の考えを疑えるということだ。

ソクラテスの問答が示しているのは、相手を言い負かす技術ではなく、自分が何を知っているつもりなのかを確かめる態度である。アリストテレスの三段論法が示しているのは、結論の前に前提があるという当たり前の厳しさである。近代以降の方法論や管理の歴史が示しているのは、問題を分け、観察し、測り、標準化する力の大きさと、その外側に落ちるものの危うさである。

企業研修でロジカルシンキングを教えるなら、MECEの前に教えるべきことがある。

自分の結論を、いったん疑うこと。

図に入らないものを、なかったことにしないこと。

論理の形をした感想を、正しさと取り違えないこと。

AIが簡単にきれいな図を作る時代に、人間が持つべきなのは、より速く図を作る能力だけではない。図の外側に残った現実を見る力である。

その緊張感がある限り、ロジカルシンキングはまだ有効である。だが、それを失った瞬間、論理は考えるための道具ではなく、考え終わったふりをするための道具になる。

目次