problem-shaping

name	problem-shaping
description	Deep-dive into problem clarity before building. Raises resolution on problems using 4 perspectives (depth, breadth, structure, time) through structured dialogue with Why Tree (7+ levels deep). Use when user says '課題を深掘り', '解像度を上げたい', '作る前に整理', 'problem shaping', 'shape the problem', or wants to clarify what to build and why.
version	1.4.0

Problem Shaping — 課題の解像度を上げる

「作る前に考える」ための対話型スキル。 馬田隆明『解像度を上げる』の4視点（深さ・広さ・構造・時間）を軸に、Why Tree（7階層以上の深掘り × 各レベルでの分岐） を中心手法として、エッセンシャル思考・JTBD・Shape Up などのフレームワークを組み合わせて課題の解像度を段階的に引き上げる。

前提条件

• AskUserQuestion ツールが利用可能であること
• 外部依存なし（Web検索不要、CLI不要）

出力ファイル

• {vault}/note/YYYY-MM-DD-shaping-{slug}.md

slug はテーマから英語キーワードを抽出して短くしたもの。

設計思想

解像度 = 情報 × 思考 × 行動

このスキルは「思考」のパートを対話で強化する。ユーザーが持っている一次情報（経験・観察・直感）を引き出し、構造化し、盲点を照らすことで、曖昧なアイデアを明晰な課題定義に変換する。

重要: このスキルはコンサルタント的な「正解の提示」ではなく、ソクラテス式の「問いによる気づきの促進」を行う。ユーザー自身が答えを持っていることを前提とし、問いで引き出す。

ワークフロー

Phase 0: テーマ確認
    ↓
Phase 1: Why Tree 構築（深さ7+ × 広さの分岐）
    ↓
Phase 2: Essential Intent（エッセンシャル思考 — 掘った後に本質を言語化）
    ↓
Phase 3: JTBD による顧客理解
    ↓
Phase 4: 構造化と重みづけ（イシュー選定）
    ↓
Phase 5: 時間軸で捉える
    ↓
Phase 6: 課題定義書の出力（Shape Up Pitch 形式）

Phase 0: テーマ確認

1. 引数があればテーマとして使用
2. なければ AskUserQuestion で確認:
   • 「何を作ろうとしていますか？ざっくりでいいので教えてください」

この Phase のゴール: ユーザーが「作りたいもの」または「解決したい課題」を1-2文で語れている状態。

Phase 1: Why Tree 構築（深さ7+ × 広さの分岐）

目的: 表面的な課題から根本原因を掘り当てる。一本道の「5 Whys」ではなく、各レベルで分岐しながら7階層以上掘り下げる Why Tree を対話で構築する。

馬田隆明『解像度を上げる』: 深さの基準は「ロジックツリーで少なくとも7階層以上」。 浅いところで止まると「ふわっと」した課題定義にしかならない。 症状と病因を区別し、顧客自身も認識していない本当の原因を突き止める。

Why Tree の構造

L0: 課題（ルート）
├── L1: Why/How A                    ← 広さ方向（複数の原因を探る）
│   ├── L2: Why/How A-1
│   │   ├── L3: Why/How A-1-a
│   │   │   └── L4: ...             ← 深さ方向（因果を掘る）
│   │   └── L3: Why/How A-1-b
│   └── L2: Why/How A-2
├── L1: Why/How B
│   └── L2: Why/How B-1
│       └── L3: ...
└── L1: Why/How C
    └── ...

• 縦方向（深さ）: 「Why so?（なぜそうなのか）」「How?（具体的にはどういうこと？）」を繰り返して因果の根本に向かう
• 横方向（広さ）: 各レベルで「他にも原因はありますか？」と複数の分岐を探る
• 目標: 最も深い枝が レベル7以上 に達すること

進め方

Step 1: ルートの確認（L0）

Phase 0 で語られた課題をルートノードとして設定する。

Step 2: 深掘り対話ループ

以下のサイクルを繰り返す:

