【無料テンプレート付き】オークションサイト開設に必要な「要件定義書」の書き方

目次

1. なぜ要件定義書が必要なのか：失敗の9割は「ここ」で決まる
2. 要件定義書の全体構成：7つの章で作る「共通言語」
3. 第1章：プロジェクト概要 — なぜ、誰のために、何をするのか
4. 第2章：事業概要とビジネスモデル — お金の流れを明文化する
5. 第3章：機能要件 — 何ができなければならないのか
6. 第4章：非機能要件 — 品質と性能の基準を決める
7. 第5章：体制とスケジュール — 誰が、いつ、何をするのか
8. 第6章：コストと投資対効果 — いくらかかり、何が得られるのか
9. 第7章：リスクと対策 — 想定される問題とその備え
10. 要件定義書の書き方チェックリスト
11. よくある質問（Q&A）
12. テンプレートの活用方法とまとめ

1. なぜ要件定義書が必要なのか：失敗の9割は「ここ」で決まる

「うちは小さいから、そんなに固く考えなくても…」

そう考えていませんか？ 実は、小規模なプロジェクトほど要件定義書が重要です。なぜなら、大企業には存在する「プロジェクトマネージャー」「システム監査役」といった専門職がいないからです。

要件定義が曖昧だと何が起きるのか

事例1：A社（アパレル通販）のケース

A社は「とりあえずオークションサイトが欲しい」とシステム提供元に依頼。会話は以下のようなものでした。

A社担当者： 「メルカリみたいな感じでお願いします」 提供元： 「かしこまりました」

数ヶ月後、デモを見たA社社長が激怒。

社長： 「これじゃあブランディングできない！ うちのロゴもコンセプトも全然反映されていない！」

原因： 「メルカリみたいな感じ」という曖昧な要件。A社が求めたのは「操作性」ではなく「ブランディング」だったのです。

事例2：B社（中古車販売）のケース

B社は「BtoBオークションサイトが欲しい」と依頼。しかし、要件定義をスキップした結果、以下の問題が発生。

• 法人向けの「請求書払い」機能がなく、取引が成立しない
• 与信管理機能がなく、代金不払いリスクが高い
• 車両の詳細スペック（年式、走行距離、修復歴）を登録できない

結果： システムが使えず、追加開発に500万円、納期は3ヶ月延期。

要件定義書が解決する3つの課題

1. 認識のズレをなくす 「オークションサイト」という言葉一つとっても、人によってイメージが異なります。要件定義書は「共通言語」として機能し、全員の認識を揃えます。

2. 見積もりの精度を高める 「こんなこともできると思ってた」という後出しは、予算オーバーや納期遅延の最大の原因です。要件を明文化することで、正確な見積もりが可能になります。

3. プロジェクトの管理基準になる 「何ができていて、何ができていないのか」を判断する基準がなければ、プロジェクトの進捗は把握できません。要件定義書がその基準を提供します。

要件定義書がないプロジェクトの悲劇

2. 要件定義書の全体構成：7つの章で作る「共通言語」

本記事で提供する要件定義書テンプレートは、以下の7章で構成されています。

オークションサイト開設 要件定義書
│
├── 第1章：プロジェクト概要
│   ├── 1.1 プロジェクトの目的
│   ├── 1.2 プロジェクトの背景
│   ├── 1.3 プロジェクトの目標（定量・定性）
│   └── 1.4 プロジェクトの範囲（何をやり、何をやらないか）
│
├── 第2章：事業概要とビジネスモデル
│   ├── 2.1 取扱商品とターゲット
│   ├── 2.2 ビジネスモデル（収益構造）
│   ├── 2.3 想定される取引フロー
│   └── 2.4 競合分析と差別化ポイント
│
├── 第3章：機能要件
│   ├── 3.1 ユーザー向け機能（フロントエンド）
│   ├── 3.2 管理者向け機能（バックエンド）
│   ├── 3.3 出品者向け機能
│   └── 3.4 外部連携機能（API、決済、配送）
│
├── 第4章：非機能要件
│   ├── 4.1 性能要件（同時アクセス数、レスポンス時間）
│   ├── 4.2 セキュリティ要件
│   ├── 4.3 可用性要件（稼働率、バックアップ）
│   ├── 4.4 拡張性要件（将来の成長を見据えて）
│   └── 4.5 運用・保守要件
│
├── 第5章：体制とスケジュール
│   ├── 5.1 プロジェクト体制図
│   ├── 5.2 役割と責任
│   ├── 5.3 全体スケジュール
│   └── 5.4 マイルストーン
│
├── 第6章：コストと投資対効果
│   ├── 6.1 初期費用の内訳
│   ├── 6.2 月次運用コストの内訳
│   ├── 6.3 想定売上と損益分岐点
│   └── 6.4 ROI（投資対効果）試算
│
└── 第7章：リスクと対策
    ├── 7.1 プロジェクト遂行上のリスク
    ├── 7.2 システムに関するリスク
    ├── 7.3 事業に関するリスク
    └── 7.4 リスク発生時の対応策

