これは先日、株式会社アイスタイルにて参加した社内むけで話した内容を清書したものです。
（現在は株式会社アイスタイルの社員ではありませんが技術顧問的な立場でサポートさせていただいてます）
対象として、初学者やエンジニアなりたての人向けではありませんが、
2、3年目の方とかが読むといいのかもしれません。
自分流のこれまでのやってきたものだったりマインド的な話だったりそういうもので、
これをやれば誰もがエンジニアとして成長できる！というわけではありません。
参考にできるところは参考にするか、ヒントにするとか息抜きに読むくらいがちょうど良いです。
加えて将来CTOだったり、技術顧問という立場になりたい、という方にもいいかもしれませんが、
自分のスタンスだったりが多く含まれていますので、
世間一般で求められてるCTOだったり技術顧問との乖離があったりするところもあると思います。
参考にできるところは参考にするか、ヒントにするとか息抜きに読（略
そもそもあなた何している人？
日中はスターフェスティバル株式会社に所属していて、
開発とマネージメント的なことをしていますが、
勤務時間外ではこれまでの経験を生かして技術顧問的なことをしたり、
マイクロサービスアーキテクチャ化の支援、
DX化推進やそれに伴うドメインモデリングの支援、
社内外問わずエンジニアのメンタリング、
組織をリードするために社外CTO的なこと、
クラウド移行だったりオンプレも含めてアーキテクト的なこと、
中長期的な事業戦略とそれに伴うプロダクト開発のロードマップ作成と技術組織のサポート的なものだったり、
そういった支援をたまーにしています。
あとはOSSやプライベートなサービスの開発をしていて、
適材適所で複数言語を使って開発するスタイルの人です。
将来的にそういう働き方をしたいとかという人は何かしらのヒントになるかもしれないし、
ならないかもしれません。
最近ですとわりと多い働き方だったりそういうエンジニアのスタイルの人です？
エンジニアの将来的なキャリア
大体は3つくらいに分割されるかと思います。
- 技術にフォーカスし、専門的な知識を持って課題解決をするタイプ
- プロダクト開発だったり事業などで技術関連分野をうまく進められるように開発組織デザインだったり、その周辺の問題解決にフォーカスするタイプ、
- 技術とビジネスを結びつけるための戦略だったり事業だったりを考えて実行するタイプ
2つに分けられなくもないんですが、3つにしてみました
これには深い意味はありません。
上から一般的に認識されているカテゴライズをするとスペシャリストタイプ、
VPoEタイプ、CTOタイプみたいな具合かなと思いますが、
組織によっては役割が違う場合があります。
スペシャリストタイプがCTOだったりすることもあります。
これは組織によって求められる役割が異なっていたりしますので、こうあるべきというのはありませんが、
どのタイプもある程度技術に精通し、ある程度ビジネス的な要素や、長期的な事業展開などを理解して
それを落とし込む力が必要（というか必須）になります。
技術を理解していない方がイニシアチブを握っていると、
開発組織の最適化などが難しい場合が多々あります。
ただしこの技術というのも、10年前の技術なら知っている、だったり
新しいものは古いものの焼き増しでしょ？新しいのは覚えなくてもいい、
という思考になるのも危険です。
逆に新しいものしか知らない、古いものは不要なのでいらない、というのも危険です。
AWSなどのクラウドネイティブな環境の場合は、通常さほど苦労はしないと思いますが、
やはり万が一の想定外の出来事が起きた時に判断と意思決定、指示ができるか、というのが求められます。
想定外のトラブルが起きた時に技術的な解決方法が全くわからない、それはクラウドの分野でないのでわからない、
もしくは事業をサポートする機能が要求された時にクラウドで提供されていないものなのでできない、
といった判断をすることは致命的な事態につながるケースが多々あります。
とはいえ必ずしも全ての分野において精通している必要はありませんし、それは不可能だと思います。
例えばkaggleなどのコンペに頻繁に参加して、その傍らモダンなフロントエンド技術を追いながら改善・開発をし
データエンジニア的にビッグデータに対応できる様にHDFSやGCPなどの連携部分の設計やミドルウェアの構築、
クラスタ管理と実装をしてマーケティング支援をサポート、
マイクロサービスアーキテクチャ化のためにドメインモデルの作成を行いながら
スクラムマスターをしてWebアプリケーションのアーキテクチャ設計と分散処理実装と・・・
かなり広い範囲となってしまいますが、
一人でこれらをやりながら経営との技術組織をうまく運用するのは不可能です。
（何年もかけて良いのであれば別ですが・・）
ただ細部まで把握していなくても、ある程度の昔と今、これからの技術を知り、
長期的な事業展開に合わせてどの様なものを選択すべきか、みたいな判断ができる様に常にアンテナを貼り、
どういうものか知っておく必要はあります。
もしくは自分がわからない領域に関しては、その分野に精通したメンバーを採用または育成するなどの動きも自身で考え
それができるように事前に動いておくなどの行動力がプラスになります。
責務の範囲だったりがテックリード、VPoE、CTOで異なったりはしますが、
みているところは大体同じでフォーカスするところが異なる、というのはわかると思います。
勘所みたいなところですね。
一人しかいない場合は一人である程度この役割を担うことになり、
役割分割できる場合はそれぞれがそれぞれの領域にフォーカスしますが、
どちらにしても事業展開も技術においても、組織についてもどれかしかしらない、どれかしかやらない、
というわけにはいかないわけにはいきません。
その会社における最適な技術戦略は中長期のビジネス展開から考える方が良いですし、
それを実現するための開発組織はどうしていくか、
スキルが足りない！だったりそれを実現するためにロードマップを経営層と判断していく、
みたいなのは濃淡はありますがついてきます。
将来を見据えてこの辺りを鍛えていく様なマインドだったり、行動をしていくといいかもしれません。
ということで本題に。
どういうことを意識していくといいのか、
自分流でやってきたことは
スキル習得に関しては日々の鍛錬を怠らないことは当たり前として
（自分の場合は開発における技術習得はプライベートな開発が7割くらい占めてます）、
必ずしもゴールとするキャリアのためにスキルをつけるということはなく、
あくまで日々の鍛錬などで（そうでなくても良いですが）習得したスキルを業務などにフィードバックして
改善を重ねた結果そういった役割が返ってくるもの、
という（自分は意識していないんですが）マインドでした。
もちろんそれらを開発にフィードバックするにはチームメンバーの’教育だったり
文化を作っていくなどもセットで必要になりますので、
リーダーシップは必須になります。
大体パワーを使う物事を進めるのは大変で、嫌がる人もおおいと思いますが
ここを自主的に巻き込んで進められる、というのは必須です。
そうでなければ、ただ意見を言うけど何もしない人、ということになってしまいます。
というのも開発や組織やビジネスもそうですが、
一度決めたらここからやり方や方針を変えない、というのはないわけです。
仮に一度決めたらもう変えない、という選択をした場合は長期的な目線でみると
あるところまではルールになどに従って進んでいけば良いですが、
時代とともに開発や組織やビジネスのやり方も最適解も変わっていくためこれに対応しなければなりません。
なので変えていく力、というのは必要なわけです。
この調子で行くと本を書けるくらいの量になっていくので、このへんで・・
学びは大事
まずは関心を持っている技術やその周辺のものをより理解するためには学習が必須です。
プライベートで勉強するの？と業務時間だけでいいとか最近だとそういう話もありますが、
自身のキャリアだったりそういう面でやるかやらないかを選択すると良いと思います。
（文脈によってコードを書いたりするのか、ミドルウェアを試すのかみたいな言葉が混ざってますが適当に読み替えてください）
自分流に昔やってきたことは、
今だとSNSなどで知見をもつ様々なエンジニアの方々の会話が見えたりそこに参加する、ということが容易ですが、
そこの会話を理解したり参加したり記事を読むには、
その人たちが話している内容を理解できる様に知識をつける必要があります。
書籍を読んだり、国内外のエンジニアの方々の記事などを読んでとにかく知識をつけます。
ここにはもちろん開発手法や開発スタイルの話、実装や設計のパターンやそれらを包括したソフトウェアアーキテクチャだったり、
それらをサポートするインフラだったり多岐にわたりますが、
そのキーワードの背景あるものを理解するためにはたくさんの知識が必要になります。
なのでたくさん読んだり知識をつけることを意識します。
ただこの本を読んだり知識をつける、ということですが
モノにもよりますがほとんどの場合において
読むだけということは、
ミュージシャンの教則本を読むだけでは
ギターが弾けないのと同じ
知識だけがある状態は意味がない
ということです。
なので読んだ内容をもとに実際に手を動かして作ってみたり
進めることで疑問に思うことが出てきたらさらに調べます。
そういったことを日常的に試行錯誤するわけです。
これを業務時間でやると、いつまで経っても成果物が上がってこない、仕事が終わらない、
という状態になってしまいます。
ある程度は割り切って仕事のコードとそれ以外のコードみたいな切り替えは必要です。
（そもそも成果物があってお金を稼いでるので、それができないのは本末転倒です）
これで本で読んだ実践に近い知識がついてきます。
それを元に少しずつ開発組織だったり業務に反映していくといいでしょう。
ただ成功する手法だけでなく、いろんなものを想定して異常（エラー）が起きた時にどうリカバリーするか、
そもそも自分で対応できるのか、などの側面も必要です。
これも合わせて日々鍛錬していくことで自分の自信にもつながりますし、
なによりもエラーや異常系の処理だったりと戦える様になって初めて習得したと言えます。
新しい言語なんかを導入する場合はまさにそうですね。
導入だけしてエラー発生！でも直し方も対応方法もわからない、だと厳しいわけです。
とここまでくるとSNSで登場する著名な方々の会話がある程度理解できたり参加することができるようになります。
あるところはわからなくても、不十分でも問題ないです。
足りないところはきっと教えてくれます。
歩みの中の成長ポイント
初学者のうちはとにかく今あるものをある程度使いこなせる様になるのが必要です。
が、経験は関係なく成長につながるものは
とにかくたくさん失敗すること、です。
学びのところにもありますが
とにかく業務外で何回もコードを書いたりミドルウェアの検証したりし、
とにかくダウンさせてそこからの復旧方法だったり、バグへの対処方法を身につけます。
そして実際の業務にフィードバックすると、さらに想定外の物事が起きます。
それはサービス停止につながるかもしれないし、軽微なエラーかもしれないし
なにかしらクリティカルな事象につながるかもしれません（個人情報とか機密情報とかそういうのはダメですよ！）
が、ビビらずにとにかく失敗するものだと思っておきましょう。
リカバリーできてさらに習得できるわけです。
なので、ある人にとっては「あいつは失敗ばかりで全然ダメ」だったり、
過去に一緒に仕事していた人たちは数年前の姿しか知らないので「あいつはイマイチだよ」
という様に思われてるかもしれません。
まぁ実際に自分はそうでしょう。
でもそれは失敗を重ねた結果、成長につながるわけです。
一緒に働く人に感謝しつつ、胸を張って失敗していきましょう。
同じ失敗は繰り返さないようにしていくだけです。
それに最初から完璧を目指すことは不可能です。
すこしでも状況が変わったら変更し辛い作りと評価されたり、不必要に複雑だと思われたり
いろいろあるでしょう。
知識量の違いだったりそれぞれがもってる考え方や手法は様々なので、
よっぽどなケース以外（例えばハードウェア開発をして一度しかコードを変更できない、とか）は100%を目指したり
変に気負う必要はありません。
失敗できない環境だったら・・？それはあまりハッピーなところではないかもしれません。
もし自身がCTOやテックリードやVPoEになった場合は、
失敗を享受する文化だったり組織を作るといいでしょう。
それまでに自身で様々な経験をしているはずです。
みんなが失敗しようともリカバリーすることはできます。
とにかく失敗は大事ということです。
技術的なアンテナ
SNSなどで新しい技術だったりの情報収集はできますが、
やってみた、という例から正確な情報を得ることはできません。
やはり失敗例やうまくいかないケースの方が価値があります。
この辺りは勉強会やカンファレンスなどで発表した方に質問するといいです。
発表時は大体うまくいった話をしますが、同時に失敗した経験も数多くあるはずです。
このあたりを聞き出したり耳を傾けることで、
新しい手法は取り入れるべきか否か、もしくは一部利用できるかなどを判断できるようになります。
もちろんSNSで直接絡んだりすることもできます。
そういった人たちと接点をもったりすることで自分の知識だけでは不十分だったことや、
さらに理解しなければいけないものなどが見つかります。
もちろん手法だけではなく、自身の所属する会社の中長期のビジネス展開を頭の片隅に入れつつ、
ああ、ここならこの技術いれれそうだなとか、そういう思考を意識しましょう。
この技術を使いたいからここをこう変える！ではありません。
技術ファースト的な発想ではなく、あくまで課題解決に対する自身の引き出しとして使います。
そういう意識を養うことでこれから必要そうな技術だったり方法論が見えてきます。
*もちろんビジネス展開ではなく、自身のブランディング戦略みたいな形でもいいでしょう。
技術や手法の見た目だけに囚われて判断してしまったら、
まだ未熟だ、ということです。
目に見える範囲だけではなく、失敗例と、なぜそれを選ぶのか、
みたいなところを意識しておきましょう。
コンフォートゾーンから抜け出すこと
いわゆる心地いいゾーンですが、
ある程度開発できるようになってきたりスキルがつくと、
自分の得意な言語や手法でなんでも解決したくなってきます。
自分もそうでした。
なんでもPHPでやるとか、ちょっと難しいかもしれない手法で解決できるけど、
それはわからんので自分の知ってる範囲だけでやる、という具合です。
世の中には似たケースでいくつかの技術的な選択肢があったりします。
例えばRDBMSでLIKEとかできるけど、スケーラビリティ意識したらSolrとかElasticsearchな訳ですが、
RDBMSの知識そのままでは利用できないため、クラスタの設計だったりサイジングだったり、
インデックスの作り方なども新たに覚えなければなりません。
つまり今はできないけど少しの努力と少し背伸びをすればできるようなものであれば、
心地いいゾーンから少しはみ出て範囲を広げる、ということを意識するようにします。
もちろん全方向にというわけにはいきません。
それこそ冒頭の
kaggleなどのコンペに頻繁に参加して...
みたいになります。
徐々に広げた結果そうなるのは問題ないですが、
成長途中にありとあらゆる分野に伸ばすのは大変労力もかかりますし、
習得が困難になります。
ある程度理解してやるけど、ここは最新追うとか第一線目指す、みたいなのはやらない！
という領域を決めることが大事です。
（自分の場合はフロントエンド技術がそうなんですが）
このゾーンを抜けるためにも学びが必要ということですね。
逆にこのゾーンを抜けない、ずっとそこでいい、という選択をすることもあります。
もちろんこれはその人の特性だったり性格もあるのでそれも問題ありません。
ただCTOやテックリードやVPoE、またはマネージャを目指すみたいな場合はどうでしょう？
今はできないけどすこし背伸びすればできそうだな、というものをつかわないと解決できない要件が現れた時、
例えば数億ユーザーが使うサービスに成長した場合にレコメンデーションなどデータを活用したものが出てくるわけですが、
（DXなどにもよくありますね）
分散ファイルストレージの知識やSparkだとかBeamみたいな知識が必要になるわけです。
少しの労力と学習で使うことができますが、
運用となると多少難しいのでそれなりの時間が必要になります。
ですが、頑張ればできそうです。
（想像しにくいかもしれませんが）
というケースおいて、無理っすできないっす、だったり、
組織の中でこういう手法があるから試してみたら？的なアドバイスをすることができなかったり
推進するようなことが全くできなかった場合にどうなるでしょう。
その分ビジネスの変化ができなくなるわけですからサービスの成長だったり、
それに伴うなにかしらの大きな変更だったりのチャンスがなくなるわけです。
会社の成長を止めてしまうようなやり方を推進しすぎると衰退を早めてしまうものです。
（やりすぎはだめですけど）
いいバランスを取れるようにするためには
適切にコンフォートゾーンを抜け出すのは大事だと思います。
抜け出すヒントとして、自社にそういう環境がなかったら・・・
他社エンジニアと交流を持ってそういう知識をわけてもらったりするような努力は必要です。
もちろん自社でできない場合はアウトソーシングという選択肢がありますが、
ある程度のことを理解していないと提案されてもまったく理解できず、
ビジネス側に反映しようと思っても全然マッチしなかったり、
想像と違ったものが出来上がっていた、などにつながります。
これは危険！
とにかく現時点の自分の知識だけで満足せずに、井の中の蛙にならないように
定期的に自身に刺激を与えて範囲を広げる努力をしましょう。
きっとプラスにしかなりません。
経験や学びをアウトプット
これは必須ではありませんが、習得のためのPDCAだったり、
自分の糧とするには有用だったりするものですが、
カンファレンスやブログなりでアウトプットを継続的にして、
いろんな人の指摘を受けたり、
もしくは受けないように自分の知識とアウトプットが間違っていないtか確認しながら磨いていく、
を重ねることでさらにさらにプラスになります。
ここで得た経験をチームや組織にフィードバックしたり、
自らそれを材料に組織をリードしていく人になっていったりという成長につながります。
自分に自信をもつ、という点でもプラスになるでしょう。
ただアウトプットしたから偉いとかそういうことはありません。
自身の考え方だったりを整理することに価値があると思っています。
アウトプットしたついでに参加者のみなさんと飲み会ができるとか最高ですね
（今はできませんが）
少しだけ意識しておくといいかもしれないこと
繰り返しになりますが、時間外で勉強しろという話ではありませんが、
自身が何もしてない時に他のエンジニアの誰かは常に成長している、ということは事実です。
どういうキャリアを歩んでいくかを照らし合わせながら、
そんな日々成長している人たちに追いつくか追いつかないか、
もしくは著名な人たちと会話できるようなエンジニアになるのか、
などを意識してみるといいかもしれません。
もし具体的な姿などが想像できなければロールモデルを探すのが良いでしょう。
社内外関係なくそうしたエンジニアの方を探してみたり想像してみたりしましょう。
もちろん表向きの姿だけではなく、どういう経験をしてそうなったのか、なども参考にできるはずです。
そうした結果エンジニアとしての歩んだ先が見えてくるはずです。
キャリアのためにやるぞ！と意気込んでもこうしたことは見えてこないかもしれません。
ここに書いてあることはあくまで自分の体験などを掻い摘んで書いてあるだけです。
背景のはもっと様々なことがありますが、参考にできそうなところは取り入れてみるといいかもしれません。
もしみなさんの上司だったりにあたる人たちが、
組織や技術やビジネスなどに対する姿勢、リーダーシップが大きく欠けている人たちだったら・・？
それはチャンスかもしれません（？）
頑張っていきましょう
長文おわり
