mcpField
F
framing-doc

framing-doc

github.com/rjs生産性1.4k109 回インストール5 週間前に更新
リポジトリ

framing-doc について

framing-docは、1件以上の会話の文字起こしから問題設定ドキュメントを作るスキルです。発言の引用と分析を分け、挙がった選択肢を整理し、解決策を設計せずに問題と望ましい結果を定めます。

主な機能

  1. 01話者付きの発言引用を記録
  2. 02選択肢と支持の強さを評価
  3. 03問題と望ましい結果を定義
  4. 04必要に応じて解決策の境界を設定
  5. 05主張を文字起こしの根拠に紐付け

活用シーン

  1. 01会話をもとにプロダクトの問題を設定
  2. 02複数の会話で出た案を比較
  3. 03今取り組む問題の優先理由を記録
  4. 04よくある誤解を避ける境界を設定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rjs/shaping-skills --skill framing-doc

インストール後、Claude Code で/framing-docを入力して読み込まれたか確認します。

詳細

会話トランスクリプトからのフレーミング

1つ以上の会話トランスクリプトからフレーム文書を作成します。フレームで捉えるのは「なぜ」です。つまり、解決すべき問題は何か、そしてなぜ他の問題ではなくこの問題なのかを明らかにします。

始める前に

ユーザーに次のことを尋ねます。

  1. どのトランスクリプトですか？ 具体的なファイルパスを確認します。ユーザーが指定した順に読みます。会話の順序は、アイデアが複数の通話にわたって発展することが多いため、重要になる場合があります。
  2. トピックの分野は何ですか？ これらの会話が何についてのものだったか、おおまかな見当をつけます（例：「AI 機能」「オンボーディングの再設計」）。何に注目すべきかを把握するためです。

フレーム文書に含まれる内容

フレームは3つのセクションで構成されます。

1. ソース — 実際に話されたこと

トランスクリプトから逐語的な引用を抜き出します。これが事実の根拠です。文書内のそれ以外の内容はすべて、この素材の解釈です。

  • 引用の話者を明記します
  • 引用だけで意味が通じるよう、十分な文脈を含めます
  • 必要に応じて引用の間に短いつなぎを加えますが、独自の説明は最小限にします
2. 事前検討 — 浮かび上がった選択肢と、この案を選ぶ理由

会話全体で出てきた選択肢を概観します。これは背景情報ではありません。なぜこの問題をフレーミングするのかを示す議論です。

浮かび上がった選択肢ごとに、次の点を示します。

  • どのような選択肢か
  • 誰にメリットがあるか
  • どれほど強い支持があるか（何人が独立して提案したか。他の人はその案を引き継いだか、それとも話題にしなくなったか）

次に、今取り組む案を選ぶ理由を示します。

  • なぜ他の案より緊急性や重要性が高いのか
  • 今はなぜ他の案を選ばないのか（これは「今はなぜ選ばないのか」であり、「今後も選ばない理由」ではありません。アイデアを退けるのではなく、優先事項ではない理由を説明します。）

他の案について、ロードマップや実施順序を作ってはいけません。 それらを実施するか、いつ実施するかは、将来の判断事項です。主張するのは、この案をまず選ぶ理由だけです。

3. 問題／成果 — 具体的なフレーム

問題： 何がうまくいっていないのか、どのような痛みがあるのかを示します。読みやすいよう箇条書きにします。

成果： 成功とはどのような状態かを示します。こちらも箇条書きにします。高いレベルにとどめ、特定の解決策に限定しないでください。

4. 対象外／重点 — 解決策の範囲を明確にする（任意）

どのような解決策が適切で、どのような解決策が適切でないかを読者に示すガードレールです。問題／成果の後に、独立したセクションとして配置します。形式は同じで、対称的な2つの箇条書きリストにします。

役割： 問題と成果を正しく読み取った人が、方向性の異なる解決策を提案してしまうのを防ぎます。たとえば、プログラムをシステムに取り込むことに関する問題に対して、「コーチにプログラム内容を提案する AI」を提案するのは、問題に形式上は対応していても、主旨を完全に見失っています。

含める場合： よくある誤解がある場合や、明らかにもっともらしいものの誤った方向に進みやすい場合に含めます。会話の中で、参加者が「これは X についての話ではない」と境界線を引いていることが判断の目安です。誰もその境界線を引く必要を感じていなければ、このセクションは不要でしょう。

