SIer/年収1000万を手放した私 ( 後編 / 復活の章 ) 〜 webエンジニアの 挫折者から生存者へ 〜

f:id:tai-hey:20200102180048p:plain

はじめに

みなさま、おはこんばんにちは。


私は プレイド のエンジニアの大平(おおひら) (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで 株式会社プレイド で勤務しています。

twitter.com

日々の活動内容(プログラミング・SaaS/SIerロードバイク・減量など)をつぶやいたりしておりますので、本エントリを読んで興味を持たれた方は、twitterでフォロー、リプライ、メッセージなどをいただければと思います。基本すぐに回答します。


本エントリは、去年2018年12月に執筆した、 前編 と、 今年2019年9月の 中編後編 の 挫折の章 の続編になります。

www.taihey-blog.com

www.taihey-blog.com

www.taihey-blog.com




- 対象読者

  • エンジニアに限らず前向きに人生のチャレンジをしようとしている方
  • 人生のレーンチェンジを考えている方
  • SIerからwebエンジニアになりたいが、実際はどのようになるのかを知りたい方
  • 未経験でwebエンジニアに転職したが、業務に挫折しかけている方
  • 30代以降でなにかにチャレンジしたい方


- 本連載の構成と後編について

エントリの構成は下記の通りです。
- 前編 (NRI〜転職決意まで)
- 中編 (退職〜プレイド入社まで)
- 後編 (転職後〜現在まで)

  • 挫折の章  
  • 生存の章  ※本エントリ
  • 反省の章


本連載は、私がSEを7年勤め、年収1000万のキャリアを積むも、自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。2019年は転職含め怒涛のように環境が変わっていきました。恵まれた高給の大企業の環境から、直近の年収アップを捨て、個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦していました。社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

後編はいよいよwebエンジニアとして入社後の奮闘記の話となります。

今までで一番内容が濃く、心境やスキルの状態が様々に変化するような、厳しいチャレンジが続く期間でございました。業務の中でかなりたくさんの失敗を続け、必死にもがいた期間でありました。 そのため、現実では複雑に内容が絡み合い、伝えたいことがぼやけてしまうので、後編を3つの章にわけることにしました。はじめは、ストーリーメインで、転職した直後の 2018/07〜2018/10 くらいまでの 挫折の章 となります。次は、どん底であった状態から無事生存するまでを書いたお話、2018/11〜2019/10 までの 生存の章 を執筆します。

生存の章までの一通りストーリーの流れを見た後は、苦しんだ経験の私自信どこがまずかったのを振り返り、分析する、反省の章 を執筆したいと思います。

もしかしたらwebエンジニアとしてはもっと安全で楽な成長の方法があるかもしれません、私の体験が正解とも思っていませんので、どのエントリも一種の体験談として読んでほしいと思います。

まずは、後編・挫折の章までの振り返りからいきたいと思います。

- 前回までのあらすじ

前編参照: 新卒で文系SEとして野村総合研究所(以下NRI)に7年勤務しましたが、PM・業務を考えるマネジメントメインのロールモデルではなく、エンジニアとして構造や処理を考えるロールモデルを目指し、転職を決意し転職活動を開始します。

中編参照: 転職活動は苦労の連続でした。はじめに応募した大手のエンジニア職などを20社ほど応募するも全落ちを経験します。次の応募群ではコードも書くビジネス職をおすすめされることに、違和感を感じます。そこで修行と称し、100%業務でコードを書くエンジニア職を目指すことで腹をくくります。年収を 1/3 にしてもよいからとコードを書く環境を求めがむしゃらに応募し、晴れて現職の会社 プレイド と出会うことができました。


後編/ 挫折の章 参照: 数ヶ月にわたった選考全落ちを経験した厳しい転職活動を経て憧れのwebエンジニアとして入社した私。入社当初はキラキラしている環境に浮かれていたものの、業務に入った瞬間に沢山の壁にぶつかります。新人エンジニアくらい全く業務が出来なくて挫折の穴に落ちていきます。

本エントリ、後編/ 復活の章 は前章でどん底に落ちた私が挫折者と生存者の狭間でどう苦しみ、身体やメンタルをボロボロにしながら、転機を経験してどう復活していったかを書いています。 それでは前章の最後、ブランチをぶっ壊してしまった事故のところから再開しましょう。



※ 一応現職の話がメインになりますので、内容は私の体験と心境、会社で現状オープンになっている情報をベースにしております。会社の意図や戦略とは一旦切り離して読んでいただければと思います。

ブランチをぶっ壊す事故が私をどん底まで突き落とした

- 頭に血が登り顔が熱くなる感覚が身体を襲う

前回、後編/(挫折の章) の最後でブランチをぶっ壊してしまった私。

その時はリードエンジニアの方が素早く対応していただき、検証環境の弊社範囲内で閉じることができ、 事なきを得たのですが、前職でいつの日か本番障害を起こしてしまった時のように本当に焦りました。(是正ももちろんしました。)


しかも私はややこしい壊し方をしてしまったようで、トリッキーな方法で直さねばやらねばならないようでした。 目の前でリードエンジニアはじめ数人のエンジニアさんがいろいろフォローしてくれているのですが、 私はただ見ているだけ。NRI時代は障害の状況を整理し、パートナーさんに指示、復旧作業、お客さんへ報告資料を作るなどを一人で指示したりしていたのですが、 今は全くなにもわからず、発言の一つもできませんでした。 頭に血が登って顔が熱くなる感覚が身体を襲いました。


金融系のシステムは一桁ミスったり、エラー1つで大騒ぎだったりするので、 事故をやってしまった感覚が身体が覚えており、手が震えたり、緊張状態がしばらく高く続きました。

この事故がきっかけで私の気分の高揚は一気になくなりました。圧倒的無力感です。

「中途で入ったのに迷惑かけてしまう」
「一刻も早く戦力にならないと」
「あ、やばい、でも事故って他のこともいろいろやるの怖い、緊張する」
「何をうかれているんだ、遊んでいるとかそんな場合ではない。」

そんな心理状態に陥っていました。 周りのエンジニアの方に優しくしていただけたのですが、 おそらく気づけば私は、このときから自分を必要以上に追い込み始めていました。


- 爆速で成長することを決心。それが裏目に。

自信と浮かれ具合を一気に消失した私は、迷惑をかけないために、 一刻も早く一人前のエンジニアに成長するために、自分の成長イメージを設定します。

メモに目標を書いていきます。 一ヶ月で基本的なバグフィックスができるようになる。3ヶ月で簡単なモジュールが追加できる。 半年で新規で機能を作れるようになる。。etc...

これも特に成長には関与しません。全くの逆効果でした。 ただただ自分を焦らせる結果になっただけなのでした。 どんどん実態の自分の成長からは離れ、目標を下方修正するもまだまだ届かない。 そしてそれを行うことで自分のダメさを再認識することになり、自分を追い込んでいきます。

つらすぎて3ヶ月ほどでこれはやめることにしました。


11月〜2月:冬。チーム変更。人生最大のどん底。潰れる。

- チームが変わる。CPOからのメッセージは、「成長しろ」

入社から3ヶ月たった2018年10月、ダメダメかつ事故った私は、チームが異動になります。 弊社はちょっと特殊で、フォーカスといって数ヶ月でその時最適な開発活動ができるように、チームが流動的に変わる仕組みになっています。 その流れのチーム異動の中で転機となる人と出会うことになります。

blog.plaid.co.jp

チームが大きく変わる人に対しては、CPOからやりたいことがあっているかとか、ミッション概要的な話を軽くミーティングします。

私はその際にCPOから

「成長するんだ」

とメッセージを受けます。

数ヶ月ダメダメだった私はこれが転機と考え再度ここで成長を決心します。 ただ現実は残酷です。決心は新たにしても成長できるものではありません。


- 生活の全てをエンジニアリングに捧げる

事故ったことがトラウマで、遊んでいる場合ではありません。チームも変更になったことですし、何かを変えなければいけません。生活の不要なものをすべてを捨て、全てを自分の成長に捧げることを誓います。

やったことは下記のとおり、食生活・睡眠・通勤まで全てを変えていきます。

www.taihey-blog.com




- ダメな私を救ってくれた先輩エンジニア

新しく入ったAPIを作るチームでは、APIを管理する画面を作成するため、私はフロントエンドを中心に担当し開発することになります。画面をいくつか振られ、開発を進めていきます。

生活の全てをなげうっていますが、そんなにすぐに成長はできませんでした。注ぐエネルギーとは裏腹に、状況は特に変わらず相変わらずダメダメでした。Vue.js のフロントだけの開発になりましたが、まだまだ満足にissueをこなせません。

そのチームは slack で今日何をするのかを報告をするのですが、ずっと同じissueを繰り返し、苦戦していることを報告します。フロントだけなのに、何も進まない。同じようなエラーと戦い続けていました。


そんな中見かねたのか、同じチームの先輩エンジニアにペアプログラミングをしていただけるようになりました。

この方との出会いが私のエンジニア人生をどん底から救うことになります。

隣同士で座り、二人で同じコードを見て、先輩の指示でコードを書いていきます。

「まず作りたい画面を呼び出すコードはこうなってて、ここに追加するにはここのコードに〇〇って書いて... エラーがでたね。これはどういう意味か分かる?ググると〇〇とでてくるね、そしたらVueのマニュアルをみて...」

とまさに一挙手一投足。

そこで私は本当に基本的な動作が足りていないことに気づきました。

  • 環境構築の方法、切り分け方
  • webアプリの段階的な作る手順(DOMを追加する、データを取ってくる、データを表示する)
  • ソースコードの全体感・細かい読み方
  • エラーの見方・切り分け方
  • 英語マニュアルの読み方、調べ方
  • 海外のエンジニアのやり取りの調べ方

ペアプログラミングに夢中になっている中、気づけば外は暗くなっていて、8時間ぶっ通しでやっていました。その日は一旦終了。疲れ果てていました。

後日も詰まった時は細かくペアプログラミングを何回かしていただき、これがきっかけで本当に少しだけ、フロントの基本動作はできるようになりました。

その後も2ヶ月ほど開発以外でも基本的なエンジニアの動きなどを 1on1 していただき、立ち上がりが少し出来たように思います。

先輩は既に退社されているのですが、未だに会う機会があります。その時の話を未だにすることがあります。私の一番つらい時期を支えていただいた方でした。


- 他人と比較し、自分で自分のメンタルを劣等感でえぐってしまう

先輩から助けられつつも、追い込み始めてから数ヶ月、メンタル的にもだいぶきつくなってきます。 今となっては下記のような自分への責めが、状況を悪くしていたように感じます。

私の次にも何人もエンジニアが入ってきます。
どなたもエンジニアをやったことがある人ばかりです。

入社後2週間で機能をアウトプットして発表されていたり、issueを普通に解いて貢献をされています。 エンジニアはアウトプットがすべての世界です。そのように称賛されている姿を見るとアウトプットの出せていない自分と比較して自分を責めてしまいました。

新卒や学生インターンも優秀な方ばかり(機械学習の研究室だったり、自分でwebアプリをバリバリ作っていたり)です。同じ様に劣等感を感じてしまいます。

挫折の章で書いたように、私は異業界×異業種 のレーンチェンジで完全未経験。

何年もエンジニアをされていた方々に勝てるわけはないのです。比較してもしょうがないのですが、自分はあくまでも中途で30代。本来はすぐにアウトプットを出さなければいけないはず。スタートも一番出遅れているし、成長も一番遅い、とまた自分を責めてしまいます。

「人のアウトプットをみて、すごいなと思う。けど自分は何もアウトプットできていない。エンジニアはアウトプットが全てなのに自分が何を作ったかなんて、全く言えない。価値が出せていない。辛い。」

まさに No Value。ついには、自分はここにいて良いんだろうか。と思うまでになっていました。どんどんダークサイドに闇落ちしていく自分に気づいていましたが、止められずにいました。


- ここで無理が身体にくる

年末にかけて冬場になってきました。生活を変え、精神的にも肉体的にも自分を追い込み、すべてをコード書くことに注ぎました。

ここで身体に異変を感じるようになります。 メンタルもやられていると共に、身体にもガタが来たのです。

目頭が痛くなり、肩がガチガチに凝り、集中力が続かなくなってきたのです。
またみぞおちもモヤモヤして気持ち悪い、不安な心理状態が続いていました。

流石にまずいと思ってとりあえずマッサージにいきました。診てもらうとどうやら同じ姿勢(特に私は猫背)でコード書いているのと、業務での緊張状態が続いたため、緊張することが普通の身体になってしまっているようでした。 目の痛みに耐えられず、眼科も受診しましたが、目の使いすぎで頭皮まで固まってしまっているそう。それは土日寝まくっても回復しないわけです。

体力は落ち、体重も入社から6kgほど増えていました。 習慣になっていたロードバイクをほぼお休みしてしまい、運動量も減ってしまっています。ストレスで食べる量も増えたことが原因だったようです。


- 潰れる。

このように自分への立て続け与えたの劣等感で身体もメンタルもボロボロになってしまっていました。ちょうど連休だったのでどこかに行こうと思うこともなく、家でただただ寝ているだけ。
本当になにもしたくなくなりました。俗にいう潰れた状態に近かったのではと思います。

平日はなんとか出社はしていましたが、丁度チームもリリースが終わり谷間を迎えましたのでリモートをはさみつつ様子をみることにしました。 弊社は裁量でやっているため、やれる量は個人の判断にほぼ任されます。

私は自分で自分をストイックに追い込み過ぎました。

なんとかここらへんで稼働を抑えることで回復を中心に行うことにしました。これは年始〜2月くらいの話で、人生史上辛い冬となりました。

治療としてはマッサージや鍼治療などで肩・背中・目を中心に回復していきました。 休みはPCを見るのを控え、公園などでぼーっとすることなどで気分転換をすることで身体をいたわっていきました。


プライドを捨てることでスタンスの変化で訪れた転機。少しだけ技術的希望も見えてくる

- 様々な方に助けられ、基礎を叩き込み、技術的に見えてきた範囲

こんな身体もメンタルもボロボロで、どん底の状態です。私はどうなってしまうのでしょうか。


- 環境構築をはじめからペアプロしてくれたCPO

ちょうど新しい環境で開発するプロジェクトだったのもあってか、 見かねてなのか、環境構築はCPOが0からのペアプログラミングをしてもらう機会がありました。 挫折の章でぶつかった壁である環境構築を少しずつ克服していくことになります。

コマンド一個一個がうまくいくかどうかを確認しつつ進めてくれ、いつもは複雑に絡み合ってできている環境ではなく、 素の環境構築を経験することが出来たと思っています。




- CPOに言われた「プライドを捨てろ」「プログラミングに近道はない」「勉強中」

そんなペアプログラミングの中で私の心境を変える言葉がありました。

  • プライドを捨てろ

   → 出来ない前提でいいから質問しろ、知ったかぶらずしつこく食らいつけ

  • プログラミングに近道はない

   →すぐにはできるものではない。焦るな。

  • 勉強中

   →勉強中なのだからわからないところはわからないとはっきり言え。

どの言葉も、総じて自分の理想を作らず、追い込まず、ハードルを上げず、愚直に進めないとエンジニアリングは身につかない、ということだと思います。

確かに私は

「エンジニアとは、自分で調べて自分で実装するのものだ。人に頼っていてはだめ。特に私は中途だし。自分でやりきらないと本当に理解したことにならない。」

と思っていました。


これが一種のプライドの高さだったのだと今では思います。中途で活躍しなければというプライドを持っていた私にとって一つ一つが自分の心にささりました。




- 他のベテランエンジニアにも助けてもらう

ここから徐々にプライドを捨てて質問をしだしてから、周りから扱いも変わってきました。どんな基本なことでも素直にわからないと言い、質問をしつこくしていると、状況が伝わったのか、新しいチームになったベテランエンジニアの方にも丁寧に教えていただけるようになりました。スタンスを変えることで状況が少しずつ変わってきたのです。


- webアプリの基礎技術スタックを叩き込む

勉強中のスタンスをとってから初心に帰り、本当に基礎からやりなおすことにしました。 年末年始も返上で自分でコードをかたっぱしから読み、チュートリアルを試し、 Vue.js/Node.js/express/HTML/webpack/などがどのようにつながっているのかを調べるため、一つ一つコードを書き、インプットしました。 この活動は、本来一番初めにやらなければいけないことをだったように思います。私は成長に必ず必要な、大事なところを飛ばしていたようでした。基礎からの積み上げの大事さを学び、技術的な転機もこの頃だったと思います。


もう一つの転機。ブログ執筆。

- 初個人ブログ執筆・初バズリを経験


ここで No Value だった私にもう一つの転機が訪れます。ブログの執筆です。 年末から2月にかけて2つのブログを書くことになります。

まず1つ目は何気なく自分のブログを日記がてらにやろうと思い立って執筆した個人ブログになります。

www.taihey-blog.com

こちらはしがないアドベントカレンダーの21日目として出すことになります。 SIerからの転職が流行っていた?ので私もその流れで書くことにしました。

あまりブログなど執筆したことがなく、期限まで時間がなかったので、慌てながら書いたことを覚えています。

このエントリは、エンジニア界で一つの指標になっているはてぶ (ブックマーク。いいね・シェア数のようなもの) では 340 を頂き、ページビューでは 2万PV ほど記録することができ、初のバズりというものを経験しました。twitterはてブの通知がおいきれないほど来たりして、忘年会どころではなく、興奮がやみませんでした。


- 初エンジニアブログ、自分の経験をアウトプットすることを経験する


更に私はもう一つ、会社でのブログを書きます。

弊社ではエンジニアブログを持ち回りで書いていくのですが、私にもこのタイミングで回ってくることになりました。

本当にここまで No Value だし、なにか、何かで会社に貢献しなければならないと必死に考えました。そこで書いたのが自分のキャリア特性を生かした下記のブログとなります。

tech.plaid.co.jp

始めての技術ブログではあったのですが、推敲などいろいろな方に協力いただき、NRI時代でも書いたことのない記事を出すことになります。

この記事も 65 はてブをいただき、自信になったことを覚えています。

このあたりで私はコードだけではなく、ブログでのアウトプットを出せることに気づき、少しここで活路が見えてきたように感じます。


- 知り合いのカンタンなwebアプリ製作のお手伝い


ブログだけではなく、コードでもアウトプットを出すように動き出します。課題感にあった実装力を鍛えるため、複雑な KARTE を離れもう少し自分の身の丈にあったプロダクトに触れて経験を積みたい、 と思うようになりました。

その際にブログを読んだ知り合いから、「個人のアプリを作っていて、手伝ってくれないか」とお声がけいただきました。春先から夏まで、短期間ではありましたが手伝うことになりました。そのプロダクトも Node.js ベースで、実装を手伝うことでwebアプリの開発経験として良い経験になりました。


- ブログをきっかけの出会い。


webアプリのお誘いのように、ブログを出してから、twitter経由で様々な人にお声掛けいただき、会うことが増えました。
転職経験のインタビューを受けたり、webエンジニアへの異職種の転職相談をされたり。やはり転職エントリが響いたようで、それがきっかけで今も人と会うことが多くなりました。また、新たな世界が広がるとともに、自分の一個人としての価値について考えるようになりました。アウトプットすることでこんなにも人に影響を与えることがあるのかと。




4〜9月:春。どん底・挫折者からの生存者へ。

- 苦しんで覚えたフロントエンドで成果がでる。

ボロボロで挫折しかけたころから考えると嘘のようですが、ここまできてやっと生存したと実感するようになりました。文字通り春を迎えることになります。

1月まで担当してたチームが変わり、ジョブ配信系のチームに異動となります。

サービスリニューアルのプロジェクトで、チーム的に入り口としてもフロントエンドを中心にやったほうがやりやすいという配慮もあり、ここでも春先までフロントエンドを中心に行うことが多くなりました。


つらい時期もありましたが、気づけばフロントエンドを中心に3-4ヶ月やったおかげで、issueも少しずつ進めることができるようになり、自分の中でフロントエンドとは何かを整理・昇華できるようになってきました。

業務としても、フロントエンドならなんとかなる、Vue.js については一人前まではいかないまでも、半人前強くらいには実装できるようになっていました。

また、このタイミングでエンジニアブログの順番が回ってきて、業務経験を整理した内容を記載した下記のエントリを執筆します。

tech.plaid.co.jp

こちらも他のエントリとは違い、技術的な内容ながら、かなりご好評いただき、2万PV・455 はてブほどを記録し、多くの方々に見ていただくことになりました。ありがとうございました。

このエントリをネタに秋にかけてLTをいくつか登壇させていただき、リアルな意見をいただくこともできました。


また、年末にも一年間のwebエンジニアとしての経験から下記の人材についてのエントリも執筆し、キャリアの方向性も見えてきたように思えます。未経験/レーンチェンジが自分の原点になったのかもしれません。

www.taihey-blog.com


活路が見えた現在。「挫折者」ではなく、これからの「生存者」としての私。

昨年の冬は 挫折者 になってしまうギリギリのラインまでいっていました。本当に人生で一番つらい経験となりました。そしてつらい時期を越えて数ヶ月経ち、生存者 としての私として生きていきます。

それから私はどうなったのか。昨年9月から2020年1月現在まで、ビジネスエンジニアというチームに所属して元気にやっています。

www.wantedly.com

KARTEは、CXプラットフォームというプロダクトとしてプロダクトアウトでの開発がメインになります。 ただ、それだけだとビジネスに最適にフィットさせることは難しいです。 多少は顧客のニーズに合わせて開発することが必要になります。 ビジネスと会話し、プロダクトの特性を最大限に引き出すように開発を行うことがこのチームのミッションです。

私はもともとSI出身でビジネスと会話でき、要件定義経験があるというのと、性格あっているからだと思うのですが、ビジネスをドライブさせる開発がとても好きなので、このチームのポジションはとてもあっていると思います。

弊社には少ないタイプである「プロダクトアウトの会社で生きるマーケットフィット人材」として価値を出していこうと思っています。具体的には、今外部連携API の開発を行っています。フロントエンドだけでなく、サーバサイドにも担当範囲を広げ、開発を行っています。公開できる状態になったら、このブログでも発表したいと思います。




まとめ

お読みいただきありがとうございました。

30代、未経験で大企業の恵まれた環境やキャリアを捨て、スタートアップの技術力一本で勝負する環境に飛び込んだ私。転職も全落ちを経験し、転職後も自分のできなさに自分を追い込んでしまい挫折を経験しました。

あのつらい時期、もしかしたら挫折者としてwebエンジニアを辞めていたかもしれません。でも周りの方々の助けもあってなんとか生存しています。

かなりつらい経験となりましたが、不格好でも全てをなげうっても本当にやりたいことにチャレンジする、このことを学ぶよい人生経験になったと思います。

赤裸々に語ってきていますが、どんなバッシングのコメントを頂いてもかまいません。中編までのエントリを読んでいただいた方で、何名かにエントリを読んで元気がでたといっていただけました。転職や人生を変える決断を岐路にたっている方々ともお会いし、少しでも背中を押せたのかもしれません。

そんな方たちと出会うことで、私自身もチャレンジした経験を執筆する価値、活動をする価値と喜びを感じました。

未経験でwebエンジニアになりたい方を始めとして、私は少なくともそんな人生を変えようとしている方や、再スタートをしようとしている方に届いてほしい。そういう思いでエントリを書いています。


次回について

次回はここまで来たストーリーを振り返りながら、自分の心理状況、反省会をしたいと思います。マインドでの反省、スキルを習得するのになにをしくじってしまったのか。次回やるならどうするのか。しっかりとここで分析・反省をしていきたいと思います。

それでは、今回はここまで。人生にチャレンジするみなさまの成功を願いながら、復活の章は筆を置きたいと思います。 ありがとうございました。




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

SIer/年収1000万を手放した私 ( 後編 / 挫折の章 ) 〜 webエンジニアの 挫折者 と 生存者 の狭間で過ごした1年間〜

f:id:tai-hey:20200102161322p:plain

はじめに

みなさま、お久しぶりです。


私は プレイド のエンジニアの大平 (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで 株式会社プレイド で勤務しています。

twitter.com

普段からつぶやいたり(プログラミング・SaaS/SIerロードバイク・減量など)しておりますので、本エントリを読んで興味を持たれた方は、twitterでフォロー、リプライ、メッセージなどをいただければと思います。基本すぐに回答します。


本エントリは、去年2018年12月に執筆した、 前編 と、 今年2019年9月の 中編 の続編となります。

www.taihey-blog.com

www.taihey-blog.com 中編を出してからというもの、前編のときよりも多くの方にお会いすることができ、みなさまから温かな応援コメントを頂きました。ありがとうございました。


- 対象読者

  • エンジニアに限らず前向きに人生のチャレンジをしようとしている方
  • 人生のレーンチェンジを考えている方
  • SIerからwebエンジニアになりたいが、実際はどのようになるのかを知りたい方
  • 未経験でwebエンジニアに転職したが、業務を覚えるのに苦しんでいる方
  • 30代以降でなにかにチャレンジしたい方


- 本連載の構成と後編について

エントリの構成は下記の通りです。
- 前編 (NRI〜転職決意まで)
- 中編 (退職〜プレイド入社まで)
- 後編 (転職後〜現在まで)  ※本エントリ


後編はさらに下記に分かれます。

  • 挫折の章  ※本エントリ
  • 生存の章
  • 反省の章

の3章となります。


本連載は、私がSEを7年勤め、年収1000万のキャリアを積むも、自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。2019年は転職含め怒涛のように環境が変わっていきました。恵まれた大企業の環境から、個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦していました。社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

後編はいよいよwebエンジニアとして入社後の奮闘記の話となります。

今までで一番内容が濃く、心境やスキルの状態が様々に変化するような、厳しいチャレンジが続く期間でございました。業務の中でかなりたくさんの失敗を続け、必死にもがいた期間でありました。 そのため、現実では複雑に内容が絡み合い、伝えたいことがぼやけてしまうので、後編を3つの章にわけることにしました。はじめは、ストーリーメインで、転職した直後の 2018/07〜2018/10 くらいまでの 挫折の章 となります。次は、どん底であった状態から無事生存するまでを書いたお話、2018/11〜2019/10 までの 生存の章 を執筆します。

生存の章までの一通りストーリーの流れを見た後は、苦しんだ経験の私自信どこがまずかったのを振り返り、分析する、反省の章 を執筆したいと思います。

もしかしたらwebエンジニアとしてはもっと安全で楽な成長の方法があるかもしれません、私の体験が正解とも思っていませんので、どのエントリも一種の体験談として読んでほしいと思います。

まずは、中編までの振り返りからいきたいと思います。

- 前回までのあらすじ

前編参照: 新卒で文系SEとして野村総合研究所(以下NRI)に7年勤務しましたが、PM・業務を考えるマネジメントメインのロールモデルではなく、エンジニアとして構造や処理を考えるロールモデルを目指し、転職を決意し転職活動を開始します。

中編参照: 転職活動は苦労の連続でした。はじめに応募した大手のエンジニア職などを20社ほど応募するも全落ちを経験します。次の応募群ではコードも書くビジネス職をおすすめされることに、違和感を感じます。そこで修行と称し、100%業務でコードを書くエンジニア職を目指すことで腹をくくります。年収を 1/3 にしてもよいからとコードを書く環境を求めがむしゃらに応募し、晴れて現職の会社 プレイド と出会うことができました。


ここまで簡単に前回までの振り返りができたところで、ここからは中編の続きからとなります。転職後、意気揚々と入社する 2018/07 からの話となります。



※ 一応現職の話がメインになりますので、内容は私の体験と心境、会社で現状オープンになっている情報をベースにしております。会社の意図や戦略とは一旦切り離して読んでいただければと思います。

晴れてwebエンジニアとして入社。社会人8年目の30歳男性。普通に浮かれる。

キレイなオフィス。PCはMac。晴れやかなイベント。

2018年7月1日。入社した私は気合が入っていました。中編 で苦しんだ転職活動を抜け、6月下旬に入社を決め、すぐ7/1から入社を やっとwebエンジニアとして第一歩を踏み出すことができたのです。オフィスも面談した五反田から銀座に移転しました。私の入社日が GINZA SIX への移転と重なり、入社した日はまだ引っ越し用のダンボールがあり、バタバタしている状態でした。

まず驚いたのはオフィス環境でした。オフィス内はとても広く、一つも仕切りがありません。フロアの向こうまで見えて開放感があり、窓からは中央通りが見えます。聞いたところ、コンセプトは完成しないオフィス。かっこいい。今までNRIでの巨大ビルでしっかり整備されて仕切られたオフィスに慣れていた私としては、その差に驚きながらも気分が上がらざるを得ませんでした。心機一転気合を入れ直したのを覚えております。

業務中でもEDMを中心として音楽が流れます(自分たちで好きなものを流します)し、作業に集中できるようイヤホンやヘッドホンは可。打ち合わせスペースの壁はホワイトボードになっており、直接書き込めます。オシャレかつ機能的。

フリーアドレスらしく、今日の私の席らしい場所に案内されます。椅子に座ってみると、なんとエルゴヒューマンアーロンチェア。ここまで見てすでに私は「これぞまさにネットで見るエンジニアオリエンテッドの環境だ!」と興奮していました。机の上に置いてあったのは業務端末で支給されたのはもちろんMac Book Pro。早速 Googleのステッカーなんか貼ったりしての憧れのwebエンジニアになれたんだと実感し、気分も高揚しました。

打ち合わせは芝生があり、靴を脱いで上がって打ち合わせ自由な規模で行うことができます。そこで全社員芝生に座りながらあつまって打ち合わせしたり、顧客とのミートアップなどのイベントを開催したり。私は「サークルみたい。イケイケベンチャーじゃないか!」とますます興奮。

はい、社会人8年目、30歳にもなって完全に浮かれてます。

また、その芝生や会社のスペースを使って、しめめし会や移転パーティ、日本酒会など、華やかなイベントも定期的に開催されていました。この点も気分の高揚を手伝っていました。

初日はカンタンなセットアップなどやツールのインストールで終了。次の日からは、いきなり業務に入ることはなく、1ヶ月は社内オンボーディングの一環で、いくつかのオリエンテーションと KARTE を知るカリキュラムもこなてから、実務に入っていく流れとなります。


プレイドのプロダクトの技術、革新さに衝撃を受ける

2日目からオンボーディングカリキュラムがはじまります。事業の全体感の説明であったり、プレイドの事業の中核となる KARTE についての先輩エンジニアから説明などがカリキュラムとして組まれています。説明の中でも、特にプロダクトのカリキュラムに関してはエンジニアとしてはしっかり理解しておきたいところです。プロダクトの説明の中では、KARTE のプロダクトのアーキテクチャの話や、インフラの話が印象的でした。例えば、日々送られてくる大量データを爆速で解析(一秒以内)しますし、特にそれを支えるGCPを活用したクラウドでの自動スケールは、衝撃でした。

私が昔担当していたプロジェクトは、SIでよくあるオンプレミスで運用し、正災対2台ずつのHR構成となっていました。20代の頃経験したサーバー更改プロジェクトでは、HR構成をRAC構成にするというプロジェクトだったのですが、1〜2台ほどの本番サーバースペックがデータ量に耐えられるかどうかの調査をしたり、その中で障害対応をしたりと、かなり苦しんだ経験がありました。 KARTE のアーキテクチャの柔軟さを知り、こんな素晴らしい構成があるのかと驚いたのを覚えています。また、実際に自分が開発する環境としても、フロントエンドは Vue.js, バックエンドは Node.js で書かれており、java, COBOL, C がメインだった私には非常に KARTE の環境のモダンさを感じました。

もう一つ、あまり詳しくないのですが、リリースをする際にサーバーをクラスタに分けて新旧のサーバを上手く調整する仕組みになっており、リリース毎にまとまったサービス停止時間を設けない、ということも衝撃でした。私の経験したプロジェクトではリリースでは決まってサービスの停止時間があり、その度に時間調整をしていたからです。

一見クラウドがいいモダンな環境がいい、というように見えそうですが、どちらのシステムが良いというわけではないと思っています。以前下記のブログでかいたようにシステム構築の経緯として、求められる品質が違う(顧客の基幹システムと自社のマーケティングツールである)のと、開発された時期が違う(NRIで経験していたものは新しくて2000年代より以前から稼動しているシステム、KARTE は正式プロダクトリリースが2015年3月)ので、その時採用するアーキテクチャも変わってくる、ということを学習しました。

tech.plaid.co.jp



説明だけではプロダクトを理解するのは (特にKARTEは!) 難しいです。そのため、KARTE のプロダクトを触って覚える「KARTE Dojo」というものがあり、KARTE の機能を一通り練習するカリキュラムがあります。そこでも私はプロダクトの実現している世界に衝撃を受けました。 KARTE は、タグを埋め込んだwebサイトのポップアップ・チャットなど様々な機能を管理画面上のGUIで設定し、配信することができるのですが、これをwebサイトで実際に配信して動かすまでにはミニマムで考えてコードを書くことがなく実現することができます。

通常SIでサイトを構築して運用するプロジェクトであれば、私の経験上、エンジニアを常に張って、ビジネス側と要件を関係各所に確認のための打ち合わせを行い、日程を調整し、仕様を関係者の承認をとり、設計書を修正し、何かあれば認識合わせを都度行い、テスト方針を決め、コードを修正し、タイミングに合わせてテスト。。。などなどいろいろな人が関わります。

KARTE があれば少なくともビジネス側(マーケター)だけで完結することが可能なのです。(難しいカスタマイズはコード修正が必要ですが)

工数であれば数人月、ものによっては十数人月で実現するものをプロダクトとビジネス側の担当者ベースだけでミニマムで実現することができます。こんなプロダクトを開発できる喜びが、KARTE を触っている間にふつふつと湧き上がってきたのを覚えています。

............はい、楽しいのはここまで。ありがとうございました。気持ちが高ぶり良かったはじめの一ヶ月で終了です。世の中そんなに甘くはない。実務に入った瞬間、そんな浮かれている気持ちは消え失せます。


webエンジニアとして業務を開始。目の前はまっくら。新人に逆戻り。

オリエンテーションとオンボーディングカリキュラムを終え、issue を振られて開発を進めていきます。

とりあえずwebエンジニアとしては完全に未経験。チーム開発に必要なスキルセットを全くもっていなかったので全部がわかりません。SEのスキルセットなんてほとんど通用しません。

ここで今思うと業務で一通りこなすのに必要なスキルと状況(心境)を粒度関係なく列挙してみます。 下記は現在のプロダクトに使われている技術です。これでも全部では無いと思います。

  - github使い方(issue,PR運用?エクセルレビューじゃないの?)
  - git branch (commit, push とか checkout とか全般) → 後に会社のブランチぶっ壊して事故る
  - docker (docker-compose?k8s?manifest?container?image?)
  - Node.js 関連 (初めて。npm?, express?, package.json?, pug?)
  - Vue.js 関連 (え、Laravelとは違うの?SPA?MVVM?Store?component?)
  - javascript (ECMA?コールバック?async?Promise?javasciptの配列操作ならやったことある!)
  - webpack (え、なに?ごめん全然わからない。)
  - API (CDNならjqueryでHTMLに読み込むのやったことあるよ!え、違う?それ以外もある?)
  - Linux(操作方法はNRIでやってた。なんとか触れる。)
  - DB設計(oracle経験ありだけど実装経験なし。NoSQLは初めて。型がないDBなんてあるの?)
  - mongo (mongo?mongoose?ORmapper?DBならoracleだったよ!DBアクセスのコード書いたこと無いけど)
  - SQL (oracleでやったことあるよ!カンタンなCRUDなら書けるよ!)
  - クラウド(GCP?聞いたことある!)
  - リリース (リリースはパートナーさん任せでした。)
  - datadog の監視 (よく保守運用はやってたけど、性能は基盤チームの範囲だったよ。)
  - KARTE の使い方(KARTE Dojoはやったよ!基本機能だけなので他のはわからないよ!)
  - 業界用語・業務知識(マーケティング用語。SI用語が全く通じない。webプッシュ?セグメント?イベント?)
  - 各プロダクトの英語ドキュメントの読み方(え、TOEIC350点なんですけど。)
  - アジャイル開発(アジャイルなんかかっこいいやつ!ウォーターフォールはガチガチでやったことある!))
  - slack (slack?NRIでは基本メールだったよ!)

思いつくままに列挙しました。書いてたらできなさすぎて辛くなってきました。。 なんということでしょう。私は文系卒の新人エンジニアに戻ってしまったかのようです。

今ならこういう分野、ということがわかりますが、そもそもこれをこの分野だとカテゴリ分けすることが難しかったです。 まず断片的なぐちゃぐちゃな情報を認識し、カテゴリ化、関係性を構造化するまで時間がかかりました。 わかってきたのは今年の秋くらいになります。

ではissueに取り組みます。


- 業務でぶつかる壁の数々

周りの先輩を追いかけるために目の前の課題をどんどん突破していこうと。そんなイメージでいました。

ただ、自分を追い込んだところでスキルはカンタンに伸びたら誰も苦労しません。私はwebエンジニアの壁に次々とぶつかっていくのです。壁の代表的ないくつかをご紹介していきます。


壁1:環境構築

システムを開発するには、本番環境で動かせるよう、自分のPC内でアプリを動かせるように環境を構築します。 KARTE は、環境を構築する際にいくつかのコマンドをまとめたコマンドを使って、複数のコマンドをいっぺんに実行し楽に環境を構築する手順となっています。 ただ、私のコマンドを実行する順序を誤ったり、wikiに書くまでもないエンジニアとしての暗黙的な前提知識や前提条件の準備が実は必要だったり、たまたまエラーになることが多々ありました。 今思えばドキュメントとしては普通のエンジニアが実行するには必要な情報は載っていたと思うのですが、当時のエンジニア初心者の私には想定外で、そもそも知識がないことが起きすぎました。

その際に先輩に聞くのですが、忙しくされているので聞くタイミングを逃したり、 私も先輩に時間を取らせてはいけないし、30歳で社会人経験7年もあって、中途入社だし新卒の時みたいに丁寧に教えてもらうようなコストはかけさせられない。特にエンジニアは自分でエラー解消してナンボとよく聞きますし、できれば自分で突破したい。と思っておりました。 この考え方も今思えば本当に良くなかったと思っています。

その時は npm もよくわからず、docker なんて触ったことがない。知っているのはプログラミングスクールのジーズアカデミーでならったローカルでの開発方法とカンタンなAPI開発とかjavascriptだけ。その時は周りに聞ける人がいたし、みんな同じようなものを作っていたのでできていただけ。だからできていたのでした。

- この苦しみは最初だけではない

環境構築なので、一回構築して終了で最初の方だけ苦しむのか、と思いますが、実はこの壁は今年の秋までの1年間完全に解消することはありませんでした。 なぜかというと、環境構築には様々な技術の知識がいると同時に、別の課題もあったからです。

対応する issue の度に毎回触れる機能が変わるのです。

- チームが変わるため、環境、構築方法、データも毎回変わる

tech.plaid.co.jp

KARTE は上記(丁度私の入社した近辺の2018年8月に投稿)で記載されているように、 サーバサイドのみ(マイグレーションバッチ、テストコード、空行、コメント行などは除く)で5万行ありました。更にフロントエンドの Vue.js の実装を考えると( Vue.js は1100コンポーネント以上) はもっとあります。これで実装量が想像いただけましたでしょうか。

さらにKARTE 自体はたくさんの機能があります。ポップアップ, レポート, API機能, 連携系(LINE, slack, mailgun, sendgrid, SF)などなど。。。 その度にそれ用のデータを仕込んだり、必要なプラグインを入れたり、必要なものが変わってくるのです。

そして弊社はフォーカスといってチームやタスクが数ヶ月で変わり、関わる機能が変わります。

毎回チームが変わる度に取り扱う機能も変わるのです。また、日々のバグ対応や保守運用課題をみんなでランダムで対応したりするガチャという仕組みがあります。この仕組は個人的にはとてもいい仕組みだと思っています。ただ、この対応の一つ一つの度に担当する機能が変わります。こちらもその度に当たる機能や必要なデータのパターンも変わってきますし、1から調べなければいけません。

なれた人には似たようなものなのでしょうが、私には毎回違うものの様に見えました。その度に不明なエラーや動かないシステムに苦しみました。

本当に最近、「ああ、この機能ね。やったことある」というものがいくつか出てくるようになってきました。


壁2:コードが読めない。何をやっているのかさっぱりわからない。

環境構築ができたとして、本当の闘いはこれからなのです。まだスタートライン。バグ改修であったとしても普通の開発であったとしても、コードを読んでそもそもの機能の構造がわからないと開発をすすめることができません。

幸い、javascriptは多少読めましたが、本当に初心者が読める範囲のもので、プロダクト自体が既に抽象化されたコードで何をやっているかが初心者には捉えづらく、いきなり中級者〜上級者のコード(ECMA記法で promise 化や、ファイルも汎用化されて呼び出し元の近くにもなかったりとか、コールバックでファイルがあちこちで参照しあっていたり)にふれることになりました。それはそうですよね。

プロダクトは既に(サーバだけで)12万行を越えています。 それを初心者にはわかりやすいカンタンで冗長なコードで書くわけにはいかない。

難しいことはわかりましたが、とはいえ業務に取り組まねばならないので、やるしかありません。

1行のコードを直すまでに下記の工程を踏んでいきます。

■ 1.知る
  • そもそも担当する機能自体が何をやっているかを確認する
  • その画面で事象や開発したい機能でのオペレーションを実施する
  • ファイルがどのような構造になっているのか確認する
  • コード1行1行が何をしているのか、想定している動きになっているのか確認する
■ 2.動かす
  • データの構造に合わせて、データを仕込む
  • データを用意し、バグの場合は再現させて原因を特定する
  • そもそもこれらを調べるためにライブラリやツールなどの基本的な使い方を調べる必要がある
■ 3.調べる
  • データは想定したもの、動きになっているか。
  • エラーはでていないか。
■ 4.直す
  • 修正したコードが他に悪い影響を与えてないかテスト
  • 次他の人が見た時に直しにくい、読みにくいコードになっていないか

などなど実はいろいろな情報収集やタスクが必要だったのです。

と1行直す間に一週間、一ヶ月と経つことがほとんどでした。 実は調べたら直さなくて良かったものだったりすることもありました。

一個改修や調査するのがやっとで、毎日エンジニアのみなさんはやっているのかと尊敬する日々でした。


壁3:組織文化・業界用語が初遭遇、伝わらない

異業種 × 異業界

大規模金融系基幹SIerのSEとマーケティングツールのWebエンジニアは、完全な別業界、別職種です。

普通は、 - SIer の SE → webエンジニア = 環境だけを変える - webマーケター → webエンジニア = 環境を変えずにやることを変える など片方だけを変えます。私の場合はかなり無理をしていて、異業種×異業界をしてしまっていました。

そのため慣習やノウハウ、用語は全く新しいものと遭遇します。プロダクトはマーケティングプロダクトだし、そもそもマーケティングツールの用語がわからないし、開発用語もSI時代のものが伝わらない。考え方も全く違い、ウォーターフォールではなくアジャイル開発、マネージャーを置かないスタイルなどなど。。。

メモやネットで用語や考え方をググる毎日でした。

このように、はじめに(というか1年間ずっと)ぶつかっていた壁はこの3つが一番大きなものだったのではないかと思っています。




その結果どうなったか。タスクをこなせずキャパオーバー。

上記のようにwebエンジニアの洗礼として壁にぶつかりまくりました。今考えてみてもひどいものでした。 最初のコードを2週間や1ヶ月かけて書いたがレビューでそもそものやり方からひっくり返ったり、一つもまともにissueをこなせなかったり。 また、はじめは2チーム掛け持ちでやっていたが、一つもissueが解消できず、キャパオーバーで一つのチームにしてもらうなど配慮してもらうほどでした。 周りの方に配慮頂いてやりやすいように調整頂いて大変ありがたかったのですが、本来自分でやるべきだったタスクを引き取っていただき、大変申し訳なかった感情が強く生まれてしまい、自身の無力感を圧倒的に感じていました。


入って初めての大失敗。事故。ブランチをぶっ壊す。

そんな矢先、事故が起こるのです。git branch でlocalのgitを操作していたら、誤ってdevelopブランチを壊してしまったのです。 どういうことかというと、localのブランチが2週間以上古くなっており、 開発用ブランチをrevertかなにかをして2週間分のコミットをしてしまったようです。

slack で「あれ?なんかおかしくない?この前の修正が反映されてないよ」とザワザワしだします。

「。。。すいません、、それ僕かもしれません。。」

この事故をきっかけにまた私はどん底に落ちていくのでした。


まとめ

この事故の後、私は人生最大のどん底にいくことになります。

今は元気でやっているので、無事戻ってきているのが分かると思うのですが、この後が人生で一番つらい時期であったと思います。

復活の章 では、どん底だった話と、それから何をきっかけに上向いてきたのか。そのへんを中心にお話していきたいと思います。

同時にリリースしておりますので、気になる方は下記から続きを見ていただければと思います。

www.taihey-blog.com




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

ウィルパワーを5ヶ月間マネジメントしてエンジニアとして超集中力を保った話

shutterstock_1055471537.jpg

※この記事は私の下記のqiitaからの移行記事です。

qiita.com

はじめに

PLAID Advent Calendar 2018 の第10日目は、7月からプレイドにjoinしているソフトウェアエンジニアで、武井壮アカウントをめざしている @tai-hey が担当します。

私はSIerから今年30歳で業界を越えた転職をしてきまして、スタートアップのスピード感と考え方に刺激的な毎日を送っています。

まず、この投稿内容にした動機について話します。 転職してきて、今までとは全く違った環境、業務を行っているため、即戦力でできる範囲は限られています。業務を経験する中でいち早く戦力化できるようになりたいので、少なくとも自身の集中力を最大限保っている状態でないと実現は難しいと考えたので一部書籍を参考にした箇所と、前職の段階から実践していることを合わせてエンジニアとしてのユースケースに落としてみました。

5ヶ月この書籍を実践して、ある程度実例として実績をつめたことと、エンジニアのユースケースとしてアジャストできたので、ここで一度整理するために advent calendar として投稿することにしました。

一部、参考にした書籍は こちら(自分を操る超集中力) です。

対象の読者

この投稿はアウトプットを出す際に集中力というフローを実践して、エンジニアのユースケースとして落とし込んだ実績を記載しています。 私は以前SEとしてビジネスサイドも経験しているため、集中力を保ちパフォーマンスを上げるという面では共通しているところがあるのかと思いますので、汎化させてビジネスサイドの例に当てはめてもいいかもしれません。

リスト

今回記載するtipsのリストは下記の通りです。他にもいろいろやっていますが、効果の高いと判断したものを抜粋しています。 見ていただき、自分にフィットしそうだなという習慣を取り入れていただければと思います。

  • ウィルパワーを使って集中する
  • ウィルパワーを余計なことで減らさない
  • ウィルパワーを回復する
    • 早寝早起き
    • 最低睡眠時間

ウィルパワーについて

先に本記事のメインの考え方となるウィルパワーについてお伝えします。ググってみるといろいろでてくるのですが、これは心理学者ロイ・バウマイスターという人が提唱した考え方らしく、一人一人が持ついろいろ生活する上で必要な意思の量(ドラクエでいうMPみたいなもの)だと思ってもらって良いと思います。

私が大事にしているポイントは - 起きた瞬間からこのウィルパワー(MPみたいなもの)を使い続ける。 - なるべく余計なことで減らさないようにする。 - 睡眠によって回復する。 となります。

最大容量は個人差によりますが、しっかり回復すれば一日消化しきることはなかった(一日しっかり集中できるようになった)ので、今回はブログの言及対象外にしたいと思います。

私が実践を通して生活習慣を改善していった結果、エンジニアのような知的生産型(アウトプットとしての生産性が大事な)職種は体力ももちろんですが、このメンタル的なウィルパワーが重要なことがわかりました。

体力はある程度体感としてわかるので把握しやすいですが、ウィルパワーについては知らず知らずに消耗しているケースが多いので、かなり生活習慣を見直せば効果的なケースが多いと思っています。

実践リスト

ウィルパワーを使って集中する

では、集中すること自体においてエンジニアのユースケースに効果のあったものを中心に紹介していきます。

  • ポモドーロテクニック ポモドーロテクニックググるとたくさんでてきます。30分(25分作業・5分休憩)サイクルで実施します。 プログラミングをするにあたってコードを書いたりしている際に、同じことでぐるぐるしてしまって先に進まないケースってありますよね。ポモドーロテクニックはタスクの進捗にかかわらず、時間で区切って休憩をいれるので、休憩の際に脳が勝手に整理してくれるみたいです。確かに休憩の間(私はこの間に水をくんだりトイレにいったりしています。)にあれ?そういえばあの方法はどうだろうか、誰々さんに確認したらどうだろうか、とコードの別解法やそもそもコード以外にも起こすべきアクションを思いつくことが多かったです。

  • あらゆる通知を切る スマホはかなり時間を奪ってしまうことはいろいろなところで言われていますが、特に友達からのLINE通知が来たり、その他アプリの通知が多かったり、集中力を遮って効率的にウィルパワーを使えなくなってしまいます。スマホはその場にあるだけで気になることが多いので、私はスマホはリュックにしまったり、視界から入らないようにしています。 似たような話で、slack通知やmac自体の通知があります。すべての通知をONにしておくと不要な通知が入って一瞬目線が右上に移ってしまい、集中力を遮ってしまいます。私はmacは基本おやすみモードにして通知を表示させないようにしています。 また、slackは不要なチャンネルはミュートにしています。緊急な場合は自分宛てにメンションがくるはずなので、slackチャンネルの右側にメンションがあれば赤い数字がでるので、ポモドーロテクニックの休憩の段階で確認します。これでだいぶ深く集中する(途中で現実に引き戻されない)ことが多くなりました。

  • 実施するハードルを下げる このノウハウは行動科学マネジメントというメソッドが一部絡んでいるのですが、人が物事を集中する時で、やる気が出ないときはとりあえず作業を始めてみると集中しだす、という原理があります。プログラミングを始めるときや、バグの調査などでなんとなくやる気が出ないときはプログラミングをやろう、バグの調査をしよう、と考えずに、とりあえずPCを開く、とりあえずissueを開くというように先をあまり考えずに行動だけ始めるといつの間にか本当にやるタスクをやっている、という状態に持っていけます。意識を強く使ってしまうとタスクのスタート時にウィルパワーを多く消費するので、私は腰が重いタスクだと感じる時はこれを意識して早く集中するようにしています。

ウィルパワーを余計なことで減らさない

ウィルパワーを気にして生活していく中で、ウィルパワーはなにか考えるたびに消費するので、業務以外で減らすのは個人的に許せなくなってきました。 その中で生活習慣を変えたものを紹介します。

  • 通勤電車 通勤電車はウィルパワーを全力で削ってきます。特に満員電車のストレスは戦闘機パイロットのストレス以上というのを聞いたことがあります。私の大事なウィルパワーを業務以外で削るわけにはいかないので、私は朝6時台の電車にのるか、それをすぎるようならピークを過ぎた8時後半の電車にのるように変更しました。乗り換えの際も早く急行に乗るよりも、一本遅らせて座れる電車を選ぶようになりました。これで大事なウィルパワーを温存します。

  • ミニマリズム 人は物があるとそれに意識を持っていかれる性質があるそうです。おそらくこれは物があるとそれを管理するコストや、ものを見ることでその情報を処理するコストを無意識に使ってしまうようです。私も実感があって、最近昔の服や本を捨てようかどうか悩んでいる時期があって早く判断してしまえば考えることがなくなるので、ウィルパワーを無駄に消費してしまっていたと感じています。 いろいろ捨てていくうちにテレビも捨ててしまいました。テレビは受動的に不要な情報も入ってきてウィルパワーを使い過ぎてしまっていたので個人的には良い判断だったと思っています。

ウィルパワーを回復する

毎日使い切ったウィルパワーは回復させなければ次の日は100%の状態でタスクをこなすことができなくなります。 そのためには体力と同じで回復をしっかり行わなければいけません。ウィルパワーの回復は睡眠が回復の主要方法のようで、睡眠の質が翌日のパフォーマンスに影響することがわかりました。

  • 早寝早起き 早寝早起きはかなり個人差が出ると思います。できるエンジニアは夜型が多いイメージがあり、一回ゾーンに入ると夜通しプログラミングする、というエンジニアは特にイメージしやすいかと思います。社内外問わず、確かに私の知っている優秀なエンジニアは夜型が一定数いると思っています。私はエンジニアになった当初、その流れに乗って夜通しやってみようと思いましたが、どうしてもその次の日などになるとパフォーマンスがかなり下がってしまうので、夜型にはなれませんでした。 私は朝型が身体にあっているようで、調子が良いときは朝5時台に起きて、6時台の電車に乗っています。朝の時間は生産性が高いため、技術的なインプットや実装の設計などの自身が重要と考えるタスクを実施しています。

  • 最低睡眠時間 最低睡眠時間もこれも人それぞれですが、私は最終的に7時間ちょっとの睡眠時間がベスト、というところにたどり着きました。はじめは6時間で大丈夫だろうと生活を行っていましたが、どうしても3〜4日経った段階で頭がまわらない状態が続くようになってしまいました。これは実際の眠気と差異があるからだと思っています。おそらくカフェインとかで目が覚めているけど頭が回っていないゾンビ状態だと思っています。こちらの時間は個人で睡眠時間の計測と日中のパフォーマンスを確認してみると最適な時間がわかるかと思います。

さいごに

いかがでしたでしょうか。エンジニアとして集中力を保つことが出発点となりましたが、もう少し業務に余裕が出てくれば、業務外の活動(LTや自作サービスなど)に使う余力がでてくるのでは、と推察しています。これをきっかけに生活全体が改善され、この5ヶ月でかなりQoLが向上したと思っています。 これ以外にも食のとり方やトレーニングなどの生活習慣改善を行っているので別の記載に投稿していきたいと思います。




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

多能人材になれ!ソフトウェア開発の職種の壁を攻略〜シンクロ率100%ソフトウェア開発補完計画〜

f:id:tai-hey:20191216110639p:plain

この記事は プレイドアドベントカレンダー23日目です。

はじめに

私は プレイド のエンジニアの大平 (@Victoria_Peak_) と申します。グーグルとロードバイク、筋トレが大好きです。特技は早起きです。

twitter.com

2019 年も年末に向けて後少しのところ、みなさまどうお過ごしでしょうか? そろそろ今年の振り返りなどする頃ではないでしょうか。

私の 2019 年はかなりチャレンジングな年となりました。SE・PM キャリアとして7年勤めた野村総合研究所を辞め、プレイドに2018年の7月に転職しました。

PMキャリアからエンジニアキャリアへのレーンチェンジのため、スキルセットは新卒の時と同じゼロになり、業界も SIの基幹システム系 から Web業界のマーケティング周りへと、環境が激変した中でチャレンジした一年となりました。

振り返りの中で、未経験からwebエンジニアとして一年半勤めた中で業務経験から、一つ考察をしてみましたのでこのエントリとしてご紹介したいと思います。


対象読者

  • 十数人以上のソフトウェア開発組織に在籍し、環境がすぐに変えられないが自分を適応させたい人
  • 自分を磨くことを通して職種の壁を超えたい人
  • ポータブルスキルを持ち、どんな環境や会社にいっても自分を適応させたい人
  • 職種の壁を感じていて、どうにかしたい人
  • ソフトウェア組織の確認・認識合わせの作業に疲弊している人
  • 未経験からレーンチェンジをしようとしている人
  • ビジネスからエンジニアになろうとしている人


目次

目次は大きくわけて3章構成となっています。 私のエントリは相変わらず長い(今回は1万字)ので、さらっと見たい方は下記で概要をつかみ、見出しを飛ばしながら見ていただければと思います。

  • 1.モデリングはソフトウェア開発の共通言語になる
  • 2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている
  • 3.多能人材で職種の壁を無効化し、私はソフトウェア全能神になる


言葉の定義(職種の壁)

エントリ内で「職種の壁」という言葉がでてきますが、これは「職種と職種の境界」と「職種毎のスキルセットの境界」の意味でつかっています。別の職種の経験がなく、コミュニケーションなどに説明や経験が必要な状態を指します。




1.モデリングはソフトウェア開発の共通言語になる

転職してから一年ほど経った後、業務の経験を昇華させて整理し、9月にモデリングベースでフロントエンド設計を見直した記事を執筆しました。

tech.plaid.co.jp


フロントエンド設計概念の依存関係を整理し直す中の気づきを整理したのですが、この執筆の中でモデリング起点でシステムが構築されることに気づくことができました。

モデリング起点は私のエンジニア活動でのバイブルになりました。モデリングに可能性を感じる日々、その中で年末に向けて仕事やそれ以外でもいろいろな活動の中で模索していきました。


- ブログエントリの反響 〜そして気づき〜

エントリの内容にコメントをもらったり、LTで発表して実際の反応を聞いたりしている中で、ある一つの共通点に気づきました。

私の想像以上にみなさまの職種の境界線に対する関心が高いことです。

要約すると下記のような話が多いように感じました。

仕事をしている中で「プロダクトの今の仕様についてはエンジニアさんの言うことが正しいから」「ここはデザインの範疇だからデザイナーさんに任せよう」

と思いつつも、

「本当にその仕様はそうあるべき?ユーザーを考えたらこうならない?」 「デザインはアートっぽくキレイにするだけじゃなくてプロダクトの使いやすさによせられない?」 「やっぱりもう少しプロダクトの仕組みにも踏み込んで理解したい」 「(聞くのはこわいけれど)分かれば自分の仕事をもっと質を高められるはず」

と思っていたり。


- ビジネス × システム = △  デザイン × システム = ??

やはり私の想像以上に世の中にはまだ職種境界というものが多く存在し、人はその境界を意識し、ストレスを感じているのではないでしょうか。

元々一人で作成するようなものだったソフトウェアは、成果物として大きくなるほど、作業分担化が進みました。

既にビジネスとシステムの関係性については、下記のエンジニアブログにて、私の経験則も踏まえ記載しています。みなさんもご存知の通りビジネスとシステムは密接に関わっており、意識するかと思います。 私もここを経験として知っているからこそ、ビジネスとシステムの役割の壁は壊せると思っていましたし、それに向けての活動をすすめています。

tech.plaid.co.jp


私も9月のエントリのネタになったプレイドでの活動の中で、みなさまと同じように、デザインとシステムに壁を感じていました。

9月のエントリで活動を整理した際に、壁に気づいてからというもの、今度はどうやったらデザインとシステムの壁を超えられるのかを考えるようになりました。

私は日頃からソフトウェア開発では、職種の壁はないと信じているのですが、まだ半信半疑になっていました。

その中であるワークショップに出会うことで確信を得ることになりました。


- OOUI との出会いでデザインとシステムの壁撤廃が確信に変わった。

この確信のきっかけとなったのは弊社のブログでも取り上げられている下記のワークショップです。私もこのワークショップに参加しました。


note.com


前から OOUI には注目していて、弊社のデザイナーの 鈴木さん とはよく会話をしていたのですが、このワークショップを紹介いただき、参加することになりました。

詳細は上記エントリを確認いただきたいのですが、ワークショップの内容は、まさに私が今までやっていたモデリングの内容そのもので、OOUI はモデリングベースで UI を考察する、「構造を起点とするデザイン手法」だと解釈しました。

このワークショップを通して、元々感じていたデザインとシステムの境界を超えるためには、OOUI はとても有効で、デザイナーもエンジニアもモデリングを共通言語として学べば、ソフトウェア開発の可能性をまだまだ広げられると確信を持ちました。


以前から私はビジネス × デザイン × エンジニアの全ての境界線を取り除けば、ソフトウェア開発をより確実に迅速に進めることができるのではと信じてやみませんでした。今回はそれを裏付けるような内容に興奮さえ覚えました。

そのようなことを考えていると、今年の弊社の活動の中でとても良い事例が既に行われていました。下記のアドベントカレンダーを参照いただければと思います。


note.com


このビジネス × デザイン × システムは モデリングベースを共通言語として壁が撤廃できることが確信に変わったところでもう少し考察を進めたいと思います。

今度は組織に目を向け、ソフトウェア開発の組織構成について考察をしてみることにします。ここからは図で段階を追って説明することにします。下記の2点について論じようと思います。

  • 2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている
  • 3.多能人材で職種の壁を無効化し、私はソフトウェア全能神になる


2.私たちのソフトウェア開発組織は意思疎通に疲弊させられている

私自身あまりソフトウェア開発の歴史は詳しくないのですが、ソフトウェア開発は一つのソフトウェア完成品の成果物を作成するのに、はじめは一エンジニアだけで作成したのが、コードの肥大化と共にいつの間にか役割の分化が進みました。


- 個人のソフトウェア開発

f:id:tai-hey:20191215103739p:plain
個人のソフトウェア開発

ソフトウェア全能神創世記

まずは最小単位の一人でアプリを作るケースです。 エンジニアが一人で作成するケースがイメージしやすいでしょう。 この段階ではデザインも好きに決めていいですし、ローンチ後のビジネス展開も一人で決められます。 有名なアプリたちもこのようなケースから始まったものは多いのではないでしょうか。 プロダクトが手にとるようにわかり、自分が神様になった感覚ではないでしょうか?


- 少人数チームでのソフトウェア開発(細かい・少量のバケツリレー)

f:id:tai-hey:20191215145115p:plain
チームのソフトウェア開発

役割分担が始まる。軽く話しながらそれぞれがそれぞれを分担することで開発スピードは上がる。

少人数スタートアップなど、チームでのソフトウェア開発のイメージです。 作業メンバーが分かれるので、作業工程は Vue.js設計地図 でも書いたように、ビジネス → モデリング → デザイン → システムの順で進んでいきます。

役割分担はもちろんビジネスとシステムやモデリングを同じ人がやるケースもありますし、デザインもビジネスの人が書くこともあるでしょう。そこらへんは垣根がありません。出来る人がやるイメージでしょうか。

作業の流れは大まかに左から右に流れ、細かい・少量のタスクのバケツリレー形式でタスクがいったりきたりしています。

プレイドもほぼこのようなチームが複数あるゲリラ組織的なチームになります。ただ組織全体の話になるのでその解説は割愛します。


- 会社のソフトウェア開発(細かい・大量のバケツリレー)

f:id:tai-hey:20191215145619p:plain
会社のソフトウェア開発

作業コスト・コミュニケーションコストが爆増

これ以上大きくなってくると一つのソフトウェアでも様子が変わってきます。人数が増え、一気に組織的な(十人〜数十人規模など)開発になります。みなさまが会社で開発しているケースがこれがほとんどではないでしょうか。一つの職種が2人以上になった時点でこの概念に入るかと思います。

作業の流れはかわりませんが、バケツリレー(タスク)の量が格段にあがります。バケツリレーの種類も、依頼調整に加えて確認のバケツリレーが多くなってきます。会社としてどのようなシステムにすべきなのかという点で工程間の人々の距離が遠くなり、書面確認などでの間接コストが高くなります。ここらへんはみなさん体感で分かるかと思います。

[ソフトウェアを良くする活動] < [認識を合わせるための間接的な活動] → そして私たちはリスクヘッジに疲弊する

本来効率化のために作業分担しているにも関わらず、職種間で余計なコミュニケーションコストが増えています。 ソフトウェア自体を良くする活動に注力すべきだと思うのですが、 「誰かがいった何かを確認する」ために職種間で認識を合わせる何かのリスクヘッジのために日々追われることになります。

言った言わないを繰り返さないために確認工程は肥大化し、確認用ドキュメントを作り、やっても意味のないようなチェックが横行し、私たちは疲弊していきます。


- 私はソフトウェア開発の時代の揺り戻しをかけたい

機動力を失った開発組織

このように疲弊してしまった組織はソフトウェア開発の機動力を失います。

時代として一人でやっていたシステムは分担化が進み、中〜大規模になることが多くなりました。 感の良い方はお気づきかもしれませんが、単純に作業をするだけではなく、特に会社のソフトウェア(少人数のチームでももちろん)では、人数がここで大きなファクターが存在します。

  • 作業工程(見えるバケツリレー)
  • 意思疎通(見えないバケツリレー)☆

そうです、意思疎通です。意思疎通は見えていないコストですが、やっかいなことにこの意思疎通はタスクに具現化します。このために私たちの貴重な時間や労力を奪われています。

意思疎通を可視化する

先程お話したように、意思疎通を具現化したものが細かい定義書だったり、確認のメールだったり、打ち合わせだったりします。意思疎通がソフトウェアの本質以外を肥大化させます。

一章で考察してきたようにモデリングは共通言語になります。共通言語にしただけで全てが解決するとは限りません。そうです、役職の壁がハードルになるのです。先程は作業工程のみの図でしたが、ではこの意思疎通を含めたコミュニケーションの相関図を書くと、下記のようになります。

f:id:tai-hey:20191217090941p:plain
開発のコミュニケーション組織相関図(意思疎通 追加ver)

こちらはモデリングを共通言語にそれぞれがコミュニケーションをとる相関図です。真ん中の相互矢印はメインの意思疎通で、点線は実際のバケツリレー(タスク)となります。開発職種もA,B,Cさんの3職種となります。


意思疎通を撲滅させる

私はより良いソフトウェア開発を考えた時に、今後は一人でソフトウェア開発をしていた前の状態に揺り戻しをかけたいと思っています。規模感が小さくなることはおそらく無いと思いますので、それを保ったままシステムをさも一人で作っているよう(全員Aさん)に近づけたいのです。

f:id:tai-hey:20191215155746p:plain
開発のコミュニケーション組織相関図(理想)




3. 多能人材で職種の壁を無効化し、私はソフトウェア全能神になる

ではそのような規模が大きくなりがちなシステムを、さも一人で開発する(全員Aさん)ようにはどうすればよいのでしょうか?壁を撤廃するといっても本当にできるのでしょうか?


- 多能人材を目指す

越境ではなく境を無効化する

少なくとも、仮にモデリングを共通言語にしたとしても認識をあわせるコミュニケーションコストは絶対にかかります。では、意思疎通を撲滅させるためにはどうすればよいのでしょうか?現実的な解を模索していきます。

私はそれを自分自身を多能人材にすればいいという発想に至りました。つまり私が全部Aさんになることができればいいのです。

巷ではよく「エンジニアのわたしが○○チームで頑張った、越境した」と聞くことがあります。

それでも確かに素晴らしいと思うのですが、まだそれでは人の意識の壁は超えられていません。私はどんな環境でもソフトウェア開発とそれを取り巻くチームとのシンクロ率100%を目指したいと思っています。

多能人材は「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」です。

この人材像が達成できると、極端にいうと、メインの矢印である職種間の意思疎通が不要になり、役職の壁が無効化され、コミュニケーションコストがゼロに近づきます。それに伴い確認のバケツリレーもなくなります。



なぜかというと

  • エンジニアの私がデザイナー(ビジネス)を「見聞き、理解」して「教えてもらいながら」開発する

よりも

  • エンジニアの私がデザイナー(ビジネス)を「やったことがある」ので「なにを考えているかを手にとるように把握できている」

には圧倒的な差があると思っています。これを目指したいと思っています。




- 環境はすぐには変わらない。自分自身を鍛え、適応させろ

なぜ環境を変えずに自分を変える方向を選択するようになったのか?

組織自体を組み替えたり、という方法もあるでしょう。これは完全に好みと私の生き様に近いのですが、私は転職や複数組織に携わった経験から、会社など他人や環境を変えるのは社歴の浅い人やポジションの関係もありすぐに変えるのは難しい事が多いです。組織自体を変えるにも時間がかかり、必ず変えられるとは限りません。自分を変えるのであればそれよりも遥かに簡単で確度が高いです。

自分が多能になれば、自分がジョインするだけで組織や環境に関係なくソフトウェア開発を一つに補完できると思うし、すぐに効果がでるはずなのです。

なので今回は環境は変えず自分を鍛えて開発適応度を上げていく、という方法で模索していきたいと思います。自分が強くなれば組織を変えられるかもしれない。なので先に自分が強くなる方を選びます。


- どのようなキャリアパスで経験していくのか。(ただし、これは茨の道)

まあ、言うは易く行うは難しです。この人材になるには生半可な継続時間だと達成できないと思っています。私はこれまでも、この先も、長い戦いを覚悟して目指します。 いろいろな人からも無理だとか組織を変えたほうが速いとかという意見も聞くことになるでしょう。でも私は進みます。

先程お話した「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」というのは、それぞれを経験しているからこそリアルタイムに化けられるのです。

そのためにはビジネス、エンジニア、デザイナーをそれぞれ数年は経験することが必要になってきます。

少なくとも私は今の時点でビジネス(PMキャリア)7年 → エンジニア(1.5年)なので理想に近づいてきています。ビジネス × エンジニアのメリットも感じております。

では、どのようにキャリアパスを歩んでいくか、自分の経験を積んでいくかの計画をこれから述べていきます。


- ソフトウェア開発体制の実態

f:id:tai-hey:20191215160955p:plain
キャリアをどう歩んでいくか

私たちのとりまく環境は実際こうなっており、まずこの図をベースとして表現をしてみました。これからどうやって一つにしていくかを実態に落として考えていきます。


- コミュニケーションするのはリーダー

f:id:tai-hey:20191215161316p:plain
キャリアをどう歩んでいくか

システムの共通言語はモデリングであると述べました。そのモデリングをつかって、各職種チームとコミュニケーションを取ります。実質はリーダーのような人(図の白抜きの人)を中心に仕様やデザインを検討していくことになるでしょう。

この際先程の大量のバケツリレーが行われるコストがネックになるのですが、これを多能人材は解消することになります。下記の図のように、この人たちをAにすること が目指す方向性となります。

f:id:tai-hey:20191216005812p:plain
茨の道のゴール



- スタートはメンバーから

f:id:tai-hey:20191216010034p:plain
茨の道第一歩目

スタートはみなさま新卒時など、よくあるようにこうなります。赤い人のようにメンバーからスタートです。


- 普通はここまで

f:id:tai-hey:20191216010225p:plain
普通はここまで

普通はそのまま何年か経つとリーダーになり、コミュニケーションの先頭に立つことになります。ビジネスでもいろいろな守備範囲があると思いますので、ビジネスの中で経験を踏んで極めたりして価値を出し、そのまま定年を向かえるのも全然正解です。(エンジニア、デザイナーもしかり)


- メンバーに戻る勇気をもって、あえてレーンを変える

f:id:tai-hey:20191216010526p:plain
メンバーに戻る勇気をもって、あえてレーンを変える

でも目指す方向は全部Aさんにすることですので、このまま甘んじててはいけません。ここであえてレーンを変えます。メンバーに戻りますし、スキルセットはゼロになりますし、年収は下がるでしょうし、怖いですがやります。私は既にビジネス(SE・PM) から エンジニアになっているので、これは一回クリアしています。私は今この状態です。


- あとは繰り返し

f:id:tai-hey:20191216011123p:plain
何年か経つとこうなる(Cさん→Aさん)

はい、ここまでくるとわかりますね。あとはこの繰り返しです。


- 最後のレーンチェンジ

f:id:tai-hey:20191216011252p:plain
最後のレーンチェンジ

ここでもう一回やってみましょう。


- 更に数年でやっとゴール

f:id:tai-hey:20191216011432p:plain
完成形

はい、これで晴れてBさんもAさんとなり、全てがAさんになりました。ここまできて晴れて「ビジネス・デザイナー・エンジニア。どの職種でもそのシーンで必要な人にリアルタイムで化ける人」多能人材となりました。

こうなったあとのメリットは先程述べたとおりですが、ここまで来た後が本番だと思っています。

正直ちょっとここまでいけるのかどうなのかは自分でもわかりません。挫折してしまうかもしれないし、別の方向にいってしまうかもしれません。 現時点で私の意志は堅く、多能人材に挑戦したいです。私は今2段階目の途中なので、まずはエンジニアをしっかり続けて、CさんをAさんにする活動を続けていきたいと思います。


まとめ

はい、いかがだったでしょうか?年末ですので、今年の振り返りから現状の把握、将来像を考察してみました。みなさまの今後のキャリアのご参考になれば幸いです。 ソフトウェア開発はまだまだ可能性があります。私は今エンジニアという構造の中身の方に身をおいていますが、可能性を感じるその気持ちは日に日に強くなっております。

今回は職種の壁をテーマに執筆しましたが、どうにかしてこの壁を撤廃・攻略し、その一心で今後も活動を続けていきたいと思います。

2019年、みなさまはどのような自分だったでしょうか。 2020年、みなさまはどのような自分にしたいでしょうか。

私もそんな問を自分に問いかけながら年を越したいと思います。

最後までお読みいただきありがとうございました。




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

SIer/年収1000万を手放した私 〜選考全落ちを経験しながらもやりたかったこと〜(中編)

f:id:tai-hey:20190923133222p:plain

はじめに

みなさま、お久しぶりです。

私は プレイド のエンジニア、大平 (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで プレイド で勤務しています。

twitter.com


本エントリは、去年年末に執筆した、 前編 の続編となります。

www.taihey-blog.com

※前編の反響が私の想像以上に大きく、続きを読みたいといろいろな方々から応援を頂きました。ありがたいことに家族や友人、twiter、ブログのコメントでもたくさんのコメントを頂きました。ありがとうございました。



- 本連載の構成と中編について

エントリの構成は下記の通りです。
- 前編 (NRI〜転職決意まで)
- 中編 (退職〜プレイド入社まで) ※本エントリ
- 後編 (転職後〜現在まで)


本連載は、私が自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。昨年は転職含め怒涛のように環境が変わっていきました。恵まれた大企業の環境から個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦しておりました。社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

中編はその苦労の直前(といってもここでも大変なのですが)、転職活動の内容となります。

転職してから私は、Webエンジニアとして一年の間、twitter などで、SI から Webエンジニアへの転職に関する議論をいろいろ見てきました。どういうやり方が正かどうかはわからないのですが、その議論を見た上で私の転職活動を振り返ってみました。今思うとポートフォリオを作ったりする正攻法ではないと思っているため、この頃の私の転職戦略はあまりおすすめできないと思っています。私自身、はじめての転職だったのでかなり手探りで活動をしておりました。年齢も30歳直前を迎えていたため、転職に焦っていたのも事実です。慌てながらも転職活動をしていたので、一種の体験談として読んでほしいと思います。

まずは、前回の振り返りからいきましょう。

- 前回のあらすじ

(前編参照) 新卒で文系SEとして野村総合研究所(以下NRI)に入社した私は、普通のNRI社員として働いていました。なれないITの仕事に苦労しながらも、このままSEとしてキャリアを積み続けるのだと疑わず、順風満帆な人生を歩んでおりました。しかし、6年経ってプログラミングスキルが満足に身についていないことに違和感を覚え、G's academy (以下 G's )に入学します。

gsacademy.tokyo

G's で必死に深夜まで(または朝まで)プログラミングを業務と並行して書いた数ヶ月。その中で G’s のメンターであるWebエンジニアの方々やモダンな技術に触れていくことで、自身のキャリアの方向性を考え直し、レーンチェンジを決意します。

「30歳直前を迎えた今、恵まれた環境を捨てても本当にやりたいこと、将来像を追いかけたい」

PM・業務を考えるマネジメントメインのロールモデルではなく、エンジニアとして構造や処理を考えるロールモデルを目指し、転職を決意します。


それでは、ここからは前編の続きからとなります。退職を決意した2018年2月、後転職活動開始のエージェント探しからとなります。

3月/転職活動開始、エージェント選定

- 転職ってどうやるのか。とりあえず情報収集だ。

仕事ではやりたいこと(前編のブログ参照) を業務内容にしたい、その一心で転職を決意します。 とはいえ、始めての転職活動となるので、並走していただくエージェントを選ぶところからはじめました。今はリファラルや wantedly なども方法だったりしますが、当時の私はweb系の友人も多くなければ、カジュアル面談という概念を転職活動ではじめて知るくらいの転職知識が皆無の状態でした。

また、動き出すにはまずは情報収集・インプットが大事。自分が市場からどう見られているのか(市場価値)、やりたいことがどれくらい実現可能かどうかも知る必要があります。そこを明るくするためにもエージェントとの面談活動の目的でもありました。

- やりたいことを深堀りしながらエージェントを選定する。

普通の転職エージェントや、IT業界全般が強いエージェント、Web 系特化のエージェントなど、各エージェントの特徴をネットや友人などに聞き、情報収集を行いました。本編とは少しそれますが、wantedly にてカジュアル面談を繰り返し、自分のやりたいことと市場価値の情報収集も行いました。

トータルで5・6社くらいのエージェントと面談を行いました。それぞれの面談の中で自分の市場価値ややりたいことがどれくらい妥当性があり、転職する際にどのようなモデルケースがあるのかをすり合わせていきました。

- やりたいこと・キャリア・自身の市場価値が見えてくる。

面談をいくつか繰り返す中で、下記のことが明確になってきました。 例外のケースが有るかと思いますが、私が感じた内容となります。

  • 30歳という年齢は労働市場として未経験レーンチェンジは、ほぼラストチャンスであること
  • 自分が20代で積み上げてきたキャリアはエンジニアというよりも PM ≒ ビジネスサイド
  • 自分が将来的になろうとしている将来像は長期的に見れば可能性はある
  • 短期的にやりたいことはプログラミング
  • レーンチェンジとして業務未経験のハードルはやっぱり高い。ここはチャレンジ。

が見えてきました。

面談の中で自分で明確になった箇所や、労働市場からどう見えているかをすり合わせていく中で、自分のやりたいことと経緯・キャリアの簡単なスキルマップをパワーポイント作成しました。このパワーポイントを作成することでかなり自分の転職活動の軸が明確にすることに役立ちましたし、実際に面接官に渡して説明したりすることもありました。こちらは別ブログでまた紹介したいと思います。

- エージェントの決め手はやりたいことの理解深度。

今回の私の転職は、待遇等ではなくやりたい業務内容の優先順位が一番高かったため、 企業選びに対して企業選定の精度を高めるためには業務内容を正しくエージェントと同期させる必要がありました。

その前提を踏まえた上で、それぞれの面談を通して、あるエージェントに決めました。今までやってきたこととこれからどんなレーンチェンジをするかを、面談をしていく中で一番よくヒヤリング頂き、理解して頂けたと感じたことが決め手になりました。

例えば、その方はジーズアカデミーをご存知で、その中の活動内容もよく理解してくれていたことでした。他のエージェントはIT業界自体は詳しかったりするのですが、お願いしたエージェントはその中でもサーバーサイドとかフロントエンドの話や、技術のより詳しい範囲での理解をしてくれていたことが会話の中で読み取れました。また、実際に私と似たようなレーンチェンジ事例を担当されていたことも決め手となりました。これは巡り逢いかなと思っております。

面談前後も感触と心境を聞いて頂いたり、他の企業との日程調整を丁寧にしてくださり、かなり助かりました。とても感謝しております。ありがとうございました。

4月/退職・転職応募開始。しかしメガベンチャー・有名企業・大手のエンジニア職に応募全落ちで撃沈。

- 転職活動の前にまずは退職だ。

ここまでの活動で、エージェントも決まった、やりたいことも固まってきた、というところまで来たのですが、転職活動よりも先にやることがあります。NRI への退職願です。

通常であれば現職を続けながら並行で転職活動、ということになるでしょう。ただ、30歳直前という年齢を鑑みていち早く業務でプログラムを書くため、とりあえず先にやめることにしました。おそらくテンパって頭がおかしくなっていたのでしょう。と今になって思います。

並行でやってしまうと、面接をするタイミングも業務後になりますし、内定をもらったとしても現状の業務と調整し、退社日を決め、有給も取って、、となると半年後とかになってしまう可能性もありました。今となっては数ヶ月くらいそんなに変わらないのではと思っているのですが、当時はとりあえずやめることにしました。

ここは NRI の方に本当に感謝なのですが、理由を説明したら快く応援してくれ、業務と要員の調整を行っていただけました。スムーズに4月末を最終出社とすることができました。ありがとうございました。

- もう後はない。転職活動応募開始。

会社も無事退職することができたので、転職活動の応募を開始します。もう後には戻れません。転職活動がはじめてではありますが、自分の市場価値がどこまでいけるのかチャレンジしてみようとまずはチャレンジングな応募を中心に行いました。

選定企業軸はエンジニアファーストで、自身がコードを書く業務につけること、テッキーな社員が多いことです。その軸の中からなるべくレベルの高い企業を選定しました。

エージェントとも相談し、その評価軸からレベルの高いメガベンチャーや大手インターネット企業20社ほどを受けることにしました。

まだ始めたばかり。応募企業も就活のときとは違い、転職活動では十数社受ければいずれかはいけるだろう、と強気でいました。私自身正直どこか受かるだろうと高を括っていました。それが甘かったのです。

- 結果は全落ち。

結果は全落ちでした。4月の NRI 最終出社の時点では残り一社のところまで来ておりヒヤヒヤしていましたが、希望していた企業だったのでその最終面接が終われば転職活動は終わりにする予定でした。

しかし最終面接で落ち、応募企業にすべて落ちることになりました。 送別会の時に、「今転職活動どんな感じ?」と当時の上司や同僚に聞かれ、「全部落ちました、一からですねぇ」と笑ってごまかしていましたが内心はかなり不安だったのを覚えています。敗因は書類で半分以上落ち、プログラミングのテストと併せた筆記で落ちるところも多かったです。想像ですが、未経験30歳直前でコードを書く職を受けるということのハードルの高さ、プログラミング技術力がシンプルに足りなかったのだと思っています。まあそれは落ちるよね、と落ち込みながらも納得していました。

(内心)ああ、どうしよう、終わった。もう一度一からやり直しだ。

ここでエージェントに改めて相談に行くことに。。。






5月/追加15社Web企業を中心にエンジニア職で再チャレンジ。

- 気を取り直して再チャレンジ。

5月に入りました。新緑で天気もよく、世間は超大型のGWだったりするのですが、私の気持ちは真逆。そんな気持ちの余裕はなかったのです。

でも全落ちしたからといって落ち込んでいる場合ではありません。後戻りはできないのです。前に進むしか無い。そう自分に言い聞かせて活動を再開します。ていうかそもそも先に辞めてしまったお前が悪い。お金だって半年前はやめるなんて思ってないから転職活動に向けて特別貯金なんてしていない。もって数ヶ月しかない。まさにキングダムの壁将軍状態。兵糧(貯金)がない。昔に遊びすぎた。

今後受ける企業軸は変えず、エンジニアファーストでコードを書かせてもらえる企業中心のままです。エージェントに相談し、追加で企業を選定しました。

兵糧がないのに反省の色が見えません。やっぱり頭がおかしかったのでしょう。

今回はある程度選考が通るようになります。エージェントに選考企業を配慮して頂いた結果が功を奏しました。

- 面接中に感じた違和感。

書類選考は通るのですが、少しここで違和感を感じます。

面接をしてみると、エントリーする職種の業務内容が、クエリとかデータを作ったりもするビジネス職でした。また、エントリーはエンジニアだけれども、選考の途中でコードを書く系のビジネス職での選考をおすすめされるのです。

おそらくエージェントがエンジニア職希望です、と出しても、企業側のある程度受け入れを考えると、エンジニア職ガッツリよりも、エントリーはコードを書くビジネスとして入り、いずれエンジニア寄りにいったほうがよいという判断なのです。確かにもともとSEだったのでそのほうがバリューもでやすいし、待遇もそんなに落とさなくてよいし、客観的に見ても合理的な判断だと思います。

それと最終的な将来像がITコンサルタントITアーキテクトエバンジェリストをかけ合わせたような人材(詳細は別ブログで)になりたいので、そのためにコードを書ける職種につきたい、と書類に書きましたし、面接でそう言ったのでそう思われるのも無理ありません。

ですが、私はかなり違和感を感じます。

- 違和感を内省を重ねて明確に。

ここで内省を重ね、その違和感を深堀りしていきました。

「そうだ違う。私は今すぐエンジニアになりたいのだ。はじめは業務でほぼ100%コードを見ていたいのだ。そうしないと業務内でコードを書く濃度が薄くなっていまう。一番キャリアのネックになっているプログラミングの成長が遅くなってしまう。最速で将来像に近づかなければ。」

こういう周りになんて言われても将来像にこだわるところが要領悪いなと31年生きてきて思います。

申し訳無かったのですが、内定を頂いていた企業も選考を進んでいる企業もエンジニアでないならばと辞退させて頂き、応募する企業を再度検討することになるのです。

6月/修行だ。年収3分の1でもいいからと必ずコードをかけるエンジニアになれる企業を中心に応募。

さあさあ転職活動が泥沼の様相を呈してきました、これはもつれ込みそうです。久々に昔のことを書いていてほんと頭がおかしいなと思うのですが、もう少しなので筆を進めていきます。

- 3度目の正直。再度応募企業を見直し。

5月の面接の内容と、感じた違和感について素直にエージェントに伝えたところ、嫌な顔一つせず、再度選定を進めて頂けました。仕事とはいえ本当にありがとうございました。。。

流石になりふりかまっていられません。エンジニアとしてコードを書けるところであれば、条件は度外視です。スタートアップ、ベンチャー中心にとにかくコードを業務で書ける職種の軸でエージェントに選定してもらいます。自分でもネットで企業を調べながら選定企業を加えてきます。もう必死です。

それでも順風満帆には行かず、スタートアップもどこも受け入れてくれるわけではなく、エンジニア業務経験のないのであれば体制上余裕がないのでまず受け入れられない、という企業も実際にありました。確かに現状スタートアップの中にいて体制の余裕の少ない企業が多いのも共感できます。

- プレイド との出会い

そんな中受けていた一社の中に プレイド がありました。面接したのは6月の中旬。選定企業の中でも最後のほうで、本当に軌跡に近かったと思います。面接の時点で他の会社から内定がでていたのもあり、そんなに猶予もありません。

一次面接時はまだ五反田のオフィス。今ほどは大きくないオフィスビルの窓際の駅の見える小さな会議室で面接したのを覚えています。



- 話せば話すほど プレイド の文化・考え方に惹かれる。

一次面接、二次面接と進んでいくにあたって、なにか他の会社とは違う惹かれるポイントを感じます。なんかこの会社、他と考え方が違う。変だ。

考え方の普通じゃなさはまた別の機会に置いておき、プレイドに惹かれた理由、マッチした理由を紹介したいと思います。

- 私がしたい「技術力で市場を作ること」の気づきと共感。

まずスキルよりも将来的な志向性で見られていたことが大きかったです。私の将来像(ITコンサルタントエバンジェリストITアーキテクトをかけ合わせたような人材像)に共感していただけました。そこまで特に進展がなかった将来像でしたが、新しく言語化してもらえました。

「ああ、大平さんは技術力を武器に市場を作っていきたいんだね。」

なるほど、たしかに市場を作っていく、という言語化はしていませんでした。思ったよりこの言葉が私の中でしっくり来ており、面接時に更に将来像が明確になったのは久々でした。この将来像に共感してもらえて、今でも社内でもその話をすることがありズレていないのが実感できます。

- 将来像へのスキル構築プロセスが自由だった。

次の点ですが、将来像へのスキル構築のプロセスも自由度が高かった点が挙げられます。5月の面談のように、普通のキャリアであれば、コードを書くビジネス職の採用になるはずだと思います。私は最終的にはそちらに近い方向に向かいたいのですが、プレイド はしっかりエンジニアとしてコードを書くことを尊重してくれたことがマッチしていた要因の一つでした。二次面接で当時のCTO(現CPO)と面接した時は、いつかはフロントにでるかもしれないが、まずは納得のいくまでコードをかいてよい、ということが決め手となりました。フロントに出るイメージも、100%ビジネスなのか、70%ビジネスで30%エンジニアなのか、スタンスも自由に決めて良い。とのことでかなり自由度の高さに惹かれました。

- Google リスペクト文化

それと Google リスペクトの文化です。私はミーハーなので Google 大好きです。NRI の時から Google の働き方や考え方に憧れて書籍を読んでいたくらいでした。プレイド 社内でも Google 文化をリスペクトしているし、実際にやりとりもある、という話を聞けたの惹かれた理由の一つです。

- そして入社

本当にそこからはトントン拍子で話が進みます。最終的に5社ほど内定を頂いており、どの会社も魅力的な企業でかなり迷いましたが、6月下旬には プレイド に内定受諾の返事をし、7/1から入社となるのです。

はぁ、、ここまで長い道のりでした。はじめはどうなるかとは思いましたが。。 有給も尽きているため、行き着く暇もなくここから私のエンジニア生活が始まります。。。ここからが本当の勝負ですし、本当に大変です。。



最後に

中編エントリをお読み頂きありがとうございました。 最後に心境変化のまとめと今後の方向性を少し追記して終わりにしたいと思います。

- 転職活動を通じて変化した心境と覚悟。

正直4月で全落ちしてしまった時にはどうしようかと思っていました。転職するなんて数ヶ月前には思っても見なかったので、貯金もしておりませんでした。もともと金遣いが荒くロードバイクとか飲み会にかなり使っており、辞めてから数ヶ月やりきれるかどうかという状況でもありました。とはいえやめてしまったので転職活動をやるしかありませんでした。ここはかなりしんどかったのを覚えています。あきらめて内定の出そうなところに落ち着きそうですが、将来像になるために繰り返し内省してモチベーションを保ち、納得して転職活動を終わらせるまで頑張ったのを覚えています。

また、覚悟が変わりました。NRI・大企業という恵まれた環境や年収を捨てていますので、もちろん以前より年収が下がっていますし、普通にしていたらこれ以降伸びるとは思いません。前職では大企業ですしほぼ会社の業務に乗ることで給料がでていたと思いますし、ある程度昇給もしていったはずです。

ただ、これからの人生は違います。そういう生活や環境は捨てました。プレイド はスタートアップなので、大企業ほどの個人への後ろ盾はありません。しかも移った職種は技術力がシビアに問われる世界であるwebエンジニア。自分の市場価値・個人としての実力を意識して磨いていかなければいけない職種です。ただ、必死に手を動かしスキルを磨けば市場価値も年収も上がっていくはずですし、なにか私個人としてのバリューをダサなければいけません。今後はエンジニアとしてその市場価値の追求もこだわっていきたいと思っています。

- 次回について

長めの体験談エントリでございましたが、お読み頂きありがとうございました。 転職するまでを書いてきた本連載ですが、次回が一番苦労した経験となります。 30歳、レーンチェンジをしたことでどんな点が苦労したのか、メンタル的に変えなければいけなかったのか、スキルとして何を苦労したのか、業務でやっていくのにどうやって克服していったのかを綴っていきたいと思います。

前編中編間よりは間は開かないと思いますが、もう少々お時間をいただければと思います。それでは、後編エントリでまたお会いしましょう。




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com

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

f:id:tai-hey:20200102175043p:plain※2018/12/26 少し内容をブラッシュアップしました。

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

私は プレイド のエンジニア、大平 (@Victoria_Peak_) と申します。 7年勤めた野村総合研究所を辞め、2018/07〜現在まで プレイド で勤務しています。

Kaz_Victoria / SaaS & SIer の境界線とは (@Victoria_Peak_) | Twitter

と申します。

adventar.org twitter.com

はじめに

投稿のきっかけと動機

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

twitter.com

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

tech.plaid.co.jp

qiita.com

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



本連載の構成と前編について

エントリの構成は下記の通りです。
- 前編 (NRI〜転職決意まで) ※本エントリ
- 中編 (退職〜プレイド入社まで)
- 後編 (転職後〜現在まで)


本連載は、私が自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。昨年は転職含め怒涛のように環境が変わっていきました。恵まれた大企業の環境から個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦しておりました。社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

前編は新卒で入社したNRI時代から始まり、その中でキャリアをどう見直し、何をきっかけに転職を決意したのかを綴っております。

私は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年目)

