プロダクトを愛するということ〜ぼくは自社開発に向いていない〜

f:id:tai-hey:20200505194900j:plain みなさんこんにちは。

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

twitter.com

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


こちらの記事は 障害対応という花形 の続編となります。

www.taihey-blog.com




今回は下記の本ブログのメインストリームである「年収1000万を手放した私」のスピンオフとして書いています。


www.taihey-blog.com


- 前回のあらすじ

前回はIT業界の人事のお二方の質問をきっかけに障害対応を題材に、ビジネスとエンジニアのハブになることのキャリアの考察を深めました。

今回は、SIer / 自社開発webスタートアップを経験した私から見える、2つのビジネス構造の違いを分析し、そこで自分をどう活かしていくかを考察していきたいと思います。


0. 今回の構成

本エントリをきっかけにさらに考察を深めたのですが、結論から言います。

私は自社開発エンジニアに向いていません。

そこに至るまでとその先どうするかを綴っていきます。

今回は下記の構成で考察を展開していきます。

- 1.受託開発と自社開発の違いを分析する
- 2.ぼくは自社開発に向いていない
- 3.汎用ソリューション&プロダクト機能のマッチ力で勝負する




あくまでサンプルは私の観測範囲になります。

私のキャリアがSIer大企業→自社開発webエンジニアスタートアップのため、規模の差異 × 異業種 × 異職種のため対極といっていいほど離れた環境を歩んできました。

軸を混ぜすぎてしまうと混乱するので、規模の話は置いておいて、受託:SIer/PMキャリア→自社開発/webエンジニア軸で考察することにします。


1. 受託開発と自社開発の違いを分析する

■ ビジネスモデルの違い

- 受託は顧客のシステムを作る

まずはビジネスモデルの違いから見ていきましょう。

受託と自社開発はビジネスモデルが違います。前提としてここが差異が大きく、話のベースとなります。

まずはこの差異について考察していきましょう。

こちらの図を御覧ください。


f:id:tai-hey:20200505171011p:plain
受託のビジネスモデル



図の登場人物は顧客、顧客が使うシステム、付加価値とお金を産むビジネスモデル、提供先のエンドユーザー、受託会社となります。

システムとはビジネスモデルを最大化する資産であると私は認識しています。

資産の所在は顧客会社にあり、これをどのように作るかでビジネスモデルを成長させていきます。

受託会社側はこのシステムを作らせてもらう形で業務を請け負います。


- 自社開発は自分たちのシステムを作る

自社開発の場合はどうでしょうか?

自社開発の場合も価値を生んでくれるプロダクトに労働力を注ぐことが重要となりますが、資産の所在が違うことに注目してください。

自分たちの事業の自分たちのシステムを作ることが前提となります。


f:id:tai-hey:20200505171044p:plain
自社開発のビジネスモデル



これで前提条件が抑えられました。もう少し考察していきましょう。


■ 提供価値の違い

- 受託開発の価値はフローの最大化

次は提供価値の差異を見ていきましょう。

先程ビジネスモデルを紹介したので、もちろんそれに伴い私達が提供する価値も変わってきます。

併せて各々パワーを入れなければいけないスキルやスタンスが浮かび上がってきます。

顧客のシステムを構築する受託の会社は、ケースに合わせた労働力を提供することが重要です。

締結した契約期間内で、顧客を理解し、顧客だけでは構築できない戦略のコンサルティングや開発デリバリー、マネジメントなどの提供フローの価値を最大化することが至上命題となります。

モノではなくコトの提供です。

コンサルタントでいうお客さんに向いて働き value を出すのと同じですね。




f:id:tai-hey:20200505172236p:plain
受託の価値




- 自社開発の価値はストックの最大化

反対に自社開発では、フローの最大化ではなく、いかに自分たちのプロダクトを資産=ストックとして作り上げることが重要です。

プロダクトがマーケットにとって素晴らしいものであればあるほど、それ自体が生産してくれる付加価値が最大化されます。

自分たちが動かなくても、プロダクトが最大限価値を提供してくれる、最高の資産にすることが至上命題になります。

こちらはコトではなくモノの提供です。

弊社ではこれをプロダクトを「磨く」といいます。


f:id:tai-hey:20200505172940p:plain
自社開発の価値



■ 決定権の違い

- 受託はソリューションのプロ、コンサルタントチック

次に決定権の違いを見ていきましょう。

受託はお客さんが儲かることが正で、要件がどうなれば正しいか、儲かるのかは顧客が決めます。受託会社はそれをいかにして実現するのかが大事です。

自分たちがビジネスに対して持った違和感は、というのは提案やアドバイスができても決断ができません。

また事業自体の意味などを説明を受けたりすることはありますが、なんとなく自分ごとにさせることは難しいです。

私が前職でいたNRIは、長くお付き合いするタイプのSIerなので、何年か同じお客さんとプロジェクトをすすめることが多くなります。

ただ、お客さんの事業や業界に対して理解は深まるのですが、次このビジネス企画をしよう、とはなかなかなりません。

本番リリース後もなんとなくお客さんから効果や問題がないかどうかを見聞きすることのほうが多く、ビジネスを自分ごとのように体感することが難しいです。

あくまでビジネス企画は顧客スタート、決定も顧客側に裁量があります。




f:id:tai-hey:20200505174037p:plain
受託の決定権



このようなことから、受託とはコンサル的な立場に近いことがわかってきたと思います。

ただ、そのおかげで伸びるスキルもあります。

会社間をまたぐからこそ、合意形成などのプロジェクトマネジメント力、分析や説明が必須なコンサルティング力は伸びます。ソリューションのプロと言えると思います。

反して自分たち発進の事業企画力はスキルとして経験が積みにくくもなります。


- 自社開発は、エンジニアもビジネス企画に裁量を持つ事業会社である

自社開発を経験してきましたが、SIer時代よりもプロダクトに対して自分たちで決定している = 責任を持っているように感じます。

自社開発は自分たちの事業を伸ばすことが至上命題のため、ビジネス企画/プロダクトのプランニングについても自分たちで裁量、責任を持ちますし、逆にそれをしっかりグリップしないとビジネス/プロダクトとしてぐらつくことになります。

技術選定も事業(内部的なスキルセットも含め)として最適なものを自分たちで選びます。

業務要件の深いところはビジネスサイドのプランニングをしているメンバーに確認することがありますが、エンジニアもビジネス企画がどのようにインパクトがあるのかもしっかり理解しなければならないと感じます。

機能リリース後も自分たちの事業のため、それがどうマーケットに響いたのかも近く感じるようになりました。


f:id:tai-hey:20200505174343p:plain
自社開発の決定権



2. ぼくは自社開発に向いていない

■ 2年間のキャリアを自己否定する

- 受託に向いているのはフローを最大化することが好きな人

これらを踏まえ、約2年間エンジニアをしてきた経験を照らし合わせて考察していくと、私はある結論に行き着きました。


「メインキャリアとして、私は自社開発エンジニアは向いてない。」


あれほどなりたかったエンジニアに転職することができ、自社開発エンジニアとして全力で駆け抜けてきた2年間でしたが、思わぬ結論に至りました。

実際ちょっと落ち込みました。悩みました。

ただ、私のモチベーションをダイアログしてみると、プロダクトではなく、汎用的な理論やスキームを確立することにモチベートがあることに気づきます。

ビジネスサイドがやりたいことを100%、それ以上に実現することに喜びを感じます。

