フルスタック化しないと生き残れないのか？日本語版（1/3）

エイクエントの兄弟ブランドVitamin-Tが行ったウェビナー（オンラインセミナー）を邦訳し、書き起こしました。

Rethinking full stack: cost and compromise

当ウェビナーは64分間あり、書き起こすと19000文字ほどになります。一度に読むのは骨が折れると思われるので、3回に分けてお届けします。
今回は前編です。

• 前編（この記事）
  • フルスタックの定義
  • フルスタックへの不安
  • 成果を上げるチームとは？
• 中編
  • HTMLとCSSは軽視されているのか？
  • BEDとFEDの微妙な関係
  • 理想的なチーム構成
• 後編
  • フロントエンドはデザインとインタラクションに分けられるのか？
  • 肩書は必要化？
  • 「最先端で最高」でなくても生き残れるのか？
  • FEDの生きる道

登場人物

• Jeremy : エイクエント教育プログラムのディレクター
• Eric Meyer : CSS教本など多数の著書を持つスペシャリスト Webサイト
• Dan Mall : クリエイティブ・ディレクター。SuperFriendly社創業者|SuperBooked社CEO Webサイト

略語

• FED : Front End Developer（フロントエンドディベロッパー）
• BED : Back End Developer（バックエンドディベロッパー）

J: ウェビナーを始める前に、そもそも、なぜこのトピックを選んだのかなど背景についてお話します。それはフルスタックWebディベロッパーとフロントエンドWebディベロッパー（FED）の違いにも関わることだからです。議論のきっかけとして、マンディーマイケルが書いたこの刺激的なタイトルの記事をあげてみたい。「JavaScriptも書けない人に価値あるの？」

この記事では、Web業界、つまり、マネージャやWebチームを実際に指揮している人、デザイナーやディベロッパーにおける、フルスタックをめぐるダイナミクスについて語られています。

フルスタックとは、HTMLとCSSとJavaScript、時にはその他のバックエンドフレームワークを含むことです。フロントエンドというのは、定義は色々ありますが、ここではHTMLとCSSとします。他にもこのトピックについて書いている人はいます。ブラッド・フォレストは各企業を訪問して「フロントエンドのユーザー体験に責任を持つのは誰なのか？」を訊きまわっています。

このフロントエンドコーディングをするのは誰？という問いに答えるのは一見簡単なようで、そうではないですよね。このウェビナーに登録してくださった方からもいろいろな論点があげられています。なのでポイントを３つに分けて話を進めたいと思います。

メリッサさんからの質問「フロントエンドとフルスタックの定義ってどうやって決めるのか？」これが一つ目。二つ目は「そのスタックの中に何が含まれるのか分からないのに、フルスタックという言葉に意味はあるのか？空虚なバズワードに過ぎないのでは？」。そして三つ目は「フルスタックという語は無理やり作り出された造語なのか？あるいは90年代、2000年代の現実のニーズからマネージャーや開発者が使い始めた言葉なのか？」

フルスタックの定義

J: 論点がずれないように確認したところで、エリックとダンの意見をきいてみましょう。まずはエリック、君はフルスタックをどう定義しますか？

E: おっと。その質問は、まずは、ダンに訊いてほしいな。ダンはクライアントワークを僕以上にやっているからね。

J: オーケー。ではダン、お願いします。

D: じゃ僕からいくね。この質問に答えるのは難しい、だって、業界として皆が同意する定義が出ていないからね。ジェレミーがいうように、HTML + CSS + Jacscriptをフルスタックという呼ぶ人はいるし、同じ組み合わせをフロントエンドと呼ぶ人もいる。そういう人にとってフルスタックとはフロントエンド + バックエンドなんだよね。「その言葉ってどういう意味で使っている？」という質問は、僕が考察を始めるきっかけになることが多い。僕は、クライアントや仲間と仕事をするときに、そういうあいまいな言葉は避けるようにしているんだ。でないと、言葉の定義にエネルギーを費やすことになるからね。