この7章をすべて埋めることで、誰が読んでも「何を、なぜ、どのように作るのか」が理解できるようになります。

3. 第1章：プロジェクト概要 — なぜ、誰のために、何をするのか

第1章では、プロジェクトの「Why（なぜ）」を明確にします。ここが曖昧だと、後続のすべての判断がブレます。

1.1 プロジェクトの目的

目的を書く際のポイント：

• 「システムを導入する」ことが目的になっていないか
• ビジネス上の目的（売上向上、コスト削減、顧客囲い込みなど）を明確にする

悪い例： 「オークションシステムを導入する」

良い例： 「現在Yahoo!オークションで支払っている年間約100万円の手数料を削減し、顧客データを自社で蓄積することで、リピート率を現在の不明から30%以上に向上させる」

記入欄：

【プロジェクトの目的】
（例）現在Yahoo!オークションで販売している骨董品・古美術品を、自社のオークションサイトに移行する。
これにより、年間約120万円の手数料を削減し、顧客データを自社で管理することで、
リピート率を40%以上に向上させる。また、海外コレクターへの直接販売を可能にし、
売上の海外比率を30%まで高める。

1.2 プロジェクトの背景

なぜ今、このプロジェクトが必要なのか。市場環境、競合状況、自社の課題などを記述します。

記入欄：

【プロジェクトの背景】
（例）骨董品・古美術品業界では、従来の対面オークション・画廊販売からオンライン販売への移行が進んでいる。
Yahoo!オークションでも取引は行われているが、手数料負担が大きく、また顧客データが
自社に残らないため、リピート販売が困難な状況にある。さらに海外コレクターからの
問い合わせが増加しているが、Yahoo!オークションでは専門的な商品情報（来歴、鑑定情報）の
表現機能が不十分で、海外向け販売の機会を逃している。

1.3 プロジェクトの目標

定量目標（数値で表せるもの）：

• 売上目標（例：初年度月商100万円、2年目300万円）
• 会員数目標（例：初年度500名、2年目2,000名）
• 手数料削減額（例：年間100万円削減）
• リピート率（例：40%以上）
• 海外売上比率（例：30%）

定性目標（数値で表せないもの）：

• ブランド価値の向上
• 顧客との関係構築
• 業界内での認知度向上

記入欄：

【定量目標】
1. 売上目標：初年度月商100万円、2年目月商300万円
2. 会員数目標：初年度500名、2年目2,000名
3. 手数料削減：年間120万円（Yahoo!オークション利用時と比較）
4. リピート率：40%以上
5. 海外売上比率：30%

【定性目標】
1. 「○○ブリーダーの直販サイト」としてのブランド確立
2. コアな骨董・古美術愛好家のコミュニティ形成
3. 業界内でのデジタル化の先駆者としての認知

1.4 プロジェクトの範囲

「何をやるのか」だけでなく、「何をやらないのか」を明確にすることが重要です。範囲が曖昧だと、後から「これもやってほしかった」という要望が無限に出てきます。

記入欄：

【プロジェクトの範囲（やること）】
1. オークションサイトの開設（SaaS型システムの導入）
2. 独自ドメインの取得と設定
3. サイトデザインのカスタマイズ（ロゴ、カラー、レイアウト）
4. 決済機能の設定（クレジットカード、銀行振込）
5. 会員管理機能の設定
6. 初期商品の出品（20点）
7. 運用マニュアルの作成

