Relicのデザインエンジニア像を決めていった話
こんにちは、Relicのフロントエンドエンジニアのちゃあゆです！
ここ数年でデザインエンジニアという言葉を耳にすることが増えてきましたが、「デザインエンジニア」とは何をする人なのか、パッとイメージが浮かびますか？
🤔…「フロント」× 「デザイン」をする人かな？
そんなぼんやりしたイメージを持つ方が多いのではないかと思います。
Relicでも2021年7月にデザインエンジニアリンググループという組織を発足しました。が、当初はRelicの「デザインエンジニア」の役割はまだまだ言語化できていない状態で、最近になりようやく固まってきました。
この記事では、そんなRelicのデザインエンジニア像を決めていった様子を紹介したいと思います！
デザインエンジニアリンググループ設立の背景
そもそもRelicで「デザインエンジニアリンググループ」を設立したのは、従来の「職種による縦割り体制」ではカバーしきれない部分が出てきたことが背景にあります。
例えば、あるプロジェクトでデザイナーとエンジニアはそれぞれ次のような悩みを持っていました。
デザイナーの悩み
解決したい課題に対してベストであろうデザインを見せても、「これはできない / できるか分からない」「これはちょっと工数がかかる」と言われる。諸々の事情を考慮した結果、 デザイナーの「本意」とは異なるデザインに落ち着くというような状況。
エンジニアの悩み
デザインが意図する「UIによって解決したい課題」が分かれば「こういう技術を使えばもっと簡単に（or 適切に）解決できそう」というアイデアは出るものの、すでに色々決まっている状態。決まったことを今さら覆すのも難しいし..と、これもまた諸々の事情を考慮し無難なところに落ち着く。
結果的に技術的なアプローチでUXを改善する試みが薄れるという状況。
このような状況では、課題を解決するどころか、忖度の結晶のようなアウトプットができあがります。
少し極端な例えですが、割とあるあるなケースではないでしょうか。
解決したいこと
上の例のように、両者の本意を検証できない状況は非常にもったいないですよね。このようなデザイナー・エンジニアの制約は排除したいです。
また、事業化に向けてまずは小さなボリュームで検証することも求められるようになってきました。つまり、「形にする」までをスピーディに行うことが必要です。
それらの役割の担い手としてデザインエンジニアリンググループが設立されました。
とはいえ、グループの設立からしばらくは具体的な役割の言語化ができていない状態が続き、「デザインエンジニアリンググループって結局何してるの？」という空気はあったと思います。
当事者の我々も、当初は「他のフロントエンドエンジニアやデザイナーとの役割の違いって何だろう..？」という状態で、Relicでの役割を言語化するまでには議論を重ねました。
デザインエンジニアの定義とは？
ダイソンのデザインエンジニア
さて、そもそも「デザインエンジニア」って一般的にはどういうものなんでしょうか？
この「デザインエンジニア」という言葉が世に広まるきっかけになった有名な例として、ダイソンのサイクロン式掃除機の開発秘話が挙げられます。
ダイソンにはいわゆるデザイナーは存在せず、いるのは多くのデザインエンジニア。今や誰もが聞いたことのある「吸引力の変わらないただひとつの掃除機」は、彼らデザインエンジニアが約5000回ものプロトタイプ製作を重ねて誕生したそうです。
ダイソンでは「エンジニアリングとデザインは一体である」という考えを企業文化にしているようで、世の中的にもこのような考えが広まっているのではないかと感じています。
他社のデザインエンジニアの例
最近は「デザインエンジニア」の求人や情報を発信している企業さんも多く見かけるようになりました。
下記に数社の例を引用します。
テクノロジーの領域に専門的な知見をもち、ハードからWebまでさまざなプロダクトやサービスのアイディエーションから実際にプロトタイプを作成を担うことが多いポジション
フロントエンド/iOS/Android/Flutterエンジニアといった「UIを開発する職種の能力」を持った人が、UIデザイナーといった「UIをデザインする職種の能力」を併せ持ち、双方の能力を発揮して活動するマルチスタックエンジニアの事を「デザインエンジニア」と呼ぶ
プロダクト開発の現場においてユーザーにとってより良いUI/UXの提供を常に目指していくため、デザインとエンジニアリングの領域において熱量を持つ人材が必要です。 デザインとエンジニアリング２つの領域を横断的に考え、自分ごととして UX を実現できるデザインを作っていただける方を募集します。
こうして見てみると、企業ごとの「デザインエンジニア」の定義は様々で、一般的な定義があるわけではなさそうです。
一方で、「領域の横断」「プロトタイプ」のような言葉が登場することが多いようにも感じました。
どんな言葉で定義されているかは各企業のカラーが感じられますが、解決したいことや実現したいことは近いのではないでしょうか。
Relicのデザインエンジニア像を決めよう！
Relicでのデザインエンジニアの役割を決めていくにあたっては、メンバーでいくつかのワークを行いました。
「デザインエンジニアリング」のイメージ
まずは、グループのメンバーそれぞれが持つイメージを知ることから始めました。
「デザインエンジニアリング」と聞いてイメージするもの出し合い、「これまでの業務実績とのギャップ」という観点で分類していきました。
下の図は実際のワークで用いたツールのキャプチャです。あまり深く考えず、ホワイトボードツールの付箋に書いてラフに出し合いました。
「越境」や「検証」という言葉や、「ツールや既存パーツを活用して素早く開発する」というイメージが見えてきました。
また、これまでの業務実績とのギャップが大きいことではありますが、UIやデザインシステムの構築といった意見も挙がりました。
この段階ではやはり漠然としたイメージなので、具体的な役割に落とし込んでいく必要があります。
「デザインエンジニア」としてこだわりたいこと
次に、各メンバーが「デザインエンジニア」として何にこだわりたいかを知るワークを行いました。
下の図のように、いくつかの単語の中から各々のイメージに当てはまるものを選びました。
オレンジ色の付箋がついている単語は実際にメンバーが選んだものです。
結果としては「横断」や「試作」に複数の票が集まりました。
しかし一つの単語に絞るのに迷ったという声も多く（私も迷いました）、「横断」や「試作」をするための「共感」だったり、それらを「専門」とする集団でありたい、など。
そのような各メンバーの想いはどれも共感できるものでした。
Relicのデザインエンジニアの役割
上で紹介したワークは一例ですが、議論を重ねながら「Relicにおけるデザインエンジニアの役割」を次のように決めました。
事業化の0→1 や 1→10 のフェーズにデザインエンジニアが入ることで、新規事業開発を加速できると考えています。
①プロトタイプを素早くつくり、検証を行う
検証フェーズではノーコード/ローコードツールやBaaSなどを活用し、バックエンド・フロントエンド両方の領域をデザインエンジニアが担当します。
デザイナーとの連携も密に取り、素早く形にしていきます。
こうして想いをカタチ（=プロトタイプ）にスピーディーに落とし込むことで、早い段階で検証を行うことができます。
②本開発での事業化の確度を上げる
本開発の段階に①の検証に携わったデザインエンジニアが入ることで、検証フェーズのナレッジを持ってスムーズに開発を進めることができると考えます。事業化に向け、検証時に得られた情報を活かす狙いです。
デザイナーとデザインエンジニアのコミュニケーションはここでも密に行い、引き続きスピーディーな検証を繰り返します。
このように、フロントエンド領域を主軸としながらも、デザイン・バックエンド領域を横断して事業開発を加速することがRelicの考えるデザインエンジニア像です。
私のイメージですが、デザイン、エンジニアリング、場合によってはそれ以上の領域にまで..と、全体のギャップを埋める潤滑油のような存在だと思っています。
さいごに
Relicのデザインエンジニア像を決めるに至るまでの、グループ設立の背景から議論の様子を紹介しました。
Relicにおける存在意義や役割が決まり、グループとしてはようやくスタートラインに立ったという感じです。
ここから社内外への認知も広めていくぞ！と燃えております🔥
現在はグループで「デザインエンジニアリング」な取り組みも進めており、その内容も今後紹介したいと思います！
最後まで読んでくださりありがとうございました😄
今回紹介したデザインエンジニアリンググループに限らず、Relicでは一緒に議論できるメンバーを絶賛募集中です！
興味を持ってくださった方は是非Relic採用サイトを覗いてみてください。
カジュアル面談も行っています。
地方拠点も拡大中で、U・Iターンも大歓迎です🙌
この記事が気に入ったらサポートをしてみませんか？