problem-framing

概要

問題のフレーミングは、解決策にリソースを投入する前に、正しい問題に取り組んでいることを確認する「発見のゲート」です。人間中心設計の原則と戦略カスケードを用いて、症状から根本原因へと進みます。

鉄則

承認済みの問題のフレーミングなしに分析を行わない 拙速な分析は、間違った問題の解決につながり、価値の低い、あるいは存在しない課題に対する洗練された解決策にリソースを浪費することになります。

状態遷移図

digraph problem_framing_flow {
    "Start" [shape=doublecircle];
    "Step 1: Observe & Gather Context" [shape=box];
    "Step 2: Root Cause Analysis (5 Whys)" [shape=box];
    "Step 3: Reframing & Questioning" [shape=box];
    "Gate: User Approval of Problem Statement" [shape=diamond];
    "Step 4: Define Winning Aspiration" [shape=box];
    "Done: Discovery Gate Passed" [shape=doublecircle];

    "Start" -> "Step 1: Observe & Gather Context";
    "Step 1: Observe & Gather Context" -> "Step 2: Root Cause Analysis (5 Whys)";
    "Step 2: Root Cause Analysis (5 Whys)" -> "Step 3: Reframing & Questioning";
    "Step 3: Reframing & Questioning" -> "Gate: User Approval of Problem Statement";
    "Gate: User Approval of Problem Statement" -> "Step 4: Define Winning Aspiration" [label="approved"];
    "Gate: User Approval of Problem Statement" -> "Step 1: Observe & Gather Context" [label="rejected"];
    "Step 4: Define Winning Aspiration" -> "Done: Discovery Gate Passed";
}

このスキルを使用する場面

• 新しいプロジェクト、戦略、分析タスクを始めるとき。
• プロジェクトが「行き詰まっている」ように感じられたり、方向性を見失ったりしたとき。
• ステークホルダー間で成功の定義が食い違っているとき。
• 「何を」または「なぜ」を十分に理解する前に、「どうやって」に飛びついていると気づいたとき。

このスキルを使用しない場面

• 手順が確立され、検証済みの、定型的でよく理解されているタスク。
• フレーミングにかかるコストが潜在的な価値を上回る些細なタスク（例：誤字の修正）。
• 以前の段階ですでに問題が厳密にフレーミングされ、承認されている場合。

中核となるプロセス

ステップ 1：観察して背景を把握する

• 応用エスノグラフィーを実践する： ユーザーの動機、関心、真のニーズを理解するため、ユーザーの自然な環境で観察します。人口統計だけでなく、実際に行われている 活動 に注目します。（出典：Norman, The Design of Everyday Things）
• 問題を説明する： 誰よりも的確に問題を説明することを目指します。「問題を最もよく説明する人が、それを解決する可能性が最も高い人です。」（出典：Kaufman, The Personal MBA）
• SPIN の背景情報を集める： （1）現状を理解する、（2）認識されている問題を特定する、（3）短期的および長期的な影響を明確にする。（出典：Kaufman, The Personal MBA）

ステップ 2：根本原因分析（5 Whys）

• 5 Whys を実施する： 症状を超えて究極的で根本的な原因を見つけるため、「なぜ？」と少なくとも5回問いかけます。（出典：Norman, The Design of Everyday Things）
• 「ヒューマンエラー」の罠を避ける： 分析を「ヒューマンエラー」で終わらせないでください。エラーが発生することを許したシステム、設計、または環境を調査します。（出典：Norman, The Design of Everyday Things）

ステップ 3：再定義と問いかけ

• 機能不全を招く思い込みに異議を唱える： 進歩を妨げる思い込み（例：「ずっとこのやり方でやってきた」や「これは不可能だ」）を特定します。それらをデザイン上の課題として捉え直します。（出典：Burnett, Designing Your Life）
• 適切な問いを立てる： すでに解決策を含んでいる問いの立て方は避けます（例：「より良いはしごをどう作ればよいか？」ではなく、「高い場所にどうすれば届くか？」）。（出典：Burnett, Designing Your Life）
• アンカープロブレムを特定する： 現状のままでは解決できない問題を認識し、実行可能な課題として捉え直します。（出典：Burnett, Designing Your Life）
• 対比による認識の形成： フレーミングを用いて、重要度の高い詳細を強調し、無関係な詳細を目立たなくすることで、注意を集中させます。（出典：Kaufman, The Personal MBA）

ステップ 4：勝利への願望を定義する

• 勝利への願望を設定する： 成功とは何かを定義します。これにより、カスケード内の以降の戦略的選択（Where-to-Play、How-to-Win）の背景が定まります。（出典：Lafley, Playing to Win）
• ニード・ペイオフを定量化する： 問題が解決された後に顧客／ユーザーが得る、金銭的および感情的なメリットを明確にします。（出典：Kaufman, The Personal MBA）

スキル間の呼び出し

必須のサブスキル：using-skills — 適切なスキル呼び出しの規律を確保します。 推奨されるサブスキル：stakeholder-discovery — 問題のフレーミングを誰が承認する必要があるかを把握します。

問題の合理化表

考え方	実態
「問題は明らかだから、すぐに始めよう。」	明らかな問題は、たいてい根本原因のより深いところにある症状にすぎません。
「問題の枠組みを定めるワークショップをする時間はありません。」	間違った問題を解決するには、正しく枠組みを定めるよりもはるかに長い時間がかかります。
「クライアントはすでに問題が何かを教えてくれました。」	クライアントは実際の問題ではなく、必要だと考えている解決策を説明することがよくあります。
「分析しながら問題の枠組みも定めていきます。」	枠組みを定めない分析は方向性を失い、確証バイアスに陥りやすくなります。

危険信号

次のような考えが浮かんだら、いったん止まりましょう。近道をしようとしています。

• 「まったく同じ問題を以前に見たことがある。答えはわかっている。」 → 検証せずにパターンマッチングに頼っています。
• 「[Specific Solution] を構築する必要があります。」 → 問題ではなく、解決策の枠組みを定めています。
• 「なぜかというと、[Name] がそう言ったからです。」 → 根本原因ではなく、権威を根拠にして考えるのをやめています。

診断チェックリスト

• 問題は技術要件ではなく、人々のニーズや目標という観点で表現されていますか？
• 根本原因にたどり着くために、「なぜ？」と少なくとも5回尋ねましたか？
• 問題の記述に、特定の解決策が含まれていませんか？
• 成功とは何かを定義する明確な「勝利への志」がありますか？
• 自然な環境にいるユーザーを観察して、問題の記述を検証しましたか？

参考文献

• Kaufman, The Personal MBA, Ch. 3 (Value Creation), Ch. 6 (Sales/SPIN)
• Lafley, Playing to Win, Ch. 2 (Winning Aspiration), Ch. 5 (Strategy Cascade)
• Norman, The Design of Everyday Things, Ch. 1 (Affordances/Signifiers), Ch. 6 (Design Thinking/HCD)
• Burnett, Designing Your Life, Ch. 1 (Reframing/Dysfunctional Beliefs)
• Kuang, User Friendly, Ch. 5 (Observation vs Creation)
• Berkun, Making Things Happen, Ch. 5 (Problem Definition)