問題解決思考の基礎

問題解決は「すぐに解決策を考える」ことではない。本当に解くべき問題を見極め、構造的に分解し、仮説と検証のサイクルを回すことが本質である。

問題と課題の本質

問題（Problem）とは何か

問題とは「現状（As Is）」と「あるべき姿（To Be）」のギャップである。

flowchart LR
    A[As Is
現状] ---|ギャップ = 問題| B[To Be
あるべき姿]

このシンプルな定義が重要な理由は、問題を語るためには必ず「前提」が必要だということ。前提が異なれば、同じ現状でも問題の捉え方は変わる。

例：

• 前提A「売上は成長し続けるべき」→ 売上横ばいは問題
• 前提B「利益率を維持すべき」→ 売上横ばいは問題ではない可能性

前提を定義する

問題を定義する前に、「変えられないこと」を明確にする必要がある。前提が曖昧なまま問題解決を進めると、途中で「そもそもそれは変えられない」と判明して手戻りが発生する。

前提の明示化

1. 前提を洗い出す - 暗黙の前提を言語化する。「当然こうだろう」と思っていることを列挙
2. 変えられるか確認する - 本当に変えられないのか、それとも変えないと決めただけなのか検証

現状の整理

同じ現状でも、何を制約として扱うかで課題の定義は全く変わる。

flowchart TB
    S[現状：チームの残業が多い]
    S --> PA[「人員は増やせない」を
制約とすると]
    S --> PB[「業務量は減らせない」を
制約とすると]
    S --> PC[「納期は変えられない」を
制約とすると]
    PA --> IA[課題：業務効率化]
    PB --> IB[課題：人員増加]
    PC --> IC[課題：スコープ削減]

ここで重要なのは、「人員は増やせない」などは本当の制約（物理的・法的に不可能）ではなく、前提（変えないと決めたこと）である可能性が高いということ。前提を問い直すことで、より良い解が見つかることもある。ただし、前提を変えるには通常、より上位の意思決定者やステークホルダーとの交渉が必要になる。

前提と制約の違い

ここでは、前提と制約を上記の定義として扱う。前提を制約と混同すると、本来は変えられる選択肢を見落とす。「それは本当に変えられないのか？」と問い直すことが、真の課題を見極める第一歩になる。

Problem と Issue の違い

英語では problem と issue を区別する。この区別が問題解決の質を変える。

flowchart LR
    A[Problem
問題状況] --> B[分析・分解]
    B --> C[Issues
論点・課題]
    C --> D[仮説・検証]
    D --> E[意思決定]

イシューとは「答えを出す価値のある本質的な問い」。問題解決の鍵は、漠然とした problem から具体的な issue を抽出することにある。

問題解決のプロセス

全体像

問題の認識からフィードバックまで、各ステップを反復しながら進める

このプロセスは直線的ではなく、フィードバックループを持つ。検証結果によって仮説を修正し、ときには問題の認識自体を見直す。

イシュードリブンなアプローチ

イシュードリブンとは、「何を解くか」を最初に見極めるアプローチ。

100の問題があっても、本当に答えを出すべき問題は2〜3個。残り97〜98個に時間を使うのは犬の道であり、バリューのある仕事は生まれない。

よいイシューの条件：

1. 本質的な選択肢である - 答えによって意味合いが大きく変わる
2. 深い仮説がある - 常識を覆す、新しい構造で説明するなど
3. 答えを出せる - 手持ちの技術・手法で検証可能

論理的思考の構造

問題解決には論理的思考が不可欠である。しかし「論理的」とは何を意味するのか。

論理的ではない思考

以下のような思考は、一見もっともらしく見えても論理的ではない：

• 「若者のユーザーは、…といっている」
• 「売上の伸びが鈍化…」
• 「業界のエキスパートは、…といっている」
• 「過去のベストプラクティスは…」
• 「最近の競合の動きは、…」

これらは情報を羅列しているだけで、情報の関連性・重要性が明確ではない。事実やデータを並べることと、論理的に考えることは別物である。

論理的とは何か

論理的であるとは、「話が縦にも横にもきちんとつながっている」ことである。