思い返してみると新卒で入った SIer、つまり受託スタイルは性格的に私には合っていたのでしょう。

私のキャリア像として、はじめのほうに提示した下記の図のように、本来は幅広いデジタルソリューションを提供できる人材が理想なのです。


f:id:tai-hey:20200505180814p:plain
受託はフローの価値を最大化する



過去を振り返ってみると、面接の時の発言を思い出しました。エンジニアになりたかったのは、エンジニア一筋でコードのみ書くのではなく、どんな顧客でも最適なソリューションを提供し、「フローの価値を最大化する」ことだったことなのです。


■ 自社開発とは:業界を想い、プロダクトを愛するということ

ちなみに自社開発に向いている人はどういう人物像なのかも考察してみました。

プレイドと他のいくつかの現場の自社開発のエンジニアを見ているのですが、向いている性格としては、


「プロダクトや業界に「愛」があること」


だと思います。

こういう技術だけを使いたいよりは、こういうプロダクトを作りたい、だったり、この事業/業界をこうしたい、などの想いを感じることが多いのです。

この思いがあれば優先順位がプロダクトや事業になりますので、障害対応や細かい改修であっても嫌な顔ひとつせずに対応できているように見えます。

土日もプロダクトのことを考えますし、試し開発をしてみたりします。

インタビューしたわけでもなく、アンケートを取ったわけでもないのですが、現場に2年間経験している中で、自社開発で活躍しているエンジニアは、言葉の節々にもそのような意思を感じるのです。

自社開発に向いている人はプロダクトやものを磨くことがとても好きだったり、業界や業務を好きになれる愛を持てることなのではないでしょうか。

プロダクトに対して親心・愛をもつということが子育てのように「磨く」という行為に反映されるのだと思います。


3. 汎用ソリューション&プロダクト機能のマッチ力で勝負する

■ 私はソリューションの価値を最大化したい

このように私はプロダクトに対して「磨く」ということにあまりモチベートができないことがわかりました。

そうすると2つ疑問が湧いてきました。


  • 前回のエントリのように、障害対応できるのだから自社開発向いてるんじゃないの?
  • 向いてないならエンジニア辞めたらいいんじゃないの?

この質問に答えていきましょう。

- 汎用スキーム化/仕組み化が好き

1つ目の疑問についてです。

個々のプロダクトや機能を伸ばすイメージで開発することにモチベーションがわかないのですが、インシデントマネージャーはあくまで障害対応コンサルタント的に、自動化の仕組みや汎用的な基準を作っているのです。

このスキームはKARTEでなくても使えるので、汎用的なスキルなのです。

この行動自体は汎用的なのでそこにモチベートを感じていますし、向いていると思います。


- 多機能プロダクトを武器にソリューションを最大化する

次に2つ目の疑問についてですが、これについては図に表してみました。


f:id:tai-hey:20200505183623p:plain
マーケット/顧客/ソリューション関係図



自社開発は左のように複数顧客に対して一つのマーケットで、プロダクト特化 or 業界特化が普通です。

そのため、業界やプロダクトに深く入り込む愛が必要なのです。

マーケティングツールだと思っていたのでと業界特化・固定ではモチベートがあがらないと思っていました。

入社当初は業界特化型だとおもっていましたが、実はKARTEは、幸いにも業界問わず、一つのプロダクトで幅広いデジタルコミュニケーションのソリューション提供できることに気づきます。


f:id:tai-hey:20200505183851p:plain
KARTEを武器にした幅広いソリューションを実現したい



上記の図のように、プロダクト開発に携わっていく中で理解を深めるほど、もしかしてKARTEはフローにレバレッジをかけて価値を最大化することができる。とても大きな武器になるのではと気づいたのです。

ここで思いついたのがプロダクト・アウトの自社開発企業で、汎用ソリューション&プロダクト機能のマッチ力で勝負する、というデジタル人材キャリアの可能性でした。


■ 企業システムの医者を目指す

- KARTEの汎用性、多機能性

この章に入る前に、まず狙うポジショニングを説明するために、武器となるKARTEの機能汎用性を図で説明します。(本当にざっくりなのでHPを見てもらったほうがいいかもしれません。)

karte.io




f:id:tai-hey:20200505191110p:plain
KARTEの汎用性



幸いにもKARTEは他のプロダクトよりも機能の汎用性がとても高いと感じます。

そこを目指していることが日々活用していく中でわかってきました。

いいかえるならインターネットのミドルウェアで、プロダクト分類では Horizontal/SaaS に分類されます。(ここの考察は別のエントリで述べます。)

KARTEマーケティングツールスタートであるものの、今や機能としては顧客のサイトでやりたいことは何でもできるものではないかと思います。

機能として顧客へのメール,LINE,ポップアップ,アンケート,トラッキング,ユーザー解析,外部データ連携...などなど数え切れません。

私はこの「どの業界でも通用する汎用性」にとても惹かれていて、これを使えば様々なソリューションが展開できると思っています。

プロダクトを「磨く」ことには熱量を込められませんでしたが、このプロダクトを使って「幅広くソリューションする、機能をうまく顧客にマッチさせる」ということを極めていきたい、そんな思いで進めています。


- 直近のポジショニングコンセプト

プロダクトの汎用力が理解できたところでポジショニングコンセプトに入ります。

プロダクトを磨くことが苦手な私でしたが、フローを最大化することは得意ですので、直近では、自社開発ではこのようにポジショニングをしようと思っています。

f:id:tai-hey:20200510135949p:plain
自社開発でフローを最大化するポジショニングを取る、人材コンセプト




汎用プロダクトといっても、100%顧客にvalue出せるとは限りません。

実現したいビジネスに対して使う機能が正しい選択か、使い方のフォロー、(プロダクトのコアコンセプトを損なわないような前提で)特定のお客さんようにオーダーメイドしたり、足りない機能を拡張したり、ユースケースに合わせた「プロダクトのラストワンマイルの開発」などが必要だと思っています。

前回の「障害対応という花形」で述べたように、ビジネスとエンジニアのハブのなり、仕組みづくりをすること、開発力が必要であれば自力で突破できるポジショニングです。

www.taihey-blog.com

まずはそこのポジショニングで開発力及びプロダクトソリューション力を深めていきます。


- 将来は、企業システムの医者

前節でKARTEの多機能性/汎用性を表現したところで、これを武器にした全体像を表現したいと思います。


f:id:tai-hey:20200510134332p:plain
幅広いソリューションとグランドデザインを提供できるデジタル人材


このように企業システムの医者のように様々な視点からソリューションを提供する人材を目指します。


イメージができたところで、下記の5つの能力をメインとして身に着け、企業システム課題へ対抗する汎用力を伸ばしていきたいと思っています。

いきなりすべて習得するのは難しいので、いくつかステップを踏む必要があります。

こちらも工程別に必要なスキルを図で表現してみました。


f:id:tai-hey:20200510144704p:plain
デジタル人材スキルマップ



左から上流のスキルになります。右に行くほど工程が進んでいき、主に4つのメインスキルに分解されていることがわかります。

SIer時代にPM/SEキャリアで習得済のスキルが黒枠になっています。

業務フローに関するスキルとPM推進力、開発要件定義は身につけられています。

赤は現在エンジニアとして奮闘中のスキルとなり、自分で実装したりKARTEの開発をメインで行っています。

開発を後数年は続けながら、ビジネスサイドに出つつ、KARTEのプロダクト自体の利用に携わっていきます。

