0.はじめに
みなさま、こんにちは。
私は プレイド のエンジニアの大平(おおひら) (@Victoria_Peak_)
と申します。
7年勤めた野村総合研究所を辞め、2018/07〜現在まで 株式会社プレイド で勤務しています。
日々の活動内容(プログラミング・SaaS/SIer・デジタル人材のキャリア・ロードバイク・減量など)をつぶやいたりしておりますので、本エントリを読んで興味を持たれた方は、twitterでフォロー、リプライ、メッセージなどをいただければと思います。
基本すぐに回答します。
本エントリは、2018年12月に執筆した、 前編 と、
中編 、
後編 の 挫折の章 、
後編 の 復活の章の続編になります。
- 対象読者
- エンジニアに限らず前向きに人生のチャレンジをしようとしている方
- 人生のレーンチェンジを考えている方
- SIerからwebエンジニアになりたいが、実際はどのようになるのかを知りたい方
- 未経験でwebエンジニアに転職したが、業務に挫折しかけている方
- 30代以降でなにかにチャレンジしたい方
- 本連載の構成と第二部について
エントリの構成は下記の通りです。
■ 第一部：
■ 第二部： 反省の章
- 第一回 / 挫折心理から生まれた理想のメンタルスタイル「熱中ドリブン」
- 第二回 / ※本エントリ
本連載は、私がSEを7年勤め、年収1000万のキャリアを積むも、自身の本当にやりたいことに気づき、転職してwebエンジニアになり、1年と少しが経つまでの体験談を綴っていきます。
2019年は転職含め怒涛のように環境が変わっていきました。
恵まれた高給の大企業の環境から、直近の年収アップを捨て、個人の技術力が勝負のwebエンジニアとしてスタートアップに飛び込み、他のことが手に付かないほど業務に四苦八苦していました。
社会人になってから転職後はおそらく私の社会人人生で一番長く、苦労した体験になったと思っています。
第一部は、ストーリーメインで、現在の私までを描きました。
(※内容は上記のリンクを参照してください。)
どん底であった状態から無事生存するまでを書いたお話、2018/11〜2019/10 までの 復活の章 を執筆しました。
一通りメインストーリーが終わった後は、第二部として苦しんだ経験を振り返り、挫折と成長戦略について考察を連載執筆していきたいと思います。今回はその第二回です。
第一回は挫折の心理状態を振り返り、理想のメンタルモデルである熱中ドリブンについて考察しました。
今回はプロダクトにフォーカスして下記の構成で考察していきます。
1.プロダクト難易度を考察する 2.高難易度プロダクト攻略法を考察する 3.恵まれた環境 / サバイバルな環境
1.プロダクト難易度を考察する
- 初心者から見たプロダクトは絶壁
前回は観察対象を自分のみにフォーカスして努力値/行動量を増大させるメンタルモデルについて語りました。
私が挫折した要因はこれだけではありませんでした。私の勤めている会社のプロダクトKARTEは、価値の実現可能性はとても高いのですが、同時に難易度も高いものでした。
私は高難易度のプロダクトに対してのアプローチを誤ってしまったため、何度も挫折してしまいました。
前回の心理的要素に加えて外部要素、私達の日々ぶつかるプロダクトのその攻略法について考察していこうと思います。
システムに向き合う人々は、日々プロダクトの難易度との戦いで、それが難しすぎると挫折するし、簡単すぎると飽きます。
プロダクトの難易度をクライミングのような、山に例えようと思います。
下記のように表現してみました。
私達、駆け出しエンジニアから見えるプロダクトとはこのように見えています。
壁のようです。
縦軸のレベルは前回同様の3レベルで表現しています。
右に進むほど時間を書けて登ろうとするのですが、初心者は知識がなく、一般的な技術も、プロダクトの仕様も全くわからないため、壁のように見えてしまいます。
プロダクトは先人の英知が詰まっています。
汎化されたコード、複雑なモデル、知らない技術、特別なロジックやビジネスモデルに応えるべき実装したハンドリング...
そのため経緯や仕様などは結果としてのコードに落ちていますが、経験が過小で、スキルの乏しい駆け出しエンジニアには使いこなすにはすぐに理解することができません。
- 完全未経験で手探りで見えた解像度
この壁を手探りで削りながら進んだ図がこちらになります。
今私は感覚的には Lv2 〜 Lv3 の序盤というところでしょうか。
一年半夢中でコードに向き合い、プロダクトに向き合い、人間性を捧げました。朝から晩までコードをがむしゃらに書き続けました。
知識もスキルも乏しいため、初回の登山はこれくらいの解像度にしかなっていませんでした。何度もLv2に届こうとする中で挫折してLv1まで落ちて戻りを繰り返しました。
Lv2まで登ってくると、少しLv3が見えてきます。プロダクトは壁ではなく、大きな階段のように見えます。
すると図:[初心者から見たプロダクトスキルレベル] で見ていたようなモヤのかかったものが晴れて、次のレイヤが見えてくるようになりました。
プロダクトの戦略性や実現したいビジネスモデル/ビジョンです。
スキルレベルが上がることで解像度が上がったのでしょう。
- プロダクト難易度と駆け出しエンジニアの定義認識
私が何度も落ち続けた Lv1 〜 Lv2 ここが心理的にも一番認知が歪みやすく、挫折しやすいポイントとなります。
エンジニアとして働けるボーダーラインについて図にしてみました。
とりあえずコードを書けばわかる、という発言があるのに、これほど挫折してしまう人が多いのは理由があるようです。
初心者がから見える壁のようなプロダクトと、才能や運や努力や環境依存で生存して登りきれた人が登りきった後から見たプロダクト、この２つの解像度の認識の相違があるからだと思います。
壁のようなプロダクトを自分で分解できることがエンジニアとして活き続けられる暗黙的試験としてあるように感じました。
挫折という曖昧な定義で業界の暗黙的試験に落ちてしまった人は「努力不足」となってしまい、業界からいなくなる、もしくは別の職種になったりしています。
私からみたwebエンジニア業界は「自走できる人材になるために自走で成長を求められる業界」のように見えました。
- 発信でプロダクトの階段を分解する
私は業界を変えるつもりは特になく、駆け出しエンジニアにももう少し努力のステップをデザインしてあげてもいいのではないか、という思想を持っています。
少しでも後から来る駆け出しエンジニアが登りやすく、正しい努力をできるようにしたい。また、業界としても企業の戦力になりやすい人が少しでも多くエントリできるように、私の発信によって階段を分解していこうと思っています。
- プロダクト難易度は動的に上昇していく
業界の話からプロダクトの話に戻ります。
webエンジニアになってからこの2年弱でいくつかのプロダクトを開発する機会がありました。
プロダクトは生命体のようで、日々コードは変わっていきます。基本的にコードは追加され、アーキテクチャは複雑になり、難しい技術が採用されていくので、難易度が上昇方向に動きます。
- モデルやシステムのファイル構造やアーキテクチャの複雑性 - プロダクトのコード量に匹敵する規模性 - 汎用的なユースケースへの対応できるかどうかの汎用性
これらの要素に難易度が依存すると思っています。
こちらに関しては説明するには長くなってしまうので別エントリで述べたいと思います。
こちらの図のようにプロダクトの難易度とは固定ではなく、マクロでは難易度が上昇していきます。
事業で実現したいものが難しければ難易度は上昇します。
特に弊プロダクトのKARTEは実現するビジネスの未来が汎用的で大きいため、複雑性も極めて高い事がわかりました。
2.高難易度プロダクト攻略法を考察する
図を初心者から見た視点に戻し、次は高難易度プロダクトの攻略法を考察していきます。
- 突破口はプロダクト成熟度
私はwebエンジニア未経験にも関わらず、初回から成熟度の高いプロダクトにぶつかってしまったのかもしれません。
他の現場を経験した結果、高難易度プロダクトの攻略法はその成熟度にありました。
弊プロダクトKARTEは実現するビジネス価値が大きいためかなり複雑性の高い初期のものに比べれば相対的に成熟しています。更にその成長は加速しています。
私は高難易度プロダクトを突破するために自分で制作を試みたり、業務外の時間を利用し他の現場の開発に携わることを試みました。
その中であることに気づきます。プロダクトの難易度が圧倒的に違うのです。
他の現場は初期段階ということもあり、プロダクトの複雑性、規模性、汎用性はKARTEに比べると簡単であることに気づきました。
そこが私の挫折からの突破口となります。
- スキルが低いうちは成熟度が低いプロダクトで経験を積め
成熟していないプロダクトであればモデルも使う技術も基礎で問題ないし、ある程度ベタ書きや冗長な記載であっても問題ないケースが多いと思っています。
スキルがあるエンジニアであれば、いきなり完成イメージや抽象化汎用化を含めて実装できると思いますし、それでも問題はありません。
ただ、そのエンジニアもはじめは冗長なコードからスタートし、抽象化汎用化されたコードにリファクタリングを大量に書く経験することで、ノウハウが蓄積され、抽象・汎用的なコードをはじめから書けるようになるのです。
ですので、駆け出しエンジニアの場合は冗長なコードからスタートさせる必要があります。
汎用化や抽象化は、その機能に対して複数のデータケースでの処理が必要な適性にあわせてリファクタリングしていけば良いと思います。
- 低難易度プロダクトで登坂力を習得する
登坂力トレーニングをデザインする
この突破口をきっかけに高難易度プロダクトの攻略法を考察します。低難易度プロダクトを担当できた場合、それに沿ってトレーニングを行います。
下記の図に表現してみました。
技術スタックは高難易度プロダクトとできれば同スキル/言語がよいでしょう。
扱う技術が、経験のない新規性があるものに対しては、適切な登坂トレーニングが積めない可能性があります。
難易度の低いプロダクトで、ある程度登坂力(時間をかければできるレベル)を身に着けたら本来戦うべき高難易度のプロダクトに挑戦しましょう。
Lv2であれば時間をかければできるので、挫折することは少なくなります。
挫折はやめてしまうこと = 挫折 になってしまうため、辞めてしまわないようにトレーニングをデザインしてください。
プロダクト自体を変えるのが難しい場合はプロダクトの中の簡単な機能でも構いません。
自分のスキルレベルでも対応できる難易度に当てはめることが重要です。
私はいくつかの現場のプロダクトに触れることで、自分のスキル不足や努力不足が悪いのではなく、プロダクトの難易度とスキルの関係性に気づき、トレーニングをデザインし直しました。
そのステップを積んだことで現在では高難易度プロダクトのKARTEの実装スピードも上がりました。ある程度時間をかければ進められるレベルまで到達しています。
そもそもプロダクトが難易度が高いか、低いかを把握
駆け出しエンジニアの場合は普通のスキルと違って難しく、今登っている山(プロダクト)が難易度が自分の登坂力にあった山であるか、自分の登坂力がどれほどであるかが把握するのが難しいと感じます。
現実の山だと難易度が見えやすいです。誰も登山初挑戦でヒマラヤに登りません。まずは高尾山くらいからスタートするはずです。
システムになってしまうと、複数サンプルを見ることは少なく、一発目に担当するプロダクトが難易度が高かったりすると「エンジニア向いていないんだ」と自分のせいにしてしまい挫折の要因となります。
そこは実際のエンジニアさんに聞いてみたり、いくつかの現場で情報収集するのが良いかと思います。
- 高難易度プロダクト × スキル低で戦う
難易度が高いプロダクトで、どうしてもスキルが低い状態で立ち向かわなければいけないケースはどうでしょうか。
考えてみましたが、自力で登坂するか、先輩方にペアプロなどでサルベージして引き上げてもらうしか思いつきません。
サルベージで引き上げてもらえても、プロダクトの複雑性と本人のスキルに乖離があればあるほど、引き上げる側もパワーとコストが必要です。
ある程度助けてもらえると思いますが、環境によってはパワーやコストがかかりすぎます。
よく見るのが、そこまでパワーやコストをかけて助けてられないため、時間をかければできるLv2に到達する前に、"残りは自分で登ってきてね、わからなかったら聞いて" という事象が発生します。
このように「自走できる人材になるための自走での成長」を求められます。
高難易度プロダクトというのはこの絶妙な本人の成長とプロダクトと組織のバランスの中で成り立っているんだ。と感じます。
私がいる環境はスタートアップです。
基本的には自分で「自走できる人材になるための自走での成長」しないといけません。
誰も助けてくれないかもしれない。自分はエンジニアに向いていないかもしれない。など、自分との葛藤と成長の戦いで、圧倒的な胆力が求められます。
高難易度プロダクト × スキル低で戦わなければいけない場合はここを考慮していただくと良いかと思います。
- 成長に銀の弾丸はない
ここまでで私の考察上では、エンジニアの成長には銀の弾丸はないと思っています。
ただ、努力の方向を正しく認識したり、今の自身をとりまく環境の解像度は高く持ってほしいのです。
その解像度で成功率が格段に上がるはずです。このエントリがチャレンジする人の参考になっていただければと思います。
3.恵まれた環境 / サバイバルな環境
最後に環境について軽く触れてこのエントリは終わりにしたいと思います。 直前では高難易度プロダクトに低スキルで立ち向かわなければいけないケースについて触れました。
その場合の挫折確率は環境が大きく依存すると思います。
私は新卒から野村総合研究所という大企業に7年間いました。
環境は恵まれていて、SE / プロジェクトマネージャーとして成長がデザインされている環境にいました。
成長の段取りも、仕事の難易度調整、タスク分解も上司や人事、組織がやってくれました。このキャリアの成長に関してはとても感謝しています。
SE / プロジェクトマネージャーキャリアとしては、Lv3にはなっていましたが、このデザインされた成長のレールを一回外れ、30歳でエンジニアという新しい山に登り始めました。
しかも飛び込んだ先はスタートアップです。
周りはエンジニア10年選手や元CTO、新卒からインターンを数年やって生き残ったツワモノたちばかりです。
スタートアップは教育に一からコストをかけるような環境ではありません。成長もデザインされておらず、成長は本人の責任です。
今回のような自分のスキルには高難易度すぎるプロダクトと認識するのが遅かったため、何度も挫折しました。
ただ、サバイバル環境といえども当時は何度も潰れかけた時に、先輩方に何人も助けていただきました。大変感謝しています。これはメインストーリーを参照してください。
- プライドを捨てることでスタンスの変化で訪れた転機。少しだけ技術的希望も見えてくる - 様々な方に助けられ、基礎を叩き込み、技術的に見えてきた範囲 - 環境構築をはじめからペアプロしてくれたCPO - CPOに言われた「プライドを捨てろ」「プログラミングに近道はない」「勉強中」 - 他のベテランエンジニアにも助けてもらう
www.taihey-blog.com
挫折要因にはプロダクトに加えて環境も大きく依存します。
もし自分の環境が自分の成長方向に対してそっていれば恵まれている環境ですし、難易度が高すぎ、サバイバルすぎるのであれば、環境を変えることも考慮してみてもいいかもしれません。
ぜひ3点目の環境についても考慮に入れていただければと思います。
以上が高難易度プロダクト攻略法となります。
まとめ
お読みいただきありがとうございました。
今回は自身のスキルレベルとプロダクトの難易度について考察しました。
このブログを呼んでいる方々には、チャレンジするポジティブな方に、 少しでもそのチャレンジが成功するよう、課題の解像度を上げ、難易度を適切に調整してトライしてほしいと思います。
また、エンジニアに関わらず、少しでもこれから新しいことにチャレンジする方々のお役に立てればと思います。
次回について
第1回では自分自身、第2回では自分自身×プロダクトという位置づけが見えてきました。
これらは単一スキル前提で話しましたが、最後の環境やレーンチェンジに関連して、第3回は自分自身 × 複数スキル を考慮したエンジニアの成長戦略について考察していきたいと思います。
P.S.
日々の活動の記録や、転職やその他仕事についてご興味がれば下記までよろしくお願いします。