flowchart TB
    subgraph vertical["縦の論理（直列）"]
        direction TB
        V1[主張] --> V2[根拠]
        V2 --> V3[事実]
    end

    subgraph horizontal["横の論理（並列）"]
        direction TB
        H0[主張] --> H1[要素A]
        H0 --> H2[要素B]
        H0 --> H3[要素C]
    end

縦の論理は「本当にそうなの？」、横の論理は「本当にそれだけ？」で検証する

縦の論理と横の論理の両方が満たされれば、人は誤解や違和感なく理解できる。

縦の論理

縦の論理を構成する方法は2つある。帰納法と演繹法である。

具体例：子供が親に靴を買ってもらうとき

帰納法の例：

flowchart TB
    K1[A君は新しい靴を買ってもらった] --> KC[だから僕にも
新しい靴を買ってほしい]
    K2[B君も新しい靴を買ってもらった] --> KC
    K3[C君も新しい靴を買ってもらった] --> KC

演繹法の例：

flowchart TB
    E1[徒競走で優勝したい] --> E2[今の靴では走りにくい]
    E2 --> E3[優勝するためには新しい靴が必要]
    E3 --> EC[だから僕に
新しい靴を買ってほしい]

どちらも「新しい靴を買ってほしい」という結論に至るが、説得の構造が異なる。帰納法は「みんなが持っている」という事実の集積、演繹法は「目標達成に必要」という論理の連鎖で支える。

Why So? と So What?

縦の論理を検証する2つの問いがある。

flowchart TB
    M[メッセージ] -->|Why So?| R1[根拠1]
    M -->|Why So?| R2[根拠2]
    M -->|Why So?| R3[根拠3]
    R1 -->|So What?| M
    R2 -->|So What?| M
    R3 -->|So What?| M

ビジネスでの具体例：

flowchart TB
    M[ベトナムのB社を委託生産先
および市場進出の第一候補とすべき]
    M -->|Why So?| R1[B社の生産コストが一番安い]
    M -->|Why So?| R2[委託リスクは中国以外は十分低い]
    M -->|Why So?| R3[市場魅力はベトナムが一番高い]

「帰納法」か「演繹法」で、メッセージを根拠で支えるのが縦の論理の基本である。

flowchart LR
    subgraph 演繹法
        D1[一般原則] --> D2[個別事例への適用]
        D2 --> D3[結論]
    end

    subgraph 帰納法
        I1[事例1] --> I4[一般化]
        I2[事例2] --> I4
        I3[事例3] --> I4
    end

横の論理

大きな問題をそのまま解くことはできない。答えを出せるサイズまで分解する技術が必要。横の論理を構成するのはMECEとGroupingである。

MECE（Mutually Exclusive, Collectively Exhaustive）

「漏れなく、ダブりなく」分解する原則。考えるポイントを抜け漏れダブりなく分解することで、横の論理を担保する。

左：Good MECE（重なりなし、隙間なし）、右：Bad（重複=Overlap と隙間=Gap あり）

MECEの4つの作り方

二分割（A−Not A）の例：

flowchart LR
    subgraph 二分割
        A1[国内セールス] <--> A2[国内以外セールス]
        B1[大企業向け] <--> B2[中小企業向け]
        C1[新規顧客] <--> C2[既存顧客]
    end

プロセス分割の例：

flowchart LR
    P1[訪問] --> P2[商談] --> P3[見積] --> P4[契約]

数式分割の例：

フレームワーク分割の例（PEST）：

Grouping

要素をグルーピングして意味ある順序にまとめることで、横の論理を担保する。

Groupingの3つの根拠

因果の因（時間の順序）：

flowchart LR
    G1[現状分析] --> G2[課題抽出] --> G3[対応策検討]

結果をもたらす行動が原因になり、一連のプロセスとして表される。

部分/全体の部分（構造の順序）：

flowchart LR
    S1[自動車メーカー] --> S2[部品メーカー] --> S3[材料メーカー]

組織や産業などの全体システムは、各サブシステムの集合体として表される。

類似するもの（度合いの順序）：

flowchart LR
    D1[私大文系] --> D2[国公立文系] --> D3[理系]

類似するものはすべてを網羅しているわけではなく、一部の抜粋として表される。

ロジックツリー

