追加費用が発生しない開発会社の見分け方 変更管理の手順と書面
要約： 追加費用の請求が突然来ない開発会社は、変更管理の手順を書面で持っています。範囲外の作業には、変更依頼、書面の見積りと納期への影響、お客様の承認が必要で、そのあとで初めて着手します。本記事では、4つの手順、契約書に入れておきたい項目、見積りで注意したい兆候を整理します。
目次
- システム開発の追加費用は、どこから発生するのか
- 変更管理の手順は、どんな流れなのか
- 手順を有効にするために、契約書へ何を書くのか
- 見積りのどこに、追加費用の兆候が出るのか
- VAONは、範囲の変更をどう扱うのか
- この手順で解決できないこと
- よくあるご質問
1. システム開発の追加費用は、どこから発生するのか
システム開発の追加費用は、たいていは「範囲内」と「変更」の境目が書面になっていないことから生まれます。この境目が双方の頭の中にしかないと、最終の請求書の段階で、2つの解釈がぶつかります。
よくある発生源は3つです。1つ目は、お客様が実際に要件を変える場合です。機能の追加や、確定したあとの業務フローの変更がこれにあたります。2つ目は、もともと要件にあった内容が曖昧に書かれていて、開発側が不明確な部分を「範囲外」として扱う場合です。3つ目は、チャットや会議で頼まれた作業がその場で行われ、あとから請求書に別の行として載る場合です。
1つ目は、どのプロジェクトでも普通に起きます。2つ目と3つ目は、書面の問題です。特に2つ目は契約前の仕様書の質から始まっており、オフショア開発が失敗する本当の理由は、仕様書にあるで扱っています。
2. 変更管理の手順は、どんな流れなのか
変更管理は4つの手順で進み、どの手順でも書面が残ります。
- 変更依頼を出す。 確定した範囲の外にある作業は、変更依頼書として記録します。お客様と開発側のどちらからでも出せます。
- 書面で見積りと納期への影響を示す。 開発側が、費用と、納期が動くかどうかを書面で示します。ほかの項目への影響も含めます。
- お客様が書面で承認する。 権限のある方が、誰かが着手する前に承認します。
- 作業する。 手順3のあとにだけ行います。
手順3から、短い原則が決まります。承認がなければ作業せず、作業しなければ請求もしません。価格を見たうえで変更を見送ることもでき、その場合、プロジェクトは元の範囲で続きます。
この4手順は、特定の会社の独自の工夫ではありません。経済産業省とIPAが公表している「情報システム・モデル取引・契約書」には、変更管理手続の条項があります（第一版では第37条）。この資料の解説では、変更管理手続は、システムの信頼性の確保に必要な手戻りと、それに伴う応分の負担を双方が協議する場とされています。このモデル契約はウォーターフォール型の、重要なシステムの受託開発を想定しているため、すべての案件でそのまま使えるわけではありません。ただ、この考え方が標準的な実務であることは分かります。
3. 手順を有効にするために、契約書へ何を書くのか
契約書には、次の項目を明記しておくことをおすすめします。口頭の取り決めだけの手順は、納期が迫ると省かれるためです。
| 項目 | 書いておくこと | 理由 |
|---|---|---|
| 範囲の定義 | 特定の要件定義書（版数、日付）を参照する。「必要な機能一式」とは書かない | 基準がないと、変更と当初の要件を区別できない |
| 変更を依頼・承認する人 | 双方の役職を書く | 権限のない人がチャットで同意してしまうのを防ぐ |
| 変更依頼書の内容 | 内容、費用、納期への影響、ほかの項目への影響 | 十分な情報で判断できる |
| 見積りの回答期限 | 開発側が回答する最大の営業日数 | 長く待たされたあとに、同意を迫られるのを防ぐ |
| 承認しなかった場合 | 元の範囲と価格を維持する | 断る権利が実際に使える |
| 変更と不具合修正の区別 | 製品の不具合は変更管理を通さず、契約不適合責任などの条項に従う | 不具合の修正が新規要望として請求されるのを防ぐ |
| 緊急の作業 | 短時間で承認できる経路（例：役職を明記したメール） | 遅すぎて手順が使われなくなるのを防ぐ |
「変更と不具合修正の区別」の行は、AIがコードの作成に関わる場合に、特によく読んでいただきたい項目です。AIが書いたコードの不具合の責任は別のテーマとして、AIが書いたコードに不具合が出たら、責任は誰にあるのかで扱っています。
4. 見積りのどこに、追加費用の兆候が出るのか
見積りは、1ページ目から追加費用の兆候を示すことがあります。確認し直したい箇所が6つあります。
| 見積りや打ち合わせでの兆候 | 確認したい質問 |
|---|---|
| ほかの見積りより明らかに安く、「詳細は後日」と書かれている | 価格に含まれていない部分はどこですか |
| 固定価格なのに、要件定義書がない | 価格は、どの文書、またはどんな前提にもとづいていますか |
| 範囲が「必要な機能を含む」と書かれている | 具体的な機能の一覧はどこにありますか |
| 変更について触れていない、または「発生したら相談」とだけある | 変更は、どう見積り、どう承認しますか |
| チャットや電話での同意で足りるとされている | 作業の開始前に、書面で何をいただけますか |
| 変更の見積りが金額だけで、納期への影響がない | この変更で、納期はどれだけ動きますか |
滑らかに答えてくれても、どの文書にもつながらない場合も、兆候の1つです。技術的な制約についても早い段階で確認してください。制約が遅く判明すると、大きな変更につながりやすいためです。技術的な制約を契約前に聞き出す5つの質問にまとめています。
5. VAONは、範囲の変更をどう扱うのか
VAONは、範囲の変更を第2章の4手順で扱います。範囲外の作業には変更依頼書を作成し、VAONが書面で見積りと納期への影響を示し、お客様が承認されてから着手します。承認がなければ作業せず、請求もしません。VAONは、これを日本のお客様に次の一文でお伝えしています。「ご承認いただいていない作業の請求書をお送りすることはありません。」
この手順は、2つの取り組みに支えられています。1つ目は仕様確定フェーズです。要件を文書にし、開発フェーズの固定見積りを着手前に出すので、「範囲」に具体的な基準ができます。2つ目は、日々の進め方です。プロジェクトは1〜2週間の短い単位で進め、そのつど動くものをご覧いただきます。毎週の報告には「お客様に決めていただきたいこと」の欄があり、変更の必要は、費用がまだ小さい早い段階で見えやすくなります。終盤にまとめて出てくることを避けられます。
ご予算の目安を伺った場合は、予算に収まる案と、より広げた案の2つをご提案します。途中で項目が追加されるのではなく、選ぶ前に比べていただけます。
6. この手順で解決できないこと
変更管理は、変更にかかる費用そのものをなくすものではありません。妥当な変更には、やはり費用と時間がかかります。違いは、同意する前に金額が分かることです。変更の余地がまったくない予算であれば、問題は手順ではなく計画にあります。
そのほかの限界です。
- お客様の時間がかかります。 依頼のたびに、権限のある方が読んで承認する必要があります。その方が不在になりがちな場合は、最初に代理の方を決めておいてください。
- よい仕様書の代わりにはなりません。 仕様が曖昧だと範囲の境目がぼやけ、議論は「これは変更なのか」に移ります。VAONが先に仕様確定フェーズを行うのは、そのためです。
- 「追加費用なし」は、確定した範囲に対するものです。 法令の改正や、外部システムの仕様変更など、外部の事情による変更も、通常は同じ手順を通ります。
- VAONは、変更依頼の頻度や平均の金額を公表していません。 本記事にも数字は載せていません。
7. よくあるご質問
固定価格なら、追加費用はまったく発生しませんか。 いいえ。固定価格は、文書に書かれた範囲に対して価格を確定するものです。その範囲外の作業をご依頼いただくと費用は発生しますが、見積りをご覧になり、書面で承認されたあとだけです。
チャットで小さな作業を頼んだら、請求されますか。 VAONでは、範囲外の作業は、変更依頼が出され、見積りを書面でご承認いただいた後に着手します。チャットでのご依頼は、フィードバック管理ファイルに記録するか、バックログのタスクにしたうえで、金額と影響とあわせてお客様にご確認いただきます。承認されなければ、作業は行わず、請求もしません。
変更管理の条項は、どのくらいの長さが必要ですか。 長い必要はありませんが、第3章の表にある、誰が依頼するか、誰が承認するか、依頼書の内容、見積りの期限、承認しなかった場合の扱いは必要です。役職、日付、参照する文書が入った短い条項のほうが、長くて曖昧な条項より役に立ちます。
要件定義書がなく、内容がまだ曖昧な案件でも使えますか。 難しいです。文書がなければ、「変更」と呼ぶための境目がありません。その場合は先に仕様確定フェーズを行い、要件定義書と開発フェーズの固定見積りを得てから、変更管理の手順を適用してください。
複数の開発会社の見積りを比較されていますか。 見積りと契約書の案を、VAONの初回のご相談にお持ちください。60分で、CEOが同席します。契約を前提とするものではありません。無料相談（60分）
執筆者： ダン・ヴァン・ルアン（Đặng Văn Luân）、VAON 創業者・CEO。ハノイ工科大学HEDSPI課程卒業。FPT Software、東京のDigital Plus（5年、1,000万ユーザー規模のシステム）を経て、従業員120名のITO企業でCOOを8年務め、ISO 9001・ISO 27001に沿った管理体制を構築。業界歴15年。
参考資料
- 経済産業省・IPA「情報システム・モデル取引・契約書」（第一版及び追補版。変更管理手続の解説、第一版第37条）：https://www.ipa.go.jp/archive/digital/model/ug65p90000001lgm-att/000079617.pdf（2026年10月17日確認）
- IPA「情報システム・モデル取引・契約書（第二版）」：https://www.ipa.go.jp/digital/model/model20201222.html（2026年10月17日確認）
