第2章 相談を意思決定の問いへ変える

「解約率が上がっています。オンボーディングを改善したいので、競合を調べてください」

この依頼は具体的に聞こえます。問題は解約率、解決策はオンボーディング改善、作業は競合調査と、すでに揃っているように見えるからです。しかし、ここで調査を始めると、クライアントが最初に口にした因果関係と解決策を、そのまま正しいものとして扱うことになります。

解約率の上昇は、問題そのものではなく症状かもしれません。オンボーディングに原因があるとは限りません。価格改定、顧客構成の変化、サービス品質、競合の参入、計測方法の変更も候補です。そもそも、いま決めるべきことがオンボーディング施策なのかも分かりません。

コンサルタントは、依頼を受け取ってすぐ作業へ移るのではなく、その依頼を「誰が、何を、いつ、どの基準で決めるのか」という問いへ変換します。本章では、この変換を問題設定と呼びます。

問題設定は、最初に一度決めて固定する準備作業ではありません。調査や対話によって見直される仮説です。よい問題設定とは、問題を美しい一文にすることではなく、次に何を確かめ、何を決めればよいかを明らかにすることです。

2.1 依頼の言葉は出発点にすぎない

クライアントが最初に話す内容には、複数のものが混ざっています。

• 起きていること
• 困っていること
• 原因についての見立て
• すでに考えている解決策
• 社内で説明しやすい言い方
• コンサルタントへ頼みたい作業

先ほどの依頼を分けると、次のようになります。

依頼の言葉を疑うことは、クライアントを否定することではありません。発言には、その人が持つ経験と組織内の事情が含まれています。それを重要な初期仮説として尊重しながら、事実と解釈を分けます。

すぐに言い換えを提示するより、まず具体化します。

• 「解約率」はどのように定義していますか
• どの期間と比較して上がりましたか
• どの顧客群で変化していますか
• オンボーディングが原因だと考えた根拠は何ですか
• 競合調査の結果を受けて、誰が何を決めますか
• 何もしなかった場合、いつ、どのような影響が出ますか

ここでの目的は、質問を多くすることではありません。依頼の中に隠れている前提を、検証できる形にすることです。

2.2 症状、原因、課題、解決策の混同

問題に関する用語は、会社や本によって意味が揺れます。本書では、議論を追いやすくするため、次のように区別します。

この区別は、唯一の正しい用語体系ではありません。実務では、クライアントが使う言葉を無理に置き換える必要もありません。重要なのは、同じ言葉で別のものを指していないかを確かめることです。

症状も、価値判断から独立した事実ではありません。数値の変化は観測できても、それを「問題の兆候」とみなすには期待値が必要です。誰がどの期待を重視しているのか、その期待が顧客、従業員、経営者の間で衝突していないかを確認します。

混同すると、調査の順序が逆になります。解決策から始めると、その解決策を支持する情報ばかり集めやすくなります。症状を原因と呼ぶと、「解約率が高いのは顧客が解約するからだ」という循環した説明になります。課題を「オンボーディングを作ること」と置くと、作るかどうかを検討する余地がなくなります。

問題設定では、少なくとも次の鎖を仮置きします。

観測された症状
  ↓ 何が生んでいるか
原因仮説
  ↓ 何を変えられるか
課題
  ↓ どの方法を選ぶか
解決策仮説
  ↓ 誰が何を決めるか
意思決定の問い

矢印は事実ではありません。それぞれが検証対象です。一本の鎖に早く絞らず、重要な代替仮説を残します。

原因候補は、根拠の強さ、症状への影響の大きさ、介入可能性を分けて評価します。影響が大きくても変えられない要因があり、変えやすくても影響が小さい要因があります。「原因らしい」と「いま働きかける価値がある」は別の判断です。

2.3 問題の見方が解決策を狭める

同じ状況でも、問題の切り取り方によって、調べるものと選択肢が変わります。

たとえば「会議が多く、開発が遅い」という相談を考えます。

会議の効率として捉える

会議時間、参加者、議題、進行方法を調べます。解決策は、会議の削減、時間制限、議事進行の改善などになります。

意思決定権限として捉える

誰が承認するのか、どの判断が上位者へ集中しているのかを調べます。解決策は、権限委譲、判断基準の明文化、承認段階の変更などになります。

仕事の依存関係として捉える

複数チームの作業がどこで待ち合っているかを調べます。解決策は、チーム境界、担当範囲、システム構造の変更かもしれません。

優先順位として捉える

同時に進める案件数や、割り込みの発生源を調べます。解決策は、仕掛かりの制限、経営判断の集約、案件の中止かもしれません。

どれか一つが最初から正しいわけではありません。複数の見方を置くと、最初の解決策へ固定されるのを防げます。一方で、可能性を無限に広げると何も調べられません。次の観点で、最初に確かめる見方を絞ります。

• 観測された複数の症状を説明できるか
• 反証できる形になっているか
• 行動につながるか
• 重要な関係者を見落としていないか
• 期限内に確かめられるか

