Melting Pot of Thoughts

SaaSスタートアップのCTOです。思考の整理のため考えたことをメモ書きレベルでアウトプットしていくブログです。

”フルスタックエンジニア”という単語はもっとポジティブな意味で捉えられていいんじゃないか

個人的な感覚ですが、昔から"フルスタックエンジニア"という単語はネガティブに捉えられることが多い気がしています。

実際、試しに”フルスタック”とGoogle検索してみたところ、サジェストには「いらない」「器用貧乏」「笑」など、嫌われている雰囲気がありました。(ポジティブなキーワードはありませんでした)

 

f:id:doyaaaaaken:20211225183632p:plain

フルスタックエンジニアが生きづらい世の中である

個人的にはフルスタックエンジニアになろう」という心意気はもっとポジティブに捉えられていいのではないかと思っています。

 

"フルスタックエンジニア"の定義は?

IT用語辞典e-wordsのサイトによると次のような定義でした。

https://e-words.jp/w/%E3%83%95%E3%83%AB%E3%82%B9%E3%82%BF%E3%83%83%E3%82%AF%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2.html

フルスタックエンジニアとは、通常はそれぞれに専門の技術者がいて分業されるような複数の技術分野についての知識や技能に精通し、一人でシステム開発や運用を行なうことができる技術者のこと。対象分野によって求められる技能の組み合わせ(スキルセット)は異なる。

フルスタック”の定義はここに記載されているとおり、「複数の技術分野を習得していればOKであり、あらゆる全て技術分野に精通している必要はない」という前提で話を進めていきます。

 

なぜ”フルスタックエンジニア”はこれほど嫌われているのか?

Web検索で出てきた記事を見ていると嫌われている理由は、「"フルスタックエンジニア"は全てが中途半端であり価値が出せないため」という理由が多いようです。

 

特に”フルスタックエンジニア”を名乗る人を嫌う理由としては、「その人が”フルスタック”と名乗り何でもできます感を出しているが技術レベルが低い」という理由が多いようです。

確かに私もプログラミングスクールを出て日がエンジニアの人が、RubyOnRailsでWebフロント・Webサーバ・DBを触っただけでも”フルスタックエンジニア”と名乗っているのを見かけたりします。

エンジニアに限らないですが、結局のところ仕事は特定の分野に詳しくなりそこで価値を出せるようにならない限り、いくら幅を広げたところで価値は出せないままです。

自身の得意領域を深められていないのにも関わらず、”フルスタック”と名乗り「何でもできます」感を出すのが嫌われている一つの理由ではないかと思っています。

 

あとは”フルスタックエンジニア”という求人を嫌う理由としては、「便利屋としてこき使われるイメージがあるため」という意見が多いようです。
他の専門家たちがやらない雑多な仕事をたくさん振られ続け、自身の技術力をじっくりと深めてキャリアアップする機会が得られないのではないかという懸念から避けられているようです。

 

個人的にもこういった嫌われる理由については理解できるなと感じます。

 

あとは語感もよくない…

また”フルスタック”という言葉は”フル”と付いているので、「全てをこなせる」という意味に聞こえてしまいます。
なので”フルスタックエンジニア”と聞くと、”万能エンジニア”と言っているような気がし、実際はそんな人はほとんどいないので、嫌われている理由の一因になっているのではないかと感じています。

 

実際は前述のIT用語辞典e-wordsに書かれている定義のとおり「複数分野に精通している」という意味なので、フルスタックエンジニアは万能である必要はないです。

似た意味の語で”マルチエンジニア”という単語があるそうなのですが、そちらのほうが語感的には実態に近いな思いました。
”マルチエンジニア”という単語のほうが流行っていれば、ここまで嫌われることはなかったのではないかと思います。

 

特定領域がある程度できるようになったら、別の領域にも幅を広げるべき

ここまで”フルスタック”が嫌われる理由について書いてきましたが、個人的には”フルスタック”に幅を広げていくこと自体はものすごく大事なことだと思っています。

もちろん『特定の領域をある程度深められてから』という前提はありますが、エンジニアは自身の専門領域以外の領域にも幅を広げていかなければむしろ生き残れないと感じています。

 

基本的には技術は金槌やノコギリと同じく”ツール”なので、特定技術しか知らない人はその”ツール”を使った解決法しか思いつけません。
特に自分の専門領域と隣接した領域を知らずには、より良い解決法を思いつけません
例えばWebフロントエンジニアであれば、その領域しか知らなければ実直に仕様に沿って実装するしかないですが、Webサーバサイドを少し知っているだけでAPI仕様を変える提案をできたり、デザインのことを少し知っているだけでUIを変える提案をできたりします。

 

