■ この記事はこんな人におすすめ
- 開発チームに配属されたばかりで「要件定義」という言葉をよく聞く
- 要件定義が何なのか、なぜ大切なのかが分からない
- 実装を始める前に何をすべきか知りたい
- チーム内で依頼者と話し合うときの流れを理解したい
■ この記事で得られること
- 「要件定義」の本質が3分で理解できます
- 依頼者と開発チームの間で何が起きているのかが分かります
- 要件定義がうまくいくかどうかで、プロジェクトの成否が変わる理由が理解できます
- 実際に要件定義を進めるときのステップが明確になります
■ 参考書籍
1. 結論：要件定義とは「依頼者が納得するための条件を満たすこと」
要件定義は、難しく聞こえるかもしれませんが、本質は非常にシンプルです。
「依頼者が『これならOK』と納得するための条件を満たすこと」
実装を始める前に、開発チームと依頼者が「同じビジョン」を共有するプロセス。それが要件定義です。
要件定義がないまま実装を始めると、こんなことが起きます：
- ❌ 作ったものが「想像していたものと違う」と言われる
- ❌ 追加の機能が次々と出てくる
- ❌ スケジュールと予算が大幅に超過する
- ❌ 実装をやり直す羽目になる
要件定義がしっかりしていると：
- ✅ チーム全員が同じ目標に向かって動ける
- ✅ 「なぜこの機能が必要なのか」が明確
- ✅ 実装の効率が劇的に上がる
- ✅ 後になって「やっぱり変更」が減る
2. 要件定義が直面する現実的な制約
「依頼者が『これならOK』な仕様」にたどり着くまでに、常に以下のような制約が立ちはだかります。
| 制約 | 説明 | 例 |
|---|---|---|
| 実装者のスキル | チーム内の技術力では実現不可能な要件がある | 「AI を使った自動分類機能」→ 機械学習の専門家がいない |
| 現代の技術 | 既存技術では対応できない新しい要件がある | 「リアルタイムで10万人同時接続」→ 確立された解法がない |
| 期間 | スケジュール内に完成させられない要件がある | 「3ヶ月で100の機能を実装」→ 物理的に不可能 |
| 予算 | 予算内では実装不可能な要件がある | 「クラウドで高可用性を実現」→ インフラ費用が膨大 |
| 人手 | 必要なリソースが確保できない要件がある | 「iOS と Android 版を並行開発」→ 人材が不足 |
重要な考え方
完全な要件は存在しません。制約を理解した上で、何を優先するかを判断することが求められます。
3. 要件定義の基本的な流れ：往復のプロセス
要件定義は、一度の完成ではなく、往復を何度も繰り返すプロセスです。
要望(C) → 要求(C) → 検討(M) → 提案(M) → 検討(C)
↑ ↓
←─────── このループを繰り返す ←────
-
C = Client（依頼者）
- 「こんなことがやりたい」と要望を示す
- 提案を受けて検討し、フィードバックを返す
-
M = Me（実装チーム）
- 要望を「実現可能な要求」に落とし込む
- 制約を踏まえた提案を示す
- 依頼者のフィードバックを次の検討に反映させる
このサイクルこそが要件定義です。 一度で完璧な仕様書ができるわけではなく、何度も往復して形を整えていきます。
例：実装チームと依頼者の往復
❌ 悪い例（往復なし）
依頼者：「使いやすいUIが欲しい」
開発チーム：「わかりました。では実装します」
↓
実装完了後に...
依頼者：「これじゃない！想像と違う」
✅ 良い例（往復あり）
依頼者：「使いやすいUIが欲しい」
開発チーム：「それは具体的にはどのような操作を想定していますか？」
依頼者：「初心者でも直感的に操作できて、3分で基本が分かるようにしてほしい」
開発チーム：「では、3つのメニューに絞り込む案を提案します。こちらをご確認ください」
依頼者：「このレイアウト案、もう少し工夫が必要ですね」
開発チーム：「かしこまりました。こうしてはいかがでしょう」
↓
最終的に両者が納得する仕様が完成
4. 要件は3つのカテゴリに分類される
すべての要件は、以下のいずれかに分類されます。
■ 1. UI（ユーザーインターフェース）
「ユーザーが何を見て、どう操作するのか」
- 画面レイアウト（どの要素がどこに配置されているか）
- 入力フォーム（テキストボックス、ボタンなど）
- 表示内容（何を表示するのか）
- ナビゲーション（どの画面からどの画面に移動するのか）
具体例
商品一覧画面には、以下の要素を配置する：
- 検索フォーム（上部）
- 商品リスト（中央）
- ページネーション（下部）
■ 2. 機能（Function）
「ユーザーの操作に対して、システムが何をするのか」
- データ処理（計算、変換、整形）
- ビジネスロジック（注文処理、支払い処理など）
- 外部連携（別システムとのデータ連携）
- 通知・警告（ユーザーへの通知）
具体例
「商品検索ボタンをクリック」という操作に対して、
システムは「入力されたキーワードでデータベースを検索し、
マッチした商品を返す」という機能を提供する
■ 3. データ（Data）
「システムが何を保持し、どう管理するのか」
- テーブル設計（どんなデータを保存するか）
- リレーションシップ（データ同士の関係）
- データの有効期限（いつまでデータを保持するか）
- アーカイブ・削除ルール（古いデータをどう処理するか）
具体例
商品情報テーブル：商品ID、商品名、価格、在庫数
在庫ロック：注文時に在庫を一時的にロック
5. 要件定義の準備フェーズ：6つのステップ
実装の前に、チーム内の理解を統一するために、以下の6つを順番に整理します。
■ ①企画（Planning）
目的：「何が実現できるか」を明確にする
依頼者：「新しい機能を追加してほしい」
↓
開発チーム：「で、それで何が実現されるんですか？」
チェックリスト
- なぜこれを作るのか（背景・問題）
- 実現すると何が変わるか（効果）
- 誰が使うのか（ターゲット）
- いつまでに必要か（期限）
具体例
❌ 悪い企画案
「新しい在庫管理システムを作る」
✅ 良い企画案
「毎朝の朝礼時に店舗スタッフが5分以内に在庫不足を確認できるようになることで、
発注ミスを減らし、売上ロスを月3%削減する」
■ ②全体像（System Overview）
目的：大枠の理解を共有する
シンプルに図に描いてみる。
外部システムA
↓ (データ連携)
[我々のシステム] ← ユーザーが操作
↓ (結果の通知)
外部システムB
開発に必要な情報
- API の仕様（他システムとどう通信するのか）
- データフォーマット（どんな形式でやり取りするのか）
- エラーハンドリング（通信に失敗したときどうするのか）
- 連携のトリガー（いつ他システムと連携するのか）
■ ③区分け（Scope Definition）
目的：「何を作るのか」「何を作らないのか」を線引きする
これが曖昧だと、後で「やっぱり追加で…」が増え、スケジュール超過につながります。
決める項目
- フェーズ1（必ず実装）： 最小限の機能
- フェーズ2以降： 優先度が低い機能
- 外部対応： システムでは対応しない作業（手作業で対応）
- 今後対応予定： 制約上、現段階では未実装
具体例
【オンラインストアシステム】
◎ フェーズ1で実装：
- 商品検索・表示
- カート機能
- 注文処理
△ フェーズ2で検討：
- レビュー機能
- ウィッシュリスト
- ポイントシステム
✗ 実装しない：
- 在庫の自動発注（手作業で対応）
- SNS連携（当初は不要）
■ ④実装技術（Technology Stack）
目的：技術的な実現可能性を確認する
チーム内の技術レベルに合わせた選択が重要です。高度な技術は、実装スキルがなければ負債になります。
決める項目
システムアーキテクチャ
- 全体構成：モノリス vs マイクロサービス
- 動作環境：オンプレミス vs クラウド
- スケーラビリティ：どれくらいの負荷に対応するか
各部の実装技術
- フロントエンド：React / Vue / その他
- バックエンド：Node.js / Python / Java / その他
- データベース：PostgreSQL / MongoDB / その他
- インフラ：AWS / GCP / Azure / その他
具体例
❌ 危険な選択
「最新の技術スタック使いたいので、Rust + GraphQL + Kubernetes で作ります」
→ チームに経験者がいなければ、開発効率が落ちて負債になる
✅ 適切な選択
「チーム内で React と Node.js の経験者が多いので、この技術スタックを採用します」
■ ⑤実現したいことの整理（Requirements Refinement）
目的：「目に見えるやりたいこと」から「本当に実現すべきこと」を抽出する
依頼者の「要望」と「本質的なニーズ」は異なることがあります。
プロセス
- 依頼者からの要望をそのまま列挙する
- 各要望について「なぜ必要か？」と問い直す
- 本質的な要件だけを残す
具体例
要望：「テンプレートから一括で作成したい」
↓ なぜ必要か？
本質：「手作業による時間短縮」「ヒューマンエラーの削減」
結論：
単なる「一括作成機能」ではなく
→「効率化」と「品質確保」が真の目的
→ 他の手段でも実現できる可能性がある
例えば：
- 自動入力機能（テンプレート機能なし）
- チェックリスト表示（エラー防止）
なども候補として考えられる
■ ⑥利用者の行動シナリオ（User Scenarios）
目的：システムが実際にどう使われるかをイメージする
具体的に「いつ、誰が、何をするのか」を書く。
シナリオに含める要素
| 要素 | 説明 | 例 |
|---|---|---|
| タイミング | いつ使うのか | 毎朝8:30、月初めなど |
| 理由 | なぜ使うのか | 売上記録、在庫確認など |
| 具体的な仕事 | 何を達成するのか | 「明日の仕込み数を決定する」 |
シナリオ例
【朝礼時の在庫確認】
時間帯：毎朝8:30
ユーザー：店舗マネージャー
流れ：
1. システムにログイン
2. 昨日の売上を確認
3. 在庫が足りないものを確認
4. 本社に追加発注を連絡
実現されるべき機能：
- ログイン機能
- 売上表示（フィルタリング機能付き）
- 在庫アラート（不足しているものを目立つように）
- 発注テンプレート（メール下書き機能）
複数のシナリオを用意することで、見落としていた要件が発見できます。
6. UI設計フェーズ：概念を具体的な画面に落とし込む
概念が固まったら、ユーザーインターフェースを具体化します。
■ ステップ1：ラフ項目を洗い出す
各画面に表示される主な要素を、大まかに決めます。
【商品一覧画面】
- 検索フォーム
- 商品リスト
- ページネーション
- 詳細表示ボタン
■ ステップ2：導線を考える
「ユーザーはどう画面を移動するのか」を図で示します。
ログイン画面
↓
メニュー画面
├→ 商品一覧 → 商品詳細 → 購入画面 → 完了画面
├→ 注文履歴 → 注文詳細
└→ 設定画面
■ ステップ3：ラフの詳細を記入
各要素について「それは何か？」「何が表示されるのか」を明記します。
| 要素 | 説明 | 入力 / 表示 | 補足 |
|---|---|---|---|
| 検索フォーム | 商品をキーワード検索 | 入力 | 複数キーワードでAND検索 |
| 商品リスト | マッチした商品を表示 | 表示 | 10件ずつページネーション |
| 詳細ボタン | 選んだ商品の詳細へ遷移 | アクション | クリックで詳細画面へ |
7. 機能設計フェーズ：画面から機能を設計する
UI がまとまったら、各機能を具体化します。
■ ステップ1：画面遷移図から機能をピックアップ
「どの画面からどこへ遷移するのか」を分析し、必要な機能を抽出します。
例：「商品一覧 → 詳細 → 購入」という遷移があれば
必要な機能：
- 商品検索機能
- 商品取得機能
- 購入処理機能
■ ステップ2：表示項目から「出力」を決める
画面に何を表示するかが、機能が何を出力すべきかを決めます。
【商品詳細画面で表示する情報】
↓
出力：商品ID, 商品名, 説明, 価格, 在庫状況, レビュー
■ ステップ3：遷移元画面から「入力」を決める
ユーザーが前の画面で入力したものが、この機能の入力です。
【検索フォームでユーザーが入力】
入力：キーワード, カテゴリフィルタ, ソート順
【これを受け取る機能が決定】
機能：商品検索（キーワード, カテゴリフィルタ, ソート順から結果を返す）
■ ステップ4：処理をツリー構造で整理
複雑な処理は、ツリー構造で整理することで、実装が明確になります。
【注文処理】
├─ 注文情報の入力
│ ├─ 配送先住所の選択
│ └─ 支払方法の選択
├─ 在庫の確保
│ ├─ 在庫確認
│ ├─ 在庫数を減らす
│ └─ 確保ロック
└─ 決済処理
├─ 決済ゲートウェイへ送信
├─ 結果確認
└─ エラー時のロールバック
このツリーは、実装時のモジュール分割にそのまま活用できます。
■ ステップ5：機能を分割する
大きな機能は複数の小さな機能に分割します。
【大きな機能】
「注文処理」
【分割後の機能】
① 注文情報の検証
② 在庫の確認
③ 決済の実行
④ 注文の記録
⑤ 完了メールの送信
分割のメリット：
- テストがしやすい
- 再利用しやすい
- エラーハンドリングが明確
- 責任を分けて並行開発できる
8. データ設計フェーズ：何を保存するか決める
機能がまとまったら、データ構造を詳細設計します。
■ ステップ1：これまでの成果物から必要な項目を洗い出す
企画、UI、機能の各段階で出てきた「データ」を、すべて集約します。
UI から出た情報：商品名, 価格, 在庫数
機能から出た情報：商品ID, 説明, レビュー, 在庫ロック
シナリオから出た情報：売上日時, 売上数
■ ステップ2：データベース設計を行う
効率的なテーブル設計を行います。この段階では完全な正規化は不要。実装時に最適化すればOK。
【products テーブル】
- product_id (主キー)
- product_name
- description
- unit_price
【inventory テーブル】
- inventory_id (主キー)
- product_id (product テーブルを参照)
- stock_quantity
- updated_at
【sales テーブル】
- sales_id (主キー)
- product_id (product テーブルを参照)
- quantity_sold
- sales_date
9. よくある落とし穴（やってはいけないこと）
要件定義を進める中で、よく陥るミスを紹介します。
■ 落とし穴1：要件と実装仕様を混ぜる
❌ 悪い例
「AWS RDS を使った PostgreSQL データベースを実装する」
✅ 良い例
「複数ユーザーの同時アクセスに対応した、
スケーラブルなデータベースが必要」
ポイント
- 要件は「何を実現したいか」
- 実装仕様は「どう実装するか」
要件定義の段階では、「何を」にフォーカス。「どう実装するか」は実装フェーズで決めます。
■ 落とし穴2：曖昧な表現
❌ 悪い例
「使いやすいUI が必要」
「高速に動作する」
「簡単に操作できる」
✅ 良い例
「検索から結果表示までが 3秒以内」
「初心者でも 3分以内に基本操作が可能」
「100件のデータを 1秒で読み込む」
ポイント
- 数値や具体例で測定可能にする
- 「簡単」「速い」など抽象的な言葉は避ける
■ 落とし穴3：ユーザー視点の欠落
❌ 悪い例
「在庫テーブルに在庫数カラムを追加する」
✅ 良い例
「店舗スタッフが、朝の短い時間で
在庫の不足を素早く確認できる機能が必要」
ポイント
- 「誰が」「何をしたいのか」が最初にある
- システムの技術的な詳細よりも、ユーザーの行動を優先
10. 要件定義完了時の確認チェックリスト
要件定義が十分か、以下を確認してください。
■ 企画の確認
- 背景と目的が明確に記述されているか
- 実現による効果が具体的か（数値で示せるか）
- ターゲットユーザーが定義されているか
■ UI の確認
- すべての画面が図示されているか
- 画面遷移が矛盾なく描かれているか
- 各要素の意図が説明されているか
■ 機能の確認
- すべての画面に対応する機能が定義されているか
- 入力と出力が明確か
- エラーケースが考慮されているか（通信失敗、データ不正など）
- 外部連携の仕様が決まっているか
■ データの確認
- 必要なテーブルがすべて定義されているか
- リレーションシップが適切か
- データの有効期限が決まっているか
■ 全体
- 依頼者が内容を理解・納得しているか（最重要）
- チーム内で実装イメージが共有されているか
- 実装できない要件は記録されているか
11. 実装前の最終チェック
要件定義が終わり、開発に進む前に、以下を最終確認します。
■ ビジョンの共有
依頼者と開発チームが同じビジョンを持っているか
イメージの齟齬がないか、確認しましたか？
■ スコープの明確化
何を作るのか、何を作らないのか、線引きが曖昧でないか
フェーズ分けは明確か？
■ 実装可能性の検証
技術的な課題は洗い出されているか
予算的な課題は洗い出されているか
時間的な課題は洗い出されているか
■ 優先度の決定
制約がある場合、何を優先するか決まっているか
フェーズ1 で最小限の機能は何か、決まっているか
これらが確認できたら、開発フェーズへ進む準備が整った状態です。
まとめ
重要なポイント（3分で読める要約）
-
要件定義とは「依頼者が納得するための条件を満たすこと」
- 実装を始める前に、チーム全員が同じビジョンを共有するプロセス
-
制約を認識することが必須
- スキル、技術、期間、予算、人手の制約がある
- 完全な要件は存在しない。何を優先するかを判断することが大切
-
往復を何度も繰り返す
- 一度で完璧な仕様書ができることはない
- 依頼者と開発チームの対話の中で、要件が洗練される
-
UI・機能・データの3つの視点から検討する
- すべての要件はこの3つのいずれかに分類される
- 漏れなく検討することで、実装がスムーズになる
-
ユーザー視点を忘れずに
- 「誰が」「何をしたいのか」が最初にある
- 技術的な詳細よりも、実現したい価値を優先
結局何をすればいいの❓
今すぐ実践できるアクションリスト
この週（Day 1-2）
- プロジェクトの背景と目的を依頼者に確認する
- 「何が実現できるか」を言語化する
- ターゲットユーザーを定義する
来週（Day 3-5）
- 全体のシステム図を簡単に描く
- スコープを線引きする（何を作る／作らない）
- ユーザーシナリオを複数パターン書く
2週目（Day 6-10）
- 主な画面を図に描く
- 画面遷移を整理する
- 各機能の入出力を明確にする
3週目以降
- データテーブルを設計する
- 要件定義書を完成させる
- 依頼者と最終確認を実施する
優先度
- 必ずやる：ビジョンの共有、スコープの線引き、ユーザーシナリオ
- できればやる：UI 設計、機能設計、データ設計
- 後回しでもOK：細かい実装仕様、最適化
以上が、開発メンバー初心者向けの要件定義ガイドです。
要件定義は「完璧な仕様書を作ること」ではなく、「チーム全員が同じ目標を向いている状態を作ること」 が最重要です。
依頼者と開発チームの対話を通じて、初めて要件が洗練されます。恐れずに質問し、確認し、一緒に進めていきましょう。
株式会社シンシア
株式会社xincereでは、実務未経験のエンジニアの方や学生エンジニアインターンを採用し一緒に働いています。
※ シンシアにおける働き方の様子はこちら
シンシアでは、年間100人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。