SIer、SESで働くってこんな感じ
IT業界に未経験からプログラマーとして就職しようとした場合、
「SIer」や「SES」という言葉を見かけることがよくあると思います。
今回は「SIer」「SES」について、そこで働いた体験談をお届けします。
実務経験のある言語は
Java,Python,Kotlin,SQL,JavaScript,HTML,CSSなどで、
主にサーバーサイドの開発をしてきました。
短いもので半年前後、Javaは3年程度の経験です。
WebアプリケーションやAndroidアプリの開発をしてきました。
今回は、SIer、SESで働いてきた経験をお伝えしていきます。
IT業界について
SIerとは
SIerってご存知でしょうか。SIerは、エスアイヤーと読みます。
システムインテグレーター（System Integrator）の略で、システム開発を受託する企業のことです。
情報システムを作りたいという要望に対して、分析、提案、開発、運用、保守など、何でもやるのがSIerです。
Wikipediaでは次のように定義されています。
システムインテグレーター（英: Systems Integrator）は、個別のサブシステムを集めて1つにまとめ上げ、それぞれの機能が正しく働くように完成させるシステムインテグレーション事業を行う企業のことである。
SESとは
SES（System Engineering Service）は、一般的には準委任契約のことを指します。
対象的な契約形態に、請負契約があります。
請負契約が成果物に対して対価が支払われるのに対し、SESは働いた時間に応じて対価が支払われます。
SIerで、SESで、働いてきました（体験談）
SIerで働く
情報系でない学部を卒業してSIerに就職しましたが、研修が手厚く、システム開発の基礎知識を教えていただいたのを、今でも覚えています。
学生時代にプログラムに興味がわき、独学で勉強していましたが、体系立てて教わることができたのがよかったです。
Javaで仕事をしていきたいと思っていて、途中まで良かったのですが、プログラムを書く仕事は長くは続きませんでした。
今思えば、システムエンジニアになれるように配慮された人事だったのだと思います。
しかし、私はプログラムを書くためにプログラマーの道を選んでいたので、思っていたのとは違う業務が続きました。
勉強し、上司に幾度となく直談判しましたが、聞き入れてもらうことはなく、転職をしました。
転職先では、絶対にプログラムを書く仕事をしたいといって転職活動をして入社していたので、しっかりと携わることができました。
勉強会も豊富な会社だったので、積極的に参加しました。
SIer時代はほとんど客先常駐でしたが、たまに持ち帰りの案件があり、自社内で仕事をすることができました。
その後、別の会社では、業務があまりない案件もザラでした。
一昔前は、業務が長すぎてブラックという状況がよくあったようですが、2015年に就職した私には無縁でした。
業務がない間は、チーム内で許可を得て、プロジェクトに関連することや興味のある技術を、各自で調べて良いことになっている現場が多かったです。
その時間の中で、テストデータを生成するツールを作ってみたり、プロジェクトのソースコードを読んだりして、技術力を磨きました。
ときには、その時間の中で得た知識をチーム内で発表しあうこともありました。
SESで働く
フリーランスになってからは、自身と企業でSESを締結して、案件に参画しました。
SIer時代にもSESの形態で働いて来ていましたが、フリーになると、自分でSESの契約を結びます。
上述したとおり、SESは働いた時間に対して対価が支払われます。
新規での開発もありますが、保守案件だと、障害の調査や修正なども入ってきます。
成果物ではなく時間で動くので、見積もりが重要になってきます。
「こんな機能がほしいんだけど、どのくらいでできそう？」「この障害、あとどのくらいで直せる？」などの質問を躊躇なく投げかけられました。
心のなかでの第一声は、「やってみないとわかりません」です。
はじめのうちは的はずれな見積もりをしていましたが、そこをどうにか、知識でカバーし、見積もりを出してきました。
見積もりは経験が物を言います。
他に働いていて気づいたことですが、SESは時間で拘束されるので、働く質が下がりがちです。
システムの品質にしても、周辺の作業をやるにしても、自分次第で良くもなるし、悪くもなります。
働いた感想
SIerで手厚く仕事をいただけるのも、SESで時間を買っていただけるのも、労働者としては安心です。
一方で、自分で成長するために動けないと、プログラマーとしての成長はないと感じました。
プログラマーがSIerやSESで成長しにくいと感じる理由
理由1 エンドユーザと距離がある
実際にシステムを使用するユーザの声が届きにくいので、どういうシステムが求められているのか、わかりにくいです。
レビューやクレームを参考にしたり、想像力を働かせたりすることぐらいしかできませんでした。
実際に使われる状況やシーンを見ることができればよいのですが。
大規模な対企業向けシステムだと、用途自体が身近でないこともあります。
実際にどのようなユーザがどのように使うのか、わかった方が、プログラマーとしても良いシステムを作れると感じました。
理由2 開発のほんの一部を担うことが多い（特に大規模なプロジェクト）
システムの全体像が見えないことも間々あります。設計と実装がわかれていることも多いです。
設計もできるプログラマーでありたい私としては、物足りないと思うことが多く、
業務以外で自分の興味を掘り下げる時間を作って解消してきました。
結論 IT業界で働く上で、どこを担うか、担っていきたいかが重要
WebやIT業界は凄まじい速さで変化してきて、細分化も激しいです。
こんな混沌としている業界で、
自分がどのような技術を扱って、どのようなシステム開発のどのような工程を担いたいのか、はっきりさせていくことが、とても重要だと思いました。
体験談おまけ コミュニケーションについて
この業界はコミュニケーションができないと、、コミュニケーションが大事だから、、と、どこに行っても頻繁に言われています。
ものを創り上げるとき、意思伝達ができていないと、到底成し遂げることはできませんよね。
この点では、コミュニケーションが重要だというのは共感できます。
しかし、日本人特有のものなのかはわかりませんが、暗に汲み取る文化を、
システム開発のコミュニケーションに持ち込まないでほしいと思う場面に、何度も遭遇してきました。
このような状況が往々にして起こっているので、私はできるだけ明文化するようにしています。
常駐していても、リモートでも、同じことです。
コミュニケーションのコストは、もともとかけるべきだった部分が浮き彫りになっているだけなのでは、、と思ってしまう、リモート過渡期です。
未経験からプログラマーになりたいけど、
受託開発を行う会社と、自社開発を行う会社、どっちを選ぶべき？