フルスタックエンジニアの末路！かつて英雄だった彼は何処へ

はじめまして，３０代フリーランスの底辺プログラマです．

フリーランスという立場上，様々な会社を渡り歩いてきました．

其の中で，いわゆる「フルスタックエンジニア」と名乗る人たちに会ってきました．

あなたは，職業を聞かれた時，なんて答えますか？？

なんて答えますか？？

「コーダー」

「プログラマ」←多いです

「PM」

「エンジニア」←多いです

「サーバサイド・フロントエンドエンジニア」

「バックエンドエンジニア」

「SE」

「インフラ屋」←多いです

「テスター」

...

おそらく何らかのポジションの一つを答えると思います．よく聞くのは，BOLD表記にしました．

そして，そのポジションを元に会話をすることになります．

しかし，上述したように，一定多数の方は「フルスタックエンジニア」と答えます．ただ，そう答える人たち初めて出会ったは，約４年前のことでした．

其の頃，僕はフロントエンジニアという人たちからjQueryができないと終わってるだの，Backboneって知ってる？だの，CoffeScriptって言うのがあってねだの，そんなことを聞かされて毎日を過ごしていました．

そんな彼らを一蹴りしてたのがその当時出会ったフルスタックエンジニア．彼は経験年数こそまだヒヨッコの枠でしたが，知識量はすごかったです．よく経験もしていないのにそんなに言語やフレームワークの是非を語れるな，と僕は思いましたが，まあそういうタイプの人間は少なからずいますので無視していました．

フルスタックエンジニアとはなんですか？

あ，とここでフルスタックエンジニアとはなんですか？という話があるかもしれませんので，そのあたりを世間一般の話と僕の私見により解説します．

まず，世間一般論ですが

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

引用： e-words.jp/w/フルスタックエンジニア.html

• 複数の技術分野についての知識や技能に精通していなければなりません．
• 一人でシステム開発や運用を行うことができる技術者でなければなりません．
• 通常はそれぞれに専門の技術者がいて分業されているものを一人で行う必要があります．

これがどれだけ難しいことを言っているかというと

通常のシステム開発は数人で役割分担されて品質保障もされているでしょう．

しかし，フルスタックエンジニアがその各専門担当の人員と同等・あるいはそれ以上の能力を持っており，かつ一人で其の専門のメッシュ的役割も担うので情報連携を取る必要がなく，ただただ仕様に準じるだけで一人で作業が完結することができるのです．

確かに，このスペックを持っているエンジニアは，会社からすれば喉から手が出るほどほしいですね． 

私見

フルスタックエンジニアは，大体フルスタックエンジニアではないですね．

現場のレベルが低かったりすると，他の人よりもいろんなことをやらされるではないですか？その作業領域が広いので，フルスタックエンジニアと名乗ってるに過ぎないのです．もちろん，ネット上で本当に優秀なフルスタックエンジニアな人はいるかもしれませんが，正直リアルな現場では数人程度しか会ったことがないです．また，彼らは自分のことをフルスタックエンジニアとは言いません．周囲からそう思われているだけで本人は「プログラマ」と名乗っていました．

要は，大体のフルスタックエンジニアが似非です．

本来エンジニアは，技術者という専門職でありスペシャリストを目指すのが一般的でした．

ジェネラリストは，フルスタックエンジニアとは違うと思います．

さらに，ジェネラリストというものにも達していない方が多いです．

もう一ついいますとフロントエンジニアがメインの方がフルスタックエンジニアと名乗ることが多いです．おそらく，AWSなどのクラウドがメジャーになったことで，バックエンドの参入障壁が下がったことが要因だと思います．

フロントエンジニア出身の自称フルスタックエンジニア

最初の話に戻りますが，フロントエンジニア出身の自称フルスタックエンジニアは本当に多いです．自称と書いてるのは，本物に会ったことがほぼ無いからです．たまにいますが，別にそんなレアな人を考慮しなくても良いと思います．

実際に僕がよく出会う自称フルスタックエンジニアのスペックは以下のようなレベル感が多いです．