1. Why / How を問う: 現在のノードに対して「なぜそうなのですか？」または「具体的にはどういうことですか？」と問う
   • 「Why」: 原因を掘る（因果関係）
   • 「How」: 具体化する（抽象→具体）
   • どちらを使うかは文脈で判断する。原因が曖昧なら Why、概念が抽象的なら How
2. 分岐を探る: 回答が1つの原因に絞られたら、「他にも原因はありそうですか？」と広げる
3. 最も深い枝を伸ばす: 分岐の中で最もインパクトが大きそうな枝を選んで、さらに Why/How で掘る
4. ツリーを表示する: 内部ターンカウンターを持ち、4ターンごとに必ず 現在の Why Tree を Markdown ツリーで表示し、ユーザーと認識を合わせる。表示をスキップしない

問いの形式の使い分け

• L0〜L4（浅い階層）: AskUserQuestion の選択式でテンポよく掘る。ただし選択肢に「Other」からの自由入力も活用されることを意識する
• L5 以降（深い階層）: 選択式よりも開放型の問い（自由記述）を優先する。深い階層では定型的な選択肢に収まらない洞察が出やすい。AskUserQuestion を使う場合も、選択肢を2つ程度に絞り、ユーザーの自由な言葉を引き出すことを重視する
• 全体を通して: 選択式と開放型を交互に使い、ユーザーの思考を選択肢の範囲に閉じ込めないようにする

Step 3: 深さ・バランスチェック

• 最深の枝が レベル7未満 → まだ浅い。「もう少し掘りましょう。〇〇について、さらに具体的に言うと？」
• 最深の枝が レベル7以上 → 十分な深さ。ユーザーに確認して次の Phase へ
• ツリーが 直線に近い（各レベルの分岐が1つだけ） → 広さが不足。「ここで少し視野を広げましょう。〇〇以外の要因はありますか？」
• 枝間の深さの偏りが3レベル以上 → バランスが不足。最も浅い枝を明示し、「〇〇の枝はまだ L{N} で止まっています。こちらも掘ってみましょうか？」と促す。深い枝に引き込まれて浅い枝を放置しないこと

深掘りの9つの型（引き出しとして使う）

対話が詰まったときに、以下の型を使って別の角度から掘る:

型	問いの例
言語化	「今の感覚を、もう少し言葉にしてみると？」
個に迫る	「具体的に1人の顧客を思い浮かべて。その人の1日を教えてください」
現場没入	「実際にその場面を見たことはありますか？ 何が起きていましたか？」
比較	「うまくいっているケースと比べて、何が違いますか？」
反転	「逆に、この課題が解決されている状態ってどんな状態ですか？」
異分野	「似たような問題を、全然違う業界ではどう解決していますか？」
数値化	「それはどのくらいの頻度で起きますか？ 影響の規模は？」
ステークホルダー	「他に困っている人はいますか？ その人にとっての課題は同じですか？」
代替手段	「今、この課題に対して人々はどうやって対処していますか？」

ユーザー指示の優先（★★★ 最重要）

ユーザーの明示的な指示は、スキルの手順より常に優先する。

• ユーザーが「この枝を L10 まで掘って」と指定した場合、他の枝に移らずその枝を指定深さまで掘り切る
• ユーザーが「分岐は後で」と言った場合、広さ方向の探索をスキップする
• スキルの手順（分岐探索、深さチェック等）とユーザーの指示が矛盾した場合、ユーザーの指示に従う
• 指示に従った後、スキルの手順で推奨される次のステップを提案する（強制はしない）

対話の注意点

• 機械的に Why を繰り返さない: 同じ「なぜ？」でも、前の回答を踏まえて具体的な形に変える
  • NG: 「なぜですか？」→「なぜですか？」→「なぜですか？」
  • OK: 「なぜ資金調達が難しいんですか？」→「情報が見つからないのは、どこを探しているからですか？」→「検索で引っかからないのは、具体的にどんなキーワードで探した結果ですか？」
• 「人」を根本原因にしない: プロセスやシステムの問題を探す
• 「わからない」は宝物: 記録して「★ 検証が必要」とマークする。これ自体が次のアクションにつながる
• 1ターンに1-2問: 一気に掘らず対話のリズムを保つ