【プロジェクトの範囲外（やらないこと）】
1. 自社開発（SaaS型システムの利用とする）
2. スマートフォンアプリの開発（Webサイトのみ）
3. 在庫管理システムとの連携（今期は対象外）
4. 会計ソフトとの連携（今期は対象外）
5. 海外向けの多言語対応（今期は対象外、来期検討）

4. 第2章：事業概要とビジネスモデル — お金の流れを明文化する

第2章では、サイトで「何を」「誰に」「どのように」売るのかを明確にします。

2.1 取扱商品とターゲット

記入欄：

【取扱商品】
カテゴリ1：骨董品・古美術品（陶磁器、掛け軸、茶道具など）
カテゴリ2：古書・古地図・古版画
カテゴリ3：武具・甲冑・刀剣（古物許可要）

【ターゲット顧客】
- 一次ターゲット：日本国内の骨董愛好家・コレクター（40代〜70代男性中心）
- 二次ターゲット：海外のコレクター（アジア、欧米）
- 三次ターゲット：骨董・古美術ビギナー（これから始める層）

【ターゲットの特徴・ニーズ】
- 高額商品（1匹10万円〜100万円）でも安心して取引できる場を求めている
- 血統や品質に関する詳細な情報を求めている
- ブリーダーから直接購入したいというニーズが高い

2.2 ビジネスモデル（収益構造）

オークションサイトの収益構造は、主に以下のパターンがあります。自社のモデルを明確にしましょう。

記入欄：

【収益モデル】
基本モデル：落札手数料（落札金額の5%）
補足：初年度は出品手数料無料キャンペーンを実施
将来的に検討：VIP会員向けの年会費制（年間10,000円で手数料優遇）

【手数料設定の根拠】
Yahoo!オークションの手数料8.8%より低く設定し、出品者の移行を促進。
同時に、自社の収益も確保できる水準として5%を設定。

2.3 想定される取引フロー

取引の流れを図解または文章で明確にします。

記入欄：

【取引フロー】

1. 出品者
   └→ 商品情報登録（画像、説明文、開始価格、期間）
        └→ 出品

2. 購入希望者
   └→ 会員登録（メールアドレス、パスワード）
        └→ 入札（自動入札設定可能）
             └→ 落札

3. 落札後
   └→ 落札者：支払い（クレジットカード or 銀行振込）
        └→ 出品者：入金確認、発送手配
             └→ 落札者：商品受取、評価投稿
                  └→ 取引完了

【特記事項】
- 自動延長機能あり（終了5分前に入札があった場合、5分延長）
- 即決価格設定可能（設定した価格で即時落札）
- ウォッチリスト機能あり（気になる商品を登録可能）

2.4 競合分析と差別化ポイント

記入欄：

【主な競合】
1. Yahoo!オークション：最大のオークションプラットフォーム。手数料8.8%。
2. メルカリ：フリマアプリの雄。手数料10%。
3. 骨董専門の対面オークション会：リアル開催、参加に交通費・入会金が必要。

【差別化ポイント】
1. 骨董・古美術特化：来歴（provenance）情報、鑑定書添付機能など、専門情報を充実
2. 低手数料：Yahoo!オークションの8.8%に対し、5%に設定
3. ブリーダー直販：中間業者を介さず、ブリーダーから直接購入可能
4. 越境対応：英語・中国語対応で海外バイヤーも参加可能

5. 第3章：機能要件 — 何ができなければならないのか

第3章では、サイトに必要な機能を漏れなくリストアップします。優先度（必須／重要／あるとよい）をつけることで、コストと期間のバランスを取ります。

3.1 ユーザー向け機能（フロントエンド）

記入欄：

3.2 管理者向け機能（バックエンド）

記入欄：

3.3 出品者向け機能

記入欄：

3.4 外部連携機能

記入欄：

6. 第4章：非機能要件 — 品質と性能の基準を決める

機能要件が「何をするか」を決めるのに対し、非機能要件は「どの程度の品質で行うか」を決めます。ここを曖昧にすると、「動くけど使いにくい」システムになります。

4.1 性能要件

記入欄：

【同時アクセス数】
- 通常時：50人同時アクセス
- ピーク時（オークション終了間際）：200人同時アクセス
- 将来的な拡張を見据え、1,000人まで対応可能なシステムを選定

