はじめに
みなさま、お久しぶりです。
私は プレイド のエンジニアの大平 (@Victoria_Peak_)
と申します。
7年勤めた野村総合研究所を辞め、2018/07〜現在まで 株式会社プレイド で勤務しています。
普段からつぶやいたり(プログラミング・SaaS/SIer・ロードバイク・減量など)しておりますので、本エントリを読んで興味を持たれた方は、twitterでフォロー、リプライ、メッセージなどをいただければと思います。基本すぐに回答します。
本エントリは、去年2018年12月に執筆した、 前編 と、
今年2019年9月の 中編 の続編となります。
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月)ので、その時採用するアーキテクチャも変わってくる、ということを学習しました。
説明だけではプロダクトを理解するのは (特に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 の度に毎回触れる機能が変わるのです。
- チームが変わるため、環境、構築方法、データも毎回変わる
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 で「あれ?なんかおかしくない?この前の修正が反映されてないよ」とザワザワしだします。
「。。。すいません、、それ僕かもしれません。。」
この事故をきっかけにまた私はどん底に落ちていくのでした。
まとめ
この事故の後、私は人生最大のどん底にいくことになります。
今は元気でやっているので、無事戻ってきているのが分かると思うのですが、この後が人生で一番つらい時期であったと思います。
復活の章 では、どん底だった話と、それから何をきっかけに上向いてきたのか。そのへんを中心にお話していきたいと思います。
同時にリリースしておりますので、気になる方は下記から続きを見ていただければと思います。
P.S.
日々の活動の記録を見たかったり、転職やその他仕事についてご興味がれば下記までよろしくお願いします。