KARTE関連のスキルが溜まってきたら、今度はお客さんのサイトの状況を見つつwebサイトやシステムのコンサルティング力を身に着けたいと思っています。(もちろんそこでKARTEを武器にしながら)

最終的には複数システムをグランドデザインできるような人材を目指しています。

このような手順で「汎用ソリューション&プロダクト機能のマッチ力で勝負し」、「自社開発でフローを最大化する人材」というポジショニングを極めていきたいと思います。

おそらく10年〜15年ほどかかるかと思いますが、全力で邁進していこうと思います。

以上が、自社開発エンジニアに向いていない私が最終的に目指すキャリアの方向性となります。




最後に

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

今回は自社開発エンジニアに向いていないという自己否定をはさみながら、そんな中でどのようなポジショニングを取っていくか、という考察を深めていきました。

ハブ型デジタル人材を目指す人が増えてほしい。

エンジニアキャリアにはエンジニアアスリートとしてではなく、既存キャリアと掛け合わせることで、デジタル人材は様々な方向や可能性を見いだせる職業だと思います。

世間では、「自社開発でエンジニアになること = 幸せ」、「エンジニア一筋で生きていくことがキラキラで花形」と言われていますが、そこは学生や新卒からプログラミングが好きで始めていて、仕事で訓練されたエンジニアさんが既に沢山います。かなりのレッドオーシャンです。

そこで社会人になってからエンジニアだけで圧倒的に成果を出せるのは一握りでしょう。感覚的には甲子園に出るとか、プロ野球選手になるとかそのレベルかなと思います。

ただ、ビジネスとエンジニアを数年ずつやると、この圧倒的価値がでるあなたしかできない「役割の狭間」を見つけることができるのです。

ここも別途エントリで考察していきたいと思います。

代表的な一つのキャリアに固執せず、自分だけのキャリア像の解像度をこのブログをきっかけに見つけ出していただければと思います。


P.S. 日々の活動の記録、デジタル人材としてどのようにしていくべきか、転職やその他仕事についてつぶやいていますので、ご興味があれば下記またはフォローをよろしくお願いします。




twitter.com www.wantedly.com

第二部:SIer/年収1000万を手放した私 〜 第2回:高難易度プロダクト攻略法 〜

f:id:tai-hey:20200418143135j:plain

0.はじめに

みなさま、こんにちは。


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

twitter.com

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

基本すぐに回答します。


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

www.taihey-blog.com

www.taihey-blog.com

www.taihey-blog.com

www.taihey-blog.com




- 対象読者

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


- 本連載の構成と第二部について

エントリの構成は下記の通りです。

■ 第一部:

■ 第二部: 反省の章

  • 第一回 / 挫折心理から生まれた理想のメンタルスタイル「熱中ドリブン」

www.taihey-blog.com

  • 第二回 / ※本エントリ


本連載は、私がSEを7年勤め、年収1000万のキャリアを積むも、自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。

2019年は転職含め怒涛のように環境が変わっていきました。

恵まれた高給の大企業の環境から、直近の年収アップを捨て、個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦していました。

社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

第一部は、ストーリーメインで、現在の私までを描きました。 (※内容は上記のリンクを参照してください。)

どん底であった状態から無事生存するまでを書いたお話、2018/11〜2019/10 までの 復活の章 を執筆しました。

一通りメインストーリーが終わった後は、第二部として苦しんだ経験を振り返り、挫折と成長戦略について考察を連載執筆していきたいと思います。今回はその第二回です。

第一回は挫折の心理状態を振り返り、理想のメンタルモデルである熱中ドリブンについて考察しました。

今回はプロダクトにフォーカスして下記の構成で考察していきます。

1.プロダクト難易度を考察する
2.高難易度プロダクト攻略法を考察する
3.恵まれた環境 / サバイバルな環境




1.プロダクト難易度を考察する

- 初心者から見たプロダクトは絶壁

前回は観察対象を自分のみにフォーカスして努力値/行動量を増大させるメンタルモデルについて語りました。

私が挫折した要因はこれだけではありませんでした。私の勤めている会社のプロダクトKARTEは、価値の実現可能性はとても高いのですが、同時に難易度も高いものでした。

私は高難易度のプロダクトに対してのアプローチを誤ってしまったため、何度も挫折してしまいました。

前回の心理的要素に加えて外部要素、私達の日々ぶつかるプロダクトのその攻略法について考察していこうと思います。

システムに向き合う人々は、日々プロダクトの難易度との戦いで、それが難しすぎると挫折するし、簡単すぎると飽きます。

プロダクトの難易度をクライミングのような、山に例えようと思います。

下記のように表現してみました。


f:id:tai-hey:20200418102842p:plain
初心者から見たプロダクトスキルレベル



私達、駆け出しエンジニアから見えるプロダクトとはこのように見えています。

壁のようです。

縦軸のレベルは前回同様の3レベルで表現しています。

右に進むほど時間を書けて登ろうとするのですが、初心者は知識がなく、一般的な技術も、プロダクトの仕様も全くわからないため、壁のように見えてしまいます。

プロダクトは先人の英知が詰まっています。

汎化されたコード、複雑なモデル、知らない技術、特別なロジックやビジネスモデルに応えるべき実装したハンドリング...

そのため経緯や仕様などは結果としてのコードに落ちていますが、経験が過小で、スキルの乏しい駆け出しエンジニアには使いこなすにはすぐに理解することができません。


- 完全未経験で手探りで見えた解像度

この壁を手探りで削りながら進んだ図がこちらになります。


f:id:tai-hey:20200418103200p:plain
私が登りながら見えたスキルレベル



今私は感覚的には Lv2 〜 Lv3 の序盤というところでしょうか。

一年半夢中でコードに向き合い、プロダクトに向き合い、人間性を捧げました。朝から晩までコードをがむしゃらに書き続けました。

知識もスキルも乏しいため、初回の登山はこれくらいの解像度にしかなっていませんでした。何度もLv2に届こうとする中で挫折してLv1まで落ちて戻りを繰り返しました。

Lv2まで登ってくると、少しLv3が見えてきます。プロダクトは壁ではなく、大きな階段のように見えます。

すると図:[初心者から見たプロダクトスキルレベル] で見ていたようなモヤのかかったものが晴れて、次のレイヤが見えてくるようになりました。

プロダクトの戦略性や実現したいビジネスモデル/ビジョンです。

スキルレベルが上がることで解像度が上がったのでしょう。


- プロダクト難易度と駆け出しエンジニアの定義認識

私が何度も落ち続けた Lv1 〜 Lv2 ここが心理的にも一番認知が歪みやすく、挫折しやすいポイントとなります。

エンジニアとして働けるボーダーラインについて図にしてみました。


f:id:tai-hey:20200418111033p:plain
エンジニアとして働けるボーダーラインのそれぞれの認識



とりあえずコードを書けばわかる、という発言があるのに、これほど挫折してしまう人が多いのは理由があるようです。

初心者がから見える壁のようなプロダクトと、才能や運や努力や環境依存で生存して登りきれた人が登りきった後から見たプロダクト、この2つの解像度の認識の相違があるからだと思います。

壁のようなプロダクトを自分で分解できることがエンジニアとして活き続けられる暗黙的試験としてあるように感じました。

挫折という曖昧な定義で業界の暗黙的試験に落ちてしまった人は「努力不足」となってしまい、業界からいなくなる、もしくは別の職種になったりしています。

私からみたwebエンジニア業界は「自走できる人材になるために自走で成長を求められる業界」のように見えました。


