SIerに7年いて幸せで染まりかけたのに、年収1000万を手放してWeb業界で本当にやりたかったこと(前編)

この記事は、#しがないラジオ 2 Advent Calendar 2018 - Adventar の21日目の記事となります。

adventar.org

はじめに(本記事の位置付け)

私は今年の6月に野村総合研究所(以下NRI)を退職してスタートアップでエンジニアとして働き始めました。 はじめにメンターとしてついてくださったのが「gamiさん」

twitter.com

でした。その時はgamiさんはしがないラジオをやっている、SEからWeb系に転職って同じ境遇だなあと思っていたくらいでした。 今回弊社でも社内のEngineer Blog と、PLAID Advent Calender のブログとして一つ書き、なにか個人的に記載するネタを、ということでこの退職エントリ的なものを書こうと思いました。

tech.plaid.co.jp

qiita.com

しがないラジオは聞いたことないのですが、SIer脱出マニュアルはこれを機に読ませていただきまして、共感する箇所が多々ありました。どうSIerから転職するかとか、転職のためにどのような活動を行うべきかという観点では他のブログなどで多く語られているかと思いますので、今回はなぜSIer向きで幸せだったのにやめるまでの決意に至ったかの考え方に焦点を当てたいと思います。

SIerからWeb系への直近の実例ではgamiさんも取り上げられている「おれの遺言を聞いてくれ」で話題になりましたね。

oreno-yuigon.hatenablog.com

私の実例としてはSIerは7年いて給料もよかったですし、このままずっと定年まで会社にいるのかなと思っていましたし、正直幸せでした。そんな私が30歳目前で転職(転職先はまだ弊社に決まっていませんでしたが先に退職しました。)をした理由と敬意について一実例として読んでいただければと思います。ちなみに退職理由も前職に説明して温かく送り出していただいていますので、ご安心ください。。

対象読者

  • エンジニア・ビジネスサイド問わず、30代未経験でレーンチェンジを考えている方
  • SIerでSEからWeb系に転職を考えている方
  • SEでも幸せな路線を探している方
  • ITコンサル志望の方
  • SEで技術が好きな方

1.文系学部生から技術を身につける(SE1年目〜3年目)

私は私立文系の学生(経済学部)でした。コンサルを目指していて、戦略・業務・IT・会計etc..たくさんあるコンサルタントの中でも、組織の仕組みや構造を改善することにフォーカスしたく、IT業務コンサルを目指していました。そのために先に技術を習得するべきだと思い、技術が身につき優秀な社員が多いと聞きNRIに入社しました。文系学部卒の私からしたらプログラミング言語って何?状態から始まったので、周りの理系院生の同期たちは研修や業務の習得スピードが早く、とても距離が遠く感じました。今考えると文系学部生→IT企業でSEというのは一種のレーンチェンジだったのかもしれません。

大企業の場合は育成担当や部としても育成計画を立てるため、手を動かせるSEとして一人前にさせよう、という社内の方針もあって、開発(COBOLでしたが、、)や本番作業などを経験させていただきました。初心者なりにもITというものがプログラムやデータの作りが肝になること、一緒に働いていた手を動かせるパートナーさんやNRI社員はとても印象深かったです。いつかはプログラムやデータを自在に操り、手を動かせる人材になれると思っていました。

目の前の業務をこなすことが不安を取り除くことが第一優先で、作業内容も2年目からはマネジメント業務(パートナーさんの開発やテストの管理など)がほとんどになってくるのですが、2〜3年目くらいまではDBの移行作業や本番データのパッチ当て(データの更新作業)、開発環境の調査など手を動かせることがありましたので、技術を身につけることにあまり違和感を覚えていませんでした。

ただ、技術を身につけるという意味だと途中ではあっていたのですが、1年目以降、ものづくりが自分でできる & プログラムを作る、という面では全く経験していないことに少し違和感を持ち続けながらも、目の前の業務に精一杯でした。

2. SEとして一人前になる(SE4年目〜6年目)

