要件定義書の変更を頼んだら「変更管理の費用がかかる」と言われた。無料の修正と有料の変更の境目と、頼む前に確認したい5つのこと

要件定義書（＝作るシステムの内容を文章で決めた書類）を承認したあとで、「ここを変えたい」と開発会社に伝えたところ、「変更管理の費用がかかります」と返ってきた。初めて言われると、「ちょっとした修正なのに、なぜお金が？」と戸惑う方は少なくありません。

先に結論をお伝えします。無料か有料かを分けるのは、変更の「大きさ」よりも、「承認した書類の内容が変わるか」と「作業量・納期・他の機能に影響が出るか」です。書類どおりに作られていない部分を直すのは、一般に開発会社の責任で直す範囲です。一方、書類に書いてある内容そのものを変えるのは、たとえ小さく見えても、確認や見積もりの作業が発生するため有料になることがあります。

この記事では、システム開発の発注者に向けて、変更管理の費用が発生する理由、無料と有料の分かれ目、変更を頼む前に確認したい5つのことを、そのまま使えるチェックリストと質問例とあわせて解説します。契約の解釈は個別の契約書によって変わりますので、一般的な考え方としてお読みください。

変更管理とは？なぜ費用がかかるのか

変更管理（＝仕様の変更を、決めた手順で受け付けて、影響を調べて、合意してから進める仕組み）は、システム開発では標準的な進め方です。発注者から見ると「ひとこと伝えれば済むこと」でも、開発会社の側では次のような作業が発生しています。

• 変更が、すでに作った部分や、これから作る部分のどこに影響するかを調べる
• 設計書・テスト項目・画面の説明書など、関連する書類を直す
• 作業量と納期の変化を見積もり、発注者に提示する
• 合意した内容を、変更の記録として残す

つまり、費用がかかるのは「修正そのもの」だけでなく、影響を調べて、安全に変えるための作業も含まれるからです。特に、複数の機能がつながっているシステムでは、1か所の変更が思わぬ場所に響くため、この確認を省くと不具合の原因になります。

経済産業省が公開している「情報システム・モデル取引・契約書」でも、仕様の変更は、双方が決めた手順に沿って提案・検討し、合意したうえで進める考え方が盛り込まれています。変更の影響を見て、費用や納期を見直す余地を残しておく、という発想です。

📰 出典：経済産業省「情報システム・モデル取引・契約書（第二版）」

開発会社の側も、変更を断りたいわけではなく、「決めた手順を飛ばすと、お互いに困る」という事情でこの仕組みを使っていることがほとんどです。

無料の修正と有料の変更の境目

実際の契約書や開発会社によって扱いは違いますが、考え方の目安は次のとおりです。

内容	一般的な扱い	例
承認した書類と違う動きをしている	開発会社が直す（無料のことが多い）	書類に「半角英数字で入力」とあるのに全角で入力できてしまう
書類に書いていなかったことを追加したい	変更として見積もり（有料のことが多い）	一覧画面に、書類にない検索条件を足したい
書類に書いてある内容を変えたい	変更として見積もり（有料のことが多い）	承認フローを2段階から3段階にしたい
文言や色など、書類に影響しない軽微な調整	無料の範囲を契約で決めている場合がある	ボタンの文言を「登録」から「保存」に変える
書類の読み方が人によって違う（あいまいな記載）	話し合いで決める。ここがもめやすい	「適宜通知する」の「適宜」が何分以内なのか

この中で最ももめやすいのは、最後の「あいまいな記載」です。「当然入っていると思っていた」という発注者と、「書いていないので入っていない」という開発会社の間で、認識がずれてしまいます。この点は、同じ要件定義の話題として、別の記事でも詳しく解説しています。

詳しくは次の記事で解説しています。

変更を頼む前に確認したい5つのこと

1. 契約書に「変更管理」の手順と費用の定めがあるか

まず、契約書や注文書、要件定義書に付いている資料を見て、変更の依頼方法と費用の考え方が書かれているかを確認します。「変更は書面（メールでも可か）で申し入れる」「変更の見積もりは無料か有料か」「軽微な修正の回数や上限」などです。読み方が分からなければ、そのまま開発会社に聞いて構いません。

