【失敗5例】要件定義の進め方 - エンジニアのための完全ガイド

参考資料

本記事は以下の書籍の内容を参考に、学習を兼ねてまとめたものです。

• 『はじめよう! 要件定義 〜ビギナーからベテランまで』羽生章洋 著

より詳しく学びたい方は、ぜひ原著も読んでみてください。

この記事で学べること

• 要件定義とは何か、なぜ必要なのか
• 要件定義を始める前に準備すべきこと
• UI、機能、データの定義方法
• 実際の作業の進め方と成果物

1. そもそも要件定義って何?

1-1. 料理に例えるとわかりやすい

要件定義を理解するために、料理を例に考えてみましょう。

あなたがレストランで料理を注文する場面を想像してください。

「目玉焼きを作ってください」

これは一見シンプルな注文ですが、実はいろんな情報が抜けています。

• 両面焼き? 片面焼き?
• 黄身はどれくらい固める?
• 塩コショウはどれくらい?
• 付け合わせは何?

コックさんとお客さんの間で「美味しい目玉焼き」のイメージが違っていたら、期待外れの料理が出てきてしまいます。

システム開発も同じです。

**作ってほしい人(依頼主)**が
**作る人(開発者)**に出す
依頼事項(リクエスト)

これを明確に定めることが要件定義なんです。

1-2. なぜ要件定義が必要なのか

友達同士のやり取りなら「まあいいか」で済むかもしれません。でも、企業の業務システムを作る場合、認識のズレは大きな問題を引き起こします。

• 作り直しで膨大な工数が発生
• 予算オーバー
• プロジェクトの炎上
• ユーザーの不満

こうした問題を防ぐために、依頼事項を明確に定まった形にして、開発者に伝える必要があるのです。

2. 要件定義の基本的な流れ

要件定義は次の5つのステップで進めます。

ステップ1: 要望を出す

まずは「こんなことできたらいいな」「こんなのがほしいな」という願望から始まります。

この願望を検討して、何かしらの求めるものが定まってくる。これが要望です。

具体例:

• 「在庫管理をもっと楽にしたい」(願望)
• 「スマホで在庫数を確認できるシステムがほしい」(要望)

ステップ2: 要望を要求にする

要望は心の中で思っているだけの状態。これを誰にでもわかる形にする必要があります。

つまり、言葉や書面にすること。これが要求です。

具体例:

【要求書】
システム名: 在庫管理アプリ
概要: スマートフォンから在庫数をリアルタイムで確認できるシステム
必要な機能:
- 商品別の在庫数表示
- 在庫数の検索機能
- 在庫が少なくなったら通知

ステップ3: 要求を検討する

受け手側(開発チーム)で要求を検討します。

• 技術的に実現可能か?
• 予算内で作れるか?
• 期限内に完成するか?
• 必要なリソースは揃っているか?

要件とは「依頼主と開発者の間での相互の合意事項」です。一方的な要求ではなく、双方が納得できる内容にする必要があります。

ステップ4: 代替案を考え、提案する

単に「できる」「できない」を答えるだけでなく、専門家として代替案を提案することが重要です。

具体例:

【提案】
要求: リアルタイムで在庫数を確認したい

代替案1: 5分ごとに自動更新する方式
→ コスト: 低、レスポンス: やや遅い

代替案2: WebSocketを使った完全リアルタイム方式
→ コスト: 高、レスポンス: 速い

代替案3: 手動更新ボタン + 自動更新の組み合わせ
→ コスト: 中、レスポンス: 中、おすすめ!

ステップ5: 合意形成を繰り返す

提案を受けて、依頼側が再検討します。これを繰り返すことで徐々に合意形成がされていき、最終的な要件が出来上がります。

3. 要件を構成する3つの要素

完成したソフトウェアを作るために必要な情報は次の3つです。

UI(ユーザーインターフェース)

ユーザーが実際に操作する画面や入力項目のこと。

依頼主が「完成したソフトウェア」を確認する方法は、UIを通じてソフトウェアを操作することです。

機能

ボタンを押したときに動く処理のこと。

UIができていても、ボタンを押しても何も動かなければ意味がありません。

データ

