HTMLもCSSも完成して、かつ、奥が深いということだよね。こんな質問が届くのだろうか?このウェビナーの参加者から寄せられたものだけど「なぜ未だに、FEDとBEDの関係は微妙なのでしょう?私は伝統的タイプの組織に所属していますが、いつもバックエンドの人がリーダーシップを発揮し、権限を持って決定を下します」。この質問は、エンジニア文化とデザイナー文化の違いに関係しているようで、興味深いと思う。この問題を引き起こしているのは組織の歴史に関することだと思うな。FEDとBED、チームが出来た時にどちらが大きかったのかとか、どちがより会社へ利益をもたらしたのかとか。BEDチームが会社に対してXXXXドルをもたらしたと実証できるなら、BEDが優勢になると思う。話をひっくり返してみよう。それがデザインエージェンシーなら、BEDはサポート役で、FEDが会話をリードするはず。これは僕の推測なので、ダンの意見を訊いてみたい。エリックの言うとおりだと思うよ。FEDとBEDは、重要とみなす事が異なるんだ。残念なことに、FEDがそれに命を捧げたい思う(ほど重要な)ことは、他の人には理解が出来ない。僕は、セクションタグを使うべきか、アーティクルタグを使うべきかという議論を各所で投げかけてきたけど、他の人にとっては「それはいいとして、ログインできるの?」という反応になってしまう。FEDが重要とみなすことは、ビジネスに関わる他の人にとっては重要性を感じられない場合が多い。実際はビジネスに関係してるのだけど、とても遠くに感じられてしまうことなんだ。ユーザーがログインできなければどんなタグを使ってるかは関係ない。OLタグかULタグかなんてどうでもよい。セマンテック云々なんてビジネスの必須条件ではないし、だからFEDは自説を主張するのをためらってしまうんだ。「ビジネスは重要じゃないんだ、重要なのは、正しくマークアップすること」と言ったり「僕はCSSをBEMではなくOOCSSで書く」と言ったりする。いうのはプロセス改善には重要なんだけど、一般の人はそれを分からないし、FEDは伝えるのがうまくない。「そんな些細なこと気にしないで、ログインできるようになったの?」なんて返されてしまうんだ。BEDの仕事は分かりやすくて、FEDのはそうではないんだ。これは企業文化にも関係したことだと思う。BED重視はトップダウンで下りてくる考えだよね。過去10〜15年、アップルの成功を受けて、デザインの重要性がひろく語られるようになりそれを真似する企業が、程度の差はあれ、増えてきているのに、不思議だとと思う。デザイナー、UX専門家、コンテンツ戦略家などの採用は単なるリップサービスに過ぎないようにも見える。それに反する流れがあり、注目をあつめるのはJS。happening.」なんてのはそれを表しているよね。業界全体のトレンドであり、ビジネスディシジョンに関することなんだと思う。ここでちょっと思考実験をしてみたい。プロジェクトには変数がたくさんあるし、時間の経過と共に変化し、プロジェクト毎、企業ごとににまちまちだし。変数の1つは、そのプロジェクトをすすめるスピードと、インハウスの専門知識、コンサルタントの専門知識、そしてビジネスに重要な事の割合かな。1つの例はアクセスビリティで、その欠如で訴訟を起こされるまでは、その重要性は理解されない。アクセスビリティの重要性はいつも訴えるべきなんだけど、人はそれに気づかない。僕は、チームを作るときにはまずプロジェクトについて考えるようにしている。プロジェクトにとって本当に重要なのは何かを。クライアントと話す時はいつも、彼らにとって何が重要かを訊くようにしいているんだ。僕は幾つものプロジェクトを手がけてきたプロとして、僕のアイデアを出し、メンバーにもアイデアを出してもらい「お客さんはこれらが重要とは思わないかもしれないし、考えたことさえないことかもしれない。僕たちはとても重要と思う。話を聞いて欲しいし、これを学びのプロセスの一部と思って欲しい」なんて伝えるようにしている。AngularでいくべきかReactでいくべきかあるいは他のフレームワークで行くべきか。それがチームにとってどんな意味を持つのか?それがユーザから見たパフォーマンスにどんな意味を持つのか?哲学というより実用性に重きを置くけど、これは哲学とプラグマティズムを両端に持つスペクトラムで、そのバランスはプロジェクト毎に異なるものなんだ。前の質問に関連付けて話してみたい。FEDが提供できることの1つにページパフォーマンスがある。この点についての理解が深まっているように感じているよ。別の言い方をすると「どれだけ速くサーバーから情報を取り出し、ユーザーに届けるか、表示するか」ということ。具体的な評価指標がなんであれ、ページパフォーマンスの重要性は認識されつつあるな。Etsyのエンジニアチームどんなことをしているか聞いたことがある。今も状況は変わっていないはず。彼らは異なるネットワーク環境下でページスピードテストを定期的に行い、その結果を、部屋の壁にモニターを掛けて、文字通り、モニターしているんだよんね。「アメリカのブロードバンド、アメリカのダイヤルアップ。これは欧州、そして豪州...」。豪州は他国へのネットワークが遅いので「かわいそうなオーストラリア」とあだ名が付いていたりする。彼らはページロードスピードを録画してたりもする。「昨晩、このページはブロードバンドで2秒、ちょっと遅いブロードバンドや3Gでは6秒...」実際はダイアルアップは測っていないんだけど「...オーストラリアは9秒」。社員は朝出勤すると「なぜレンダリングに突然5秒もかかるようになったのだろう?」と考え始める。ネットワークスピードには関係がないはずだから、昨晩自分たちがしたことに起因しているはず。巨大イメージをアップしたっけ?間違えて超ハイレゾの画像をアップしたっけ?などと。BEDは、サーバー内のモノを速く出すこと、FEDはそれらが速くレンダリングされることを担当しているんだ。どれだけ速くレンダリングされるかは、FEDにとって実際に計測できる指標だと思う。今そこに注目していないなら、そうすべきだろう。それは冒頭で話題にしたブラッドの記事に関係していると思う「フロントエンドのユーザー体験に責任を持つのは誰なのか」。僕は、ここにある種の危険があると思っている。それはJSを過剰に評価をしてしまうことさ。JSは学ぶのに時間がかかるから。フレームワークについても、AngularにしろReactにしろ最先端について行きたいと思ったら、それ自体が仕事になるほど。エイクエントではNodeのクラスをやっているわけで、それが現在のWeb業界なんだよね。僕が恐れているのはJSとフレームワーク知識に過剰な価値が置かれてしまうことと、それに伴ってUIへの関心やページパフォーマンスへの配慮が薄れてしまうこと。これまで僕が関わったプロジェクトでうまく行かなかったものを思い出してみると最も害が大きいのは「サイロ化」さ。プロセス間での仕事の受け渡しがうまく行かず「これは別の誰かがやると思っていた」とやり残しが出てしまう。サイロ化を防ぐには、役割をオーバーラップさせるのが効くと思う。役割をクッキリハッキリ分けるのではなくね。あるのは、エンジニアが「ログイン機能を実装したよ」という。僕が、ユーザーがパスワードを確認したいという要望を持っていると伝えても「ログインを可能にするフレームワークを使っているんだ」と返事が来る。そのエンジニアが、責任を負いたくない、あるいは説明もしたくないというタイプの場合「自分の仕事はした。これ以上俺に何をしろと?」なんて返事が来るんだ。いうメンバーは有害だよね。皆さんの組織文化がこのようなものだったら、その有害性に気づかずにチームを率いているってことだね。これはBEDに特有の現象というわけではない。全ての役割に関わることなんだ。デザイナーもディベロッパーも、コンテンツストラテジストも、IAも。エンジニアリング的構造に合わないサイト構造が造られたら、それって問題だよね。BEDだけでも、FEDだけでもなく、サイロ化はそれはどこで発生しようが問題なんだ。僕がよく使うツールはRACIメトリクスというもの。Rはresposibility、Aはaccouantability、Cはconsulted、Iはinformedを表し、プロジェクト開始時に、メンバーの全員が、最低1つは、数多くのタスクでこれらの役割を追うのかをきめるんだ。FEDはIAについて「responsible」になる必要はないけど「informed」される必要はある、というようにね。「え、そんなことが起こっていたとは知らなかった」ということはあってはいけないと思う。それはチームへのエンゲージが足りない状態で、大事なことが「割れ目」からこぼれ落ちてしまうから。サイロ化を防ぐのが問題解決の第一歩だと思う。面白いしクールなやり方だね。これは10年以上前から存在するマネジメント手法の1つだよ。作ったのは他の誰かで、たまたまそれを見つけた日「これは使える!」と思ったんだ。ここで、次の質問を見てみよう。「昨今の労働市場で成功するために、フロントエンドデザイナーとして最低限知っておくべきテクニカル面は何ですか?」これはゼネラルな質問だね。「デザイナーはXXを知っておくべきか」というのは。技術的基盤を知っておくのは重要だけれど、Nodeサーバーの最新状況を知っておくことは、多分違う。ここで僕達が考えるべきことは、この質問にどう答えるべきかということではないかな。エリック、君は、FEDこそオーナーシップを持ち、ハッキリ言うことが重要と説いていたはず。フルスタック症候群が出てくるのはココなんだよね。他に何が必要?という問に対しては本当にたくさんの答えがあるから。エリック、君がやってきた仕事は人の感情に配慮していて、現実世界のデザインを理解しようとしているようにみえる。それが、エンジニアの採用にどう関連しているのかな?バックエンドの技術者を採用することは、UX人材を犠牲にすることを意味しているのかな?最終的にはみなチームでプレイするわけなんだけど。それは組織としてのフルスタック症候群問題だね。組織としてスタックをカバーする際、どのようにするのか?XYZのスキルをもった人を雇うということは、ABCのスキルを持った人を雇わないということだよね。願わくばABCスキルを持った人もどこかの時点で雇えればよいのだけど、人件費予算がなくなるわけだ。組織の資金は限られているから、選択を迫られるわけさ。個人的にはできるだけ多様なチームにすることが大事と思う。ダンも言ったように、なるべくスキルをオーバーラップさせるのがヨイのではないかな。多様というのは、スキルについていえば、6人のNodeディベロッパーを雇うより、数人のNodeディベロッパーと数人のFEDそしてUXとIA専門家を各一人といった具合。当たり前に聞こえると思うけど。スキル以外の面、たとえば、教育や文化、育ち、年齢、経験も多様なほうがよい。僕は採用予算を管理しているわけではないのである意味気楽に言っているのだけどね。多様性を増したいのであれば、当該分野について今は知らなくても、学ぶ力のある人を採用するのがよいと思う。経験豊かな先輩に助けてもらえる状況においていは、学ぶことに貪欲で学ぶ能力が高い人のほうが、その道一筋30年で固まってしまった人よりも、チームに貢献してくれるからさ。繰り返しになるけれど、もし最先端のフレームワークについて行く必要があるとなったら、燃え尽き症候群の問題にも突き当たるだろうね。ダンが言うように、隙間からこぼれ落ちることはたくさんあると思う。採用担当者や、チームマネージャがこのウェビナーを聞いているはずなんだけど、チームメンバーの多様性が重要という点は繰り返して訴えたい。スキルの多様性は更に重要で、長い目で見ると、それによってプロジェクトがヘルシーになるわけだから。僕が読んだリサーチによると、チームの生産性も上がるんだよね。