フルスタック化しないと生き残れないのか？日本語版（2/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（バックエンドディベロッパー）

HTMLとCSSは軽視されているのか？

J: そうだね。実際にそうすることは重要だよね。僕が興味深いと思ったのは、HTMLとCSSは簡単と思われているけど、エリックが書いたCSS教本は1100ページもあるよね。

E: およそ1100ページだね。僕は1088ページと言ってきたけど表紙と裏表紙を除くと1086ページかな。

J: ということはCSSは修得するのが結構難しい言語に見えるのだけれど、その点について話してくれないか？

E: この第四版は実はCSSの全ての面をカバーしているわけではないんだ。あまりにも細分化が進んでいる点はあえて触れていない。きっとみんなが驚くのはマルチカラムの実装方法。この本でこれに触れなかったのは、ブラウザーによってレンダリングが異なってくるし、スペックもどうせすぐ変わるから。そうしたら更に10ページ位加えることになると思う。

CSSについては長い間こう言われてきた「学ぶのは数分ですむけれど、習熟するには長い時間がかかる」と。そうはいっても、CSSには膨大な数のプロパティがあり、それぞれがどう関係しているか理解しないとマスターにはなれない。だからたくさんの本が出版されているじゃないか。もしレイアウトに関するバグに出くわしたら、それはプロパティがある組み合わせで使われるケースが想定されていなかったからさ。そんなバグに出くわした時は、FirefoxやWebKitの開発チームに知らせることが超重要なんだよね。どんなバグであれ、現場レベルのバグの全てを開発段階で想定するのは不可能だから。CSSは一般的に思われるよりずっと複雑だし、同時にパワフルなんだよ。

HTMLも同じだと思う。皆、HTMLは必要に応じて学ぶというスタイルで学んでいると思う。だから、HTMLの可能性に気づいていないんだ。特定のフレームワークを使わなくてはいけない状況に置かれて、初めて、データアトリビュートに気づくディベロッパーがほとんどだと思う。その場合でも、そのフレームワーク中でのデータアトリビュート活用法に過ぎない。本来それによって可能になることはもっと多いのにね。

他の例を話そう。input typeには一般的に知られているよりも多くのモノを指定できる。色々問題があるのは知っているけど、カラーピッカーinputはその一例さ。文字通りカラーを選べるinput typeで、理屈ではピッカーをクリックするとパレットが現れ、ホイールやスライダーを使って色を指定できるあれさ。ブラウザーによってサポート状況が微妙なんだけど、それを知っている開発者は少ないよね。HTML は一見シンプルでも奥は深いのさ。

HTMLとCSSが、伝統的プログラマーから甘く見られているのには理由があると思っている。それはHTMLとCSSは、ループ構造や条件分岐などを実現できないからさ。ま、CSSにはメディアクエリやフィーチャークエリがあるのだけど、プログラム言語としては粗雑なものにすぎない。「三つの値をこの組み合わせで評価して全てTureなら次の動作をしろ…」なんて命令は出来ないのさ。そういう意味ではプログラム言語ではないのだけど、別の見方をするとスゴイ面もある。HTMLとCSSは文法を少しくらい間違えても大丈夫なんだ。

タグを閉じ忘れても何かしらは表示されるなんてスゴイことじゃないか。他のプログラム言語では、JSもそうだけど、こうはいかない。カッコを1つ忘れたら、全て動かなくなる。XMLも同じさ。

BEDとFEDの微妙な関係…

J: なるほど。HTMLもCSSも完成して、かつ、奥が深いということだよね。でも、ならばなぜこんな質問が届くのだろうか？このウェビナーの参加者から寄せられたものだけど「なぜ未だに、FEDとBEDの関係は微妙なのでしょう？私は伝統的タイプの組織に所属していますが、いつもバックエンドの人がリーダーシップを発揮し、権限を持って決定を下します」。この質問は、エンジニア文化とデザイナー文化の違いに関係しているようで、興味深いと思う。両者のパワーバランスにはお金が関係しているのだろうか？