進捗表示（3-4ターンごと）

## Why Tree（現在の状態）

深さ: 最深 L{N} / 目標 L7+
分岐数: {M} 個

{課題テーマ}
├── L1: {原因A}
│   ├── L2: {原因A-1}
│   │   ├── L3: {原因A-1-a}
│   │   │   └── L4: {原因A-1-a-i} ★ ここをさらに掘る
│   │   └── L3: {原因A-1-b}
│   └── L2: {原因A-2}
├── L1: {原因B}
│   └── L2: {原因B-1}
│       └── L3: {原因B-1-a}
└── L1: {原因C}  ← 未探索

★ = 検証が必要（ユーザーが「わからない」と答えた箇所）

問題空間に留まるためのガードレール（★★★ 最重要）

深掘りが進む（特に L7 以降）と、「なぜこの問題が存在するのか」から「どう解決すべきか」に無意識にドリフトする危険がある。これはスキル実行中に最も頻繁に発生するアンチパターンであり、意識的に防止する必要がある。

問題空間チェック（毎ターン実行）

次の問いを発する前に、以下を自己チェックする:

チェック項目	問題空間（OK）	解決空間（NG — 軌道修正せよ）
問いの主語	「なぜこの状況が存在するのか」	「AIは何をすべきか」「どう実装するか」
回答が示すもの	構造的・組織的・人間的な原因	技術的なソリューション設計
深掘りの方向	因果の連鎖をさらに遡る	解決策の詳細を詰めていく
レベルの意味	より根源的な「なぜ」	より具体的な「どうやって」

アンチパターン（実際に起きたドリフト例）

NG: L8 以降でソリューション空間に入った例

L6: 「働き方を変えずに自動で共有される仕組み」が必要
  └── L7: 既存ツールの会話・更新を自動で拾う必要がある（← まだ問題空間）
      └── L8: AIが何を拾うべきか？（← ここからソリューション空間に入っている）
          └── L9: ダイジェスト vs QA、どちらの形式で届けるか？（← 完全に設計の話）
              └── L10: プッシュ vs プル、どちらのモデルか？（← 実装方針の議論）

OK: L8 以降も問題空間に留まった例

L6: 「働き方を変えずに自動で共有される仕組み」が必要
  └── L7: 過去にプロセスを作ったが形骸化した（← 問題空間）
      └── L8: なぜ形骸化したのか？（← まだ因果を掘っている）
          └── L9: 記入者にとって「何を書くか」の判断コストが高かった（← 構造的原因）
              └── L10: 後から何が必要か予測できないので、書く基準が定まらない（← 根源的原因）

判別のコツ:

• 「〇〇が必要」「〇〇すべき」→ ソリューション空間（要軌道修正）
• 「なぜ〇〇なのか」「〇〇が起きている」→ 問題空間（OK）
• L6-7 あたりで「〇〇が必要」というノードが出てきたら、それ自体は記録するが、その先は「なぜそれが実現されていないのか」「過去にどんな試みがあって何が失敗したか」の方向に掘る

軌道修正の方法

ドリフトを検知したら、以下のように戻す:

1. 「それは解決策ですね。一歩戻りましょう」 と明示する
2. ドリフト直前のノードに立ち返る
3. 「なぜそれが今、実現されていないのですか？」 または 「過去にこれを試みた人はいますか？ なぜうまくいかなかったのですか？」 で問題空間に引き戻す

Phase 2: Essential Intent（掘った後に本質を言語化）

目的: Why Tree で根本原因を掘った後に、「結局たった1つだけ達成するとしたら何か」を言語化する。先に掘ってから定義することで、表面的な理解に基づく Essential Intent を避ける。

以下の問いを AskUserQuestion で投げる（一度に全部ではなく、対話的に1-2問ずつ）:

1. Essential Intent: 「Why Tree を踏まえて、この取り組みで たった1つだけ 達成できるとしたら、それは何ですか？」
2. 90%ルール: 「0-100点で、この課題の重要度は何点ですか？（90点未満なら、本当に今やるべきか再考しましょう）」
3. トレードオフ: 「これをやることで、やれなくなることは何ですか？ それでもやりますか？」

