フルスタック化しないと生き残れないのか？日本語版（3/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: ここからはQAセッションに入りましょう。早速チャールズから質問が寄せられているので、ダンやエリックに答えてほしい。「フロントエンドの仕事は、デザインとインタラクションに分けることが出来るのでしょうか？」面白い質問と思うのだけど、ダンとエリックはどう思う？インタラクティブ性はWebにデフォルトとして備わっているものなのか、それともデザインとインタラクションは分離できるものなのか？

D: それについてはいろんな学派があると僕は思っているね。ジェレミーが冒頭でフルスタックディベロッパーについてのブラッドの記事を紹介してくれたよね。彼のことは個人的に知っているんだけど、ブラッドがよく言っているのはデザイナーとディベロッパーの中間にfront-end designerという概念を置くこと。それはコーディングを担当する人は、デザインについての最終責任を持たないまでも、説明責任は持つという考え方なんだ。ディベロッパーはデザイナーと時には席を同じくしてデザインプロセスを共有すべきという考え方。まずそれが一つ。

僕はプロジェクトを進めるときには、プロジェクトは、デザインとエンジニアリングを両端に持つスペクトラムで、スペクトラム上には、いろいろな職務のメンバーがいると考えるようにしている。ここではいわゆる職種というのは関係がない。メンバーが「何であるか」ではなく「何が出来るか」を見ているんだ。「FEDを雇わない」と言っているのではないよ。あるプロジェクトでは「HTMLをCSSを書ける人」を一人と「JavaScriptを書ける人」を一人雇ったり、他のプロジェクトでは、その3つを出来る一人を雇ったりする。

僕はスペクトラムが端から端までカバーされるようにして、かつ、個別メンバーのカバー領域が重なり合うようにしている。スペクトラムを分割することができるかって？それは出来るさ。どんな学派のやり方だって、みんなが好きなだけ細かく分割することが出来る。それによって生産性が上がるかどうかは、やってみないとわからない。だから、いつでもどの組織でも通用するやり方とは言えないのだけどね。

でもこれだけは言っておきたい「まず分割してみよう。そして何が起こるか観察するんだ」と。もしそのやり方が以前のやり方よりヨイと分かったら、続ければよいし、そうでないなら他のやり方を試したり、以前のやり方に戻ればよいんだ。

E: 僕は、Webにおいて、デザインとインタラクションを分けるのはあり得ない選択だと思っているね。本でさえインタラクションを考慮してデザインされているのだから、すべてのデザインはインタラクションを考慮すべきだ。上手にデザインされた本は、ページをめくることを前提にして、スペースが空けられているよね。高速道路を車で走っているときに文字が沢山書かれたビルボードを見たことはないかな。ちゃんと読もうとしたら、事故を覚悟しなくちゃいけない。メディアの特性を理解しないでデザインするとこんなふうになってしまうんだ。

Webは本やビルボードよりもインタラクティブ性が高く、歴史上、最もインタラクティブ性が高いメディアなんだ。どんなシンプルなWebでさえ、スクロールはするし、リンクをクリックすることができる。「ビジュアルデザイナーはあっちをやって、インタラクティブデザイナーはこっちをやって」という風に分けるのは、生産性を下げることでしかない。そんなやり方はサボタージュとしか思えない。Webは根本からインタラクティブで、流動的なメディアなんだから、そうでないふりをしてデザインプロセスを進めるのは筋が悪いとしか言えない。

D: 僕は時々、代理店内のチームをコーチすることがある。制作プロセスとかメンバーの役割とかをコーチするのだけど、いつもFEDという役割をなくすことを奨励し、デザイナーとエンジニアだけにするんだ。デザインの世界にはいろいろなデザイナーがいて、イラストレーターがデザイナーと名乗っていたり、3Dデザイナーがいたり、その中にコードを書けるデザイナーがいたりする。

