# Rfp

> 対話形式でヒアリングし、構造化されたRFP（提案依頼書）をMarkdownで作成する。

- Skill: `ousiass/rfp` (Agent Skill, multi-file: 7 files)
- Install (CLI): `npx skillmds@latest add ousiass/rfp`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ousiass/rfp/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: ousiass (https://skillmd.com/u/ousiass)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/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ドキュメントのみ