エンジニアでも「請負」と「準委任」の違いは明確に理解しておこう
システム開発完了後もＩＴベンダーのメンバーがユーザー企業のオフィスに常駐したり、あるいは都度ユーザー企業から問い合わせを受けて訪問し、システムの不具合や障害などの対応を行うことがしばしばあります。
今ではクラウド環境がメインとなっている開発プロジェクトも増えているでしょうけど、そういったプロジェクトでも「訪問」や「現調」はないかもしれませんがやはり遠隔での対応と言うのはあることでしょう。
その場合の契約は、OSのパッチ充てや障害への対応に加え、軽微なシステム改修も月額費用の中に含まれることも多いかと思います。
簡単な画面の変更や小さな機能追加など数日で完了するような作業を、別途開発契約を結ぶことなく実施することは私もエンジニア時代よく行いました。
多くの場合、保守ベンダーは作業に一定の追加開発が含まれることを見越しているので、見越したうえでの見積もりを出していて、ユーザー企業もそれに納得して契約します。
追加開発が大量に発生して見込み作業量を超える月もありますが、ほとんど作業のない月もあるため結局「行って来い」で費用と作業量のバランスが取れるという仕組みです。
もちろん、年間を通しても作業量が当初の予定通りとならないこともありますが、そこはお互いに柔軟に対応する…つまり作業量が多過ぎても少な過ぎても、ある程度は恨みっこなしで不問にするというのが一般的な姿です。
ところがこの作業量と支払いが著しくバランスを欠き、どちらかが一方的に損をする場合があります。
常にこの「柔軟さ」を求めすぎたためにある意味属人化しすぎて、仕組みに落とせないズブズブの関係になってしまっているせいです。
それも一時的であれば我慢できますが、常態的にどちらかが損をし続け、しかもそういった関係が長く続けば続くほど契約形態の変更を申し出ても受け入れてもらえない……。そんなケースをよく聞きます。
あるＩＴベンダーは、ユーザー企業の基幹システムの保守作業を請け負っていた。契約では作業工数の多寡にかかわらず、毎月約299万円の支払いが成されることになっていたが、実際にはソフトウェアの不具合への対応については、支払いの対象とならず、またその他の支払いについても、ユーザーによる研修が必要であることが契約に記されていた。
ベンダーは、この契約のもと作業を行っていたが、実際には作業が瑕疵への対応であることや仕事が未完成であることを理由に減額されることが多く、常時赤字を抱え込む状況であった。ベンダーは契約を実際に費やした工数に応じて請求する形態に変更するよう求めたがこの交渉もまとまらなかった。
しかしある年、ベンダーが３ヵ月分の作業工数を基に算出した1075万円の保守費用に対し446万円しか支払いが成されなかったことを機にベンダーは訴訟を提起した。ユーザーは、工数分の支払いをしなかったのは作業に本来無償で行うべき瑕疵への対応が含まれており、また依頼したのに完成していない開発作業があったからと言うが、本来保守作業は準委任契約であり、瑕疵や仕事の未完成は支払いを拒む理由にはならないとして残金約600万円の支払いを請求した。
これは「請負」という契約形態が保守作業に認められるものなのかが争点となった判例です。
判決文を読むと、この契約が「準委任契約」なのか「請負契約」なのかが非常に曖昧です。
「毎月定額で継続的に作業をする」という点は支払いの根拠を「作業時間」に持つ準委任契約と考えられます。一方、「支払いの条件がユーザーの検収、つまり仕事の完成」にあり、「瑕疵の修補は支払いの対象にならない」とするあたりの文言を見ると請負契約にも見えます。
ベンダーは「請負に見える部分は本来の契約と異なっているものだ」と訴えていますが、作業の実態は「月額費用の上限は決められていながら減額だけは可能」という随分とユーザーに都合の良いものでした。
果たしてそれは契約に対して妥当だったのでしょうか。
裁判所はこの契約が準委任なのか請負なのか、以下のように判断しています。
本件個別契約の契約書では、（中略）仕事の内容を定めるのではなく（中略）稼働時間によって定めていたこと、（中略）ベンダー社員が常駐させられ、ユーザーの完全な指揮命令下に置かれ、（中略）請負であれば、当該月の作業内容、時間が大きく変動することが認められるのであり、（中略）本来は準委任契約に近い性質を有していたものとみるのが妥当である。
しかし、本件個別契約の契約書の作業内容には、本来請負として把握するのが相当である「ソフトウェアの軽微な改変または機能追加」が含まれていて、（中略）必ずしも警備とは言えない改変または機能追加も本件個別契約に基づいて行われていたと認められる。また、報酬支払の前提としてユーザーによる「検収」を定めており、ユーザーからのクレームに押され、実績工数を大きく下回る請求工数となることが常態化していたから、その後の運用の実態において、本件個別契約の実質は請負に近いものとなっていた。
このような実態に照らすと、当事者間の黙示の合意により契約内容が変更されたものとみる外ない。
「契約の変更はされなかったが、両者の黙示的な合意によって実態は請負に変更された」という珍しい判断です。こうした例は極めて稀です。ユーザーもベンダーもあまりに契約に無頓着すぎたために、法律や契約を無視した結果、当事者同士での暗黙で決められたやりとりが優先されている…と判断されたわけです。
契約書というそんざいすらも
「実態」と「黙示的な合意」の前では万能ではない
ということになるからです。これは民法522条の影響もうけているのかもしれません。
1. 契約は、契約の内容を示してその締結を申し入れる意思表示（以下「申込み」という。） に対して相手方が承諾をしたときに成立する。
2. 契約の成立には、法令に特別の定めがある場合を除き、書面の作成その他の方式を具備することを要しない。
元々、法律の中では「双方が合意していれば契約として認める」ものとしていて、さらに「法律で定められている場合を除き、書面の作成は必須ではない」としているため、いくら契約書で定めていたとしても、その後双方合意のもとで契約書外の進め方が常態化している以上、そちらが優先される…と判断されたのでしょう。
もっとも、この契約変更が本当に「両者の合意」の下でなされたのかは極めて疑問ですが。
社員を299万円分常駐させられ、実際の仕事量はそれを上回るリスクも背負っていたにもかかわらず、仕事の完成をユーザーが認めなければ支払いを減額されるという契約はかなりベンダーに不利な条件です。
請負と準委任の「悪いとこ取り」に作業が変質していくのをベンダーが喜んで受け入れた…とは到底思えません。顧客との関係維持を重視せざるを得ない弱みにつけ込まれたのかもしれません。ベンダーの担当者および責任者たちがよほど『契約』に無頓着で、ユーザーの顔色だけ見て判断していたのかもしれません。
ですが、いち技術者であった頃はこうした契約のあり方まで知る必要はないのかもしれませんが、プロジェクトマネージャーとなり、さらに管理職へと役割が変わる過程で必ずと言っていいほど『契約』については熟知しておいた方がいいでしょう。
大抵の場合、昇進・昇格するとそれまでの上司が抱えていた既存の顧客を任されるケースもあると思います。この時、過去の関係性維持を中心にビジネスを継続しようとするとこうした弊害をもたらします。無駄な忖度は、傷口をどんどん広げてしまうだけでしかありません。
裁判所は「契約だけが全てではない」とする考え方を提起しています。
「いくら契約があっても、常識的に考えておかしいとなれば、
100％それに縛られるとは限らない」
という判断です。裁判所は当初見積もりを超える工数をベンダーが請求することについて、以下のように判断しています。
（ベンダーの当初見積もり工数よりも超過した工数分の請求が認められるかについては、）社会通念によってこれを認める外ない。見積もりに応じて発注がされている以上、見積工数を超過する請求工数は原則として認められないと解すべきである。ただ、超過するに至った原因がユーザーによる追加的な指示に起因する時はユーザーが負担すべきである。
「見積り時点で想定されていなかった作業は、ユーザーが追加費用を払うべき」とする判決でベンダーには請求した300万円の半額が支払われることになりました。
「準委任契約であっても、その実態が請負であることに両者が合意したのなら契約形態は黙示的に変わる。ただし、当初の契約時点で想定していなかった作業についてはユーザーが負担すべき」
としたものです。請求が600万円だったのに対して支払いが300万円だったのは、ベンダーの行った作業が本当に想定外のものであったかなどを精査しての結果でしょう。
本件は裁判には勝ったようですが、このベンダーには反省点も多いことがわかります。
準委任契約のつもりであったのなら、なぜ「支払いに成果物の完成と検収が義務付け」られる契約を結んだのか。しかも、瑕疵の補修は本来「開発契約」の瑕疵担保責任であり「保守契約」内で作業すべきことではありません（別要員が無償で行うのが理想的）。
「作業時間」と「仕事の完成」という２つのゴールを持ち、契約外で行うべき瑕疵の補修もない交ぜになってユーザーに押し切られるまま作業を続けた、というのが実態でしょう。
ベンダーとしても、お客さまには言いにくいこともあると思いますが、保守も受け持つ気があるのであれば確実にやらなければならないことがあります。
・保守が準委任契約であることをユーザーに合意してもらい、
その工数を超える作業は別途請負契約で行うこと
・瑕疵への対応は（当初開発のものであれ、追加開発のものであれ）
保守とは別のものとして対応し、なし崩しにならないようにすること
・ユーザーがそれを勝手に曲げるようなことを言いだしたら、
勇気をもってその是正か明示的な契約変更を申し出ること
売上や利益をおもんばかる気持ちも分からないわけではありませんが、それと同時に多くの社員や外注の人たちの人生も抱えていることを忘れないでください。
「言っていることは分かるけど、
それで売上が落ちてもいいっていうのか？」
と言う声が聞こえてきそうですが、逆に
「売上を落とさないと言う責任感はご立派だが、
それで多くの社員が疲弊し、
ある人は疾病し、辞めていく事態になってもいいと言うのか？」
と言われて言葉が詰まる程度の浅はかな考えにはならないでください。
「お金」は大切です。
しかし「お金」だけを大切にしていればいいわけではありません。
エンジニア一人ひとりの人生を「お金」だけで割り切らないでください。
同じ理由で、同じ決断を下される側になった時をイメージをした際にあなた自身が嫌な気持ちになるのであればそれは確実に「やってはダメな施策」です。
「相手が嫌がることはしない」
これは基本中の基本ですが、同様に
「自分がされて嫌なことは相手にもしない」
と言うのもモラルの"基本中の基本"のはずです。主張すべきことは主張し、切るべきユーザーは切っていかないと日本のエンジニアはいつまでも浮かばれませんし、結果的にその企業からはエンジニア離れが生じ、組織が衰退していくだけです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。