エンジニアの方に目を向けると、こちらにもいろいろなエンジニアがいる。サーバーを構築する人、データベースを設計する人、そしてフロントエンドのコーディングが出来る人。そんな中で、無理やり分割点を見つけることは難しいよね。ディベロッパーという役職はちょっと扱いが難しい。なぜなら、多くの場合、ディベロッパーはデザインとエンジニアリングの中間にくるから。

企業によっては「ディベロッパーなんて役職は存在しない。それが意味することが不明確だから」という場合もある。そういう組織には、デザインが出来るエンジニアと、コードが書けるデザイナーがいて、それぞれが思いのままに時間の使い方を割り振っているんだよ。

肩書は必要か？

J: 次のJohnからの質問は面白い。「UIとFEDを隔てる境界線はなんですか？」さっきの質問と似ていると同時に、これはゼネラリストとスペシャリストの議論につながるからね。どこかの時点で、定義をはっきりさせるか、自分を規定の箱に入れなくてはいけなくなる。

D: ふむ。「規定の箱に入らなくてはいけない」という考え方はどこからやってくるのだろう？チームメンバーが僕とどうインタラクションするのかや、僕に何を期待しているのかを知る必要があるから、箱理論にも、もっともな面はあるけどさ。だけど役割の境界が曖昧ではいけないのかな？ベキ論とは別に、境界の曖昧さは既に起こっていることで、自然なことだと思う。

「UIとFEDを隔てる境界はなんですか？」というJohnからの質問には「その境界がないとしたら、一体何が起こるのだろう？そのことであなたの物事の進め方に影響は生じるのかな？」と答えたい。

E: 僕はJohnがそんな質問をすることは分かる気がする。なぜならあるケースに置いては、自分が「何であるか」が職位と給料を決めるからね。僕が大学で勤めていたときは、エンジニアには1〜4のレベルがあって、それによって休日日数や給料が決まっていたんだ。だけど今僕たちがいる業界では「箱に入るな」というのが正解だと思う。世の中には僕達を型にはめようとする力が既に働いているじゃないか。なぜ自分から進んで型にハマろうとするんだい？

J: それはうまい言い方だね。僕自身Webビジネスに携わって20年近くになるし、エリックとダンもかなり長い期間この業界にいるよね。この業界に入るための「エントリーポイント」を定義するのは年々難しくなっているように感じる。それがWebディベロッパーでも、Webデザイナーでも。業界で必要とされる知識を身につけるのは、ホントに大変で、もうそれが参入障壁に見えるほど。これはまだWebが発展途中だからだとも思うのだけど。Webはまだ若い産業だよね。

D: それはオハイオのSparkboxという代理店が「ハンマーとノミ」という記事に書いていることだね。彼らのやっていることはとてもスゴイことだと思う。僕たちは今、デザイナーとかディベロッパーを定義して、どんな時、どんな組織でも通用するルールを作ろうと四苦八苦している。これはホントに大変なことさ。そんな中彼らはこう言っているんだ。「僕たちは肩書を変えている」と。でもこれは彼らが肩書だけでなく、仕事そのものをどう捉えているかということなんだ。

彼らにはフロントエンドデザイナーというポジションがあるのだけど、彼らはこう言っているんだ。「ウチの会社のフロントエンドデザイナーは他とは違う。ハンマーの役を果たすものもいれば、ノミの役を果たすものも居る。ハンマーはHTMLとCSSで構造を構築するのが仕事で、ノミはアニメーションや、フォントスペースやフォントなどをちゃんとするのが仕事なんだ」と。彼らが自分たちなりに役割を定義していて、それが機能しているのが、僕はすごくヨイと思う。彼らは決してこうは言わない「他の会社もハンマーとノミのスタイルでいくべきだ」と。 彼らは単に「ハンマーとノミは僕達のプロセスに合っていて、それがうまくいく限りにおいて、このやり方を続けるつもりだ」と言っているに過ぎない。そこが好きなんだ。