戦略的な問題のフレーミングと定式化を研究した Ananth、Park、Turner は、症状へ注意を向ける段階と、その症状を説明する原因を組み立てる段階を区別しています。戦略的で複雑な問題では、目立つ一つの症状だけを見るより、関連する症状を広く確認してから原因を考えることが、狭すぎる局所的な解決を避ける助けになります。緊急対応や境界の明確な技術問題では、必要な速度に合わせて探索範囲を狭めます。

問題定義を研究した Gerald F. Smith は、問題解決には問題の定義や表現が先行する一方、その定義自体が十分に扱われてこなかったと指摘しています。問題をどう表現するかは、分析モデルを作る前の単なる言葉選びではなく、その後の探索を方向づける判断です。

2.4 誰の問題かで境界が変わる

「売上が落ちた」という症状でも、関係者によって問題の意味は異なります。

• 経営者は、利益と成長への影響を見る
• 営業責任者は、商談数と成約率を見る
• プロダクト責任者は、顧客が価値を得られているかを見る
• 顧客は、支払った費用に見合う結果が得られるかを見る
• サポート担当者は、問い合わせ増加と対応負荷を見る

一つの視点だけで境界を決めると、別の場所へ負担を移す解決策を選びかねません。サポート時間を短縮して費用を下げても、顧客の自己解決が難しくなり、解約が増えれば全体では悪化します。

問題設定では、次を確認します。

• 誰が困っているのか
• 誰が決めるのか
• 誰が実行するのか
• 誰が利益を得るのか
• 誰が費用や危険を負うのか
• 誰の声が、現在の会話に入っていないのか

すべての関係者を同じ重さで扱うという意味ではありません。関係者の期待が対立するとき、問題設定によって対立を消したように見せてはいけません。両立しない目的と、各案で誰が負う不利益を記録し、決定者が選択の理由を説明できるようにします。

複雑な問題では、唯一の定義へ急いで合意すること自体が危険です。経済協力開発機構（OECD）と国際応用システム分析研究所（IIASA）のシステム思考に関する報告も、複雑な政策課題では相互関係、フィードバック、複数の価値を扱う必要があり、単一の問題定義や評価尺度への固定を避けるよう提案しています。企業の案件すべてが同じ複雑さを持つわけではありませんが、部門をまたぐ問題では参考になります。

2.5 意思決定の問いに必要な 7 要素

問題を広く理解するだけでは、プロジェクトを進められません。何を決めるかまで具体化します。本書では、意思決定の問いを次の 7 要素で記述します。

冒頭の依頼は、まず次のように構造化できます。

決定者: 事業責任者
選択: どの顧客群へ、どの初期支援を試すか
期限: 8 月末
目的: 新規顧客の 90 日以内解約を減らす
判断基準: 期待効果、顧客への危険、支援工数、実行可能性、学習価値（次の判断で不確実性を減らせる情報が得られるか）
制約: 追加開発なし。既存人員で 4 週間運用できる
不足: 解約が増えた顧客群、初期行動との関係、手動支援の効果と負荷

この 7 要素は、決める前の問いを構造化します。施策を試す段階では、別に停止条件を加えます。この例なら、顧客苦情または 1 人あたりの支援工数が合意した上限を超えたら停止します。

これを一文にすると、次のようになります。

事業責任者が 8 月末までに、新規顧客の 90 日以内解約を減らすため、どの顧客群へどの初期支援を試すかを決める。期待効果、顧客への危険、支援工数、実行可能性、学習価値で比較する。追加開発は行わず、既存人員で 4 週間運用できることを条件とし、解約が増えた顧客群、初期行動との関係、手動支援の効果と負荷を確かめる。

この一文が最終回答なのではありません。次の調査を設計するための暫定的な問いです。調べた結果、問題が初期利用ではなく価格改定後の顧客構成にあると分かれば、問いを変えます。

この問いは、コンサルタントだけで確定しません。決定者、プロジェクトのスポンサー、実務責任者と確認し、異論と未合意点も残します。未合意点には、解消する責任者と期限を付けます。全員が同じ文言を暗記する必要はありませんが、調査結果を受けて誰が何を変えるのかは共有します。

政策判断向けの OECD のチェックリストも、問題の性質と規模、発生理由を明確にし、介入の便益と費用、代替手段を比べることを求めています。対象は規制ですが、「対策を選ぶ前に問題と代替案を明らかにする」という順序は、事業上の問題設定にも応用できます。

2.6 スコープは「扱わないこと」まで決める

問題の境界を広げれば、多くの要因を含められます。しかし、すべてを扱うプロジェクトは終わりません。

スコープでは、対象だけでなく、扱わないものと理由を記録します。

除外は「重要ではない」という宣言ではありません。期限内の決定に対して、いまは優先しないという選択です。除外した要因が重要だと分かったときに戻せるよう、理由と見直し条件を残します。

スコープを変えるときは、変更した問い、変更理由、期限と費用への影響、承認者を短いログに残します。変更そのものより、誰にも共有されないまま期待だけが変わることを避けます。

また、スコープは分析対象だけではありません。誰に話を聞けるか、どのデータを使えるか、どの会議で決めるかも境界です。意思決定者へアクセスできないなら、問いをどれだけ整えても、提案は決定につながりません。

