WEB制作・システム開発において、追加報酬請求が認められるための条件

【ご相談内容】

委託者からの依頼に基づき、WEBシステム開発を手掛けているのですが、委託者からの変更依頼が多く、想定していた工数を大幅に超過している状況です。

当社としては、追加報酬請求を行いたいのですが、認められるのでしょうか。

 

 

【回答】

WEB制作やシステム開発に関する契約は、一般的には請負契約に該当すると考えられます。この請負契約に該当する場合、あくまでも「仕事の完成」に対して報酬が支払われるという関係になりますので、たとえその過程における努力や作業量が当初の見込みと異なっていても、「仕事の完成」のみ評価対象となる故、追加報酬を請求することはできません。

もっとも、委託者からの変更依頼により、当初想定されていた業務＝契約に基づき本来予定されていた業務と異なるというのであれば別論です。この場合、新たな業務を依頼したこと、すなわち追加業務に関する発注となりますので、これを受注したのであれば、その追加業務に関する契約に基づき、別途報酬（追加報酬）を請求することが可能となります。

以上を整理すると、①追加業務の受発注に関する合意があったか、②報酬支払いに関する合意があったのかが、本件でのポイントとなります。

以下では、追加業務と認定されるための要件と追加報酬額の算定方法を中心に解説します。

なお、本記事では、工程が終了しておらず未完成である場合や契約不適合がある場合など、報酬請求が認められない事由が存在しないことを前提に解説しています。

 

 

【解説】

1.本来業務と追加業務の峻別

(1)追加業務を確定させることの困難性

追加報酬請求が認められるためには、契約を締結した段階で予定されていた業務とは異なる業務を行ったことが大前提となります。

当たり前のことなのですが、現場実務では、「その業務は本来予定されていた業務」に含まれるか否かで激しく対立します。このような事態が生じる原因ですが、WEB制作やシステム開発の場合、契約締結後にベンダとユーザが協議しながら、具体的な表示形式（ユーザインターフェース）や実装機能等が決まっていくという、業務フローとならざるを得ないからです。

例えば、次のような裁判例があります。

【大阪地方裁判所平成14年8月29日判決】

本件開発委託契約に基づき被告が完了すべき業務の内容は、基本機能設計書で確定された当初仕様（処理手順、操作画面の種類・相互関係、機能の表示・配置、入出力項目、画面表示、階層関係等）を内部設計以降の作業によって実現することであり、これが、本件開発委託契約に基づく報酬請求権と対価関係に立つ業務の範囲であると解される。 （省略）仕様変更の申出は、法的には、委託者による当初の契約に基づく業務範囲を超える新たな業務委託契約の申込みと解され、これに対して受託者が追加工事代金額を提示せず、追加代金額の合意がないまま追加委託に係る業務を完了した場合には、委託者と受託者の間で代金額の定めのない新たな請負契約が成立したものとして、相当の追加開発費支払義務が生じると解するのが相当である。 （省略）もっとも、ソフトウェア開発においては、その性質上、外部設計の段階で画面に文字を表示する書体やボタンの配置などの詳細までが決定されるものではなく、詳細については、仕様確定後でも、当事者間の打合せによりある程度修正が加えられるのが通常であることに鑑みると、このような仕様の詳細化の要求までも仕様変更とすることは相当でないというべきである。

 

上記の裁判例は、外部設計の段階では画面に表示する文字の書体やボタン配置などの詳細を決定できないことを前提に、仕様確定後に詳細を詰めていく過程において一定程度の修正が行われることは予定されている以上、本件の事例の場合は、本来の業務範囲の具体的内容を明確化しただけに過ぎず、追加業務に該当しないとしています。

もちろん、修正の程度によっては「追加業務」と評価されることもあり得ます。ただ、現場実務では非常に微妙な判断が生じることを認識しておく必要があります。

 

(2)ベンダとしての対策

追加報酬請求が認められるか否かは、「追加業務」であることをどのように裏付けるのかが重要なポイントとなります。

