要件定義書にハンコを押したあとで、「あれ、これはどういう意味だったのだろう」と気づく。システム開発を発注する方なら、一度は冷や汗をかきそうな場面です。
「要件定義書を承認してしまったが、中身をよく理解していなかった。後から直せるのか」
先に結論をお伝えします。承認したあとでも、直せる可能性は十分にあります。ただし、直し方には「解釈をすり合わせる」「変更として相談する」「次の段階に回す」の3通りがあり、気づくのが早いほど選択肢が広く、費用も小さく済みます。この記事では、承認後に気づいたときの動き方を、開発会社へそのまま聞ける質問例とあわせて整理します。
要件定義書を承認すると何が確定するのか
まず「承認」の意味を押さえましょう。要件定義（＝作るものを文章で決める工程）の成果物である要件定義書は、その後の設計・開発・見積もりの土台になります。承認は「この内容で進めてください」という合意の記録です。
ただし、承認した瞬間に何も変えられなくなるわけではありません。多くの開発では、承認後に変更が出ること自体は想定されており、変更を扱うための手順（変更管理）が用意されています。
システム開発の要件を定義する責任は、使う側である発注者にあると、公的機関も整理しています。
📰 出典：IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版」
これは「発注者が全部分からなければならない」という意味ではありません。分からないまま進めず、分かるまで開発会社に説明を求めることも、発注者の大切な役割だということです。
承認後に「分かっていなかった」と気づく3つのパターン
気づく場面は、おおよそ次の3つに分かれます。どれに当たるかで、取るべき動きが変わります。
| パターン | 例 | 直しやすさ |
|---|---|---|
| ① 書いてあるが、読み違えていた | 「承認フロー」が自分の想像していた流れと違った | 解釈のすり合わせで済むことが多い |
| ② 書いていない（書き漏れ） | 例外処理や帳票の出力形式が載っていない | 追加の相談になりやすい |
| ③ 書いてあるとおりで、業務に合わない | 現場の実態と違う前提で書かれていた | 内容次第。変更の相談が必要 |
①の「読み違い」は、その場で確認すれば傷が浅い
専門用語や図の読み方を取り違えただけなら、書かれている内容自体は変わりません。開発会社に「ここはこういう意味ですか」と確認し、認識が合えば何も直さずに済みます。ずれていたときも、設計前なら修正の手間は小さくて済みます。
②の「書き漏れ」は、範囲内か範囲外かで扱いが変わる
書かれていない要望は、見積もりに含まれていないのが一般的です。ただし、書かれていなくても当然に含まれる機能（例：ログイン後にログアウトできる）もあります。範囲内かどうかの判断は、要件定義書の記載と見積もりの前提を並べて確認します。判断に迷う場合の考え方は、次の記事でも解説しています。
③の「業務に合わない」は、早く伝えるほど安く直せる
実際の業務とずれていると気づいたら、黙って進めないことが一番大切です。開発が進むほど、直す箇所が増えるためです。
気づいたらすぐやる4つの対処
対処1：どこが分からないのかを、具体的な箇所で特定する
「全体がよく分からない」では相談しにくいものです。まず、要件定義書を読み返して、引っかかる箇所に印をつけましょう。次の3種類に分けておくと、後の話が早くなります。
- 意味が分からない言葉や図
- 自分の業務の実態と違う記述
- 書かれているはずなのに見当たらない内容
対処2：今どの工程にいるかを開発会社に確認する
直す費用は、工程が進むほど大きくなりやすいと言われています。設計前なのか、開発中なのか、すでに画面ができているのかで、取れる手が変わります。開発会社に現在の工程を聞き、気づいた点がどの工程の成果物に影響するかを教えてもらいましょう。
対処3：「承認を取り消したい」ではなく「確認したい点がある」と伝える
最初から承認のやり直しを求めると、話が身構えたものになりがちです。まずは「承認後に確認したい点が見つかったので、時間をください」と伝えるほうが、建設的に進みます。開発会社にとっても、後から大きなずれが出るより、早い段階で分かるほうが助かるのが普通です。
「承認後でも、気づいた時点で教えていただくほうが、手戻りが小さく済みます。遠慮なく声をかけてください」
対処4：変更するなら、費用・期間・範囲を文書で確認する
内容を変えることになったら、口頭で済ませず、次の3点を文書で残しましょう。
- 何を変えるのか（変更前と変更後）
- 費用と納期への影響
- 変更後の要件定義書の版と、承認者
契約書に変更管理の取り決めがある場合は、その手順に従います。契約や費用の扱いは個別の事情で変わるため、判断に迷うときは弁護士や専門家へ相談してください。モデル契約書の考え方は、経済産業省が公開しています。
やりがちな失敗
- 気づかないふりをして進める：後で大きな手戻りになりやすく、費用の話も難しくなります
- メールや口頭だけで「たぶん大丈夫」とする：後で認識が食い違ったときに確認できません
- 開発会社の説明を一度聞いただけで納得したことにする：自分の言葉で言い直して、相手に確認してもらうと安心です
- 現場の担当者に見せずに承認する：実際に使う人が確認すれば、業務とのずれを早く見つけられます
次の案件で繰り返さないための承認前の工夫
今回の経験は、次の案件に活かせます。承認の前に、次のことを習慣にしておくと安心です。
- 要件定義書の内容を、自分の言葉で1枚に要約し、開発会社に見てもらう
- 現場の担当者に読んでもらい、業務と合っているか確認してもらう
- 分からない言葉は、承認前にその場で聞く
- 「承認」の条件（誰が・いつまでに・何を確認するか）を最初に決めておく
発注者がやることチェックリスト
- ☐ 引っかかる箇所に印をつけ、「意味」「実態との違い」「抜け」に分けた
- ☐ 開発会社に、現在の工程を確認した
- ☐ 「承認後に確認したい点がある」と、早めに伝えた
- ☐ 確認した内容と回答を、メールや議事録に残した
- ☐ 内容を変更する場合、費用・納期・範囲への影響を文書で確認した
- ☐ 変更後の要件定義書の版と、承認者を決めた
- ☐ 次回に向けて、承認前の確認手順を社内で決めた
開発会社への質問例
- 「要件定義書の◯◯の部分について、承認後に自分の理解と違う点が見つかりました。確認させていただけますか？」
- 「現在はどの工程ですか。この点を直す場合、どの成果物に影響しますか？」
- 「この変更は、現在の見積もりの範囲内でしょうか。範囲外の場合、費用と納期への影響はどのくらいですか？」
- 「変更した内容は、要件定義書の新しい版として残していただけますか？」
- 「今後、要件定義書の承認前に、内容を確認する場を設けていただくことは可能ですか？」
まとめ：承認後でも、気づいた時点で動けば間に合うことが多い
要件定義書を承認したあとでも、すべてが確定するわけではありません。大切なのは、次の4つです。
- 分からない箇所を具体的に特定する
- 今の工程を確認する
- 「確認したい点がある」と早めに伝える
- 変更するなら、費用・期間・範囲を文書で残す
気づいた自分を責める必要はありません。専門用語の並ぶ文書を、一度で完全に理解できる方はまれです。次の一歩として、まずは引っかかる箇所に印をつけるところから始めてみてください。
あわせて読みたい関連記事