SEとしては順当に経験を積む

そんな違和感を持ちながらもSE3年目までに2プロジェクトを経験しました。3つ目の金融系プロジェクトは4年ほど長く経験するプロジェクトとなり、順当にSEとしては経験を積んでいきます。給料も上がっていくし、仕事としても任される範囲の規模も大きなものになっていくので、成長している実感があり充実していました。

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

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

違和感を取り戻すために行動する(6年目後半〜7年目前半)

そんな中、プロジェクトとしても落ち着いている時期で、仕事に余裕がでてきましたので、目の前の業務よりも将来像を考えるようになりました。その考察の中で私はやっぱりプログラミングができていないことの違和感を再度思い出します。社内のプログラミング関連の研修を受け出しましたし、自分でも集中的にやるべきだと思って自費で数十万払い、まずは普通のプログラミングスクール(Java silverくらいまでの授業)に通いはじめました。平日の日中は業務、夜はプログラミングスクールで体力的にもしんどかったですが、プログラミングできるようになりたいという思いが強く、通うことができました。プログラミングに関して少しだけ理解が深まりましたが、ものを作れるレベルかというとそうではなく、演習をなぞるレベルにとどまっていました。プロダクトを作れるようになるとまではいきませんでしたので違和感が取り切れていませんでした。