浮かび上がるタイミング： トランスクリプトを最初に読み込むだけでは、機械的に見つからないことが多いでしょう。レビュー時に表面化する可能性のほうが高く、フレームを作る人が「X についてではない」という発言の傾向に気づく場合もあれば、フレームを読んだ人が、問題／成果には沿っているものの主旨を見失った提案をする場合もあります。その時点で、境界線を明確にする必要があると気づきます。

形式：

## Less about

- [What this project is NOT trying to solve]
- [The wrong direction people might naturally head toward]

## More about

- [What kind of solution actually fits]
- [The real nature of the problem being addressed]

引用や話者の明記は不要です。内容を統合したものです。要点に絞ってください。

最も重要な原則：論評ではなく、根拠を示す

問題と成果の各行を書いた後に、次のことを確認します。誰が、どこで、これを言いましたか？

  • 具体的な人と発言の場面を特定できる → 残し、出典を示します
  • 誰かの発言から直接読み取れる → 残し、その理由を添えて、含意であることを示します
  • 出典をたどれない → 削除します
避けるべきよくある落とし穴

点と点をつなぎ、推測を事実として提示しないでください。「データ入力が難しいため、トライアル中にコーチが離脱する」という説明はもっともらしく聞こえますが、誰もそう言っていないなら、確立した事実として書かないでください。

生き生きと伝えるために脚色しないでください。 問題をより具体的に聞こえさせるために、誰も述べていない詳細（「あらゆるエクササイズ、セット、レップ、パーセンテージ」など）を付け加えるのは、編集者の主観を持ち込むことになります。

選択肢のリストを水増ししないでください。 ある人が挙げただけで、誰も取り上げなかったアイデアは、「支持を得た選択肢」ではありません。反応の強さを正直に見極めてください。複数の人がそれぞれ独立して提起しましたか？ ほかの人が発展させましたか、それとも話題が立ち消えになりましたか？

Problem の記述に編集者の主観を持ち込まないでください。 「TB は乗り換える価値を示す必要がある」や「最大の障壁」といった表現は、根拠ではなく修辞です。実際に語られた内容をもとに主張を組み立ててください。

自分の解釈を、相手の発言として提示しないでください。 解釈としての語りと、実際に語られた内容は分けてください。Source セクションに書くのは相手の言葉です。Problem／Outcome はあなたが要点を抽出したものであり、Source にさかのぼって根拠を確認できる内容にしてください。

フレームの見直し

下書きができたら、Problem と Outcome の各行を確認してください。

  1. 各箇条書きを読む
  2. この主張の根拠は何かを考える
  3. 根拠が直接の引用なら、括弧内に出典を示す
  4. 根拠が暗示されているなら、そのことを明示する
  5. 根拠がないなら、その行を削除する

事前作業の選択肢テーブルも同様に確認してください。記載した各選択肢について、次の点を確かめます。

  • 会話の中で実際に支持を得ていましたか？（複数の人がそれぞれ独立して支持しましたか？）
  • それとも、ある人が挙げただけで、ほかの人は取り上げませんでしたか？

選択肢のリストは、ためらわずに縮小してください。水増ししたリストより、実際に存在する選択肢が少数あるほうがよいです。

ドキュメント形式

---
shaping: true
---

# [Topic] — Frame

## Source

### [Speaker] ([Date])

> "Verbatim quote..."

> "Another quote..."

[Brief connective context where needed.]

### [Speaker] ([Date])

> "Verbatim quote..."

---

## Pre-work: [Topic] Options Landscape

[N] options surfaced with real traction across conversations:

| Option | What it does | Who benefits | Signal strength |
|--------|-------------|--------------|-----------------|
| **A. [Name]** | ... | ... | ... |
| **B. [Name]** | ... | ... | ... |

([Note on ideas that were mentioned but didn't get traction — dropped.])

**Why A now:** [Evidence-based argument for urgency/importance.]

---

## Problem

- [Bullet — traceable to source]
- [Bullet — traceable to source]

## Outcome

- [Bullet — high-level, not solution-specific]
- [Bullet — high-level, not solution-specific]

---

## Less about

- [What this is not]

## More about

- [What this is]

このスキルで行わないこと

  • 解決策の形を定めません。 フレームが示すのは「なぜ」です。形（「どのように」）はその後、別のシェーピングドキュメントで扱います。
  • 今後の作業の順序を決めません。 現時点で優先するものを1つ選びます。それ以外をロードマップにすることはありません。
  • 会話を要約しません。 Source セクションには重要な引用を記載します。ドキュメントの残りの部分は要約ではなく、要点を抽出したものです。

コメント

Markdown 対応