問題解決とは何か・なぜフレームワークが必要か
ビジネスにおける問題解決とは、「あるべき姿（理想）」と「現状」のギャップを認識し、そのギャップを埋める解決策を見つけ・実行するプロセスです。「問題」は現状と理想のギャップそのものを指し、「課題」は目標達成に向けて取り組むべき事柄を指します。この区別を曖昧にしたまま進めると、的外れな対策に終わりがちです。
フレームワークとは、問題解決の過程を体系化・標準化した思考の枠組みです。フレームワークを使うことで、複雑な問題を短時間で分解・分析でき、「思考の整理」と「スピードアップ」が実現します。ただし、フレームワーク自体を目的化してしまい、アクションにつながらないという失敗も多いため、あくまで問題解決を促進するための手段として使う意識が重要です。
問題解決の基本プロセス：What→Where→Why→How
どのフレームワークを使う場合も、問題解決の基本プロセスは共通しています。
- What（何が問題か）：問題を正確に定義する。「売上が低い」ではなく「〇月の新規顧客獲得数が目標比30%減」というように具体化する
- Where（どこで起きているか）：問題の発生箇所・範囲を特定する。全体の問題か、特定部門・製品・プロセスの問題かを絞り込む
- Why（なぜ起きているか）：根本原因を追究する。表面的な原因ではなく、問題が繰り返す真因を特定する
- How（どう解決するか）：具体的な解決策を立案・実行する。根本原因に対応した施策に絞り込む
このプロセスで特に重要なのはWhat（問題の正確な定義）です。問題が曖昧なまま解決策を探すのは、目的地を決めずに地図を開くようなものです。
主要な問題解決フレームワーク4選
1. PDCAサイクル
最も広く使われるマネジメントサイクルです。Plan（計画）→ Do（実行）→ Check（評価）→ Act（改善）の4ステップを繰り返すことで、継続的な改善を実現します。業務改善・営業管理・品質管理など、幅広い場面で活用できます。
PDCAの失敗の多くはPlan段階とCheck段階で起きます。Planでは目標設定が非現実的になりがちで、Checkでは成功・失敗要因の分析が形骸化しがちです。「とりあえず実行（Do）して、振り返り（Check）を省く」パターンが最もよく見られる失敗例です。
2. なぜなぜ分析（5 Whys）
「なぜ？」を繰り返すことで表面的な原因ではなく根本原因を特定する手法で、トヨタが開発しました。一般的に5回「なぜ」を繰り返すことで真の原因にたどり着くとされています。
例：「機械が止まった → なぜ？過負荷がかかった → なぜ？潤滑が不十分 → なぜ？ポンプが作動不全 → なぜ？軸が摩耗 → なぜ？金属くずが混入していた」→ フィルター設置という根本対策へ。表面原因（過負荷）を修正するだけでは再発を防げません。
なぜなぜ分析でよくある失敗は「つじつま合わせ分析」です。対策案を先に決め、それに合わせた原因分析をしてしまうパターンで、事実に基づいた客観的な分析が前提条件です。
3. ロジックツリー（イシューツリー）
問題や課題をMECE（モレなく・ダブりなく）の原則でツリー状に分解し、全体像と各要素の関係を可視化するフレームワークです。3種類あります。
- Why ツリー：問題がなぜ起きているかを探る（原因分析）
- How ツリー：どうすれば解決できるかを具体化する（解決策立案）
- What ツリー：問題を構成要素に分解する（構造把握）
例として「受注率が低い」という問題をWhy ツリーで展開すると、「営業担当の提案力不足」「提案書の質の問題」「商談数不足」に分解でき、それぞれに対して施策を立案できます。
4. フィッシュボーン図（特性要因図）
1956年に石川馨氏が考案した、「結果」と「要因」の因果関係を魚の骨状に可視化するフレームワークです。4M（Man：人、Machine：設備、Method：手順、Material：材料）の視点で大骨を設定し、各要因を深掘りします。製品の不良率上昇・サービス品質の低下など、複数の要因が絡み合う問題の分析に向いています。なぜなぜ分析と組み合わせると効果的です。
問題解決を正確に進めるための実践ポイント
業務を完璧に理解してから解決策を考える
問題解決の精度は、現状の正確な把握に比例します。何かを改善する前に、まず業務を完璧に理解して言語化することが前提（GL16）です。現場を直接見ず、データや報告書だけで分析を行うと、現実と乖離した解決策になりがちです。「現場に行く・当事者に直接話を聞く」というアクションが、問題の正確な把握に不可欠です。
仮説を持ってから分析する
問題解決においても、「仮説があり、事実確認したい」という状態で分析を進める（GL8）ことが効果的です。「何もわからないのでとりあえず調べる」という状態では、分析が発散し、時間を無駄にします。「〇〇が原因ではないか」という仮説を立て、その仮説を事実・データで��証するサイクルを回すことで、問題解決のスピードと精度が上がります。
As-Is / To-Be で問題を定義する
As-Is（現状）とTo-Be（理想状態）を明確に言語化することで、解決すべき問題の範囲と優先度が明確になります。現状が「月次クレーム件数50件」、理想が「月次クレーム件数10件以下」であれば、40件削減という具体的な目標が設定でき、そのギャップを埋めるための施策に集中できます。
フレームワーク活用時のよくある失敗
- 問題の定義が曖昧なまま進める：「業務が非効率」「売上が低い」という漠然とした問題認識のまま対策を考えると、的外れな施策に終わる
- フレームワーク完成が目的化する：ロジックツリーやフィッシュボーン図を「作ること」で満足し、アクションにつながらない
- 表面的な原因対処に留まる：「担当者の確認不足」という表層原因のみに対処し、なぜ確認不足が起きたかを掘り下げない
- 一次情報を確認しない：現場・当事者に直接確認せず、報告書やデータだけで原因分析を完結させる
まとめ
問題解決のフレームワークは、思考を整理しアクションを導くための道具です。What→Where→Why→Howのプロセスを守り、PDCAで継続的に改善し、なぜなぜ分析で根本原因を特定し、ロジックツリーでMECEに解決策を整理する――この組み合わせが、ビジネスの問題解決力を体系的に高めます。まず直面している業務課題を一つ選び、「問題の正確な定義」から始めてみましょう。