develop-solution-brief

ソリューション概要

ソリューション概要とは、問題に対して提案する解決策を伝える、簡潔な1ページの文書です。問題の理解から詳細な仕様へとつなぐ役割を果たし、実装の詳細に踏み込みすぎることなく、関係者がアプローチについて合意するために十分な背景情報を提供します。1ページという制約によって、明確さと優先順位付けが求められます。

使用する場面

• 関係者に解決策のアプローチを提案し、賛同を得るとき
• 部門横断チームで、何を、なぜ作るのかについて認識を合わせるとき
• 詳細なPRDを作成する前に、解決策の意図を文書化するとき
• 複数の解決策を大まかに比較するとき
• 経営陣に製品の方向性を伝えるとき

使用しない場面

• 関係者間で合意済みで、エンジニアリングチームが完全な仕様を必要としている場合 -> deliver-prd を使用します。概要は提案を行い、PRDは仕様を定めます
• 問題の枠組みがまだ定まっていない、または合意されていない場合 -> まず define-problem-statement を使用します
• すでに下された決定を記録する場合 -> develop-adr（技術面）または develop-design-rationale（デザイン面）を使用します
• ビジネスモデル全体にわたる戦略的な選択肢を比較する必要がある場合 -> foundation-lean-canvas を使用します

手順

ソリューション概要の作成を依頼された場合は、次の手順に従います。

1. 問題を振り返る 問題を最大2～3文で要約します。問題の説明全体を繰り返すのではなく、必要に応じて参照してください。読者が、この解決策でどのような課題に対処するのかをすぐに理解できるようにします。

2. 提案する解決策を説明する 何を作るのかを、明確で専門用語を使わない表現で説明します。ユーザー体験と中核となる価値提案に焦点を当てます。実装の詳細は避けてください。ここで説明するのは「何を」であり、「どのように」ではありません。

3. 主な機能を列挙する 解決策を構成する必須機能を3～5個特定します。問題解決に必要な最小限の機能に絞ります。あると便利な機能まで含めたくなる気持ちを抑えてください。1ページという制約が、焦点を絞ることを求めます。

4. 成功指標を定める 解決策と測定可能な成果を結び付けます。この解決策がうまくいったかどうかを、どのように判断しますか。問題の説明にある指標を参照し、目標を設定します。

5. トレードオフを明示する 明確に「行わない」ことと、その理由を記録します。優れたソリューション概要では、スコープの制約や、検討したものの採用しなかった代替案について率直に説明します。

6. リスクと軽減策を特定する 成功を妨げる最大のリスクと、その対処計画を明らかにします。これにより関係者の信頼を高め、懸念を早期に表面化できます。

7. 次のステップを概説する 解決策を前進させるための、直近のアクションを3～5個示します。誰が何をするのかを具体的に記載します。

出力形式

references/TEMPLATE.md のテンプレートを使って出力を構成します。完全な概要では、テンプレートのすべてのセクション（問題の振り返り、提案する解決策、主な機能、成功指標、検討したトレードオフ、リスクと軽減策、次のステップ）を記入します。

品質チェックリスト

仕上げる前に、次の項目を確認します。

• 印刷時に1ページに収まる（約500～700語）
• 問題の振り返りが簡潔である（最大2～3文）
• 解決策の説明に専門用語を使っていない
• 機能が必須のもの3～5個に絞られている
• トレードオフが明示されている
• 次のステップが具体的で、実行可能である

例

完成例は references/EXAMPLE.md を参照してください。