デザインエンジニアリングへの注目の高まり

近年ソフトウェア開発においてデザインエンジニアリングという言葉を目にする機会が増えています。従前では工業デザインの分野として対象製品の製造や建築にかかる関係者が多く、工程も多岐に渡るものづくり過程において、ユーザーにとっての利便性及び効用の追求と、製造工程のリードタイム短縮やロス効率の最大化を両立させるためのアプローチとして議論されていたようですが、足元ではそのスコープがソフトウェア開発領域にも広がってきています。

デザインエンジニアリングの定義

ソフトウェア開発におけるデザインエンジニアリングの定義についても諸説ありますが、InVision社が公開する「DesignEngineeringHandbook」¹では以下のように定義されています。

Design engineering is the name for the discipline that finesses the overlap between design and engineering to speed delivery and idea validation. From prototyping to production-ready code, this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work encapsulates the systems, workflows, and technology that empower designers and engineers to collaborate most effectively to optimize product development and innovation.

デザインエンジニアリングとは、デザインとエンジニアリングが交差する領域における問題解決を行い、プロダクトの納品とアイデアの検証を素早く実施するための指針となるものです。デザインエンジニアリングの役割は、プロトタイピングから本番リリース可能な状態に至るまで、デザインの意思決定を加速させるとともにリスクを軽減し、UIにかかるコードの品質を向上させることです。デザインエンジニアの仕事は、プロダクト開発とイノベーションのプロセスを最善化するために、デザイナーとエンジニアとの最も効率的なコラボレーションを実現し、システム、ワークフロー、技術をカプセル化することです。(筆者訳）

「DesignEngineeringHandbook」内においては、大手テック企業やスタートアップ企業においては渇望されがちなUIデザインからフロントエンドのマークアップだけでなくサーバーサイドのコーディングも一部実装できる何でも屋になることを推奨しているわけではなく、InVison社の定義するデザインエンジニアリングはより組織的な汎用性を企図するものであり、デザインとエンジニアリングを繋ぐための新しい業務や役職をつくる必要性が示唆されています。

デザインとエンジニアリングを繋ぐ役割への期待の高まり

ROUTE06(ルートシックス)においても、プロフェッショナルサービスとして様々な企業のデジタルプロダクトのデザイン構築をご支援させていただくなかで、デザインと開発のスムーズな連携の必要性については日々実感するところです。特に顧客企業の担当者と弊社のプロダクトマネージャー、デザイナー、ソフトウェアエンジニアが目線を共通化するためのワイヤーフレームやモックアップの作成するシーンは多く、実際のソフトウェア開発に入る前にどれだけ関係者間で実用的かつ実装可能なUIデザインを構築できるかによってその後の開発効率が大きく変わります。近年ではFigmaなどのデザインプラットフォームの普及によってモックアップからPRD(プロダクト要求仕様書 / Product Requirements Document)等の作成効率が大幅に向上しており、ツールの進化によってデザイナーの活躍の幅が広がっていることも、デザインエンジニアリングが注目されるようになってきた背景の一つと言えるでしょうか。

デザインエンジニアリングの業務内容

プロダクト開発おけるデザインエンジニアリングの業務内容としては、前述のInVsion社のドキュメントによれば主に以下のプロセスに分類されます。

1.バリュー： プロダクトがユーザーに提供する価値、または解決する課題は何か
2.ユーザービリティ： プロダクトをどう利用するかユーザーにとって明確であるか
3.実現可能性： エンジニアが限定された期間、リソース、技術のなかで、必要な機能を実装することできるか
4.ビジネスにおける実行性： そのソリューションは事業に便益をもたらすか

またデザインエンジニアはコードを書くべきかという論点については、上記のプロセスにおける観測効果を最大化することを主目的であるため、コードを書くデザイナーでもそうでないデザイナーでも活躍できることが示唆されています。前者についてはUIエンジニアリングとして、実装効率とデザインの美しさを両立させたプロダクション(本番環境)水準のフロントエンドのコードを記述するだけでなく、フレームワークやツール選定等を行うことが期待されます。後者においてはデザインテクノロジストとして、チーム全体のプロトタイピングの高速化に貢献するようなストーリーティングや、ドキュメンテーション、ユーザーリサーチやA/Bテストなどの環境を整えることが期待されています。

デザインエンジニアに求められる要件

デザインエンジニアはチーム開発において実践的なプロトタイピングを推進する役割として、大前提としてユーザーの課題解決に情熱を持ち、プロダクトチーム全体の文化やプロジェクトマネジメントに貢献する姿勢が求められます。エンジニアリング面ではJavaScript、React、Gitを使った実装力及びフレームワーク活用やコードレビューの実務経験など、デザイン面ではクリエイティブやUIのチーム制作の実務経験に加えてユーザーリサーチやデザイン原則の理解及び実行力などが期待されます。HTML/CSSなどによるマークアップを行う機会も多いものの、チームで汎用的なプロトタイピングを実施可能な状態にするためのコンポーネント単位での設計力が求められる機会も少なくありません。個人でそれらの要件を網羅する人材は少なく、Figmaなどのプロタイピング/デザインツールなどを共通スキルとしつつ、チーム内でのデザインテクノロジストやUIエンジニアなどの役割分担やコラボレーションを行える体制づくりが重要になります。一方でデザインエンジニアリングはまだまだ新しい業務領域及びキャリアパスであり、企業やチームに応じて求められる要件や役割が異なっているのが現状です。

デザイナーにコーディングスキルは求められるのか

従前から活発に議論されてきたものではありますが、デザインエンジニアにおいてもコーディングスキルの要否については頻繁に語られる論点です。前述の通り、チームの役割に応じて必ずしもコードを書くことが求められないものの、HTML/CSSだけではなくJavaScriptライブラリやサーバーサイド言語での実装スキルがあるほどプロダクト開発の現場で重宝される機会は多く、個人のキャリアにおける選択肢もますます広がっていくことが予想されます。一方でコーディングの実装経験が長いほど、実現可能なフレームワークやコンポーネントを前提としたインターフェースを設計する場合も多く、それが必ずしもユーザーにとって最適なデザインになるとも限りません。コーディング経験の少ないデザイナーの方がシステムによる潜在的な制約条件を意識せず、自由にデザインの可能性を広げやすいと考えることもできます。デザインエンジニアリングもユーザー志向かつチーム開発を重視する過程から生まれた考え方であり、コーディング未経験であってもチーム開発への貢献に情熱を持ち、エンジニアリングチームにインスピレーションを与えるデザイン等を生み出せるデザイナーであれば、コードを書けるデザイナーと同等に活躍できる機会が増えていくと筆者は考えます。JavaScriptライブラリ等のフロントエンドの実装技術にしても、デザインのトレンド及びツールにしても、デザインエンジニアリング領域における変化のスピードは早く、いずれの立場においても常に新しいことを学び続ける学習力や多様な思想やバックグラウンドのチームと協業できる柔軟性が求められる点に変わりありません。

Admiral Grace Hopper: “The most dangerous phrase in the language is: We’ve always done it this way.”

おわりに

デジタルプロダクト開発においてデザインとエンジニアリングを繋ぐ役割としてデザインエンジニアリングの必要性は高まりつつあるものの、業務内容やスキル要件などを明記している企業はまだまだ少なく、今後より議論が活発になっていくことが予想されます。ROUTE06においてもプロトタイピングを通じてプロダクトデザインの受容性、実装可能性及びビジネスインパクトを最大化できるような環境や体制を構築することは重要な経営論点であり、顧客企業からの期待も高いテーマでもあるため、今後も関連分野のリサーチや情報発信なども積極的に行っていきたいと考えています。

脚注

1. Natalya Shelburne, Adekunle Oduye, Kim Williams, Eddie Lou,and Caren Litherland Design Engineering Handbook ↩