「きっと何者にもなれない自分というエンジニアとしての生存戦略」

という記事が僕の周りでbuzzってた。読んだ限り、そのままでいいんだよ、と、恐縮ながら声をかけてあげたいと思ったわけですが、３点ばかし思うところがあったので雑で恐縮ですが書いてみます。

１．自分は何をしたいのか？願望を持つ重要性

「きっと何者にもなれないエンジニアの生存戦略」として以下の項目を挙げられていた。

1.有名OSSにContributeする。
2.起業する。
3.CxOとしてJoinする。
4.副業として顧問になる。
5.サービスを立ち上げる。

これのいくつか大部分は、「自分がこうしたい」という強い気持ちが必要なので、それがないなら無理に焦らないほうが良い。

OSSでContributeしてる人に話を聞くと、必要に迫られてやったという話をよく聞きます。つまり、issueがあるかないかで変わってくるでしょう。残念ながら僕はソフトウエアに対しては受け身なので、そういうのやったことないのでこれ以上の話は知りませんが、issueを抱けるぐらい深く理解し、使い込むってのが大切な気がしますね。是非、コミッタの人とかに何をきっかけにこうなったのか聞いてみてください。

それよりも最近思ってることなんですが、経験的にも、Webサービスをゼロから１人で作れない人が増えている気がします。ステートレスなシンプルなアーキテクチャですが、それが故に、UXにおいては気を使わないといけない部分が沢山あるわけで、Webサービスを丁寧に作るのは案外骨が折れる作業です。

１人から数人でWebサービスを作りきって、なおかつ、ユーザーさんに支持され、それを維持しつづけるという経験は大切だと思います。プロであれば、仕事という場で堂々と、その機会に携われるのでしょうから、是非やりきりましょう。

そもそもWebのエンジニアは、他人が作った素敵な技術を使わせてもらって、その技術を最大限活かしサービスを作るのが仕事なのですから、目の前にある技術をリスペクトし、その技術の良さを理解し、自分が携わるプロダクトに活かす。この目利き力と実装力は重要。

せっかく素敵な技術を使わせてもらってもアウトプットが残念だと勿体無いですからね。そのコーディネート力がWeb系エンジニアの腕の見せ所です。

2．人から期待され信頼される重要性

さきほどの「CxOとしてJoin」と、「副業として顧問」ですが、この２つは、自分１人ではできません。

依頼者が必要です。自分で起業するのではなく、CxOになるには、CEOが必要です。

つまりCEOから認められないとなることができません。周りに認められるぐらい、期待され、その期待をちゃんと実現し、この人ならやってくれるだろう、という信頼される人間にならないと、その機会はやってこないということです。

誰が将来、声をかけてくれるCEOや技術顧問の発注者になるかわからない以上、エンジニアとして全方位で信頼されるべく、毎日、生きるというのも、エンジニアの重要な生存戦略です。

3．マネジメントに対する誤解

みんなマネジメントに対して誤解があるなぁと思うことがあります。

よくある大企業的マネジメントってあるじゃないですか。35歳定年説みたいなの。

言っときますけど、スタートアップやベンチャーにおいては、そんなマネジメント必要ないですから。

ベンチャーにおいては、まだ最先端のトップが40代が中心、自分たちのキャリアモデルすら完結してないわけですから、人の管理しかしないマネジメントは必要ないです。少なくともそれがエンジニアマネジメントの定義ではない。

エンジニアのリーダーは、エンジニアチームから尊敬され、これから入ってくる人材を魅了するために技術が語れることが求められます。

つまりエンジニアに認められるスキルを持つことが重要。それを実現するために必要なことが、技術から離れることだと思いますか？

ギーク方面のCTO的エンジニアは、エンジニアリングのカリスマとして君臨しますが、チームマネジメント方面のエンジニアは、広義のプロダクトマネジメントとして、人を活かしながらプロダクト、サービスにコミットするのが仕事です。

どっちにせよ技術者に認めれられ続けるよう、技術が語れる力は維持しないとやっていけない仕事です。

例えば、障害が起きた時には、その解決について、持てる技術力とプロダクト知識とメンバーの技術力を生かしてメンバーを率いていく。そういうのも役割の一部だと思います。

そこで技術的にも人的にも解決法が不適切で小さくまとまっていたら、問題解決力がない人と判断されてしまいます。技術力に劣ることで判断力が欠ける場合、チームメンバーはすぐに見抜きます。それではリーダーは続きません。

そもそもネットにおける「技術力」の定義が、「誰かが作った技術を使えることや貢献すること」に偏ってるのが間違いなんですよね。

ネットというメディアにおいては、注目されている技術に歩み寄るのが一番汎用性が高いですから、どうしても、そこばかりがクローズアップされがちです。

もちろん、その部分も重要ですが、「誰かが作った技術」には自分たちが書いたコードやプロダクトも含まれることを忘れてはいけません。自分たちのソースコードは、ネットでは公開されていないことがほとんどですから、その部分のコントリビュートは社内でしか見ることができません。

そこで起きる様々なこと。例えば、雑用みたいなデータ修正のための何万件のSQLデータを速やかに作成して流すことも大切な仕事ですし、トラブル解決や何かの開発において、工数をはかって、人力のほうが合理的なら、人力で解決することを適切に判断し、ちゃんと実現できることも技術力と言えます。

なんでもコードで解決することがエンジニアリング力ではありません。
こういう系の話においては、結構スルーされてると思うので、書いてみました。

さいごに

いろいろ書いてしまいましたが、以下のフレーズが気になりました。

あくまでエンジニアとしてエンジニアリングを全うするようなエンジニアでありたい。

エンジニアリングと言ってるものが、誰かが作った技術を良い感じに自分が携わる仕事に活かしていく作業だとして、いずれ自分ひとりでは、時間的、能力的、作業的に、できないことを誰かと一緒に解決していく必要性に気が付いたら、次のステージに行けると思いますので、今やれることをやりきるように是非、がんばってください。

そこで仲間からポジティブに協力を得るために必要なスキルとして、エンジニアとして生きるための願望と、それを補助するマネジメントスキルとか言うやつが武器になってくれるでしょう。

【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください