システム開発の追加費用を請求できるか｜仕様変更・追加開発の実務

システム開発の追加費用を請求できるかは、単に「想定より工数が増えた」という事情だけでは決まりません。受注者側としては、当初の見積・仕様・要件定義で予定された範囲を確定し、その範囲を超える仕様変更・追加開発が、発注者の依頼または承認に基づいて行われたことを示す必要があります。

追加費用のトラブルでは、発注者側から「当初から含まれていた」「バグ修正にすぎない」「追加費用がかかるとは聞いていない」と反論されることが多くあります。この記事では、受注側企業が追加報酬を請求する場面を想定し、法的な考え方、証拠の集め方、請求前に整理すべきポイントを説明します。

執筆者：弁護士 坂尾 陽（企業法務・M&A担当）

追加費用を請求できる基本線

システム開発で追加費用を請求できる典型例は、当初契約や当初見積の対象外である仕様変更・機能追加・作業範囲拡大について、発注者が依頼し、受注者が対応した場合です。たとえば、要件定義後に新しい帳票を追加する、外部システムとの連携を追加する、当初想定していなかった権限管理や承認フローを実装する、といったケースが考えられます。

もっとも、追加費用が認められるためには、受注者が「予定外の作業だった」と主張するだけでは足りません。裁判や交渉では、当初スコープ、変更依頼、作業実施、金額根拠の四つをつなげて説明できるかが重要になります。

当初スコープと追加作業を切り分ける

追加費用を請求する前に、まず当初スコープを確定します。開発契約書、見積書、提案書、要件定義書、基本設計書、議事録、WBS、画面一覧、機能一覧、見積前提条件などを確認し、どこまでが当初報酬に含まれていたかを整理します。

当初スコープが曖昧なまま請求すると、発注者から「その作業は当然含まれている」「完成させるために必要な作業だった」と反論されやすくなります。特に、画面の文言修正、軽微なレイアウト調整、不具合修正、検収前の手直しは、追加作業なのか当初債務の履行なのかが争われやすい部分です。

追加作業と評価されやすい例

追加費用の対象にしにくい例

追加費用の合意がある場合

最も見通しが立ちやすいのは、追加作業について追加見積書、発注書、メール承認、チャット承認、議事録上の合意が残っている場合です。金額、作業範囲、納期への影響、検収方法が記録されていれば、発注者が後から支払を拒む場合でも、合意に基づく報酬請求として整理しやすくなります。

ただし、実務では「急いでいるので先に進めてほしい」「費用は後で相談しましょう」という形で作業が先行し、金額の明確な合意がないまま追加開発が進むことがあります。この場合でも、追加作業を発注者が依頼し、受注者が有償で対応する前提だったことを示せれば、黙示の合意や相当報酬として請求できる余地があります。

追加見積書に押印がない場合でも、発注者が見積内容を前提にスケジュールを承認した、課題管理表で「追加対応」と整理した、追加費用の協議を継続しながら成果物を利用した、という事情があれば、合意の成立や少なくとも有償性の認識を補強する事情になり得ます。

金額の合意がない場合と商法512条

金額の合意がない場合でも、会社間のシステム開発取引では、商法512条に基づく相当報酬請求が問題になります。商法512条は、商人が営業の範囲内で他人のために行為をしたときに、相当な報酬を請求できるとする規定です。

システム開発会社が、発注者のために、営業として追加開発や要件定義を行った場合、契約書や追加発注書が十分に整っていなくても、相当な報酬を請求できる可能性があります。ただし、商法512条は「作業をしたら必ず請求できる」という万能の根拠ではありません。

特に問題になるのは、その作業が本当に発注者のために行われたのか、発注者が成果や便益を受けたのか、相当報酬額をどのように算定するのかです。受注者側の営業活動、提案活動、見積作成、受注獲得のための無償対応と評価される作業は、商法512条の対象になりにくいことがあります。

