株式会社アイシス　代表取締役の政平です。
シリーズ）ＩＴ業界の仕組み１１の 続きです。

本日は、「SES、請負、派遣契約のシステム業界における実情と問題点」についてお話します。

◆ SESの実情と問題点

SES（準委任契約）の実情を見ていきましょう。

（作業場所について）
技術者志望にとってどこで働くかは大きな関心事でしょう。
1章で述べたように、SESは必ずしも客先常駐である必要はありません。
しかし、機密性、開発環境、管理のために客先に常駐しているケースが多いのが実情です。

＜機密性＞
システム開発の場合、セキュリティが重視されます。
ユーザーの顧客データやプログラムが世間に流出したら大変です。
セキュリティを守りやすいのは、ユーザー（客先）への常駐です。
金融系、保険系はセキュリティに関して特に厳しく、客先以外での作業は大きく制限されます。
そのため大手SIer、中小開発会社、何れも技術者が客先に常駐します。

＜開発環境＞
開発には様々な環境が必要です。ハードウェア、インフラ、データベース、開発ツール、ミドルウェアなど。客先に用意されているものを、技術者所属の会社で揃えるのは難しい。所属元が中小零細企業の場合、開発環境の費用が出せないという理由もあります。
プログラミングの時は所属元で開発し、本番環境と同等のテスト環境が必要な結合試験以降は客先というケースもあります。

＜管理＞
目の前にいれば、管理もしやすい。
稼働時間や休日出勤なども見た目に分かる。
席にいつもいない人、昼休み終わっても寝ている人などもたまにいて。。。
また、ユーザーと打ち合わせしやすいから上流設計は客先で、プログラミングフェーズは所属元で開発というケースもあります。

その他、商流が深い下請け企業に開発環境場所（オフィスが狭い）がないという実情もあります。

但し、作業場所については2020年のコロナ対応で状況が大きく変わりました。準委任契約であっても在宅勤務が増えました。
これからの働き方に注目していきましょう。

（指揮命令について）
指揮命令の明確化は、技術者や管理者にとって大切なことです。
前回の記事で述べたように、準委任契約と派遣契約での最大の違いは、指揮命令者が誰かということ。
SESでは自社の責任者が指揮命令者。
であるはずなんですが…

ユーザー、下請け会社、技術者ともに勘違いしていることが多い。
特にユーザーがここで述べているようなことを、全く理解していない人がたくさんいます。
準委任と派遣の違いが分からなければ、ユーザーが技術者に対して作業指示（命令）を出してしまいますよね。
受託者側の特に管理者はよく理解しておかなくてはいけません。

正しくは、ユーザーがSESの責任者（指揮命令者）に対して作業依頼を出し、SESの責任者が技術者に対して作業指示を出す。

このことが守られていないプロジェクトが多いのが実情です。
客先常駐にて、契約違反をおかし、ユーザーが指示命令をどんどんと出すという状況は、よい就業先とは言えないでしょう。

（商流について）
システム業界特有の商流。商流にはSESが大きく関わっています。
商流については、私の別記事にまとめています。そちらをご覧ください。

準委任契約は、基本的に再委託が禁止されています。
しかし、上位会社が認めれば再委託が可能です。
※契約内容によるので契約書をご確認ください

（責任範囲について）
これはユーザーにとって問題。
請負契約は、納品・検品後にようやく売上計上となります。
準委任契約では善管注意義務を怠らなければ問題ない。

この善管注意義務というのがあいまいです。
一生懸命やっているのか、手を抜いているのか。
あきらかな怠慢（欠勤が多い、業務中寝る、悪意をもった行為など）でもない限り、
本人しかわからない。
成果がでなくても支払いは契約どおりにしなければならない。
ユーザーからみると不安が残る。

準委任契約を逆手にとり、無責任な対応や悪意をもって怠ける技術者が残念ながら存在することも事実です。
また、開発会社や技術者都合で無責任なプロジェクト離任。
こういったことも多い事例です。

もちろん、多くの技術者はユーザーのため、自分の技術力向上のために努力しています。

（＊SESの問題点）
SESはよく問題が多いと言われます。 ここではSESの何が問題なのかを見ていきます。

確かにSESは多重商流を招きやすい。
また、請負契約と違って成果物にコミットしていないので、依頼されたことだけを対応しておけばよいというマインドを持ちやすい。

しかし請負契約や派遣契約が適さないケースがある。
準委任契約に頼ったシステム開発の数は多い。

SESや準委任契約の是非について議論しても仕方がないと私は思っています。
では、何が問題なのか？

SESという仕組みを利用し
　・技術者紹介だけをやって利益を抜く会社
　・技術者に問題が起こっても責任を取らず逃げてしまう会社
　・技術者の育成を全く考えない会社

このような悪徳会社が問題なんです。
SESは、このような会社が生き残れてしまう契約でもあります。

こんな開発会社にいる技術者は不幸です。
こんな開発会社を経由している下の商流の会社も不幸です。
では、どうすればよいのでしょうか？

ユーザー（発注側）は、責任をもって仕事をしてもらえるシステム開発会社に発注する。
システム開発会社側も、再委託する際は責任をもって対応する会社に発注する。

うちの会社では、請負でも準委任契約でも責任感をもって仕事をしています。
一次請けとしてユーザーとコミュニケーションをとり
システム完成後の保守開発まで担当します。
（SIerの立ち位置です）
お客様との永続的な信頼関係が弊社の経営理念です。

◆請負契約の実情と問題点

請負契約の実情と問題点についてみていきましょう。
準委任契約と違い請負契約は成果物責任があります。
そのため成果物に対する対価（開発費用）を先に決めます。
この見積りやその後の仕様変更などで、多くのプロジェクトが失敗しています。以下、見ていきましょう。