E: この問題を引き起こしているのは組織の歴史に関することだと思うな。FEDとBED、チームが出来た時にどちらが大きかったのかとか、どちがより会社へ利益をもたらしたのかとか。BEDチームが会社に対してXXXXドルをもたらしたと実証できるなら、BEDが優勢になると思う。

話をひっくり返してみよう。もしそれがデザインエージェンシーなら、BEDはサポート役で、FEDが会話をリードするはず。でもこれは僕の推測なので、ダンの意見を訊いてみたい。

D: エリックの言うとおりだと思うよ。FEDとBEDは、重要とみなす事が異なるんだ。残念なことに、FEDがそれに命を捧げたい思う（ほど重要な）ことは、他の人には理解が出来ない。僕は、セクションタグを使うべきか、アーティクルタグを使うべきかという議論を各所で投げかけてきたけど、他の人にとっては「それはいいとして、ログインできるの？」という反応になってしまう。

FEDが重要とみなすことは、ビジネスに関わる他の人にとっては重要性を感じられない場合が多い。実際はビジネスに関係してるのだけど、とても遠くに感じられてしまうことなんだ。もしユーザーがログインできなければどんなタグを使ってるかは関係ない。OLタグかULタグかなんてどうでもよい。セマンテック云々なんてビジネスの必須条件ではないし、だからFEDは自説を主張するのをためらってしまうんだ。そして「ビジネスは重要じゃないんだ、重要なのは、正しくマークアップすること」と言ったり「僕はCSSをBEMではなくOOCSSで書く」と言ったりする。そういうのはプロセス改善には重要なんだけど、一般の人はそれを分からないし、FEDは伝えるのがうまくない。だから「そんな些細なこと気にしないで、ログインできるようになったの？」なんて返されてしまうんだ。BEDの仕事は分かりやすくて、FEDのはそうではないんだ。

J: これは企業文化にも関係したことだと思う。BED重視はトップダウンで下りてくる考えだよね。過去10〜15年、アップルの成功を受けて、デザインの重要性がひろく語られるようになりそれを真似する企業が、程度の差はあれ、増えてきているのに、不思議だとと思う。デザイナー、UX専門家、コンテンツ戦略家などの採用は単なるリップサービスに過ぎないようにも見える。

けれどもやっぱりそれに反する流れがあり、注目をあつめるのはJS。ダンがこのウェビナー前にツイートした「In a world where JavaScript is kind of king, there is this interesting conflict happening.」なんてのはそれを表しているよね。業界全体のトレンドであり、ビジネスディシジョンに関することなんだと思う。

ここでちょっと思考実験をしてみたい。もしWebアプリを開発するためにチームを組むことになったら、どんな人を探すのだろう？どんな役職がそのチームには重要だろうか？

D: 複雑な問題だね。プロジェクトには変数がたくさんあるし、時間の経過と共に変化し、プロジェクト毎、企業ごとににまちまちだし。変数の1つは、そのプロジェクトをすすめるスピードと、インハウスの専門知識、コンサルタントの専門知識、そしてビジネスに重要な事の割合かな。

1つの例はアクセスビリティで、その欠如で訴訟を起こされるまでは、その重要性は理解されない。アクセスビリティの重要性はいつも訴えるべきなんだけど、人はそれに気づかない。僕は、チームを作るときにはまずプロジェクトについて考えるようにしている。プロジェクトにとって本当に重要なのは何かを。だから、クライアントと話す時はいつも、彼らにとって何が重要かを訊くようにしいているんだ。僕は幾つものプロジェクトを手がけてきたプロとして、僕のアイデアを出し、メンバーにもアイデアを出してもらい「お客さんはこれらが重要とは思わないかもしれないし、考えたことさえないことかもしれない。でも僕たちはとても重要と思う。だから話を聞いて欲しいし、これを学びのプロセスの一部と思って欲しい」なんて伝えるようにしている。

AngularでいくべきかReactでいくべきかあるいは他のフレームワークで行くべきか。それがチームにとってどんな意味を持つのか？それがユーザから見たパフォーマンスにどんな意味を持つのか？哲学というより実用性に重きを置くけど、これは哲学とプラグマティズムを両端に持つスペクトラムで、そのバランスはプロジェクト毎に異なるものなんだ。

