‣
‣
- リリース
‣
- #200_hr にてプロポーザル実施
‣
- 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）の所属については、本人が希望するチームに所属する（両方兼務も可）
- 年間トータルで見て半稼働ずつになっているか、エンジニアとしての稼働が多くなっている事が望ましいが、実際に経験された方の意見を元に目安となるバランスを調整したい
/assets/images/6901382/original/c36d92bc-a710-48e1-8aeb-cbefed3d5c9f?1622700681)