■ この記事はこんな人におすすめ

開発チームに配属されたばかりで「要件定義」という言葉をよく聞く
要件定義が何なのか、なぜ大切なのかが分からない
実装を始める前に何をすべきか知りたい
チーム内で依頼者と話し合うときの流れを理解したい

■ この記事で得られること

「要件定義」の本質が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人程度の実務未経験の方が応募し技術面接を受けます。
その経験を通し、実務未経験者の方にぜひ身につけて欲しい技術力（文法）をここでは紹介していきます。