テストが始まったころに、開発会社から「この画面の項目追加は要件に入っていないので、追加で180万円かかります」と言われる。要件定義の打ち合わせでは話した記憶があるけれど、仕様書に書いてあるかどうかまでは確認していない。払うべきものなのか、それとも押し返していいのか。判断がつかないまま返事を求められる、という場面です。
システム開発の追加費用について書かれた記事は多いのですが、その大半は請求する側から書かれています。開発会社が「なぜ発生するのか」を説明したものか、法律事務所が「どういう場合に請求できるのか」を論じたものです。払う側が、目の前の請求をどう判断すればよいのかを順番に整理したものは、ほとんど見当たりません。
この記事では、追加費用になるものとならないものの境界がどこで決まるのかを示したうえで、変更の手続きを実際にどう回すのかを説明します。結論を先に言うと、判断の起点は「言った・言わない」ではなく、システム仕様書の記載と、変更の手続きを通ったかどうかの2点です。
この記事のポイント
- 追加費用かどうかの境界は、打ち合わせでの発言ではなくシステム仕様書の記載で決まる
- IPAのモデル契約は、仕様書を決められた変更管理の手続きでしか変えられない構造にしている
- 手続きを通さずに着手された作業は、発注側が合意していないと言える
- 変更を協議した結果として「進めない」と決める道も、手続きの中に用意されている
目次
システム開発の追加費用はなぜ発生するのか
追加費用の話がこじれるのは、多くの場合「その作業がもともと頼んだ範囲に入っていたかどうか」で認識が食い違うからです。金額の大小より先に、この境界をどう決めるかを揃える必要があります。
追加費用になるものとならないもの
境界の決め方はひとつです。システム仕様書に書いてあることは、元の契約の範囲に入っています。書いていないことは、新しく足す作業なので追加になります。
単純に聞こえますが、実務ではここが曖昧なまま進みます。要件定義の打ち合わせで出た話が、そのまま仕様書に反映されているとは限らないからです。発注側は「話したのだから入っているはず」と思い、開発会社は「仕様書に書いていないので入っていない」と考える。この差が、テストの段階になって表面化します。
そのため、請求が来たときに最初に開くべきなのは、見積書ではなく仕様書です。仕様書に該当する記載があるなら、それは追加ではなく、契約した範囲の作業が終わっていないという話になります。記載がないなら、追加として扱うのが筋です。
判断の起点はシステム仕様書の記載
この考え方は、SucSakが独自に言っているものではありません。IPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書（第二版）は、システム仕様書を契約の一部として位置づけたうえで、仕様書は「第37条の変更管理手続によってのみ変更ができる」という構造を取っています。
つまり、モデル契約の世界では、仕様は打ち合わせの会話では変わりません。変更したいなら、決められた手続きを通す必要があります。逆に言えば、手続きを通っていない要望は、まだ仕様になっていないということです。
ここから2つのことが言えます。ひとつは、発注側が「話したはず」と主張しても、仕様書に反映されていなければ根拠として弱いということ。もうひとつは、開発会社が手続きを通さずに作業を進めてしまった場合、あとから請求されても発注側は合意していないと言えるということです。後者は、開発会社側にも手続きを守る義務があることを意味します。
なお、実際の契約がモデル契約と同じ構成になっているとは限りません。手元の契約書に変更管理の条項があるかどうかは、請求を判断する前に確認してください。個別の契約についての法的な判断は弁護士に確認することをおすすめします。
発注側の事情で発生する典型パターン
追加費用のうち、発注側に起因するものには決まった型があります。
| いつ起きるか | 何が起きているか |
|---|---|
| 要件定義のあと | 現場にヒアリングしたら、決めた業務の流れと実態が違っていた |
| 設計のあと | 「今のやり方どおり」と伝えた内容の解釈が、自社の想定より狭かった |
| 開発中 | 社内の決裁が遅れ、開発会社の要員が待機した |
| テスト段階 | 実際に画面を触って初めて、足りない項目に気づいた |
このうち、決裁の遅れによる待機は特に説明がつきにくい種類の請求です。成果物が何も増えていないのに金額だけ増えるからです。ただ、開発会社の側から見れば、確保していた要員が動けなかった実費が発生しています。防ぐには、契約時に社内の承認日程を伝えておき、それを前提に工程を組んでもらうしかありません。
もうひとつ見落とされやすいのが、発注側の調達ルールが遅れを生む場合です。取引実績のない会社とは直接契約できない、購買部門の登録に数週間かかるといった社内の決まりがあると、着手日が後ろにずれます。ずれた分だけ要員の確保期間が延び、それが費用として乗ります。自社のルールを変えられなくても、リードタイムを先に伝えておけば工程に織り込めます。
開発会社の見積もり漏れで発生する場合
もうひとつ、上位の解説記事があまり触れない側があります。発注側は何も変えていないのに、開発会社の見積もりが足りていなかったケースです。
このパターンは、元の見積書の作りに兆候が出ています。
- 前提条件の欄が空欄か、定型文しか書かれていない
- 工程が「開発一式」のようにまとめられ、内訳がない
- 性能や同時利用者数といった非機能の条件が書かれていない
- データ移行やテストデータの準備が、どちらの作業か書かれていない
これらが揃っている見積書は、見積もった側も範囲を確定できていません。あとから「そこまで含んでいなかった」という話が出やすくなります。見積書のどこに危ない兆候が出るかはシステム開発見積もりチェックシート（危険サインを見抜く60項目）にまとめてあるので、追加見積もりを受け取ったときの点検にも使えます。
見積もり漏れが原因の場合、全額を発注側が負担するのが当然という話にはなりません。仕様書の記載は変わっていないので、境界としては契約の内側にあるからです。どちらの責任がどれくらいかを話し合う場面になります。
システム開発の追加費用を発注側が見極める方法
ここからは、実際に請求が来たときの順番です。額面を見て反射的に交渉に入る前に、確認しておくと判断が変わることがあります。
請求が来たら最初に確認する3点
確認するのは3つです。順番に意味があります。
- 仕様書に記載があるか。あれば追加ではなく、契約範囲の未完了です
- 変更管理の手続きを通っているか。発注側が変更に合意した記録があるか
- 事前に分かり得たことか。開けてみて初めて分かったのか、設計段階で分かったはずなのか
3つ目の切り分け方は、既存システムの改修で追加費用が出たときの考え方と同じです。詳しくはレガシーシステムの改修はどこまで？見積もりの読み方も解説で扱っているので、そちらを参照してください。
変更管理の手続きを回す順番
1つ目と2つ目を確認した結果、これは追加だと判断したとします。そこから先が、この記事の本題です。
モデル契約のひな型では、変更は第37条の変更管理手続に沿って進みます。実際の流れは次のとおりです。
| 段階 | やること | 動く側 |
|---|---|---|
| 1. 変更提案書を出す | 変えたい内容を書面にする | 気づいた側（発注側からでもよい） |
| 2. 変更管理書を交付する | 決められた項目を書いて相手に渡す | 提案を受け取った側 |
| 3. 連絡協議会で協議する | 変更を進めてよいかを話し合う | 双方 |
| 4. 承認して確定する | 双方の責任者が記名押印する | 双方 |
この手続きで効くのが2番目です。変更管理書に書く項目が決められていて、そこに費用だけでなく期間と影響も含まれています。
- 変更の名称／提案の責任者／年月日／変更の理由
- 変更に係る仕様を含む変更の詳細事項
- 変更のために費用を要する場合はその額
- 検討期間を含めた変更作業のスケジュール
- その他変更が契約の条件（作業期間または納期、委託料、契約条項等）に与える影響
現場でよく起きるのは、金額だけが口頭で伝えられ、後ろの3つが出てこない状態です。ひな型に沿うなら、スケジュールと他への影響は費用と同じ扱いの記載事項です。「この変更で他の機能の完成日はどう動きますか」と聞くのは、踏み込んだ要求ではなく、書面に書かれるはずの項目を確認しているだけになります。
4番目も押さえておいてください。双方の責任者が変更管理書を承認して初めて変更が確定します。さらに、納期や委託料といった契約条件に影響する場合は、変更契約を結んだ時点で確定するとされています。つまり、承認より前の段階で作業が始まっているなら、それは手続きの外で動いていることになります。
なお、協議がまとまらない間、開発会社の側が作業を中断できるという定めも置かれています。協議を引き延ばすと工程が止まるので、変更の話が出たら早く場を持つほうが結果的に損をしません。
この手続きは最初の1回だけ回せばよいものではありません。プロジェクトの途中で変更は何度も出ます。毎回この流れを通す運用にしておくと、終盤に「実はあの分も」とまとめて請求される形になりません。
手続きを通さず着手された作業はどう扱うか
ここがいちばん揉めるところです。開発会社がよかれと思って先に作業を進め、完了後に「あの分の追加です」と請求してくる場合があります。
モデル契約の考え方に沿えば、変更は手続きを通ってはじめて仕様になります。手続きを通っていない作業は、発注側が合意した変更ではありません。つまり、請求の根拠として弱い立場にあるのは開発会社の側です。この点は、発注側が負い目を感じる必要のないところです。
とはいえ、実際に動いた工数はあります。その場でできることは3つです。
- その作業が本当に必要だったのかを確認する。不要なら、成果物を受け取らないという整理もありえます
- 必要だったなら、なぜ事前に提案が出なかったのかを聞く。仕組みの問題なら、そこを直すのが先です
- 今後は合意前に着手しないことを、その場で双方の記録に残す
金額そのものをどう詰めるかは、ベンダーとの折衝の技術の話になります。内訳の分解のさせ方や、お金以外の変数の使い方はベンダーコントロールのコツ｜折衝・調整をうまく進める実践術にまとめているので、交渉の場に立つ前に目を通しておくと動きやすくなります。
進めないと決める場合も手続きの中にある
追加費用の話は「払うか、揉めるか」の二択になりがちです。しかし、変更管理の手続きは、合意するためだけの仕組みではありません。
モデル契約のひな型には、変更管理手続の協議の結果、変更の内容が納期や委託料などの契約条件に影響を及ぼすといった理由で発注側が個別契約の続行を中止しようとするとき、未了部分について契約を解約できるという条項が置かれています。協議の結果として進めないという判断が、あらかじめ想定されているということです。
この位置づけを知っておくと、協議の場での立ち方が変わります。提示された金額に対して「払えません」と言うのではなく、「この変更は今回は見送ります」と言えるからです。前者は交渉ですが、後者は手続きに沿った判断です。
ただし、中止はただで済むものとして書かれてはいません。同じ条項の続きでは、発注側は中止の時点までに開発会社が行った業務の委託料を支払い、解約によって開発会社に生じた費用や損害も賠償するものとされています。手続きの中に用意された道ではありますが、精算を伴います。選ぶ前に、手元の契約書の該当条項を必ず確認してください。
次の契約に何を書いておくか
いま起きている請求を処理したら、次の発注で同じ形にならないようにします。効くのは3つです。
ひとつめは、変更管理の手続きそのものを契約に書くことです。前の節の4段階を条文にしておけば、合意前に着手された作業について話す根拠になります。条項の確認観点は受託開発の契約で発注者が確認すべきこと（著作権・ソースコード）にまとめています。
ふたつめは、見積書の前提条件欄を埋めさせることです。空欄のまま受け取らず、「この見積もりに含まれていない作業を書いてください」と依頼します。見積書は含むものを書く形式なので、含まないものは黙っていれば書かれません。
みっつめは、打ち合わせで決まったことをその場で確定させることです。「持ち帰って検討」で終わった話は、仕様にも記録にも残りません。決めきれないなら「いつまでに誰が決めるか」だけでも議事録に書いておきます。
システム開発の追加費用に関するよくある質問
- Q. 見積もりに書いていない作業は払わなくていいのですか
- 見積書に書いていないことと、契約の範囲外であることは別です。判断の基準になるのは仕様書と契約書です。仕様書に記載があれば、見積書に個別の行がなくても契約範囲に含まれていると考えるのが自然です。逆に、どちらにも記載がなく、変更の合意もしていない作業であれば、支払いの義務があるかは検討の余地があります。個別の判断は弁護士に確認してください。
- Q. 打ち合わせで口頭合意した内容はどうなりますか
- 口頭のやり取りに意味がないわけではありませんが、後から内容を確かめる手段がないため、主張の根拠としては弱くなります。議事録に残っていて、相手が確認済みであれば状況は変わります。だからこそ、決まったことをその場で文字にする習慣が効きます。
- Q. 話し合いがまとまらないときはどこに相談すればよいですか
- まず社内の法務や顧問弁護士に契約書を見てもらうのが先です。契約書に協議の手続きや紛争解決の条項が書かれていることが多く、そこに従うのが最短になります。金額が大きく当事者間で解決しない場合には、ソフトウェア関連の紛争を扱う裁判外紛争解決の窓口もあります。いずれにせよ、支払いを保留したまま作業だけ進む状態が続くのがいちばん困るので、判断は早めに動かすほうがよい場面です。
