要件定義書を承認して開発が進み、いざ画面を触ってみたら「この機能がない」。開発会社に伝えると「要件定義書に書かれていないので対象外です」と言われてしまい、納得がいかない。システム開発の現場で、とても多い食い違いです。
「要件定義書に書いていないが、当然入っていると思っていた機能が入っていないと言われた。これは誰の責任になるのか」
先に結論をお伝えします。責任の所在は「書いていないこと」だけでは決まらず、「契約の範囲」「やり取りの記録」「その機能がなくて目的を果たせるか」を合わせて見て判断されます。 一般論としては、書かれていない機能は追加費用や追加の期間の相談になることが多い一方、「当然あるべき機能」を専門家である開発会社が確認すべきだったかどうかが争点になるケースもあります。個別の判断は弁護士など専門家に確認するとして、この記事では、発注者が今日からできる確認と、開発会社への切り出し方を整理します。
なぜ「当然入っている」と「入っていない」が食い違うのか
発注者と開発会社のどちらかが悪いというより、見ている景色が違うことで起きる食い違いがほとんどです。
理由1：発注者にとっての「当然」は、社内では説明不要な業務の常識
「ログインできれば自分のデータだけが見える」「入力を間違えたら直せる」「一覧は検索できる」。業務に慣れた方ほど、こうした動きは言うまでもない前提になります。ところが、要件定義書（＝作るものを文章で決めた書類）は「書かれたことを作る」ための書類です。言うまでもない前提ほど、書かれずに抜け落ちます。
理由2：開発会社は「書かれていること」を基準に見積もる
開発会社は、要件定義書にある機能をもとに作業量と費用を見積もります。書かれていない機能まで含めると、見積もりより工数が増えてしまうため、安易に「入っているはず」とは言えません。「対象外です」という返答は、多くの場合、悪意ではなく契約の範囲を守るための反応です。
理由3：機能の「あるなし」ではなく「どこまで」が決まっていない
たとえば「検索機能」と書いてあっても、キーワードだけか、日付や担当者で絞れるのか、並べ替えはできるのかは別の話です。「機能の名前はあるが、中身の範囲は書かれていない」ケースでも、「当然ここまでできる」と思っていた発注者との間でずれが生まれます。
責任はどう考えられるのか（一般論）
法律の個別判断はできませんが、考え方の枠組みは公的な資料で確認できます。
📰 出典：IPA（情報処理推進機構）「プロジェクトマネジメント義務と協力義務」解説コラム
IPAの解説コラムでは、受注者（開発会社）には、契約書に書かれていなくても、専門的知識に基づいて開発を適切に進め、発注者がプロジェクトに適切に関わるよう働きかける義務があると整理されています。一方、発注者には、仕様の決定などを適時・適切に行い、資料の提供など必要な協力をする義務があるとされています（執筆時点：2026年10月）。
つまり、責任は一方に決まっているのではなく、双方に役割があるという整理です。実際にどちらの責任がどの程度重いかは、次のような事情で変わります。
| 見るポイント | 発注者に有利に働きやすい例 | 開発会社に有利に働きやすい例 |
|---|---|---|
| 契約・要件定義書の記載 | 「一般的な〜機能」など範囲があいまいに読める | 対象外の機能が明記されている |
| やり取りの記録 | 打ち合わせやメールで要望を伝えた記録がある | 要望を伝えた記録がなく、承認の記録がある |
| 機能の性質 | その機能がないと、業務の目的を果たせない | 目的の達成に必須とまでは言えない |
| 確認の機会 | 開発会社から確認や提案がなかった | 確認の場で「なくて良い」と合意している |
どれか1つで決まるものではありません。ここで大切なのは、「後から責任を問う」より「今できる確認」に力を使うことです。
見つけたときに、まずやる5つのステップ
ステップ1：「ない機能」を言葉にして、目的を添える
「あるはずの機能がない」と伝えるだけでは、開発会社も対応を決められません。次のように、何をしたい場面で困るのかを添えてください。
- 何ができないのか（例：登録したデータを後から修正できない）
- どの業務の場面で必要か（例：入力ミスが毎日数件ある）
- なければ何が困るか（例：担当者が毎回、開発会社に修正を依頼することになる）
ステップ2：要件定義書・議事録・メールを探す
「書いていない」と思っていても、議事録やメール、画面のモックアップ（＝見本の画面）に記載や図が残っていることがあります。逆に、発注者側が要望を伝えていた記録が見つかれば、話し合いの大きな材料になります。見つけたら、日付と出所をメモしておきましょう。
ステップ3：「追加」か「必須の不足」かを開発会社と一緒に整理する
開発会社に、次の2つに分けて考えてもらうよう頼みます。
- 新しい要望（追加）：当初の想定にない機能。見積もりと期間を相談する
- 目的を果たすために必須の不足：なくては業務が回らない機能。扱いを協議する
この切り分けが、費用の負担を話し合う出発点になります。変更管理（＝仕様変更の扱いを決めるルール）の考え方は、次の記事でも解説しています。
ステップ4：複数の対応案と費用・期間を出してもらう
「作る・作らない」の二択にせず、案を並べてもらうと現実的に決めやすくなります。
- 今回のリリースに含める（費用・期間が増える）
- 簡易版を入れ、本格版は次の段階にする
- 業務の運用（手作業やExcel）で当面補う
- 今回は見送り、運用開始後の改修で対応する
ステップ5：合意した内容を文書に残す
口頭で合意すると、また食い違いが生まれます。決まった内容、費用、期間、リリース時期を、メールや変更依頼書で必ず残してください。
やりがちな失敗
- 感情的に責任を追及してしまう：責任の所在の議論は長引きやすく、肝心のリリースが遅れます。まずは「どう解決するか」を先に決めましょう。
- 「常識だから」で済ませる：業務の常識は開発会社にとって初耳です。常識こそ言葉にして共有する必要があります。
- 承認の署名を「形式」だと思っている：要件定義書の承認は、書かれた内容に合意した記録になります。承認前に読み込む時間をとりましょう。
- 発見が遅れる：リリース直前に気づくと、選べる対応案が減ります。画面ができた段階で早めに触って確認するのが安全です。
次の発注で「当然」を抜け漏れさせない予防策
今回の経験を、次の依頼や追加開発に活かすための工夫です。
| 予防策 | 具体的にやること |
|---|---|
| 「当然」の洗い出し | 「普段の業務で、やって当たり前のこと」を担当者全員に書き出してもらう |
| 画面を見て確認 | 文章だけでなく、画面の見本を見ながら「これでできるか」を確認する |
| 「しないこと」も書く | 対象外の機能を明記してもらい、あいまいな範囲を減らす |
| 業務の1日を通しで追う | 1日の流れを画面ごとにたどり、足りない操作がないか確認する |
| 早めに触る | 完成を待たず、途中の段階で実際に操作して確認する |
発注者がやること チェックリスト
- ☐ 「ない」と気づいた機能を、困る場面とあわせて文章にしたか
- ☐ 要件定義書・議事録・メール・画面見本に記載がないか確認したか
- ☐ 「追加の要望」なのか「目的に必須の不足」なのか、開発会社と整理したか
- ☐ 複数の対応案について、費用と期間を出してもらったか
- ☐ 合意内容をメールや変更依頼書で文書に残したか
- ☐ 次回に向けて「対象外」の項目も確認する習慣を決めたか
開発会社への質問例
- 「この機能について、要件定義書のどの項目に近い記載があるか、一緒に確認させてもらえますか」
- 「この機能がないと、○○の業務が回らず困っています。追加の扱いにするか、必須の不足として扱うか、どう整理できますか」
- 「対応案を、今回に含める場合と次の段階にする場合で、費用と期間を並べて見せてもらえますか」
- 「今後に備えて、対象外とする機能を要件定義書に明記していただくことはできますか」
- 「画面ができた段階で、業務の流れどおりに触って確認する場を設けていただけますか」
まとめ
要件定義書に書いていない機能が入っていないとき、責任は「書いてあるか」だけでなく、契約の範囲・やり取りの記録・機能の必要性を合わせて見て判断されます。ただ、揉めた後に責任を整理するより、次の3つで実務的に進めるほうが近道です。
- ない機能を「困る場面」とあわせて言葉にする
- 「追加」か「必須の不足」かを分け、複数の対応案を出してもらう
- 合意内容は必ず文書に残し、次回から「当然」を書き出す
個別の契約や費用負担の判断が必要な場合は、弁護士など専門家に確認してください。開発会社との打ち合わせで何をどう切り出すか迷うときは、まず状況を整理するところからご相談ください。
あわせて読みたい関連記事