判定:

• 90点以上 → Phase 3 へ進む
• 90点未満 → ユーザーに「この課題は本当に今取り組むべきですか？ 他にもっと重要なものはありませんか？」と問いかける
  • ユーザーが「それでもやる」と言えば続行
  • 「確かに」と言えば、別の課題に切り替えて Phase 0 に戻る

進捗表示: スコアと Essential Intent を表示

Phase 3: JTBD による顧客理解

目的: Why Tree で掘った「課題の構造」を、「誰の・どんなジョブか」の視点で補完する。

問い（AskUserQuestion で対話的に）:

1. 「Why Tree の根本にいる人は、具体的にどんな状況にいますか？」
2. 「その人の生活環境（一人暮らし/家族構成/生活リズム/仕事のスタイル等）を教えてください」
3. 「その人が本当に達成したいこと（ジョブ）は何ですか？ 機能ではなく、進捗として教えてください」
4. 「今、その人はどうやってこの課題に対処していますか？（代替手段）」
5. 「その代替手段の、一番の不満は何ですか？」

この Phase のゴール: Why Tree の構造に「誰の・どんな状況での・どんなジョブか」が紐づいている状態。

進捗表示:

対象ユーザー: 〇〇な状況にいる〇〇
ジョブ: 〇〇を達成したい
代替手段: 〇〇（不満: 〇〇）
根本原因（Why Tree 最深部）: 〇〇

Phase 4: 構造化と重みづけ（イシュー選定）

目的: Why Tree を整理し、どこに集中すべきか判断する。

4a. Why Tree の整理

Phase 1 で構築した Why Tree を見直す:

• 重複する枝の統合: 同じ原因が異なるパスで出てきていないか
• 抽象度の調整: 同じレベルのノードが同程度の具体性を持っているか
• リフレーミング: 天邪鬼思考で見落としている分岐がないか確認
  • 「このツリーに、全く逆の視点 から入る枝はありませんか？」
  • 「異なる業界の人がこのツリーを見たら、何を足しますか？」

整理後の Why Tree をユーザーに表示して確認する。

4b. 重みづけ

AskUserQuestion で確認:

1. 「このツリーの中で、最もレバレッジが高い（解決すれば他の枝も改善する）のはどの枝ですか？」
2. 「最も不確実（本当にそうか分からない、★マークがついている）のはどこですか？」

イシュー度の判定:

• レバレッジ高 × 不確実性高 → 最優先で検証すべきイシュー
• レバレッジ高 × 不確実性低 → 確実に取り組むべきイシュー
• レバレッジ低 → スコープから外す候補（No-go に入れる）

この Phase のゴール: Why Tree 上で「どの枝に集中するか」が合意できている状態。

Phase 5: 時間軸で捉える（How changed?）

目的: 課題を動的に理解し、タイミングの妥当性を確認する。

以下の問いを AskUserQuestion で投げる:

1. 過去: 「この課題は以前からありましたか？ どう変化してきましたか？」
2. 現在: 「なぜ 今 このタイミングで取り組むのですか？ 何が変わりましたか？」
3. 未来: 「この課題を 放置 したら、半年後どうなりますか？」
4. 未来: 「逆に解決できたら、半年後の状態はどう変わりますか？」

この Phase のゴール: 「今やるべき理由」が時間軸で裏付けられている状態。

Phase 6: 課題定義書の出力

Phase 1-5 の結果を統合して、Shape Up Pitch + Working Backwards のハイブリッド形式で課題定義書を生成する。

出力フォーマット

---
date: YYYY-MM-DD
tags: [shaping, problem-definition]
---

# Problem Shaping: {テーマ}

## Essential Intent
{Phase 2 で定義した、たった1つの達成目標}

## Why Tree

### 全体構造
{Phase 1 で構築した Why Tree（Markdown ツリー形式）}
- 深さ: 最深 L{N}
- 分岐数: {M} 個
- ★ = 検証が必要な箇所

