2024年の目標とやらないこと
写真は、9月1週間ほ…
2013年4月に社会人になって、4年と4ヶ月。最近では、6ヶ月前、2017年の2月には初めての転職を経験した。技術者には、2014年の8月になった。感覚的には4〜5年は技術者をやった気持ちでいたが、完全に気のせいだった。3年は節目の年だと思うので、記念にポエムを書いておくことにする。
「フルスタック?それは何もできないことと一緒だ」と、自分が技術者になる前、昔の上司(企画職)に散々なことを言われたものだ。これは今でもよく覚えていて、たまに思い出す。この上司の主張はもはや極論で、色々とすっ飛ばしている指摘なので、なんだかなあ…と思う一方で、フルスタックと主張するのは体の良い「何でも屋」であるように判断されたに違いない。フルスタックというのはイコール何でも屋であるように見えてしまうとすれば、少なくともフルスタックエンジニアは価値を下げないよう、何かしら見繕う必要はあると思う。
ちなみに、フルスタックエンジニアの定義は諸説あると思うが、自分なりのゆるい定義としては、サーバサイド、フロントエンド(Webまたはネイティブアプリケーション)、インフラ、リレーショナルデータベース、の分野の全ての経験を有し、各領域において実際に実装ができるレベルの能力があり、各分野の技術的な特性を理解し、アプリケーションやインフラを適切な設計に導くことができる人材である。ちなみに、自分は今現在フルスタックエンジニアではない。前述のようなエンジニアを目指している。
サラリーマンの人材市場で捉えると、フルスタックのエンジニアです、なんて、複数のスキルがあるからこそ、長所の捉えどころに困り、取り扱いがしにくそうなのは確かだ。しかし、それがサラリーマンの人材市場からはみ出た、起業家としてみた場合に、このような評価は異なってくると思う。事業を起こす場合と考えると、そのシチュエーションで必要な人材には、専門性も必要な一方、複数分野にまたがる能力を保有していることは評価につながるのではないか。
スタートアップは無論、専門性の高い人材の集まりだと思うが、実際には枠にとらわれない仕事の仕方をしていると思う。事業を急速に立ち上げる段階には一人あたりに要求スキルが実際にはかなり複数あるため、「私にはこの分野しかできない」はそもそもNGという認識だ。実際に、先日スタートアップで技術リーダーを務める友人と話をしていたら、このあたりの話題が上がった。友人のコメントでは、ごく普通に複数分野をかけ持つことができない人材は、スタートアップでは使い物にはならない、という話であった。
フルスタックエンジニアは、スタートアップ界隈を起点とし、数年前にバズワードとなった。これは、スタートアップの早いステージで要求される技術者の人物像をなんとなく形容した結果、きっとそうなっただけだと思う(スタートアップのボードメンバーに入るために必要な、よくある人物像的な感じで)。だとしたら、フルスタックエンジニアは事業を起こすのが早いエンジニアとして価値が高いはずだ。ちなみに、ここでいうスタートアップの規模は、10名以下のごく少数の人員で構成される程度の規模である。
ポエムなので、自分の話をする。JavaScriptなら、ある程度クライアントとサーバサイドは書けるようになった。ただ、サーバサイド、リレーショナルデータベースの分野は個人事業での経験が主になるため、クライアント経験よりかはまだまだ浅い。インフラは、そこそこの規模感(物理・仮想ホスト合計200台、月間10億PV程度)のオンプレミス環境を1.5年ほど経験し、そのような規模感の環境での運用のノウハウを習得したつもりだ。
自分のスキルの中では、現状ではJavaScriptが強いと言えば強いのかもしれないが、JavaScriptの界隈は技術の流行り廃りが早く、さらに特定分野についての専門家が存在する。自分は、そこまで最新事情についてキャッチアップできている自信はない。細分化されたJavaScriptの分野を追い始めると多くの時間がかかるとみており、今後もこれはそこそこにしておき、適宜適切な技術の習得に時間をかけていきたい。
JavaScriptの技術セットオンリーだと、多言語を扱える人間からディスられることが分かったので、これはなんとかしたい。しかしながら、しばらくNode.jsでの開発が続く見込みなので、これを続け、専門性を追求したい。インフラでいうと、awk, Go, Docker, GCPが気になっていて、これらは全てやるべきだと思っている。インフラにGoを入れた理由は、最近テストツールをNode.jsで書いていて不便さを感じたためだ。高速に処理でき、また言語の特性としてそもそもツールを書きやすいなれば、現状はGoと認識しているので、あえてここに入れた。副産物として、ツール開発の知見を活かしつつ、Webのサーバサイド処理を多少はGoで書けるというよう持っていけばOKな気がしている
クライアントについては、WebフロントエンドはReactをメインに、Vueは試せる機会があれば使う。ネイティヴアプリケーションは、近々Objective C、Android Javaのスキル要求があり、これらのどちらか、または両方をやることになる(React Native開発がつらかったので、両方のOSの特性を知るために、今はどちらもやりたい気持ちではある)。
やることはたしかに多いのだが、技術領域に固執せず、どんどんと学習し、習得していくこと。それが将来的にフルスタックエンジニアの強み、特徴の一つになり得ることだと思っている。
フルスタックエンジニアについての痛烈な指摘だと、過去の自分の上司のような「色々できるといって、結局何ができるのかわからないヤツ」みたいな批難を受けやすいと思う。おそらく一般的にも「コイツは一体一番何が得意なの??」と、フルスタックエンジニアは経歴書を見るとそのようにながちな存在だとは思う。色々できるから…だけでは、手厳しい見方をされるのは当然であり、色々できるからでしかできないことを売り込むほうがきっと良いはずだ。
フルスタックエンジニアともなれば、各分野の技術知識があるため、横断的に技術選定時のリスクを測れるなど、幅広い知識と経験をもとに技術的リスクを減らす「ブレない判断能力」で自分を売っていくのが個人的に良さそうな気がしている。ある一つの特定分野のプロフェッショナルは、もちろん特定分野の判断には強いが、一方で、もしかしたら多面的に見ることが苦手かもしれない。
フルスタックエンジニアに専門性がないとは主張はしない。しかし、字面に起こすと専門性が見えにくいのは事実だと思う。なので、フルスタックエンジニアは、各技術分野を横断的に理解しているからこそ導ける「強み」を導き出し、人材市場で戦うのが良いのではないかと思った。
自分は、アプリケーションが「将来の技術負債の塊」にならないよう、技術選定や設計の段階で最大の能力を発揮できるようなエンジニアになりたいと思っている。技術選定ではしゃいでしまう技術者がやってしまうのが、お気に入りの選定技術で開発をし、製品をリリースすることそのものがゴールになってしまうことだと思う(こういった場合は運用段階で悲惨なことになるケースが多いと思う)。そうではなくて、製品リリースは一つの通過点であり、製品を実際の運用に落としてみて、評価される技術者になりたい。障害発生件数が少なく、スケールしやすい作りになっている。システムを分解しやすく、後々システムを疎結合ないしリプレースしやすい。開発段階ではなく、運用の段階で「この製品の仕組み(設計)はよくできている」と評価されるような設計に導ける人材になりたい。
3年後くらいにまたポエムを書いて、このような人物になれてたら良いなあ。
(広告)
新品価格 |
プログラムを書きながらTranceを聴くのが良いですね。みなさんも聴いたほうがいいですよ、Trance。EDMよりハードトランスでしょ。
Discussion about this post