システムが扱う情報のこと。

機能が正しく動くためには、必要なデータが存在している必要があります。

定義する順番が重要!

1. UI を決める
2. 機能を決める
3. データを決める

この順番で進めると、依頼主にとってわかりやすく、納得しやすくなります。

4. 要件定義を始める前の準備【超重要】

実は、要件定義を始める前にやるべきことがたくさんあります。ここをしっかりやっておくと、後の作業がスムーズに進みます。

準備1: 企画を確認する

まず、そもそも「なぜこのシステムを作るのか」を確認します。

企画書に最低限含めるべき項目:

1. プロジェクト名: 〇〇在庫管理システム

2. なぜ作るのか(目的)
   - 在庫管理の業務効率を30%向上させる
   - 在庫切れによる機会損失を削減する

3. 何を作るのか
   - 作るもの: スマホで使える在庫管理アプリ
   - 利用者: 倉庫担当者、店舗スタッフ
   - 得られる便益: いつでもどこでも在庫確認可能

4. どのように作るのか
   - 開発体制: エンジニア3名、デザイナー1名
   - 期限: 6ヶ月

企画意図から外れた要件を定義しても、依頼主から納得が得られません。まず全体の方向性を確認することが大切です。

準備2: 全体像を描く

作成するシステムが、利用者や他のシステムとどんな関係にあるのかを図にします。

全体像を描く手順:

ステップ1: システムを中心に描く

┌─────────────────┐
│  在庫管理システム  │
└─────────────────┘

ステップ2: 利用者を配置する

┌─────────┐
│倉庫担当者│
└─────────┘
        │
        ↓
┌─────────────────┐
│  在庫管理システム  │
└─────────────────┘
        ↓
┌─────────┐
│店舗スタッフ│
└─────────┘

ステップ3: 利用者が行うことを書く

┌─────────┐
│倉庫担当者│─「在庫を登録」
└─────────┘
        │
        ↓
┌─────────────────┐
│  在庫管理システム  │
└─────────────────┘
        ↓
┌─────────┐
│店舗スタッフ│─「在庫を確認」
└─────────┘

忘れがちな2つのポイント:

1. システム管理者を忘れずに

   • 誰がマスタデータを管理するのか?
   • 誰がユーザーアカウントを管理するのか?

2. 連携するシステムを描く

   • 既存の販売管理システムと連携するか?
   • 外部のAPI(配送業者など)と連携するか?

この全体像の枠内が、今回の要件定義のスコープです。枠を超えるような要件は、今回のプロジェクトの対象外ということになります。

準備3: 実装技術を決める

サンプルアプリケーションを作れる程度に、基本的な技術を決めておきます。

決めるべきこと:

1. システムアーキテクチャ

• Webブラウザ型
• スマホアプリ + Webサーバ型
• デスクトップアプリ型

2. クライアント側の技術

• フレームワーク: React / Vue.js / Flutter
• 状態管理: Redux / Context API
• UIライブラリ: Material-UI / Tailwind CSS

3. サーバー側の技術

• 言語: Node.js / Python / Ruby
• フレームワーク: Express / Django / Rails
• データベース: PostgreSQL / MySQL / MongoDB

4. 通信

• プロトコル: REST API / GraphQL / WebSocket
• データ形式: JSON / XML

なぜここで技術を決めるのか? 実装の都合がわからないと、現実的な要件が決められないからです。

「この技術では実現できない」という事態を後から発見すると、大幅な手戻りが発生します。

準備4: 実現したいことを整理する

要件定義の段階で「具体的に何を実現するのか」が書かれていないと、迷子になってしまいます。

実現したいこと一覧の例:

優先度: 高
- 商品の在庫数をリアルタイムで確認できる
- 在庫が閾値を下回ったら通知する
- スマホから在庫の入出庫を登録できる
- バーコードで商品を検索できる

優先度: 中
- 在庫の推移をグラフで表示できる
- 在庫の棚卸作業を支援する
- 発注書を自動生成できる

優先度: 低
- 複数の倉庫を管理できる
- 在庫予測機能

これをリスト化しておくことで、「実はこういうことを実現したかった」というちゃぶ台返しを防げます。

