厄介な問題フレームワーク

英語名 Wicked Problem Framework
読み方 ウィキッド プロブレム フレームワーク
難易度
所要時間 数日〜数週間(問題の規模による)
提唱者 Horst Rittel & Melvin Webber (1973)
目次

ひとことで言うと
#

「正解がなく、定義自体が曖昧で、解こうとするたびに問題の姿が変わる」ような厄介な問題(Wicked Problem)に対し、従来の分析的アプローチではなく探索・実験・適応のサイクルで立ち向かうフレームワーク。ホルスト・リッテルとメルビン・ウェバーが1973年に概念を提唱した。

押さえておきたい用語
#

押さえておきたい用語
厄介な問題(Wicked Problem)
明確な定義も正解もなく、解こうとする行為自体が問題を変化させるような複雑な問題。気候変動、貧困、組織文化の変革などが典型例。
おとなしい問題(Tame Problem)
定義が明確で、手順を踏めば正解にたどり着ける問題。数学の方程式や製造工程の最適化などが該当する。厄介な問題との対比で使われる。
ステークホルダーの多元性
厄介な問題では関係者ごとに問題の定義が異なり、「何を解決すべきか」についてすら合意が取れないこと。
適応的アプローチ(Adaptive Approach)
計画通りに進めるのではなく、小さく試して、結果から学び、方向修正を繰り返す問題解決スタイル。厄介な問題に対する基本姿勢。

厄介な問題フレームワークの全体像
#

厄介な問題フレームワーク:問題の性質を見極めてアプローチを選ぶ
合意の度合い確実性の度合い高い低い高いおとなしい問題Tame Problem定義が明確・正解がある→ 分析的に解けるベストプラクティス適用複雑な問題Complex Problem因果関係が不明確→ 実験して学ぶプローブ → 検知 → 対応厄介な問題Wicked Problem定義自体が流動的→ 適応し続ける探索 → 実験 → 適応複雑さが増す
厄介な問題への取り組みフロー
1
問題の性質を見極める
おとなしい問題か厄介な問題かを判定
2
多元的に問題を定義する
ステークホルダーごとの視点を集約
3
小さく実験する
仮説を立て、低コストで試して学ぶ
適応し方向修正する
結果から学び、問題定義も更新し続ける

こんな悩みに効く
#

  • 問題を定義しようとするだけで関係者の意見が割れ、議論が前に進まない
  • 過去に成功した解決策を適用しても、今回はまったく機能しない
  • 問題を解決したはずなのに、別の場所に新たな問題が発生してしまう
  • 不確実性が高すぎて、従来の計画駆動型アプローチでは手が付けられない

基本の使い方
#

問題の性質を診断する

目の前の問題が「おとなしい問題」「複雑な問題」「厄介な問題」のどれかを見極める。

  • おとなしい問題のサイン: 問題の定義が明確、類似の成功事例がある、正解がある
  • 厄介な問題のサイン: ステークホルダーごとに問題の定義が違う、解くたびに問題の姿が変わる、やり直しがきかない
  • 厄介な問題に分析的アプローチ(MECE分解→施策実行)を当てはめると、的外れな解決策に大量のリソースを投じるリスクがある
ステークホルダーの視点を多元的に集約する

厄介な問題では「問題の定義」自体が人によって異なる。まず各ステークホルダーの視点を集め、問題の全体像を多元的に描く。

  • 各ステークホルダーに「あなたにとってこの問題とは何か」をヒアリングする
  • 視点の違いを「対立」ではなく「問題の多面性の表れ」として捉える
  • 全視点を統合した「暫定的な問題定義」を作る。ただし、これは後で変わることを前提にする
小さな実験を設計し実行する

正解がわからないからこそ、仮説を立てて小さく試す。失敗のコストを最小化しながら学ぶ。

  • 「この仮説が正しければ、この小さな施策でこの変化が起きるはず」という形式で実験を設計する
  • 実験期間は2〜4週間が目安。長すぎると環境が変わり、学びが陳腐化する
  • 同時に複数の実験を走らせ、ポートフォリオとして管理する
結果から学び、問題定義も更新する

実験の結果を踏まえて次の一手を決め、必要に応じて問題の定義そのものを改訂する。

  • 「実験が失敗した」は「正解に近づいた」と読み替える。何が機能しないかわかったのは前進
  • 問題定義が変わったら、ステークホルダーと共有し直す
  • このサイクルを「もういいだろう」ではなく「十分に改善された」と合意するまで繰り返す

具体例
#

例1:大企業のDX推進が泥沼化した問題を立て直す

従業員3,000名の製造業。CDO直轄でDXプロジェクトを立ち上げ、2年間で8億円を投じたが、現場への浸透率は12%。経営層は「現場が変わらない」、現場は「使えないシステムを押し付けられている」と対立していた。

問題の診断: 「DX推進」は典型的な厄介な問題だった。技術導入(おとなしい問題)として扱ったことがそもそもの誤り。

ステークホルダーの視点:

  • 経営層:「デジタル化でコスト30%削減」が問題定義
  • 現場管理者:「日報のデジタル化で仕事が増えた」が問題定義
  • 現場作業員:「なぜ今のやり方を変えるのかわからない」が問題定義
  • IT部門:「要件が曖昧でシステムの仕様が定まらない」が問題定義

