江原さんが所属するデザイナー組織について紹介いただけますか？

私が所属するプロダクトデザイン課は、ラクスが提供している多くの製品のデザインを横断的に手掛けています。
ラクスの製品は、対象とする領域に応じてバックオフィス（経費精算、請求書発行、勤怠管理、販売管理など）向け、フロントオフィス（マーケティング、コールセンターなど）向けがあります。
プロダクトデザイン課では複数のデザイナーが在籍しており、それぞれ各製品の専属デザイナーが業務に当たっていますが、製品の垣根を越えて相談し合ったりもしています。

私は現在、バックオフィスの中でも経費精算業務を効率化する「楽楽精算」のデザインを担当しています。３名のデザイナーが楽楽精算を担当しており、日々寄せられるデザイン面での顧客課題解決に取り組んでいます。

江原さんがUIデザイナーとして、ドメイン理解の重要性を強く認識するきっかけになった事例をテーマにお話しいただきます。まず、なぜUIデザイナーがドメイン理解をすることが重要なのでしょうか？

まず、ドメイン理解が顧客の課題解決に必要不可欠だからです。
ドメイン理解の観点例としては、下記のようなものが挙げられ、達成したい課題解決の解決策を選ぶ際に必要になってきます。

・目の前の利用者の専門分野に明るくなり、どのような行動、思考で仕事をしているか？
・利用者と業務上関係する人はどんな人で、どのように利用者の業務にかかわるか？
・利用者が自分が担当するシステム外でどんなことをしているか、考えているか？

楽楽精算は経費精算を扱うため、例えば税法が深くかかわってきます。UXの要求段階でも、インボイスなどの最新動向や金額表示などの分かりやすさ、正確性などを考慮する必要があり、必要となる専門性が非常に高い傾向になってきています。その意味では、UIデザイナーだけでなく、すべての関係者にドメインの理解が必要となっているといえると思います。

今回ご紹介いただく事例について教えてください。

以前、デザイナーと製品企画で協業し要求調査をした際のお話です。想定顧客は経理担当者で、請求書受領後の処理業務に関する機能を検討するため、業務課題をインタビュー調査しました。
製品企画２名、デザイナー２名のチームで10組のお客様にそれぞれ２回に分けてインタビューをしていくというもので、インタビュー、記録者、タイムキーパー、指示役など役割をチームで回しながら進めていきました。

※ 2023年12月現在は、楽楽精算の要求調査や顧客業務課題のヒアリングは製品企画とプロダクトマネージャー（PdM）が協力して行っています。デザイナーは基本的にPdMを介して要求を把握し、必要に応じてCSに深堀ヒアリングを行う体制になっています。
デザイナーとPdMの役割はこちらの記事をご覧ください。
「デザインの業務プロセス」
https://career-recruit.rakus.co.jp/career_engineer/tech-design/culture-023

PdMの顧客調査方法についてはこちらの記事をご覧ください。
「楽楽精算PdMはどのように顧客ニーズを理解しているのか」
https://career-recruit.rakus.co.jp/career_engineer/tech-design/culture-030

要求調査は具体的にどのように進めていったのですか？

「起業の科学」という書籍がありまして、本プロジェクトでは活動をスタートアップの起業と見立てて、その書籍で紹介されている手順を応用し進めました。楽楽精算自体はスタートアップではありませんが、新規機能の検討にあたりゼロから仮説検証を行いたかったというのが手法選択の背景です。

実際には書籍の全ての内容を適用したわけではなく、Customer Problem FitとProblem Solution Fitのフレームワークをチームで応用しました。
起業の科学の冒頭には解決すべき課題を特定する「アイデアの検証」という項目もありますが、今回はインボイス制度に対応する請求書処理の課題があると分かっていたので省いています。

・Customer Problem Fit
顧客が抱える課題を言語化し、顧客が本当に課題を持っているか検証するプロセスとなります。
製品企画のメンバーと議論を重ね、顧客が抱える請求書における課題を言語化しました。早い段階で関係者に簡単に伝わるよう、エレベータピッチも作成しました。
その後カスタマージャーニーを作成し、それを元に顧客が本当に課題を感じているのかインタビューを開始しました。既存顧客１０社にインタビューを了承してもらい、顧客の課題を深堀していきました。