問題を木構造で分解する手法。分解の切り口によって複数の型がある。

Where型（どこに問題があるか）

flowchart TB
    W0[売上低下] --> W1[製品A]
    W0 --> W2[製品B]
    W1 --> W1a[東日本]
    W1 --> W1b[西日本]:::problem
    W2 --> W2a[東日本]
    W2 --> W2b[西日本]
    classDef problem fill:#ff6b6b,color:#fff

What型（何が問題か）

flowchart TB
    X0[顧客満足度低下] --> X1[製品品質]
    X0 --> X2[価格]
    X0 --> X3[サービス対応]:::problem
    X0 --> X4[納期]
    classDef problem fill:#ff6b6b,color:#fff

Why型（なぜ問題が起きているか）

flowchart TB
    Y0[サービス対応が悪い] --> Y1[人員不足]
    Y0 --> Y2[スキル不足]:::problem
    Y0 --> Y3[システム制約]
    Y2 --> Y2a[研修不足]
    Y2 --> Y2b[マニュアル未整備]
    classDef problem fill:#ff6b6b,color:#fff

How型（どうやって解決するか）

flowchart TB
    H0[スキル向上] --> H1[研修実施]
    H0 --> H2[マニュアル整備]
    H0 --> H3[評価制度見直し]
    H1 --> H1a[座学]
    H1 --> H1b[OJT]

分解の視点

同じ問題でも、切り口によって見える世界が変わる。複数の切り口を試すことで、問題の本質に迫れる。

ピラミッド構造

論理的な思考や説明は「ピラミッド構造」で表現できる。ピラミッド構造では、縦と横の論理が共に適切である必要がある。

flowchart TB
    M[メッセージ] --> R1[根拠1]
    M --> R2[根拠2]
    M --> R3[根拠3]
    R1 --> D1[データ1-1]
    R1 --> D2[データ1-2]
    R2 --> D3[データ2-1]
    R2 --> D4[データ2-2]
    R3 --> D5[データ3-1]
    R3 --> D6[データ3-2]

具体と抽象の往復

問題解決では、観察の粒度を意識的に切り替える必要がある。

具体と抽象の往復（事象→原理→解決策）

観察の粒度としての具体⇔抽象

問題解決では具体と抽象化を往復する。具体的な事象から抽象的な構造を見出し、その構造を別の具体的な状況に適用する。

flowchart TB
    C1[具体：事象] -->|抽象化| A[抽象：構造・原理]
    A -->|具体化| C2[具体：解決策・行動]

仮説生成のプロセス

「システムが遅くなった」という観察から「データベースのクエリが原因ではないか」という仮説を立てる。この仮説生成は、しばしばアブダクション（仮説的推論）と呼ばれ、演繹・帰納と並ぶ「第三の推論形式」として紹介されることが多い。

しかし、アブダクションを演繹・帰納と同列に扱うことには問題がある。

アブダクションの形式的構造：

もし H ならば E が起きる
E が観察された
∴ H である

これは論理学では「後件肯定の誤謬」と呼ばれる形式であり、妥当な推論ではない。

仮説生成の実際のプロセス：

実際に仮説を「思いつく」過程を観察すると、複数の要素が組み合わさっている：

1. 帰納的要素 - 「前にも似たような遅延があり、そのときはDBが原因だった」という過去の事例からのパターン認識
2. 演繹的要素 - 「クエリが重いとレスポンスが遅くなる」という既知の原理の適用
3. 問いの設定 - 「何が説明変数になりうるか」という視点の選択

つまり仮説生成は、帰納・演繹・問いの設定の複合プロセスである。「アブダクション」という名前は、この複合プロセスの結果（仮説が生まれること）に名前を付けたものである。

仮説思考で重要なのは、この複合プロセスを意識的に回すこと。そして生成された仮説は必ず検証が必要である。

フェーズごとの思考の対応

前提を問い直す思考

問題解決において、帰納・演繹は「縦の論理」を構成する推論形式である。一方、「前提を問い直す」という行為は、推論形式とは異なる次元の思考である。

メタ認知とは

自分の思考を客観視する認知。「なぜ自分はこの問題を問題と捉えているのか」を問う。

