【翻訳】デザインエンジニアリング

Design Engineering

Jonathan Snook Original:Design Engineering)by Jonathan Snook

JavaScriptだけがフロントエンド開発ではない。それはデザインとディベロップメントの技術が人種のるつぼのように融合したものである。それはアクセシブルなUIを実装するためであり、Web標準を受け入れるものである。 — Matt Hill

Shopify Adminの開発に関して言えば、最近まで2つの専門職、つまりデザイナーとエンジニアを受け入れていた。今では3つめの専門職がある、しかしながらそれが確かなものとして認識されるまで時間がかかった、フロントエンドデベロッパーである。フロントエンドデベロッパーのスキルはデザインとエンジニアリング両方にまたがっている。これまでクオリティの高いフロントエンドコードをフロントエンドデベロッパーの助けもなしに書けるデザイナーを雇えて、私たちは非常にラッキーだった。

フロントエンドデベロッパーの精鋭チームの作り方に関してはいくつかの異論がある。『もし彼らがデベロッパーであるのなら、彼らはエンジニアチームに所属しているだろう。』つまり逆を言えば、バックエンドデベロッパーはフロントエンドデベロッパーでもあるということだ。Shopifyは彼らデベロッパーに対してフルスタックであることを期待している。しかし、フロントエンド開発がディベロップメントであるのなら、なぜ私たちはデザイナーにもそれを求めないのか?

私たちはフロントエンド開発バックエンド開発という用語を使うが、フロントエンドデベロッパーが開発に着手する段階とバックエンドデベロッパーが開発を終える段階を多くの人がよく勘違いしていることが問題だ。

開発プロセスを考えてみれば、そこには3つの段階、デザイン(Design)、デザイン実装(Design Implementation)、アプリケーション開発(Application Development)が存在する。

Spectrum of Application Development

デザイン

デザイナーは多くのツールを使い、彼らはデザインがどのように実装されているか理解すべきだが、HTML/CSS、JavaScriptを使って彼ら自身のデザインを実装する必要はない(ちょうど印刷デザイナーに印刷を任せる必要がないのと同じようにだ。なぜなら私たちはプリンターを持っているから)。デザイナーが複数のデザインの試行錯誤に集中できる、もしくはデザイン的問題に本格的に取り組むことができることはアドバンテージであり、結果としてデザイン実装(デザインをプロダクト前段階のHTML/CSSに落としこむこと)に集中する必要性はない。

デザイナーはコードの書き方を知るべきと私は強く信じているが、組織の拡大によっては専門性を高める必要もあると述べたい。

アプリケーション開発

アプリケーション開発とはインターフェースとサービングをベストの方法で繋げることである。私たちはクライアントサイドMVCもしくはサーバーサイドレンダリングをどちらを使うべきか?キャッシュもしくはストレージシステムとは何か?データモデルとは何か?これらの問いはHTTPの境界線を超えた問題であり、どちらか片方の領域だけで考えるべきことではない。

OOPとプロトタイプ継承を理解することは、複数ブラウザでのCSSプロパティのレンダリングと、多様な入力方法、マウス、キーボード、ジェスチャーまたはスクリーンリーダーにアクセシブルでありつつ、さまざまな携帯端末、タブレット、またはデスクトップでベストな実装の仕方を理解することとは違うスキルセットを必要とする。

デザイン実装

デザインを実装することはHTML/CSSといくぶんかのJavaScriptを書くことを意味し、さまざまなデザイン上の制約、つまり異なるブラウザ、異なるサイズ、異なる解像度、異なるインタラクションの方法(マウス、キーボード、ジェスチャー、スクリーンリーダー)を克服しデザインを確かなものとすることである。またそれはUX検証のためにプロトタイプを作成することでもある。これらの領域を担当するものはデザイナーである必要はないが、デザイン思考を持っており、かつデベロッパーである必要はないが、テクニカル思考を持っている。

この役割の人たちはデザインとエンジニアリングの間に立ち、見事な架け橋を作ってくれる。私はよくこの人たちのことを『デザインの調停者(arbiters of design)』と呼んでいる。彼らはそのデザインが実装可能かどうか、制約がどんなものか教えてくれたり、可能な限り多くのユーザーが使いやすいインターフェースと一貫性を構築するために手助けをしてくれる。彼らはビジュアルワークをコードに変換してくれる。彼らはデベロッパーのマインドセットであるレンダリングのパフォーマンスや、読み込み時間に関心があり、ハイパフォーマンスなフロントエンドを実装するためにエンジニアリングをもちいて解決してくれる。

役割

これらの境界を超えて仕事ができるジェネラリストとそれぞれのセクションで専門性を発揮できるスペシャリスト両方を揃えることが重要である。ほんのすこし前まで、Shopify Admin内で、私たちはデザイン実装を担当する者の育成に力を入れてこなかった。この理由は、私たちがスペシャリストを超えたジェネラリストを求めているためであり、デザイナーはデザインに集中するべきとと考えているためだ。

彼らをなんと呼べばいいのか?

フロントエンドはデザインエンジニアリングと言い換えることができるか? — Dan Donald

私たちはこの役割の人をなんと呼ぶべきか議論した。デザインインプリメンター(Design Implementors)はあまりしっくりこない。デザインエンジニア(Design Engineers)と呼ぼうと私たちはほぼ決めていたが、やはりそれではいささか『ディズニー』すぎるのだ。

私たちは既にShopify.comを担当する優秀なフロントエンドデベロッパーチームをトロントとほかの進行中のプロジェクトに持っていた。彼らはどちらかと言うとバックエンド開発寄りだったため、私たちのそれとはすこしばかり違っていた。

結局、私たちはフロントエンドデベロッパー(Front-End Developer)に戻ってきた。

彼らが担当する領域の端にも関わらず、それは一般的であり、すべてのフロントエンダーを内包する。

産業として、私たちがこれまでほかのテクノロジーで見てきたように私たちはデザイン・コードの設計においてより専門性を高める方向にシフトしていく傾向があり、プロダクトをスケールし、大規模なコードベースと大人数でのサイト開発においての新しいワークフローを見守り続けている。


ShopifyのWebデベロッパー・デザイナーであり、SMACSSの提唱者でもあるJonathan Snook氏の記事。翻訳にあたっては氏の同意を得ている。

個人的には自分の肩書に関してはあまり興味はないが、名前があやふやなものに対して世間一般の認知は得られない。どういったものかよくわからないものにはお金は回らない。かける労力に対して見合った見返りがなければ理不尽であろう。もしフロントエンド周りで仕事をしているのであれば、自分たちの職種を定義し主張することが存在価値を認めさせる一歩だと思う。