・Problem Solution Fit
顧客が課題をどのように解決したいかを明らかにし、プロトタイプを実際に使ってもらいながらインタビューを進めるプロセスとなります。

この段階では、確からしい課題に対してあるべき姿を考え、課題解決ジャーニーを書き起こしました。この段階で、対応する課題とターゲット顧客をチーム間で定めました。その後、時間の都合上、プロトタイプ作成まではいきませんでしたが、ジャーニーに機能の理解を助ける情報などを付け加えながらインタビューを進めました。

全体をとおして、フレームワークを適宜省きつつ、顧客との対話にはできる限り時間をいただきましたので、１回２時間という長時間お客様と話が出来たのは非常にありがたい経験でした。おかげで、役回りを毎回変えたにもかかわらず、どんな立場でも十分に聞きたいことを聞ける時間があったのが良かったですね。

デザイナーからは特にお客様が業務フローで課題を伝えてくれた時に、それがどうして課題なのか？を、詳しく聞きました。システムでどこまで解決すべき問題なのかを判断するためです。例えばある課題がお客様の画面サイズに起因することが分かれば、新規開発した機能を有償で導入するか、使うディスプレイを変えるか、顧客の選択をコスト面からの判断もできます。

実際にインタビューを進めてみて、いかがでしたか？

実際に顧客との対話の現場に出てみると、当初の仮説では予想していなかった機能の使用法や取引形態、業態があることが分かりました。顧客から得られる有益な情報も多く、地道にドメイン学習を続けていく原点になっています。調査の結果では、特定業態の顧客が領収書を受け取った際に課題を持っていることが分かりました。ビジネス的にも筋の良さそうな課題として企画が感じ取ったことをよく覚えています。

ただ、要求確定段階になると改善の余地が大きかったです。ペルソナ策定のタイミングに加え、前提としていた自身のドメイン知識にも課題があり、一部ターゲット業種ではない顧客へもインタビューをしてしまっていたことが分かりました。その分要求が不確かとなり、後続のプロセスにも負担をかけてしまったことは反省です。その後開発チームに要求をひも解いていただく形となり、正しいドメイン知識をもとに課題が整理されていないと、顧客課題解決につながる機能開発にならないということを学びました。

ドメイン知識は正しくターゲットの課題をとらえるために必要ということですね。そこからどんな学びがありましたか？

反省が多かった経験の中でも、良かったことは有りました。
一つは自分の意識が大きく変わったこと。製品企画と越境して業務をすることで、自身の仕事や知識が顧客や関係者に与える影響をより意識するきっかけとなり、それまで以上に主体的に動くモチベーションになりました。

二つ目は、関係者とのつながりです。プロジェクトというのは通常行う仕事よりも大きく、関係者に対する影響範囲も大きいものです。そういったものを共に乗り越えた関係は、そのあとの仕事において強い結束を生みます。暗黙、あうんといった物でしょうか？形に見えないもので非常に価値のあるものです。

そして最後はドメイン知識の必要性を認識し、常に学び続ける習慣がついたことです。
デザイナーが自立して事業の一員として役割をこなすには、日ごろからドメインのことを学習し、関係者に価値を提供し、顧客に価値を提供するようにならないといけません。これまでの経験や学習から得られたドメイン知識は、体制が変わった現在もPdMとのコミュニケーションの土台となっています。ドメイン知識を理解することで、自分自身がPdMの仕事内容を想像でき、話の内容の理解が深まったように思います。その結果、PdMの判断が顧客課題解決につながっていることを信頼し、開発の優先順位も腹落ちして業務に取り組めています。

このような経験から、あらゆる面で今はドメインの学習が必要と感じています。特に経費精算業務は日々変化しつづけている領域でもありますので、引き続きキャッチアップを続けていきたいと思います。