また技術の変化は激しいので、長い目でみると必ずどこかのタイミングで廃れていきます。
ノコギリの使い方を極めても、電動チェーンソーが出た瞬間にその技術は使い物にならなくなります。
インフラにおいてもオンプレミスからクラウドへと技術転換が起きました。

特定の専門領域だけしか知らないと、別分野や新しい分野を自分で評価することができず、また移行も難しくなります
そのため幅を広げなくても目先の仕事はこなせますが、キャリア上非常に大きなリスクとなります。

 

そういった背景で、自分の専門領域から幅を広げるのはすごく大事なことです。

 

"専門領域+α" vs ”フルスタック"

ここまでの話では専門領域から幅を広げる『専門領域+α』の大事さについての話をしました。
では多くの領域に精通する『フルスタック』になる必要はあるのか?と感じるかもしれません。
結論から言うとこれら両者はエンジニア・エンジニアリングマネージャの関係性同様、相互に行き来できるキャリアパスのような関係性なのではないかと考えています。

 

組織は大きくなればなるほど『専門領域+α』の人材が増えていきます。
組織というものはスケールするために、専門的な役割を持たせたチームに分割していく必要があるためです。
(そして分割したチーム同士が円滑に連動するためには、専門領域だけでなく隣接領域(+α部分)も理解している必要があります)

 

しかし特に事業会社はそうなのですが、組織は方向性を変えたり組織編成を組み替えたりするタイミングが必ず来ます。
現実のビジネスは流動的で、技術の流れは非常に速いので、組織もそれに合わせて変わっていかなければいけないからです。
そういった場合、専門領域に特化した人材であったとしても(転職しない限りは)自身の専門領域を少しズラす必要性が出てきます。

 

また昨今世の中の変化が早く、ビジネスがスピード・機動力重視にどんどんなってきています。
どれだけ大きな会社であっても、新規事業や企業内のDX化プロジェクトなどの重要性が高まってきており、数も増えてきています。
そういったスモールなプロジェクトでは、エンジニアはフルスタックであることが求められます。

 

つまりフルスタックエンジニアは、プロジェクトや会社のフェーズによって生まれる役割であり、通常のエンジニアと行き来可能なキャリアパスであり、ポジティブに捉えられていいものだと思っています。

 

「成功のために何でもやる」ポジション

「エンジニアリングマネージャ」や「テックリード」といった仕事は、チームの成功のために何でもやることが仕事の責務の一部になっています。
そして「成功のために何でもやること」を熱意があればこなせる単なる雑務だと思われがちですが、実際はリーダーシップや課題発見力や臨機応変な対応力など様々なソフトスキルの組み合わせによってなされる高度な仕事です。
フルスタックエンジニア」という仕事も同じであり、チームが成功するために技術的な様々な課題を何でもこなす仕事であり、単に様々な部分を触れるだけでなく技術的に全体を俯瞰できるスキルや高い学習能力が求められる高度な仕事です。

最近ではエンジニアリングマネージャになった後、技術力を再び磨くためにエンジニアに戻るというケースも増えています。
フルスタックエンジニアも同じで、新規開発スタート時にはフルスタックエンジニアになり、その後チームの専門性が上がったときに再びエンジニアに戻ればいいのではないかと思います。
一度エンジニアリングマネージャやフルスタックエンジニアを経験したことで、チーム全体の動きも今までよりもよく見えるようになっているでしょう。

 

最近出た「チームトポロジー」という本で提唱されている「ストリームアラインドチーム」という概念があります。
「組織が価値を生み出し顧客まで届く流れ」がストリームであり、それに沿った形で作られたチームのことをストリームアラインドチームと呼び、このチームが中心となり他チームの力を借りつつ機能開発していくという考え方です。
ストリームアラインドチームは他チームを待つことなくデリバリー(デプロイ)することができ、まさにこのチームが中心となって価値提供していくことになります。


個人的にはこの考えが好きで、「フロントエンド」といった技術領域でチームを切るのではなく、「ユーザに届ける価値の単位でチームを切り、その中にフロントエンドエンジニアがいる」といった考え方のほうが自然なチームになる気がしています。
DevOpsにおける「開発が運用も意識すべき」という考え方も、このストリームアラインドチームの考え方に近いです。
ストリームアラインドチームに沿ったチームの切り方をすると必然的に、決められた仕様に沿って特定技術領域だけを実装するのではなく、複数領域を横断的にこなすフルスタックエンジニアが増えていくのではないかと考えています。

 

 

そういった背景で私は、フルスタックエンジニア”という仕事は昨今のスピード感ある世の中において行き来可能な重要なキャリアパスの1つであり、もっとポジティブな意味で捉えられてもいいのではないかと思っています。

(ただしすでに単語として悪いイメージがついてしまっているため、別のバズワードに形を変えてとして再登場するんじゃないかと予想しています。)