この記事はGoodpatch Advent Calendar 2020 1日目の記事です。

はじめに

去年、UX Engineer Meetupというイベントを開催し、デザインとエンジニアリングに関心を持つ人達と交流することができ、私自身とても学びが多いイベントになりました。

それから１年ほどが経ち、社内でも「UXエンジニア会」と呼ばれる会議が立ち上がるなど新しい活動も始まりました。しかし、この職種はまだ一般的ではなく、会社によって呼び方や役割は様々なので、具体的にどんな働き方をしているのか疑問に感じる人も多いのではないでしょうか。そこで、今回はGoodpatchにおける「UXエンジニアとは？」ということをテーマに具体的な取り組みを交えながら、ご紹介したいと思います。

ただ、正直なところでは「UXエンジニア」という職種は会社として明確にJob Descriptionを定義している訳ではなく、現時点ではエンジニアのキャリアの１つとして個人個人が実践しながら議論を深めているという状態です。

UXエンジニアって何？

このシンプルな問いについて、明確な定義がある訳ではありませんが、現時点では以下のように捉えています。

デザインとエンジニアリングを支援し、ユーザーに喜ばれるプロダクトをつくる

抽象的ではありますが、UXエンジニアの目標は「デザインとエンジニアリングの領域を横断しながらユーザーに喜ばれるプロダクトをつくること」だと考えています。エンジニアとして使いやすさや美しさなどに気を配りながらプロダクトを設計・実装したり、それを実現する上で障害となる技術的・組織的な問題にも取り組みます。UXエンジニアはデザイナーとしての目線とエンジニアとしての目線を使い分けながら、新しいアイデアを検証したり、デザインとエンジニアリングの分業化により生まれる問題に対処します。

“ユーザー”とは誰のこと？

ソフトウェア開発の現場ではよく“ユーザー”という言葉が使われますが、多くの場合、いわゆるエンドユーザーを指しています。エンドユーザーの利用体験を考えるのがとても大事なことです。一方で、ソフトウェアを運用する人たちもいます。ここでは運用に含まれる人たちをシステムユーザーと呼んでいますが、プロダクトの開発が複雑化・長期化した現代においてエンドユーザーだけでなく、システムユーザーの利用体験を考えることは大切なことだと考えています。「顧客満足度を上げるためには従業員満足度が重要である」という考え方に近いかもしれません。

デザインとエンジニアリングの分業により生まれる問題

専門性の異なる職能が分かれるのは決して悪いことではなく、分けることによって職能ごとに最適化しやすい側面もありますし、それで上手くいっているところもあると思います。しかし、組織が大きくなってきたり、デザイナーとエンジニアが別々の組織に属している場合などで問題が起きることがあります。たとえば、プロダクトを作る上では設計から実装、その後のテストまですべての工程が重要であるにもかかわらず、デザイナーとエンジニアの責任範囲が違うばかりにコミュニケーション上のすれ違いが起こるのはその一例です。そのような問題を放置していると、いずれUIやコードが複雑化し、ユーザーや開発チームを苦しめてしまいます。

プロジェクトでの関わり方

UXエンジニアは仕事内容、プロダクトのフェーズ、チームの特性に基づいて、大きく２つのポジションがあります。１つ目はデザインレンズのUXエンジニア、２つ目はエンジニアレンズのUXエンジニアです。

デザインレンズのUXエンジニア

デザインレンズのUXエンジニアはデザイナーに近い存在です。デザイナーがSketchやFigmaなどを用いてUIデザインを行いますが、それらのツールで解決できない問題をUXエンジニアは技術的なスキルを用いて支援します。

たとえば、ユースケースによってはSketchなどの単純なプロトタイプではユーザーの体験や負荷を把握することが難しい場合があります。実際に開発してみてリリースした後でユーザーの反応を知ることはできますが、開発工数が大きい場合は１ヶ月以上待たなければいけないこともあります。また、一度リリースした機能を削除するのも容易ではありません。そのようなケースでは、UXエンジニアは設計の意図を理解しながら、簡易的な実装モデルを設計し、よりリアルなプロトタイプを作ることで問題を早く検知します。また、実装コストを踏まえて開発すべき機能の優先順位を検討することもあります。

デザインレンズのUXエンジニアは基本的にデザインチームに所属します。

エンジニアレンズのUXエンジニア

エンジニアレンズのUXエンジニアはソフトウェアエンジニアに近い存在です。ただし、一般的なエンジニアよりもデザインについて理解があり、デザイナーとの共通言語を持っているため、デザインフェーズで気づかなかった問題などに柔軟に対応します。たとえば、Sketchで描かれたUIではイレギュラーケースが考慮がされていない場合、UXエンジニアはユーザーに適切に表示されるようにビジュアルを調整したり、表示ロジックを工夫して問題の解消に取り組みます。また、周囲のソフトウェアエンジニアに対してもデザインが理解されるように支援し、デザイナーとソフトウェアエンジニアのコミュニケーションコストを削減します。

