システム開発の業界では客先常駐の形態がとられていることが当たり前のようになっていますが、そこで働くエンジニアにとって客先常駐は害悪でしかなく、私は常々この業界から客先常駐（SES）が消滅してほしいと願っております。「この業界」と書きましたが、本音を言えば我々のようなシステム開発会社と客先常駐の会社が同じ業界に分類されることでさえ嫌気がさしています。
これからシステム開発の業界を目指す学生の方々には、就職した後になって「こんなはずではなかった」とならないように、正しい情報を知っていただきたいと日々情報発信に務めております。つい先日も下記のようなことをブログに書きました。
この記事ではどちらかと言うと、会社を選定する際に客先常駐のSES企業を見分ける方法についてまとめたものですが、本日は不幸にもSES企業に就職してしまって客先常駐の仕事をすることになると実際こんな感じになるよ！という内容をまとめてみました。
何度も面談を行うことになる
常駐先となる顧客と何度も面談を行うことになります。一度で常駐先が決定するとは限りませんから、決まるまで何度でも面談が行われます。せっかく就職活動で何度も面接して入社したのにまた面談の嵐です。場合によっては常駐先となる顧客だけではなく、間に入って中間マージンを搾取する会社の人とも面談する場合もあります。
営業の人に連れられて面談場所へと向かうわけですが、途中で中間マージンを搾取する会社の営業の人に奴隷のように引き渡されてから常駐先の現場となる顧客のところへ面談に向かう場合もあります。
派遣契約の場合だとこのような事前の面談は禁止されていますが、彼らは実態は派遣なのに派遣契約ではなく請負契約や準委任契約の形を取ることによって面談してもOKという詭弁をふるっています。
経歴詐称を強要されることがある
客先との面談では「スキルシート」というエンジニアのスキルや経験プロジェクトを記入したものが客先に提示されます。このスキルシートの内容に虚偽の内容が記載されて客先に提出されてしまうことがあります。
なぜ虚偽の記載をするかというと、その方が単価が上がるからです。契約も取りやすくなります。実際にはほとんど経験したことのないスキルが経験豊富であるかのように記載されたり、エンジニア経歴が１年しかないのに３年あるかのように嘘が書かれることもあります。自社の営業や、中間マージンを搾取するために間に入っている会社が勝手に書き換えてしまう場合もあります。
できないことを「できます」と言わなければならない。経験していないのに「やってました」と言わなければならない。辛いですね。こんなことを平気でやってしまう営業がうごめいているのが客先常駐の世界です。
他社の名刺を持たされることがある
客先によっては再委託を禁止している場合もあります。これは派遣契約で禁止されている多重派遣を気にしてのことだと思われますが、再委託禁止と言われたところでSES企業はそんなことには物怖じせずにたくましく営業活動を展開します。
エンジニアに偽造した他社の名刺を持たせて、間に入っているよその会社の社員であるかのように振る舞わせて客先の面談の場に向かうのです。１社しか勤めたことがないのに、なぜか色んな会社の名刺を持っているというエンジニアの方もいらっしゃるのではないでしょうか。
長机の狭いスペースの現場が多い
さて、色々と問題はありますが経歴詐称や他社の名刺をフル活用して何とか参画先のプロジェクトが決定したとします。しかし客先常駐の現場というのはなぜかエンジニアにとって過酷な環境であることも多いのです。
その代表例としてあげられるのが、長机の狭いスペースの現場です。
快適に仕事を進めるためには最低でも１２０センチ程度の横幅は必要なのではないかと私などは思うわけですが、長机にキツキツに詰めて座らされて開発をしなければいけない現場が珍しくありません。イメージ図としてIPAの資料に載っていた図を載せておきますね。
この資料によると１９８８年からこんな感じのようですね。きっとこれからも客先常駐の現場ではこの伝統が大切に守られていくことでしょう。
貧弱なスペックの開発マシンが多い
もし客先常駐の現場で高スペックの開発マシンを割り振ってもらえたとしたら、それはものすごく幸運なことです。多くの場合ではスペックの低い貧弱なマシンが支給されることがほとんどです。
開発の生産性を高めたければ少しだけお金を積んで高スペックなマシンを用意した方が絶対に費用対効果が高いことは明らかなのですが、客先常駐の関係者各位はそういうことまで頭の回らない残念な人達が多いので、余っている貧弱なパソコンを回してきたりします。とても開発用とは言えないような悲惨なスペックの場合も普通にあります。
開発用のマシンが貧弱であるということは、エンジニアにとってはそれだけで仕事のモチベーションを奪うだけの十分すぎる理由になります。ドラクエで言えば勇者にずっとどうのつるぎを装備させて戦わせているようなものですね。これではまともな戦いなんてできっこありません。
偽装請負が行われている
客先常駐の現場というのは偽装請負の温床となっています。客先常駐なのに偽装請負が全く行われていない現場を探すことは極めて困難でしょう。偽装請負とは、労働者としての権利は与えないままに労働者としての義務だけ課すという卑劣な行為です。
客先常駐の現場に投入されると、他社の人間から業務の指示をされることが日常茶飯事となってしまいます。客先常駐には様々な問題があるのですが、その多くは偽装請負に根っこがある問題と言えます。
長時間残業が蔓延している
通常の会社であれば労務管理の責任は当然その従業員が所属している会社にあります。会社は従業員が普通に働けるように労務管理を行いますが、客先常駐（SES）の場合はそういうわけにはいきません。エンジニアはずっと客先にいますので管理もクソもないのです。
本来であれば指揮命令をする人が労務管理も行わなければなりませんが、客先常駐の現場では指揮命令してくる人はいますが、はっきり言って労務管理の責任の所在は曖昧な状態となってしまいます。誰もしっかりと責任を取る人が存在しません。
その結果としてエンジニアの稼働が上がって長時間残業が常態化していても、誰も何の対処もしてくれないなんてことが起きてしまいます。
契約時間の上限までこき使われる
SESの契約では月あたり「１４０時間～２００時間」のように労働時間の上限と下限が定められることが一般的です。このこと自体は準委任契約であればおかしなことではないのですが、客先で常駐してしまっていますので指揮命令の権限が自社になくなってしまっていると問題が起きます。
客先で他社の人間が指揮命令しているような状態だと、自社にはどのように業務を行うかという裁量がなくなってしまいます。そうするとブラックな顧客が「契約時間の上限まで働かせないと損だ」と言い出すことがあります。
せっかく効率よく仕事を進めて残業ゼロで帰れるような状況であったとしても「あいつは早く帰っているけど２００時間ギリギリまで働かせろ」なんて言う人が出てきます。もう違法であることなんて全く気にせずにやりたい放題です。
休む時は自社と客先で許可が必要
客先常駐の現場で仕事をしていても有給を取りたい時はあります。有給は労働者の権利ですから当然のことですね。そして有給は自分が所属する会社に申請すれば原則として好きな時に取得することができます。
ただしSESで客先常駐をしている場合にはそうはいきません。自社だけではなく、客先でも休みの承認を取らなければなりません。自社で有給取得OKと言われても客先がNGを出せば休むことはできません。おかしな話ですよね。
自社で有給取得出たからと言って、客先で承認を取らずに黙って仕事を休んだら多分客先の人が顔を真っ赤にして怒ってしまいます。嘘でも「偽装請負ではない」と言い張るのであればせめてこれくらいは筋を通してほしいものですね。
休みすぎると各所からクレームが入る
無断欠勤のようなことを繰り返してしまえばそれを咎められてしまうことは仕方ありませんが、客先常駐の現場では普通に休もうと思っただけでもクレームが入ることがあります。
SESの契約では月あたり「１４０時間～２００時間」のように労働時間の上限と下限が定められていると言いましたが、この下限を下回るようなことがあると契約で定められている単価を割り引いて精算するようになっています。つまりこのケースだと月の労働時間が１４０時間に達していないと企業は売上が下がるということです。
そうするとですね。まずは自社の営業からクレームが来ることがあります。１４０時間を下回るようだと困る。休日出勤でも残業でもして１４０時間は何としてもキープしろと。さらに契約の間に入って中間マージンを搾取している会社からも同じクレームが入ることがあります。お前ら何もしてないんだから黙ってろボケ！と言いたい気分です。
GWとか年末年始とか営業日の日数が少ない月だと、特に休みを取らずに普通に働いているだけでも契約時間の下限を下回ってしまうようなことがたまにあります。そうすると無駄に残業したり休日出勤したりするように営業から指示がくるようなことまであります。その営業が普通に休日を満喫していたりするとグーで殴りたくなってしまいます。
効率よく働きすぎると嫌がられる
普通の会社だと効率よく仕事を進めて早く仕事を終わらせれば喜ばれます。これが普通の会社です。しかしSESの場合はそうではありません。
SESという仕事の形態は、労働時間とセットで契約単価が定められていますから、あまり効率的に働きすぎて早く帰られてしまうと契約に定められている労働時間の下限を下回ってしまうリスクがあります。だから必要以上に業務効率化を進めてしまうと本当に嫌な顔をされます。
私が以前いた常駐現場で効率よく仕事を進めた時にやることがなくなってしまったので、次の仕事を振ってもらうようにPMにお願いしました。最初のうちは新しい仕事を振ってもらっていたのですが、だんだん次にやる仕事が枯渇してきてしまい本当にやることがなくなってしまったので「帰っていいですか」と聞くとそれはダメだと言われる。頼むから時間までは席に座っていてくれと言われました。
その現場ではセキュリティ上の都合でインターネット接続が一切されておらず、当時はスマホなんてものもない時代でしたので、仕事もなくてインターネットも使えないと本当にやることがありませんでした。やることが何もなかったので私は常駐現場のビルの１階から１０階までの階段をダッシュで往復して体力トレーニングしてました。しかもスーツで。（実話です）
それでも次の仕事が枯渇したまま帰らせてもくれないので、とうとう私は鬱になりそうなくらいに病んでしまい、暇すぎて辛いのでもう抜けさせてくださいと言ってそのプロジェクトを抜けさせてもらいました。（仕事くれないくせに中々抜けさせてくれなかった…）
SESでは効率的に仕事をすることよりも、契約で定められた時間におさまるように程よく働くことの方が喜ばれます。契約時間の下限を切ってしまうくらいに効率よく働くと本当に嫌な顔をされてしまいます。
組織としてのノウハウの蓄積がない
客先常駐ではなくて全て持ち帰りで仕事をするようになって、客先常駐と持ち帰り開発の大きな違いで気づいたことの一つが、客先常駐だと組織としてのノウハウの蓄積がないということです。
アクシアでは持ち帰りの形でシステム開発の仕事をするようになってから約１０年になりますが、１０年の間で色々と失敗もしてきてますけどその経験やノウハウは全て組織として蓄積されてきています。前回までのプロジェクトで得た教訓は次のプロジェクトに活かされ、新たな仕組みを作ったりそれまでの仕組みをブラッシュアップしたりしてきました。
しかし客先常駐のスタイルだとプロジェクトごとに各所からメンバーが招集され、プロジェクトが終了すると解散です。基本的にはこれを繰り返します。個人としてそのプロジェクトから得るものはあるでしょうが、組織としてノウハウが蓄積されるようなことはありません。新しいプロジェクトではまたゼロからの出発となります。
プロジェクトごとに解散してしまうので、少し工数のかかってしまう業務効率化の仕組みだと見送りになってしまいます。そのプロジェクト単体では費用対効果が見合わないからです。しかし持ち帰りでシステム開発をする場合だと、他のプロジェクトにも適用して以後長く効果が得られるのであれば、例え一つのプロジェクト単体では赤字となってしまうような業務効率化のための施策であっても「実施する」という判断もありえます。
その辺りの事情も客先常駐だと業務効率化が進まず長時間残業が常態化してしまっている要因の一つと言えるでしょう。
帰属意識が低下する
帰属意識低下の問題は客先常駐で仕事をしている多くのエンジニアが遅かれ早かれ抱えることになる問題です。自社ではなく他社に常駐し、どこの会社の所属なのかわからない人達とも一緒になって常に仕事をしていますので、自分は一体何者なのかと悩むようになります。別にこの会社の社員である必要はないのではないかと思うようになるのです。
中には帰属意識の低下という問題を乗り越え、「別にどこの会社でもいいや」と常駐エンジニアとしての境地に達している人も中にはいますが、一方で帰属意識の問題で悩み続ける人も存在するのが実情です。
普通に働いていている場合は「帰属意識」というものを中々認識することすらありませんが、働く人にとっては意外と大切なものなのかもしれません。
年齢を取ると仕事がなくなってくる
SESの案件では年齢の上限設定がされていることが珍しくはありません。３０歳まで、４０歳までと年齢指定されていることが当たり前にあるのです。
実際に年齢制限にひっかかってしまって次の案件を見つけることができずにこの業界を諦めてしまうエンジニアの人も存在します。実力さえあれば年齢など仕事の成果には本来全く関係ないことなのですが、悲しいことにSESの世界では年齢も重要な要素であることが事実です。
学生の方々にはこれを読んでいただき「こういう世界で働きたい！」と思ったのであればSESの会社にご応募されると良いかと思います。しかし「これは思っているのとは違うな」と思われたのであれば、全力で客先常駐を事業としているSES企業を回避していただければと思います。
まともな客先常駐のシステム開発というものを私は見たことがありませんが、もし存在したとしてもその比率は０．００１％くらいではないでしょうか。（この数字は感覚的なもので統計データ等はありませんｗ）
何も知らずに入社してみたら「こんなはずではなかった」とならないように、システム開発の業界を目指す方の少しでも参考になれば幸いです。