準備5: 利用者の行動シナリオを書く

ユーザーがなぜシステムを使うのか、どのタイミングで使うのかを可視化します。

スイムレーン図の例:

┌─────────────────────────────────────┐
│ 店舗スタッフ                          │
└─────────────────────────────────────┘
    │
    │ 商品が売れた
    ↓
┌───────────────┐
│ 在庫確認画面を  │
│ 開く           │
└───────────────┘
    │
    ↓
┌───────────────┐
│ 商品を検索     │
└───────────────┘
    │
    ↓
┌─────────────────────────────────────┐
│ システム: 在庫数を表示                 │
└─────────────────────────────────────┘
    │
    ↓
┌───────────────┐
│ 在庫が少ない   │
│ ことを確認     │
└───────────────┘
    │
    ↓
    (発注依頼へ)

行動シナリオから得たい情報:

1. システムを利用するタイミング

   • 例: 商品が売れたとき

2. システムを利用する理由

   • 例: 在庫が足りるか確認するため

3. システムで達成する仕事

   • 例: 在庫数を確認し、必要なら発注する

重要なのはUIの出現場所が明確になることです。これが要件定義の材料になります。

準備6: 概念データモデルを作る

「どんなデータを使うか」の簡単なメモを作ります。

┌─────────┐       ┌─────────┐
│  商品    │       │  在庫    │
├─────────┤       ├─────────┤
│ 商品ID   │←─────│ 在庫ID   │
│ 商品名   │       │ 商品ID   │
│ カテゴリ │       │ 数量     │
│ 単価     │       │ 倉庫ID   │
└─────────┘       │ 更新日時 │
                  └─────────┘
      ↓
┌─────────┐
│  倉庫    │
├─────────┤
│ 倉庫ID   │
│ 倉庫名   │
│ 住所     │
└─────────┘

ここでは厳密な正規化は不要です。「こんなデータがありそう」というレベルでOK。

ここまでの準備で揃うもの:

• 企画書
• 全体像
• 実装技術
• 実現したいこと一覧
• 行動シナリオ
• 概念データモデル

これらを材料として、いよいよ要件定義に入ります!

5. UI(ユーザーインターフェース)の定義

5-1. UIを構成する要素

UIは次の3つの要素で構成されます:

1. データ項目: 表示する情報(商品名、在庫数など)
2. 操作項目: ボタン、入力欄、チェックボックスなど
3. レイアウト: 画面の配置やデザイン

5-2. UI定義の手順

ステップ1: 対象となるUIをピックアップ

行動シナリオから、定義すべき画面を選びます。

例: 在庫確認画面

ステップ2: ラフなイメージを描く

まずは手書きやツールでざっくり画面イメージを描きます。

┌────────────────────────┐
│ 在庫確認               │
├────────────────────────┤
│ [検索: ______] [🔍]   │
├────────────────────────┤
│ 商品A  在庫: 50個      │
│ [詳細] [入庫] [出庫]   │
├────────────────────────┤
│ 商品B  在庫: 3個 ⚠️   │
│ [詳細] [入庫] [出庫]   │
└────────────────────────┘

ステップ3: 必要な項目を列挙

画面に必要な項目を全部書き出します。

データ項目:

• 商品名
• 在庫数
• 単位(個、箱など)
• 最終更新日時
• 警告アイコン(在庫少ない場合)

操作項目:

• 検索入力欄
• 検索ボタン
• 詳細ボタン
• 入庫ボタン
• 出庫ボタン

ステップ4: 動線を考える

画面遷移を図にします。

[在庫一覧画面]
    │
    ├→ [検索ボタン] → [検索結果画面]
    │
    ├→ [詳細ボタン] → [在庫詳細画面]
    │
    ├→ [入庫ボタン] → [入庫登録画面] → [確認画面] → [完了画面]
    │
    └→ [出庫ボタン] → [出庫登録画面] → [確認画面] → [完了画面]

ステップ5: 操作と機能を織り込む

画面遷移に、どのボタンでどの処理が動くかを書き加えます。

[在庫一覧画面]
    │
    │ [検索ボタンクリック]
    │ → 機能: 在庫検索処理
    ↓
