問題解決のプロセス：What→Where→How

問題解決のプロセスとは：What→Where→How

ビジネス課題の問題解決プロセスは、次の4ステップに整理できます。

• 問題定義（What）：何が問題かを規定する
• 問題特定（Where）：どこが問題かを特定する（原因分析の視点を含む）
• 解決策立案（How）：何をするかを決め、計画に落とす
• 実行（Execute）：実行・評価・定着を図る

実行を別とすると、What→Where→Howの3ステップです。問題解決フレームワークには複数の流派があります。本稿では、組織内の納得感を得やすく、生成AIとも相性のよいシンプルな枠組みを採用します。

1．問題定義（What）

取り組むべき問題を明確化します。組織で解く場合は、誤解のない言語化と関係者の共通認識づくりが不可欠です。納得しやすい定義の枠組みを用意しましょう。

定義の前に問題発見

実務では、明確に言語化できない違和感や課題感（「Something Wrong」）から始まることが多いものです。観察・ヒアリング・データ探索で違和感を集め、定義の素材にします。

問題の再定義

一度で最適な定義に到達するのは困難です。仮定義を起点に、解くべき・解きやすい問題へと再定義します。

• レベルの上げ下げ：上位／下位の課題は何か？
• 視点の変更：誰の視点で読むか？誰が読んでも同じ問題に見えるか？

用語整理：問題と課題の違い

「問題」はあるべき姿と現状の差、「課題」は差を埋めるための具体的な行動です。定義で両者を混同しないことが、後工程の精度を高めます。

2．問題特定（Where）

合意したビジネス課題について、どこに焦点を当てるかを特定します。基本は「分けること」と「選ぶこと」です。

分ける（問題の分解）

ロジックツリーなどで構造化します。顧客課題の分解にはカスタマージャーニーマップが有効です。

選ぶ（重要課題の選択）

評価軸を決め、テコが効く重要課題を一つ（または資源に応じて少数）選びます。

原因分析（Why）の位置づけ

多くのフレームワークでは「Why（原因分析）」を独立ステップとしますが、本稿では Whereの内部で原因仮説の形成・検証 を行います。これにより、特定対象と原因の整合性を保ちながら優先順位付けが可能です。

3．解決策立案（How）

優先課題に対して解決策を設計します。抽象的な発想だけでなく、「基本方針＋具体策」のセットでアクションプラン（Action Plans）に落とすことが要点です。

実行の前に解決策立案（Action Plans）

Howは実行そのものではなく、実行のための計画づくりです。複数案を広く出し、評価軸で選定してから詳細プランに落とし込みます。

4．実行（Execute）

最も時間と資源を要するフェーズです。前段の3ステップで計画の質を高め、実行中はモニタリング・評価・定着（標準化）までをセットで回します。

問題解決プロセス実践：生成AIを使った問題解決

プロセスに沿って3つのワークショップを実施します（フレームワークとサンプルプロンプトは、貴社状況に合わせて調整）。詳細はAIを活用した問題解決研修をご参照ください。

ワークショップ1：問題定義（What）

「誰の」「どんなジョブの」「どんな課題」で定義します。ペルソナで解像度を上げると、次工程が容易になります。

問題定義プロセスでの生成AI活用方法

ワークシートとサンプルプロンプトを用意。初期テーマから生成AIで複数の顧客課題仮説を生成し、グループで定義を磨きます。

ワークショップ2：問題特定（Where）

カスタマージャーニーマップで顧客体験をフェーズ分解し、行動・ジョブ・ペインを対応づけます。重要な課題を一つ選びます。

問題特定プロセスでの生成AI活用方法

ジャーニー一式の原案を生成AIで複数生成し比較。分量が多い作業の省力化と発想の幅出しに有効です。

ワークショップ3：解決策立案（How）

選定課題の解決策を「基本方針＋具体策」で設計します。

解決策立案での生成AI活用方法

課題仮説から解決策までを生成AIで一式生成し、論理整合性を保ったまま複数案を比較。最適案を選定し、アクションプラン化します。

What→Where→Why→Howの問題解決プロセス

What→Where→Howを解説しました。もう一つの代表的問題解決プロセスにWhat→Where→Why→Howがあります。

• 問題定義（What）：何が問題かを規定する
• 問題特定（Where）：どこが問題かを特定する（原因分析の視点を含む）
• 原因分析（Why）：特定した問題の原因を分析する
• 解決策立案（How）：何をするかを決め、計画に落とす

問題解決の専門書などでは、What→Where→Why→Howの4ステップで解説することが多いです。しかし、本記事ではよりシンプルなプロセスとしてWhat→Where→Howの3ステップをおすすめします。

問題解決のプロセスからWhyを省略する理由

本来は問題解決プロセスで原因分析を行うことは必須です。しかし、ビジネス実務ではWhyを省略した3ステップを採用した方が効率的なことが多いです。

理由1：WhereとWhyの区別が難しい

英語の意味からもわかる通りWhereは問題点＝問題の場所の特定。WhyはWhereのプロセスで特定した問題点の原因を究明する作業です。問題解決プロセスのWhereとWhyのステップの違いは比較的明確なように思えます。
しかし、実際に分析してみると、問題解決プロセスのどのステップの話をしているのか共通見解を持つのは難易度が高いです。比較的区別がしやすいWhere（問題点）とHow（解決策）のプロセスでも混同が多く見られます。ましてや、似た概念であるWhereとWhyを区別することはますます困難です。

理由2：PDCAが回しやすい

What→Where→Why→Howの4ステップの方が厳密性が高い問題解決プロセスです。しかし、原因分析（Why分析）の難易度が高いこともあり、What→Where→Howの3ステップに比べ、多くの時間と労力がかかります。特にアジリティを求められるDX時代には、時間をかけるよりもざっと問題解決のプロセス全体を回して実行し、仮説検証。2周目、3周目と仮説検証プロセスを複数回繰り返す方が効果的です。
なお、実行コストが高い問題、たとえば高額の設備投資が必要なプロジェクトなどでは4ステップを採用した方が良い場合もあるでしょう。一方、日々の業務改善、データ活用によるPDCAなどはWhat→Where→Howの3ステップを使って早い改善サイクルを回す方が得策です。