ゆれるデザインエンジニアの輪郭

こんにちは、estie デザインエンジニアの@hikrrrです。

近ごろは “デザインエンジニア” についてのトピック・議論をTwitterなどで観測することが増え、過渡期だな〜と楽しい気分になります。その役割の厳格な定義づけはさておき、そこにデザインとエンジニアリングの要素が入り混じることは認めてよさそうです。

ただ、その2つへの関心を持ちあわせていると「どこを目指したいのか」「何を成せるのか」を見失いませんか？働くうえで志向と実務が一致しないケースはめずらしくないはず。しかし、私はそうした環境にいて苦しかった覚えがあります（上流からUIデザインが降りてくるような案件は特に歯痒かった）。

フロントエンドエンジニアとしてキャリアに迷っている方は、本記事で説明するデザインエンジニアを1つのロールモデルとしてご参考いただければ嬉しいです。

デザインエンジニアへの道のり

専業でエンジニア・デザイナーをやっている人たちと比べてしまうと、どうしたって器用貧乏感が……！どちらもやりたいのに人生の時間が圧倒的に足りない……！異なる志向がせめぎ合い、私自身も悩むことはあります。

デザインとエンジニアリングの交わりに興味を持ったのは大学時代でした。「この課題はこうしたサービスにより解決すべきだろう」「そのとき人とソフトウェアはこう関わるべきだろう」といったビジョンをもとに仮説を立て、それを検証するためのプロトタイプを開発していました。人に重きを置いており、自ずとUIへの関心は高まっていきます。そしてユーザへ価値を届けることについて問うた結果、実際に動かすための技術にも興味が湧きました。

こうして抱いたデザインエンジニア（のようなもの）への志向は、現在のキャリアにてかなり的確に実現されていると感じています。時にはｶｲﾊﾂ… ﾅﾆﾓﾜｶﾗﾅｲ……と打ちひしがれることもありますが、その気持ちに向き合ってこそ目指したいデザインエンジニア像が明確になるのかもしれません。模索のプロセスも含め、いまの仕事を楽しめています。

デザイニングへの招待

フロントエンドエンジニアのみなさんにとってデザイナーが近い存在であることは言うまでもないはず。一方、事業上の Why に対する距離感はいかがでしょうか？もし遠くに感じることがあれば、プロダクト側でその距離を縮めてくれるのが “デザイニング” であると私は考えています。

持論ですが、デザインの1つの効能は「ものの見方を変えること」でしょう。それが意味するのは、サービスや製品を通してユーザの見る世界へ変化をもたらすことです。障害そのものを取り除くのはむずかしくても、その性質や対処の角度は変えられます。そのための営みこそデザイニング——ユーザの世界へ入り込み・現状を整理し・解法を見出すことに違いありません。

「プロダクトがなぜ必要とされるのか」「事業としてどのように成立するのか」について、解像度を高めたうえで開発することに意義を感じています（純粋に楽しい）。とはいえ、ジェネラリストやオールラウンダーを志すわけでなく……。デザインが持つ多様で広範な性質そのものを私は体現したいのです。

デザインエンジニアリング・スキルの探求

How の話に移りましょう。以前、デザインとエンジニアリングの融けるところと題してブログを書きました。Alan Cooper氏により提唱された、ソフトウェアデザインが対象とする3つのモデルを参照しています。

Mental Models: 脳内モデル。ユーザの考えるシステムの動き
Represented Models: 表現モデル。UIとして目に見えるシステムの動き（他2つのモデルを媒介する）
Implementation Models: 実装モデル。実際のシステムの動き

脳内モデルと表現モデルとが近くなるほど使いやすいシステムになります。実際にどう動いているかについて、大半のユーザの関心は高くありません。一方で、実装モデルと表現モデルを ”開発プロセスとして” 近づけることの効果は大きいと考えています。

いま思えば、私のこの考えは “Form follows function: 形態は機能に従う“ に通ずるものかもしれません。この言葉は進化論、そして建築や工業デザインに由来するものです（詳しくはこちら）。一例としてメッセージ送信処理のトリガーは、ボタンの形態をとることが一般的と思われます。しかし送信機能を果たすのが目的ですから（話が飛躍しますが）その手段はジェスチャーやボイスコントロールといった無形でもよいわけです。

ユーザや文脈に適する操作のかたちは何なのか？を見定める過程がUIにおけるデザイニングと言えるでしょう。システムの構成や処理の流れを理解したうえで、例えば楽観的更新——ユーザの認知特性に沿わない箇所はインターフェイスを擬装するのっておもしろいですよ！

そのためには当然、エンジニアリングとデザイニングそれぞれの修得が必要でしょう。2つを高めるのと同時に、掛け合わせて1つのスキルとして発揮することを私は追究しています。先のブログで綴った通り、きっとそこで軸になるのはインタラクションデザインの考え方です。

estie におけるデザインエンジニアの働き方

端的に言って、デザインエンジニアに求められるのは「システムとしてもユーザにとっても都合のよい製品をつくる」ことだと思います。それは事業のどんなフェーズでも変わらないはずです。ただ、不確実性が高い場合は、検証の手段を素早く的確につくる意味がより大きくなります。デザインエンジニアが活躍する場と言ってよいでしょう。

エンジニアとしてもデザイナーとしても手を動かせると、現場でちょっと試作を作る必要が出てきたときに他の人との違いが出ます。自分の頭の中で作らなければならないものをデザインとエンジニアリングの要素に分解し、ぱっと作って出せる。そのプロセスに複数人が関わるのか、それとも一人である程度やれるのかで、スピードと質の両面に大きな差が生まれます。

（引用元：takram 田川欣哉に学ぶ、《デザインエンジニア》の仕事と思想）

バックエンド／フロントエンドで別けないエンジニア職、マークアップ・スタイリングまで担当するデザイナー職。estieの開発チームはこれを基本としています。その環境のなか、デザインエンジニアだからこそ生み出せる価値は何か？どう立ち回ると最も有効か？まだまだ探求の余地がありそうです。

こんな開発をしました

estieは、オフィス領域を足掛かりに商業用不動産向けのSaaSを開発しています。8万棟のビルをはじめとし、データが根幹にある事業です。そこで、外出のついでにビルデータを更新できる社内向けアプリをつくりました。Expo (React Native) + Firebaseを用いて一人で開発し、かかった期間は1.5ヶ月ほどです。こちらにて詳しく書いております。

ある日「こういうことできたらいいよね〜」と雑談していたところ、帰路にてアイデアがひらめき、かけ足で自宅へ。「これは絶対に明日見せたい！！！」と小一時間かけてモックを作り、展開しました。すると他のメンバも沸き立ってくれ、とても嬉しかったです。粗くでもアイデアをパッとかたちにすることはやはり重要ですね。

事業課題を捉えて解法の実現まで持っていくのはなかなかハードでしたが、刺激に満ちていました。ビジネスリスクや技術課題をドキュメント化してまず合意を取ったことや、UIデザインを中盤からコードベースで実施したこと、そして型定義を設計書代わりに実装していったことなどは今回の開発でよかったポイントだと思っています。