ousiass/rfp

rfp

Web制作・システム開発・その他あらゆる案件のRFPを対話で作成する。技術要件を重視した構成。

前提条件

• Claude Code 環境

引数

• テキスト (例: /rfp ECサイトリニューアル): 初期情報として扱い、不足分をヒアリング
• 引数なし: 最初からヒアリングを開始

フェーズ1: プロジェクト概要のヒアリング

引数でわかっている情報はスキップ。

1-1: 案件種別（選択式）

AskUserQuestion で確認：

1. 案件種別: Webサイト制作 / Webサイトリニューアル / システム開発 / アプリ開発（「その他」は自動付与）

1-2: 基本情報（テキスト入力）

案件種別の回答後、以下をテキストで質問（ユーザーにまとめて回答してもらう）：

• プロジェクト名: 仮称でもよい
• 背景・目的: なぜこのプロジェクトを行うか
• ターゲットユーザー: 誰が使うか

1-3: 現状と課題

回答内容に応じて追加質問（最大4問）：

| 状況 | 追加で聞くこと | |------|-------------| | リニューアル案件 | 現行サイト/システムのURL・課題・残したい部分 | | 新規案件 | 競合・参考サイト・差別化ポイント | | システム連携あり | 既存システムの構成・連携要件 | | 複数ステークホルダー | 意思決定者・承認フロー |

フェーズ2: 要件のヒアリング

2-1: 機能要件

AskUserQuestion で確認：

1. 必須機能: 最低限実現したい機能（複数選択可、案件種別に応じた選択肢を提示）
2. あれば嬉しい機能: 予算次第で追加したい機能
3. コンテンツ: 主要なコンテンツやページ構成

2-2: 技術要件（詳細にヒアリング）

AskUserQuestion で確認：

1. 技術スタック指定: 指定あり（具体名）/ おまかせ / 一部指定あり
2. ホスティング・インフラ: クラウド指定 / オンプレ / おまかせ / 既存環境あり
3. セキュリティ要件: 個人情報取扱い / 決済機能 / 社内限定 / 特になし
4. 非機能要件の重視度: パフォーマンス / 可用性 / スケーラビリティ / 保守性

回答に応じて深掘り（最大4問）：

| 状況 | 追加で聞くこと | |------|-------------| | 技術スタック指定あり | バージョン指定、選定理由、制約 | | クラウド指定 | プロバイダー、既存アカウント、予算制約 | | 個人情報・決済あり | 認証方式、暗号化要件、コンプライアンス基準 | | 高可用性が必要 | SLA目標、許容ダウンタイム、DR要件 | | 既存システム連携 | API仕様、データ形式、認証方式、移行要件 | | モバイル対応 | レスポンシブ / ネイティブアプリ / PWA |

2-3: デザイン要件

AskUserQuestion で確認：

1. デザインの方向性: 既存ブランドガイドラインあり / 参考サイトあり / おまかせ / デザインカンプ提供予定
2. 対応デバイス: PC + スマホ / PC のみ / スマホ優先 / タブレット含む
3. アクセシビリティ: WCAG準拠必要 / 基本的な配慮 / 特になし

フェーズ3: 制約条件のヒアリング

AskUserQuestion で確認：

1. 希望スケジュール: 公開・リリース希望時期
2. 予算規模: 具体的な金額 / レンジ（〜100万 / 100-500万 / 500-1000万 / 1000万〜）/ 未定・提案に含めてほしい
3. プロジェクト体制: 発注側の体制（専任担当者の有無、レビュー体制）
4. 運用・保守: 納品後の運用保守要否、期間、範囲

フェーズ4: 提案条件のヒアリング

AskUserQuestion で確認：

1. 提案に含めてほしい項目: 見積書 / 体制図 / 実績 / 開発手法 / 保守プラン
2. 評価基準の優先度: 技術力 / 価格 / 実績 / 提案内容 / 体制（優先順位をつける）
3. 提出期限: いつまでに提案がほしいか
4. 選定スケジュール: 選定プロセス（書類選考 → プレゼン → 最終決定など）

フェーズ5: プレビューと出力

1. templates/ 配下のテンプレートを参照し、収集情報からRFPドラフトを作成
   • 01-overview.md: プロジェクト概要・背景・スコープ
   • 02-functional.md: 機能要件
   • 03-technical.md: 技術要件（詳細）
   • 04-design.md: デザイン要件
   • 05-management.md: 体制・スケジュール・予算
   • 06-proposal.md: 提案条件・評価基準・提出方法
2. ユーザーにプレビュー表示
3. AskUserQuestion で確認：
   • このまま出力: 問題なし
   • 修正あり: 修正箇所をフィードバック → 修正 → 再確認
4. カレントディレクトリに rfp-<プロジェクト名(kebab-case)>.md を生成（docs/ があればその中に配置）
5. パスをユーザーに報告

提案依頼物（提案者に提出を求めるもの）

RFPには以下の提出物を明記する。ヒアリング内容に応じて取捨選択：

| 提出物 | 必須/任意 | 用途 | |--------|----------|------| | 提案書 | 必須 | プロジェクトへのアプローチ・理解度の確認 | | 見積書 | 必須 | 費用の比較・予算との照合 | | プロジェクト計画書 | 必須 | スケジュール・マイルストーンの妥当性確認 | | 体制図 | 必須 | 担当者のスキル・経験の確認 | | 類似実績 | 必須 | 類似案件の経験・品質の確認 | | 会社概要 | 必須 | 企業の安定性・信頼性の確認 | | 技術提案書 | 任意 | アーキテクチャ・技術選定の詳細（技術重視案件で必須化） | | デザイン案・モックアップ | 任意 | デザインの方向性の確認 | | 運用保守提案・見積 | 任意 | 納品後の保守体制・費用 | | セキュリティ対策書 | 任意 | セキュリティ要件への対応方針（個人情報・決済ありで必須化） | | テスト計画書 | 任意 | 品質保証のアプローチ | | データ移行計画書 | 任意 | リニューアル案件でデータ移行がある場合に必須化 |

ルール

• 質問には必ず AskUserQuestion を使い選択式で提示する。テキストだけで質問しない
• 1回あたり4問以内にまとめる
• 各選択肢の description に補足情報を記載する
• 未定・不明な項目は「提案に含めてほしい」として記載し、空欄にしない
• 技術要件は他セクションより詳細に記述する
• 業界用語はそのまま使うが、必要に応じて補足説明を加える
• RFP出力前に必ずプレビューしてユーザー承認を得る
• コード作成・実装は行わない。成果物はRFPドキュメントのみ