- 発信でプロダクトの階段を分解する




f:id:tai-hey:20200418104411p:plain
発信でプロダクト階段を分解する



私は業界を変えるつもりは特になく、駆け出しエンジニアにももう少し努力のステップをデザインしてあげてもいいのではないか、という思想を持っています。

少しでも後から来る駆け出しエンジニアが登りやすく、正しい努力をできるようにしたい。また、業界としても企業の戦力になりやすい人が少しでも多くエントリできるように、私の発信によって階段を分解していこうと思っています。


- プロダクト難易度は動的に上昇していく

業界の話からプロダクトの話に戻ります。

webエンジニアになってからこの2年弱でいくつかのプロダクトを開発する機会がありました。

プロダクトは生命体のようで、日々コードは変わっていきます。基本的にコードは追加され、アーキテクチャは複雑になり、難しい技術が採用されていくので、難易度が上昇方向に動きます。

- モデルやシステムのファイル構造やアーキテクチャの複雑性
- プロダクトのコード量に匹敵する規模性
- 汎用的なユースケースへの対応できるかどうかの汎用性

これらの要素に難易度が依存すると思っています。

こちらに関しては説明するには長くなってしまうので別エントリで述べたいと思います。




f:id:tai-hey:20200418112131p:plain
動的に上昇するプロダクト難易度



こちらの図のようにプロダクトの難易度とは固定ではなく、マクロでは難易度が上昇していきます。

事業で実現したいものが難しければ難易度は上昇します。

特に弊プロダクトのKARTEは実現するビジネスの未来が汎用的で大きいため、複雑性も極めて高い事がわかりました。


2.高難易度プロダクト攻略法を考察する

図を初心者から見た視点に戻し、次は高難易度プロダクトの攻略法を考察していきます。

- 突破口はプロダクト成熟度

私はwebエンジニア未経験にも関わらず、初回から成熟度の高いプロダクトにぶつかってしまったのかもしれません。

他の現場を経験した結果、高難易度プロダクトの攻略法はその成熟度にありました。

弊プロダクトKARTEは実現するビジネス価値が大きいためかなり複雑性の高い初期のものに比べれば相対的に成熟しています。更にその成長は加速しています。

私は高難易度プロダクトを突破するために自分で制作を試みたり、業務外の時間を利用し他の現場の開発に携わることを試みました。


f:id:tai-hey:20200418114824p:plain
初心者から見た プロダクト(成熟)



その中であることに気づきます。プロダクトの難易度が圧倒的に違うのです。

他の現場は初期段階ということもあり、プロダクトの複雑性、規模性、汎用性はKARTEに比べると簡単であることに気づきました。

そこが私の挫折からの突破口となります。


- スキルが低いうちは成熟度が低いプロダクトで経験を積め

f:id:tai-hey:20200418115327p:plain
初心者から見たプロダクト(初期)



成熟していないプロダクトであればモデルも使う技術も基礎で問題ないし、ある程度ベタ書きや冗長な記載であっても問題ないケースが多いと思っています。

スキルがあるエンジニアであれば、いきなり完成イメージや抽象化汎用化を含めて実装できると思いますし、それでも問題はありません。

ただ、そのエンジニアもはじめは冗長なコードからスタートし、抽象化汎用化されたコードにリファクタリングを大量に書く経験することで、ノウハウが蓄積され、抽象・汎用的なコードをはじめから書けるようになるのです。

ですので、駆け出しエンジニアの場合は冗長なコードからスタートさせる必要があります。

汎用化や抽象化は、その機能に対して複数のデータケースでの処理が必要な適性にあわせてリファクタリングしていけば良いと思います。


- 低難易度プロダクトで登坂力を習得する

登坂力トレーニングをデザインする

この突破口をきっかけに高難易度プロダクトの攻略法を考察します。低難易度プロダクトを担当できた場合、それに沿ってトレーニングを行います。

下記の図に表現してみました。


f:id:tai-hey:20200418120808p:plain
低難易度プロダクトで登坂力トレーニング→高難易度プロダクト



技術スタックは高難易度プロダクトとできれば同スキル/言語がよいでしょう。

扱う技術が、経験のない新規性があるものに対しては、適切な登坂トレーニングが積めない可能性があります。

難易度の低いプロダクトで、ある程度登坂力(時間をかければできるレベル)を身に着けたら本来戦うべき高難易度のプロダクトに挑戦しましょう。

Lv2であれば時間をかければできるので、挫折することは少なくなります。

挫折はやめてしまうこと = 挫折 になってしまうため、辞めてしまわないようにトレーニングをデザインしてください。

プロダクト自体を変えるのが難しい場合はプロダクトの中の簡単な機能でも構いません。

自分のスキルレベルでも対応できる難易度に当てはめることが重要です。

私はいくつかの現場のプロダクトに触れることで、自分のスキル不足や努力不足が悪いのではなく、プロダクトの難易度とスキルの関係性に気づき、トレーニングをデザインし直しました。

そのステップを積んだことで現在では高難易度プロダクトのKARTEの実装スピードも上がりました。ある程度時間をかければ進められるレベルまで到達しています。


そもそもプロダクトが難易度が高いか、低いかを把握

駆け出しエンジニアの場合は普通のスキルと違って難しく、今登っている山(プロダクト)が難易度が自分の登坂力にあった山であるか、自分の登坂力がどれほどであるかが把握するのが難しいと感じます。

現実の山だと難易度が見えやすいです。誰も登山初挑戦でヒマラヤに登りません。まずは高尾山くらいからスタートするはずです。

システムになってしまうと、複数サンプルを見ることは少なく、一発目に担当するプロダクトが難易度が高かったりすると「エンジニア向いていないんだ」と自分のせいにしてしまい挫折の要因となります。

そこは実際のエンジニアさんに聞いてみたり、いくつかの現場で情報収集するのが良いかと思います。


- 高難易度プロダクト × スキル低で戦う

難易度が高いプロダクトで、どうしてもスキルが低い状態で立ち向かわなければいけないケースはどうでしょうか。


f:id:tai-hey:20200418124534p:plain
自力クライム or サルベージ



考えてみましたが、自力で登坂するか、先輩方にペアプロなどでサルベージして引き上げてもらうしか思いつきません。

サルベージで引き上げてもらえても、プロダクトの複雑性と本人のスキルに乖離があればあるほど、引き上げる側もパワーとコストが必要です。

ある程度助けてもらえると思いますが、環境によってはパワーやコストがかかりすぎます。

よく見るのが、そこまでパワーやコストをかけて助けてられないため、時間をかければできるLv2に到達する前に、"残りは自分で登ってきてね、わからなかったら聞いて" という事象が発生します。

このように「自走できる人材になるための自走での成長」を求められます。

高難易度プロダクトというのはこの絶妙な本人の成長とプロダクトと組織のバランスの中で成り立っているんだ。と感じます。

私がいる環境はスタートアップです。

基本的には自分で「自走できる人材になるための自走での成長」しないといけません。

誰も助けてくれないかもしれない。自分はエンジニアに向いていないかもしれない。など、自分との葛藤と成長の戦いで、圧倒的な胆力が求められます。

高難易度プロダクト × スキル低で戦わなければいけない場合はここを考慮していただくと良いかと思います。


- 成長に銀の弾丸はない

ここまでで私の考察上では、エンジニアの成長には銀の弾丸はないと思っています。

ただ、努力の方向を正しく認識したり、今の自身をとりまく環境の解像度は高く持ってほしいのです。