不当利得、事務管理、損害賠償といった構成が主張されることもありますが、開発作業そのものの相当報酬を回収する主たる構成としては、まず合意の成立、黙示の合意、代金額の定めのない契約、商法512条を中心に検討するのが通常です。不当利得や事務管理は、立替費用や成果の利用など個別事情が強い場合の補充的な検討にとどめるのが安全です。

裁判例から見る判断の分岐

システム開発の追加費用請求では、裁判例上も、当初仕様と追加仕様の切り分け、発注者の依頼・承認、作業の完成、工数・金額の立証が重視されています。

大阪地裁平成14年8月29日判決

大阪地裁平成14年8月29日判決は、ソフトウェア開発の途中で仕様変更・追加要求が問題となった事案です。同判決は、仕様変更の申出を、当初契約に基づく業務範囲を超える新たな業務委託契約の申込みと捉えました。そして、追加代金額の合意がないまま追加委託に係る業務を完了した場合には、代金額の定めのない新たな請負契約が成立し、会社間取引として商法512条により相当額の追加開発費支払義務が生じると判断しています。

この裁判例は、受注者側にとって重要です。もっとも、同判決は、全ての変更要求を追加費用の対象にしたわけではありません。当初の基本機能設計書に含まれていない新機能や処理手順の変更は仕様変更と評価される一方、画面上のボタン配置や文言表示のような詳細項目については、追加開発費用の対象にならないと判断されたものもあります。

つまり、追加費用請求では、「変更があった」だけでなく、その変更が当初仕様を超える有償の追加作業なのかを、項目ごとに分類して説明する必要があります。

東京地裁平成19年10月31日判決

東京地裁平成19年10月31日判決は、正式な契約締結前の新会計システム導入に関する交渉・作業が問題となった事案です。要件定義や全体設計の対価が争われ、商法512条に基づく報酬請求が一部認められました。

この判例は、追加開発そのものだけでなく、契約書作成前や正式発注前に行った要件定義・設計作業についても、発注者のための有償作業と評価できるかが問題になることを示しています。契約書なしの開発報酬については、契約書なしのシステム開発で報酬請求できるかで別途整理します。

名古屋地裁令和6年5月31日判決

名古屋地裁令和6年5月31日判決では、生産管理システムの完成、仕様変更への協議、追加対応の有償性などが問題となりました。同判決は、完成すべき仕事が概要設計書で合意されたシステムであることを前提に、開発工程の完了や完成の有無を慎重に検討しています。また、仕様変更について誠意をもって協議する旨の文言について、直ちに法的義務を課すものではないと評価した点も実務上参考になります。

この裁判例からは、追加費用請求をする側であっても、まず当初契約上の仕事がどこまで完成していたのか、追加対応が当初債務の履行なのか、別作業なのかを分けて説明する必要があることが分かります。

請求前に整理すべき証拠

追加費用を請求する前に、証拠を時系列で整理します。裁判例でも、追加作業の対象、工数、金額根拠の説明が重要になっています。請求書だけを送っても、発注者が争う場合には説得力が足りません。

工数表は重要ですが、工数表だけでは弱いことがあります。どの工数が、どの追加依頼に対応し、どの成果物に反映され、当初スコープのどこを超えたのかを対応付けることが必要です。

発注者側から想定される反論

追加費用請求では、発注者側から典型的な反論が出ます。請求前に反論を想定し、証拠と説明を準備しておくことで、交渉の精度が上がります。

当初範囲に含まれていたという反論

最も多い反論は、「それは当初の開発範囲に含まれている」というものです。この反論に対しては、当初仕様書や見積前提と、追加要望後の仕様・成果物を比較し、差分を明確にします。単なる作業量ではなく、機能・画面・帳票・連携・処理手順・データ項目などの差分で説明することが重要です。

バグ修正にすぎないという反論

発注者側は、追加対応を「不具合修正」と位置付けることがあります。受注者側としては、当初仕様を満たすための修正なのか、当初仕様を超える新たな要望なのかを分ける必要があります。バグ修正と追加開発が混在している場合は、請求対象を追加開発部分に限定し、無理に全部を請求しない方が説得的です。

