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