僕自身、フルスタックをキチンと定義できないし、規範となるべき定義をみたこともない。だから僕はこんな事は言わないようにしている。「彼がウチのフルスタックディベロッパーです」「僕はフルスタックディベロッパーです」「うちにはフルスタックの連中が居るんだよ」。そうではなくもっとハッキリ表現するようにしている「OK、じゃうちはHTMLとCSS、そしてJavaScriptをやるよ」とか「おっしゃ、ウチはフロントエンドとバックエンドの両方を、つまり、Laravelなどのフレームワークを使ってHTML、CSS、JavaScriptやるよ」という風にね。

J: エリック、君はこの業界が長いから訊くけど、フルスタックという言葉が出てきたのはいつごろか覚えている？またこの言葉についてどう思う？

E: 歳をとると記憶が曖昧になるのだけど、フルスタックという言葉を目にするようになったのはこの5年位じゃないかな。その前にも目にしたことがあったかもしれないけどね。僕がフルスタックを定義するように頼まれたら、フロントエンド＋バックエンドと答えると思う。フロントエンドと言うのは、HTMLとCSSでJavaScriptを含めることも多い。バックエンドはバックエンドで動いているものは何でも。そう思うのは僕がフロントエンドの出身だからだと思う。バックエンドの仕事もしたことあるけど、ここ数年の僕の仕事の多くはフロントエンドなんだ。

もし僕がバックエンドの人だったら「ブラウザーと自社サーバーにインストールしてある6つのアプリ…」なんて答えると思う。つまりダンが言っているように業界で皆が同意する定義はないってこと。どんなクライアントの誰と話しているのか？あるいは、一つのクライアントの中でも誰と話しているかで答えは変わるんだ。バックエンドの人は彼らなりの答えを持ち、フロントエンドの人はまた違った見方をする。超テクニカルな話をしたいなら、フルスタックというのは文字通り、フロントエンドとバックエンドのすべての部分に関してになる。でもそれはもう別の話題だね。

フロントエンドに関していうと、明確な見方がある。なぜなら、フロントエンドで扱うものは少ないから。HTMLとCSSとJavaScript、もしかすると、議論は分かれるけど、画像処理を4番目に上げるかもしれない。でもそれだけ。画像を更に細かく話す場合は、そのフォーマットかな。JSのフレームワークをつかっているなら、それが何なのかも。

バックエンドになると話はややこしくなる。PHP、Ruby、Laravel、ExpressionEngineなどなど。バックエンドには多種多様なものがあるからね。誤解や混乱はバックエンドから生まれているのだと思う。こんな風にいうことが出来たら簡単なんだけど「フロントエンドはさっき触れた3つで、それにサーバーを足せばフルスタック。Apache、.Net、ASPとか色々あるけど」と。

フルスタックへの不安

J: ジレンマとしてあるのは、フルスタックという言葉が色々なところで使われていて、それは「フルスタックエンジニアは交換可能だから」と思われているからではないかな。4、5人のフルスタックディベロッパーのチームを作れば、そのチームは何でも出来る。UIも、データベースマネジメントも。そんなことは夢物語なんだけどね。

フルスタックという言葉が一般的になっていくと、フロントエンドの人達の間にはある種の不安感が生じると思うのだけれど、どうだろうか？答えはYESだよね。

E: 全くその通りだと思う。DigitalOcean社にジョエルという男がいて、「フルスタックへの不安」という話をしていたのを思い出した。フルスタックへの不安（フルスタックではないと仕事を得ることが出来ない）は業界で起こっていることだね。

J: その点に関する必然的帰結として「偽物シンドローム」があると思う。スタックの一部を知っているとみなされたエンジニアがチームにジョインしたとする。でも実際はそうではないので、出来るふりをしてしまう。ダンはこういうケースを見たことある？