【レスポンス時間】
- ページ表示：3秒以内
- 入札処理：1秒以内
- 商品検索：2秒以内

【データ容量】
- 画像1枚あたり：最大10MB
- 商品1件あたりの画像枚数：最大20枚
- 総データ容量：初年度100GB、3年後500GBを見込む

4.2 セキュリティ要件

記入欄：

【通信セキュリティ】
- SSL証明書による暗号化通信（https化）必須

【個人情報保護】
- 個人情報データベースへのアクセス制限（管理者のみ）
- パスワードのハッシュ化保存
- 個人情報のバックアップ時も暗号化

【決済セキュリティ】
- PCI DSS準拠の決済代行会社を利用
- クレジットカード情報は自社サーバーに保存しない

【不正対策】
- 不正アクセス検知・遮断機能
- 連続ログイン失敗時のアカウントロック
- 不自然な入札パターンの検知（オプション）

【監査・ログ】
- 管理者操作ログの保存（誰が、いつ、何をしたか）
- ログ保存期間：最低1年間

4.3 可用性要件

記入欄：

【稼働率】
- 目標稼働率：99.5%以上（年間ダウンタイム約44時間以内）
- メンテナンス時間は除外するが、事前告知必須

【バックアップ】
- データベース：日次バックアップ
- 画像ファイル：週次バックアップ
- バックアップ保持期間：30日間
- 障害発生時の復旧目標時間：4時間以内

【障害対応】
- 障害発生時の連絡窓口：システム提供元のサポート窓口
- 緊急連絡手段：電話（平日9:00〜18:00）、メール（24時間）
- 障害発生時の自社対応者：○○（担当者名）

4.4 拡張性要件

記入欄：

【短期的な拡張（1年以内）】
- 出品者数の増加：現在想定10名 → 50名まで対応可能
- 会員数の増加：現在想定500名 → 2,000名まで対応可能
- 商品数の増加：現在想定100点 → 500点まで対応可能

【中期的な拡張（3年以内）】
- 多言語対応（英語、中国語）
- 在庫管理システムとの連携
- 会計ソフトとの連携
- スマートフォンアプリの開発

【APIの提供】
- 将来的な外部連携を見据え、APIが提供されているシステムを選定
- 必要に応じて自社データのエクスポートが可能であること

4.5 運用・保守要件

記入欄：

【運用体制】
- 運用担当者：Aさん（商品出品、問い合わせ対応）
- 運用担当者：Bさん（入金確認、発送手配）
- 管理者：Cさん（システム設定、アカウント管理）

【運用時間】
- 商品出品・管理：平日9:00〜18:00
- 問い合わせ対応：平日9:00〜18:00（メールは24時間受付）
- 発送手配：落札後24時間以内

【マニュアル】
- 管理者向けマニュアル：必須
- 出品者向けマニュアル：必須
- 一般ユーザー向けヘルプ：必須

【保守・サポート】
- システム提供元のサポート時間：平日9:00〜18:00（電話・メール）
- 緊急時（サーバーダウンなど）の連絡先：提供元の専用窓口
- バージョンアップ：提供元のスケジュールに従う

7. 第5章：体制とスケジュール — 誰が、いつ、何をするのか

第5章では、プロジェクトを進める体制とスケジュールを明確にします。

5.1 プロジェクト体制図

5.2 役割と責任

記入欄：

5.3 全体スケジュール

記入欄：

5.4 マイルストーン

記入欄：

8. 第6章：コストと投資対効果 — いくらかかり、何が得られるのか

第6章では、プロジェクトにかかるコストと、それによって得られる効果を明確にします。

6.1 初期費用の内訳

記入欄：

6.2 月次運用コストの内訳

記入欄：

6.3 想定売上と損益分岐点

記入欄：

【月商別損益計算】

【損益分岐点】

• 月商約14万円で固定費を回収可能
• 月商約20万円で利益が出始める

6.4 ROI（投資対効果）試算

記入欄：

【Yahoo!オークション継続 vs 独自サイト開設の比較】

年間差額：約93.6万円

【投資回収期間】

• 初期投資：14,500円
• 月次利益増：約7.8万円（月商100万円時）
• 投資回収期間：1ヶ月未満