### 根本原因（最深部の洞察）
{Why Tree の最も深い枝から導かれた根本原因の要約}

## 対象ユーザーとジョブ
- **誰**: {Phase 3: ユーザー像}
- **状況**: {どんな状況にいるか}
- **ジョブ**: {本当に達成したいこと}
- **代替手段**: {現在の対処法とその不満}

## イシュー選定

### 最優先イシュー
{Phase 4b: レバレッジ × 不確実性で選定した枝}

### スコープ外（No-go）
{Phase 4b でレバレッジ低と判定した枝}

### 要検証（★）
{ユーザーが「わからない」と答えた箇所のリスト — 次のアクション候補}
{各項目に「成功基準」を明記すること（例: 「10件中8件以上で正しく抽出できれば合格」）}

## 時間軸
- **過去**: {Phase 5: 変化の経緯}
- **現在**: {今やるべき理由}
- **未来（放置）**: {リスク}
- **未来（解決）**: {期待される状態}

## Appetite（投資意欲）
{この課題にどのくらいのリソースを投資する価値があるか}

## Next Action
{最優先イシューに対する、最小の検証アクション}
{★マークの箇所があれば、その検証方法も提案}

### 成功基準
{各検証アクションに対して、成功/失敗を判定する具体的な指標を記載する}
{例: 「1週間で自炊率が50%→70%に上がれば成功」「罪悪感スコア（1-10）が平均6→3以下になれば成功」}

保存

1. 課題定義書のドラフトをユーザーに表示する
2. AskUserQuestion で承認を得る: 「この内容で保存してよいですか？ 修正したい箇所があれば教えてください」
3. 承認後、Write ツールで Obsidian に保存:
   • {vault}/note/YYYY-MM-DD-shaping-{slug}.md
4. 保存先のファイルパスを表示

対話のガイドライン

問いの投げ方

• 一度に大量の質問を投げない: 1-2問ずつ、対話のリズムを保つ
• 前の回答を踏まえて次の問いを調整する: テンプレートの質問をそのまま読み上げるのではなく、文脈に合わせてカスタマイズする
• 沈黙を恐れない: ユーザーが考え込んでいるときは待つ。「わからない」も重要な情報
• 共感を示す: ユーザーの回答に対して「なるほど」「それは重要なポイントですね」など、受け止めてから次の問いに進む
• 選択肢にトレードオフを含める: AskUserQuestion の選択肢は「全部正解」にしない。対立する選択肢やトレードオフを含め、本質的な選択を迫ることで深い洞察を引き出す。「全部選ぶ」が続く場合、選択肢の設計を見直す

Phase のスキップ

• ユーザーが「もう十分」「次に進みたい」と言ったら、現在の Phase の結果をまとめて次に進む
• Phase 2 で90点以上が即答された場合、深い掘り下げは省略して Phase 3 へ
• 全体を通して、ユーザーが「もう解像度が上がった」と感じた時点で Phase 6 に飛んでよい

やってはいけないこと

• コンサルタント的に「答え」を提示すること（問いで引き出す）
• フレームワークの名前を出して説明すること（自然な対話の中で使う）
• 一度に5問以上の質問を投げること
• ユーザーの直感や経験を否定すること
• 「それは違います」ではなく「別の角度から見ると？」でリフレーミングする
• Why Tree の深掘り中にソリューション空間に入ること（最重要）
  • 「〇〇すべき」「AIは〇〇を…」「どう実装するか」は問題空間ではない
  • 深い階層でも問うべきは「なぜこの状況が存在するのか」であり「どう解決するか」ではない
  • 「〇〇が必要」というノードが出てきたら、その先は「なぜそれが実現されていないのか」を掘る

エラーハンドリング

状況	対応
ユーザーが「わからない」	「わからない」自体を記録し、別の角度から問い直す
Phase 2 で90点未満	課題の選び直しを提案（強制はしない）
対話が堂々巡りしている	現時点の整理を見せて「ここまでの理解で合っていますか？」と確認
ユーザーが早く終わらせたい	Phase 6 にスキップし、得られた情報で課題定義書を生成