D: もちろん。業界の進化とともに、その種の不安も進化していると思う。今は、自分がデザイナーやディベロッパーとして経験したことを思い出しながら話を聞いていたところさ。2000年代の中頃、まだレスポンシブがやってくる前、ブラウザーがWeb標準に従っていた頃、AJAXが出てきた頃だったと思う。AJAXが広まる前の会話は「君はHTMLとCSSをやってくれればよい。JavaScriptが必要ならバックエンドディベロッパー（BED）がやるから」なんていうものだった。とにかくサイトをたくさん作らなくてはいけなかったし、そこでJSはあまり必要とされなかったんだ。

そしてAJAXがやってきた。僕はFEDの一人でAJAXの命令を書けるほどJSを知らなかった。BEDがJSを書いていたと思うのだけど、それは変な話だよね、だってAJAXはフロントエンドのテクノロジーだから。それはクライアントサイドのテクノロジーだけど僕の範疇ではなかった。その後、AJAXはどんどん高度化していって、FEDとして僕はその役をこなせるほどJSを知らなかったんだ。

JSはその後、サーバーサイドにも発展していき、Nodeなんてのも出現し、フロントエンドとバックエンドの垣根が曖昧になってきているのが今だよね。僕自身、JSはある程度は書けるけど、自分がHTMLやCSSを書ける程のレベルではない。AJAX命令を書かなくてはいけないという事実はあるので、それが僕の不安材料なんだよね。でも今はクライアントサイドの技術でサーバーサイドのコードを書いているよ。

僕のような経験をしてきた人は多いと思う。「僕にはJSの書き方はわからない。 でもそれってそもそも僕が知っているべきこと？僕が学ぶべきこと？他の人の仕事に踏み込んでいるのではない？」業界の進化は、業界で働くひとの不安や心配に連動していると思う。

成果を上げるチームとは？

J: それは面白い意見だね。ボストンのイベントで君がプレゼンをした時、モダンデザイナーについて語るスライドで、君は、デザイナーもJSONをマスターすべきと言っていたよね。今の話と関係づけると、どういうことになるのだろう？境界線はどこになるのかな？つまり、今、ある者が「僕はフロントエンドの人です」といったとき、その人はモダンWebデザイナーと大きく異なるのだろうか？

D: 表面的には違いはないと思う。一つ言えるのは、もしその境界がどんどん曖昧になっていくという立場をとるならば、僕たちが助け合っていくべきということ。「JSは僕の仕事じゃない、君の仕事。だから君がやって」ではなく「JSは君の仕事ではないことは知っているけど、簡単な書き方は教えてあげるよ」と。それがJSONや変数の設定かもしれないけど。こういうアプローチがチームとしての不安を減らすんだと思う。

タイトルは忘れてしまったけど、グーグルがこんな研究を発表していた。それはチームのメンバーはどんなときに最大の成果を出すのかという研究で、仮説としては、経験を積んだ人を同じチームに入れると良い結果が生まれるというものがあった。でも実際はそうではなかったんだ。

終身雇用の者のチーム、スキルの高い者のチームもその答えではなかった。最高の結果を出したのは、心理的な安心感を醸成したチームだった。僕はその安心感は、助け合うことから生まれていると思う。「これは君の本来の仕事ではないから、君がやり方を知らないのは当然と思う。でも僕がやってあげるから心配しないで」こんな風に助け合う。「君が学べるようなシナリオを僕が作ってあげるよ。学びの最中は失敗しても大丈夫。僕がバックアップで入るから。僕をセーフティーネットにして君は成長してほしい」

実際に経験した例はこんな風だった。「君はどうやりたい？」とまず訊いてみる。Angularを学んでみたいという答えが返ってきたら「なるほど。このプロジェクトではAnglarを使わずに終わるかもしれない。そんな時は他のやり方でやってみよう」こんな風に言うと安心感が生まれて「Anglarを学べなくてもOKさ」となる。こういう風に言うと、不安感をなくすのに効くんだ。うまくやらないと首になってしまうという不安を減らすことができる。メンバーの不安をなくすことができると、メンバーは成長するという実例を僕は見てきたよ。

（中編へ続く）