その解像度で成功率が格段に上がるはずです。このエントリがチャレンジする人の参考になっていただければと思います。


3.恵まれた環境 / サバイバルな環境

最後に環境について軽く触れてこのエントリは終わりにしたいと思います。 直前では高難易度プロダクトに低スキルで立ち向かわなければいけないケースについて触れました。

その場合の挫折確率は環境が大きく依存すると思います。

私は新卒から野村総合研究所という大企業に7年間いました。


f:id:tai-hey:20200418125839p:plain
成長がデザインされている恵まれた環境



環境は恵まれていて、SE / プロジェクトマネージャーとして成長がデザインされている環境にいました。

成長の段取りも、仕事の難易度調整、タスク分解も上司や人事、組織がやってくれました。このキャリアの成長に関してはとても感謝しています。

SE / プロジェクトマネージャーキャリアとしては、Lv3にはなっていましたが、このデザインされた成長のレールを一回外れ、30歳でエンジニアという新しい山に登り始めました。

しかも飛び込んだ先はスタートアップです。

周りはエンジニア10年選手や元CTO、新卒からインターンを数年やって生き残ったツワモノたちばかりです。

スタートアップは教育に一からコストをかけるような環境ではありません。成長もデザインされておらず、成長は本人の責任です。




f:id:tai-hey:20200418131218p:plain
大企業からスタートアップに完全未経験でレーンチェンジをするということ



今回のような自分のスキルには高難易度すぎるプロダクトと認識するのが遅かったため、何度も挫折しました。

ただ、サバイバル環境といえども当時は何度も潰れかけた時に、先輩方に何人も助けていただきました。大変感謝しています。これはメインストーリーを参照してください。


- プライドを捨てることでスタンスの変化で訪れた転機。少しだけ技術的希望も見えてくる
- 様々な方に助けられ、基礎を叩き込み、技術的に見えてきた範囲
- 環境構築をはじめからペアプロしてくれたCPO
- CPOに言われた「プライドを捨てろ」「プログラミングに近道はない」「勉強中」
- 他のベテランエンジニアにも助けてもらう

www.taihey-blog.com


挫折要因にはプロダクトに加えて環境も大きく依存します。

もし自分の環境が自分の成長方向に対してそっていれば恵まれている環境ですし、難易度が高すぎ、サバイバルすぎるのであれば、環境を変えることも考慮してみてもいいかもしれません。

ぜひ3点目の環境についても考慮に入れていただければと思います。

以上が高難易度プロダクト攻略法となります。


まとめ

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

今回は自身のスキルレベルとプロダクトの難易度について考察しました。

このブログを呼んでいる方々には、チャレンジするポジティブな方に、 少しでもそのチャレンジが成功するよう、課題の解像度を上げ、難易度を適切に調整してトライしてほしいと思います。

また、エンジニアに関わらず、少しでもこれから新しいことにチャレンジする方々のお役に立てればと思います。


次回について

第1回では自分自身、第2回では自分自身×プロダクトという位置づけが見えてきました。

これらは単一スキル前提で話しましたが、最後の環境やレーンチェンジに関連して、第3回は自分自身 × 複数スキル を考慮したエンジニアの成長戦略について考察していきたいと思います。


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

twitter.com www.wantedly.com

第二部:SIer/年収1000万を手放した私 〜 第1回:挫折心理から生まれた理想のメンタルモデル「熱中ドリブン」 〜

f:id:tai-hey:20200418141509j:plain

0.はじめに

みなさま、こんにちは。


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

twitter.com

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

基本すぐに回答します。


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

www.taihey-blog.com

www.taihey-blog.com

www.taihey-blog.com

www.taihey-blog.com




- 対象読者

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


- 本連載の構成と第二部について

エントリの構成は下記の通りです。

■ 第一部:

■ 第二部:

  • 第一回 / 反省の章 ※本エントリ


本連載は、私がSEを7年勤め、年収1000万のキャリアを積むも、自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。

2019年は転職含め怒涛のように環境が変わっていきました。

恵まれた高給の大企業の環境から、直近の年収アップを捨て、個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦していました。

社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。

第一部は、ストーリーメインで、現在の私までを描きました。 (※内容は上記のリンクを参照してください。)

どん底であった状態から無事生存するまでを書いたお話、2018/11〜2019/10 までの 復活の章 を執筆しました。

一通りメインストーリーが終わりました。今回からは、第二部として苦しんだ経験を振り返り、挫折と成長戦略について考察を連載執筆していきたいと思います。



- メンタルモデルの重要性

本エントリでは挫折することの真理に近づくことで、新しいチャレンジをする際に必要な挫折しないメンタルモデルを考察していきたいと思います。

メインのストーリーでは、挫折の章復活の章 で私が苦しんでいたように、自分で自分を追い詰めてしまうことがなによりも自分の足をひっぱっていたように感じます。

今回は 挫折してしまうメンタルモデル挫折しないメンタルモデルを図解していこうと思います。

本エントリは下記の3構成に沿って進めていきます。

  • 1.自走できる人材になるためのロードマップ
  • 2.挫折しやすいメンタルモデル
  • 3.理想的なメンタルモデル

1.自走できる人材になるためのロードマップ

- webエンジニアは自走できるまでに、自走で成長しなければいけない



一般的に仕事において自走できる人材は、はじめから自走できる人材になれることはなく、まずはベースのインプットと訓練を積むことが必要です。

新卒でweb系の会社に入れば、研修でその後の業務と連動するようなベースの知識や訓練をある程度積むこともできるでしょう。

私も前職ではSEとして5年目まで継続的な研修や半年に一回成長目標を立てて、自走できるまで上司にサポートをしてもらっていました。

成長させていただいたことに関して今でも大変感謝しています。

私は30代で完全未経験でエンジニアになったため、スキル0からスタートしました。

さらにweb業界では未経験のメンバーに対して、自走できる人材に自走でなれるかを求められていることを強く感じました。(弊社がスタートアップということもあると思いますが。)


- 自走できるまでには3つのレベルが存在する

エンジニアを約2年間経験し、自走できる人材になるまでにわかったことがあります。

自走できる人材になるためには、下記のような3つのレベル感があることがわかりました。

下記の表を御覧ください。横軸が時間軸。縦軸はスキル軸となります。

f:id:tai-hey:20200414092733p:plain
自走できる人材へのロードマップ

段階は下記の3段階あります。

Lv3: 自走できる
Lv2: 時間がかかるが自走できる
Lv1: スキル無し

私はLv1からスタートしました。

時間の投入時間や投入量によって自分のスキルレベルが上昇していきます。

Lv1は一番初歩的で、プログラミングスクール出たあたりとなります。

右も左もわからない状態です。

学習すべきところは先輩から言わせると、「それくらいググれよ」「ドキュメントに書いてあるじゃん、読めよ」というレベルの質問ばかりになります。

例としては javascript の知識、Dockerの知識、マーケティングツールのプロダクト仕様・知識、英語ドキュメントの読み方、海外ライブラリの github issueを読む、環境構築などがあります。

具体的なスキルは下記のイメージです。 挫折の章 から引用

  - 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では基本メールだったよ!)

通常はフロント、サーバサイドに絞った前提で、ある程度(感覚的には1年くらい)業務経験を積んで行くことでLv2に到達します。

Lv2では、実装要件とプロダクトの仕様が固まれば、時間はかかりますが、issueをクローズさせることができるまでに達します。

質問内容も、プロダクト仕様やデータの作り方、モデルの構造など、ややプログラミング自体というよりも設計に近い質問が多くなります。

