問題解決のプロセスとは？基本3ステップとDX時代のフレームワーク

問題解決のプロセスから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ステップを使って早い改善サイクルを回す方が得策です。

1．問題定義（What）

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

定義の前に問題発見

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

問題の再定義

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

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

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

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

2．問題特定（Where）

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

分ける（問題の分解）

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

選ぶ（重要課題の選択）

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

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

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

3．解決策立案（How）

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

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

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

4．実行（Execute）

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

What（問題定義）で使う主要フレームワーク

問題定義（What）では、「顧客は誰か」「解くべき問題は何か」を定めます。ここでは、顧客視点で問題を定義する「ジョブ理論」や、現状と理想のギャップから定義する「AsIs ToBe分析」などが使われます。

ジョブ理論（Jobs-to-be-Done）

これは「顧客は製品（モノ）を買っているのではなく、片付けたい用事（ジョブ）を解決するために雇っている」という考え方です。顧客の表面的なニーズではなく、本質的な「ジョブ（用事）」と、それが片付かない「ペイン（不満、悩み）」を明らかにすることで、解くべき問題をシャープに定義できます。

AsIs ToBe分析（現状とあるべき姿）

「AsIs（現状）」と「ToBe（あるべき姿）」をそれぞれ具体的に描き出し、その間にある「Gap（ギャップ）」を問題として定義するフレームワークです。特に業務改善やシステム導入のプロジェクトで強力です。

Where（問題特定）で使う主要フレームワーク

問題特定（Where）では、定義した問題を分解し、どこに焦点を当てるかを選びます。顧客体験を時系列で分解する「カスタマージャーニーマップ」や、問題を構造的に分解する「ロジックツリー」が代表的です。

カスタマージャーニーマップ

顧客がサービスを認知し、利用し、その後に至るまでの一連の体験を時系列で可視化する手法です。体験をフェーズごとに分解し、各フェーズでの顧客の行動、思考、感情（特にペイン）を洗い出します。これにより、顧客体験のどの部分（Where）が最も解決インパクトが大きいかを特定できます。

ロジックツリー

問題を構成要素に分解していく（構造化する）ためのフレームワークです。「MECE（モレなくダブりなく）」の原則に従って問題を分解し、根本的な原因や、最もインパクトの大きい打ち手（レバレッジ・ポイント）がどこにあるかを特定します。

How（解決策立案）のフレームワーク：基本方針＋具体策

解決策立案（How）では、特定した課題（Where）に対して具体的な打ち手を設計します。ここでは、アイデアを発散させるだけでなく、実行可能なプランに落とし込むことが重要です。

そのためのシンプルなフレームワークが「基本方針＋具体策」のセットで考えることです。

• 基本方針：解決の「方向性」を示す、抽象度の高いコンセプト（例：「手続きのストレスをゼロにする」）
• 具体策：基本方針を実現するための具体的なアクション（例：「AI-OCRによる自動入力」「チャットボットによる24時間サポート」）

まず方針（幹）を固めることで、その後の具体策（枝葉）がブレなくなり、関係者間での合意形成もスムーズに進みます。

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

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

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

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

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

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

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

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

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

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

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

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