SE年収1000万までの道のり

パソコン初心者の僕が年収1000万を超えるまでにしたこと。仕事、転職、独立、副業、投資など。

*

IT業界の契約形態まとめ

      2016/03/20

契約書にサインする人

請負、委託、準委任、派遣、SES(システムエンジニアリングサービス)、タイマテ(タイムアンドマテリアル)、等々、契約形態に関する言葉が沢山あって何が何だか分からなくなります。

ここではIT業界の契約形態に関する言葉を実例と共にまとめました。

スポンサーリンク

請負契約

一括、または、一括請負、などと呼んだりもしますが全て請負契約と同じ契約形態を指しています。

まず、請負契約とは何かをwikiで調べてみると

請負(うけおい)とは、当事者の一方(請負人)が相手方に対し仕事の完成を約し、他方(注文者)がこの仕事の完成に対する報酬を支払うことを約することを内容とする契約。日本の民法では典型契約の一種とされ(民法632条)、特に営業として行われる作業又は労務の請負は商行為となる(商法502条5号)。

引用元:

https://ja.wikipedia.org/wiki/%E8%AB%8B%E8%B2%A0

と、あります。

 

これを超簡単にいうと、このシステムを作ったら1000万円とか、この画面を作ったら100万円のように、決められた成果に対してお金を払う「貰う」契約になります。

特徴

この請負契約の大きな特徴としては、過程が問われないということがあげられます。

仕事を受注した会社は、新人を使おうが、外人を使おうが、決められた納期までに約束した成果物を納めれば、その過程はどうでも良いのです。

ですので、契約時に定められた成果物さえ予定通りに出せるのであれば、経験が浅い技術者に経験を積ませたり、単価の安い技術者を雇って差益を抜いたりを自由に出来ます。

メリット・デメリット

例えば、一般的には2人で5ヶ月「10人月」掛かるとされている仕事を受注したとして、独自のノウハウを持っていたり、優秀な技術者がいたりして1人で5ヶ月「5人月」で完成したとします。

実際は半分のコストで仕事を終わらせたにも関わらず、そんな場合でも10人月分のお金が満額貰えるのです。

つまり、上手くプロジェクトをやり繰り出来れば受注した会社は大きく儲けられる可能性があると言えます。

 

逆に、実際に掛かる工数よりも少なく見積もってしまったり、想定外の出来事でプロジェクトが上手く進められず、予定以上の工数が掛かったとしても納期や金額を後から変更することは出来ません。

ですので、このような場合には赤字覚悟で追加要員を投入したり、残業、徹夜、休日出勤をする等して何とか納期に間に合わせるのです。(これがIT業界で有名なデスマーチ(死の行進)です)

また、このように受注側は赤字になるリスクがあるので、リスク分を見積金額を上乗せするケースが多いです。

成果物の責任

もしも納品した成果物に不具合が見つかった場合、納品後1年以内は無償で直さなければいけないという決まりがあり、これを瑕疵担保責任と呼んでいます。

但し、納品後1年以内でも製造会社以外の技術者※が修正した場合、瑕疵担保責任の対象外になるので注意が必要です。

※製造会社の技術者でも、発注元に委託や派遣契約をしている技術者が修正すると、製造会社以外の技術者が修正したとみなされ瑕疵担保責任の対象外となります。

現場の実態はどうなのか

発注者からすると、納期や金額が決まっていて、なおかつ1年間の瑕疵担保責任がある請負契約で発注したいところですが、成果物が明確にならないと請負契約は出来ないので、一般的には要件定義や基本設計位まで終わるまでは委託(SES)契約で行い、詳細設計、開発、単体テスト位を請負契約にすることが多いです。

 

受注会社にとっては、上手くプロジェクトをやり繰り出来れば大きな利益が出る可能性がある請負契約ですが、実際に請負で大きく利益を出しているところは少ないです。

本当は、想定外の作業が発生するリスク分や、瑕疵担保責任による不具合の修正工数等を上乗せして見積もりを出したいところですが、発注側は必ずといって良いほど複数の会社に対し相見積もりを取りますのでバッファを上乗せし過ぎると案件自体をライバル会社に取られてしまいます。

その為、少しでも想定外の作業が発生すると破綻するようなギリギリのラインで見積もりを出すことになり、結果的にデスマーチに繋がっていきます。

場合によっては敢えて赤字覚悟の見積もりで案件を受注しにいって、2次開発や、別の案件に繋げることで、トータルで黒字にするなどの営業戦略もあります。

SES(システムエンジニアリングサービス)契約

業務委託、準委任、タイマテなどと呼んだりもしますが全てSES契約と同じ契約形態を指しています。

 

まずは、SES(システムエンジニアリングサービス)契約とは何かをwikiで調べてみると

SES契約は労働法規などでは業務請負の一種とみなされる。このため、労務管理や指揮命令系統などが発注元企業から独立している必要がある点が、発注元企業による指揮命令の下で業務を行う派遣契約との大きな違いである。賃金は技術者の労働力に対して支払われ、システムの完成は支払い要件には含まれない。

引用元:

https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E5%A5%91%E7%B4%84

と、あります。