（見積失敗：ユーザー側の起因）
ユーザーはシステムを発注するための予算取りや稟議のため、開発見積額が必要です。
システム要件があいまいなまま開発ベンダーに見積りを求める。
そして見積書がそのまま注文書に。

その後、システム要件が進んでいくうちに開発コストが収まらなくなった。
しかし予算は確定しているため追加予算が出ない。
その分、開発会社にしわ寄せがくるというパターンはあります。

また、自社の予算都合のためゴリ押しして不当に開発予算が少ないといったこともあります。

（見積失敗：開発会社側の起因）
開発会社が起因となる見積り失敗例は以下のようなものがあげられます。
・見積担当者の経験が乏しく見積りがあまい
　開発ベンダーが自社で対応したことがない新技術や
　業務システムなどの場合に見積コストを過小評価
　してしまう場合があります。
・コストが合わなくても営業として取りたい、受けざる負えない
・予算内に収まるようにシステム要件をまとめられない

（仕様変更が多くプロジェクト炎上）
少々の仕様変更は可能です。
しかし度重なる仕様変更はシステム開発コストがあがります。

仕様変更を出さないようにするのは難しい。
・ユーザー側の役員やキーマンから仕様変更依頼があった
・ユーザーと開発側で認識の齟齬があった
・必要な機能が後から分かった　など

ユーザーには仕様変更による開発への影響が見えにくい。
仕様変更は、計画の再検討、工程を遡り二重作業、他機能への影響調査、要員の再配置、などに影響を及ぼします。
仕様変更対応は、非常にコストがかかります。

（まとめ）
知り合いの大手SIer営業マンがうまいことを言っていた。
「システム要件が決まらないのに見積らなければならない。
　エスパーじゃないんだから見積もれない。」

その後、この営業担当者は上司に命令され、不安ながら見積書を提出していました。そのプロジェクトでは多くの犠牲者がでたことでしょう。

見積りの失敗や、要件定義のあまさ等による度重なる仕様変更。
このしわ寄せは技術者に降りかかります。
開発費用が過小に少ないと、少人数で、経験不足な技術者、無謀な短期間でのスケジュールでシステムを開発しろ、となる。
今までどれだけ多くの技術者が苦労したことか。

私もこのケースで何回も被害に遭いました。
（だから、私はシステム業界をよくしたいと心底考えています）

無理な納期に対して品質を問われる技術者が不幸。
納期に間に合わず、バグの多いシステムを受け取るユーザーも不幸。

国内のプロジェクト開発の三分の二が、予算や期間の問題を抱えているという記事を目にしたことがあります。

請負契約は発注側と受注側の双方が協力しなければ成功しません。

◆派遣契約の実情と問題点

派遣契約の問題点についてみていきましょう。
※ここでは自社で一人だけ派遣されるケースを例にとります

（技術者の成長）
技術者が一人前になるには相当の時間が必要です。
また一人で習得することは難しく、先輩社員から指導をしてもらう場面が多い。
自社の先輩がいない場合、ユーザーや他社の技術者から教えてもらう必要がある。教える側も自社の社員でなければ、多くの時間を使ってくれることはあまりないでしょう。
派遣契約の場合、技術者として成長することは困難が伴います。

（責任の認識違い）
システム開発の最中に、技術者の都合で離任。
こういったことは準委任契約、派遣契約ともに多い。
派遣は契約期間があります。満了すれば契約を終わらせることは委託者、受託者ともに自由です。
契約期間中に役割を果たすことを前提とした契約が派遣契約です。
システム開発を完了することに責任はない。
よってシステム開発が大変な状況であっても、契約満了すれば自己都合でプロジェクトを抜けることも自由なのです。
発注側はそのことをよく考えて契約する必要があります。

（管理工数）
請負契約はもちろん、準委任契約も受注側に管理義務があります。
派遣契約は指揮命令が派遣先にあります。
発注側は派遣者の管理をする必要があります。
管理には多くの工数が必要です。
ユーザー（発注者）は適任者が自社でいるか、管理者がいない場合にどのように対処するかを検討しておく必要があります。

（その他）
以前は特定労働者派遣の手続きが簡素だったため、技術者を派遣することが容易にできました。技術者を雇用し、客先へ常駐させる。一般労働者派遣のような決まり事がなかったため、技術者の待遇はひどいことが多かった。
現在では法改正により特定労働者派遣はなくなりました。
労働者派遣を保有している会社は、会社のホームページに記載しているため容易に確認できます。

◆会社選びのアドバイス

Googleで検索すると「SESはやめとけ」などのキーワード候補が出ます。

上記のようにSESが悪いわけではない。
しかし、SES企業の中には悪徳会社も存在します。

まず、企業を見極めようと努力することが必要です。
技術者を育てようとしているか、
育成制度は整っているか、
深い商流の会社ではないか、など。

会社説明会や面談時には
請負契約の有無、客先常駐の割合、派遣の割合
などを聞いてみてください。
その会社の方針が分かると思います。

◆さいごに

SES、準委任契約、請負契約、派遣契約についてみてきました。
難しい箇所もあったでしょうか？

まず契約内容を理解すること。
各契約には良い点や問題点があります。
システム開発の状況に適した契約をすることが肝要です。

担当している技術者が不幸にならないよう、
世の中に理不尽なことが起きないように願っています。
システム業界が少しでもよくなるように。

それでは。

（「ＩＴ業界の仕組み　その１３」に続く）

ここでも語っていきますが
noteでＩＴ業界やエンジニア、社会人として成長するための記事を連載しています。
もしご興味ある方は、以下からお願いします。
note　政平秀樹
https://note.com/masa_hide