株式会社renue
広告運用AIエージェント
広告運用、AIエージェントに任せてみませんか？
入札・予算配分からクリエイティブ改善まで、AIエージェントが広告運用を自動化します。何をどこまで自動化できるか、サービスページで確認できます。
問題解決とは何か・なぜフレームワークが必要か
ビジネスにおける問題解決とは、「あるべき姿（理想）」と「現状」のギャップを認識し、そのギャップを埋める解決策を見つけ・実行するプロセスです。「問題」は現状と理想のギャップそのものを指し、「課題」は目標達成に向けて取り組むべき事柄を指します。この区別を曖昧にしたまま進めると、的外れな対策に終わりがちです。
フレームワークとは、問題解決の過程を体系化・標準化した思考の枠組みです。フレームワークを使うことで、複雑な問題を短時間で分解・分析でき、「思考の整理」と「スピードアップ」が実現します。ただし、フレームワーク自体を目的化してしまい、アクションにつながらないという失敗も多いため、あくまで問題解決を促進するための手段として使う意識が重要です。
問題解決の基本プロセス：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）
「なぜ？」を繰り返すことで表面的な原因ではなく根本原因を特定する手法で、トヨタの公式資料で紹介されている手法です。Toyota Irelandの品質方針は、根本原因を調べるために「なぜ」を5回問うと説明しています。2006年3月のToyota Traditions記事の公開保存は、大野耐一氏による5回の問いかけと、先入観なく現場を観察する指導を紹介しています。5回は問いを深める手順の説明であり、回数だけで真因が必ず特定できるという実測保証ではありません。答えを現場の事実と照合する案です。歴史上の最初の考案者や開発時期は、今回確認した公式紹介記事だけでは確定していません。
例：「機械が止まった → なぜ？過負荷がかかった → なぜ？潤滑が不十分 → なぜ？ポンプが作動不全 → なぜ？軸が摩耗 → なぜ？金属くずが混入していた」→ フィルター設置という根本対策へ。表面原因（過負荷）を修正するだけでは再発を防げません。Toyota Traditionsの紹介例は、溶接ロボットの停止、回路過負荷、軸受の潤滑不足、油ポンプの供給不足、吸入口への金属切りくずの詰まり、ポンプのフィルター欠如を順に扱っています。本記事の「軸が摩耗」を含む機械停止例と細部は同一ではありません。原例の出所は未確認のため、この公式記事の事例や検証済みの実事故の記録と同一視せず、実際の対策は原因と装置条件を確認して選ぶ案です。
なぜなぜ分析でよくある失敗は「つじつま合わせ分析」です。対策案を先に決め、それに合わせた原因分析をしてしまうパターンで、事実に基づいた客観的な分析が前提条件です。
3. ロジックツリー（イシューツリー）
問題や課題をMECE（モレなく・ダブりなく）の原則でツリー状に分解し、全体像と各要素の関係を可視化するフレームワークです。3種類あります。
- Why ツリー：問題がなぜ起きているかを探る（原因分析）
- How ツリー：どうすれば解決できるかを具体化する（解決策立案）
- What ツリー：問題を構成要素に分解する（構造把握）
例として「受注率が低い」という問題をWhy ツリーで展開すると、「営業担当の提案力不足」「提案書の質の問題」「商談数不足」に分解でき、それぞれに対して施策を立案できます。この例で「商談数不足」を扱う際は、率と件数を分けてください。本記事で受注率を「対象をそろえた商談のうち受注した件数÷その商談数」と定義すると、商談数の少なさだけで率が低いとはいえません。商談数不足は受注件数が少ない問題の候補として扱い、受注率の問題では案件構成・提案内容などの仮説を、同じ対象・期間の成否データで確かめる案です。原例の「営業担当の提案力不足」「提案書の質の問題」も、確認済みの原因ではなく調べる仮説です。
4. フィッシュボーン図（特性要因図）
原記載の1956年という考案年は未確定で、石川馨氏に帰属する「結果」と「要因」の因果関係を魚の骨状に可視化するフレームワークです。4M（Man：人、Machine：設備、Method：手順、Material：材料）の視点で大骨を設定し、各要因を深掘りします。製品の不良率上昇・サービス品質の低下など、複数の要因が絡み合う問題の分析に向いています。なぜなぜ分析と組み合わせると効果的です。国土交通省の資料7（PDFの50頁目・誌面33頁）は1956年の考案と紹介する一方、日本科学技術連盟が公開する2012年4月号のQCサークル50年年表（PDFの1頁目）は前史欄で1953年の考案と記しています。資料間に年の異同があり、石川氏自身の最初の考案・発表資料を今回回収していないため、1956年を唯一確定した歴史的事実として扱わないでください。
問題解決を正確に進めるための実践ポイント
業務を完璧に理解してから解決策を考える
問題解決の精度は、現状の正確な把握に比例します。何かを改善する前に、まず業務を十分に理解して言語化することが前提です。現場を直接見ず、データや報告書だけで分析を行うと、現実と乖離した解決策になりがちです。「現場に行く・当事者に直接話を聞く」というアクションが、問題の正確な把握に不可欠です。
仮説を持ってから分析する
問題解決においても、仮説を立て、確かめたい事実を明確にしてから分析を進めることが効果的です。「何もわからないのでとりあえず調べる」という状態では、分析が発散し、時間を無駄にします。「〇〇が原因ではないか」という仮説を立て、その仮説を事実・データで検証するサイクルを回すことで、問題解決のスピードと精度が上がります。
As-Is / To-Be で問題を定義する
As-Is（現状）とTo-Be（理想状態）を明確に言語化することで、解決すべき問題の範囲と優先度が明確になります。現状が「月次クレーム件数50件」、理想が「月次クレーム件数10件以下」であれば、40件削減という具体的な目標が設定でき、そのギャップを埋めるための施策に集中できます。
フレームワーク活用時のよくある失敗
- 問題の定義が曖昧なまま進める：「業務が非効率」「売上が低い」という漠然とした問題認識のまま対策を考えると、的外れな施策に終わる
- フレームワーク完成が目的化する：ロジックツリーやフィッシュボーン図を「作ること」で満足し、アクションにつながらない
- 表面的な原因対処に留まる：「担当者の確認不足」という表層原因のみに対処し、なぜ確認不足が起きたかを掘り下げない
- 一次情報を確認しない：現場・当事者に直接確認せず、報告書やデータだけで原因分析を完結させる
まとめ
問題解決のフレームワークは、思考を整理しアクションを導くための道具です。What→Where→Why→Howのプロセスを守り、PDCAで継続的に改善し、なぜなぜ分析で根本原因を特定し、ロジックツリーでMECEに解決策を整理する――この組み合わせが、ビジネスの問題解決力を体系的に高めます。まず直面している業務課題を一つ選び、「問題の正確な定義」から始めてみましょう。
あわせて読みたい
AI活用の相談前に確認すること
AIによる問題整理や分析を検討する相談では、対象業務、現状と目標、指標の定義と集計対象、確認済みの事実と未確認の仮説、入力可能な情報、出力を確認する担当、検証期間と予算を整理する案です。AIの原因候補は現場の記録と照合し、対策は担当者が判断する案です。リンク先で支援内容と相談条件を確認してください。