そんな違和感を持ちながらもSE3年目までに2プロジェクトを経験し、3つ目の金融系プロジェクトは4年ほど長く経験するプロジェクトとなりました。給料も上がっていくし、仕事としても任される範囲の規模も大きなものになっていくので、成長している実感はあったので充実していました。業務内容としては本番障害の緊急対応や、超大規模(最大数百人規模)だったプロジェクトのライブラリ管理担当として7〜8つもあるサブシステムの開発調整を行ったり、複数サブシステムにまたがる開発の顧客への説明資料の作成や仕様やシステム設計のとりまとめを行ったりしました。IT初心者だった私がプロジェクトの中核を担うまでに貢献できていたので、安心感を覚えていたのがこの頃でした。プロジェクト全体のモジュールの構成変更などを考えて推進してたのもありましたし、技術としても設計してプログラムの構造まで携われていることに満足していました。このまま定年までいくのかと疑ってなかったですし、幸せでもありました。

3. G's academy でWeb業界にふれる(SE6年目後半〜7年目前半)

そんな中、仕事に余裕がでてきましたし、プロジェクトとしても落ち着いている時期だったので、私はやっぱりプログラミングができていないことの違和感を思い出します。社内のプログラミング関連の研修を受け出して、自分でも集中的にやるべきだと思って自腹で数十万払い、まずは普通のプログラミングスクール(Java silverくらいまでの授業)に通いました。平日の日中は業務、夜はプログラミングスクールでしんどかったですが、少しプログラミングに関して理解が深まりました。ただ、ものを作れるレベルかというと演習をなぞるレベルにとどまってしまい、プロダクトを作れるようになった!とまでは行きませんでした。これが6年目後半〜7年目始めくらいの話です。

7年目の夏頃、まだ辞める気は全然ありませんでしたので、他にもプロダクトを作れるようになるプログラミングスクールはないかと探し始めました。そこで出会ったのが「G's academy」です。 私はこの Dev 9期生として試験に合格し、通うことになるのです。ここが大きな人生の転換点でした。

gsacademy.tokyo

HTML、CSSの基礎からJavaScriptPHP、Laravelなど毎週土曜日に授業が行われ、木曜日までにその技術やそれ以降に習った技術を使って課題を作成します。また出てくる技術もWeb業界では一般的なのかもしれませんが、今まで関わったことのない技術ばかりだったので、毎週ワクワクしていたのを覚えています。この時はまさにプロダクトを作る、という私の7年間解消できなかった違和感を解消できそうで、とても楽しい期間となりました。金曜夜の徹夜でプログラミングする合宿に参加するなど、ほんとうに夢中になってコードを書き続けました。

4. 本当にやりたかったこと (構造や処理を考えるワクワク感)

G's academyで講師のWeb系のエンジニアさんと話す機会やLTを聞く機会が多くなり、SEとWeb系のエンジニアで大きな違いがあることに気づきました。

  • SE:構築した後の「管理(設計書や顧客調整やプロジェクトマネジメント)」や「顧客の業務」をメインに業務を行う
  • Web系:「構造(アーキテクチャ)」または「処理(プログラム)」についてメインに業務を行う

toBでの話です。toCは顧客=ユーザーの利用となります。

私のPLAID Engineer Blog でも書いたのですが、下記のようにどのシステムも構造(アーキテクチャ)、処理(プログラム)、管理(設計書や顧客調整やプロジェクトマネジメント)、「顧客の業務」、「生み出す価値」で構成されます。

2.1 価値創造のためのシステムとその構造について:を参照

tech.plaid.co.jp

SE(NRIのような顧客向かいがメインなSIer)はクライアントの個社用のシステムを作っているので、業務にどのような影響があるか、を深く知っていなければなりません。NRIでやっていた金融系のプロジェクトでは、金融の業界知識がないと顧客の求める仕様もわかりませんし、個社用のシステムは構築できないため、業務知識や管理にパワーが割かれます。既に構築された構造を変えにくいシステムを運用するには、管理にフォーカスして業務の影響がないようにコントロールすることがメインになります。新規構築だったとしてもNRI社員だけだと単純に人手がたりないのでパートナーさんに仕事をお願いするのでその管理業務もメインとなります。

