🪆 Page icon🪆 Page icon

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

改版履歴
2022/02/03
リリース
2022/02/01
#200_hr にてプロポーザル実施
2022/01/31
Draft 作成

ゆめみにおける定義

概要

フロントエンド/iOS/Android/Flutterエンジニアといった「UIを開発する職種の能力」を持ったメンバーがUIデザイナーといった「UIをデザインする職種の能力」を併せ持ち、双方の能力を発揮して活動するマルチスタックエンジニアを「デザインエンジニア」と呼ぶ
技術領域を示す必要がある場合は開発対象の名称を「デザインエンジニア」前に置く
「iOSデザインエンジニア」「フロントエンドデザインエンジニア」など
2022/01 まで、「UXエンジニア」とゆめみ内で定義されていた職種の定義( 🙌UXエンジニアの定義 )をアップデートした形となる
「UXエンジニア」という名称はエイリアスとして残すが、非推奨とする。
背景
「フロントエンド開発+UIデザイン」というスコープは、UXを構成する要素の一部分のみを担当する形であり、また「UX」という言葉が人によって認識が異なるため、肩書の印象としてぼやける
一方で、Googleの募集職種として名前があるなど、一定の人にとって、自己定義しやすい名前となっていることもあるため、エイリアスとしては残し、禁止にはしない

期待されること

エンジニアなので、主体は「UIを開発すること」
デザインから開発を全て行うというわけではない
スケジュールや体制によってはデザインから開発まで全部やっても良い
その上で、ゆめみではデザインを社外の人もしくは社内で行うため、各デザイナーとスムーズに連携や意思疎通ができることが求められる
プロトタイピングを必要とするプロジェクトにおいては、テクニカルプロトタイピングの開発(デザインツールからエクスポートしたものではなく、デザインデータからUI部分に関する開発)を行うことが期待される

フェーズ別の活躍イメージ

プリセールスフェーズ(リードエンジニア以上)
デザインやUIに関連する要件や制約事項についてデザイナーと協力しながら検討し、関係者と合意形成ができる
デザインを考慮したUI開発の工数見積もりを行うことができる
企画・要件定義フェーズ
デザインデータに対してシステム要求を鑑みたUI開発目線でレビューを行うことができる
異常系、正常系の別パターン、非同期表示のタイムラグ、状態変化のパターン、ホバー時・・・
デザインデータを元に画面仕様書を作成することができる
デザインデータを基にテクニカルプロトタイピングを開発することができる
デザインシステムとしてUIコンポーネントライブラリを開発することができる(例:BBCのStorybook
開発フェーズ
各職種の開発責務
ビジネスロジックによってUIに変化がある場合の実装では品質や開発速度を高められる
検収フェーズ
表示に関する不具合の対応可否判断・実際の対応

所属

UIデザインギルド、各開発系職種ギルド(フロントエンド/iOS/Android/Flutter)の所属については、本人が希望するチームに所属する(両方兼務も可)
年間トータルで見て半稼働ずつになっているか、エンジニアとしての稼働が多くなっていることが望ましいが、実際に経験された方の意見を元に目安となるバランスを調整したい

参考

過去の定義

Makoto Sone
Makoto Sone
02/03/2022
この「デザインデータ」起因のプロセスをなくす方法はないか?どうすればよりよくできるか?の検討にも期待したいです。デザイナーとエンジニアが分業でなく協業できる状態になればと。そしたらデザイナーからもデザインエンジニアになれる。そういう志向もあるかもしれません @Akito Uehara
Akito Uehara
Akito Uehara
02/03/2022
確かに、今は軸をエンジニアとして置いた時の定義になっているので、「デザイナーとエンジニアが分業でなく協業できる状態」「デザイナーからデザインエンジニアになれる」という観点で、さらに議論深められそうだなと思いました。検討したいと思います!(検討重ねた上で、またデザインメンバーみなさんにヒアリングさせていただくかもしれませんがよろしくおねがいします 🙇@Makoto Sone