こんにちは！TECH Street編集部です！
2023年11月27日（月）に開催した、 「UXデザイン勉強会vol.5～各社の取り組みや課題から学ぶ会～」のイベントレポートをお届けします。今回はディップ、LIXIL、パーソルキャリアのUXデザイナーが各社の取り組み事例を発表します！
登壇者は
大森すみれさん／ディップ株式会社
古藤舞華さん・前田孝高さん／パーソルキャリア株式会社
フジタジュンコさん／株式会社LIXIL
早速、内容を紹介いたします！
最初は、ディップ株式会社の大森さんの発表です。
9コマシナリオで理解度が爆上がりした話
大森：まず最初に会社紹介をしたいと思います。dip株式会社は「バイトル」や「はたらこねっと」など求人サービスを運営している会社です。
私は、入社したばかりということもあり、現在いろんなプロジェクトに参加し、キャッチアップをしています。キャッチアップする中で、ある日、Slackにfigmaのファイルが送られ、開くと膨大な資料が入っていました。
その資料を確認したのですが「最初はここから入って‥次にこうなって‥で、結局‥」と
どこが大事なのかわからない状況に陥ってしまいました。
しかし、わからないとは言いづらいし、かといってキャッチアップするのには時間がかかります。それに自分の理解があっているのかも分かりません。
そこで、ずっとデザインを学んできたので、テキストばかりの情報を「可視化」してみようと思いました。
私の理解を整理すると、プロジェクトの目標や課題などは理解できても、｢誰が、どこで、どんなふうに必要なのか｣というシーンで不明瞭な部分がありました。
- 「カスタマージャーニーマップを描けばどこがペインかわかるけど、また長くなりそうだし」
- 「ペインのフェーズはわかっているから、もっとユーザーのコンテキストも含めて共有できる成果物がいいな」
- 「普段TO-BEの提供価値を共有するときに使うあれ使えるかも」
などと考えた結果「９コマシナリオ」を使ってみることにしました。
９コマシナリオ
9コマシナリオとは、ペルソナとシナリオを組み合わせたようなツールになります。
ペルソナ
実際のユーザーをイメージし、ニーズや行動を考慮して設計するためのツール
シナリオ
特定の製品やサービスがどのような状況・環境・コンテキストで使用されるかを説明するツール
9コマシナリオでは、以下のような構成になっています。
- 1コマ目にペルソナ
- 2コマ目にペルソナの現状
- 3コマ目に予期的UX
- 4〜7コマ目に一時的UX
- 8コマ目にエピソード的UX
- 9コマ目に累積的UX
新サービスの体験価値を伝えるのに有効
ところで、9コマシナリオは、新しいサービスの体験価値を伝えるのにも有効です。それを描く場合は下記の構成になります。
- ３コマ目は利用前のタッチポイント、サービスを知るきっかけを描く
- ４～７コマ目はサービス利用中の体験を描く
- ８コマ目はサービス利用直後を描く
- ９コマ目にサービスを使い続けたときの体験を描く
今回は、課題が生じるシーンを描きました。
課題が生じるシーンの9コマシナリオ
- 1コマ目：ペルソナ（ちょっと雑な営業さん）
- 2コマ目：上からの圧力や既存顧客の増加などがありフォローの時間が足りなくなってしまった
- 3コマ目：２時間でフォローし終えたい
- 4コマ目：効果が悪い企業の詳細を見に行く
- 5コマ目：ツールがたくさんあり、タブがぎゅうぎゅうになるほど開かなければキャッチアップできない！
- 6コマ目：対策を考えて顧客に電話
- 7コマ目：原稿に反映する
- 8コマ目：5コマ目(赤枠)にかけていた時間が長すぎたため、目標の２時間をオーバー
- 9コマ目：時間が足りなかったため、フォローすべき顧客に提案ができずに機会損失に…
結果
9コマシナリオを作成したことで、
- 自分も周りのPjメンバーも課題に対する解像度を上げることができた
- 認識があったことで、この場合は？といった質問が少なくなった
- ワークがスムーズに進むようになった
というようにプロジェクトメンバーから好評をいただきました。
メリット
さらにこの結果から
- 自分の理解度を他人と共有しやすい
- ユーザーの行動・思考・感情を短時間で読み取れる
- ペルソナ・前後の文脈・ゴールを意識できる
というメリットがありました。
同じ言葉を使って説明しても、思い描くシーンにズレが生じることがありますが、絵にすることで認識のズレが減って、他人と共有しやすくなります。
ペルソナや前後の文脈、ゴールを描くので、それを一貫してズレなく描けることが強みだと思います。
内容は以上になります。
大森さん、ありがとうございました！
続いては、パーソルキャリア株式会社の古藤さん・前田さんの発表です。
dodaサイトにおけるデザインシステムの構築・浸透の取り組み
古藤：「dodaサイトにおけるデザインシステムの構築・浸透の取り組み」というタイトルで、前半にデザインシステムのプロジェクトとしての全体観とデザイン面の説明を私から行い、後半に技術面の話を前田からお話したいと思います。
dodaではUXの向上に向けていくつか取り組んでいることがあります。その取り組みの1つであるデザインシステムの話をするにあたって、まず「UXとデザインシステムの関係性」について説明させてください。
上図の左側のように、開発の中での課題から工数やスケジュールが優先される中で、どうしても見た目としてのデザインの優先順位が下がってしまい、結果的にユーザビリティの低下を招くことが多くあります。
これに対して上図の右側のように、各種課題の解決が見込めるデザインシステムを置くことで、デザインの統一がされやすくなり、結果的にユーザー体験の向上に近づくと考えています。
UXとデザインシステムの関係性をお話しできたかと思うので本題に入っていきます。
ここからは具体的なdodaサイトのデザインシステムについてお話します。
dodaで構築したデザインシステムは、通称「IO（イーオ）」という名称で社内に広めています。
このIOの構築を開始したのは2年半ほど前からで、構築当初のデザインデータはXD、コンポーネントライブラリーはHTML／CSS版でしたが、それをFigma化したりReact版を提供することで、現在まで進化をしてきました。
dodaとはパーソルキャリアが運営する転職情報サイトおよび、転職に関連したサービスを展開するブランドです。本日お話するIOは、このサイトの中の「求人を探す・紹介してもらう」という領域をメインに運用しています。
このdodaサイトですが、恥ずかしながらよく見ると同じようなパーツでも絶妙にデザインが違っていたり、ソースコードを見ても適切なクラス名が付けられていないものがありました。
ではなぜ、こんなことが起きるのか。
それは、「求人を探す・紹介してもらう」の領域だけでも、100名弱の関係者がいるのですが、時に明確な答えのないデザインの意思決定に複数の関係者がいるため時間を要しまったり、スケジュールの関係で、やむなく行った部分最適でのデザイン推進が起因しています。
その結果、ユーザーが見えるデザインに誤差が生じてしまい、欲しい情報を取得しづらい（分かりづらい）状況になっていました。
これらの課題を解消するため、dodaサイトのデザイン標準を定義して、コンポーネントをまとめたデザインデータとそれに紐づくコードを提供するデザインシステム構築のプロジェクトが発足しました。
デザインシステムを構築することで、デザインが統一され、工数削減も狙え、そしてユーザビリティの向上も期待できます。
運用体制については、デザイナーが1〜2名、エンジニア2〜3名の全て兼務メンバーで構築運用しています。
ここからはデザイン面で、やってきたことを交えてお話します。
デザイン面でお話することは「デザインデータの作成」と「浸透活動」の2点です。
まずはデザインデータの作成についてです。
当時、簡易的なコンポーネント集は存在していましたが、サイト全体を俯瞰したコンポーネントデータはありませんでした。
そのため、当時メインで使っていたプロトタイプツールであるXDで、100以上ある画面を俯瞰して、定義されたデータを作成し、一気にコンポーネントを作りきって浸透させることにしました。
全画面のコンポーネント定義にあたり、具体的には
- 100画面キャプチャ取得する
- 要素をバラバラにする
- グルーピングする
- 各コンポーネント精査
- 他社を参考にしてグルーピング精査
- 全てXD化する
という流れで作成しました。
進めていく中で、現状あるものをブラッシュアップしたくなりましたが、それをするとコンポーネントがまとまらないので、その気持ちを抑えて、まずは現状のデザインをまとめて、そのあとにコンポーネントのブラッシュアップを行うことにしました。
Figma移行
続いて、デザインデータのFigma移行についてです。
XDでのデザインデータの構築完了からおよそ1年3か月後にFigma化の対応を行いました。
その背景としては
- doadサイトとして、React化の流れによるコンポーネントの分類見直しの機会があった。
- XDのメンテナンスモード期間の突入＝事実上XDの終了を意味する
ここからエンジニアとコンポーネントの分類検討と、デザインデータ作成の日々が続きました。
浸透活動
IOの運営メンバーとIOの想定ユーザーそれぞれの運用フローを検討したり、コンポーネントの分類に馴染みのないエンジニアに、分かりやすく共有をしたり、コンポーネントの追加・修正の基準となるようなフローを検討したりしました。
その後、これだけの期間と工数をかけたデザインシステムの施策に対して、成果や効果の照明を求められるようになります。
成果や効果の証明となる参考事例があまりなかったので、アンケートやバックログでの施策のカウント方法などを検討して、オリジナルで指標を作りました。
浸透施策で一番大事だったのは、「草の根活動」だったと感じます。
dodaの開発関係者はとても多いので、直接会話をすることで繋がりが持て、声を収集できるようにしました。ある程度の繋がりができたタイミングで説明動画を作成し広範囲に届けました。
浸透施策でもう一つポイントとして紹介するのは「盛り上げ施策」です。
盛り上げ施策として、IOのロゴは汎用性も高いので、グッズなども作成しました。
デザインシステムの施策方法は他にもあると思うので、ぜひみなさんの組織に合ったものを検討してみてください。
デザイン面のまとめ
デザインデータ作成
他社事例をふんだんに分析させてもらいながら、dodaの最適解を考えつつ取り込めるところは取り込んでいきました。
浸透活動
他社でも自信を持って「浸透したよ」と言い切っているところやビジネス観点踏まえデザインシステムの存在意義を効果として証明している他社事例を当時聞かなかったので、dodaとして現実的な、とにかく考えうることをがむしゃらにやり抜いた。
技術面での展開
前田：続いて、技術面については私から説明させていただきます。
まず、dodaサイトでは大きく技術が変わったことがありまして、元々はJavaで構築されて、その中でテンプレートエンジンを利用して、画面はHTML/CSSで構成されていました。それをある時から、Next.jsで構築しようという動きが出てきました。
Javaアプリでの展開の場合では、パーツで定義されているので、これらをそれぞれHTML/CSSで構築してマークアップして、実際に使うときは共通サーバーにCSSを配置して、それを各開発部署などでページで読み込んでもらう形で対応していました。
一方、Reactでの構築の場合では、Reactコンポーネントライブラリを使用しました。コンポーネントライブラリとは、見た目、機能をエンジニアが使いやすいようにある程度定義して、パーツとして提供しているものです。
下記の画像はReactコンポーネントライブラリでのソースコードの一例です。
このようにして、HTML/CSSからコンポーネントライブラリへと変遷していきました。
今回は、「どうやってReactコンポーネントライブラリを提供していったのか」や「HTML/CSSからどういう風にアップデートしたのか」について深掘りしたいと思います。
HTML/CSS版での課題点とReact版での改善点
HTML/CSS版での課題点は、ソースコードを生で管理していたので、古いバージョンや新しいバージョンのソースコードが全部同じ場所に共有されており、その結果、画面ごとに読み込むCSSが異なり、つまり画面デザインが変わってしまう点でした。
では、React版ではどうしたかというと、ライブラリで提供することで解決したいと考えました。
そもそもライブラリはバージョンを管理して運営していくものなので、基本的にはインストールすれば最新のものとなり、その後はチームごとに更新してもらうようになっています。
それに加えて、SlackやTeamsなどで、エンジニア向け全体に周知しました。
それと「提供パーツの再定義」を行いました。
これまでは小さいパーツも大きめのパーツも同じ粒度で管理されていました。これの辛いところは、仕様変更されるとデザインシステムも更新しなければならないため、デザイン以外の要件でコードが変わってしまい、その都度更新をかけなければなりませんでした。これでは運用側も使う側も大変です。
そこでReact版では汎用パーツと固有パーツの2つに分類したことにより、デザインとして提供しているものはデザインが変更されたときのみ更新されて、仕様変更の際には使っている人で対応してもらえるようになりました。
技術面のまとめ
開発体制がHTML/CSSからReact基準になったため、ライブラリ化含めいろいろな恩恵がありました。そして、運用しやすい形で構築することで、長い間UXを安定して提供できます。
構築・運用を通して思ったこと
デザインシステムの構築から2年半が経過して、その中でポイントだと感じたことを3点共有します。
【順応】
- XD→FigmaやHTML/CSS→Reactのように技術もツールも変化していく。
- デザインシステムは育てていくものと言う前提で時代の流れや外部環境に順応しながらブラッシュアップをかけていく。
【理解】
- プロダクトの成長という共通の目的に併せて理解を仰ぎつつ、デザインシステムの重要さを伝える。
- プロダクトの成長にデザインやいいコードは欠かせないはず。
【継続】
- とにかく、続けること。
- 浸透は構築よりも難しいということを念頭に。
- 成果を確認しつつキャリアと結び付けモチベーション維持。
古藤さん・前田さん、ありがとうございました！
続いては、株式会社LIXILのフジタさんの発表です。
こんがらがった糸を解きほぐす / UXデザイナーの試行錯誤ぶり
フジタ：LIXILは製造業なので、デザインといえばインダストリアルデザインが主力です。例えば、キッチンやトイレなどの「モノ」が主な対象です。とはいえ、IT技術の浸透とともに「コト」のデザイン（サービスデザイン）の重要性も高まり、このような流れの中で2016年にLIXILに入社し、デジタル領域におけるUXデザインを担当しています。
インダストリアルデザインには専門のチームがありますが、デジタル領域には専門チームがなく、今のところ私1名がUXデザイナーとして、様々なプロジェクトに参画しています。
LIXILのUXデザインの取り組み
UXデザインといっても領域が広く、UXリサーチャーとして、「UXリサーチのみ担当」、サービスデザイナーとして「機能要件を決めるところまで担当」、あるいは、UXデザインとUIデザインの領域が被っているところから、「UI設計のみを担当」など、分割した役割で業務にあたる方も多いと思います。
一方、私の場合は「コト」のデザインを全部見るというスタンスで仕事をさせてもらっているので、下図のジェームズ・ギャレットによる5段階モデルのところの「戦略」から「表層のUIデザイン」のところまで、参加するプロジェクトの状況に応じて対応しています。
ギャレットの5段階モデルとUXの時間軸を重ねて見るとわかりやすいと思うのですが、UXが関わる部分は広範囲になり、どこか一部だけやってもあまり効果がでないことがわかっているので、できるだけ戦略から、インタラクションまで関わるようにしています。
基本的には最初から最後まで担当するスタンスでやっていますが、プロジェクトによっては一部だけやってほしい、というリクエストをいただく場合もあります。一部だけ携わるのは、UXデザイナーとして価値を出しづらいことがあります。
今回は、そんな価値の出しづらいシチュエーションの中で、私がどのようにして対応していったのかをお話します。
一筋縄ではいかない事業ドメイン
入社したてのころに、「製造業では独自のやり方を持っているから、ITの人たちのやり方は通用しづらい」と言われました。製造業の事業ドメインは、「製造（LIXILはここ）→流通店→販売店→施工店→施主（一般のお客様）」と、いわゆるエンドユーザーのもとに商品が届く前に、多くのステークホルダーが介在しているので、一辺倒なメソッドは通用しません。今まで私は比較的シンプルな「サービサー→ユーザー」という世界で仕事をしてきたので、なかなかうまくいきませんでした。
失敗のよくあるパターン
①主語がでかい
たくさんのステークホルダーがいる中で、主語が大きいままに扱うと、結局だれのことかわからなくなってしまいます。また、「顧客」といっても様々な状況にあるので、主語がざっくりしているせいで、その状況を捉えきれないのも失敗の要因のひとつになります。
②課題がでかい
ステークホルダーの主語が大きいままに課題を考えてしまうので、もちろん課題もざっくりとしてしまい、大きくなります。扱えるサイズの課題になっていないと、適切な手法も採用されず、その結果解決策もなんとなくふわっとしたまま、効果が図れません。
このように、混乱したままUXデザインに取り組もうとしても、思ったような効果が出ません。
プロジェクトの実例
実例として、
- 法人のお客様向けにLIXILの商品情報を紙のカタログの代わりにインターネットで参照できるサービスをつくりたい
というプロジェクトを担当しました。
いつもなら、冒頭にお話した通り、戦略からプロジェクトに入るようにしていますが、このプロジェクトでは、UIデザインのフェーズから入ることになりました。
私が入った段階ではすでにサービス企画が立てられており、ワイヤーフレームを渡されましたが、使う人が誰なのか、どんな状況で何を目的に使うのかが不分明なままだったので、最適な情報提供がどのような形になるのかもわからないままUIデザインに入ってしまいました。
つまり、「何を作るべきかの基準が明確でないまま制作を進めることになってしまった」のです。
このような形でサービスを作ると、提供者側も、利用者側にもストレスが生じます。このまま進めてはいけないと思い、まずは、｢誰のために何を作るのか｣｢誰のためのサービスなのか｣ということを明確にするべきではないか、と考えました。
作り手（LIXIL）側の課題や問題設定はしっかりとなされていたのですが、使い手（お客様）側の課題は見立てられていませんでした。「誰がユーザーなのか」「そのユーザーはどんな状況で、どんな課題を抱えているのか」「そのユーザーはどんなことが達成できればこのサービスそ使う価値を感じるのか」これらに対して、仮説も見立てもなかったのが、混乱の源泉だったように思います。
混乱から抜け出すためのプロセス
この混乱から抜け出すために用いたのが「人間中心設計（Human Centered Design）」という手法です。
HCDは、国際規格のISOでも定義されているプロセスですが、「人間中心設計」の名の通り、「使う人がどんな状況にあり、どんなことをしたくて、どんなことを達成すれば満足するのか」という一連の流れを分析・検証していきます。
このプロセスの最大の意義は、個人的には、「わかっていること」の総量が増えていくことではないか、と思います。
サービスを作るというのは不確実性が高く、”わかっていること”のほうが圧倒的に少ないです。HCDの採用により、”わかっていること”を増やし、｢この機能ならこういうユーザーに納得してもらえそうだ」｢これならこういうユーザーにとってハズさないものになりそうだ｣というように、仮説検証を繰り返しながら「わかっていること」を増やす手続きだと考えています（もちろん、HCDを採用したとしても、プロダクトは市場に投下するまでその価値がわからないものであり、確証にはなりえません。あくまで仮説の補強です）。
登場人物を整理し、利用状況を見立てる
このHCDを採用するために一番最初に行ったことは、登場人物を整理し、それぞれの人物ごとにどんな利用状況にあるのか事実と仮説とともに書き出すことでした。
課題を分割する
登場人物とその利用状況が整理されると、その人たちがどんなことを成し遂げたいと思っていて、どんな課題をもっているかが見えてきます。これに対して初めて機能を考えることができます。
このやり方は構造化シナリオ法に基づいています。サービスを考えるときには、ついインタラクションを考えてしまいます。今なら「ChatGPTを使って◯◯」というようなアイデアが先行してしまいますが、しかし、この段階で必要なのはそのようなインタラクションではなく、バリューとアクティビティです。HCDを採用することで、利用者の状況と成し遂げたいことにフォーカスできます。成し遂げたいことの仮説のうえで、インタラクションを考えます。
サービスブループリントで見立てる
最後に、サービスブループリントを採用し、私たちが見立てている「機能」と「体験」を時系列で可視化させます。このサービスブループリントを書き終えて、ようやくUIに入ることができます。
まとめ
今回はHCDがハマりましたが、すべてHCDで解決できるとは考えておらず、プロジェクトの目的や状況によっては他の方法を採用するほうがよいときもあると思います。
また、課題を見つけられたとしても、解決しようとする課題が大きすぎると扱いに困りますし、課題が大きいまま格闘しても思ったような効果は得られません。よって、扱えるサイズに砕いていくことが重要だと考えます。
フジタさん、ありがとうございました！
続いては、Q&Aのコーナーです。
Q＆Aコーナー
続いてQ＆Aコーナーであがった質問を紹介します。
（Q）9コマシナリオというのはUXデザインでは一般的なものなのですか？（エンジニアの立場で聞いてしまってます）むっちゃこれいいですね！
大森：社内ではみかけないですが、大学ではこれを書くのが一般的でした。そこで、仕事に取り入れました！
（Q）コマで一番難しい箇所、比較的簡単な個所はどのあたりになりますでしょうか？作成時のポイントはございますか？
大森：ペルソナ設定がズレるとその後もズレるので、「ペルソナ設定」が難しいと感じています。基本に忠実に書いていくのがポイントです。
（Q）そもそもペルソナ設定が難しいです。。。
大森：社内に向けたサービスを作る部署なので、こちらでペルソナとなる営業さんへアプローチできています。
（Q）これから目指すこと聞きたいです
大森：１００人中１００人が知っているプロダクトを作る人になりたいです！
（Q）開発チームとの連携で壁はありませんか？また、その壁をどうやって乗り越えた、みたいな工夫があればお聞きしたいです
古藤：壁はありました。スキルの壁です。デザインを作ったのはいいが、適切なクラス名をどう付けるかで悩むことがありました。また、1px の修正など細かい修正がエンジニアに負担をかけることもありました。デザイナーがGitを覚えて、簡単な修正はデザイナー自身で行うようにしました。
前田：ユーザー側との壁がありました。前提として、まだ日も浅いサービスで、開発者側の想いをユーザーに伝えられている点は、チートっぽいですがよいです。使い方を明記する必要性は感じています。草の根活動が必要だなと思っています。
（Q）関連部署が多そうですが、横串はどうやってますか？オンラインチャット上なのか、定例会なのか、直に合うとか。オンボとかも含めてなかなか大変そう。
古藤：めちゃくちゃ大変です。スクラムが複数あって、このスクラムマスターを訪ね歩いています。その中でキーマンとのコミュニケーションを大切にしています。
メンバーの負担や人の入れ替えのあるスクラムがあるので、今後QAチームとの連携をしたりと良い仕組みを作っていきたいです。
（Q）開発メンバーもデザインの素養があったり理解があったりしたのでしょうか？
前田：フロントエンドエンジニア程度の素養があります。デザイン側の立場に寄り添った理解を持って開発しています。
（Q）浸透活動への施策が素晴らしいですね、こういった策定は単独でUX部署が決めていくのでしょうか？それともPJ全体での確定でしょうか。また、一番困難だった点も参考までにお聞きしたいです。
古藤：プロジェクト全体での確定です。デザインシステムのメンバーで粛々と行っています。ユーザー対象者にアンケートを投げてもなかなか回答もらえなかったり、、などの困難がありました。
（Q）Figma上のコンポーネントライブラリと、技術側のライブラリで、切り分け方をどの程度一致させていますか？
古藤：完全には一致できていないです。Figmaの運用は最近始めたばかりで、現時点では無理に一致させることはしていません。
（Q）製造業とSaaSだと全くUXデザインも異なりますよね、もっとも異なる意識部分はどのあたりでしょうか？
フジタ：実物のモノ（トイレとかキッチンとかドアとか）があるということと、物理的にそれらが大きく、製品的に施主（住んでいる人）が直接的に扱えなかったり、施工店やショールームスタッフなど、物理的に接点をもつステークホルダーが多いというところが特徴的かなと思います。
（Q）B2B2C、これUXデザインとしては実際どこに注力すべきか、むずかしそう。政治的圧力とかなんというかが多そうだし、中間管理職的なつらさもキツそう(;'∀')
フジタ：プロジェクトメンバーやリーダーたちが、UXデザインを実践する意義を必ずしも感じているというわけではないので、仲良くならないと話を聞いてもらえないという経験はあります。入社当初はつらい経験もいくつかありましたが、もうLIXILに所属して長いので、「フジタが言うならまあやってよ」と言ってくれるリーダーやメンバーが増えてきました。（ありがたいことに！）
（Q）UIデザインフェーズから入ることになったというのは前任者からの引継ぎでしょうか？それともそもそもそのタイミングまでUX担当者がいなかったのでしょうか？
フジタ：私が入るタイミングまで担当者がいませんでした。そもそもこういうとりくみが必要だと思っていなかったのかもしれませんし、「顧客のことを考える」は誰でもできることなので、必要ないと思って走っちゃったのかなという気はします。
（Q）HCD初めて聞きました
フジタ：HCD（Human Centered Design）は人間中心設計と呼ばれるものづくり・コトづくりのプロセスです。国際規格であるISO 9241-210:2010で定義されています。
ご参考）https://www.slideshare.net/masaya0730/iso92412102010
（Q）UX改善の取り組みはどういった形でPDCA回されていますか？ UXへの投資基準はどんな流れで決まってきますか？(例えばユーザーインタビューに毎年300万円の予算枠があるとしたら、その枠はどういった背景・経緯でそこに至ったのか？) また、UXへの投資結果として、どうやって評価されていますか？
大森：社内に依頼してインタビューしています。(＝予算などは関係ありません)
投資の結果については、ベンチマークしてKPIとしてどれくらい作業時間が削減されたかなどで判断しています。
古藤：（話せる範囲で。。）
社内向けでサクッとやっているところはあります。フィットするユーザーにインタビューできるといいのですが、社内で近い人とインタビューをしあったりしています。
フジタ：明確にUXに対しての投資がなされているプロジェクトはなく、プロダクト改善の運用費として予算がとられていることがほとんどです（そこからUIであったり、体験の改善だったりのコストがあてられる形）。だいたいは四半期に1回のチェックでPDCAを回しています。
（Q）各部署でUXの改善に関心を持ち、積極的に取り組んでいただくためには各部署に対してどういったアプローチが良いですか？良い布教方法があればお願いします。
大森：ディップでもこれから広めていくところです！
古藤：「小さく回して、効果が出たところに興味をもってもらう」手法がおすすめです。
前田：ユーザー体験に繋がる前の話で、パフォーマンスなどの数値化できる目標があると、興味を持ってもらいやすい。SEOだとサイトパフォーマンスの数値など。
フジタ：私自身、とても悩んでいるところです……社内勉強会をやっても勉強会だけだと浸透しづらい。LIXILには自分の稼働の20％を他の業務に割り当てられるという制度があるので、興味をもった若手を引き込んで一緒にやる、という草の根活動をしています。が、これも限界があるので、別のアプローチも模索しているところです。
（Q）UXの効果は見えにくかったり、でも見ようとしても「UXはその性質上、可視化しようと数値化すべきでない」という意見もあると思います。効果を実感するためにはどんな方法が良いですか？逆にUXが悪化しだすとどこに最も早く影響が出てくると感じますか？
大森：目標に対してKPIを策定し、UXの効果を測定しようと試みています。例えばタスクの成功率やエラーの頻度などを、改善する前と後で比較して結果を考察するなどということをやっています。悪影響はわかりません！すみません！
フジタ：個人的には、えらいひとたちにはサービスなどの利用者によい体験を提供するというとりくみに効果とか数字ごちゃごちゃ言わないでほしいと思っているのですが、そういうわけにはいかないので、UXの向上がコンバージョンに貢献するという前提でKPIを設定しています。UXが悪化すると、営業やコールセンターにクレームのお電話が入ります。
（Q）これは各社さんにお聞きしたいのですが、UXデザインにおけるもっとも大事なことは何でしょうか？あと、人が大事でしょうか？プロダクトが大事でしょうか？ブランドが大事でしょうか？
大森：どれも大切ですが、人やそのマインドが大切だと感じています。自分達のこうしたいや管理する側の要望を聞き入れてしまうと、ユーザーにとってはノイズが多いプロダクトになってしまうので、ユーザーになりきる（かなり解像度を高くしないと難しい）、そして俯瞰してフローを考えるという視点を持つことを常に心がけています。
フジタ：UXデザインを実践するためのマインドやスピリットでいうと、「人間に興味がある」ことが一番大切だと思っています。人間に関わる活動なので、人もプロダクトもブランドも全部大事だと考えます。
（Q）UI設計もかじっているエンジニアです。周りの人間はエンジニアが多く、デザイン話がうまく伝わっていない現状があります。デザインに詳しくない人間にうまく伝える大変さは各社さんありますか？
大森：とても大変で絶賛苦戦中です！そんな中で上司に教えて頂いて気づいたのですが、うまく伝わらない時自分の主語と相手の主語が異なっているということです。UXに知見のあるグループでの会話は自然とユーザー主語で話が進んでいくのですが、非デザイナーとの会話では機能やペルソナ以外の人物が主語になり、うまく話は伝わらないしプロダクトの軸はずれてしまうということがあるので、主語を合わせながら話を進めていくことが大切だと感じています。
フジタ：大変です！ ただこちらも開発のことがわからないので、そこはお互い様かと思います。専門用語を使わない、サンプルをいっぱい出す、共通言語を増やしながらコミュニケーションをつづけていくのがなんだかんだで早道なのかなとも思います。
（Q）ジャーニーマップをまとめる時は何人位で打ち合わせ決めていくのですか
大森：大体インタビューの結果などから1人でたたき台を作成し、3〜4人でブラッシュアップを行い、MTGの報告でチームメンバー（10人程度）の方々から確認いただくことが多いです。
フジタ：基本的にはリサーチに関わったメンバー、コアメンバーなどで、5〜6人くらいかなと思います。ワークショップだともっと人数が増えますが、ステークホルダーが多いとまとまりづらいので、少数精鋭でまとめることが多いです。
（Q）これまでで工夫されたUXの事例があればを教えてください
大森：新しいプロダクトの画面を作成した際に、情報過多の画面があったので、UXの前にワーキングメモリや認知負荷の説明をして構造について検討するということをしました。これを使うのは人間なので、そういった行動のメカニズムを知ることで、より自然なUX、ユーザーにとって使いやすいプロダクトになれると考えています。
フジタ：設計やプロトタイピングでは実際の利用状況の再現にこだわっています。本当にそういうシチュエーションがあるのか、現場に確認しながら設計しています。
また、検証において得られる成果を限定的にしています。一度にいろんなことを検証しようと思っても、複合的な事象だと因果関係・相互関係を紐解くのが難しいからです。
いかがでしたでしょうか。皆さんがサービス開発時の技術スタック選定において少しでも役に立てればうれしいです。
次回のイベントレポートもお楽しみに♪
