Goodpatch Advent Calendar 2018、19日目の記事です！
先日開催されたCookpad Product Kitchen #1 with Takramの中で、CookpadのUXエンジニアの方が、事業会社におけるUXエンジニアの役割について発表されていました（スライドはこちら）。
非常におもしろい発表だったのですが、「じゃあクライアントワークの場合はどうなんだ」ということで、実際にGoodpatchでUXエンジニアとして働いていた経験から、僕なりの考えを書いてみます。
基本的なスタンスは変わらない
https://speakerdeck.com/dex1t/the-intersection-of-design-and-engineering?slide=18 より
自社サービス開発の場合
解き方が不明で正解がわからない「Wicked Problem」に対して、プロトタイピングを行います。作っては試すのを繰り返すことで、プロダクトの輪郭を描いていきます。
https://speakerdeck.com/dex1t/the-intersection-of-design-and-engineering?slide=22 より
その際、仕様はFixしないものと捉えます。後からでも閃きが生まれれば取り入れ、より良いユーザー体験を追求します。その分、期限は絶対のものではなくあくまで目安とします。
実際には、１つのプロダクトの中でも「Wicked Problem」にあたるものと、デザインや実装方針がすぐ決まる機能（例：アプリ内課金機能）があるので、役割分担をします。
クライアントワークの場合
クライアントワークの場合、POはクライアントの中にいます。自分たちに「何をどういう優先順位で作るか」の決定権があるわけではありません。そのため、Wicked Problemに取り組めるとは限らず、例えばマンガアプリのようにある程度は定番パターンが決まっている案件も多いです。
また、クライアントワークでは自社サービス開発に比べて締切が決まっている場合が多いです。ビジネス的な都合で決まる場合もありますし、アジャイル開発等の文化がなくて締切ベースになる場合もあります。とはいえ、締切が悪ではありません。ビジネスにとって期日やスピードもまた重要だからです。
そのような環境で、UXエンジニアはプロジェクトのスタートから参加し以下のように振る舞います。
解き方が不明な課題（Wicked Problem） と 自明な課題 の切り分けを行う
- 解き方が不明な課題があれば、プロトタイピングを繰り返しながら、クォリティをあげていきます
- 解き方が自明な課題に対しては、デザインが固まっていなくても、できるところから早く実装し、あとからブラッシュアップする余裕をつくります
スケジュールの問題でユーザー体験をないがしろにしない
- 余裕をもった見積もりを行ったり、開発プロセス・スケジュールの認識をあわせることで、より良いユーザー体験を追求できる環境をつくります
- 炎上してしまうと、いわゆる当たり前品質すら危うくなり魅力品質まで手が回らなくなってしまうので、絶対に防ぎます
- 余裕を持ちすぎると、スピードが落ちたり必要以上に凝ってしまうため、バランス感は重要です
- エンジニアリングだけでなく、PM的な目線も重要になってきます
https://speakerdeck.com/sagaraya/development-process-for-better-ux?slide=20 より
細部にこだわる
- ユーザー体験やビジネス価値のコアとなる部分を見極め、アニメーションやマイクロインタラクションの実装、細かいUIや文言の改善、パフォーマンスチューニングなどを実施し、徹底的にクォリティを上げます
- それによってプロダクトへの愛着を高めたり、KPIの達成につなげます
- エンジニアリングだけでなく、デザイナー的な目線も重要になってきます
おわりに
UXエンジニアはそもそも少なく、その中でクライアントワーク経験がある人はもっと少ないです。僕が書いたのはあくまでGoodpatchでの経験を経て考えたことなので、ぜひ他の会社での経験を経て考えたことも知りたいです。そんな方はぜひ UX Engineer Advent Calendar 2018 へ！