エンジニアレンズのUXエンジニアは基本的にエンジニアチームに所属します。

チームの特性や状況に応じて役割は異なる

Goodpatchのクライアントワークでは作るものが何も決まっていない要求分析・体験設計のフェーズからエンジニアが関わることもありますし、要件定義以降の開発を担当することもあるので、プロジェクトの状況に応じてポジションを変えながら仕事を行っています。この働き方を実現する上で上司やチームと会話し、理解してもらうことが大切です。

なお、この２つのレンズの話は以下の記事（中国語）を非常に参考にさせていただきました。

具体的な取り組み

UXエンジニアにはその特性上、価値を発揮しやすい領域があります。ここに書かれてる内容が全てではありませんが、共有できる範囲で具体的な取り組みをいくつかご紹介します。

コミュニケーションを円滑にするプロセス設計

ユーザーの体験を重視しながらも、目標とする時期までにプロダクトをリリースすることはチームにとって重要なミッションです。クライアントやデザイナーの要望を汲み取りながら、無理が生じないように開発プロセスを設計することでプロダクトの品質を管理します。特にデザイナーとエンジニアがどのような連携を取るのかは注視すべきところでもあります。デザイナーとエンジニアの距離感が遠ければ遠いほど、意思疎通のコストは高くなるのでメンバーの意向やスキルに合ったプロセスを設計することは大切です。

ワンキャリアクラウドのプロジェクトではアジャイル開発（スクラム）を推進し、プロダクトオーナー、デザイナー、エンジニアのコミュニケーションが円滑になるように開発プロセスの設計を行いました。

ワンキャリアクラウド｜Work｜Goodpatch グッドパッチ

実現性を踏まえた要件定義

Goodpatchが提供している「Strap」ではさまざまなアイコンを配置できるアイコンエレメントの機能がありますが、その機能を開発する前の企画の段階ではユーザーに提供したい機能が多くあり、実装に必要な工数やスコープ的にどこまでやるべきかの判断が難しい部分がありました。技術的な複雑性を把握した上で、タスクの見積もり精度を上げるために、「スパイク」というやり方で事前調査を行いました。

限られた時間の中でユーザーにとって価値がある機能を提供するために、すべての機能を実装すべきかをユーザー目線で考えることはとても大事なことです。デザイナーとエンジニア両方の観点で、ユーザーの利用体験を犠牲せずに「実現性」と「提供する価値」を判断しつつ、分析した内容をチームに提案しました。

価値と実現性を検証するプロトタイピング

Strapにはカスタマージャーニーマップを簡単に描くためのエレメントがありますが、このエレメントを実装する前の段階で、このアイデアに対して以下のような課題と不安がありました。

ユーザーに対する価値について：大量の開発工数を投資する価値があるのか
ユーザーに対する挙動について：ユーザーはUIが使いやすいと思うのか
チーム内に対する認識について：チーム内のメンバーは同じ認識を持っているのか

課題と不安を解消するためにチームと相談した結果、少しの時間を投資してプロトタイプを作ることにしました。しかし、このような機能を検証するのに、デザインモックアップ的なプロトタイプだけでは足りないことを分かりました。そのため、実際にコードを使ったテクニカルプロトタイプを作成することにしましたが、プロトタイプをつくる上でデザイナーが考えていることを再現することは大切なポイントです。

▼プロトタイプ

▼最終の実装版

デザイナーが考えている細部のインタラクションを再現できるように、デザイナーと同じ言葉を使った上でテクニカルプロトタイプを素早く実装することで最終的なデザインに近いプロトタイプをつくることができ、当初の不安を解消することができました。

運用を効率化するデザインシステム

モチベーションクラウドのプロジェクトでは、プロダクトの運用が長くなるにつれて、開発組織も大きくなり、デザイナーも複数名体制となったため、プロダクト全体でUIの一貫性を維持するのが難しくなりました。その際にUIの一貫性や開発効率を維持していくためにデザイナー達と一緒に今後の運用方法について話し合い、既存のUIコンポーネントのリファクタリングやエンジニアメンバーへ運用ルールの周知などを行っていきました。こちらに関しては、以下のスライドをご参考にいただければと思います。

MOTIVATION CLOUD｜Work｜Goodpatch グッドパッチ

おわりに

いかがでしたでしょうか。私たちとしても、ご紹介した内容を完璧に実践できている訳ではなく、まだまだ模索している段階ですので、一緒に議論できる仲間を増やしていきたいと考えています。もし、同じような領域に関心がある方がいましたら、ぜひGoodpatchにジョインしていただきたいですし、そうでなくとも悩みやナレッジについて情報交換できると嬉しいなと思っています。

なお、この中で紹介している事例は同僚でStrapの開発メンバーであるfish氏と共同で作成しています。彼の記事もぜひご覧ください。

ここまで長文読んでいただき、ありがとうございました！