徒然なるままに

学習メモがメインです

SIer(SES)から脱出した話 Part1.新卒入社〜退職編

こんにちは。最近SIer(SES)⇨Webエンジニア?(自社勤務)として転職した者です。

この記事はSIer脱出を語る Advent Calendar 2019 9日目の記事です。

今回は転職した話を書き連ねていこうと思います。筆者自身の転職活動の振り返り、そしてSESで働くエンジニアに向けた情報提供をのためにできればと思い書いています。 (SESから脱出したい人に対してキャリアを考える一つのきっかけになれば幸いです)

教訓

先に結論として教訓として伝えたいこと書きます。一番伝えたい内容なので教訓だけ読んでも大丈夫です笑

  • 先に会社辞めて転職活動しないこと

    基本的に先に会社を辞めるのはお勧めしません。金銭的・精神的な余裕が無くなり転職することが目的となる可能性があります。あくまでも転職は手段です。転職して価値を提供することが目的です。
    筆者は地方から上京してきて一人暮らし、かつ、関東で知り合いが多くないので孤独感とプレッシャーで押し潰れそうでした。。。

  • やれることはやっておくこと

    転職せずに働く環境を良くすること、実績を上げることをやっておくことをお勧めします。ネガティブな理由駆動で転職すると次に転職してもネガティブな理由で転職したくなります(と思います)。隣の芝生は青く見えてしまうものです。一旦落ち着いて自分がやりたいこと、やりたくないことを会社に相談してみてはいかがでしょうか。もしかしたら転職せずとも自分が良いと思える環境につく可能性があります。いい環境で実績を上げられば次の転職活動にも役立ちます。

  • 転職活動はなるべく早くからに行動すること

    一般的に若ければ若いほど吸収が早いです。若いだけで価値があります。ポテンシャルとして認識される期間は限りがありますので、早めにどんどん行動しましょう。

”転職活動はなるべく早めに行動すること”と”やれることはやっておくこと”は一見矛盾しているように思うかもしれません。転職活動しても必ず転職する必要はないと思っています。後悔がないように色々と行動し自身が選択できる状態にしておくことが重要です。焦らず落ち着いて、でも行動は止めないでください。

もし一人では難しい場合はメンターと相談することをお勧めします。今はググれば色々メンターのサービスがあると思います。個人的には下のサービスを使ってみるのをオススメします!

beta.kiitok.com

前職での経験

ここからは筆者の体験談を簡単に書いていきます。

業務経験

SESで主に公共系システムの運用保守SEをしていました。開発作業はあまり携わっていません。

公共系というとどういうイメージを持たれるでしょうか。お堅い、バグが許されないシステム、税金計算ミスってくれないかな(?)とかでしょうか。

筆者自身が公共系システムに携わった上でのイメージは以下の通りです。

良いイメージ 悪いイメージ
社会貢献性が高い COBOLを筆頭に開発環境がレガシー
インシデント管理、品質管理が厳格に管理されている 安定第一なので実績のあるレガシーな環境から脱却することが非常に困難

ただ、その手段がエクセルスクショは好きではありませんが、品質管理が徹底していたのは自分にとって合っていた部分かな〜と思ってます。

業務以外での学習(資格取得)

  1. Oracle Master Bronze 12c
    • RDBMSを使うために最低限SQLの知識を得るため
  2. Oracle Certified Java Programmer, Bronze SE 7/8
    • Javaを覚えるため
  3. 基本情報技術者試験
    • 一通りの情報の知識を覚えるため、Javaを覚えるため

SQLは汎用性が高いのでこのスキルを取得できたのは結構重宝しています。
Java身につけるために基本情報とJava Bronzeとりました。基本情報の午後の過去問を写経してEclipceで実行・デバッグしてました。当時はやってやった感がありましたね笑
一方でJavaのBronzeの試験は簡単すぎて取った意味ないです。最低限silver以上で良いと思います。

個人的には学習方法は資格ではなく、別の方法をお勧めします。(Progateとか簡単なアプリ作るとか)

退職理由

以下の理由で退職しました。勢いよく、次の会社が決まる前に退職しました。

  1. SESという働き方に納得できなかった

    就職する前から客先常駐で作業する認識は持っていました。あくまで自社の人間として常駐して作業するイメージを持っていました。ですが、実際には常駐先の名刺であったり常駐先の会社名を名乗って作業することが多く、自分がどこの所属するのかわからなくなっていきました。
    また、常駐先が大体3〜6ヶ月ごとに代わり、その度に転居を伴うのがかなり苦痛でした。常駐先の現場は案件の都合によるものとわかってはいてもしんどかったです。

  2. 汎用性の高い開発スキル・技術スキルを身に付けたかった

    そもそも開発作業にアサインされない、されてもCOBOLといったレガシーな言語での開発でのアサインとなってしまい、技術力が向上しないし実務経験を積めない危機感がありました。

  3. 生産性を上げて業務を遂行したい

    gitなどのバージョン管理ソフトウェアがないので過去ソースのdiff比較が手間だったり、テストを手動でやってエビデンスとしてスクショをエクセルに貼り付ける作業など、時間の無駄に耐えられませんでした。その時間を別の作業に充てた方がよっぽど生産的だと思ってました。

  4. 技術的な部分は外注すれば良いという考え方 会社というより業界構造の話かもしれません。下流工程(開発作業)は軽視され、ユーザーと接する上流工程の方が重要視され単価が高い点に違和感を抱いていきました。筆者としては開発もユーザーと接するどちらにも携わりたいし、どちらもやれるチーム・組織でないと今後変化に対応できないのではないかと考えています。

反省点

転職しよう!と決めてから、前職でで環境を良くしようと努力していない部分もあったな、、、と今考えれば色々あります。

  1. "スキルアップの機会は会社が与えてくれるもの"という勘違い

    スキルを身につけないと!と常々思ってはいました。
    技術スキルを身につけるには実務経験が必要。そして実務経験を見につけるには会社から案件としてアサインされることが必要。でも結果的に開発作業を通して技術スキルを向上できる案件にはアサインされない。

    自身がスキル不足にも関わらずただ単に会社が悪い!と思ってしまっていた。 なぜアサインされないか分析できていないし、すごくアピールもしていたかというと、できていなかった部分が多かったと思います。 待っていてもチャンスは掴めないので自分から身につけることに途中から気づきました。

  2. 会社との話し方、立ち回り方

    会社の考えを理解する努力を怠っていたと思います。途中から信用できないと自分自身で勝手に決めつけが入っていた部分もありました。案件についても”ただ開発がしたい”と言った、目的や背景を正しく伝えられず、間違った認識を与えてしまっていた部分もあったと思います。コミュニケーションの難しさ・能力の低さを感じ、理解する姿勢をもっと持つべきではなかったのかと反省しています。

さいごに

書きたいことが当初の想定よりどんどん増えていってボリュームが多くなってしまいました...まだ書きたいことはあるのですが、取り留めが無くなってしまうのでこれくらいにします。
次回は退職〜転職活動を書く予定です。多分今回よりボリュームは少なくなるはず...です。

最後まで読んでいただいてありがとうございます!これを読んでくれた人が楽しい仕事につけることを願っています。目指せ!仕事が楽しい状態!!