2.7 AI には答えより別の見方を求める

問題設定で AI を使う価値は、最初から正しい問題を当ててもらうことではありません。人間が置いた見方を広げ、暗黙の前提と反証候補を見つけることにあります。

たとえば、次の材料を渡します。

観測された症状:
新規顧客の 90 日以内解約率が、直近 3 か月で上昇した。

現在の見立て:
オンボーディングに問題がある。

決めたいこと:
来月、解約を減らすために何を試すか。

制約:
追加開発はできない。4 週間、既存人員で試せること。

依頼:
1. この問題の別の捉え方を 5 つ挙げる
2. 各案について、成立を支持する事実と反証する事実を示す
3. 最初の 1 週間で確認できることを示す
4. 現在の問いに埋め込まれた前提を指摘する

AI の候補は、事実ではありません。実在しない顧客事情や、与えていない因果関係を補うことがあります。候補を採用する前に、社内データ、顧客との対話、業務の観察、一次資料で確かめます。

もう一つの危険は、詳細な依頼文が AI の探索を固定することです。「オンボーディングが原因です」と断定してから改善案を求めれば、その前提に沿った案が増えます。現在の見立てを仮説と明記し、「この見立てが誤っているとしたら何が起きているか」を尋ねます。

AI は問題設定の速度を上げますが、問題の境界によって誰が得をし、誰が見落とされるかを判断する責任は人間に残ります。

2.8 問題設定を更新する合図

問題設定に時間をかけすぎると、調査も行動も始まりません。反対に、早く固定しすぎると、後から得た事実を現在の枠へ押し込みます。

決定の重要度と失敗費用に応じて、問題設定の深さを変えます。小さく取り消しやすい判断なら、最低限、次の 4 点があれば動き始められます。

1. 誰が、何を、いつ決めるか
2. 最初に何を確かめるか
3. どの条件で止め、問いを見直すか
4. 顧客、法令、安全への重大な危険がないか

大きな投資、組織変更、顧客へ不可逆な影響を与える判断では、関係者、原因仮説、判断基準、スコープをより丁寧に確認します。

通常の問題設定は、次の条件が揃えば調査を始められます。

• 暫定的な決定者と決定期限が分かる
• 原則として、現状維持を含む代替案を確認している
• 主要な症状と原因仮説を区別している
• 最初に確認する事実が決まっている
• 対象と、いま扱わない範囲が分かる
• 新しい事実によって問いを見直せる

法令対応、事故対応、緊急障害など、選択の余地や時間が小さい場合は、数を満たすために案を増やしません。その場合も、実行方法、危険の抑え方、停止や復旧の条件は比較できます。

調査中に次の合図が現れたら、問題設定へ戻ります。

• 症状の定義や数値が部門によって異なる
• 主要な原因仮説を反証する事実が見つかった
• 決定者が想定と違った
• 選択肢が最初から一つに固定されていた
• 対策による負担が別の関係者へ移ると分かった
• 期限や制約が変わった
• 集めた情報が、決定に使われない状態が続いた

問題設定の変更は失敗ではありません。新しい事実を受けても問いを変えないことの方が問題です。ただし、変更するたびに、調査範囲、期限、費用、関係者への影響を共有し、変更ログに残します。

2.9 依頼を問いへ変える 4 手順

ここまでの内容を、実務で最初に行う順序へまとめます。

1. 依頼を分ける 観測された症状、原因仮説、解決策仮説、作業依頼を分けます。
2. 別の見方を置く 別の見方を置き、最初に確かめるものを選びます。
3. 意思決定の問いを書く 決定者、選択、期限、目的、判断基準、制約、不足を記述します。
4. 合意して、更新条件を決める 決定者と実務責任者へ確認し、最初に確かめること、停止条件、問いを見直す合図を残します。

この 4 手順は、前の節を省略するための新しいフレームワークではありません。案件の大きさに合わせて、どこを詳しく確認するか判断するための入口です。

考えてみる問い

最近受けた依頼を、症状、原因仮説、解決策仮説、作業依頼に分けてください。そのうえで、決定者、選択、期限、目的、判断基準、制約、不足の 7 要素を使い、意思決定の問いへ書き換えてみましょう。

問題設定は、最初から正しい問題を言い当てる技術ではありません。依頼に含まれる前提を見えるようにし、複数の見方を比べ、次に確かめることを決める技術です。

問いが定まれば、次は限られた時間の中で何を行うかを設計できます。第3章では、仮説、作業、成果物を結び、プロジェクトを進める道筋を扱います。

参考資料

最終確認日: 2026 年 7 月 15 日。本章の用語区分と「意思決定の問い」の 7 要素は、以下の資料を踏まえた本書独自の整理です。

• Gerald F. Smith ― Defining Managerial Problems: A Framework for Prescriptive Theorizing
• OECD ― Reference Checklist for Regulatory Decision-making
• OECD / IIASA ― Systemic Thinking for Policy Making
• Ananth, Park and Turner ― Looking at the Trees to See the Forest: Construal Level Shift in Strategic Problem Framing and Formulation