システム開発では、
「開発途中になって必要な機能が増えた」
「完成したシステムが現場で使われなかった」
「想定していなかった追加費用が発生した」
といった問題が起こることがあります。
こうしたトラブルの原因が、要件定義の段階にあるケースは少なくありません。
IPAも、上流工程の作業不備による手戻りが開発プロジェクトの失敗やシステムトラブルにつながることを指摘しており、要件定義で起こる問題とその解決策を体系的に整理しています。
要件定義で重要なのは、単に「必要な機能を一覧化すること」ではありません。
- なぜシステムを作るのか
- 現在どのような業務をしているのか
- 何に困っているのか
- 誰が利用するのか
- 何をシステム化するのか
- どの程度の性能・セキュリティが必要なのか
- 何を今回作らないのか
まで整理する必要があります。
この記事では、システム開発の要件定義で起こりやすい10の失敗例と、その原因・防止方法を具体的に解説します。
要件定義に失敗すると何が起きる？
要件定義は、システム開発の上流工程に位置します。
その後に基本設計・詳細設計・開発・テストと進むため、要件定義の問題を後から修正すると影響範囲が大きくなります。IPAも、上流工程の取り組みが完成するシステムの品質に大きく影響すると説明しています。
例えば要件定義で、
顧客ごとに閲覧できる担当者を制限する
という権限要件が抜けていたとします。
開発後半で発覚すると、
- DB設計
- API
- 画面表示
- 検索
- 権限制御
- テストケース
まで変更になる可能性があります。
つまり、
要件定義の小さな漏れが、後工程では大きな手戻りになる
ということです。
要件定義でよくある失敗例10選
代表的な失敗を整理すると、次のようになります。
| 失敗例 | 主な問題 |
|---|---|
| 1. 開発目的が曖昧 | 不要な機能が増える |
| 2. 機能から考え始める | 本当の課題を解決できない |
| 3. 現場へのヒアリング不足 | 実際の業務が漏れる |
| 4. 現行業務を確認しない | 例外処理・業務ルールが漏れる |
| 5. 要望をすべて要件にする | 費用・期間が膨らむ |
| 6. 対象範囲が曖昧 | 追加開発・認識違いが起きる |
| 7. 非機能要件を後回しにする | 性能・セキュリティ問題が起きる |
| 8. データ移行を忘れる | リリース直前に問題になる |
| 9. 曖昧な表現を残す | 発注者と開発者で解釈が分かれる |
| 10. 合意・変更管理をしない | 要件がいつの間にか変わる |
それぞれ詳しく見ていきます。
失敗例1｜システム開発の目的が曖昧
典型的なのが、
顧客管理システムを作りたい
在庫管理システムを導入したい
という状態から、そのまま機能を考え始めるケースです。
これだけでは、
なぜシステムが必要なのか
が分かりません。
例えば「顧客管理システムが欲しい」という話でも、本当の課題は、
- 顧客情報が担当者ごとに分散している
- 担当変更時に情報を引き継げない
- 営業案件の進捗を管理者が把握できない
- 毎週Excelを集計している
ことかもしれません。
失敗するとどうなる？
目的が曖昧だと、
- ダッシュボード
- AI分析
- CSV
- 通知
- チャット
など、魅力的に見える機能が次々追加されます。
しかし、完成後に、
いろいろ機能はあるが、最初の業務課題はあまり改善していない
という状態になりかねません。
防ぎ方
最初に次の3つを整理します。
- 現在何に困っているのか
- なぜシステム化するのか
- 導入後どうなれば成功なのか
例えば、
営業担当者ごとに管理している顧客情報を一元化し、毎週2時間かかっている案件集計を不要にする
まで具体化します。
IPAの要件定義ガイドでも、単なるシステム機能だけでなく、ビジネス全体や業務上の要求を把握・分析してビジネス要件へ落とすことが重視されています。
失敗例2｜最初から「欲しい機能」を聞く
要件定義のヒアリングで、
どんな機能が欲しいですか？
と質問すること自体は問題ありません。
しかし、それだけで要件を決めるのは危険です。
例えば利用者から、
CSV出力が欲しい
と言われたとします。
そのまま、
CSV出力機能を開発する
と決めるのではなく、
なぜCSVが必要ですか？
と確認します。
すると、
毎月データを会計システムへ取り込むため
という理由が出てくるかもしれません。
その場合、本当に必要なのはCSVではなく、会計システムとのAPI連携かもしれません。
防ぎ方
機能要望が出たら、
- なぜ必要なのか
- 現在はどうしているのか
- できないと何に困るのか
を確認します。
基本は、
業務課題 → 業務要件 → 機能要件
の順で整理します。
失敗例3｜管理者だけにヒアリングする
要件定義でよくあるのが、
部長・管理者から話を聞いたので業務は理解できた
と判断するケースです。
しかし、管理者が把握している業務と、現場で実際に行われている業務が異なることがあります。
例えば管理者は、
注文内容をExcelへ登録している
と認識していても、現場では、
- 注文メールを確認
- Excelへ入力
- 商品コードを別ファイルから検索
- 在庫表へ転記
- 担当者へメール
- 月末に集計
という複雑な作業をしているかもしれません。
防ぎ方
要件定義では、
- 業務責任者
- 現場担当者
- 管理者
- 情報システム担当
- 必要に応じて経営層
など、立場の異なる関係者へ確認します。
IPAも、ITベンダーやシステム部門だけではなく、実際にシステムを利用してビジネスへ貢献する業務部門のユーザーが主体的に要件定義へ関与する重要性を示しています。
失敗例4｜現在の業務を確認せずシステム設計へ進む
現在の業務、つまりAs-Isを十分理解しないまま、
新しいシステムではこうしましょう
とTo-Beだけを考えるケースです。
例えば予約管理なら、一見、
予約を登録できればよい
と思うかもしれません。
しかし実際には、
- 定員変更
- キャンセル
- 複数人予約
- 当日参加
- 支払い済み・未払い
- 開催中止
- 満席
- キャンセル待ち
などの例外があります。
防ぎ方
まず現状業務を、
誰が → 何を → どの順番で → どのツールを使って
処理しているか整理します。
特に、
通常と違うケースはありますか？
という質問が重要です。
現物を見る
可能であれば、
- Excel
- 紙帳票
- CSV
- マニュアル
- メール
- 既存システム
も確認します。
担当者自身が意識していなかった業務ルールが見つかることがあります。
失敗例5｜利用者の要望をすべて要件にする
ヒアリングすると、多くの要望が出てきます。
例えば、
- AIを使いたい
- グラフも欲しい
- スマホアプリも欲しい
- Slack通知も欲しい
- Excel出力も欲しい
- PDFも欲しい
などです。
すべてを実装すると、当然、
費用・開発期間・保守コスト
が増えます。
防ぎ方
要件に優先順位を付けます。
例えば、
| 優先度 | 意味 |
|---|---|
| Must | 初回リリースに必須 |
| Should | できれば必要 |
| Could | 余裕があれば |
| Later | 将来検討 |
顧客管理システムなら、
Must
- 顧客管理
- 案件管理
- 対応履歴
Should
- CSV出力
Could
- ダッシュボード
Later
- AI営業分析
のように整理します。
重要なのは、
あったら便利
と、
ないと業務が成立しない
を分けることです。
失敗例6｜開発対象範囲を決めない
要件定義では、
何を作るか
だけでなく、
何を作らないか
も重要です。
例えば、
顧客管理システムを開発する
だけでは、
発注者は、
- 顧客管理
- 案件管理
- 請求
- メール配信
まで含むと思っているかもしれません。
一方、開発会社は、
- 顧客管理
- 案件管理
だけだと思っている可能性があります。
防ぎ方
対象・対象外を明記します。
| 項目 | 対象 |
|---|---|
| 顧客管理 | ○ |
| 案件管理 | ○ |
| 対応履歴 | ○ |
| CSV出力 | ○ |
| 請求管理 | × |
| 会計連携 | × |
| AI分析 | 将来 |
対象外を書くことで、
当然入っていると思っていた
という認識違いを減らせます。
失敗例7｜非機能要件を後回しにする
機能要件は整理していても、
- 性能
- セキュリティ
- バックアップ
- 可用性
- ログ
- 運用
などの非機能要件が抜けるケースがあります。
例えば完成後に、
100人同時利用すると遅い
誰でも全顧客情報を見られる
データを削除しても復元できない
と分かれば、大きな問題です。
IPAも、非機能要求についてはユーザーと開発者で認識の行き違いが起こりやすいとして、項目を網羅的に確認できる「非機能要求グレード」を公開しています。
防ぎ方
最低限、次を確認します。
- 利用人数
- 最大同時利用人数
- 利用時間
- データ量
- 画面表示速度
- バックアップ
- 権限
- 操作ログ
- 個人情報
- 対応端末
- 対応ブラウザ
- 障害時の復旧
例えば、
主要画面は通常3秒以内
DBは1日1回バックアップ
一般ユーザーは他部署の顧客を閲覧不可
のように、できるだけ具体化します。
失敗例8｜既存データの移行を後から考える
新しいシステムを作ることばかり考え、
今のExcelデータをどうするのか
を忘れるケースです。
例えば、
- 顧客20,000件
- 案件100,000件
- Excel50ファイル
- 過去10年分
があれば、データ移行だけでも大きな作業です。
さらに、
- 同じ顧客が複数登録
- 日付形式が違う
- 必須項目が空欄
- 担当者ごとにExcel形式が違う
などの問題があるかもしれません。
防ぎ方
要件定義で、
- 移行対象
- 件数
- 移行元
- 対象期間
- データ形式
- データクレンジング担当
- 移行タイミング
- 移行後の確認方法
を整理します。
例えば、
顧客20,000件、過去5年分を移行。データクレンジングは発注者側で実施。
まで明確にします。
失敗例9｜曖昧な表現を残す
要件定義書で、
使いやすい画面にする
高速に表示する
十分なセキュリティを確保する
と書いても、人によって解釈が変わります。
例えば「高速」について、
発注者は、
1秒以内
を想像し、開発会社は、
5秒なら十分
と考えるかもしれません。
防ぎ方
できるだけ確認可能な条件にします。
悪い例
検索結果を高速に表示する。
改善例
通常利用時、顧客検索結果を3秒以内に表示する。
悪い例
権限を適切に管理する。
改善例
一般ユーザーは自部署の顧客のみ閲覧可能とする。管理者は全部署を閲覧できる。
このように、
完成後に「満たしたかどうか」を判断できる表現
へ変えます。
失敗例10｜決めた要件を合意・管理しない
要件定義では、打ち合わせを重ねるうちに内容が変わります。
例えば、
1回目：
CSVは不要
2回目：
CSVが欲しい
3回目：
管理者だけCSVを使う
となることがあります。
しかし議事録・要件一覧を更新していないと、
- 発注者
- PM
- 開発者
- テスター
で認識が分かれます。
防ぎ方
要件にはIDを付けます。
例えば、
| ID | 要件 | 優先度 | 状態 |
|---|---|---|---|
| FR-001 | 顧客登録 | Must | 確定 |
| FR-002 | 顧客検索 | Must | 確定 |
| FR-003 | CSV出力 | Should | 検討中 |
変更があれば、
- 変更内容
- 理由
- 影響範囲
- 追加工数
- スケジュール影響
- 承認者
を記録します。
IPAの要件定義ガイドでも、ビジネス要求・システム化要求だけでなく「要件定義マネジメント」が重要領域として整理されています。
要件定義の失敗を防ぐ7つのポイント
ここまでの失敗例を踏まえると、対策は次の7つにまとめられます。
1．目的から始める
最初に、
何を作るか
ではなく、
なぜ作るか
を決めます。
2．現在の業務を見る
業務担当者へのヒアリングだけでなく、Excel・帳票・既存システムなども確認します。
3．現場担当者を参加させる
管理者だけでなく、実際にシステムを使う担当者も参加します。
4．業務要件と機能要件を分ける
例えば、
業務要件
全拠点の在庫を本社から確認できる。
機能要件
拠点別在庫一覧を表示する。
と分けます。
5．対象外も決める
「今回作らないもの」を明記します。
6．非機能・移行・運用も確認する
機能一覧だけで要件定義を終わらせないことが重要です。
7．要件をレビュー・合意する
業務担当・管理者・開発会社などで確認し、
この内容を前提に設計へ進む
という状態を作ります。
IPAの要件定義ガイドは、要件定義で発生しやすい問題を48の問題と128の解決ポイントとして体系化しており、要件定義を単なる文書作成ではなく継続的な整理・合意形成として扱っています。
【チェックリスト】要件定義で失敗しないための確認項目
要件定義が終わる前に、次を確認します。
【目的】
□ なぜシステムを作るのか明確か
□ システム導入後のゴールが明確か
□ 数値目標があれば整理したか
【業務】
□ 現在の業務フローを確認したか
□ 現場担当者へヒアリングしたか
□ Excel・帳票等を確認したか
□ 例外業務を確認したか
【要件】
□ 業務要件を整理したか
□ 機能要件を整理したか
□ 優先順位を付けたか
□ 今回の対象外を決めたか
【非機能】
□ 利用人数を確認したか
□ 性能要件を確認したか
□ 権限を確認したか
□ セキュリティを確認したか
□ バックアップを確認したか
□ ログを確認したか
【データ】
□ 管理するデータを整理したか
□ 既存データ件数を確認したか
□ データ移行範囲を決めたか
【外部連携】
□ 他システムとの連携を確認したか
□ API・CSV連携を確認したか
【運用】
□ 誰がユーザーを管理するか決めたか
□ 誰がマスタを管理するか決めたか
□ 障害時の対応方法を確認したか
【合意】
□ 未決事項を一覧化したか
□ 要件変更の管理方法を決めたか
□ 関係者で要件をレビューしたか
□ 発注者と開発会社で認識を合わせたか
要件定義で100％の漏れをなくすのは難しい
要件定義では、
すべてを最初から完璧に決める
ことを目標にしすぎる必要はありません。
実際に画面イメージを作ったことで、
この操作も必要だった
と気づくこともあります。
重要なのは、
分からないものを分からないまま確定扱いしないこと
です。
例えば、
| ID | 未決事項 | 担当 | 期限 |
|---|---|---|---|
| Q01 | CSV形式 | 業務担当 | 8/10 |
| Q02 | 移行対象期間 | 管理者 | 8/15 |
| Q03 | 権限パターン | 開発会社・業務担当 | 8/20 |
のように管理します。
「未決であること」が見えていれば、後から計画的に決められます。
小規模システムでも要件定義は必要？
必要です。
ただし、数十ページの要件定義書を作る必要があるとは限りません。
例えば小規模な予約管理システムなら、
- 開発目的
- 利用者
- 業務フロー
- 必要機能
- 画面一覧
- データ項目
- 権限
- 非機能要件
- 対象外
- 未決事項
を数ページ・スプレッドシートなどで整理する方法もあります。
IPAも、中小企業向けに詳細すぎる要件定義資料ではなく、ポイントを絞った実践的な入門資料を公開しています。
大切なのは文書量ではなく、
発注者と開発者が同じ完成イメージを持てること
です。
要件定義で手戻りが発生したときはどうする？
要件漏れが見つかった場合、
とりあえず追加してください
と進めるのではなく、一度影響範囲を確認します。
例えば新しく、
承認機能が必要
となった場合、
- 画面
- DB
- API
- 権限
- 通知
- 操作ログ
- テスト
- スケジュール
への影響を確認します。
そのうえで、
- 今回追加する
- 次期開発へ回す
- 別の方法で代替する
を判断します。
要件変更そのものが悪いわけではありません。
問題なのは、
影響を確認せず、変更を積み重ねること
です。
要件定義を開発会社へ丸投げしてはいけない理由
発注者側が、
システムのことは分からないので全部お願いします
となるケースがあります。
技術については開発会社へ任せられます。
しかし、
- 現在どのような業務をしているか
- 何に困っているか
- どの業務ルールが必要か
- 何を優先するか
を最も知っているのは発注者側です。
IPAも、システム要件を定義するうえでユーザー企業・業務部門が主体的に関わる必要性を強調しています。
そのため理想は、
業務の専門家である発注者
と、
システム化の専門家である開発会社
が一緒に要件を整理することです。
要件定義の失敗に関するよくある質問
要件定義で最も多い失敗は何ですか？
一つに限定することはできませんが、特に注意したいのは「目的・業務を十分に整理せず、機能一覧から開発を始めること」です。
機能が完成しても、元の業務課題を解決できない可能性があります。
要件定義で手戻りを完全になくせますか？
完全になくすのは難しいでしょう。
重要なのは、重要な要件を早い段階で発見し、変更が発生した場合に影響範囲を管理することです。
要件定義は誰が責任を持つべきですか？
開発会社だけに任せるのではなく、発注者側の業務担当・責任者も主体的に関与する必要があります。
業務上の要求と、技術的な実現方法を双方で整理します。
要件定義書を作れば失敗を防げますか？
要件定義書を作るだけでは不十分です。
重要なのは、
- 内容が具体的か
- 関係者が確認しているか
- 未決事項が管理されているか
- 要件変更が反映されているか
です。
要件変更は失敗ですか？
必ずしも失敗ではありません。
業務理解が深まった結果、より適切な要件へ変更されることもあります。
変更理由・影響・費用・スケジュールを管理できていることが重要です。
hiro-dev-labの要件定義・業務システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなく業務整理・要件定義から対応しています。
例えば、
- 現状業務のヒアリング
- 既存Excel・帳票の確認
- 業務フロー整理
- 課題の洗い出し
- 業務要件整理
- 機能要件整理
- 非機能要件整理
- システム化範囲の整理
- データ・権限設計
- 外部システム連携の検討
- Java・Python・TypeScriptを用いたWebシステム開発
などを検討できます。
例えば、
Excel管理が限界なのでWebシステム化したいが、必要な機能までは整理できていない
という段階でも、
現状業務 → 課題 → 業務要件 → 機能要件 → 設計・開発
という順番で整理できます。
要件定義の失敗を防ぐポイントは「作るもの」より「解決すること」から考えること
要件定義で失敗を防ぐために重要なのは、
どんな画面を作るか
どんな機能を作るか
から始めないことです。
まず、
- なぜシステムが必要なのか
- 現在どのような業務なのか
- 何に困っているのか
- どの状態へ変えたいのか
- 誰が利用するのか
を整理します。
そこから、
業務課題 → 業務要件 → 機能要件 → 非機能要件
へ落とし込みます。
そして、
- 優先順位
- 対象外
- データ移行
- 運用
- 未決事項
- 要件変更
まで管理します。
要件定義は、立派な資料を作るための工程ではありません。
発注者と開発者が「何を、なぜ、どの条件で作るのか」を合意するための工程です。
「システム化したいが要件が整理できていない」
「開発途中の手戻りをできるだけ減らしたい」
「現在のExcel業務を整理してシステム化したい」
「要件定義から設計・開発まで相談したい」
といった段階からでも、業務整理を進めることができます。
要件定義・業務システム開発について相談する