product-shaping

プロダクトのシェイピング

プロダクト開発とエンジニアリング作業に向けた、着手前のコミットメント手法です。Ryan Singer の Shape Up（basecamp.com/shapeup で無料版を公開）をベースに、 開発者に AI エージェントを含むチーム向けに拡張しています。

一連の流れ：生のアイデアを範囲の限られた提案へシェイピングする → 固定のアペタイトを設定してベットする → スコープを発見し、枠内に収まるようスコープを削りながら構築する → 次へ進む。 リリース後のフィードバックは、生のアイデアとして再び取り込みます。

中心となる手順

1. 境界を定める — アペタイト（「これにどれだけの価値があるか？」）を決め、問題を具体的なストーリー1つに絞ります。 「X の再設計」「X 2.0」のような寄せ集めのアイデアは却下します。
2. 要素を見つける — 解決策を大まかに、解決済みとして、範囲を限定してスケッチします。フローにはブレッドボード、 ビジュアルの問題には太いマーカーで描いた程度の精度、UI 以外の作業にはコンポーネントとコントラクトを使います。
3. 難所に対処する — 自分のスケッチに疑問を投げかけ、難しい決定を今のうちに確定し、対象外のケースを明示し、 アペタイトで賄えないものを削ります。
4. 提案を書く — 問題、アペタイト、解決策、難所、対象外事項を記載します。
5. ベットする — 中断されない期間を枠として確保し、下振れを限定します。デフォルトでは完了扱いにせず、期間も延長しません。 サーキットブレーカーが失敗をシェイピングへ差し戻します。
6. 構築する — まず統合された一片を完成させ、その後、発見したスコープを上り坂→下り坂の状態として追跡します。 最もリスクの高いものから順に取り組み、終了を判断する際はベースラインと比較します。
7. 次へ進む — スコープの削減は品質の削減ではありません。新たなフィードバックには、即座に受け入れるのではなく、 シェイピングが必要です。

参考ファイル

現在のステップで必要なものだけを読み込みます。

参考資料	読み込むタイミング
references/principles.md	理由を知りたいとき：アペタイトと見積もり、期間固定・スコープ可変、大まかさ／解決済み／範囲限定、エビデンスの境界、系譜
references/shaping.md	ステップ1～4のシェイピングの詳細。UI 以外の作業、バックエンド、インフラのシェイピングも含みます
references/betting.md	ベットとバックログ、サーキットブレーカーの仕組み、任意の足場としてのサイクル、ベットの合間の不具合への対応
references/building.md	責任の引き継ぎ、ひとまとまりの完成、スコープのマッピング、坂道状態の追跡、終了の判断
references/hybrid-adaptation.md	AI エージェントが開発者となるベット全般：予算の単位、まとめて行う方向づけ、スコープに含める検証コスト、収束しないループの終了基準
references/anti-patterns.md	重要なものにベットする前に確認します。現場で記録された失敗とその対策が記載されています

テンプレート

テンプレート	用途
templates/PITCH.md	5つの要素を記入できる提案書
templates/SCOPE_MAP.md	坂道状態、チャウダーリスト、ブレーカーチェックを含む、記入式のスコープ表

入口

状況	ここから始める
生のアイデアや依頼が届いた	references/shaping.md のステップ1
アイデアは検証済みだが、範囲が定まっていない	references/shaping.md
コンセプトを文書にまとめる準備ができた	templates/PITCH.md
次の枠に何を入れるか決めている	references/betting.md
ベットが成立し、構築を始める	references/building.md
開発者が AI エージェントである	references/hybrid-adaptation.md
プロジェクトがいつまでも終わらない／ループが収束しない	references/anti-patterns.md、続けて hybrid-adaptation の終了基準

使用しない場合

• 問題自体がまだ検証されていない場合 → product-discovery。シェーピングは、検証済みの問題を絞り込みます。問題が実在するかどうかを調査するものではありません。
• 戦略的な問いの場合（ポジショニング、市場参入、四半期をまたぐポートフォリオの配分）→ product-strategy または product-roadmapping-and-portfolio。このスキルは、アペタイトとサーキットブレーカーを備えた、範囲が定められた単一のコミットメントである一つの賭けをまとめます。ロードマップ作成では、継続／一時停止／中止の基準を設けて、複数の賭けをサイクルに沿って順序付けます。
• すでに賭けが置かれ、作業に正式な仕様が必要な場合 → 正式な仕様が必要なときは、spec-driven-development がシェーピング済みの出力を利用します。
• 無関係な機能提案をスコアで比較する場合 → product-methodology（RICE／MoSCoW）。このスキルの対象範囲では、スコアリングの代わりにアペタイトを使います。同じ意思決定で両方を使わず、どちらか一方の仕組みを使ってください。
• 完了の定義が誰にもできず、エピックを分解できない場合 → ここに戻してください。これはシェーピングされていないプロジェクトであり、無理に分割すると、互いにつながりのないタスクが生まれます。
• 作業が小規模で、定型的で、十分に理解されている場合 — シェーピングの負担を省き、そのまま実行してください。
• 賭けが置かれ、意図からデリバリーまでの制御が必要な場合 — 分類、5項目の意図コントラクト、自律性のゲーティング、失敗時のルーティング、実行をまたいで再開可能なステータス管理が必要です。bmad にルーティングしてください。シェーピングは賭けを置くところで終わります。bmad は、置かれた意図を、範囲が限定され、検査可能で、再開可能なエージェント作業を通じて実現します。

関連スキル

• product-discovery — 上流：絞り込みを始める前に問題を検証します
• product-strategy、product-roadmapping-and-portfolio — 賭けより上位の戦略的コンテキスト
• product-methodology — 成功した賭けの下流の利用者（優先順位付け、仕様のドラフト作成）
• spec-driven-development — 賭けの後、シェーピング済みの出力を任意で正式な仕様にします
• implementation-planning、subagent-driven-development — 賭けの後の実行。分解するのは下流の作業だけとし、提案を事前に細分化しないでください
• bmad — 賭けが置かれた後の、意図からデリバリーまでを制御するコントロールプレーンプロトコル：分類、5項目の意図コントラクト、自律性のゲーティング、失敗時のルーティング、再開可能な仕様ステータス
• work-tracking — 構築中にスコープ／ヒルの状態を記録する場所
• qa-methodology — ゲートではなく、サイクル後半のレベルアップとして行うエッジケースのQA

エビデンスに関する注記

すべての実践上の主張は、ある1社（Basecamp、2019年）の説明に由来します。2026年までの独立したチーム記録には、実際の適応例と文書化された中止例が示されています。重要なことに賭ける前に references/anti-patterns.md を読み、6週間のサイクルは教義ではなく、調整可能な足場として扱ってください。