社内を見てみても自身でプログラミングをしている人とか新技術の話をしている人はマイノリティでした。(私がジーズアカデミーで習った浅めな情報を話しても知らない人が多数でした。)技術ぽい人は本当に少数で、そこの人がいる部署に異動できるのかもわからない状況でした。

WebエンジニアはtoB系だと業務知識は少なからず必要になるかとは思いますが、LTなどの界隈をみても技術志向のエンジニアのLT内容は、新しいフレームワークだとか、JavaScriptの仕様が新しくでたとか、k8sの新しいアーキテクチャだとか、Google Cloud Platform の使い方だとか先進的な技術をSIerよりは積極的に取り入れているように見えました。私はこのような「構造」「処理」をメインに語れるエンジニアって かっこいい!とここでもワクワクしたことを覚えています。

そうなんです。私は、

  • 「プロジェクトマネージャとして業務や管理をメインに語れるロールモデル」よりも、
  • 「webエンジニアとして構造と処理をメインに語れるロールモデル

のほうがマッチしていると思ってしまったのです。

そこから完全にスイッチが入ってしまい、webエンジニアになると決めました。

5-1. 本当にやりたかったことを判断する切り口1 (会社に勤める理由3要素)

やりたいことを受けて、会社をやめるにあたって基準があるみたいです。どこでいっていたか忘れてしまったのですが(twitterかなにかだったかと思うんですが)、下記の3点の内2点に魅力がなくなると人は仕事をやめる、ということを見て、納得感が強かったことを覚えています。

  • 仕事

私の場合は人と仕事が魅力がなくなってしまったと思っています。魅力というよりも上の点が自分のイメージとミスマッチすると、というイメージが近いかと思います。

△人: はじめは情報理系出身の院生だとか、上級のSEの方だとか、ほんとうに優秀でITについて詳しいと思ったし、追いつけないんじゃないかと思っていました。ただ3年も4年も勉強を続けていると、ある分野では「あれ?私のほうが詳しいな。」と思うようになってきました。あと私の年代以上になってしまうとほぼプロジェクトマネージャーのロールモデルとなるので、技術寄りのロールモデルが見つかりにくかったこともミスマッチになってしまった大きな要因かと思います。「webエンジニアとして構造と処理をメインに語れるロールモデル」の近くで働きたくなりました。

△仕事: これは前の章で述べたように構造を考えることが仕事になっていなかったので、Webエンジニアとして処理と構造を考える仕事に付きたかった、となります。

◎金: これは魅力的でありましたし、最後まで後ろ髪をひかれてました笑 このまま行けば普通に給料も上がっていきますし、高給取りとして裕福な生活も手に入れられました。

上の3点を考えに考えた末、私の場合どうしても仕事と人の比重が高かったのです。

5-2. 本当にやりたかったことを判断する切り口2 (30歳という年齢)

お金に後ろ髪をひかれながらも最後に退職の決め手になったのは、30歳という年齢です。 30代目前にしてここでほんとうにやりたいことをやらないとまた2・3年後も同じようなことで悩む、というG's academy時代の恩師の言葉もあり、年収がたとえ半分とかになってもやりたいことをやろうと決心します。 目指したかった処理と構造を考えられるエンジニアになるにはレーンチェンジは今しかないと思い、退職の決断をします。

※この時はまだ転職先を決めておらず、退職を先にすることになりますが、その奮闘は後半で書くことにしたいと思います。

まとめ

長めのブログを読んで頂きありがとうございました。最後に今回の内容をメッセージとしてまとめたいと思います。

  • 自分がどのような姿になりたいかというのは、経験を積む中で少しずつ解像度が上がっていく。
  • なりたい姿の違和感はずっと残るので違和感は早めに解消したほうが良い。
  • 30歳という年齢付近で決断できるということは人生に影響が大きい。

これから(後半で書くこと)

後半では退職後どのような情報収集をして、どのような考え方のパラダイムシフトがあって、転職にどのような奮闘をしたのかをメインに書いていきたいと思います。