2年以上経つとLv3となり自走できる人材、担当した issue を自分で設計しPRを出すまでになります。人によってはレビューに入ったりします。

やっと戦力感がでてくるのではないでしょうか。


2.挫折しやすいメンタルモデル

- 鬼門は「自走のための自走での成長が求められる」 Lv1

そうです。ここまで書くとわかる方が多いかと思いますが、挫折の鬼門はまさにこのLv1。

駆け出しエンジニアでは、会社として戦力になっていないこの期間が一番心理的負担が高く、挫折要因と考えます。

Lv3までに達するまで挫折しないためには、Lv1において健全性を担保したまま経験値を適切に積み、Lv2に到達できるかがポイントとなります。

何故鬼門なのかをもう少し考察していきましょう。

下記は、挫折しやすいメンタルモデルを図にしたものです。

先程の図と図軸やレベルについては変化はありませんが、自分の理想とする成長曲線が追加を追加しました。


f:id:tai-hey:20200414094932p:plain
挫折しやすいメンタルモデル



- 実践的認知の歪みを分析する

敵は自身で生み出す認知の歪み

では何故メンタル負荷が高いのか。解像度をあげます。こちらは挫折しやすいロードマップになります。この表をベースに解説していきます。

まず、人間のストレスは「認知の歪み」が9割といわれています。(ググるといろいろ出てくるのでそこは割愛します)

今回もその認知のが私を苦しめる原因でした。この歪みは自分で生み出してしまうのが厄介なところです。私は認知の歪みは2つ発生させていました。

具体的にいうと、私がやってしまった認知の歪みは下記の2つです。


青矢印:理想の成長曲線を作を作り、差分を認知する

赤矢印:最終的な理想のレベルと現状の差分認知する


それぞれについて解説していきます。


青矢印:直線的な成長イメージは悪手

青矢印では、成長を焦りすぎるあまり、私は無意識に直線的な成長をイメージしていました。

例えば2ヶ月後に自分の設定した目標を振り返ると、目標に対して全く届いていないことに気づくのです。更にストレスを感じます。

自分の理想の成長スピードを赤矢印と考えがちな目標を立てがちです。ダイエットとか何ヶ月で何キロ!と一緒ですね。

青矢印についてはメインストーリーで見事に理想の目標を書くことで生み出してしまっています。

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

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

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

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

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




赤矢印:最終的な成長を意識しすぎるのも悪手

赤矢印では、最終的にLv3を目指していたため、今の実力の曲線との差に絶望する日々と、いくらコードを書いてもLv2にさえ近づくことができないことにストレスを感じていました。

これは完全に満足する状態に持っていけないことに認知を歪ませます。完璧主義の方に多かったりするのではないでしょうか。


実際の成長曲線は指数関数的

では実際の成長はどうなのか。現実直線的に成長できるほどそんな甘くないですし、特にプログラミングの場合は自分のレベルの成長曲線は右下の曲線になります。

実はエンジニアの成長曲線というものは、投入時間に対して比例で成果が成長するのではなく、後半に指数関数的に成長することがわかりました。

時間や量を投入してもそれほど成長せず、年単位の努力で実を結ぶとある瞬間に成果を感じやすくなってきます。

ここを認識せず、途中で辞めてしまうため挫折となるのです。

以上が、メンタル面で苦しみにより挫折を産むメカニズムです。


3.理想的なメンタルモデル

- 挫折しやすいメンタルモデルを破壊する

このように私は明らかに挫折しやすいメンタルモデルを認知していることが判明しました。

問題の整理ができました。今度はいかにして挫折しないメンタルモデルを手に入れるかを考察していきます。

まずはこの挫折しやすいメンタルモデルを破壊していきます。

f:id:tai-hey:20200414075204p:plain
挫折しやすいメンタルモデルのポイントを外す

そもそも認識が誤っていたのです。私を苦しめていた2つの認識は外しましょう。私も現在も無意識に認知の歪みを生み出していることに気づくので、「あー認知が歪んでいるな」と客観的に気づくだけで問題ありません。

認知の歪みの原因は青矢印と赤矢印を認知しすぎることが原因のため、ここを考えないようにします。しかし考えないようにしない、というのは再現性がなく抽象的なので具体的な対応策に落とし込みます。


- 未来と過去は盲目でいい。今、ここに熱中する、「熱中ドリブン」

理想のメンタルモデルを図解する

下記の図に理想のメンタルモデルを図解してみました。

先程削除した差分の線が消滅しシンプルになりました。


f:id:tai-hey:20200414075418p:plain
自走できる人材になるためのメンタルモデル



主に脳内で理想を作ってその差分があることでストレスを感じていましたが、理想のメンタルモデルでは実際の成長曲線だけを観察します。

スタート時点で理想のイメージは立てます。自分の現状のレベル感(レイヤやレベル感)と理想像をイメージします。

でも何月何日に達成するかは特に決めませんし、年単位でざっくり状態目標だけ立てます。

以前よりも成長してきて感じますが、理想のイメージは、自身が成長することで少しずつ解像度が上がっていくのを感じます。

はじめは漠然としたものでよいのですが、なぜ私がその理想イメージの状態に惹かれるのかは成長してみるとわかるのかもしれません。


理想のメンタルモデル → 圧倒的行動量/スプリント

最後に、今回の経験と考察で生まれた熱中ドリブンについて少し考察します。

このメンタルモデルでの行動は個人的に「熱中(遊び)ドリブン」と呼んでいます。 俗にいう計画的に行う行動を「計画(仕事)ドリブン」と呼んでいます。

人の不安は未来への想像から生まれます。

熱中ドリブンは、それを排除し、今ここに熱中する、というメンタルモデルです。

未来や過去を考えないことは、Well-being やマインドフルネスの考え方に近いと思います(ここも詳しくはネット上に沢山あるので割愛します。)

実際に熱中ドリブンを実践している私の行動内容や量も変わってきています。下記のツイートのように、直近でも私は熱中フェーズに入ってからプログラミングに投入量/時間が増すことを実現できています。




成果の確実性に対して変える思考スタイル

熱中ドリブンは一般的な考え方として似ているのは、アジャイルです。ただ全てがこのケースに当てはまるとは限らず、再現性がある活動などには成果が期待できるのでウォーターフォール思考で行うのが良いと思っています。

  • 「成果がある程度期待できる行動」に対しては、「直線的に目標を立てるウォーターフォール的思考」が有効です。
  • 「成果の不確実性の高い行動」に対しては、「理想のメンタルはアジャイル的思考」=熱中ドリブンが有効と思います。

    と整理できます。

特にプログラミングは私にとって未知な新規性の高いため、投入量と行動の方向性に対して確実な成果が期待できない。その場合はアジャイル的な思考法が適切と思います。

駆け出しエンジニアや新しいことに挑戦する方はこの熱中ドリブンを試してみてはいかがでしょうか。

まとめ

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

メインストーリーから毛色が変わりまして、今回からは分析/考察が中心となります。 エンジニアに関わらず、少しでもこれから新しいことにチャレンジする方々のお役に立てればと思います。

次回について

今回はメンタルの考察をしました。 第二回はプロダクトと自分のスキルレベルの相関について考察していきたいと思います。

プロダクトは成熟度があり、それに対して適切なエンジニアレベルがあります。

スキルレベルが低いエンジニアが成熟したプロダクトにあたった場合、どのように攻略していくのか、を考察していきたいと思います。


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