これを超簡単にいうと、時間を売る契約になります。

特徴

発注者のシステム開発を1ヶ月するので100万円貰う(払う)という感じで、成果物に対しての責任は一切なく、作業時間に対してお金を貰う契約形態になります。

この成果物に対しての責任が一切無いというのがSES契約の最大のポイントです。

 

極端な話、全く仕事が出来ず1ヶ月で何も成果物を出せなくても、発注者はお金を払わなければいけないのです。

もちろんそんな事をしたらすぐに契約を打ち切られて会社の信用も失いますが極論はそういうことです。

単価とは

SESは作業時間に対してお金を貰うのですが、一般的にその金額は1ヶ月辺り幾らというのが決まっていて、この1ヶ月辺りの金額のことを単価(または人月単価)といいます。

 

単価は仕事の難易度や技術者の経験年数、スキルによって大幅に変わります。

例えば、経験3年未満のプログラマーですと単価は大体50万円位ですが、経験10年以上のプロジェクトマネージャーなんかだと単価100万越えも少なくありません。

 

後は発注側の懐具合も少なからず影響します。

お金に余裕のある業種(金融、公共)がクライアントだと比較的単価は高くなり、逆にお金に余裕のない業種(製造、小売り、一次産業全般)だと単価は安くなる傾向があります。

 

単価アップの交渉が成功するかは、SEのスキルも重要なのですが、実際は発注側の懐に余裕があるかどうかが大きなポイントになったりします。

基本作業時間とは

SES契約を結ぶ際は単価と共に、1ヶ月辺り何時間作業すれば良いかも契約時に決めておきます。

1日8時間作業するとして、営業日が平均20日とすると160時間となります。

一般的には、この160時間を基準としてプラスマイナス20時間位(140時間から180時間)を基本作業時間とするのが多いです。

もちろんこれは契約毎に異なりますので、120時間から180時間という所もありますし、160時間から200時間という所もあります。

超過清算とは

プロジェクトが忙しくなり残業や休日出勤をした結果、基本作業時間をオーバーすることも多々あります。

そんな時にオーバーした分の作業時間を請求出来るかどうかも契約時に決めておきます。

 

超過分金額の決め方として良くあるケースは、単価を160で割った時給に対して超過時間を掛けるというものです。

例えば、単価80万、基本作業時間140時間から180時間という契約で、その月は残業が多くてトータル200時間作業したとします。

 

まず、時給を求めると、

単価80万÷160時間=5千円

となり、このSEは時給5千円ということが分かります。

次に上限の180時間をオーバーした時間は20時間なので、

20時間×5千円=10万円

となり超過分は10万円になります。

よって、この月請求は、基本単価の80万円に超過分の10万円を足して90万円となります。

 

このように残業が増えると発注者側としてもコストが増加するので出来るだけ超過なしでプロジェクトを進めようとします。

逆に超過清算なしの契約の場合、何時間作業しようと(させようと)金額は固定なので受注する側にとっては大きなリスクになります。

世の中には、親会社とは超過清算ありで契約しておいて、下請の外注先とは超過清算なしで契約し、わざと仕事を無茶振りして超過分の金額をピンハネするような会社もありますので注意が必要です。

指揮命令系統

指揮命令系統とは、作業者が誰の指示で仕事をするのかということですが、SESの場合は受注会社の管理者の指示のもとに作業を行います。

作業場所が発注会社(客先常駐)だとしても発注会社の社員から直接作業指示をしてはいけないという事に建前上はなっています。

しかし、実態としては守られていない現場が多くあります。(というか守られていない現場の方が多いです)

派遣契約

基本的には業務委託と一緒なのですが、指揮命令系統は発注側になります。

本来であれば発注側から直接作業指示を出せるのでフレキシブルに動けるというメリットがあるのでしょうが、実体として業務委託でも発注側が直接作業指示を出すのが恒常化しているので、わざわざ派遣法の対象になるこの契約を結ぶことは稀です。

実際に開発の現場でも派遣契約は殆ど見かけないです。

まとめ

色々な言い回しがあったり、法律の部分と建前の部分が暗黙の了解になっていたりして分かり辛いですよね。

一応、以下に表で纏めましたので、もし分からなくなったら再度こちらで確認してみて下さい。

 

IT業界の契約形態まとめ表

特徴/契約形態請負契約SES(委託)契約派遣契約
提供する物契約時に定められた成果物作業時間
成果物に対する責任ありなし
瑕疵担保責任ありなし
指揮命令系統受注側受注側発注側
発注側のメリット納期、金額が明確。臨機応変に作業を依頼出来る。
発注側のデメリット受注側のリスク分が工数として上乗せされ、見積が高くなる場合がある。能力の低い技術者がアサインされた場合、期待する成果物が出てこない可能性がある。
受注側のメリット新人や外国人等の単価の低い技術者を使って成果物を作成出来れば大きな利益を出すことが出来る。成果物に対する責任が無いのでリスクが低い。
受注側のデメリット見積もりが甘いと赤字やデスマーチになる可能性がある。技術者の頑張りが利益に繋がり難い(2倍の成果物を出しても単価は2倍にはならない。)

 

 - 基礎知識