• ビジネスサイド: 考えてますアピールはしてる．いいからプログラマの給料挙げないと転職しちゃうよ．（フルスタックエンジニアなのに，プログラマが一番）
• UI/UX: 重要だよね！てかデザイナの領域でしょｗ（フルスタックエンジニアなのに，領域外のことはしない）
• DB: SQLとかかけるけど，パフォーマンスを意識したことはない．
• サーバ: Herokuは使っていたけどAWSはEC2ならちょっとわかる．Linuxコマンドあまりわからない．straceとか使ったこともないよ．
• プログラミング: オブジェクト指向少しわかるけど，デザパタはよく知らない．設計手法もあまり知らない．でも書く速度は早いよ．
• フレームワーク: Rails？チュートリアルならやったよ．メタプロってなに？てか，Railsってもうオワコンでしょ？別のフレームワーク勉強しなきゃ．
• MVC: 知らない．

この構成は，フルスタックエンジニア？でしょうか．

十中八九，似非ですね．

実は，こういう方がフルスタックエンジニアと名乗って面接に挑む事が多いです．

また，技術のことよくわからないディレクターとかなんちゃってPMが面接しちゃうと，けっこうな確率で採用されちゃうので危険です．スキルシートに触ったことがある技術を書かれてしまうと，その技術ができてると勘違いしてしまうのです．

例えば、もしプログラマについてよくわかっていない管理者の方は、最近はやりの プログラミングのオンラインスクールCodeCamp に通ってみるのはどうでしょう？

ディレクターでも最近だと簡単なSQLぐらいはかけないと要件を伝えるのは難しいでしょうし、このスクールでは、様々な講座が展開されているのでまずは体験レッスンを受けてみて、その後本当に通うかを判断してみるのは大いに効果的だと思います。

そして，フルスタックエンジニアの末路は

現場でボコボコにされ，ゴミクズのように扱われ，切られます．

フルスタックエンジニアに依頼したつもりが，まるで素人の出来だからです．

Railsができるって言うからまかせたのに...rubocopの範疇までコード指摘させるなと．

でも，大体は，考え方を変えるだけで優秀になれると思います．

どうしたらよいですか？

簡単です．以下の本をまず読みましょう．

実は，意識を変えるだけで優秀になれる人は多いです．

優秀というのは，特定の技術のスペシャリストになるだけじゃなくて，メッシュ的存在になることも指します．ただ，できるのではなくやり方を知っているだけでも違います．

ビジネス

実践リーンスタートアップ

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

読んだ時，

正直，ビジネスってなんなの？ってレベルだったのでだいぶ勉強になり，さらにリーン開発のいろはも学べました．ビジネスへの知見を是非増やしてみましょう．

一度リーンキャンバスを書いてみると良いと思います．

多少は考え方が変わるはずです．

UX

リーンUX

Lean UX 第2版 ―アジャイルなチームによるプロダクト開発 (THE LEAN SERIES)

 リーンスタートアップを学んだらこのUXデザインの手法も学びましょう．

ユーザ体験は重要ですが，デザインに全部任せきるというのはフルスタックエンジニアとしては良くないです．

DB

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

 ミックという方が書いた本です．少し古いですが，これ読んだこと無いなら読んだほうがいいですね．

パフォーマンスについても書かれていますし，現場でも通用する設計力が身につくと思います．

サーバ or プログラミング or MVC or フレームワーク

以下の記事が参考になるでしょう．

valuable.hatenablog.com

Rubyに関して

Effective Ruby

Effective Ruby

メタプログラミングRuby

メタプログラミングRuby 第2版

一番Rubyできるという話が多いのですが，最低でもこの2つは読みましょう．ネットで拾える情報だけでなく細かいところまで体系的に見直すことができます．ネットでググって書いてるだけのエンジニアはいつか詰みます．インプットをすることで実践においてその効力を発揮する時間を短縮できますし，再学習することができます．

この本を何度も読めば，Rubyに関してはあとは最新のコミットログを追うだけでよいのです．

例えば，if文においてtrueにならない条件はnilとfalseですが，そういう基本的なことから，メタプロについての話まで乗ってます．