9. 第7章：リスクと対策 — 想定される問題とその備え

第7章では、プロジェクトを進める上でのリスクを洗い出し、対策を事前に考えます。

7.1 プロジェクト遂行上のリスク

記入欄：

7.2 システムに関するリスク

記入欄：

7.3 事業に関するリスク

記入欄：

7.4 リスク発生時の対応策

記入欄：

【緊急連絡網】
- システム障害時：システム提供元サポート窓口（電話：XXX-XXXX-XXXX）
- 決済障害時：決済代行会社サポート窓口（電話：XXX-XXXX-XXXX）
- 自社対応責任者：○○（電話：XXX-XXXX-XXXX）

【エスカレーションパス】
1. 初動対応：運用担当者（商品登録、問い合わせ対応）
2. 判断が必要な場合：事業責任者（営業部長）
3. 経営判断が必要な場合：プロジェクト責任者（社長）

【代替手段】
- システム障害時：SNSで状況を告知、メンテナンスページの表示
- 決済障害時：銀行振込のみの受付に切り替え
- 出品者不足時：自社で10点以上出品し、最低限の品揃えを確保

10. 要件定義書の書き方チェックリスト

要件定義書を作成する際に、以下のチェックリストで漏れがないか確認しましょう。

□ 第1章：プロジェクト概要

• プロジェクトの目的がビジネス視点で書かれている
• プロジェクトの背景（なぜ今必要なのか）が明確
• 定量目標（数値）が設定されている
• 定性目標（数値以外）も設定されている
• プロジェクトの範囲（やること）が明確
• プロジェクトの範囲外（やらないこと）が明確

□ 第2章：事業概要とビジネスモデル

• 取扱商品が具体的に列挙されている
• ターゲット顧客が明確（ペルソナ設定があるとなお良し）
• 収益モデル（誰から、いくら取るのか）が明確
• 取引フローが図解または文章で表現されている
• 競合分析ができている
• 差別化ポイントが明確

□ 第3章：機能要件

• ユーザー向け機能が漏れなく列挙されている
• 管理者向け機能が漏れなく列挙されている
• 出品者向け機能が漏れなく列挙されている
• 外部連携機能が列挙されている
• 各機能に優先度（必須／重要／あるとよい）がついている

□ 第4章：非機能要件

• 性能要件（同時アクセス数、レスポンス時間）が設定されている
• セキュリティ要件（SSL、個人情報保護、決済セキュリティ）が明確
• 可用性要件（稼働率、バックアップ）が設定されている
• 拡張性要件（将来的な成長を見据えた対応）が考えられている
• 運用・保守要件（体制、時間、マニュアル）が明確

□ 第5章：体制とスケジュール

• プロジェクト体制図が作成されている
• 役割と責任が明確
• 全体スケジュールが週単位で設定されている
• マイルストーンと完了条件が設定されている

□ 第6章：コストと投資対効果

• 初期費用の内訳が明確
• 月次運用コストの内訳が明確（固定費と変動費の区別）
• 想定売上と損益分岐点が計算されている
• ROI（投資対効果）が試算されている

□ 第7章：リスクと対策

• プロジェクト遂行上のリスクが洗い出されている
• システムに関するリスクが洗い出されている
• 事業に関するリスクが洗い出されている
• 各リスクに対する対策が考えられている
• 緊急時の連絡網とエスカレーションパスが設定されている

11. よくある質問（Q&A）

Q1. 要件定義書を作ったことがありません。どこから手をつければよいですか？

A. まずは「簡易版」（本記事末尾の7項目）から始めることをおすすめします。完璧を目指すと手が止まってしまいます。「目的」「売るもの」「誰に」「必要な機能」「いつまでに」「予算」「担当者」の7つだけ書けば、システム提供元への問い合わせ精度が格段に上がります。その後、提供元との対話の中で詳細を肉付けしていくのが現実的なアプローチです。

Q2. 要件定義書はシステム提供元に作ってもらえますか？

A. ヒアリングをもとに提供元側がドラフトを作成してくれるケースもあります。ただし、「何をビジネス的に達成したいか」という目的は自社でしか書けません。第1章のプロジェクト目的・背景だけでも自社で記述してから提供元に渡すと、的外れな提案を防げます。