この点、ベンダとして取り得る対策は、次のようなものが考えられます。

 

①契約書を工夫すること

上記(1)でも記載した通り、契約締結段階では具体的な業務内容を明記しづらいという問題があります。そうであれば、逆転の発想として、契約書に含まれていない業務を最初から明記することが1つの対処法となります。

例えば、契約書に次のような条項を定めておくことが考えられます。

ポイントは、本来予定されていない業務を明確化することで、追加業務との峻別を図るという点です。

第×条（業務内容） 本契約において、受託者が委託者に対して提供する業務は次の各号に定める通りとする。 ①WEBページコンテンツの企画制作、及び各種システム構築の調査・分析・企画・立案に関する支援作業 ②WEBサイト概要及び詳細設計、プログラミング、システム各種テスト、及びコンテンツデータ作成等に関する作業 ③××   第×条（除外業務） 委託者および受託者は、次の各号に定める業務が本契約の対象外であることを確認する。なお、本契約の対象外となっている業務について、委託者が受託者に対して依頼を行う場合、別途協議し合意の上、契約を締結する。 ①稼働環境や閲覧環境（OSのバージョンアップやブラウザのバージョンアップ）の変化・変更による不具合の調査および修正 ②システムに対する新規システムの導入または外部システムとの連携 ③××

また、上記に加えて、本来予定されている業務ではあるものの詳細が決まっておらず、場合によっては当初想定していた作業量を大幅に超過する恐れがあるというのであれば、次のような条項を追加することも有益かもしれません。

この条項のポイントは、本来予定されていた業務の詳細化に過ぎないのか、追加業務に該当するのか峻別することは難しいとはいえ、上記のような条項を設けておけば、少なくとも委託者に対して、内容如何によっては追加業務であることを前提にした協議を求めることが可能になるという点です。

第×条（未決定業務） 委託者および受託者は、本契約締結以降において協議を行う必要がある事項は別紙のとおりであることを確認する。なお、委託者は、協議の状況や結果に応じて、報酬や納期が変更される可能性があること予め認識し、了解する。

 

さらに、システム開発契約で推奨されている多段階契約の発想、すなわち、一度決定した事項を後戻りさせない（＝決定した事項を覆す場合は追加業務扱いとする）といった契約内容にすることも一案かもしれません。

例えば、WEB制作の場合であれば、次のように業務手順を細分化し、その手順ごとで合否判定を行い、合格後に次の手順に移行するといった内容にした上で、当該手順より外れる業務は追加業務扱いとするといった方法が考えられます。

第×条（業務内容等） 1.　委託者は、受託者に対し、WEB制作に関する次の業務（以下「本件業務」という）を委託し、受託者はこれを受託する。 ・×× ・×× 2.　本件業務に関する作業手順は、次の各号に定める通りとする。 (1)成果物に関する要件定義 (2)コンテンツの作成 (3)成果物のトップページデザイン第一案の作成。 (4)委託者による、第3号に定めるトップページデザイン第一案の確認及び合否の通知。なお、委託者が当該トップページデザイン第一案につき不合格とした場合、委託者は次のいずれか一つを選択することができる。（選択内容については省略） (5)トップページデザインに対する委託者の合格通知後、成果物の下層ページデザイン案の作成。 (6)委託者による、第5号に定める下層ページデザイン案の確認及び合否の通知。 (7)下層ページデザインに対する委託者の合格通知後、トップページデザイン及び下層ページデザインのコーディング作業の実施 3.　委託者が、前2項までに定める以外の業務の実施を希望する場合、本条第2項に定める内容とは異なる作業手順を希望する場合、又は合格通知後にデザインを変更する場合、委託者は、本契約に定める委託料とは別に、受託者が定める費用を別途支払う。

 

ところで、ベンダ視点で考えた場合、例えば仕様等の変更手続きに関して詳細に定めるべきなのか、という問題があります。