G's academy でWeb業界・技術に出会う(7年目の後半)

他にもプロダクトを作れるようになるプログラミングスクールはないかと探し始めました。そこで出会ったのが「G's academy」です。

私はこの Dev 9期生として試験に合格し、通い始めます。今まで会うことのなかった様々な人や技術との出会いがあり、大きな人生の転換点となります。

gsacademy.tokyo

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

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

NRIで行っていた業務内容との違いに気づく

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

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

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

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

tech.plaid.co.jp ※2.1 価値創造のためのシステムとその構造について:を参照

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

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

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

Webエンジニアになると決意する

Web業界のWebエンジニアのロールモデルに憧れた私は下記の結論に至ります。

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

を目指そう。

入社当初はSIerとして技術を理解しているコンサルタントとして働きたいと思っていたのですが、情報技術は思いの外深く、より技術を語る道にのめり込んでいきました。情報技術を知れば知るほど、ITも知ってて経営を進められる人材から、技術特化の方向にグラデーション的に意識が傾いていきました。

5. (考察)本当にやりたかったことを判断する切り口

前章までWebエンジニアを目指す経緯まで述べました。ここからは考察となります。辞めると決断するにあたり2つの切り口が大きな判断材料となりましたのでご参考までに読んでいただければと思います。

人が組織(会社)に属し続けたいと思う基準