Q3. 要件定義書は何ページくらいが適切ですか？

A. 規模や複雑さによりますが、スタート段階では5〜15ページ程度が現実的です。重要なのはページ数より「漏れがないか」です。本記事のチェックリスト（第10章）を使って、抜けている項目がないか確認してください。

Q4. SaaSを利用する場合でも要件定義書は必要ですか？

A. 必要です。SaaSはカスタマイズの自由度が低い分、「そのシステムでビジネス要件が満たせるか」を事前に確認することが重要です。要件定義書があれば、複数のSaaSを同じ基準で比較でき、「導入してみたら機能が足りなかった」という失敗を防げます。

Q5. 要件定義書を作った後、変更が生じた場合はどうすればよいですか？

A. 変更は必ず文書化してください。口頭での変更合意は後でトラブルの元になります。「変更内容・変更理由・変更日・承認者」を記録した「変更履歴」欄を要件定義書に追加しておくと、後からの追跡が容易になります。

12. テンプレートの活用方法とまとめ

テンプレートの活用ステップ

ステップ1：まずは「下書き」として書き出す 最初から完璧を目指さず、思いつくままに各項目を埋めていきましょう。「わからない」ところは空欄でも構いません。

ステップ2：関係者で「壁打ち」する できあがった下書きを、社内の関係者（経営者、営業担当、現場担当）で共有し、意見をもらいましょう。この段階で認識のズレを発見できます。

ステップ3：システム提供元に見せる 複数のシステム提供元に見積もり依頼をする際に、この要件定義書を提示しましょう。曖昧な「こんな感じ」より、格段に精度の高い見積もりが返ってきます。

ステップ4：契約前に最終確認 システム提供元から提示された見積もりや提案書と、要件定義書を突き合わせて確認します。「ここが違う」「ここが抜けている」という点があれば、契約前に修正を依頼しましょう。

ステップ5：プロジェクト進行中の「ものさし」として活用 開発や設定が進む中で、「これは要件定義書のどこに該当するのか」を常に確認しながら進めましょう。これが「後出しじゃんけん」を防ぐ最強の方法です。

要件定義書を使ったシステム提供元とのコミュニケーション

良い例：

「要件定義書の第3章 3.1-7『入札機能』についてですが、
『自動入札機能』が必須と記載していますが、ご提案の見積もりには
含まれていないようです。こちらは対応可能でしょうか？」

悪い例：

「そういえば、自動入札機能ってついてますよね？」

要件定義書という「共通言語」があることで、曖昧さが排除され、効率的なコミュニケーションが可能になります。

まとめ：要件定義書があなたのプロジェクトを救う

オークションサイト開設の成否は、システムの良し悪しだけではありません。

成功の条件：

1. 何を作りたいのかが明確であること
2. その内容が関係者全員で共有されていること
3. それを実現するための予算と体制が確保されていること

要件定義書は、この3つを同時に実現するための道具です。「面倒くさい」「時間がない」とスキップしたくなる気持ちはよくわかります。しかし、この作業を先にやるか後でやるかという違いがあるだけです。後でやる（＝トラブルになってから対応する）ほうが、はるかに手間とコストがかかります。

まずは簡易版の7項目から始めて、少しずつ詳細を肉付けしていきましょう。あなたのオークションサイトの「設計図」を描くことが、成功への最短ルートです。

まとめチェックリスト（要件定義書 簡易版）

時間がない方はまずこの7項目を書くことから始めてください。

1. 目的：（例）Yahoo!オークションの手数料を削減し、顧客データを自社で管理する
2. 売るもの：（例）骨董品・古美術品、陶磁器・掛け軸・茶道具など、1点3,000円〜200万円
3. 誰に売るか：（例）日本国内の骨董愛好家・コレクター（40〜70代男性）
4. 必要な機能：（例）会員登録、入札、自動延長、決済（カード・銀行振込）
5. いつまでに：（例）2か月後に本番公開
6. 予算：（例）初期費用5万円以内、月額1万円以内
7. 誰がやるか：（例）Aさん（商品出品）、Bさん（発送）、Cさん（システム設定）

この7つだけでも書いておけば、何もない状態よりはるかに良いスタートが切れます。