僕がSIerを辞めた理由

今さら感が強いですが、去年の5月にSIerを辞めました。 その前の会社とあわせて6年ほど(途中6ヶ月ほど育休期間があります)受託開発がメインのエンジニアをやってきましたが、いろいろ思うところがあって受託開発ではないところに転職しました。 その理由を差し障りのない範囲で残しておこうと思います。

本題に入る前に

あらかじめいくつか断っておくと、 SIerと言ってもよく言われるような多重請負構造の中でやっていたわけではないので、大手SIerのやり方とか下請け業者の苦悩とかはネットで見る程度の知識しかありません。 この6年間は幸いにもほぼ直受け案件でしたので中間搾取もなく給与水準が著しく低かったというようなことはないです。それから、勤務場所も自社内だったので客先に打ち合わせに行く場合を除いてスーツを着ることもないですし、勤務時間や有休取得についても結構自由はありました。 開発環境についても低スペックマシンを押し付けられていた、ということもないです

理由一つ目

さて本題です。 理由の一つ目は、技術力という観点です。

Google検索で"SIer 技術力"と入れると、"低い"と候補が表示されるように、散々言われてきていることかと思います。 よく言われることとして、プログラマの能力が低い(そもそもない)だとか、使っている技術が古いだとかあります。プログラマの能力云々については僕なんかが評価できる話ではないですが、向上心のないのだけは嫌ですね。

ただ、これは転職を考え出した時点から、情報収集、実際の転職活動を経るにつれてだんだん薄れていきました。

技術力なんて受託開発かどうかにかかわらず高いところは高いし、低いところは低い。今になって客観的に見てみると前職が技術力が低いとは思わないですし、昔に在籍していた受託開発ではないベンチャーの技術力にも疑わしいところがたくさんあります。

とはいえ、技術力が高い会社には技術力の高い人が入りたがる、というのはあると思いますので、そういう意味で技術的な成果をオープンにしやすい自社開発をしている会社の方がそういう人が集まりやすい、というのはあると思います。

逆に、転職活動中に言われて「それも一理あるな」と思った点としては、受託開発だとプロジェクトごとに違う技術に触れられるが自社開発だと同じ技術と長い間付き合うことになる、という意見です。ただ、今回の場合に限ってはほぼ自社フレームワークという枠の中に縛られて開発しておりプロジェクトを移っても目新しいことはほとんどなかったですし、最後の悪あがきでJAX-RSとかAngularJSとかねじ込んでみたくらいです。そうではなくて、プロジェクトによって環境が全く異なるという場合を想像してみても、必ずしも新しい技術に触れられるというわけではなく、次のプロジェクトがCVS管理(極端ですが)とか発狂しちゃいます。

2つ目にして最大の理由

端的に言うと、受託開発という形態に対して疑問を感じてきた、ということです。

まずは

プロジェクトにおいて発注側と受注側で思惑が違うということです。 表面上は、「一緒にプロジェクトを成功させましょう」と言っておきながら、発注側としては「お金を払うんだから、できる限りのことはやれ(要件の追加や変更であっても)」と思っていますし、受注側は「工数が増えるような追加や変更は受け入れたくないし、余計な手間はかけたくない、追加でお金出してくれるならやるよ」と思っています。 入札案件で、新規開発時は低価格で受注しておいて、保守案件時に随意契約をいいことに高額な見積もりを出す、といったようなこともよく聞きましたが、つまりは受注側の思惑はそういうことです。

例えば、機能の変更案が出たとして、それが元々のスコープに含まれるかどうかとか、追加の工数がいくらだとか、そういう交渉が必要になり変更が遅れたりそもそも行われなかったりすることで、コンシューマ向けにサービスを提供する場合はそのサービスが成功するかどうかにも大きく影響する可能性もありますし、業務システムの場合にも効率化が遅れたりできなかったりということになりえます。 もちろん、そこを犠牲にしてでも凝ったUIを作ったりプログラムの品質を高めるために労力を惜しまなかったりする人もいるのですが、それが会社やチーム全体の意思とはなりにくく、結局予算重視となってしまいがちです。

次に

納品すれば終わり、といった風潮もあります。これによって、発注側としては費用面から追加開発に躊躇することになりますし、受注側としては余計なコストをかけられないため、チームを解散して場合によっては運用チームに渡したり、他の案件の間に細々と担当を続けるということもあります。本来システムというのは使われるものであればあるほど外部要因や内部要因によって絶え間なく変更や改善が必要となると思っていますので、これと相反するような納品の形はシステムの価値を下げると思います。「納品のない受託開発」といった話もありますが、それができるのはごく限られた場合のみかなという印象です。

結局

僕がエンジニアとしてどういうことに幸せを感じるのかを考えてみると、難しいこと(※無謀なことではない)や新しいことにチャレンジすることだったり、新しい知識を得ることだったり、いいと思うものをユーザに届けられたり、ユーザ(※発注者とは限らない)に喜んでもらえたり、ということです。 前者2つについては受託開発をメインとしているかどうかでそれほど大差がない気もしますが、それでも受託開発の上記の性質を考えると実績のあるものがより重視されやすいため新しいことに手を出しにくいというのはあると思います。 後者2つについては受託開発は単純に厳しいという印象しかないです。

他にも

発注者は開発会社に多くを求めすぎ。

大手SIerでちゃんとしたところであれば、何から何までやってくれるんでしょうけど、中小SIerの場合はそういう工数を犠牲にしてコストを下げる代わりに他のところを柔軟に対応することで優位性を出していると思っているんで、多くを求めすぎてはいけないと思います。例えば、業務ヒアリングも1から10まではできませんし、リプレースで移行元の仕様書ソースコードもないのに完全再現はできません。そういう話を理解してもらうのも大変。

開発規模が大きくなりすぎ

受託開発の中でも業務システムのようなものになると規模が大きくなりがちです。 一般的に、規模が大きくなりすぎると先の見通しも立ちにくくなるためプロジェクト管理は困難になり、プロジェクトを分割することでリスクを小さくすることも可能ですが、以下のような理由により規模は大きくなってしまいます。

  • 分けると社内決裁等の調整が手間すぎるから(発注者都合)
  • 上記理由もあって、本来必要かどうかわからないものまで最初から含めたがる
  • まとめて受注して人員確保や売上見込みを立てたい(受注者都合)

そんなわけで

あまりうまくまとまってはないですが、 SIerを辞めました