なぜなら、例えば、「仕様等の変更に伴い追加業務が発生した場合、委託者と受託者は別途書面を取り交わす」と定めていたとします。もし、この条項に従って別途書面を取り交わしていたのであれば、ベンダとしては十分な対策を講じており、追加報酬請求もすんなりと認められると考えられます。しかし、往々にして現場実務では、上記のような条項を定めていたとしても、別途書面を取り交わしていないことが多いという実情があります。これは、納期が迫っている状況下で書面を作成し締結するだけの余裕がない、現場担当者間で合意に至った以上はそれを信頼して作業を進めれば事足りる、そもそも契約書にそのような条項があることを認識していない…等々の原因が想定されるところです。

が、いざ紛争となった場合、ユーザより上記条項を盾に、追加業務に関する合意不成立と言われてしまうリスクを抱えることになります。

ちなみに、一種の救済事例のような位置づけになりますが、次のような裁判例が存在します。

【東京地方裁判所平成25年9月30日判決】

ソフトウェア開発に係る請負契約について、書面がないままでは、後に、注文者である被告と請負人である原告との間で、契約の成否について紛争が発生するおそれがあることから、このような紛争の発生を防止することにあると解されるのであり、原告による書面の作成は、成立する契約の内容が当事者間で合意されたものであることを担保するために要請されるものというべきである。このような本件基本契約…の趣旨に、ソフトウェア開発の個別契約を成立させるに当たって、事前に書面を作成することを常に要求することは、この種の請負契約、とりわけ追加開発に係る請負契約の実情にそぐわないものであり、原告と被告が、事前に書面を作成しない限り個別契約は一切成立しないという意思の下に、本件基本契約を締結したとまでは認め難いこと、そして、事前に書面が作成されない限り個別契約の要件を満たさないと狭く解釈し、事前に書面が作成されない契約に本件基本契約の各条項の規制が及ばないとすることは、当事者の合理的意思に反する結果を招来することになりかねないことなどを併せ考慮すれば、被告と原告が協議して取り決めた対象業務の内容を原告が書面化したものである限り、その作成時期を契約前に限定する必要まではないと解するのが相当である。

 

上記裁判例はどこまで一般化してよいのか（適用範囲を拡大してよいのか）は議論の余地があると思われます。

いずれにせよ、ベンダとしては、現場実情からして対処しきれないような厳格な仕様変更等の手続きを設けるべきではありません。いわゆる契約書のひな形には、厳格な仕様変更等の手続きが定められていることが多いようですが、適宜見直す必要があります。

 

②仕様変更等に伴う追加業務に関する履歴を残すこと

上記①で解説した契約書の工夫が実践できない場合はもちろん、実践できたとしても、実際の現場実務においては、「本来予定されていた業務」と「追加業務」を明確に峻別できないことには追加報酬請求を行うことは困難です。

この点、追加業務に関する書面をその都度取り交わすことが理想ですが、実際のところ不可能に近いと言わざるを得ません。そこで、代替策として、例えば、ベンダとユーザの双方が確認できる議事録、変更管理表や課題管理表等に、変更内容とそれに伴う工数増加が生じることを明記することで裏付けを残していくといったことが考えられます。

なお、議事録、変更管理表や課題管理表等の作成者がベンダである場合、ベンダが一方的に作成したものであって、ユーザはその内容に同意したわけではないという反論も想定されるところです。たしかに、この反論を回避することは不可能ですが、しかし、ユーザは誤りを認識していたにもかかわらず、なぜ直ちに異議を述べなかったのか、異議を述べなかった以上は黙認していたのではないかという再反論も考えられます。

最終的にこの再反論が功を奏するか否かは、裁判官の判断となってしまいますが、議事録、変更管理表や課題管理表等の資料は、追加業務の判断において重要視している傾向があると思われます。

要は、変更が生じた都度、仕様等の変更に伴う変更内容とこれに伴う工数増加を文字化する作業にどこまで勤しむのかが、ベンダにとって重要な対策となります。

 

③追加業務それ自体が独立の価値を有すること