twitter.com www.wantedly.com

障害対応という花形

f:id:tai-hey:20200418160820p:plain みなさんこんにちは。

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

twitter.com

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


今回は下記の本ブログのメインストリームである「SIer/年収1000万を手放した私」シリーズをお休みして、スピンオフとして執筆します。

www.taihey-blog.com


0.エントリ執筆のきっかけは twitter

今回のテーマで執筆しようとしたきっかけは、twitter上のこんなやり取りがきっかけでした。

f:id:tai-hey:20200406185404p:plain
twitterでのやりとり1

f:id:tai-hey:20200406185502p:plain
twitterでのやりとり2



私は、SIer の SE から webエンジニア に転職して一年半が経過しました。

このやりとりをきっかけに、自分の経歴を見直してみたところ、最近の業務でSIer時代の経験が役に立つことが多いことに気づきました。

SIerからwebエンジニアを目指している方、普段情報を頂いているお二方に協力できるならばと今回エントリを執筆するに至りました。


今回ご協力頂いたのはこちらのお二方です。

SIer/年収1000万を手放した私」エントリをお読みいただき、実際にお会いして体験談をインタビュー頂いた炭山水さん twitter.com

お会いしたことはないですが、以前よりやりとりをさせていただいていたモロー(毛呂 淳一朗)さん

twitter.com


お二人と話していく中で、参考となるような私の体験談がみつかりましたのでそれらを語りたいと思います。

この質問に沿って今回のエントリは下記の構成で執筆しています。


1: SIer時代の会社環境や業務内容、強みとは
2: 障害対応という花形

今回は障害対応をベースにSIerで培ってきたノウハウやスキルをエンジニアリングと掛け合わせてどのように業務に活かしているのか、なぜ私は障害対応をエンジニアの花形というのかをベースに綴っていきたいと思います。

更にSIerからwebエンジニアに転職した後、どのようなキャリアや業務を歩んでいるかは、世間的にも体験談が貴重だと認識しています。

これからwebエンジニアになろうとしている方の参考にもなればと思います。


- 何故webエンジニアへレーンチェンジしたか

本エントリで初めて私の記事を読む方がいらっしゃると思いますので、転職の経緯などは下記エントリをお読みください。


www.taihey-blog.com


- 苦しんだ後の実り

転職後、この1年10ヶ月webエンジニアとして実装をひたすら続けてきました。

実装自体は苦ではなかったのですが、プログラミングスクール出たくらいでは業務に相当する技術レベルまで身につかず、あまりのできなさに自分を責めてしまいました。

本当に辛かった。

人生で一番つらい時期だったかもしれません。

つぶれかけた事もありましたが、そのおかげで成長もしっかり感じています。

やっとここにきて苦労の実りができてきたのです。(↓エントリ参照)


www.taihey-blog.com


www.taihey-blog.com


苦しい時期を抜け得た実り。

それはコードをかけるようになった上で実現できることが、NRI時代の経験も大いに助けになりシナジーを生んでいます。まずはそのNRI時代の話をしていきたいと思います。

1:SIer時代の会社環境や業務内容、強みとは

- SIer 時代の会社環境を整理する

私が新卒から7年、どのような環境でどのようなスキルを身に着けてきたのか。

SIer/業務システムの前提条件から書きたいと思います。


オーダーメイドということと、SaaSということ

SIerは基本受託スタイルです。

作るのは基本的にお客さんのシステム(お客さんに資産性がある)で、システムの種類としては業務系が多くなります。

あまり詳しくはないのですが、1990年代〜00年代は、システムを新規でオーダーメイドして作ることがメインとなっていました。

そこから10年も20年も社会インフラとして現在もいろいろな社会のコア業務を支えることができています。

ただオーダーメイドは今の時代にはあってきていないと感じていて、最近はSaaSに置き換わってきていますが、本題から外れるのでそこはまた別で語ることにします。

このように業務系システムは少なくとも長く使われることを前提にしています。


ウォーターフォール/ビッグバンリリースということ、求められる高品質、納期は絶対。

もう一つ。

SIerの開発方式のメインはウォーターフォールとビッグバンリリースです。数十人から数百人を動員して数年後に一気にリリースしてきました。

まさに巨大建造物のようです。


業務は基本変わらないので、巨大建造物システムは設計や要件が肝となります。

数年前の設計や要件から基本的にそこから変わることはありません。

1990年代に作られたシステムはリニューアルを繰り返しながらも基本的には保守運用に支えられて稼働しています。


私は、ここがNRIの賢さだと思っています。

お客さんの業務は証券・金融や産業、流通などなど、関係者やフローが複雑な業務であるため、それを自体を理解するにも専門知識がいります。

その複雑な業務のオーダーメイドをオーダーメイドで構築するため、難易度が高いです。

さらに関わるお客さんは数百人を超えるケースもあるので(会社の基幹システムなのだから会社の全員がかかわるのは当たり前)さらに難易度があがります。

難易度は高いですが、ここを一度理解し、システムを構築できた会社だけがシステム構築や改修をメインで担当することができる(= お客さんと長い付き合いができる)のです。

参入障壁がかなり高いですが、社会を支えている企業が多いため、システム構築で実現する価値も莫大です。

社員として中にいても、NRIの中の方はとても優秀なメンバーが多いと感じました。複雑な業務の理解力とシステムのPM推進力、それが業務システムを支えているのだと思っています。


求められる高品質

複雑性の高い基幹系システムに求められるのは高い品質が必須です。

今思い返してみると、web業界から見てもめちゃくちゃ高いです。

業務はもちろん止めらません。密接に絡まった業務をほぼ止めずにシステムリリースし、運用を開始するのです。

プロジェクトの指標として作成される目標は、かなり難しいのですが、新規機能追加レベルであれば障害0を目指すこともよくありました。ほぼ障害0が前提です。


ここにはお客さん側の事情もあります。

QCD(品質・コスト・納期)のバランスを考えなければいけないのです。

一番きついのは納期ですが、法律改正への対応や、予算の関係でほぼXデーが固定になってしまうことです。

先輩方や、自分の経験をもってもかなり苦労した経験があります。

ここまでお話したように高複雑性/高難易度/大規模/高品質/絶対納期であるため、やり遂げるには高いコミットメントや業界への深い業務知識が必要ですし、顧客間の調整や内部外部のマネジメント力も必要になります。


金融の大規模システムをつくるということ

ここまでで業務基幹システムいかに難易度が高いかは理解していただけたかと思います。

さらに私は品質の厳しい金融系のプロジェクトが長かったため、求められるものが他の業界よりも一段高かったと思います。

例えば、新卒は流通、産業系の部署に配属されたのですが、在庫管理のシステムなどが多く、運用でカバー(=システムと業務が密接に関わっていない)のでまだ多少のバッファがあり、融通がききました。

ただ金融の場合は、エラーの一つやバグ一つで(桁ズレとか)物によってはかなり大騒ぎになります。

バーストエラーなどはもってのほかです。

このように業界や業務内容のクリティカルさ(お金なんてまさにそうですよね)と使われるシステムの密結合度によって違ってきますので、求められる品質も変わってくるのです。


- そんな環境の中での若手時代の仕事

保守でも高い品質を求められる

若手はド新規よりも既にあるシステムの保守運用や新規機能追加くらいまで、すでに機構ができた上での開発になります。

たまに大規模リニューアルや、基盤更改、会社間システム統合プロジェクトの「お祭り」にアサインされることもあるのですが、それも新規と保守がフェーズごとに別れていて、並行で動き続けます。

