| 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: テーマ確認
- 引数があればテーマとして使用
- なければ 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: 深掘り対話ループ
以下のサイクルを繰り返す:
- Why / How を問う: 現在のノードに対して「なぜそうなのですか？」または「具体的にはどういうことですか？」と問う
- 「Why」: 原因を掘る（因果関係）
- 「How」: 具体化する（抽象→具体）
- どちらを使うかは文脈で判断する。原因が曖昧なら Why、概念が抽象的なら How
- 分岐を探る: 回答が1つの原因に絞られたら、「他にも原因はありそうですか？」と広げる
- 最も深い枝を伸ばす: 分岐の中で最もインパクトが大きそうな枝を選んで、さらに Why/How で掘る
- ツリーを表示する: 内部ターンカウンターを持ち、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 あたりで「〇〇が必要」というノードが出てきたら、それ自体は記録するが、その先は「なぜそれが実現されていないのか」「過去にどんな試みがあって何が失敗したか」の方向に掘る
軌道修正の方法
ドリフトを検知したら、以下のように戻す:
- 「それは解決策ですね。一歩戻りましょう」 と明示する
- ドリフト直前のノードに立ち返る
- 「なぜそれが今、実現されていないのですか？」 または 「過去にこれを試みた人はいますか？ なぜうまくいかなかったのですか？」 で問題空間に引き戻す
Phase 2: Essential Intent（掘った後に本質を言語化）
目的: Why Tree で根本原因を掘った後に、「結局たった1つだけ達成するとしたら何か」を言語化する。先に掘ってから定義することで、表面的な理解に基づく Essential Intent を避ける。
以下の問いを AskUserQuestion で投げる（一度に全部ではなく、対話的に1-2問ずつ）:
- Essential Intent: 「Why Tree を踏まえて、この取り組みで たった1つだけ 達成できるとしたら、それは何ですか？」
- 90%ルール: 「0-100点で、この課題の重要度は何点ですか？（90点未満なら、本当に今やるべきか再考しましょう）」
- トレードオフ: 「これをやることで、やれなくなることは何ですか？ それでもやりますか？」
判定:
- 90点以上 → Phase 3 へ進む
- 90点未満 → ユーザーに「この課題は本当に今取り組むべきですか？ 他にもっと重要なものはありませんか？」と問いかける
- ユーザーが「それでもやる」と言えば続行
- 「確かに」と言えば、別の課題に切り替えて Phase 0 に戻る
進捗表示: スコアと Essential Intent を表示
Phase 3: JTBD による顧客理解
目的: Why Tree で掘った「課題の構造」を、「誰の・どんなジョブか」の視点で補完する。
問い（AskUserQuestion で対話的に）:
- 「Why Tree の根本にいる人は、具体的にどんな状況にいますか？」
- 「その人の生活環境（一人暮らし/家族構成/生活リズム/仕事のスタイル等）を教えてください」
- 「その人が本当に達成したいこと（ジョブ）は何ですか？ 機能ではなく、進捗として教えてください」
- 「今、その人はどうやってこの課題に対処していますか？（代替手段）」
- 「その代替手段の、一番の不満は何ですか？」
この Phase のゴール: Why Tree の構造に「誰の・どんな状況での・どんなジョブか」が紐づいている状態。
進捗表示:
対象ユーザー: 〇〇な状況にいる〇〇
ジョブ: 〇〇を達成したい
代替手段: 〇〇（不満: 〇〇）
根本原因（Why Tree 最深部）: 〇〇
Phase 4: 構造化と重みづけ（イシュー選定）
目的: Why Tree を整理し、どこに集中すべきか判断する。
4a. Why Tree の整理
Phase 1 で構築した Why Tree を見直す:
- 重複する枝の統合: 同じ原因が異なるパスで出てきていないか
- 抽象度の調整: 同じレベルのノードが同程度の具体性を持っているか
- リフレーミング: 天邪鬼思考で見落としている分岐がないか確認
- 「このツリーに、全く逆の視点 から入る枝はありませんか？」
- 「異なる業界の人がこのツリーを見たら、何を足しますか？」
整理後の Why Tree をユーザーに表示して確認する。
4b. 重みづけ
AskUserQuestion で確認:
- 「このツリーの中で、最もレバレッジが高い（解決すれば他の枝も改善する）のはどの枝ですか？」
- 「最も不確実（本当にそうか分からない、★マークがついている）のはどこですか？」
イシュー度の判定:
- レバレッジ高 × 不確実性高 → 最優先で検証すべきイシュー
- レバレッジ高 × 不確実性低 → 確実に取り組むべきイシュー
- レバレッジ低 → スコープから外す候補（No-go に入れる）
この Phase のゴール: Why Tree 上で「どの枝に集中するか」が合意できている状態。
Phase 5: 時間軸で捉える（How changed?）
目的: 課題を動的に理解し、タイミングの妥当性を確認する。
以下の問いを AskUserQuestion で投げる:
- 過去: 「この課題は以前からありましたか？ どう変化してきましたか？」
- 現在: 「なぜ 今 このタイミングで取り組むのですか？ 何が変わりましたか？」
- 未来: 「この課題を 放置 したら、半年後どうなりますか？」
- 未来: 「逆に解決できたら、半年後の状態はどう変わりますか？」
この 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以下になれば成功」}
保存
- 課題定義書のドラフトをユーザーに表示する
- AskUserQuestion で承認を得る: 「この内容で保存してよいですか？ 修正したい箇所があれば教えてください」
- 承認後、Write ツールで Obsidian に保存:
{vault}/note/YYYY-MM-DD-shaping-{slug}.md
- 保存先のファイルパスを表示
対話のガイドライン
問いの投げ方
- 一度に大量の質問を投げない: 1-2問ずつ、対話のリズムを保つ
- 前の回答を踏まえて次の問いを調整する: テンプレートの質問をそのまま読み上げるのではなく、文脈に合わせてカスタマイズする
- 沈黙を恐れない: ユーザーが考え込んでいるときは待つ。「わからない」も重要な情報
- 共感を示す: ユーザーの回答に対して「なるほど」「それは重要なポイントですね」など、受け止めてから次の問いに進む
- 選択肢にトレードオフを含める: AskUserQuestion の選択肢は「全部正解」にしない。対立する選択肢やトレードオフを含め、本質的な選択を迫ることで深い洞察を引き出す。「全部選ぶ」が続く場合、選択肢の設計を見直す
Phase のスキップ
- ユーザーが「もう十分」「次に進みたい」と言ったら、現在の Phase の結果をまとめて次に進む
- Phase 2 で90点以上が即答された場合、深い掘り下げは省略して Phase 3 へ
- 全体を通して、ユーザーが「もう解像度が上がった」と感じた時点で Phase 6 に飛んでよい
やってはいけないこと
- コンサルタント的に「答え」を提示すること（問いで引き出す）
- フレームワークの名前を出して説明すること（自然な対話の中で使う）
- 一度に5問以上の質問を投げること
- ユーザーの直感や経験を否定すること
- 「それは違います」ではなく「別の角度から見ると？」でリフレーミングする
- Why Tree の深掘り中にソリューション空間に入ること（最重要）
- 「〇〇すべき」「AIは〇〇を…」「どう実装するか」は問題空間ではない
- 深い階層でも問うべきは「なぜこの状況が存在するのか」であり「どう解決するか」ではない
- 「〇〇が必要」というノードが出てきたら、その先は「なぜそれが実現されていないのか」を掘る
エラーハンドリング
| 状況 | 対応 |
|---|
| ユーザーが「わからない」 | 「わからない」自体を記録し、別の角度から問い直す |
| Phase 2 で90点未満 | 課題の選び直しを提案（強制はしない） |
| 対話が堂々巡りしている | 現時点の整理を見せて「ここまでの理解で合っていますか？」と確認 |
| ユーザーが早く終わらせたい | Phase 6 にスキップし、得られた情報で課題定義書を生成 |