前提を問い直す4つの場面

メタ認知が特に重要になる場面は4つある。

1. 問題定義時：前提の明示化

問題を定義する際に、暗黙の前提を言語化する。「前提を定義する」セクションで述べた通り、前提が曖昧なまま進めると手戻りが発生する。

• 「変えられないこと」を洗い出す
• 「変えられるが変えないと決めたこと」を区別する

2. 仮説生成時：問いの設定

仮説を生成する際に、「何を説明変数として考えるか」という問いを設定する。この問いの設定自体がメタ認知である。

• 「この現象を説明する要因として何が考えられるか？」
• 「過去の類似事例では何が原因だったか？」
• 「どの切り口で分析するのが効果的か？」

3. 分析を通じた前提の洗練

分析を進める中で、前提の解像度が上がることがある。最初は曖昧だった前提が、具体的なデータや事例に触れることで精緻化される。

flowchart LR
    A[仮説構築] --> B[検証・分析]
    B --> C[前提の解像度向上]
    C --> D[課題設定の更新]
    D --> A

前提の洗練パターン：

このフィードバックループを回すことで、最初に設定した課題が変わることは珍しくない。むしろ、課題設定が変わらないまま分析が進むときこそ、前提を問い直すべきサインかもしれない。

4. 行き詰まり時：真の課題の発見

問題解決が行き詰まったとき、前提自体を問い直すことで突破口が見つかる。

• 「そもそもこの問題設定は正しいか？」
• 「別の前提を置いたらどうなるか？」
• 「制約だと思っていたものは本当に変えられないのか？」

シングルループとダブルループ

ダブルループ学習の概念は、前提を問い直す思考を理解する上で重要。

青の内側ループ：手段の改善に留まるシングルループ、オレンジの外側ループ：前提自体を問い直すダブルループ

表面的な問題に囚われている状態は、シングルループに閉じ込められている状態。メタ認知でダブルループに移行することで、真の課題に到達できる。

真の課題を見極める

表面的な問題から深層へ

最初に認識される問題は、往々にして「表面的」である。

flowchart TB
    S1[表面的な問題
チームの生産性が低い]
    S1 -->|なぜ？| S2[中間的な問題
メンバーのスキルが足りない]
    S2 -->|なぜ？| S3[真の課題
採用基準が曖昧で
評価とフィードバックの仕組みがない]:::root
    classDef root fill:#4ecdc4,color:#fff

表面的な問題に対する解決策（研修を増やす）は対症療法に過ぎない。真の課題（採用・評価の仕組み）に取り組まなければ、問題は繰り返される。

分析から課題を抽出する

真の課題を見極めるとは、縦と横の論理で分析した結果から「問題に効果的にアプローチできる課題」を抽出することである。

flowchart LR
    A[横の論理で分解] --> B[縦の論理で深掘り]
    B --> C[説明変数の特定]
    C --> D[課題候補の評価]
    D --> E[課題の選定]

横の論理：問題の構造を把握する

MECEで問題を分解し、どこに問題があるかを特定する。

縦の論理：因果関係を追求する

Why So?で因果を掘り下げ、根本的な説明変数を特定する。

課題候補の評価

分析で特定した説明変数から課題候補を導出し、So What?で意味合いを抽出する。

課題のレベル感

課題には「対症療法」から「構造改革」までレベルがある。どのレベルで介入すべきかを見極める必要がある。

レベル選択の判断軸

• 同じ問題が繰り返されている → より上位レベルでの介入を検討
• 複数の部門・プロセスにまたがる → 仕組み改善または構造改革
• インセンティブ構造が問題 → 構造改革が必要な可能性
• リソース制約が厳しい → 実現可能なレベルから着手

構造改革は効果が高いがコストとリスクも大きい。「最小の介入で最大の効果」を狙うなら、まず仕組み改善で対応できないかを検討し、それでも不十分な場合に構造改革を選択する。

問い直しの技法

真の課題に到達するには、「前提を問い直す思考」で述べたメタ認知を実践する。具体的な問い直しの技法は以下の通り。

1. 前提を疑う：「本当にそれは問題か？」
2. 視点を変える：「別の立場から見たらどうか？」
3. 時間軸を変える：「1年後、5年後にも問題か？」
4. スケールを変える：「これは部分の問題か、全体の問題か？」

