最近、「フルスタックエンジニア」という言葉をよく聞きます。
もしかしたら近いうちにバズワードになるかもしれません。
初期のクラウド・コンピューティングが異常なまでに混沌としていたように、バズワードは、利害が絡みそうな人間が強引に意味を追加してあいまいな姿に変えるという特性を持っています。なので、今のうちに私なりに調査して、明確な意味付けをしてみようかと思います。そんなことをしても、きっと転職・派遣業界が変えてしまうのでしょうけど。
フルスタックエンジニアとは？
日本だと定義はソースによってバラバラのようですが、設計から実装・デプロイ、テスト、インフラ構築までと、とにかく幅広い範囲をカバーするエンジニアを指す用語として説明されています。
日本ではまだ情報が少ないようなので、海外からソースを
http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/
- サーバ、ネットワーク、ホスト環境
- データモデリング
- ビジネスロジック
- APIレイヤー / アクションレイヤー / MVC
- ユーザインタフェース
- ユーザ体験
- 顧客・ビジネスニーズへの理解
スキルで見れば、上記7つの知識に理解があるエンジニアのことを指すと説明されています。ただし、これは一例にしか過ぎません。フルスタックエンジニアは亜種がいっぱいいます。
- フルスタック・フロントエンド・エンジニア
- フルスタック・Ruby・エンジニア
- フルスタック・Web・エンジニア
- フルスタック・プログラマ
とか、とりあえず頭に「フルスタック」とつけば、何でもやる系を意味するようです。
先ほどのURLの内容は、Facebookのエンジニア雇用を説明したものです。彼らは、各レイヤーで特化した知識を有するよりも、全てのレイヤーでそれなりに知識を有するエンジニアの方が現場や組織を楽にできるという考えを持っているようです。そしてそれができるエンジニアを、フルスタックエンジニアと呼んでいます。Facebookも大企業化しつつあるので、コミュニケーションなどの効率化を踏まえると、そういうタイプのエンジニアの方が小回りがききやすい的なことも言っています。
この説明を聞くと、大規模化が進む企業の救世主みたいな響きがします。中途採用を積極的に行う企業が、このアイデアを組み込もうとする姿が目に見えます。実はもう既にどこかで計画しているかもしれません。ただ、この言葉を今のSIのような分野で扱うには、注意が必要ではないかと私は考えています。
ミクロに見るとエンジニアはスペシャリストでなくてはいけない
国内に限らない話ですが、エンジニアはもうずっと、アイデンティティやスペシャリティを持つことが重要視されてきたように思えます。エンジニアが自己紹介をする時、「ジェネラリスト」という人はあまり聞いたことがありません。よく使われるSEという言葉でさえ、もう少しマシな定義を持っています。
「私はOracleDBに詳しい」「私はWindowsネットワークをやってきた」と、具体的な技術名を出して自分を説明できることは、仕事を依頼する側としてもやりやすいでしょう。どういう課題を解決してくれるか明確に見えるからです。パズルのピースのように人を配置できます。
これがディレクターでなく現場の人間であっても同じでしょう。悩んだ時にその人の名前を引き出させる強い印象・アイデンティティを放つのは、技術領域や具体的な技術名なはずです。「DBに詳しい」と言うよりも「OracleDBに詳しい」と言った方が、「フロントエンドに詳しい」というより「jQueryに詳しい」と言った方が、直接的な課題と結びつきます。特化することが価値なのです。つまり・・・
「幅広くやってます」「一通りできます」な人は、
所謂ジェネラリストなエンジニアは比較されると負けるのです。
多くの現場では、本当に複雑で重大な問題を抱えた時、「幅広くやっています」な人間に解決方法を求めることは無いでしょう。「DB詳しいです」と「幅広くやっています」の2人がいて、DBに悩んだ時は前者へ相談するに決まっています。重要な判断が求められた時、価値の高い選択が求められた時、スペシャリティの無い人は必要とされないのが現場の考え方でしょう。
ミクロに見ると、エンジニアの価値はスペシャリティで決定されるのです。
マクロに見るとジェネラリストはどうしたって必要
しかし、モノを作る現場・プロジェクト・企業・業界と高い視点から見ると、そうもいきません。
入門者なら、「断片的」よりも「俯瞰的」に理解することが求められるはずです。協業する他の専門家と会話ができないと、問題の本質を捉えることができない。全体を俯瞰して、最適な解決方法を導けないかもしれない。いくら専門性が高くても、一人ではできることに限界があります。多少の基礎的な知識が必要なのです。まずは、ジェネラリストを目指すのが普通でしょう。
ジェネラリストはどの現場にもいないと困る人材でもあります。モノを完成させるには、全ての部品を揃えなくてはいけません。いくら高い専門性を持つ人を集めても、全ての部品を作れないのでは意味がない。精巧な部品を作れる人が必要な一方では、どんな部品も不足無くある程度に作れる人が必要でしょう。
マクロに見れば、ジェネラリストは必要不可欠な存在です。
フルスタックエンジニアの仕事は何なのか？
スキル体系だけで見るなら、フルスタックエンジニアがジェネラリストという解釈で間違いは無いでしょう。ただし、現場での活動の内容には、明確に違いがあります。
通常、「一通り知っている」なエンジニアは、ウォーターフォールを必要とする大規模開発の現場では、現場的にも、組織機能としても、空席となった担当へ入るように思えます。例えば、SQLが書けるけど、SQLのチューニングができない。Javaは書けるけどインターセプターが作れない。業務ロジックは設計するが、データモデリングできない。そういうメイン部分からやや外しつつ、空いた部分を埋めるためにジェネラリストが入るイメージです。所謂、便利屋です。
しかし「フルスタックエンジニア」は、空席を埋めるというよりも、アーキテクチャ全体を見た総合的な判断をしたり、インフラも含めてスタートアップを作る人。アジャイルにモノを作るプログラマというニュアンスが強いです。
私は入社してしばらく、「私はJavaしか書けないからDBをやって下さい」「ネットワークはわからないのでスイッチの設定ファイルを作って下さい」「JavaScriptのレビューができないので代わりにレビューして下さい」と、空席を埋める担当として働いていました。そのどれもが、他の専門家と比較すると選んでは貰えない、所謂「負け」の仕事です。たまたま、誰もできる人がいないから、コンスタントにやってくれそうだから担当してもらおうというタイプの仕事です。ジェネラリストです。
私がWeb信者になってからは、「川田はWeb信者」という印象だけでWebの仕事が来るようになりました。上司からJavaの仕事を指示されても、いざ現場に行くとWebに変わっていることがあります。Webの課題を全部私に依頼してくるわけです。Webに関連した悩みはとりあえず川田にメールして聞こう。レビューをお願いしてみよう。もはや知らないことは悪という状況に追い込まれ、環境に鍛えられて専門性が磨かれているという状況。ただ、ここで得られた仕事はどれも、他にできる人はいるかもしれないけど、川田に依頼しようという「勝ち」の仕事です。スペシャリストです。
機能で横割り化されたプロジェクトでは、ジェネラリスト、スペシャリスト、どちらをやっていても、組織から見たら一つの担当をする人間にしか見えません。1人/月を担当する要員でしかありません。前者も後者も、PJ全体から見ると同じパズルのピースです。だからこそ、マネジメントもある程度はうまく機能するのでしょう。そしてこういう状況下に置かれると、エンジニア個人で見れば後者の方が価値が高く、組織から見れば一人で複数の役割をこなせる前者の方が価値が高く見えてしまいます。
ジェネラリストをフルスタックエンジニアと定義するなら、マクロには必要とされ組織としては使い勝手が良い人材ということになります。そして、ミクロにエンジニア個人の価値を高めるという意味では、あまりお得感がありません。
「スキル」という側面だけで見ると、フルスタックエンジニアというのは、採用組織側の利益だけを追求した都合のいい職種と感じてしまいます。
フルスタックエンジニアはスキルではない
クラウドによる柔軟なインフラ環境、オープンソースの豊富かつ手軽なフレームワークやライブラリの充実化、JavaやWebなどの標準でコモディティ化が進み、IDEやテストも効率化されました。アプリケーション開発の作業が全体的に、時間リソースの制約から開放されつつあります。
こうした背景の中、「時間をかけないと質が高い製品を作れない。」「人をたくさん使わないと製品が作れない。」という、今までの前提が崩れつつあるという状況でしょう。効率化自体は昔からもうずっと取り組まれてきたことです。RADにせよアジャイルにせよ、手法という側面からも散々議論されてきました。しかしここ最近は、少数でも商用に耐えられる製品が以前よりもずっと多くなり、時間というリソースから開放され、スキルが生産性に与えるインパクトが高くなったのでしょう。
スキルがあれば一人（もしくは数人）で開発できるというのであれば、一つの役割しかこなせない人をたくさん集めて開発プロジェクトをやるよりも効率的です。「人月の神話」が真であるというならば、少しぐらい給料が高くても、少数でやった方が効率的です。このバランスが現実的に入れ替わったのがここ最近であり、だからこそ「フルスタック」という言葉が生まれたのでしょう。最近だと、超高速開発というコミュニティが生まれたようですが、その主たる要因はフルスタックエンジニアと同じ背景にあるように思えます。
七色いんこでなくトライアスロンランナーを
注意しなくてはいけないのは、フルスタックエンジニアの募集では、スキルの面しか語られていないという点です。どういう作業内容かまでは、どの採用枠でもあまり語られていないようです。RADもアジャイルも手法ですが、フルスタックエンジニアは職種を表す言葉であるため、これまでとは違ったリスクに見えます。
フルスタックエンジニアは、時間リソースから開放された、柔軟な開発プロセスを作るためにあるものというニュアンス。ハッカーに近い崇高さ、ブランドが感じ取れます。だからこそ、そういう人材が活きる、開発が求められる現場で、高い生産性と価値を生み出し、フルスタックエンジニアに対して高い給料を与えるモチベーションに繋がるという想定でしょう。
それが、ウォータフォールで縦割り文化を持つ旧来のSI的なプロジェクトに突っ込まれたらどうなるでしょう。やはりただの便利屋で終わってしまいます。不足している役割を補うだけの、従来のジェネラリストと何も仕事内容が変わりません。そして、フルスタックエンジニアらしい生産性を生み出すこともできず、フルスタックエンジニアらしい給料を与えることも難しいのではないでしょうか。他の作業要員と同じただの1人/月になっては、元も子もありません。
フルスタックエンジニアは希少な存在で、企業としても凄く魅力的な存在として語られます。ただ、もし企業がこういう人材を欲しているのならば、そもそもその企業がフルスタックエンジニアらしい働きを必要とする現場なのかどうかを、一度考えてみる必要があるかと思います。
また、フルスタックエンジニアとして働こうという人。スペシャリティは無いかもしれないけど、それまでにはかなりの努力を要したはずです。海外だと、ハッカーだなんて言われるぐらいだから、本当に努力したのだと思います。しかし、スペシャリティが無いというだけでただの便利屋になってしまう可能性があるので、組織は慎重に選んだ方が良いかもしれません。数人でやっているようなベンチャー企業とかだと活躍できそうですが、大規模なプロジェクトだと、、いかがなものでしょう。
七色いんこを欲している現場が、トライアスロンランナーを雇うのは勿体無いと思うのです。