やはり保守は切っても切り離せないのです。
お客さんの複雑で専門性の高い業務システムを作ったのだから、これを改修しようとすると、誰でもできるわけではありません。

業務内容の理解や品質の担保など保守でも高い難易度が求められます。

障害もエラーも基本的に起こしてはいけません。


品質の高いシステムとお金


そのため、この高難易度のシステムを運用していくにあたって、長くお付き合いとなるのでSIerとして利益が多く出始めるのは運用のほうだったりする(運用でペイする)ケースも多くあります。

はじめは赤字をある程度出しても案件を取ったりするのです。
お客さんとしてもお客さん自身のビジネスを支えるシステムのため、長く使うのは当たり前で、そのシステムを動かし続けることによってお客さんも儲かる仕組みになっています。


ただシステムや業務難易度が高いので保守もレベルが高い対応を求められ、アホもできません。

みなさんが苦しむのはまさにここなのですが。。

辛いかもしれませんがその苦労がシステムの利益を支えています。

治すにもたくさんお金がかかります。

数行治すのにも品質を保つために対象機能の今まで起きた障害のすべてを起こさないようにテストを行いますので人手やパワーもかかります。

でもお客さんは障害をほぼ起こさずに品質高く改修をしたいので高いお金を出すのです。

同時にヘタなミスをするとめちゃくちゃ怒られます。私も何度もお客さんや上司に迷惑をかけました。




2:障害対応という花形

- web業界/自社開発でも保守運用は一緒

ここまでである程度私のSIer時代の会社環境や高品質大規模システムに関わってきた経験が見えてきたかと思います。

では保守運用活動にフォーカスしながらweb業界での保守活動について見てみましょう。

炭山水さんのツイートをお借りすると保守系の作業はこんなカテゴリができます。

- 監視
- 障害対応★
- 自動化できてないとこの運用
- 保守開発




現職の自社開発でも、SIer時代と変わらずこれらも泥臭くやります。

毎日監視でアラートを検知してトリアージしますし、障害時には社内エンジニアがわらわらと slack 上に集まって対応します。

機能を担当する人やオーナーにはシステムが大変な場合は電話などでアラートが通知されるようになりますし、深夜に対応することもあります。

自動化できない箇所は日々 esa やサポートサイトにアップデートしますし、機能開発でもβ版をリリースして実績を増やし、パブリックの v1 リリース後には安定稼働までのチューニング、ユースケースによって発生するバグの対応などの保守開発(弊社では「磨く」という)をしばらく行います。


今回は私の直近の役職(インシデントマネージャー)と直結するため、例として障害対応について細かく書きたいと思います。


- 障害対応フローノウハウをweb業界でも転用する

障害が起きたときは検知→影響調査→原因特定→復旧作業→根本対応→是正→並行で報告を行います。

下記の図のように結局はお客さんへの報告を密に行わなければいけません。

図に書くとこんな感じ↓です。

こちらはインシデントマネージャーを始める際に私のノウハウをweb業界向けに整理し直したものです。


f:id:tai-hey:20200409103618p:plain
障害対応タイムライン



この図の説明は長くなってしまいますので割愛します。

SIer時代担当していたシステムは銀行系・金融系が多かったので、これを分単位、時間単位で数日行います。

大きい障害であれば数週間単位で行います。

自分がメインで担当していたシステムであればすべての指示出しと内部/顧客の調整・報告を行います。

システムの理解、業務への影響、役員レベルから担当への調整、パートナーさんへの指示、実行、報告、影響調査などなど。。。

web業界用にアレンジはしましたが、やっている考え方自体はほとんど変わりません。

「正しい情報を正しく集めて統制すること」これだけです。

SIerでの経験がこのまま今でも活きています。


- 実装経験と幅広い知識が必要

ここまで書くと結局webエンジニアになっても実装できないのではないか、と思われるかもしれません。

ただ、この仕事にはコードを書く経験とビジネス/PM経験すべてがあるからこそ、かなりのスピード感でできる仕事だと思っています。(ちなみに自動化の開発も私が行っています。)

だからこそポジションが取れるのです。

私もこの1年半コードを書きまくり、KARTE を理解し、アーキテクチャを理解し、コードを理解し、開発フローを経験し、データ構造を理解することができたためにこのような付加価値が産めるのです。

必要な経験としては下記が挙げられます。

- 障害の内容や仕様、クリティカル度合いを的確に把握するプロダクト仕様、アーキテクチャやシステム理解
- エンジニアが何を考えどうやって進めようとしているかのエンジニアカルチャーの理解
- 障害時にビジネスサイドの情報統制ができるPM力
- 組織や人、情報の動きの判断基準を決め、整理するコンサル力
- お客さんの肌感や期待値を想像し、説明や報告、情報伝達方法を考えることができるビジネスセンス
- 障害の内容をわかりやすくビジネスサイド向けに説明する翻訳力


幅広いですね。特にビジネスサイドとエンジニアのコミュニケーションや情報統制などは片方の経験だけだと難しいと思います。


障害に対して的確な指示、情報統制がとれて数十人にも及ぶ社内・関係者含め、滑らかに収束まで遂行していく感覚は、達成感と自分が成長したことを感じさせてくれます。
司令塔のようにエンジニア、ビジネス問わず幅広い知識が必要だし、自分がプレイヤーとしても実績がないといけません。
そうです、ビジネスを支える障害対応は花形です。

- 私が見出したのはビジネスとエンジニアのハブ、というポジション



情報を正しく伝えるには、最終的に顧客に事象や対策を伝えるのはビジネスサイドですから、エンジニア用語だけで説明しても正しく伝わりません。

そのため、ビジネスサイドとお客さんが理解できる内容に翻訳、整理が必要となります。

例えば、もしビジネス側経験だけであれば、システムで起きている正しい情報を集められない(理解まで時間がかかる)し、エンジニア経験だけであれば、ビジネスの期待値や顧客への伝え方を誤ってしまうこともあると思います。

翻訳できるハブになるにはビジネス・エンジニア両方の経験が必要なのです。

私はビジネスと実装経験を両方積むことで独自のポジション「ビジネスとエンジニアのハブ」を取れていると感じています。


最後に

今回のエントリは、質問をきっかけにして、障害対応にフォーカスし、SIer時代のスキルをどうweb業界でも適用させることができるか、について書いてきました。

次回は自社開発とSIerの経験から見えてきた、それぞれのビジネス構造の違いと、自分をどのようにフィットさせることで昇華させていくのかを綴っていきたいと思います。


P.S. 日々の活動の記録、転職やその他仕事についてご興味があれば下記またはフォローをよろしくお願いします。



※2020/05/02追記 弊社CPO柴山さんからコメントもらいましたので共有します。】FBより引用

「Startupでも、攻め(change)を支えているのは障害(error)とその期待値と契約を
どうバランスしつつ解くのかってとこでそれが何よりも大事なんだと思うんだけど、
その花形感は伝わりづらい。
でも、もうここで勝負は決まってるんじゃないかっていうくらい大事。
そして解く問題が異常にむずいのでここをやれる人は全然いない。」

経営者目線からだと、障害対応は大事なのはわかっているど、考える範囲や経験が幅広く必要になる、本当に不足している人材像なんだと思います。

開発でも何でも、スピードが生命線であるスタートアップの、足枷を潰していく守護神のような仕事なのだとこのコメントから改めて思います。


twitter.com www.wantedly.com

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