これらの問いを通じて、シングルループ（手段の改善）からダブルループ（前提の見直し）に移行し、真の課題に到達できる。

「解くべきでない問題」を見極める

すべての問題を解く必要はない。以下の問いで、本当に取り組むべきかを判断する：

1. 今、答えを出す必要があるか？（タイミング）
2. 答えが出たとして、行動が変わるか？（アクショナブル）
3. 自分（たち）が解くべき問題か？（当事者性）
4. 解くためのリソースがあるか？（実現可能性）

説得力をもって伝える

問題を解くだけでは不十分である。分析結果を他者に伝え、理解を得て、行動を促すまでが問題解決のプロセスである。

なぜ「伝える」が問題解決の一部なのか

どれほど優れた分析をしても、意思決定者や実行者に伝わらなければ問題は解決しない。「伝える」は問題解決の最終ステップではなく、解決の一部である。

伝えることの目的は3つある：

この3つが揃って初めて、問題解決は完結する。

前提の共有から始める

説明の最初にすべきことは、具体的な分析結果や提案を示すことではない。まず「何が問題なのか」という認識を相手と共有することである。

As-Is / To-Be の共有

問題とは「現状（As Is）と あるべき姿（To Be）のギャップ」である。このギャップの認識が相手と揃っていなければ、どれほど論理的な説明も空回りする。

flowchart LR
    subgraph 認識のズレ
        A1[自分の認識
As Is → To Be] -.->|ギャップ| B1[相手の認識
As Is? → To Be?]
    end

共有すべき3つの要素：

1. 現状（As Is）の認識 - 「今、何が起きているか」の事実認識は揃っているか
2. あるべき姿（To Be）の認識 - 「どうあるべきか」の目標認識は揃っているか
3. ギャップの大きさ - そのギャップは対処すべき問題なのか、許容範囲なのか

特に「あるべき姿」は、立場や価値観によって異なる。自分にとっては明らかな問題でも、相手にとっては問題ですらないことがある。まずここを揃える。

相手のコンテキストを把握する

相手が持っている前提知識、関心事、制約を把握した上で説明を組み立てる。

相手のコンテキストを無視した説明は、どれほど論理的でも響かない。「正しいこと」と「伝わること」は別である。

重要な前提は具体的説明の前に

分析結果や提案を示す前に、理解に必要な前提知識を共有する。相手が知らない概念や用語を使って説明を始めると、内容以前に「何を言っているかわからない」状態になる。

flowchart TB
    subgraph 悪い順序
        direction TB
        B1[具体的な分析結果] --> B2[専門用語が出てくる]
        B2 --> B3[相手が理解できない]
        B3 --> B4[説明が空回り]
    end

    subgraph 良い順序
        direction TB
        G1[前提知識の共有] --> G2[問題認識の共有]
        G2 --> G3[分析の枠組みの説明]
        G3 --> G4[具体的な分析結果]
    end

前提共有のポイント：

• 専門用語を使う場合は、最初に定義を明示する
• 分析に使った枠組み（MECEの切り口、ロジックツリーの構造など）を先に説明する
• 「なぜその切り口で分析したか」の理由も添える

分析結果を構造的に伝える

縦の論理と横の論理で構築した分析は、その構造を活かして伝える。

横の論理：どう分解したかを示す

MECEで分解した構造を示し、「全体のどこに問題があるか」を明確にする。

flowchart TB
    M[売上低下の要因分析]
    M --> W1[製品別]
    M --> W2[地域別]
    M --> W3[顧客セグメント別]
    W1 --> R1[製品Aが主因と特定]
    W2 --> R2[西日本が主因と特定]
    W3 --> R3[大企業顧客が主因と特定]

伝えるべきは結果だけでなく、「どういう切り口で分解したか」「なぜその切り口を選んだか」である。これにより、分析の網羅性と妥当性を示せる。

縦の論理：なぜそう言えるかを示す

Why So? で掘り下げた因果関係を示し、「なぜその結論に至ったか」を明確にする。