僕が実習生からよく受ける質問にこんなものがある。「僕達が最低限身につけておくべき事はなんですか？」話はさっきと同じで、いつでもどんな組織でも当てはまる最低限というものが僕には思いつかないんだ。だから僕はいつもこう答えている。「その最低限は、どの会社に入るための最低限なんだい？」と。フェイスブックに入社したいのか、地方の代理店で働きたいのかで答えは変わるということさ。だって仕事の内容が異なるからね。フェイスブックではきっと専門特化した仕事をすることになるだろう。.

Nicole SullivanはCSSのリファクタリングコンサルをやったことがあるそうだ。とっても専門的な仕事だよね。でも、地方の代理店に入社すると、君は5人の社員のウチの一人で、いろんな役目を果たさなくてはいけないだろう。IAとデザインとかね。スペシャリストかゼネラリスト化という議論がよくされるけど、そんなときは「どの会社で？」と問わなくてはいけない。なぜなら僕が見てきた限り、一概に言えることはないからさ。ゼネラリストで好まれるポジションもあれば、その逆もある。

一つ便利な考え方を上げると「小さな会社で働く場合、ゼネラリストが重宝される可能性が高く、巨大なエンジニアリング組織やシリコンバレーのスタートアップで働く場合は、専門分野に超特化しているのがよい」かな。

J: 他にも似たような質問が幾つか届いているのでまとめると、それは仕事内容の標準化とスキルを持った人材をどうバランスさせるかという点について。エリック、これは給料にも関係しているし、肩書とか、実際の仕事内容とかも重要な要素だと思うので、一概には言えないと思うけど…。

E: そうだね。組織の規模が大きくなるほど、それは問題になるね。フェイスブックが実際どうやっているのかは知らないけれど、きっと、簡単に言うと、平社員のエンジニアとシニアエンジニアがいるんだと思う。そして平エンジニアにも、シニアエンジニアにも階層があり、新人エンジニアもあるのではないかな。誰かが定義した一定の要件を満すと上のレベルへ上がり、給料も上がる。そんな仕組みだと思う。その要件が恣意的で、時代遅れのものでも僕は驚かないよ。たとえPHP2を学ぶべしというようなものでもね。

「最先端で最高」でなくても生き残れるのか？

J: 次の質問はシアトルのHeidiから「HTMLとCSSそしてJavaScriptが出来たら、バックエンドのトレーニングをしてもらえる仕事にありつくことができますか？なぜこんな質問をしているかというと、シアトルでは無理だからです。これまで何度も、『HTML、CSS、JS、バックエンドすべて出来る人がいる中で、君を雇う理由はない』と言われてきました。他の大都市でも状況は同じなのでしょうか？」

D: 僕は、すべての大都市で状況が同じとは思わない。そういう仕事みつけるのは大変とは思うけれど、社員が２、３人の制作会社で、自社とって初のディベロッパーを採用しようとしている会社を知っているからね。そういう会社はHTMLとCSSが書ける人に悪くはない給料を払って採用しようとするんだ。シリコンバレーから年収2500万円のエンジニアを引き抜くんじゃなくてね。

そういう仕事を見つけるのが大変なのは、フェイスブック社のポジションとは異なり、大々的に募集されていないからなんだよね。でも探せば見つかるはず。Amazon、Microsoft、Googleなどの派手な求人に隠れているけど。でもそいうポジションはきっとある。僕自身そういう募集を見たことがあるからね。

E: ダンの繰り返しになるけれど、どんな企業で働きたいかによる。小さな会社でよいなら、そのスキルセットでも大丈夫。でも超巨大企業で、特別待遇や優遇措置を受けたいなら、その巨大企業の要望に合わせるしかない。残念ながら、この業界の企業は、最先端で最高のものを知っている人を探しているね。

ただ、プログラミングの世界ではそれはもっともなことで、例えば、PHP5が当たり前の今、PHP2を学ぶことには意味がない。昔のコードは動かないからね。だから最先端で最高が何なのかは知っている必要がある。

けれどWeb制作をみてみると、ティム・バーナーズ・リーが作ったWebページは現在のブラウザーでもキチンと表示される。しかもレスポンシブで。もちろんメディアクエリを使っているわけではないのだけれど、画面サイズに連動するページになっている。Webは後方互換性が評価される業界なんだけど、求人広告に載っている必要条件は、最先端で最高が評価される世界の人が書いているんだよね。

