先に要点
- 受託開発では、`要件定義書という名前の大きな資料` がなくても進められる案件はあります。
- ただし、何も残さず進めてよいわけではなく、目的、対象範囲、役割分担、画面や入出力、検収条件、変更時の扱いなどは最低限どこかに合意として残す必要があります。
- 実務では、要件定義書の有無より、`あとで誰でも確認できる形で合意事項が残っているか` の方が重要です。
受託開発やWeb制作の相談で、意外と多いのが 要件定義書までは作れないけれど、開発は進めたい という案件です。
小規模案件、短納期案件、現場改善の延長のような案件では、最初から分厚い資料を作る時間も体力もないことがあります。
実際、要件定義書という名前の文書がなくても進む案件はあります。
でもその一方で、資料がないまま走り出した結果、最後に全部揉める という失敗もかなり多いです。
この記事では、要件定義書がなくても進められるのか、進めるなら最低限何を合意として残すべきかを、受託開発の実務に寄せて整理します。
要件定義で最低限決める項目そのものを先に見たい場合は、要件定義で最低限決めることは？受託開発であとから揉めやすい項目を整理 も近い話です。
提案段階で前提条件をどう書くかまで見たい場合は、提案書の前提条件とは？受託開発であとから揉めない書き方 もつながります。
この記事では、2026年4月22日時点で IPA の DX SQUARE と情報システム・モデル取引・契約書 第二版の公開情報を確認しながら整理しています。IPA でも、要求を関係者と合意して要件としてまとめることや、契約の段階で仕様や確認方法を共通理解のもとで対話することが重視されています。ここでは法的助言ではなく、受託開発であとから揉めにくくするための実務上の整理としてまとめます。
結論: 要件定義書がなくても進められるが、合意事項は残さないと危ない
先に結論を書くと、要件定義書という名前の1本の文書 がなくても進められる案件はあります。
ただし、次のどちらかは必要です。
- 要件定義書として1つにまとまった文書がある
- 議事録、提案書、見積もり、チケット、画面案、確認表などに、必要な合意事項が分散していても残っている
危ないのは、資料名の問題ではありません。
何が合意済みで、何が未確定かが後から追えない状態 がいちばん危ないです。
要件定義書がなくても進みやすいケース
次のような案件は、必ずしも分厚い要件定義書がなくても進めやすいです。
- 既存サイトの軽微改修
- 画面数が少ない社内ツール
- 対象範囲がかなり限定されている機能追加
- 関係者が少なく、判断者が明確
- 既存運用が比較的単純
- 仕様変更が少なく、短期間で完了する
たとえば 問い合わせフォームを1本追加する 管理画面に項目を1つ増やす CSV出力を1種類追加する くらいの話なら、
別紙の要件定義書を作らなくても、議事録と確認表で十分回ることがあります。
逆に、要件定義書なしで進めると危ないケース
次のような案件は、文書の粒度を上げた方が安全です。
- 利用者や権限が複数ある
- 業務ルールが複雑
- 既存データ移行がある
- 外部連携がある
- 例外処理が多い
- 検収条件で揉めそう
- 発注側と受注側の担当者が複数いる
- 途中で意思決定者が変わる可能性がある
特に危ないのは、打ち合わせでは話した で進めてしまうケースです。
その場にいた人の頭の中では通じていても、2週間後、1か月後、担当交代後にはかなりの確率でずれます。
最低限残すべき合意事項
要件定義書がなくても、最低限次は残しておく方が安全です。
| 項目 | 最低限残したいこと | 抜けると起きやすいこと |
|---|---|---|
| 目的 | 何を改善したいか、何ができれば成功か | 機能が増えても削っても判断できない |
| 対象範囲 | 今回やること、やらないこと、次回へ回すこと | 「それも含むと思っていた」が起きる |
| 利用者と役割 | 誰が使うか、誰が確認するか、誰が承認するか | 権限や確認フローが後から崩れる |
| 画面・入出力 | 画面、入力項目、一覧、検索、CSV、通知 | 帳票や出力が終盤で増える |
| 業務ルール | 必須条件、状態遷移、例外時の扱い | 見た目は合うが動きが違う |
| 外部条件 | 既存データ、API、素材、アカウント、提供物 | 依頼待ちや調査待ちが膨らむ |
| 検収 条件 | 何を確認できたら完了か、誰が確認するか | 納品後にゴールが変わる |
| 変更時の扱い | 追加要望、前提変更、見積もり直しのルール | 仕様変更とサービスが混ざる |
要するに、後で揉めやすい境界線 だけは残しておく必要があります。
どこに残せばよいのか
要件定義書がなくても、次のような組み合わせで残せます。
- 提案書
- 見積書の前提条件
- 打ち合わせ議事録
- チケット管理ツール
- 画面案やワイヤーフレーム
- テスト観点一覧
- 本番前の確認表
実務では、1本の要件定義書に全部を閉じ込めるより、
提案書で範囲 議事録で決定事項 チケットで未確定事項 確認表で検収条件 のように分けて運用することも多いです。
ただしこの運用をするなら、最終的に何が最新の合意か を誰でも追えるようにしておく必要があります。
議事録だけで代替するときの注意点
議事録だけで進める場合、特に次の書き方が大事です。
- 決まったこと
- 未決のこと
- 依頼側が持ち帰ること
- 受注側が調査すること
- 次回までに出すもの
- 仕様変更になりそうな論点
よくある失敗は、議事録が 話した内容の要約 で終わっていることです。
それだと、誰が何を決めたか、どこが未確定かが見えません。
最低でも、議事録には次のような形で残す方が安全です。
決定: 管理画面の利用者は管理者と店舗責任者の2ロールとする
未決: CSV出力の列構成は次回までに依頼側で確認
対象外: 売上分析レポートは今回範囲外とする
前提: 既存顧客データは CSV で提供される前提とする
このくらい書いてあれば、かなり実務で使いやすくなります。
あとで揉めやすい抜け漏れ
1. 対象外が書かれていない
やることだけ書いて、やらないことが書かれていないと、期待がふくらみます。
小規模案件ほど、このくらいもやってくれると思っていた が起きやすいです。
2. 誰が判断するかが書かれていない
仕様で迷ったとき、確認担当や承認者が曖昧だと止まります。
止まった結果、現場判断で進めてあとから差し戻し、という流れが起きやすくなります。
3. 検収条件がない
動いたかどうかだけでなく、どの画面、どの入力、どの通知、どの出力を確認対象にするかを残しておかないと、
納品後に ここも見てほしい これは想定と違う が増えます。
4. 変更時の扱いがない
実務では、途中変更そのものは普通に起きます。
問題は、変更が起きたときに どこから別見積か 納期にどう影響するか を残していないことです。
小規模案件で現実的な残し方
分厚い資料を毎回作れないなら、次の形がかなり現実的です。
- 最初にA4 1枚でもよいので、目的・対象範囲・対象外を書く
- 打ち合わせごとに、決定事項と未決事項を議事録で残す
- 画面や出力は、ワイヤーやサンプルで確認する
- 検収条件はリリース前に別紙の確認表にする
- 追加要望は議事録やチケットで
別論点として分ける
これなら、要件定義書はないが、合意事項は残っている 状態を作れます。
まとめ
要件定義書がなくても進められる案件はあります。
ただしそれは、文書が不要という意味ではありません。
大事なのは、要件定義書という名前より、目的、範囲、役割、検収、変更時の扱いが後から確認できるか です。
受託開発であとから揉めやすいのは、資料の見た目が薄いことより、合意事項が散らばっていて追えないことです。
最初から完璧な要件定義書を作れない案件でも、最低限の合意事項を残すだけで、かなり事故は減らせます。