spec-writer

プロダクト要件定義書を作成する

このスキルでは、会話とリポジトリのコンテキストを活用し、明確化されたアイデアを構造化された PRDにまとめます。主な曖昧さはすでに十分に解消されている（たとえば /grill-me を使って）ことを前提としていますが、必要に応じて簡単な確認を独自に行うこともできます。

使用する場面

次のような場合に、このスキルを使います。

• 「PRDを書いて」「プロダクト仕様書」「要件定義書」「機能仕様書」などを依頼された場合。
• 実装前に、新機能、変更、システムを構造化された形で文書化したい場合。
• アイデアの明確化が済んでおり、課題として登録したり、関係者と共有したり、/slice-the-spec に渡したりできる、まとまりのある単一の文書が必要な場合。

アイデアがまだ曖昧、または要件が不十分な場合は、まず /grill-me を使ってからこのスキルに戻るよう提案してください。

全体のワークフロー

明らかに完了している手順は省略または簡略化できます（たとえば、ユーザーが詳細な問題の説明やユーザーストーリーの一覧を貼り付けた場合）。

1. 問題を詳しく把握する

   • 次の点について、ユーザーに詳しく説明してもらいます。
     • 解決したい問題
     • 対象ユーザー
     • 今それが重要な理由
     • すでにある解決策の案や制約
   • すべてを再入力する代わりに、既存のコンテキスト（ドキュメント、チケット、調査結果など）を貼り付けるよう促します。

2. リポジトリを調査し、前提を検証する

   • コードベースを調べて、現在の動作、関連モジュール、データモデル、既存の API を理解します。
   • ユーザーの主張を照合し、リポジトリの情報と一致する点、異なる点、情報がない点を記録し、それに応じて理解を調整します。
   • 範囲、エッジケース、実装上の制約に関わる、リポジトリに基づいた事実を記録します。

3. 代替案を検討する

   • 他の解決策や設計の方向性を検討したか、ユーザーに確認します。
   • あり得るアプローチを 2～3 個簡潔に示し、それぞれのトレードオフ（複雑さ、リリースまでの時間、リスク、UX への影響）を説明します。
   • この PRD で主軸として扱うアプローチを確認します。

4. 実装に関する詳細なヒアリング（必要な場合）

   • 要件がまだ大まかな場合は、フロー、状態、入出力、失敗時の動作、権限、パフォーマンスへの期待など、詳細な動作についてユーザーに質問します。
   • 回答が既存の動作に左右される場合は、推測するより先にリポジトリを調査します。
   • 前提を明示し、ユーザーに確認を求めます。

5. 正確なスコープを固める

   • PRD の対象範囲を決め、対象外の項目（先送りするエッジケース、あると望ましい機能、今後の対応など）を明確に列挙します。
   • 対象とするリリースの範囲（MVP か完全な機能か）と、実装順序やフェーズ 1／フェーズ 2 の区別を明確にします。

6. モジュールとアーキテクチャの概要をまとめる（簡易版）

   • 新規作成または変更する主なモジュール、サービス、コンポーネントを特定します。
   • 独立して検証できる、テスト可能で責務の明確なモジュールを抽出できる機会を挙げます（後の TDD や /tdd の利用に役立ちます）。

7. 構造化されたテンプレートで PRD を作成する

   • セクションを明確に分けて、完成版の PRD を作成します（以下のテンプレートを参照）。
   • エンジニア、PM、デザイナーにとって分かりやすく、正確な表現を使います。

8. 適切な場所に登録する（任意）

   • 適切であれば、リポジトリの規約に従って、PRD を GitHub の課題または Markdown ファイルとして整えます。
   • コンテキストに情報があれば、ラベル、担当者、関連する課題やドキュメントへのリンクも含めます。

PRD テンプレート

この構成を使用し、必要に応じて調整してください。明らかに関係のないセクションは省略できますが、含める方向を優先してください。

1. 概要

• 何を、なぜ構築するのかを説明する 2～3 文。
• 対象ユーザー層と、目指す主な成果を含めます。

2. 問題の説明

• プロダクトにおける現在の課題や不足点。
• それを経験している人と、その状況。
• 入手できる場合は、根拠（指標、エピソード、ユーザー調査、サポートチケットなど）。

3. 目標と対象外

• 目標： 成功の状態を示す、短い番号付きリストを記載します。
• 対象外： この PRD で対応しない内容を明確に列挙します。

4. ユーザーストーリー

重要な動作をすべて網羅する、長い番号付きのユーザーストーリーを記載します。

各ユーザーストーリーは、次の形式に従ってください。

1. <actor>として、<feature>を実現したいです。それによって、<benefit>を得られます。
   • 役立つ場合は、受け入れに関する注記や補足をインラインで記載します。

コアフロー、エッジケース、権限の違い、失敗シナリオを含め、広範囲を網羅してください。

5. 機能要件

• 主要な領域やフローごとに、期待される動作を詳しく記述します。
• システムの状態と遷移、各種ユーザーが機能とどのようにやり取りするかを記載します。
• 正確性に関わる検証ルール、エラー処理、再試行、レート制限、制約を記載します。

6. 非機能要件

• 該当する場合は、パフォーマンス、スケーラビリティ、レイテンシの期待値を記載します。
• 信頼性、可用性、縮退時の動作を記載します。
• 該当する場合は、セキュリティ、プライバシー、コンプライアンスに関する考慮事項を記載します。

7. 実装上の注記とアーキテクチャ

• テキスト形式で、アーキテクチャまたはコンポーネント図の概要を記載します。
• 変更または作成するモジュール／サービスと、それらの連携方法を列挙します。
• 主要なクラス、エンドポイント、テーブルなど、現在のコードベースに関する注記を記載します。

8. 対象外

• この PRD で対応しない機能、フロー、ユーザー種別、エッジケースを明確に列挙します。
• 今後の対応や将来のイテレーションが想定されている場合は記載します。

9. リスクと未解決の質問

• 技術、プロダクト、UX、組織に関する既知のリスクを記載します。
• 実装またはロールアウトの前に解決すべき未解決の質問を記載します。
• 特に不確実性の高い前提があれば記載します。

10. 成功指標

• この作業の成功を判断する方法（入力指標と出力指標）を記載します。
• 具体的な数値がまだ決まっていない場合は、方向性を示す期待値（例：「X に関するサポートチケットの有意な削減」）を記載します。

動作とルール

1. 説明が長く続く形よりも構成を重視します。内容を明確なセクションと番号付きリストに分けてください。
2. 可能な限りリポジトリの事実を活用します。確認できる場合は、API やデータモデルを創作しないでください。
3. ユーザーが網羅性より速さを優先する場合は、優先するセクションを確認し、残りは最小限にとどめます。
4. 要件が曖昧すぎる場合は、推測せず、的を絞った確認質問を1～3件してください。
5. マーケティング用の概要資料ではなく、エンジニアが最小限のやり取りで実装できるドキュメントを目指してください。