E: ちょっと前の質問に関連付けて話してみたい。FEDが提供できることの1つにページパフォーマンスがある。この点についての理解が深まっているように感じているよ。別の言い方をすると「どれだけ速くサーバーから情報を取り出し、ユーザーに届けるか、表示するか」ということ。具体的な評価指標がなんであれ、ページパフォーマンスの重要性は認識されつつあるな。

Etsyのエンジニアチームどんなことをしているか聞いたことがある。今も状況は変わっていないはず。彼らは異なるネットワーク環境下でページスピードテストを定期的に行い、その結果を、部屋の壁にモニターを掛けて、文字通り、モニターしているんだよんね。「アメリカのブロードバンド、アメリカのダイヤルアップ。そしてこれは欧州、そして豪州…」。豪州は他国へのネットワークが遅いので「かわいそうなオーストラリア」とあだ名が付いていたりする。

彼らはページロードスピードを録画してたりもする。「昨晩、このページはブロードバンドで2秒、ちょっと遅いブロードバンドや3Gでは6秒…」実際はダイアルアップは測っていないんだけど「…オーストラリアは9秒」。 社員は朝出勤すると「なぜレンダリングに突然5秒もかかるようになったのだろう？」と考え始める。ネットワークスピードには関係がないはずだから、昨晩自分たちがしたことに起因しているはず。巨大イメージをアップしたっけ？間違えて超ハイレゾの画像をアップしたっけ？などと。

BEDは、サーバー内のモノを速く出すこと、FEDはそれらが速くレンダリングされることを担当しているんだ。どれだけ速くレンダリングされるかは、FEDにとって実際に計測できる指標だと思う。今そこに注目していないなら、そうすべきだろう。

J: それは冒頭で話題にしたブラッドの記事に関係していると思う「フロントエンドのユーザー体験に責任を持つのは誰なのか」。僕は、ここにある種の危険があると思っている。それはJSを過剰に評価をしてしまうことさ。なぜなら、JSは学ぶのに時間がかかるから。フレームワークについても、AngularにしろReactにしろ最先端について行きたいと思ったら、それ自体が仕事になるほど。それは僕が保証する。だからエイクエントではNodeのクラスをやっているわけで、それが現在のWeb業界なんだよね。

僕が恐れているのはJSとフレームワーク知識に過剰な価値が置かれてしまうことと、それに伴ってUIへの関心やページパフォーマンスへの配慮が薄れてしまうこと。

ダン、以前話した時に、バックエンドだけに集中するメンバーがいたら、そのメンバーはプロジェクトにとっては害だと言っていたよね？ その点についてもう少し話してもらえないかな？

理想的なチーム構成

D: これまで僕が関わったプロジェクトでうまく行かなかったものを思い出してみると最も害が大きいのは「サイロ化」さ。プロセス間での仕事の受け渡しがうまく行かず「これは別の誰かがやると思っていた」とやり残しが出てしまう。

サイロ化を防ぐには、役割をオーバーラップさせるのが効くと思う。役割をクッキリハッキリ分けるのではなくね。よくあるのは、エンジニアが「ログイン機能を実装したよ」という。僕が、ユーザーがパスワードを確認したいという要望を持っていると伝えても「ログインを可能にするフレームワークを使っているんだ」と返事が来る。そのエンジニアが、責任を負いたくない、あるいは説明もしたくないというタイプの場合「自分の仕事はした。これ以上俺に何をしろと？」なんて返事が来るんだ。こういうメンバーは有害だよね。

もし皆さんの組織文化がこのようなものだったら、その有害性に気づかずにチームを率いているってことだね。これはBEDに特有の現象というわけではない。 全ての役割に関わることなんだ。デザイナーもディベロッパーも、コンテンツストラテジストも、IAも。もしエンジニアリング的構造に合わないサイト構造が造られたら、それって問題だよね。BEDだけでも、FEDだけでもなく、サイロ化はそれはどこで発生しようが問題なんだ。