やや技巧的なことになるのですが、例えば、WEB制作契約において、追加業務の内容が制作されるWEBに付随する新機能を実装することであったとします。この事例の場合、元となるWEBが何らかの理由で未完成と評価される場合、追加業務だけ完成させても全く無意味であり、新機能は効果を発揮しません。

このように本来予定されていた業務と追加業務が不可分一体となっている場合、果たして追加報酬請求が認められるのかについては議論の余地があります（要は、追加業務も未完成扱いとされる可能性があるということです）。

ベンダとユーザとで評価が割れる可能性が高いため、一律に解決する術はないと言わざるを得ませんが、ベンダとしては、追加業務に独立の価値があることを裏付けられるよう対策を講じたほうが無難です。

 

 

2.追加報酬額の算定

(1)追加報酬支払に関する合意

追加業務が発生したことが裏付けられても、その追加業務に対して報酬を支払うことにつきユーザの了承が得られていない場合、そもそも追加業務に関する合意が成立したと言えるのか疑義が生じることになります。

もっとも、請負契約の場合、業務内容に関する合意が先行し、後で報酬協議を行うという実態があることから、必ずしも契約締結時点において具体的な報酬額に関する合意が必要とされていません。

例えば、相当額を支払うという暗黙の合意があれば足りるとした裁判例が存在します。

 

【東京高等裁判所昭和55年12月25日判決】

被控訴人は、控訴人の注文に基づき、本件店舗の改装工事に関して主としてデザインについての企画、設計及び監理をしていたものであり、両者はその仕事に応じて相当額の報酬を授受することを暗黙のうちに合意しながらも、その報酬額を取り決めなかったものということができる。 （省略）本件仕事をなすに際し、報酬額の取り決めはなかったけれども、当事者間においてその仕事に応じて相当額の報酬を授受する旨の暗黙の合意があったと認められること前記のとおりであるから、控訴人は被控訴人に対して本件仕事の完成引渡と同時にその報酬として客観的に相当と認められる金員の支払をなすべき義務があるといわなければならない。

 

とはいえ、紛争となる事例の大半は、契約成立後において追加報酬額について相当額を支払う旨の合意が成立しているか判然としないパターンです。

このような事例に対する裁判所の判断傾向を踏まえると、ベンダとしては以下に解説するような対策を講じておくことが求められます。

 

(2)黙示的合意の成立

契約は、通常は相手方当事者に対して明示的に了承する旨の意思表示を行うことで成立します。しかし、法解釈論としては、黙示的にも契約が成立する場合があるとされています。

どういった場合にも黙示的に了承していたと言えるのかはケースバイケースとなりますが、ベンダとしては、ユーザが対外的には了承する旨の意思表示を発していないとしても、内心では了承する意思を有しており、それを前提にした言動を行っていたことを抽出し、主張立証を重ねることで、裁判所に認めてもらうといった対処を行うことになります。

ただ、執筆者個人の見解となりますが、ユーザにおいて追加業務であるという認識がない状況下で、黙示的合意を裁判所に認めてもらうことは困難という感覚を持っています。

このため、追加業務であること及び追加業務であることをユーザが認識しえたこと…に比重を置いた主張立証を心掛けたほうが良いのではと考えるところです。

なお、黙示的合意の場合、「相当額を支払う合意が成立した」と裁判所が認定することが通常であり、具体的な報酬額の算定はもっぱら裁判所の法的判断となります。

 

(3)商法第512条に基づく報酬請求

報酬に関する明示的はもちろん黙示的な了承も認められないとなると、ベンダとしては万事休すと思われるかもしれません。

しかし、最後の砦というべきでしょうか、たとえ契約が不成立であったとしても、商法には次のような規定が定められています。

 

【商法第512条】

商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求することができる。

 

ベンダとしては、本来予定されていた業務から「外れる業務」（＝追加業務）であって、客観的にユーザのための業務遂行と認められることが重要となります。

