# Frame Problem

> 機能・施策に着手する前の計画段階で、問題そのものを枠組み化し、そのまま解決策の意思決定まで詰めきるスキル。 アクター・目的・文脈・ルールを確認し、ユビキタス言語すなわちチーム共通の用語定義を整え、なぜやるのか・なぜ今やるべきかの背景を構造化する。 枠組みが固まったら別ツールへ渡さず、本スキルの中でどの解決策にするかを一問一答で収束させる。 「新機能の計画を立てたい」「企画段階を整理したい」「なぜやるのか整理して」「課題を定義したい」「前提を整理したい」「設計の前に土台を固めたい」 「ユビキタス言語を定義したい」「チームの共通言語を作りたい」「用語の認識を揃えたい」「ステークホルダーを洗い出したい」「Why を明確にしたい」 「何を作るべきか曖昧」「背景を整理して」「要件の前提を確認したい」「どの案にするか決めたい」「解決策を絞り込みたい」といった依頼で積極的に使うこと。

- Skill: `maro114510/frame-problem` (Agent Skill)
- Install (CLI): `npx skillmds@latest add maro114510/frame-problem`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maro114510/frame-problem/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: maro114510 (https://skillmd.com/u/maro114510)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/maro114510/frame-problem

---


# frame-problem

機能や施策に着手する前に、**問題そのものを枠組み化し、そのまま採用する解決策まで決めきる**スキル。
品質最優先で、時間をかけてでもユーザーが気づいていない致命的な前提のズレや論理の漏れを発見して問いかける。

---

## 思考の軸（出力には出さない）

- **語の意味は使用で決まる**: 「ユーザー」「注文」「公開」が話者ごとに別の物事を指していないかを常に疑う。
- **人は暗黙の枠組みで隙間を埋める**: 「言わなくても分かる」という省略こそが後で食い違う。明示されていない前提を能動的に言語化させる。

---

## Step 1: 事前調査

`$ARGUMENTS` とこの会話の文脈を解析し、コードや仕様書で分かることは自分で調べる。

- **ファイルパスやリポジトリがある場合**: `Read` / `Glob` / `Grep` / `git grep` でドメイン用語・既存概念・関連機能を把握する。人間の時間を調べ物に使わせない。
- **仕様・Issue・設計書がある場合**: 全文を読んでから枠組みする。部分読みは矛盾を見落とす。

---

## Step 2: 枠組みドラフト

いきなり質問を浴びせない。まず自分で枠組みドラフトを組み、推測箇所に `[要確認]` を付ける。

| 観点 | 埋める内容 |
|------|-----------|
| **アクター** | 直接の利用者だけでなく、運用者・CS・後続システム・影響を受ける第三者まで |
| **目的** | 解決したい本当の課題と、今やる理由。手段ではなく課題で書く |
| **文脈** | 状況・背景・スコープ内外・前提条件・既存の制約 |
| **ルール** | 法令・業務ルール・非機能要件・ドメインの不変条件 |
| **ユビキタス言語** | 登場する重要語とこのプロジェクトでの意味。`git grep` でコード上の対応も記載 |
| **成功条件** | 何をもって解けたとするか。観測可能な基準で書く |

---

## Step 3: 問いかけループ

### ループ構造

**最低2ラウンド**実施する。
**収束条件**: 連続2ラウンドで「解消必須の未解決」が新たに出なかった時点でループを終了する。ただし Step 2 ドラフトで `[要確認]` を付けた項目はすべて解消、または「後送り可」として明示されていること。
「後送り可」にできるのは、その答えが枠組み・採用案・リスクの格付けのどれも変えない項目だけである。結論の土台になっている事実は後送りにできない。検証してから先へ進む。
1ラウンドで答えが返っても打ち切らない。答えが新たな矛盾・前提のズレを生んでいないかを再検査し、次のラウンドへ進む。

### 第1ラウンドで必ず確認するゼロベース検証

仕様書に書いてあっても、証拠があるかを確認する。

1. **このEpicをやらなかった場合の具体的な損失は何か**（売上減少・解約増加・機会損失・法的リスクなど）
2. **課題の根本原因を把握しているか**（データ・ヒアリング済みか、それとも仮説か）
3. **最もシンプルな代替案を検討したか**（現状維持・部分改善・価格変更・外部ツール利用など「作らない」選択肢を含む）
4. **今このタイミングで解く必要があるか**（緊急度の根拠）

### 致命的な危険信号（検出したら即座に問いかける）

- **同じ語が人によって別物を指している**: `git grep` でコード上の用法と突き合わせる
- **目的が手段にすり替わっている**: 「○○を作る」が目的化している。「それで何が嬉しいのか」を2〜3段繰り返して真の目的に到達する
- **声が拾われていないアクター**: CS・データ移行・後続バッチ・連携先システムなど影響を受けているのに検討されていない者
- **スコープ境界が未定義**: やらないことが明示できていない
- **成功条件が未定義または計測不能**: 観測可能な基準がなく「なんとなく良くなった」で完了するリスク。ユーザーが具体的な数値を示していない場合は推奨案を添えて確認を求める — こちらが数値を発明しない
- **制約どうしが両立しない**: 個々の制約は妥当でも集合として矛盾していないか
- **解くべき問題か未検証**: 課題が実在するエビデンスがなく、解決策に恋している状態
- **矛盾した情報源の上の断定**: 「要確認」が付いた値や、情報源どうしが食い違う値を土台に枠組み・リスクを組み立てている。正本を確かめてから使う

### 問いかけの所作

1. 必ず推奨案（こちらの解釈）を添える。「どう思いますか？」ではなく「自分はこう解釈しました。合っていますか？」と問う
2. 依存順に解く。前提が後で崩れる順序で聞かない
3. コードや既存ドキュメントで答えが出る問いは、自分で調べて聞かない
4. 対話できない場合は `[要確認]` を付けて先へ進む。問いを投げられないことは枠組み化を止める理由にならない
5. 「わからない」「後で」という回答は分解の合図として扱う。答えられる粒度まで問いを割って聞き直し、分解しても答えられない項目だけを検証方法と責任者を添えて後送りにする
6. 新しい事実が確定済みの回答を揺るがすときは、確定を守るために質問の射程を狭めず、再確認する

---

## 枠組みの完了ゲート

Step 3 のループ収束後、以下を**出力として**チェックする。1つでも ☐ なら Step 3 に戻る。
☑ には根拠を 1 行添える。根拠は、どのラウンドの回答か、どの調査結果かを指す。根拠を書けない項目は ☐ のままにする。意思決定完了ゲートも同じ規則に従う。

```
枠組み完了ゲート:
☑ / ☐  目的が手段でなく課題として書かれている
☑ / ☐  アクターに声なき者（CS・後続システム等）が含まれている
☑ / ☐  スコープ内外が明示されている
☑ / ☐  制約集合の内部矛盾がない
☑ / ☐  ユビキタス言語が定義されている
☑ / ☐  成功条件が観測可能な基準で書かれている
☑ / ☐  解消必須の未解決がゼロである
→ [通過 / 未通過 → Step 3 に戻る]
```

---

## Step 4: 解決策の意思決定

枠組みが完了ゲートを通過したら、そのまま本スキルの中でどの解決策にするかを詰めきる。別ツールへ渡さない。

### 候補の必須構成

以下の4類型を必ず検討する。各案に「前提・トレードオフ・想定する却下理由」を添える。

| 類型 | 意図 |
|------|------|
| 現状維持・何もしない | ベースラインのコストを明示する |
| 最小変更案 | シンプルさの探索 |
| 提案案 | 本命 |
| 大胆な代替案 | 枠組みを疑う視点を入れる |

枠組みと矛盾する案はその場で落とす。却下理由を言語化しないと完了ゲートを通過できない。

### 意思決定の完了ゲート

```
意思決定完了ゲート:
☑ / ☐  採用案が目的・制約・成功条件をすべて満たしている
☑ / ☐  却下した案の理由が言語化されている
☑ / ☐  残った未決事項は後続工程で詰めてよいものだけである
→ [通過 / 未通過 → Step 4 に戻る]
```

---

## Step 5: ドキュメント出力

両方の完了ゲートを通過したら、以下の構造で Markdown ドキュメントを作成し `Write` で保存する。
ユーザーが保存先を示している場合はそのまま保存する。示していない場合のみ保存先を確認する。
対話できない場合は、会話の文脈から推測できるドキュメントディレクトリ（例: `docs/` 配下）に `問題の枠組みと解決策_<機能名>.md` として保存し、冒頭に `[保存先: 要確認]` を付ける。

```markdown
# 問題の枠組みと解決策: <課題・機能の名前>

## なぜやるのか
- 解決したい本当の課題:
- 今やるべき理由・背景:
- 課題の実在根拠（データ・声・観測、または「仮説」と明記）:

## アクター
| アクター | 関わり方 | 関心事 |
|---------|---------|-------|

## 文脈
- スコープ内:
- スコープ外:
- 前提条件・既存の制約:

## ルール・制約

## ユビキタス言語
| 用語 | このプロジェクトでの意味 | 紛らわしい同義語 | コード上の対応 |
|------|------------------------|----------------|--------------|

## 成功条件

## 採用する解決策
- 採用案と、目的・制約・成功条件をどう満たすか:
- 却下した案と却下理由:
- 後続工程に委ねる判断:

## 未解決の前提
- **解消必須の未解決**: （なし、または残項目）
- **後送り可の未解決**: 後続の設計・実装で詰めてよい事実
```

両方のゲートを通過した場合のみ出力する：

> 問題の枠組みと採用する解決策が固まりました。次は設計文書に起こす、または実装に進む段階です。