[検索結果画面]

忘れがちな3つのポイント:

1. 同一画面への遷移

   • 例: エラーが出たら同じ画面に戻る

2. 初期処理

   • 例: 画面を開いたときの初期データ読み込み

3. 終了処理

   • 例: 画面を閉じるときのデータ保存確認

5-3. エラーメッセージの設計

エラーメッセージは次の3つを必ず含めます:

【例: 電話番号入力エラー】

現象: 電話番号の入力が不正です
原因: 許可されない文字が入力されました
対処: 数字(0-9)またはハイフン(-)のみを使って再入力してください

ユーザーが「何が起きたか」「なぜそうなったか」「どうすればいいか」を理解できることが大切です。

5-4. UI定義の成果物

最終的に次の3つが出来上がります:

1. ラフイメージまたはモックアップ
2. 画面遷移図
3. 項目の説明書

これらがあれば、デザイナーもプログラマも迷わずに作業できます。

6. 機能の定義

6-1. 機能とは何か

機能は数学の関数と同じように考えます。

y = f(x)

x: 入力
f: 処理
y: 出力

具体例: 在庫検索機能

入力(x): 商品名の検索キーワード
処理(f): データベースから該当商品を検索
出力(y): 検索結果の商品一覧

6-2. 機能定義の手順

ステップ1: 出力を決める

画面遷移図から、その機能の先につながっている画面を見て、どんな情報を出力するか決めます。

例: 在庫検索機能

出力:

• 商品ID
• 商品名
• 在庫数
• 最終更新日時

ステップ2: 入力を決める

その出力を作るために必要な材料(入力)を決めます。

入力:

• 検索キーワード(画面から)
• ユーザーID(ログインセッションから)

ステップ3: 処理を考える

入力から出力を作る処理を、階層的に整理します。

在庫検索処理
├─ 検索キーワードを取得
├─ データベースクエリを構築
│  ├─ 商品名での部分一致検索条件を作成
│  └─ 在庫数が0以上の条件を追加
├─ データベースにアクセス
│  └─ 商品テーブルと在庫テーブルを結合
├─ 検索結果を取得
└─ 結果を整形して返却
   ├─ 在庫数が閾値以下なら警告フラグを立てる
   └─ JSON形式に変換

プログラミングコードは書かない!

この時点では「何をすれば役割を達成できるか」を考えることが重要。実装の詳細は後回しです。

6-3. 機能定義の成果物

各機能について次の情報をまとめます:

【機能定義書】

機能名: 在庫検索

入力:
- 検索キーワード (文字列, 必須)
- ユーザーID (数値, 必須)

処理:
- 商品名での部分一致検索を実行
- 在庫数が0以上のものを抽出
- 在庫数が閾値以下なら警告フラグを設定

出力:
- 商品ID (数値)
- 商品名 (文字列)
- 在庫数 (数値)
- 警告フラグ (真偽値)
- 最終更新日時 (日時)

エラー:
- 商品が見つからない場合: "該当する商品がありません"
- データベース接続エラー: "システムエラーが発生しました"

7. データの定義

7-1. データベース設計の基本

データベースの設計ではER図(Entity Relationship Diagram)を作成します。

用語説明:

• エンティティ: データのまとまり(例: 商品、在庫、ユーザー)
• アトリビュート: エンティティの属性(例: 商品名、価格)
• リレーションシップ: エンティティ間の関係

7-2. ER図の作成手順

ステップ1: エンティティを洗い出す

画面遷移図や機能定義から、必要なデータのまとまりを見つけます。

例:

• 商品
• 在庫
• 倉庫
• ユーザー
• 入出庫履歴

ステップ2: 属性を定義する

【商品エンティティ】
- 商品ID (主キー)
- 商品コード
- 商品名
- カテゴリ
- 単価
- 単位
- 登録日時
- 更新日時

【在庫エンティティ】
- 在庫ID (主キー)
- 商品ID (外部キー)
- 倉庫ID (外部キー)
- 数量
- 最終更新日時

【倉庫エンティティ】
- 倉庫ID (主キー)
- 倉庫コード
- 倉庫名
- 住所
- 電話番号