当たり前ですが、本来予定されていた業務に不具合があり、ユーザからの要請はなかったもののベンダが自主的に不具合対応したという場合は、「他人のために行為をした」という要件を充足しません（単に契約違反の是正を行っているだけで、ベンダ自らのための行為と認定されるからです）。

なお、現場実務で厄介なのは、業務遂行したことの裏付け確保です。稼働実績を示す日報やタイムシート等が存在するのであればよいのですが、そういった裏付け資料が乏しい事例も存在します。要は、工数や人日等をどうやって算出するのか色々と思案する必要があります。

 

(4)報酬額の算定

上記(2)にある黙示的合意を認定した上での追加報酬請求、上記(3)にある商法512条に基づく報酬請求のいずれであっても、「相当額」とはいくらかという問題を解決する必要があります。

例えば、ベンダが見積書を提示していたのであれば、その見積書記載の金額が相当額と認定される可能性があります。

もっとも、見積書等の金額算定に際して参考となる資料がユーザに提示されていない場合、人月に基づく工数に対して一定の単価を乗じて算出するという方法が考えられます。しかし、この単価の算出が非常に悩ましく、本来予定されていた業務から逆算した単価を参照して算出する、業界標準的な単価が存在するのであればそれを用いるといったことが想定されますが、現場実務ではいかにして説得的な単価を算出するのかが極めて重要となります。

 

 

3.弁護士に依頼するメリット

WEB制作やシステム開発における追加報酬の問題は、ベンダ・ユーザのどちらの立場であっても金銭に関わるものであることから、重大なリスクとなりえます。

そして、契約内容の整備や追加作業に関する交渉の進め方などを通じてトラブルを未然に防ぐためには、法的なアドバイスが欠かせません。

そこで、企業・事業者が安心してビジネスを進めるためには、日常的に弁護士と繋がりを持っておくことが非常に有効です。

 

 

4.当事務所でサポートできること

当事務所の代表弁護士は情報処理技術者資格を保有し、IT関連の契約について深い知識と経験を持っています。また、WEB制作やシステム開発に関する契約書の作成やトラブル解決にも数多くの実績があります。さらに、顧問契約を締結していただくことで、IT企業は日常的に法律の相談ができる体制を整えることができます。これにより、紛争を防止できる契約書の作成や交渉の進め方に関する知見を得ることができ、訴訟リスクを未然に防ぐことができます。

上記以外にも、次のような強みとサポートを行っています。

 

①IT企業の顧問弁護士として多数の実績があること

当事務所の代表弁護士は、2001年の弁護士登録以来、複数のIT企業の顧問弁護士として活動し、紛争予防から訴訟対応まで幅広く関与し、解決を図ってきました。

これらの現場で培われた知見とノウハウを活用しながら、ご相談者様への対応を心がけています。

 

②時々刻々変化する現場での対応を意識していること

弁護士に対する不満として、「言っていることは分かるが、現場でどのように実践すればよいのか分からない」というものがあります。

この不満に対する解消法は色々なものが考えられますが、当事務所では、例えば、法務担当者ではなく、営業担当者やプログラマー等との直接の質疑応答を可としています。

現場担当者との接触を密にすることで、実情に応じた対処法の提示を常に意識しています。

 

③原因分析と今後の防止策の提案を行っていること

弁護士が関与する前にトラブル対応を開始したところ、法的判断の誤りにより、ご相談者様が思い描いていたような結論を得られず、以後の対応に苦慮している場合があるかもしれません。

こういった場合に必要なのは、方針・対処法の軌道修正をすることはもちろんのこと、なぜ思い描いた結論に至らなかったのか原因検証し、今後同じ問題が発生しないよう対策を講じることです。

当事務所では、ご相談者様とのやり取りを通じて気が付いた問題点の抽出を行い、改善の必要性につきご提案を行っています。そして、ご相談者様よりご依頼があった場合、オプションサービスとして、社内研修やマニュアルの整備、契約書の常時チェックなども行っています。

事業の適正化とトラブル防止のための継続的なコンサルティングサービスもご対応可能です。

 

 

 

＜2024年9月執筆＞

※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。