先に要点
- 要件定義で最低限決めるべきなのは、画面一覧だけではありません。目的、対象範囲、業務ルール、権限、例外処理、外部連携、検収条件、変更ルールまでそろえて初めて揉めにくくなります。
- 小規模案件でも、`何を作るか` より `何を今回やらないか`、`誰が判断するか`、`どこで完了とみなすか` を決めておく方が効きます。
- 要件定義は、全部を細かく決め切る作業というより、あとで認識ずれが大きくなる境界線を先にそろえる作業として考えると進めやすいです。
受託開発や社内システムの相談で、あとからかなり揉めやすいのが「それ、最初に決めていませんでしたっけ？」という話です。
画面のイメージは合っていても、権限、例外処理、CSV、通知、既存データ移行、検収条件が曖昧なまま進むと、終盤で一気に苦しくなります。
特に小規模案件では、要件定義を大げさにやりたくなくて、早めに作り始めたくなることがあります。
ただ、必要最低限の整理を飛ばすと、あとで見積もり、仕様変更、納期、検収で余計に重くなります。
この記事では、要件定義で最低限そろえておきたい項目を、受託開発やWebシステムの実務に寄せて整理します。
見積もりが外れやすい理由を先に見たい場合は、システム開発の見積もりはなぜ外れやすい？ズレる理由と実務での防ぎ方を整理 も近い話です。
途中で入る変更をどう扱うかまで見たい場合は、追加開発と仕様変更の違い｜受託開発で見積もり直しになる判断基準 もあわせて読むとつながりやすいです。
この記事では、2026年4月22日時点でIPAの公開情報を確認しながら整理しています。IPAのDX SQUAREでは、要件定義は企画の後、基本設計の前に行う上流工程であり、要求を関係者と合意して要件としてまとめる工程だと説明されています。また、IPAのモデル契約見直しでは、再構築案件で現行仕様の調査にコストと時間が要ることも明示されています。ここでは法的助言ではなく、受託開発で揉めにくくするための実務上の考え方としてまとめます。
結論：要件定義は「全部決める」より「揉める境界線を先にそろえる」
要件定義と聞くと、分厚い要件定義書を最初から完璧に作る作業に見えがちです。
でも実務では、そこまできれいに始められる案件ばかりではありません。
大事なのは、あとで揉めやすい境界線を先にそろえることです。
たとえば次のような部分です。
- 今回の対象範囲と対象外
- 誰が何をできるか
- 正常系だけでなく、例外時にどうするか
- 既存データや外部サービスをどう扱うか
- 何をもって完了とするか
- 途中変更が出たら、誰がどう判断するか
ここが曖昧だと、設計、実装、テスト、検収のどこかで必ず認識ずれが表面化します。
逆にここがそろっていれば、細部が後で詰まっても大事故になりにくいです。
要件定義で最低限決めたい10項目
まずは全体像です。小規模案件でも、最低限このくらいはそろえておくとかなり安定します。
| 項目 | 最低限そろえたいこと | 曖昧だと起きやすいこと |
|---|---|---|
| 目的 | 何を改善したいのか、何ができれば成功か | 便利そうな機能を足し続けて、ゴールがぶれる |
| 対象範囲 | 今回やること、やらないこと、次フェーズへ回すもの | 「それも入っていると思っていた」が起きる |
| 利用者と権限 | 誰が使うか、誰が見られるか、承認できるか | 管理者だけの想定が途中で崩れる |
| 画面・入出力 | 画面、入力項目、一覧、検索、帳票、CSV、通知 | 後から出力や絞り込みが増える |
| 業務ルール | 必須条件、計算、承認条件、状態遷移 | 見た目は同じでも動きが違う |
| 例外処理 | エラー時、差し戻し、取消、重複、期限切れ時の扱い | 正常系だけできて運用で詰まる |
| 外部連携・既存データ | API、メール、決済、在庫、移行対象、手入力との境界 | 終盤で癖の強い連携が見つかる |
| 非機能 | 性能、稼働時間、セキュリティ、バックアップ、監査ログ | 動くが運用できないシステムになる |
| 検収条件 | 何を確認できたら完了か、誰が確認するか | 納品後にゴールがずれる |
| 変更ルール | 途中変更の判断者、費用、納期、記録の残し方 | 仕様変更と不具合修正が混ざる |
1. 目的を決める
最初に必要なのは、何を作るかより、何を改善したいかです。
ここが曖昧だと、要件が増えても削っても判断できません。
たとえば問い合わせ管理システムなら、
- メールの見落としを減らしたい
- 担当者ごとの対応状況を見えるようにしたい
- 二重返信を防ぎたい
のように、目的を業務上の困りごとで置く方が後で判断しやすいです。
逆に、管理画面を作る 検索を強くする のような機能名だけで始めると、何のための機能かがぶれやすいです。
目的が決まっていれば、「今回は返信管理を優先し、FAQ連携は次フェーズ」といった線引きもしやすくなります。
2. 対象範囲と対象外を決める
要件定義で一番効くのは、実は対象外を決めることです。
やることだけを書いても、やらないことが書かれていないと期待が膨らみます。
最低限、次は決めておくと安全です。
- 今回作る機能
- 今回は作らない機能
- 将来やりたいが今回は入れない機能
- 手作業で運用する部分
- 他システムや他部署の責任範囲
たとえば「問い合わせ管理を作る」案件でも、
- 問い合わせ受付は今回やる
- 自動返信は今回やる
- 顧客管理との自動連携は今回はやらない
- 売上分析レポートは別案件
くらいまで分けておくと、かなり揉めにくいです。
3. 利用者と権限を決める
小規模案件ほど、権限が後回しになりがちです。
でも実際には、権限が変わると画面、一覧、通知、承認、ログ、テストが全部変わります。
最低限そろえたいのは次です。
- どの役割の人が使うか
- どの情報を見られるか
- 編集、削除、承認、出力ができるのは誰か
- 退職者や異動時に誰が権限を管理するか
特に、管理者だけが使う予定だった が途中で崩れる案件はかなり多いです。
店舗担当、外注先、経理、上長などが入ると、急に権限設計が重くなります。
4. 画面・入力・出力を決める
画面一覧だけでは足りません。
何を入力して、どこに表示して、何を出力するかまで見て初めて要件になります。
見落としやすいのは次のような部分です。
- 一覧の検索条件
- 並び順
- CSV出力
- 通知メールの内容
- 添付ファイル
- 履歴表示
- スマホ前提かPC前提か
たとえば一覧画面1つでも、検索条件が増えるだけで工数は結構変わります。
表示するだけなのか、ダウンロードできるのか、個人情報を含むのかでも話が変わります。
5. 業務ルールと例外処理を決める
正常系だけ見ていると、運用が始まった瞬間に詰まります。
実務では、むしろ例外時の扱いで困ることが多いです。
最低限、次のような問いには答えを持っておく方が安全です。
- 必須入力が欠けたらどうするか
- 同じ申請や注文が重複したらどうするか
- 承認後に差し戻しできるか
- 締切後の修正はどう扱うか
- 削除か無効化か
- 取消時に通知や在庫や請求へ影響するか
ここを決めずに進むと、あとで「業務的にはこうしたい」が大量に出てきます。
しかも例外処理は、画面1つの追加より設計とテストが重くなりやすいです。
6. 外部連携と既存データを決める
IPAのモデル契約見直しでも、再構築に入る前に現行システム調査が必要で、そこにはコストと時間がかかると注意喚起されています。
これは本当にその通りで、現行踏襲のつもりでも、現行仕様が分からない案件はかなり重いです。
特に次は早めに棚卸しした方が安全です。
連携あり の一言だけで進むと危ないです。
認証方式、更新タイミング、失敗時の再送、テスト環境の有無、既存データの欠損まで含めて確認が必要になります。
7. 非機能を決める
IPAのDX SQUAREでも、要件定義では機能面だけでなく、性能、レスポンスタイム、セキュリティのような非機能面も分析すると整理されています。
ここを飛ばすと、動くけど現場で使いにくい システムになりやすいです。
最低限、次は決めておきたいです。
小規模サイトでも、問い合わせフォーム、管理画面、CSV出力、メール通知があるなら、セキュリティとバックアップの話は避けにくいです。
保守や運用の話につながるので、Webサイト保守の月額費用に含める範囲は？受託開発の保守費用と契約の決め方 も近い論点です。
8. 検収条件を決める
要件定義で意外と後回しにされやすいのが 検収 です。
でも、何をもって完了とするかが決まっていないと、納品後にゴールがずれます。
最低限、次は言葉にしておくと助かります。
- 誰が確認するか
- 何を確認したら完了か
- テストシナリオはどこまで用意するか
- デモ確認でよいのか、実データ検証が必要か
- 検収期間は何日か
- 軽微な不具合があった場合の扱い
検収そのものの進め方や、納品後に揉めやすい確認項目をもう少し具体的に見たい場合は、検収とは？受託開発で納品後に揉めない確認項目と進め方 もあわせて読むとつながりやすいです。
ここがないと、「使ってみたら想像と違った」がそのまま検収差し戻しになりやすいです。
要件の問題なのか、不具合なのか、追加要望なのかも分かれにくくなります。
9. 変更ルールを決める
要件定義をしても、途中変更は普通に起きます。
だからこそ、変更が起きない前提ではなく、変更が起きたときの扱いを決めておく方が現実的です。
最低限、次を決めておくとかなり違います。
- 変更依頼は誰が出せるか
- 口頭だけで進めないか
- 影響調査を誰がやるか
- 費用、納期、検収条件への影響をどう残すか
- 軽微修正、不具合修正、仕様変更、追加開発をどう分けるか
ここは、追加開発と仕様変更の違い｜受託開発で見積もり直しになる判断基準 の話とかなりつながります。
要件定義で境界線が弱いと、変更管理も必ず弱くなります。
小規模案件で実際に使いやすい確認順
分厚い要件定義書を最初から作れない案件でも、次の順で確認すると進めやすいです。
- 何を改善したいのか
- 誰が使うのか
- 今回どこまでやるのか
- 画面、入力、出力は何か
- 例外時にどうするか
- 既存データや外部連携はあるか
- 何をもって完了とするか
- 途中変更が出たらどう扱うか
この順番の良いところは、機能の細かい話に入る前に、目的と範囲をそろえやすいことです。
先に画面設計から入ると、あとで目的や対象外がぶれて、余計な議論が増えやすいです。
よくある失敗
現行踏襲と言いながら現行仕様が分かっていない
かなり多いです。
「今のシステムと同じでいいです」と言われても、実際には現場ごとの運用、Excel補助、口頭ルールが混ざっています。
現行調査なしで始めると、再現すべき業務が後から出てきます。
対象外を書いていない
やることは書いてあるのに、やらないことが書いていないと、期待値が膨らみます。
特にCSV、権限、通知、帳票、移行、運用サポートは後から増えやすいです。
例外処理が抜けている
通常の登録や承認だけ定義されていて、差し戻し、取消、期限切れ、重複、権限エラーが抜けていると、リリース直前に重くなります。
検収条件がない
完了の定義が弱いと、納品後に「ここまで入っていると思っていた」が起きやすいです。
検収は最後の話ではなく、要件定義の時点で置いておいた方が安全です。
まとめ
要件定義で最低限決めることは、機能一覧だけではありません。
目的、対象範囲、利用者と権限、画面と出力、業務ルール、例外処理、外部連携、非機能、検収条件、変更ルールまでそろえて、初めてあとで揉めにくくなります。
特に小規模案件では、全部を分厚く書くことより、何を今回やるか、何をやらないか、誰が判断するか、どこで完了とするか を先にそろえる方が効きます。
要件定義は面倒な前置きではなく、あとで見積もり、仕様変更、検収で苦しまないための土台です。