ステップ3: リレーションシップを定義する

商品 ─────< 在庫 >───── 倉庫
(1)        (多)  (多)    (1)

「1つの商品は複数の倉庫に在庫を持つ」
「1つの倉庫は複数の商品の在庫を持つ」

7-3. データ定義の成果物

最終的に結合ER図が完成します。これが物理的なデータベース設計の元になります。

8. 要件定義の仕上げ

8-1. CRUDマトリックスで抜け漏れチェック

CRUDマトリックスは、各機能がどのデータをどう操作するかを一覧にしたものです。

               商品  在庫  倉庫  ユーザー
在庫検索        R     R     R      -
在庫登録        R     C     R      R
在庫更新        R     U     R      R
在庫削除        R     D     R      R
商品マスタ登録  C     -     -      R

C: Create(作成)
R: Read(参照)
U: Update(更新)
D: Delete(削除)

チェックポイント:

R/U/Dが存在するのにCが存在しないエンティティを探します。

例: 「在庫検索でRがあるのに、在庫を登録するCがない」

こういう場合、在庫を登録する機能を追加する必要があります。

8-2. マスタメンテナンス機能を忘れずに

システムが動くためには、基本データ(マスタ)の登録機能が必要です。

よくあるマスタ:

• 商品マスタ
• 倉庫マスタ
• ユーザーマスタ
• カテゴリマスタ
• 税率マスタ

CRUDマトリックスで「Cがない」ものを見つけたら、マスタメンテナンス機能を追加しましょう。

9. 成果物の整理と伝達

9-1. 成果物一覧

ここまでで次の成果物が揃っています:

1. 企画書
2. 全体像
3. 実装技術
4. 実現したいこと一覧
5. 行動シナリオ一覧
6. 行動シナリオ
7. ワークセット一覧
8. 概念データモデル
9. ラフイメージ/モックアップ
10. 画面遷移図
11. 項目の説明
12. 機能の入出力定義
13. 機能の処理定義
14. 結合ER図

9-2. 資料の並べ方

この順番で資料を並べると、読む人が理解しやすくなります:

全体から詳細へ
WhyからWhatへ
WhatからHowへ

全体 → 詳細
なぜ → 何を → どうやって

9-3. 説明会の実施

資料を作っただけでは不十分です。関係者に対して説明会を開催しましょう。

説明会で話すこと:

1. プロジェクトの目的と背景
2. システムの全体像
3. 主要な機能のデモ(モックアップ)
4. スケジュールと体制
5. 質疑応答

説明会では、一方的に話すのではなく、質問や懸念点を引き出すことが大切です。

10. 要件定義を成功させるコツ

10-1. 完璧を目指さない

要件定義の段階で100%完璧にするのは不可能です。

後から修正が必要になるのは当然のこと。むしろ「修正しやすい要件定義」を心がけましょう。

ポイント:

• 大枠から詰めていく
• 細かすぎる定義は避ける
• 変更を前提に構造化する

10-2. ユーザーと対話を重ねる

要件定義は一度で終わりません。何度もユーザーと対話を重ねることが大切です。

効果的な対話の方法:

• モックアップを見せながら話す
• 具体的なシナリオで確認する
• 「なぜ」を繰り返し掘り下げる

10-3. 図を活用する

文章だけで伝えようとすると、誤解が生まれやすくなります。

活用すべき図:

• 全体像の図
• 画面遷移図
• ER図
• スイムレーン図

図を使うことで、認識のズレを早期に発見できます。

10-4. 優先順位をつける

すべての要求を同時に実現するのは現実的ではありません。

優先順位付けの基準:

1. Must Have: 必須機能(これがないと成立しない)
2. Should Have: 重要だが後回しにできる
3. Could Have: あると嬉しい
4. Won't Have: 今回は対象外

最初のリリースではMust Haveに集中し、後から機能を追加していくアプローチも有効です。

10-5. 技術的な制約を早めに共有する

「できないこと」を後から伝えると、大きな手戻りが発生します。

早めに共有すべきこと:

• 技術的に実現困難なこと
• 予算オーバーになりそうなこと
• 期限に間に合わないこと
• パフォーマンスの問題