僕がよく使うツールはRACIメトリクスというもの。Rはresposibility、Aはaccouantability、Cはconsulted、Iはinformedを表し、プロジェクト開始時に、メンバーの全員が、最低1つは、数多くのタスクでこれらの役割を追うのかをきめるんだ。

FEDはIAについて「responsible」になる必要はないけど「informed」される必要はある、というようにね。「え、そんなことが起こっていたとは知らなかった」ということはあってはいけないと思う。それはチームへのエンゲージが足りない状態で、大事なことが「割れ目」からこぼれ落ちてしまうから。サイロ化を防ぐのが問題解決の第一歩だと思う。

J: 面白いしクールなやり方だね。そのマトリクスは自分で考えたの？それとも既にほかで言われていたこと？

D: これは10年以上前から存在するマネジメント手法の1つだよ。作ったのは他の誰かで、たまたまそれを見つけた日「これは使える！」と思ったんだ。

J: なるほど。ここで、次の質問を見てみよう。「昨今の労働市場で成功するために、フロントエンドデザイナーとして最低限知っておくべきテクニカル面は何ですか？」これはゼネラルな質問だね。「デザイナーはXXを知っておくべきか」というのは。技術的基盤を知っておくのは重要だけれど、Nodeサーバーの最新状況を知っておくことは、多分違う。

ここで僕達が考えるべきことは、この質問にどう答えるべきかということではないかな。エリック、君は、FEDこそオーナーシップを持ち、ハッキリ言うことが重要と説いていたはず。他にも重要な事はあるかな？

E: フルスタック症候群が出てくるのはココなんだよね。他に何が必要？という問に対しては本当にたくさんの答えがあるから。

J: エリック、君がやってきた仕事は人の感情に配慮していて、現実世界のデザインを理解しようとしているようにみえる。それが、エンジニアの採用にどう関連しているのかな？バックエンドの技術者を採用することは、UX人材を犠牲にすることを意味しているのかな？最終的にはみなチームでプレイするわけなんだけど。

E: それは組織としてのフルスタック症候群問題だね。組織としてスタックをカバーする際、どのようにするのか？XYZのスキルをもった人を雇うということは、ABCのスキルを持った人を雇わないということだよね。願わくばABCスキルを持った人もどこかの時点で雇えればよいのだけど、人件費予算がなくなるわけだ。つまり組織の資金は限られているから、選択を迫られるわけさ。

個人的にはできるだけ多様なチームにすることが大事と思う。ダンも言ったように、なるべくスキルをオーバーラップさせるのがヨイのではないかな。多様というのは、スキルについていえば、6人のNodeディベロッパーを雇うより、数人のNodeディベロッパーと数人のFEDそしてUXとIA専門家を各一人といった具合。当たり前に聞こえると思うけど。スキル以外の面、たとえば、教育や文化、育ち、年齢、経験も多様なほうがよい。僕は採用予算を管理しているわけではないのである意味気楽に言っているのだけどね。多様性を増したいのであれば、当該分野について今は知らなくても、学ぶ力のある人を採用するのがよいと思う。なぜなら、経験豊かな先輩に助けてもらえる状況においていは、学ぶことに貪欲で学ぶ能力が高い人のほうが、その道一筋30年で固まってしまった人よりも、チームに貢献してくれるからさ。

J: 繰り返しになるけれど、もし最先端のフレームワークについて行く必要があるとなったら、燃え尽き症候群の問題にも突き当たるだろうね。ダンが言うように、隙間からこぼれ落ちることはたくさんあると思う。採用担当者や、チームマネージャがこのウェビナーを聞いているはずなんだけど、チームメンバーの多様性が重要という点は繰り返して訴えたい。スキルの多様性は更に重要で、長い目で見ると、それによってプロジェクトがヘルシーになるわけだから。

E: そして、僕が読んだリサーチによると、チームの生産性も上がるんだよね。

J: そう。そしてダンが教えてくれた「What Google Learned From Its Quest to Build the Perfect Team」は本当によい研究だね

（後編へ続く）