アプローチ転換: DXの全社展開を一時凍結し、3つの現場で8週間ずつの実験を開始。

  • 実験A: 作業員自身が「デジタル化したい作業」を選び、小さなツールを開発
  • 実験B: 管理者と作業員が一緒にデータダッシュボードを設計し、「見たい数字」を決める
  • 実験C: 既存システムの機能を半分に削り、最も使われている機能だけに集中

結果: 実験Aの現場で浸透率が**12% → 68%**に跳ね上がった。「自分で選んだ」という自律性が鍵だった。この学びを全社展開の方針に反映し、トップダウンの一括導入からボトムアップの段階的導入に切り替えた。

例2:地方自治体の人口減少対策を再構築する

人口5万人の地方都市。過去10年で人口が18%減少し、様々な施策(移住補助金、空き家バンク、観光PRなど)を打ってきたが効果が限定的。年間予算1.2億円を使いながら、転入者数は横ばいだった。

問題の診断: 「人口減少」は厄介な問題の典型。原因は雇用・教育・医療・文化・交通など複合的で、一つの施策で解決できるものではない。

多元的な問題定義:

  • 若者:「働きたい仕事がない」
  • 子育て世帯:「教育環境と医療アクセスが不安」
  • 移住検討者:「情報が断片的で、実際の生活イメージが湧かない」
  • 地元事業者:「人手不足で事業を拡大できない」

小さな実験:

  • 実験1: IT企業3社にリモートワーク拠点を提供し、「週3日在住」のセミ移住を6か月間試行
  • 実験2: 地元高校と連携し、高校生が地元事業者のDXを手伝う「地域インターン」を実施
  • 実験3: 移住検討者向けの「2週間お試し暮らし」プログラム(家賃・光熱費を自治体が負担)

結果: 実験1のセミ移住モデルが最も効果が大きく、参加者15名のうち9名が1年以内に正式移住。「完全移住はハードルが高いが、セミ移住なら試せる」という洞察が得られた。これを受けて移住施策の主軸を「補助金による完全移住促進」から「段階的な関わりの設計」に転換。翌年の転入者数が前年比34%増

例3:スタートアップが市場が存在するかわからない領域で事業を立ち上げる

創業2年目のヘルステック・スタートアップ。「高齢者の孤立をテクノロジーで解決する」をミッションに掲げたが、顧客(高齢者本人・家族・介護施設)ごとに課題認識が異なり、プロダクトの方向性が定まらなかった。シード資金5,000万円のランウェイは残り10か月

問題の診断: 「高齢者の孤立」は厄介な問題。孤立の定義が人によって違い、テクノロジーが解決できる範囲も不明確。

ステークホルダー視点の集約:

  • 高齢者本人:「人に会いたいが、自分から連絡するのは面倒」
  • 家族:「親が元気かどうか、毎日確認する手段がほしい」
  • 介護施設:「入居者の孤立感を定量的に把握できない」

実験ポートフォリオ(各4週間):

  • 実験A: 高齢者同士を自動マッチングする音声通話アプリ
  • 実験B: 家族向けの「見守りダッシュボード」(IoTセンサーで活動量を可視化)
  • 実験C: 介護施設向けの孤立リスクスコアリングツール

結果:

  • 実験Aは利用率が低かった。「知らない人と話したいわけではない」ことが判明
  • 実験Bは家族からの評価が高く、月額980円の支払い意欲を確認。ただし高齢者本人は「監視されている感じ」と抵抗
  • 実験Cは介護施設3社がパイロット導入を希望

学びを統合し、プロダクトの方向性を「高齢者同士をつなぐ」から「介護施設の孤立リスク可視化+家族への共有」に転換。最初の問題定義とは大きく異なるプロダクトになったが、実験を通じて「本当に求められているもの」にたどり着いた。

やりがちな失敗パターン
#

  1. 厄介な問題をおとなしい問題として扱う — MECE分解→KPI設定→施策実行の直線的アプローチは、おとなしい問題には有効だが厄介な問題には通用しない。「計画通りにやったのに成果が出ない」のは、問題の性質を見誤っている可能性がある
  2. 一発で正解を出そうとする — 厄介な問題に正解はない。「より良い状態」を目指して探索し続ける姿勢が必要。完璧な計画を立ててから動こうとすると、永遠に動けない
  3. ステークホルダーの視点を統一しようとする — 問題定義のばらつきは厄介な問題の本質。無理に一つの定義に統一すると、重要な視点が抜け落ちる。多元性を保ったまま前に進む技術が求められる
  4. 実験の失敗を許容しない — 厄介な問題における実験の目的は「正解を見つける」ではなく「何が機能しないかを学ぶ」こと。失敗を責める文化では、安全な選択肢しか試されなくなり、学びの質が低下する

まとめ
#

厄介な問題フレームワークは、正解のない複雑問題を「解く」のではなく、**探索・実験・適応のサイクルで「付き合っていく」ための思考法である。まず問題の性質を見極め、厄介な問題にはステークホルダーの多元的な視点を集約したうえで小さな実験を繰り返す。計画駆動ではなく学習駆動で進むことで、最初は見えなかった突破口が見えてくる。大事なのは「正解を出す力」ではなく「正解がない状況で前に進む力」**である。