今日のフォーカス
演繹・帰納・アブダクションの三推論形式を使いこなし、ビジネス現場の論証を正確に構造化する。「正しく見える主張」の内部構造を解剖し、前提の妥当性・誤謬・情報の不完全性を見抜く力を鍛える。
演繹（Deduction）
前提が真ならば結論は必ず真。論理的に確実だが、前提の正しさ（健全性）を別途確認する必要がある。
帰納（Induction）
観察・事例から一般法則を導く。サンプルが少ないほど信頼性は低く、確率的な主張にとどまる。
アブダクション（Abduction）
観察から最良の説明を選ぶ。「仮説推論」とも呼ばれ、検証が必須。他の説明の可能性を常に考慮する。
以下の3つの推論を「演繹・帰納・アブダクション」に分類し、それぞれの特徴・強み・限界を説明せよ。
- 推論A: 「全PMはエンジニア出身か営業出身。山田さんはエンジニア出身ではない。したがって山田さんは営業出身のPMだ」
- 推論B: 「過去5回のリリース後、いずれも2週間以内にクリティカルなバグが発生。だから次のリリース後も同様のバグが出るだろう」
- 推論C: 「今朝から社内チャットにメッセージが届いていない。同僚も受信できていない。おそらくサーバー障害ではないか」
思考プロセスのヒント
推論の分類は「結論が前提からどのように導かれているか」で決まる。
- 演繹: 前提が真ならば結論は論理的に必然。「全称命題 + 個別事例 → 結論」の形がよくある
- 帰納: 複数の観察事例から一般法則・傾向を導く。「今まで〜だったから、次も〜だろう」
- アブダクション: 観察された現象を最もよく説明する仮説を選ぶ。「〜が起きている → おそらく〜が原因」
- 各推論の「限界」にも注目。論理的に正しいことと、実際に信頼できることは別
模範解答を見る
推論形式の分析
推論A — 演繹（Deduction）
推論の形式: 全称命題 + 否定 → 確実な結論
前提1: 全PMはエンジニア出身 OR 営業出身
前提2: 山田さんはエンジニア出身でない
結論: 山田さんは営業出身のPM（必然）
強み: 前提が真であれば結論は論理的に確実。否定による除去（modus tollens）の典型例。
限界（健全性の問題）: 「全PMがエンジニア出身か営業出身という二択」という前提が本当に正しいか？マーケティング出身やデザイン出身のPMが存在すれば前提が崩れる。論理的に妥当でも、前提の真偽を別途検証する必要がある。
推論B — 帰納（Induction）
推論の形式: 有限の観察事例 → 一般化（確率的主張）
観察1〜5: 過去5回のリリース後 → バグ発生
結論: 次のリリース後も → バグが発生するだろう（確率的）
強み: 過去データを根拠にした実践的な予測。ビジネスの意思決定で最も多用される推論形式。パターンの発見に有効。
限界（サンプルの弱さ・因果の問題）: 5回は統計的に弱い。なぜバグが発生するかの根本原因（テスト不足・アーキテクチャの問題）を分析していなければ、改善施策を打っても「まだバグが出る」と思い込み、改善を怠る危険がある。「相関」を「必然」として扱う誤りに注意。
推論C — アブダクション（Abduction）
推論の形式: 観察 → 最良の説明仮説の選択
観察1: 自分にメッセージが届いていない
観察2: 同僚も受信できていない
仮説: サーバー障害（最も可能性が高い説明）
強み: 限られた情報から最も合理的な行動仮説を素早く立てられる。診断・トラブルシュートの基本。日常のビジネス判断の多くはアブダクションに依存している。
限界（他の説明の可能性）: 「サーバー障害」は一つの仮説にすぎない。端末設定の問題・アカウント停止・計画メンテナンス・ネットワーク障害なども同様に説明できる。仮説は必ず検証が必要で、最初の仮説に固執する「確証バイアス」に注意。
ビジネスでは3つを組み合わせて使う。アブダクションで仮説を立て（What is the best explanation?）、帰納でパターンを確認し（Is this consistent?）、演繹で論理的含意を導く（What follows if this is true?）。どの推論を使っているかを意識するだけで、議論の質が上がる。
実践への応用
- 会議中に「今この発言は演繹・帰納・アブダクションのどれか？」と心の中で分類する習慣を持つ
- 帰納の主張を聞いたときは「サンプル数は？」「根本原因は分析されているか？」を確認する
- アブダクションで仮説を立てたら、即座に「他にどんな説明がありえるか？」と問い直す
自己評価
事業部長が月次レビューで次のように発言した：
「競合X社が増員したら開発速度が2倍になって顧客満足度も向上した。だから我々も今すぐ増員すべきだ。直近スプリントで30%のタスクが未完了になっている。優秀なエンジニアを採用できない企業は生き残れない——業界の常識だ。」
あなたはEMとして、この論証の問題点を整理し、適切に応答する必要がある。
- この発言に含まれる論理的誤謬を3つ特定せよ
- 正当な根拠として使える部分を特定せよ
- EMとしての具体的な応答を設計せよ
思考プロセスのヒント
論理的誤謬（Logical Fallacy）は、見た目には説得力があるが、論証の構造に欠陥がある主張。よく使われる誤謬:
- 誤った因果関係（False Cause）: AとBが一緒に起きた → AがBを引き起こした（相関≠因果）
- 群衆への訴え（Appeal to Popularity）: 「みんな/業界が言っている」→ だから正しい
- 合成の誤謬（Fallacy of Composition）: X社でうまくいった → 我々でも同じようにうまくいく
- 不完全な原因の特定（Hasty Causation）: 観察した問題に一番目立つ原因を即断する
誤謬を指摘しながらも、相手の根拠の有効な部分は認める「鋼鉄人（Steel-manning）」が建設的な対話を生む。
模範解答を見る
論証の分解：誤謬の特定
誤謬1: 誤った因果関係 + 合成の誤謬
問題の発言: 「X社が増員 → 速度2倍 → 満足度向上」
問題点: 「増員」と「速度2倍」は相関であり、因果関係は未証明。X社は同時期にアーキテクチャ刷新・CI/CD改善・自動テスト強化なども実施した可能性がある。さらに「X社で成功した = 我々でも同じ結果が出る」という合成の誤謬が含まれる。コンテキスト（チーム規模・技術負債・プロダクトフェーズ）が異なれば結果は変わる。
誤謬2: 群衆への訴え
問題の発言: 「優秀なエンジニアを採用できない企業は生き残れない——業界の常識だ」
問題点: 「業界の常識」は根拠なき主張を権威で補強する詭弁。「常識」と言われても、それが今の自社の状況に当てはまる根拠がなければ意思決定の根拠にならない。さらに「採用できない = 生き残れない」は極端な二値化（False Dilemma）も含む。
誤謬3: 誤った原因の特定（Hasty Causation）
問題の発言: 「直近スプリントで30%のタスクが未完了 → 人が足りない」
問題点: スプリント未完了の原因は「人数不足」だけではない。見積り精度の低さ・スコープの途中変更・技術的負債による速度低下・依存関係のブロッカー・優先度の問題など、複数の説明が可能。原因分析なしに「増員」という解に飛びつくのはアブダクションの乱用（最良の説明ではなく、最もシンプルな説明を選んでいる）。
「直近スプリントで30%のタスクが未完了」という観察事実自体は具体的な問題提起として有効。問題が存在することは示している。EMとして否定すべきはこの観察ではなく、「だから増員」という飛躍した結論である。
EMとしての応答
「X社の増員効果について、他の施策との切り分けデータがあれば見せていただけますか？どの施策がどれだけ速度に貢献したか確認した上で参考にしたいと思います。」
「スプリント未完了30%の根本原因を分析させてください。原因が人数不足なのか、スコープ管理なのか、技術的負債なのかで、最適な解決策が変わります。2週間で分析結果をお持ちします。」
「増員の検討は否定しませんが、採用コスト・オンボーディングで3〜6ヶ月の生産性低下が見込まれます。他の施策（技術的負債の返済・プロセス改善）との費用対効果を比較した上で、最も効果的な投資先を判断したいと思います。」
誤謬を指摘するときは「あなたは間違っている」と言わず、「その結論に至るプロセスに必要なデータが欠けている」というフレームを使う。相手の問題意識（スプリント未完了）は認めながら、解決策の選択に必要な情報を要求する。これが建設的かつ論理的な対話を生む。
実践への応用
- 上司や経営層の発言を聞くとき「これは相関か因果か？」を常に問い直す
- 「〇〇の常識だ」「業界がそうしている」という発言を見たら、具体的根拠を要求する習慣を持つ
- 問題を提示されたとき、すぐ解決策に飛ばず「原因の仮説を3つ以上列挙する」を徹底する
自己評価
社内ルール: 「ユーザーテストでタスク完了率80%以上ならβリリース可」。今回: 12名中10名完了（完了率≈83.3%）。ただしチーフデザイナーが「サンプルが偏っており結果を信頼すべきでない」と主張。ルール制定時のドキュメントには「ユーザーテストの品質が担保されていることを前提とする」と記載されている。
- 「完了率80%以上ならβリリース」を必要条件・十分条件の観点で分析せよ
- デザイナーの主張の論理的意味を条件式で表現せよ
- この状況でGo/No-Goの推奨を論理的に構造化して示せ
思考プロセスのヒント
「P ならば Q（P→Q）」という条件文において:
- 十分条件: PはQに対して十分（PがあればQが成立する）
- 必要条件: PはQに必要（Qが成立するためにはPが必要）
- 必要十分条件: P↔Q（PとQが同値）
- 複数の条件が「AND」で組み合わさるとき、一つでも偽になれば全体が偽になる
- 「健全な推論（Sound Argument）」には「妥当な論理形式 + すべての前提が真」が必要
模範解答を見る
問1: 必要・十分条件の分析
「完了率80%以上」はβリリースの十分条件
P = 完了率80%以上
Q = βリリース可
P → Q（Pが成立すればQが導かれる）
ルールの文言は「80%以上ならリリース可」であり、PはQに対して十分条件として設計されている。ただし「80%未満なら絶対にリリース不可」（必要条件）かどうかはルールの文言だけでは確定しない（例外規定の有無による）。
問2: デザイナーの主張の論理的表現
P1: テスト品質が担保されている（前提） P2: 完了率80%以上 ↓ P1 ∧ P2 → Q（βリリース可） 今回の状況: P2 = TRUE（83.3% > 80%） P1 = ?（デザイナーはP1が偽である可能性を指摘） P1が FALSE の場合: FALSE ∧ TRUE → Q は導けない（前件が偽）
デザイナーはP1（テスト品質担保）が成立していない可能性を指摘している。P1が偽ならば、P2が真であっても論証全体は健全でない。数値上の条件を満たすことと、論証が健全であることは別問題。
問3: Go/No-Go の推論構造
12名中10名完了 = 83.3%。数値上はルール（80%以上）を満たしている。
チーフデザイナーが「サンプルに偏りがある」と指摘。この偏りが具体的にどのようなものか（ヘビーユーザーのみ・特定属性に偏り・タスク設計の問題等）を確認する必要がある。
制定時ドキュメントに「テスト品質が担保されていることを前提とする」と明記されている。これはP1がルール適用の前提条件であることを公式に認めている。
前提1（確認済み）: 完了率83.3% → 数値上はルールを満たす 前提2（指摘） : サンプルに偏りがある可能性が高い 前提3（ドキュメント）: このルールは「テスト品質担保」を前提とする 推論: 前提2が真ならば前提3によりルール適用要件が不成立 結論: 現時点ではGoの論理的正当性がない
追加アクション: テスト設計の問題点を特定し、最短スケジュールで再テストを実施する。再テストまでのリード時間が明確になったうえで、リリース延期のビジネスコストと比較して最終判断する。
「83.3% > 80% だからリリース可」という論証は、表面的には妥当に見える。しかし論証の健全性（soundness）は「論理形式の妥当性 + 全前提が真」の両方が必要。前提の一つ（テスト品質）が疑わしい場合、数値だけを根拠にGoを推進することは論理的に正当化されない。これはビジネスの意思決定で「データは満たしているのに判断が間違い」という典型的なパターン。
実践への応用
- 「〇〇の条件を満たした」と言われたとき、「それは必要条件か十分条件か？」を区別する
- ルール・ポリシーを適用するとき、そのルールが設計された前提（コンテキスト）が今も成立しているかを確認する
- 数値がKPIを達成しているとき、「その数値の取り方は健全か？」を問い直す癖を持つ
自己評価
今日のまとめ
- 演繹: 前提が真であれば結論は確実。前提の「健全性」を別途確認する
- 帰納: サンプルの質と量・根本原因の分析なしに一般化しない
- アブダクション: 仮説は仮説であり、必ず検証する。他の説明の可能性を常に列挙する
今日の最重要キーワード
- 妥当性（Validity）vs 健全性（Soundness）
- 相関 ≠ 因果
- 必要条件 vs 十分条件
- 論理的誤謬（群衆への訴え・合成の誤謬・誤った因果）
次回への接続
明日は Thinking-A（問題解決・意思決定） 。今日学んだ推論の構造化スキルを、実際の意思決定フレームワーク（Type1/Type2・意思決定マトリクス）と組み合わせて実践する。