J: まさにその通り。Webは明らかに絶えず進化し続けているけれど、大事なものを捨ててはいけない。Webにはずっと変わらずに根底に横たわるコンセプトがあるのさ。アクセスビリティとか、ページの読み込みスピードはその例だね。

FEDの生きる道

ウェビナーの終了時間が近づいているのでこれを最後の質問にしたい。多くの企業がフルスタックディベロッパーの採用に血眼になっているけれど、そのことによってHTMLやCSSが軽視されてはいないだろうか？

E: 面白い質問だね。僕はちょっと分からないけど、ダンはどう思う？

D: 難しい質問だね。自分自身がどうやってHTMLとCSSを身に着けたのかを思い出しながら、少し前の仕事内容の標準化に関する質問を考えてみたい。僕が、業界人の常識としたいのは、ソースをオープンにすることと、ブログを書くこと。それは僕自身、多くのことをブログや本を読んだり、他の人がどうやっているのかを観察して学んだからさ。

僕がWebサイトをローンチした時に、僕のブログに集まったコメントをよく覚えている。「なんでH2タグではなくH1タグを使うんだ？」とか。そんな議論をブログのコメント欄で続けたものだよ。でも今ではそんな光景を観ることはない。理由は分かるんだ。今は他にも学びのコンテンツがあるし、コメント欄には厳しい意見が寄せられることもあるし。僕が経験したようなディスカッションはなくなってしまった。今では、なんでもかんでも空のdivになってしまった。

E: ジェレミーの質問にこたえると、そうだね、フルスタックディベロッパーにこだわる企業は、JSとフレームワークでフロントエンドをやろうとしている。ダンが言うように、中身が空のDivだらけのサイトとか、それぞれのdivにCSSが関連付けられたものとか。CSSのCは「Cascading」だということを無視しているようなフレームワークも多いな。

フレームワークを第一に考える開発ではHTMLとCSSは、本来受けるべき配慮を受けられていないことが多いように見える。面白いのは、フレームワークの中には、CSSをすべてin-lined化してしまうものもあるんだ。わざわざそんな作りになっているものがあるんだよ。そんなフレームワークを作る人は、ユーザーはゆくゆくはCSSのあるべき姿に気づくはずだから、実は、CSSをin-line化したくはないと思っているのだけれどね。ユーザーは、その変な仕様を回避しようとすると、CSSがそもそも解決しようとした問題にぶち当たってしまうんだ。

D: 反対側からコメントすると、HTMLとCSSの価値を証明する責任はディベロッパーにあるんだ。最近盛んに言われることに「プログレッシブ・エンハンスメント」がある。でも言っている本人が意味を分かっていないし、なぜプログレッシブエンハンスメントが登場したのかも知らない。エリックが言ったCSS問題と根は同じだと思う。「より多くの人がWebサイトを使えるようにする」これがプログレッシブエンハンスメントさ。プログレッシブエンハンスメントは手段の一つで有るはずなのに、ゴールになってしまうこと。これは僕達が解決しなくてはいけない問題なのさ。

僕達は、業界外の人にも通じるように、伝え方のレトリックを変えなくてはいけない。業界全体ではその方向に向かっているとは思うけど、僕達の貢献は十分ではない。僕達が貢献する方法の一つは「ターゲットとする人が分かる言葉は何だろう？」と問うこと。 アクセスビリティも曖昧な流行り言葉になっているので「もっと沢山の人がこのサイトを使うことが出来たら、もっと沢山の人にコンテンツを届けることが出来ますよね」というべきなんだ。この方が刺さる。一般の人に分かる言葉で話すというのを責任の一つと認識すべきだと思う「HTMLとCSSの価値はここにある。それはユーザーにこういう利益をもたらすものなんだ」と。

J: すばらしいまとめコメントですね。それ以上のまとめコメントは思いつきません。ありがとうございました。

翻訳：宮崎洋史（エイクエント）