システムが納品されて受け入れ確認(=発注者が「注文どおりにできているか」を確かめる工程)をしていたら、「あの操作ができない」「この画面が足りない」と気づく。そんなとき、最初に頭に浮かぶのは「これは追加費用を請求されるのだろうか、それとも無料で直してもらえるのだろうか」という不安ではないでしょうか。
「受け入れ確認で足りない操作が見つかったけど、追加費用を請求されるのか、無料で直してもらえるのか分からない…」
先に結論をお伝えします。無料か有料かは、その操作が「契約時に合意した内容に含まれていたか」で決まるのが一般的です。含まれていたのに動かないなら「不具合」として直してもらう話になり、含まれていなかったなら「追加の要望」として見積もりの相談になります。
この記事では、足りない操作を見つけたときに、開発会社に連絡する前に確かめたい5つの手がかりと、そのまま使えるチェックリスト・質問例を解説します。なお契約の解釈は個別の事情で変わるため、ここでは一般的な考え方にとどめます。
「無料で直る」と「追加費用がかかる」を分ける境目
まず、足りない操作の正体は大きく2つに分かれます。
| 種類 | 状態 | 一般的な扱い |
|---|---|---|
| 不具合(バグ) | 合意した内容に書いてあるのに、動かない・結果が違う | 開発会社が直す対象になりやすい |
| 仕様の抜け・追加の要望 | 合意した内容に書かれていない | 追加の見積もりを相談する対象になりやすい |
「業務で必要なのだから当然入っているはず」と感じても、合意した資料に書かれていなければ、開発会社は見積もりに入れていないことがほとんどです。これは開発会社が意地悪をしているわけではなく、書かれていないものは見積もれないという、仕事の進め方の問題です。
システムの要件を決める責任が発注者側にあることは、公的機関も指摘しています。
📰 出典:IPA(情報処理推進機構)「ユーザのための要件定義ガイド 第2版」
だからこそ、境目は「契約書・見積書・要件定義書(=作るものを文章で決めた資料)にどう書かれているか」で見ていくことになります。
追加費用になるかを見分ける5つの手がかり
手がかり1:見積書・契約書の「機能一覧」に載っているか
最初に見るのは、見積書や契約書に添付された機能一覧(=画面や機能の名前を並べた表)です。足りない操作と同じ名前、または同じ意味の項目があれば、「合意済みの内容」だった可能性が高まります。
手がかり2:要件定義書・画面設計書に書かれているか
機能一覧に名前がなくても、要件定義書や画面設計書(=画面の見た目と動きを書いた資料)に、その操作が描かれていることがあります。例えば、一覧画面の絵に「削除」ボタンがあるのに、実際の画面には無い、といったケースです。
手がかり3:打ち合わせの議事録やメールに残っているか
「あの操作も入れてほしい」と伝え、開発会社が「分かりました」と答えた記録があれば、合意の根拠になります。口頭だけのやり取りは証拠が弱いため、後日の確認メールを習慣にしておくと安心です。
手がかり4:契約で決めた「受け入れの基準」に照らしてどうか
受け入れ確認では、あらかじめ決めた基準(=何ができれば合格とするか)を満たしているかを見ます。基準が「機能一覧のとおりに動くこと」なら、一覧にない操作は基準の外です。基準が曖昧な場合は、まず基準を文章にして双方で確認することから始めます。
手がかり5:契約の種類(請負か準委任か)と、保証期間
契約の種類によって、修正の扱いが変わります。一般論としては、成果物の完成を約束する請負契約では、納品物が契約の内容と合っていない場合の対応(契約不適合責任)が問題になります。一方、作業の遂行を約束する準委任契約では、作業時間に対して費用が発生するのが基本です。また、納品後に無償で直してもらえる期間(保証期間)が決まっていることもあります。
契約上の責任や費用負担は個別の契約内容で変わります。判断に迷う場合は、弁護士や専門家、公的な相談窓口に確認してください。経済産業省が公開しているモデル契約書も、考え方の参考になります。
足りない操作を見つけたら、連絡する前にやること
「慌てて『直してください』とだけ送ると、話がかみ合わなくなりがちです。先に事実を整理してから連絡すると、早く決着します。」
- 現象を具体的に書く:「どの画面で、何をしようとして、何ができなかったか」を、画面のスクリーンショットと一緒にメモします。
- 業務上の影響を書く:「この操作が無いと、毎日何分かかる」「月末に何件手作業になる」など、困りごとの大きさを示します。
- 合意資料を探す:上の手がかり1〜3の資料を集め、該当する記述に印を付けます。
- 希望を整理する:「無料で直してほしい」だけでなく、「有料でもよいが、この日までに必要」「次の改修でまとめて対応でもよい」など、譲れる点を決めておきます。
- 記録に残る形で連絡する:メールなど、後から読み返せる形で伝えます。
やりがちな失敗
- 「当然入っているはず」と思い込む:業務の当たり前は、開発会社には見えていません。資料に書かれているかで話をします。
- 受け入れの期限を過ぎてから伝える:受け入れ確認の期間が決まっている場合、期間を過ぎると「合格とみなす」扱いになる契約もあります。気づいた時点ですぐ連絡します。
- 開発会社を責める口調で伝える:どちらかが悪いと決めつけると、解決が遠のきます。事実と希望を淡々と伝えるほうが、結果的に早く進みます。
- 一度に全部を要望する:「必須」「あると便利」「将来でよい」に分けて伝えると、費用を抑えやすくなります。
発注者がやること チェックリスト
- ☐ 足りない操作が起きる画面と手順を、スクリーンショット付きで記録した
- ☐ 見積書・契約書の機能一覧に、同じ内容の項目があるか確認した
- ☐ 要件定義書・画面設計書に、その操作が書かれているか確認した
- ☐ 議事録・メールに、その操作を依頼した記録があるか探した
- ☐ 契約書で、受け入れ確認の期間と合格の基準を確認した
- ☐ 契約の種類(請負か準委任か)と、無償で直してもらえる期間(保証期間)を確認した
- ☐ 業務への影響と、いつまでに必要かを整理した
- ☐ 連絡はメールなど、記録に残る形にした
開発会社への質問例
そのまま打ち合わせやメールで使える形にしてあります。
- 「この操作ができない件ですが、契約時の機能一覧や設計書のどこに該当するか、一緒に確認させていただけますか。」
- 「不具合として対応いただく範囲と、追加の要望として見積もりが必要な範囲を、理由と合わせて教えてください。」
- 「追加対応が必要な場合、概算の費用と期間を、実施前に書面でいただけますか。」
- 「今回の受け入れ確認の期間は、この件を相談している間も延長されるという理解でよろしいでしょうか。」
- 「無償で対応いただける保証期間と、その対象範囲を改めて確認させてください。」
まとめ:合意した資料を見て、事実から話す
受け入れ確認で足りない操作が見つかったとき、無料で直るか追加費用になるかは、「契約時に合意した内容に含まれていたか」が大きな分かれ目になります。
- 見積書・契約書の機能一覧、要件定義書・画面設計書、議事録やメールの順に、合意の根拠を探す
- 受け入れの基準・期間、契約の種類、保証期間を契約書で確認する
- 事実と希望を整理し、記録に残る形で、責めずに相談する
追加費用になる場合でも、「必須のものから先に」「次の改修でまとめて」といった工夫で負担を抑えられることがあります。まずは手元の資料を確かめるところから始めてみてください。
あわせて読みたい関連記事













