No More 請負契約

システム開発を契約する際には、ほとんどの場合、受託契約となります。受託契約には、準委任契約と請負契約があることは過去にも触れていますがここで再掲します。

• 準委任契約：一定期間提供した労働に対し、対価を支払う契約
• 請負契約：決められた納期までに成果物を納品し、対価を支払う契約

僕は古より続く請負契約に対して否定的な立場を取っています。昨今のシステムはスモールスタートで始めて、短いサイクルで改善を繰り返す手法（アジャイル開発）がトレンド、というかデファクトスタンダード（事実上の標準）になっています。これはただの流行ではなく、請負契約の無理や無駄の反動として台頭してきたという経緯があります。

ここではシステム開発における請負契約の諸問題について触れ、これから就職・転職を検討する方の一助となればと思います。

再三申し上げていますが、システム開発（に限った話でもありませんが）は予防が何より重要です。携わったプロジェクトが偶然燃え上がった程度ではまだマシですが、就職先の会社自体が炎上体質ではどうにもなりません。まず結論から申し上げると、

請負契約をしている会社への就職は用心しましょう

ということになります。請負契約のデメリットは以下の通りです。

• 見積のコストは持ち出しになる
• 変わり続ける要望にプロジェクトが逼迫する
• 請負契約を締結したがる企業体質に問題がある
• 受注側に圧倒的に不利、かつ法的制約が多い
• リスクに対しリターンがない

そしてメリットはひとつもありません。強いて言えば、大手 IT 企業が請負契約による受注を積極的に行っているため（というかそうせざるを得ない）、大手に所属している、或いは大手と契約している安心があるかもしれません。

それぞれについて詳細を説明する前に、請負契約について少しだけ詳しく述べておきます。

請負契約は契約前にシステム化したい要件をまとめた資料^[1]要件をまとめた資料は RFP（Request For Proposal）と呼ばれ、RFP の精度が、見積の精度に大きく影響するを、いくつかの IT 企業に提示して、システム開発の見積を依頼します。依頼を受けた会社は見積を提示し、そのなかには、

• どのようにシステム化を実現するか
• いつまでに納品するか（納期）
• どのような要員編成で開発するか
• 開発と保守にかかる金額

といった内容がどの案件でも記載されることになります。システム化を依頼した企業はいくつかの見積のうち、最も適正と思われる企業を採用し発注することになります。尚、請負契約を発注する業者の多くが、大手ユーザ企業、或いは国や地方自治体です。道路工事などと同様にコンペで受注することになります。

準委任契約にない、請負契約の特徴は以下の 2つです。

成果報酬型

納期があり、それまでにシステムを納品する必要があります。また、納期とは別に検収日があり、納期から検収日の間に発注企業がシステムを動かして不具合がないか確認します。メーカなどでいうところの検品作業だと思ってください。検収日は、システムの規模にもよりますが、通常納期から1ヶ月程度です。注意が必要なのは、入金は検収日から基本契約書に記載のある支払サイトに従った日付になります。

例えば、システム開発開始が 1/1、納期が 3/31 、検収日 4/30 で支払いサイトが 45日だった場合は、6/14 の入金まで、そのプロジェクトでは一切の売上にはなりません。

また、プロジェクトの作業者ひとりひとりに対し、対価を請求する準委任契約と異なり、そのプロジェクトに対し、何人で作業しようと受注企業側の自由です。当然プロジェクトチームの指揮命令権限は完全に受注企業側にあります。但し、これは守られない状況もしばしば存在し、実際は定期的に進捗を報告したり、進め方について指摘を受けることもあります。

尚、準委任契約でも法規上は指揮命令権限は所属会社にあります。が、外部常駐の（客先で作業を行う）場合、こちらでも実質的にはお客様の指示に従って作業を行うことになります。もちろん違法行為ですが、体裁としては、常駐者 1名が代表してプロジェクトのタスクをチーム（同じ所属会社の社員やパートナー）に指示を出している、ということになっています。少し分かりづらいですが、客先常駐はスーパーグレーゾーンとだけ理解しておいてください。

瑕疵担保責任

受注企業は納期から1年間の間（個別契約により変更可能）、システムに関する不具合を無償で対応する義務があります。大抵の場合、納期から1年も経って保守契約もなければ、プロジェクトは解散して、開発に携わっていた要員はいないことが多いため、有事の場合はその場にいる要員だけで対応する必要があります。

以上を踏まえて、デメリットの各項目について説明します。

見積のコストは持ち出しになる

見積というものは、実はかなりの労力を使います。少なくとも頭の中では一度システムを構築する必要があるためです。実際に見積をするのは、システムに一通り知見のあるベテラン SE か、各専門分野別の SE 複数人で見積をすることもあります。

上記レベルの SE の一般的な日給は ¥35,000〜40,000 とされます。見積に1週間もかかれば、ざっと 20万円程度になります。当然その間はほかの業務はできません。社員であれば給料分の経費程度にはなりますが、その費用は完全な持ち出し（会社が負担）となります。また、見積後に失注（コンペで負けること）した場合はリターンの機会すらありません。

