30代エンジニアが送る、活躍し続けるために20代のうちにすべきこと
この記事は Ateam Group Manager ＆ Specialist Advent Calendar 2020
8日目の記事です。このアドベントカレンダーでは、エイチームグループの各子会社及び各部門のマネジメント職、シニアエンジニア、シニアデザイナー以上が記事を投稿しています。
株式会社エイチームライフスタイルでWebエンジニアマネージャーをしています、@aiji42 と申します。
2014年に新卒エンジニアとして入社し、7年目となりました。
今年は働き方という意味で大きな節目の年となりましたが、私個人としても大きな節目を迎えております。
それは、「今年私がいよいよ30代に突入した」ということです。
そんな30代を迎えた私が、最前線でエンジニアとして活躍し続けるために、20代のうちにすべきことや知るべきことを、これまでの経験をもとにまとめたいと思います。
ターゲット
・現在20代(特に後半)のエンジニアで、それなりに頑張っている自負があり、30代になってもエンジニアとして活躍し続けたいと思う人
・エンジニアとして自身の価値を伸ばし続けたい人
結論
活躍し続ける = 学び続ける・変化を起こし続ける
この記事の結論、かつ、ありきたりな言葉になってしまいますが、エンジニアがこの先々活躍し続けるために必要なことは、技術を学び続け、変化を起こし続けることだと私は考えています。
なぜなのか
開発体験を変化させ続けなければならない
私が社会人になった2010年代前半は、 PHP や Ruby のようなサーバサイド言語に関するエントリーが多く、フロントエンドの言語はどちらかと言うと軽視されていたように感じます。(あくまで私の考えです)
しかし2010年代後半に入り、JavaScript は ES2015(ES6) の採択により別言語のように進化を遂げ、TypeScriptの登場によってエンジニアの開発体験は一気に変化しました。React は2013年の初版から、7年でバージョンが17まで上がっています。(とくに Hooks の登場は大きな変化を及ぼしました。)
今や「バックエンドも JavaScript (Node) で書いてしまおう」はたまた「XaaSを組み合わせれば、バックエンドは構築しなくてよいので、フロントエンドの開発にフォーカスしよう」といった選択が簡単に取れるようになっています。採用市場を見ても TypeScript スキルの価値は向上し続けています。
これらの変化は何によって引き起こされたのでしょうか？
ユーザニーズの変化 = 開発体験の変化
答えはユーザニーズの変化です。
2010年代にかけてWebのデバイスシェアはスマートフォンがPCを上回りました。手のひらサイズの小さい画面に、多くの情報を載せるためにインタラクティブなUI/UXが多く採用され、情報のリアルタイム性が求められた結果、PWAのようなコンテンツニーズが高まりました。
おそらく、向こう5年も同じようにユーザニーズは変化し続けます。その結果我々の開発体験もアップデートを余儀なくされます。
※補足① 開発体験以外の変化
開発体験以外にも変化するものがあります。ライフスタイルと業務上の責任範囲や役割の変化です。
・ライフスタイルの変化
結婚・育児による、生活の中での時間配分やモチベーションの変化
・責任範囲・役割
プレーヤーからチームリーダー・マネージャーへの抜擢
個人差は多少あると思いますが、間違いなく技術を学び続けるためのモチベーションに影響を与えます。
自由な時間が比較的多い20代のうちに経験を積み、信頼貯金と自己学習の習慣化を行いましょう。
※補足② 学び続けないとどうなる？
個人差はあれ、新人エンジニアは毎日の業務が勉強であるため放っておいても成長します。最初にコツを掴み、周りよりも一歩前に出ると、あたかも自分に才能があるかのように錯覚し、業務以外での学習が疎かになります。
(恥ずかしながら私がそうでした)
そんな状態が続くとどうなるかは容易に想像ができます。徐々に成長速度は失速し、いつのまにか、周りからは(いろいろな意味を含ませて)「丸くなったね」と言われるようになります。
いつの間にか周りとの差は埋まり、「自分は一体何をしていたんだ」と気づく頃にはもう遅いかもしれません。
自分自身に自信を持つことは、成長速度を高めるために大切なことですが、それが過信になった途端、成長は失速し始めます。
世の中の技術の成長速度を上回ろうとし、行動を伴わせなければ、悲しいことに必要とされなくなる可能性もあります。
活躍するエンジニアとは
活躍しているエンジニアは常に変化を起こす側である
問題はユーザニーズに合わせた開発体験の変化を起こす側に回るのか、起こされる側に回るのかです。どちらに回るべきなのかは自明でしょう。
常にユーザニーズを捉え事業課題としてフォーカスし、最適な技術・組織・アーキテクチャの採用を通じて、変化を与えコントロールするエンジニアこそ、活躍しているエンジニアであると言えます。マネージャーであろうともスペシャリストであろうとも、最適な変化を起こし続けるという点において同じなのです。
本題
どうやって学び続ける・変化し続けるか
前置きが長くなりましたが、ここから本題です。
勉強を業務に取り入れ学習を加速する
学生のメインは勉強ですが、社会人のメインは業務、勉強はサブとよく言われます。もちろんその通りではあるのですが、いかにサブ(勉強)をメイン(業務)に取り入れるかを考えることが重要です。
あなたが新卒1年目・2年目の時そうであったように、業務自体が学びであれば毎日成長できます。
しかし、いきなり未開拓の技術をメイン業務に取り入れるのは無謀です。ある程度の技術評価がされている必要がありますし、それなりの開発スピードも要求されます。
そうなると、最初の一歩はプライベートでの技術開拓です。これから業務でどんな課題が発生しそうかを考え、それを解決できそうな技術を先回りして開拓します。
OSSな技術であれば内部のコードがどうなっているかを読み流し思想を掴みます。プロトタイプを作ってみて業務課題を解決できそうかを判断しましょう。
チュートリアルから始めて、少し凝ったことができるくらいまではには最低限触れましょう。チュートリアル程度のレベルでは業務ではフィットできません。レールに従うことも重要ですが、カスタマイズがどの程度できそうか把握しておきましょう。
さて、業務に新しい技術を取り入れるための準備が整いました。しかしそれでもなお、メインのコードに組み込むには、ハードルが高いでしょう。
どうするか？
失敗の許容されるサイドカープロジェクトを生み出しましょう。メインのサービス・アプリケーションと関係性がありつつ、失敗したとしてもリスクが少ないプロジェクトです。業務を支援するような小さいアプリケーションや、データの見える化などが最適です。
(※予めプロジェクトを構成するシステムが分割されていれば、こういったトライを受け入れやすくなります。)
このサイドカープロジェクトこそが業務と勉強が混じりあう実験場であり、Will/Can/Must で言えば、Will と Must を重ねた場所です。私が今まで見てきた活躍しているエンジニアは、抜擢も含めて自らこの実験場を作り出すことに長けていました。
彼らはこの実験的な業務を拡大させながら、高速に学習サイクルを回していくのです。
1. 業務で起きそうな課題を予測し、解決できそうな技術を先回りして開拓
2. 業務内で失敗の許されるスコープを設定し、その中で実験する
3. 実験でトライ・アンド・エラーを重ね、スコープを大きくしていく
4. 業務での経験をさらにプライベートに活かして学習サイクルを回す
※補足③ 何を学べばよいか？
「何を勉強したらいいですか？」と質問されることがあります。
しかし、自分で何を勉強すべきか判断できないのは、自らインプット不足を露呈しており、普段の情報収集を怠っていることの現れにほかならないと思います。もしかすると、普段の仕事で業務課題や事業課題に触れようとしていないのかもしれません。
その状態では、たとえ上司から「○○を学ぶといいよ」と言われても、学習は継続しません。
たとえ、プライベートでコードを書くことをしていなかったとしても、最低限、世の中でどういった技術のトレンドが高まっているのか調べることは必要です。また、普段の仕事の中で、職能を超えてコミュニケーションをとり、自身の携わるサービスやプロジェクトが直面している課題に興味を持ちましょう。
自ずと何を学べばよいか自分で判断ができるようになります。
組織の性質を理解し変化させる
チームメンバーは組織という枠を超えられない
だからこそ組織設計は慎重に判断しなければならない
私が27歳のときに非エンジニアの上司に言われた言葉です。後にエンジニアに限って言えば、コンウェイの法則がまさにそれなのだと気付かされました。
業務課題は組織によって生み出され、組織によって解決されます。
優秀なエンジニアは(コンウェイの法則を知っていなくとも)、このことを常に念頭に置き、柔軟に組織とアーキテクチャの采配を行い、変化を与え続けているのです。
「組織を作る」というと、どうしてもマネージャーの仕事のように思えますが、アーキテクチャ先行で組織を作ることも可能です(逆コンウェイの法則)。つまり、スペシャリストもそのことを理解し、業務課題に対して適切にアーキテクチャと組織を考えていく必要があります。
まとめ
以上が、この先活躍し続けるエンジニアにとって大切なことであり、若いうちにすべきこと・知るべきことでした。
と、偉そうに言っていますが、私も30歳になったばかりで、まだまだ教えることよりも教わることのほうが多いと、この記事を書きながら思いました。
後輩エンジニアの皆さんへ
これからともに切磋琢磨して成長し続けましょう。私も皆さんに背中を見せ続けられるよう頑張ります。