ousiass rfp
Web制作・システム開発・その他あらゆる案件のRFPを対話で作成する。技術要件を重視した構成。
前提条件
- Claude Code 環境
引数
- テキスト (例:
/rfp ECサイトリニューアル): 初期情報として扱い、不足分をヒアリング - 引数なし: 最初からヒアリングを開始
フェーズ1: プロジェクト概要のヒアリング
引数でわかっている情報はスキップ。
1-1: 案件種別（選択式）
AskUserQuestion で確認：
- 案件種別: Webサイト制作 / Webサイトリニューアル / システム開発 / アプリ開発（「その他」は自動付与）
1-2: 基本情報（テキスト入力）
案件種別の回答後、以下をテキストで質問（ユーザーにまとめて回答してもらう）：
- プロジェクト名: 仮称でもよい
- 背景・目的: なぜこのプロジェクトを行うか
- ターゲットユーザー: 誰が使うか
1-3: 現状と課題
回答内容に応じて追加質問（最大4問）：
| 状況 | 追加で聞くこと |
|---|---|
| リニューアル案件 | 現行サイト/システムのURL・課題・残したい部分 |
| 新規案件 | 競合・参考サイト・差別化ポイント |
| システム連携あり | 既存システムの構成・連携要件 |
| 複数ステークホルダー | 意思決定者・承認フロー |
フェーズ2: 要件のヒアリング
2-1: 機能要件
AskUserQuestion で確認：
- 必須機能: 最低限実現したい機能（複数選択可、案件種別に応じた選択肢を提示）
- あれば嬉しい機能: 予算次第で追加したい機能
- コンテンツ: 主要なコンテンツやページ構成
2-2: 技術要件（詳細にヒアリング）
AskUserQuestion で確認：
- 技術スタック指定: 指定あり（具体名）/ おまかせ / 一部指定あり
- ホスティング・インフラ: クラウド指定 / オンプレ / おまかせ / 既存環境あり
- セキュリティ要件: 個人情報取扱い / 決済機能 / 社内限定 / 特になし
- 非機能要件の重視度: パフォーマンス / 可用性 / スケーラビリティ / 保守性
回答に応じて深掘り（最大4問）：
| 状況 | 追加で聞くこと |
|---|---|
| 技術スタック指定あり | バージョン指定、選定理由、制約 |
| クラウド指定 | プロバイダー、既存アカウント、予算制約 |
| 個人情報・決済あり | 認証方式、暗号化要件、コンプライアンス基準 |
| 高可用性が必要 | SLA目標、許容ダウンタイム、DR要件 |
| 既存システム連携 | API仕様、データ形式、認証方式、移行要件 |
| モバイル対応 | レスポンシブ / ネイティブアプリ / PWA |
2-3: デザイン要件
AskUserQuestion で確認：
- デザインの方向性: 既存ブランドガイドラインあり / 参考サイトあり / おまかせ / デザインカンプ提供予定
- 対応デバイス: PC + スマホ / PC のみ / スマホ優先 / タブレット含む
- アクセシビリティ: WCAG準拠必要 / 基本的な配慮 / 特になし
フェーズ3: 制約条件のヒアリング
AskUserQuestion で確認：
- 希望スケジュール: 公開・リリース希望時期
- 予算規模: 具体的な金額 / レンジ（〜100万 / 100-500万 / 500-1000万 / 1000万〜）/ 未定・提案に含めてほしい
- プロジェクト体制: 発注側の体制（専任担当者の有無、レビュー体制）
- 運用・保守: 納品後の運用保守要否、期間、範囲
フェーズ4: 提案条件のヒアリング
AskUserQuestion で確認：
- 提案に含めてほしい項目: 見積書 / 体制図 / 実績 / 開発手法 / 保守プラン
- 評価基準の優先度: 技術力 / 価格 / 実績 / 提案内容 / 体制（優先順位をつける）
- 提出期限: いつまでに提案がほしいか
- 選定スケジュール: 選定プロセス（書類選考 → プレゼン → 最終決定など）
フェーズ5: プレビューと出力
templates/配下のテンプレートを参照し、収集情報からRFPドラフトを作成01-overview.md: プロジェクト概要・背景・スコープ02-functional.md: 機能要件03-technical.md: 技術要件（詳細）04-design.md: デザイン要件05-management.md: 体制・スケジュール・予算06-proposal.md: 提案条件・評価基準・提出方法
- ユーザーにプレビュー表示
AskUserQuestionで確認：- このまま出力: 問題なし
- 修正あり: 修正箇所をフィードバック → 修正 → 再確認
- カレントディレクトリに
rfp-<プロジェクト名(kebab-case)>.mdを生成（docs/があればその中に配置） - パスをユーザーに報告
提案依頼物（提案者に提出を求めるもの）
RFPには以下の提出物を明記する。ヒアリング内容に応じて取捨選択：
| 提出物 | 必須/任意 | 用途 |
|---|---|---|
| 提案書 | 必須 | プロジェクトへのアプローチ・理解度の確認 |
| 見積書 | 必須 | 費用の比較・予算との照合 |
| プロジェクト計画書 | 必須 | スケジュール・マイルストーンの妥当性確認 |
| 体制図 | 必須 | 担当者のスキル・経験の確認 |
| 類似実績 | 必須 | 類似案件の経験・品質の確認 |
| 会社概要 | 必須 | 企業の安定性・信頼性の確認 |
| 技術提案書 | 任意 | アーキテクチャ・技術選定の詳細（技術重視案件で必須化） |
| デザイン案・モックアップ | 任意 | デザインの方向性の確認 |
| 運用保守提案・見積 | 任意 | 納品後の保守体制・費用 |
| セキュリティ対策書 | 任意 | セキュリティ要件への対応方針（個人情報・決済ありで必須化） |
| テスト計画書 | 任意 | 品質保証のアプローチ |
| データ移行計画書 | 任意 | リニューアル案件でデータ移行がある場合に必須化 |
ルール
- 質問には必ず
AskUserQuestionを使い選択式で提示する。テキストだけで質問しない - 1回あたり4問以内にまとめる
- 各選択肢の
descriptionに補足情報を記載する - 未定・不明な項目は「提案に含めてほしい」として記載し、空欄にしない
- 技術要件は他セクションより詳細に記述する
- 業界用語はそのまま使うが、必要に応じて補足説明を加える
- RFP出力前に必ずプレビューしてユーザー承認を得る
- コード作成・実装は行わない。成果物はRFPドキュメントのみ