やめようか悩んでいる時にtwitterを眺めていたら、会社に属し続ける基準についてのツイートを見つけました。下記の3点の内2点に魅力があれば人は会社に居続けやすい、ということを見て、納得感が強かったことを覚えています。

  • 仕事

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

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

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

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

30歳という年齢

お金に後ろ髪をひかれながらも最後に退職の決め手になったのは、30歳という年齢です。 実は社内でも「処理と構造を考えるロールモデル」をずっと探したのですが、異動するコストや時期もありますし、異動したところで本当にやりたいロールモデルが見つかるのか難しいのではと判断しました。 また、転職市場を調査(エージェント、wantedlyでカジュアル面談、人材業界関連の友人と相談)してみました。今までプログラミングの業務経験のない私はWebエンジニアとしてレーンチェンジするにはかなりギリギリのライン(転職市場では不利)であることがわかりました。私の業務経験からするとコンサルタントやマネージャー職としては需要があるものの、Webエンジニアでゴリゴリプログラミングするというのは需要は相対的に少なかったです。

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

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

まとめ

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

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



次回について

前編にて転職を決意した私ですが、その後を 中編 に記載したいと思います。 そして私は何をおもったのか、転職先を見つける前に先にNRIを辞めてしまいます。それが吉と出るか凶とでるのか。転職してプレイドに入るまでどのような転職活動を行ったのかを、次回は綴っていきたいと思います。


www.taihey-blog.com




P.S. 日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。

twitter.com www.wantedly.com