2. 変更したい理由と、変えないとどう困るか

変更の依頼は、「何を変えるか」だけでなく「なぜ変えたいか」を添えると、開発会社が別の安い方法を提案しやすくなります。たとえば「入力項目を増やしたい」の裏に「営業が毎回電話で確認している情報を残したい」という目的があるなら、既存の備考欄で足りるかもしれません。

3. 変更の見積もり（影響調査）自体が有料か

変更を実行する費用とは別に、影響を調べて見積もりを出す作業を有料とする会社もあります。逆に、一定の範囲までは無料で見積もる会社もあります。依頼する前に確認しておくと、「見積もりを頼んだだけで請求された」という行き違いを防げます。

4. 費用だけでなく、納期と他の機能への影響

費用が安くても、納期が延びたり、すでに完成した機能のテストをやり直したりする場合があります。費用・納期・他の機能への影響の3点を、変更の見積もりと一緒に出してもらいましょう。

5. 「今回の変更」か「次の追加開発」か

どうしても今回のリリースに必要か、公開後に追加で対応しても困らないか、を社内で整理します。公開後の追加開発として別に進めるほうが、全体の費用や納期を抑えられることもあります。

やりがちな失敗

• 口頭やチャットだけで変更を伝える：あとで「言った・言わない」になりやすく、費用の話もあいまいになります。変更は必ず文章で残しましょう
• 「小さな修正だから無料のはず」と思い込む：見た目は小さくても、裏側の影響が大きい変更はあります。無料かどうかは、作業量で決まります
• 変更の見積もりを取らずに「とりあえず進めて」と伝える：あとで想定外の請求になりやすい進め方です。金額と納期を確認してから合意しましょう
• 変更が出るたびに現場から個別に開発会社へ連絡する：窓口が複数あると、内容が食い違います。変更の依頼窓口は社内で一本化しましょう

発注者がやることチェックリスト

• ☐ 契約書・注文書・要件定義書で、変更の依頼方法と費用の定めを確認した
• ☐ 変更したい内容を、理由と「変えないと困ること」とあわせて文章にした
• ☐ その変更が、承認した書類の「修正」なのか「追加・変更」なのかを開発会社に確認した
• ☐ 変更の見積もり（影響調査）が有料かどうかを、依頼前に確認した
• ☐ 費用・納期・他の機能への影響の3点を書面で出してもらった
• ☐ 今回のリリースに必須か、公開後の追加開発でよいかを社内で決めた
• ☐ 変更の窓口担当者を社内で一人に決めた
• ☐ 合意した変更の内容と金額を、メールなど記録に残る形で確認した

開発会社への質問例

• 「今回のご依頼は、承認した要件定義書の『修正』にあたりますか、それとも『変更』にあたりますか。その理由も教えてください」
• 「変更の影響を調べて見積もりを出すところまでは、費用がかかりますか。かかる場合、おおよその目安を教えてください」
• 「この変更で、費用のほかに、納期や、すでにできている機能のテストへの影響はありますか」
• 「軽微な調整として無料で対応いただける範囲は、契約上どこまでですか。回数や条件があれば教えてください」
• 「目的が同じで、費用や期間を抑えられる別のやり方はありますか」

質問への答え方から、変更の理由を丁寧に説明してくれる会社かどうかも見えてきます。

まとめ：「承認した書類が変わるか」と「影響の大きさ」で考える

要件定義書の変更で費用がかかるのは、修正作業だけでなく、影響を調べて、安全に変えるための作業が含まれるためです。無料か有料かは、次の点で整理すると見通しがよくなります。

• 承認した書類と違う動きなら、開発会社が直すのが基本
• 書類にない内容の追加や、書いてある内容の変更は、変更として見積もりになる
• あいまいな記載は、話し合いで決める。早めに書面で確認する
• 費用だけでなく、納期と他の機能への影響も見てもらう

契約の細かい扱いは、契約書ごとに異なります。迷ったときは、開発会社に聞くとともに、必要に応じて弁護士や専門家にも確認してください。変更を頼む前に5つのことを整理しておけば、費用の話し合いも落ち着いて進められます。

あわせて読みたい関連記事