追加費用の説明を受けていないという反論

追加費用が発生することを明確に伝えていない場合、請求は難しくなります。ただし、発注者が追加見積を受け取っていた、費用協議をしていた、当初工数を大きく超えることを認識していた、追加対応を前提にスケジュール変更を承認していたなどの事情があれば、有償性を補強できます。

成果が使えないという反論

開発が未完成であったり、追加開発部分が利用できなかったりする場合、報酬請求の見通しは下がります。追加費用を請求するには、対象作業が完了しているのか、成果物として利用可能なのか、発注者側の事情で利用されなかったのかを整理する必要があります。成果が利用可能な状態に達していない場合は、単に労力を投じたことだけでは不十分と評価されることがあります。

請求書・内容証明を出す前の進め方

追加費用の請求では、いきなり高額な請求書や内容証明を送るよりも、まず証拠を整理し、請求対象を絞り、発注者の反論を想定した説明資料を作ることが大切です。特に継続取引がある場合、法的に正しいだけでなく、交渉で合意しやすい整理にする必要があります。

内容証明郵便は、相手方に強いメッセージを送る手段ですが、関係悪化や訴訟化のきっかけにもなります。追加費用の金額が大きい場合、取引停止のリスクがある場合、成果物の利用停止や著作権・ソースコードの扱いも絡む場合には、送付前に法的構成と証拠の整合性を確認しておくべきです。

関連する論点との違い

追加費用請求は、システム開発トラブルの中でも「追加報酬」の問題です。瑕疵、遅延、再開発費用、逸失利益などの損害賠償とは整理が異なります。損害賠償の問題は、システム開発の損害賠償で検討します。

また、そもそも契約書を作らないまま要件定義や試作を進めた場合は、当初スコープと追加スコープの問題ではなく、契約成立や契約締結前作業の有償性が中心になります。この点は、契約書なしのシステム開発で報酬請求できるかで扱います。

レベニューシェア型・成功報酬型の開発が頓挫した場合は、固定報酬型の追加費用請求とは異なり、報酬発生条件、サービス開始可能性、成果の利用可能性、利益分配合意の内容が問題になります。この点は、レベニューシェア型開発が頓挫した場合の開発費請求で整理します。

よくある質問

追加見積書にサインがなくても請求できますか

サインがないだけで直ちに請求できないわけではありません。メール承認、議事録、課題管理表、追加作業を前提にしたスケジュール承認、成果物の利用などから、有償の追加作業であることを説明できる場合があります。ただし、サイン済みの追加発注書がある場合より立証負担は重くなります。

口頭で追加依頼された場合はどうすればよいですか

口頭依頼だけでは争いになりやすいため、後追いでもメールやチャットで「本日ご依頼いただいた追加作業は、当初範囲外のため追加費用の対象になります」と確認しておくべきです。すでに紛争化している場合は、当時の議事録、作業ログ、発注者の確認コメントなどを探します。

当初見積より工数が増えた場合は請求できますか

単なる見積超過だけでは請求は難しいです。受注者側の見積ミスや作業効率の問題と評価される可能性があります。請求するには、当初見積の前提が発注者の追加要望や仕様変更により変わったことを示す必要があります。

追加開発の途中で発注者が中止した場合はどうなりますか

中止時点までに追加作業がどこまで完了していたか、成果物が発注者のために利用可能か、中止の原因がどちらにあるかで結論が変わります。契約条項、解除通知、作業進捗、成果物の引渡し状況を確認し、完成部分・未完成部分・実費部分を分けて整理します。

まとめ

システム開発の追加費用トラブルでは、請求額の大きさだけでなく、証拠の整理の仕方が結果を左右します。受注者側は、感覚的に「追加で大変だった」と主張するのではなく、当初仕様、追加依頼、作業項目、工数、相当額を対応させて、発注者側の反論に耐えられる形にしてから請求することが重要です。

関連記事