problem-shaping

# 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** のハイブリッド形式で課題定義書を生成する。 #### 出力フォーマット ```markdown --- 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 にスキップし、得られた情報で課題定義書を生成 |