flowchart TB
    C[西日本の売上が低下している]
    C -->|Why So?| C1[主要顧客3社の発注が減少]
    C1 -->|Why So?| C2[競合B社に切り替えられた]
    C2 -->|Why So?| C3[価格競争力で負けている]

因果の連鎖を示すことで、「話が飛んでいない」ことを相手に確認させる。各ステップで「本当にそうなの？」と検証できる形で提示する。

課題抽出の根拠を示す

分析から課題を抽出する際の So What?（だから何が言えるか）を明示する。

flowchart LR
    F[分析結果
価格競争力で負けている]
    F -->|So What?| I[課題候補1
コスト構造の見直し]
    F -->|So What?| I2[課題候補2
価格以外の価値訴求]
    F -->|So What?| I3[課題候補3
ターゲット顧客の再定義]

課題候補を示した上で、なぜその課題を選定したかの評価軸（効果、実現性、持続性など）も併せて説明する。

ストーリーラインの構築

分析結果を伝える全体の流れがストーリーラインである。代表的な構成パターンを使い分ける。

空・雨・傘

事実→解釈→行動の流れで構成する。問題認識から行動提案までを一貫した論理で繋ぐ。

空（事実）：西日本の主要顧客3社が競合B社に切り替えた
    ↓
雨（解釈）：価格競争力の低下が原因。放置すれば他地域にも波及する
    ↓
傘（行動）：コスト構造を見直し、3ヶ月以内に価格改定を実施すべき

この構造が崩れると説得力が失われる：

Whyの並び立て

結論を複数の根拠で支える構成。ピラミッド構造の横の論理を活かす。

主張：コスト構造の見直しを優先すべき

なぜなら：
├── 1. 価格差が競合切り替えの主因である（効果が高い）
├── 2. 製造工程の見直しで15%のコスト削減が見込める（実現可能）
└── 3. 他の施策より短期間で効果が出る（即効性）

論理と感情のバランス

説得には論理だけでなく感情への働きかけも必要である。

論理だけでは人は動かない。感情だけでは持続しない。信頼がなければそもそも聞いてもらえない。3つのバランスを意識する。

感情に働きかける具体例：

• 抽象的な数字だけでなく、具体的な顧客の声を紹介する
• 「このまま放置すると何が起きるか」の危機シナリオを示す
• 「解決した後の姿」をビジョンとして描く

伝える際のチェックリスト

まとめ：問題解決の心構え

1. すぐに解決策を考えない
   • 表面的な問題に飛びつかず、真の課題を見極める
2. イシューから始める
   • 何を解くかを最初に決める。犬の道を避ける
3. 論理的に考える
   • 縦の論理（因果関係）と横の論理（網羅性）の両方を満たす
   • ピラミッド構造で思考を整理する
4. 具体と抽象を往復する
   • 事象から構造を見出し、構造を別の状況に適用する
5. 前提を問い直す
   • 問題定義時、仮説生成時、行き詰まり時にメタ認知を働かせる
6. 分解して扱えるサイズにする
   • MECE・Groupingで横の論理を、Why So?・So What?で縦の論理を担保する
7. 仮説→検証のサイクルを回す
   • 仮説なき分析は単なる作業
8. 伝えるまでが問題解決
   • ストーリーライン、論理と感情のバランス

問題解決は技術であり、意識的な訓練で向上する。まず「解く」前に「見極める」ことから始めよう。

関連

• イシューからはじめよ - 本記事のベースとなる思考法
• イシュー - 答えを出す価値のある本質的な問い
• イシュードリブン - イシューから始めるアプローチ
• ピラミッド構造 - 縦と横の論理で構成される思考の枠組み
• 仮説思考 - 仮説を立ててから検証に入る
• ストーリーライン - 論理的な全体構成
• ダブルループ学習 - 前提自体を問い直す学習
• バリューのある仕事 - イシュー度と解の質の両方が高い仕事
• 認知的距離 - 問題と解決策の間の認知的な隔たり

抽出された概念

• MECE - 漏れなくダブりなく分解する原則（横の論理の担保）
• ロジックツリー - 問題を木構造で分解する手法
• 縦の論理と横の論理 - 論理的思考の2つの方向性
• 帰納法と演繹法 - 縦の論理を構成する2つの推論形式