そのため、受注できる見込みがない仕事の見積を辞退することも当然できますが、付き合いで見積を出すように要求されることもしばしばあります。僕自身の経験では、SIer から、すでに発注する会社は決まっているが、会社のルールとして必ず複数社から見積を取る必要があり、それに付き合わされたことが何度かあります。例えそのような場合でもあまりにどんぶり勘定に見積もるわけにはいかないのが難点です。下手な見積を出すと、その後の評価に関わるためです。はじめから出来レースなのに、なんともひどい話ですよね。

変わり続ける要望にプロジェクトが逼迫する

請負契約での成果物は見積の内容以上でも以下でもありません。途中で追加要件が発生したり、変更依頼があれば作業を止めて再度見積をすることになります、法規上は。しかし、往々にして発注側との力関係により、追加や変更が無償で押し通されることがあります。ここで開発会社が異を唱えてトラブルになるとその後の契約に支障をきたすため、受注側は泣き寝入りすることが常です。

追加・変更の大きな問題は、それにより出来上がってきたシステムの作りを根本的に見直さなければならない可能性が発生する、という点です。単純な追加工数でなく、これまでの作業が台無しになりかねない、ということです。一軒家を建て始めてある程度経ってから水周りを変えるような要望は無茶だとはなんとなく想像できるのですが、システムではそのような考慮はされません。結果作業量も増え、当初スケジュールから遅延し、SE は残業や休日出勤を余儀なくされます。そして追加・変更はほとんどの場合発生します。

しかしこれは必ずしも発注側に問題があるとも限りません。請負契約は上記の通り、事前に構築するシステムを可能な限り細かく定義して、それに必要な工数を IT ベンダが見積り、合意したうえで期間までにシステムを構築します。よほど小さなシステムでも最低 1ヶ月、僕の経験では3名程度のプロジェクトでも 3〜4ヶ月はかかります。3〜4ヶ月もあれば顧客の要望が変わることなど想像に容易いことです。寧ろそんな期間を置いたうえで、顧客も仕様を忘れてしまったようなシステムを完成させて納品したところで、「うーん、なんか違うな」と思われるのは仕方がないことだと思います。

冒頭でも書いた通り、システム開発は最低限の機能を急ぎ開発し、クライアントにデモンストレーションを実施、フィードバックを反映する、という小さいサイクルの反復が最も適切であると最近は考えられています。そもそも請負契約はシステム開発に向いていないと考えるのが妥当です。

請負契約を締結したがる企業体質に問題がある

上記の通り、請負契約はシステム開発に向いていません。それでも尚、請負契約で締結せざるを得ない状況は絶えません。例えば、僕の知る限り、公共団体（自治体）は請負契約の前提で公募を出します。一部例外（随意契約と呼ばれる形態）もありますが、基本的には請負契約です。これは公平性を満たすための措置ですが、逆に公共団体であれば仕様の追加・変更は発生しにくいのでそのへんはそれほど気にする必要はないでしょう。

問題は、公共団体でもないのにシステム開発を請負で発注する会社ですが、これは大した理由もなく、業務委託は請負契約でなければ発注できないなどの規約があるためです。この規約にどれほど恣意的な意図があるかは不明ですが、請負契約での発注が発注側に有利であることをある程度理解している可能性は充分にあると考えられます。

体感的に請負契約での発注が義務付けられている会社はもともと国営であった会社や、大企業、或いは歴史の古い会社です。言葉は違えど、共通点は歴史ある会社です。IT 業界において時代錯誤な請負契約にこだわる姿勢はまさに旧態然と言ってよいでしょう。変革するつもりがないという意思表示です。本来であればわれわれ IT 業とは相反する存在です。

受注側に圧倒的に不利、かつ法的制約が多い

これは前提で述べた、瑕疵担保責任などの法的制約と、請負契約でありながら顧客から業務命令が発生するなど、実態としての不自由さを表しています。

リスクに対しリターンがない

ここまで見てきた通り、多くの制約や炎上する条件揃い踏みの請負契約ですが、リターンはほとんどありません。1人月あたりの価格が準委任契約と比較して若干高いですが、上記を補って余りあるとは到底言えません。度重なる仕様変更にかかるコストや炎上による社員の退職、瑕疵対応分を真面目に計算すればどれほど割りに合っていないかは明らかです。百害あって一利あり、くらいでしょうか。

---

建築業界などは請負契約が未だに標準だそうですが、それは様々な理由により、請負契約が業界的に適切であるということです。繰り返しになりますが、請負契約が悪い、ということでなく、請負契約はシステム開発にはそぐわない、ということです。

未だに請負契約でシステム開発を発注する会社は、よほど IT のリテラシが低いか、IT ベンダを食い物にしようとしている、と疑わざるを得ません。意識的かどうかにかかわらず、Win-Lose を実践する会社とは距離を置くことを強く推奨します。無茶なプロジェクトは始まった段階で敗北が確定しており、そこでは誰もが無傷では済みません。

もしみなさんがこれから就職しようとしている企業が請負契約で発注または受注している企業であれば充分な注意が必要です。そして、長年の付き合いで請負契約にはしているものの、実態としては準委任契約となっている場合もあることを最後に補足しておきます。ただ個人的には、そこまで長い付き合いであれば、その企業からの売上が、全体の売上に対し、売上の大部分を占めている可能性があるため、経営方針に不安を感じます。リスクを分散していない、或いは営業が弱いと判断できます。まあ、その話は別のところで。