正直に伝えることで、代替案を一緒に考えることができます。

10-6. 小さく始めてフィードバックをもらう

いきなり全機能を作るのではなく、小さく始めてフィードバックをもらいましょう。

具体的なアプローチ:

1. コア機能だけのプロトタイプを作る
2. ユーザーに触ってもらう
3. フィードバックを反映
4. 機能を追加
5. 2-4を繰り返す

アジャイル開発的なアプローチです。

11. よくある失敗パターンと対策

失敗パターン1: 画面だけ決めて機能を後回し

症状:

• 画面はきれいだけど動かない
• 実装段階で「これ作れない」と発覚

対策:

• 画面と機能を同時に考える
• 技術的な裏付けを取りながら進める

失敗パターン2: データ設計を軽視する

症状:

• 後からテーブル構造の大幅な変更が必要に
• パフォーマンス問題が発生

対策:

• ER図を丁寧に作る
• データの正規化を意識する
• インデックス設計も考慮する

失敗パターン3: エラー処理を考えない

症状:

• エラーが発生したときの動きが不明
• ユーザーが困惑する

対策:

• 画面遷移図にエラー時の動きを書く
• エラーメッセージを具体的に定義する

失敗パターン4: 非機能要件を忘れる

症状:

• 動くけど遅い
• セキュリティが甘い
• 可用性が低い

対策:

非機能要件もしっかり定義する:

• パフォーマンス要件(応答時間、同時接続数)
• セキュリティ要件(認証、暗号化)
• 可用性要件(稼働時間、バックアップ)
• 保守性要件(ログ、監視)

失敗パターン5: ドキュメントが属人化

症状:

• 担当者しかわからない
• 引き継ぎができない

対策:

• 標準的なフォーマットを使う
• 図を多用してわかりやすくする
• 定期的にレビューする

12. 実践チェックリスト

要件定義を進める際に、このチェックリストを活用してください。

準備フェーズ

• 企画書を確認した
• 全体像を描いた
• 実装技術を決めた
• 実現したいことをリスト化した
• 行動シナリオを作成した
• 概念データモデルを作成した

UI定義フェーズ

• 必要な画面をリストアップした
• 各画面のモックアップを作成した
• 画面遷移図を作成した
• 項目を列挙した
• エラーメッセージを定義した
• デザイナーと連携した

機能定義フェーズ

• 各機能の入出力を定義した
• 処理内容を階層的に整理した
• エラー処理を考慮した
• パフォーマンス要件を確認した

データ定義フェーズ

• エンティティを洗い出した
• 属性を定義した
• リレーションシップを定義した
• ER図を作成した
• 正規化を検討した

仕上げフェーズ

• CRUDマトリックスを作成した
• マスタメンテナンス機能を確認した
• 成果物を整理した
• 説明会の準備をした
• 関係者の合意を得た

13. まとめ

要件定義は、システム開発の成功を左右する重要な工程です。

この記事のポイント:

1. 要件定義 = 依頼主と開発者の合意形成

   • 一方的な要求ではなく、対話を通じて作る

2. 準備が8割

   • 企画、全体像、技術選定をしっかり行う
   • 行動シナリオで利用者の視点を明確にする

3. UI → 機能 → データの順で定義

   • ユーザー視点から始める
   • この順番が最も理解しやすい

4. 図を活用する

   • 全体像、画面遷移図、ER図は必須
   • 文章だけでは伝わらない

5. 完璧を目指さない

   • 大枠から詰めていく
   • 修正を前提に進める

6. 抜け漏れをチェック

   • CRUDマトリックスで検証
   • マスタメンテナンスを忘れない

おわりに

要件定義は、一度で完璧にできるものではありません。何度も試行錯誤を重ねながら、少しずつ精度を上げていくものです。

最初は戸惑うことも多いと思いますが、この記事で紹介した手順を参考に、まずは小さなプロジェクトから始めてみてください。

経験を積むことで、徐々に「要件定義のコツ」が掴めてきます。そして上流工程に関わることで、システム開発全体を俯瞰する視点が身につきます。

エンジニアとしてのキャリアの幅を広げるために、ぜひ要件定義にチャレンジしてみてください!