こんにちは！TECH Street編集部です！
2024年5月23日（木）に開催した、 「UXデザイン勉強会vol.6」のイベントレポートをお届けします。TECH Streetコミュニティ恒例の事例・知見共有勉強会。 今回はチームラボとパーソルキャリアのUXデザイナーが各社の取り組み事例を発表したのでその様子をお届けします。
登壇者はこちらの方々！
松森 裕真/パーソルキャリア株式会社
伊藤祐春/チームラボ株式会社
早速、内容を紹介いたします！
まずは、パーソルキャリア 松森さんの発表です。
書籍「デザイントークンのつくりかた」の輪読会をしてみて
松森：弊社では社内の有志が集まって運営しているコミュニティ「UXDIG」があり、エンジニアリングとデザインが交わる領域の開拓や探求をテーマに活動を行っています。そのコミュニティで、先日「デザイントークンのつくりかた」という書籍の輪読会を行いました。
今回は輪読会を経て得た知見などを共有します！
デザイントークンってなに？
そもそもデザイントークンとは、デザインを構成する「最小要素」を定義する方法論で「一貫性」のあるデザインを実現してくれるものです。
一貫性がもたらすメリットは大きく以下の2つがあります。
- 利用体験的側面
- ブランド資産的側面
他にも関わるメンバーがデザインに対する共通認識を持てたり、1つのソースからWeb,ios,androidなど様々なプラットフォームに展開できます。
このようにいろいろなメリットがあるデザイントークンですが、その設計についてお話します。
デザイントークンを設計するためには
デザイントークンを設計するには、以下の4つを行います。では、それぞれ細かく見ていきます。
- 観察する
- 分類する
- 記録する
- 整理する
観察する
まずはプロダクトで使われている断片を収集して階層構造として整理します。
UIやコミュニケーションのタッチポイントであるビジュアルデザインをくまなく観察し現状を把握するところから始めます。
分類する
次に「分類する」です。これは
- プロダクトのアイデンティティを決定づける要素
- ポジティブな印象やネガティブな印象など同一の文脈を持つ要素
- 同様の機能を持つ要素
これらの要素をできるだけたくさん洗い出して共通項でグルーピング＆命名します。
記録する
次に「記録する」です。
同じグループなのに見た目が違うものを｢揺れ｣と表現しますが、それを観測して記録します。
統一できていなかった場合は直したくなりますが、それをグッとこらえて記録し、チームで共有し議論します。また｢使うかもしれない｣というものはほとんど必要になることがないので入れない、必要になったら加える、という方針で進めていきましょう。
整理する
最後に「整理する」です。
書籍内では主要な大手プロダクトが使っているデザイントークンを収集分析してくださっていますが、それらをもとに
- 原始的な値のレイヤー
- 参照レイヤー
- 意味的なレイヤー
- 成果物レイヤー
以上大きく4つの階層を提示してくれています。
大枠の構成は「色」「タイポグラフィ」「サイズ」「シャドウ」「不透明度」という5つの項目を定義する認識で、それぞれに先ほどの4階層の深さを持っているイメージです。
社内事例のご紹介
具体的な社内事例は以下になります。
PERSOL MIRAIZ
開発中の新規プロジェクト
HR forecaster
社内事例を眺めてみて
これらの社内事例を眺めてみてみると「デザインと実装でトークンを完全一致させる」というのを初手で目指すことは目標が大きすぎるということに、気づきました。
そこで、デザイナーとエンジニアで共通認識にできる命名規則を作り、スケールの認識をそろえるという部分がまず目指したい妥当なラインだと感じました。
社内事例を参考に定義方法を考える
これらの社内事例を参考に、デザイントークンの定義方法を考えてみました。
まずは「最小単位、スケールの認識を揃える」です。これについてはあまり難しくないのかなと思います。
次に「デザイナーとエンジニアで共通認識にできる命名規則を作る」です。これに関しては、デザイナー目線よりエンジニアの知見を借りた方が早いと感じ、エンジニアへ話を聞きに行きました。
すると、以下の要素からおのずと命名規則はすでにあるor自然と決まってくるパターンが多いらしいとわかりました。
- 使用言語の推奨方針
- 各PJでのコーディングガイドラインの方針
- 導入しているUIライブラリの推奨方針
そのため、命名規則をエンジニアさんと揃えたかったらとりあえずエンジニアさんに聞きに行って、エンジニアさんが持っている方針をたたき台にして決める、という方法が良さそうだなと思いました。
また命名規則の設計に関してはプリティクス的観点でアルファベット順に並べられるケースが多いため、親しい要素が隣り合うように設計したいという思いがあるようです。
つまり大きい概念から徐々に細部の小さい概念が記述されるような命名規則が求められます。
とはいえ、Webやデジタルプロダクトでは「どの要素が親で子になるのか」の判断が属人化してしまうケースが多いです。また、すべてを洗い出して順序を定義するには手間がかかり過ぎてしまいます。そこで、何か参考になるものを…と探して見つけたものが以下の記事です。
この命名規則モデルのありがたいところは、横断的な概念要素に対して親子関係を明快にしてくれているところです。まさに、先ほどお話した悩みを解決してくれるものです。
この「Semanticにおける命名規則モデル」をざっくり説明解釈したのが下図となっています。
デジタルプロジェクトにありがちな要素を大きく4つのグループに分類し、それらをさらに大・中・小の3段階の階層に整理して、どの順番で記述すべきかを指定してくれています。
この場合、ドメインが一番大きな概念なので頭につけて、徐々に小さな粒度になっていきます。大項目に所属する要素は重複していたりスキップされることもありますが、ほぼ迷うことなく命名ができます。
ここまで紹介してきましたが、「命名規則について正解はない」と各所で言われています。今回においてもこれは正解ではなく一つの参考として捉えていただければと思います。皆さんのプロダクトと照らし合わせてベストな命名規則をチームで開発してください。
デザイントークンはいつ導入すべきか？
それでは、デザイントークンはいつ導入すべきなのでしょうか？
開発には大きく分けて3つのフェーズがあると思います。これらの3つで、導入コストやプロジェクトの不確実性が高いor低いで分けてみました。
0→1フェーズでは導入コストは低いですが、組み上げている最中なのでプロジェクトの不確実性は高いです。そのため、せっかくきっちりと作ってもリリース前に｢やっぱりやめておきましょう｣といったビジネス的な判断や、サービス自体が大きく形を変える可能性があります。
1→100フェーズではすでにサービスがリリースされた後で、プロダクトの提供価値も安定してきているため、不確実性は比較的低いと思います。しかし成熟しつつある状況なので、導入コストは高いと思います。
これらを考慮すると、1→10フェーズ、つまりファーストリリース後でこれから体制を整えようと、チーム全体の意識が向いているタイミングが最適だと考えます。
そうは言っても、どのフェーズであっても早さと手軽さを求められますし、導入コストは低いに越したことはありません。
Primitive TokenやReference Tokenは決めの問題ですが、Component Tokenはプロダクトの状況に大きく左右されるため、最大公約数的なものを見つけるのは難しそうです。
しかしSemanticTokenではそれらを作れそうですし、ここに叩き案があると導入コストも下がるのではないかと思います。
Semantic Tokenの叩き案を作ってみた
そこで、Semantic Tokenの叩き案を下記のように作ってみました。今回は重要そうな「色」「タイポグラフィ」の2つに絞って作成しました。
まず色からご紹介します。大まかな構成は、｢どこで使うか｣と｢何色を使うか｣を指定する構成です。
どこで使うかに関してはコンポーネントトークンの領域になるので、今回は省略します。
何色を使うかについては、TokenName1と2で構成しています。
TokenName1では色の種類、TokenName2では明るさを定義しています。
TokenName2で、6段階の理由はtext,border,Focusは他の配色と重複しても問題ないと判断して6段階にしてみました。
次に、タイポグラフィについてです。
コンセプトとサイズを組み合わせて構成する作りになっています。
コンセプトとサイズをTokenName1とTokenName2に割り当てて、それらを組み合わせる形で構成しています。
以上が、私が考えた叩き案です。細かく見るとツッコミどころはいろいろあるかもですが、少しでも皆さんのデザイントークン作りの糧になれば幸いです。
まとめ
デザインシステム然り、デザイントークンもエンジニアとデザイナーの共通言語を作ることで、「職能ごとの分断を防ぎ、開発チームとの連携を強めるツールになる」という側面が実は一番でかいメリットなのではと思います。
自分自身、UIUXデザイナーを名乗っていますが、UXもプロダクトもチームで作るものだと思っています。皆さんのチームでもBTC（B＝Business、T＝Tech、C=Creative）連携を強めてよりイカしたプロダクトづくりをしていただけると幸いです。
発表は以上です。
松森さんありがとうございました！続いては、チームラボ 伊藤さんの発表です。
思考の体系化でチームアプトプットを底上げする
伊藤：チームラボといえばアートを手がける集団というイメージが強いかもしれませんが、実はソリューションからはじまった会社で、事業規模もアート事業を上回っています。これまでも金融業界や不動産、アパレルやスポーツなど多岐にわたる業種のクライアントからお声がけをいただき、プロダクト開発をしています。
全社で1,000人いるなかでエンジニアは全体の7割に該当します。ソリューションに関わる人数は700人ほどで、デザイナーはおよそ20名在籍しています。これまでの案件数は100件を超えています。
チームLabの一気通貫プロダクト開発フロー
チームラボではすべての職種が会社に揃っており、構想策定から開発、そしてその先の運用まで一気通貫で手がけています。チームラボのデザイナーはすべての工程に大なり小なり関わり続けるポジションであり、プロジェクトにアサインされた瞬間からプロジェクトに関するデザインについて考えています。
要件定義から参加し、デザインフェーズを担当するのはもちろんのこと、エンジニアと実装の相談をしたり、リリース後にはデータサイエンティストと相談してUIを改善します。
しかし、デザイナー1人1人が異なるデザインの思想で、プロジェクトごとにすべてイチから作ろうとすると、工数も膨らむだけでなくチームラボとして提供するクオリティの水準を担保できなくなってしまいます。
そのため、思考の段階から一定の水準を満たさなければならないと考えます。
いかにチームの中でその思考がブレないかが課題となりますが、その取り組みとして、私たちは思考の体系化を目指しています。
思考の体系化とは
思考の体系化とは、例えばUIUXの設計を考える際に、「どのような観点で、どのような順番で思考して、さらにそれをどうレビューするのか」ということをすり合わせようという、カルチャー的なものです。
その思考の体系化のプロセスをフロー図にしたものが以下になります。
「原則」から始まり、「パターン」「設計」「ナレッジ化」へと進みます。それでは、1つずつ紹介いたします。
原則
「プロダクトがユーザーにとってどれくらい価値のあるものか、どのような体験を提供できるのか」の「原則」を考えるところからスタートしています。我々はここでユーザーファーストの体験設計を定義しています。
ユーザー体験を考えるにあたり、3つに分けた「パターン」からブレないように気を付けて設計していきます。
「設計」の中でも細かく分かれていて、体験や機能、情報、レイアウト、UIについて同様のパターンを用いて思考していきます。
「ユーザーのための体験を考える」ということは珍しい話ではありませんが、メンバー全員が同じ方向を見るということがポイントです。
思考プロセスを活用した事例
この思考プロセスを活用した弊社の事例をご紹介します。
北海道の安平町にて地震で倒壊した校舎を新しくして学校を建てようというもので、「地域と学校が一体になれるような空間を作ろう」というコンセプトがありました。
新しく校舎を建てるタイミングで、テクノロジーを切り口にして学校とコミュニティセンターを共存させる取り組みがなされました。
例えば家庭科室は地域の方がキッチンとして使えるようにし、美術室はアトリエとして使えるようになっています。
また、教室のドアや窓は大きくして廊下から見えるようにしています。それによって、生徒や地域の方がお互いのアクティビティを認知することができ、両者間の境界線を曖昧にすることによって共創の体験を生み出す空間づくりにしています。
これまで部屋というのは、1つ1つの空間が物質的に区切られていて、それぞれの空間にはそれぞれの機能が限定されていました。
例えば、小学校と公民館では下図のように区切られる場合があります。
ICTを活用
そこでICTを活用して、1つの空間に複数の機能を持たせることにしました。
例えば、ベッドやお風呂、キッチンが付いた空間をある時は「自分の家」として使い、あるときはそれを「ホテル」として貸し出すサービスが既に存在しています。
テクノロジーによって空間に｢モード｣という概念を与えられ、空間とユーザーの関係性も変わってきます。
安平町立早来学園の事例を先ほど紹介したパターン図に落とし込むと以下のようになります。
最終的なアウトプットとしては、施設を予約できるサイトを作り、各部屋の前に誰が何時に使うのかわかるタブレット案内を出すようにしました。このインターフェイスはサイネージとして町役場にも設置されているので、学校にいない人でも街のアクティビティを知ることができます。
また、学校関係者ではない人が出入りすることへの配慮として、安全性を担保するためにスマートロックとドアを連動させています。それらのシステム連携も弊社で開発させていただきました。
以上のような形で「空間を体験に合わせて最適化する」というソリューションを提供いたしました。
｢ユーザーの欲求｣｢を満たす手段｣｢を使うときに考えること｣を考え、それをさらに細分化させて、「これ以上無理！」というくらいまで考えていくと、｢つまり、こういうことだよね｣というものが出てきます。そしてそれこそが、本質的なソリューションになるだろうと考えています。
ナレッジ化
本質的なものは時代が変わっても変わらないもの、つまり普遍的だと思っているので、本質的なソリューションも自ずと似てくると思います。そこで、思考の体系化の最後にある「ナレッジ化（知の蓄積）」がとても大事になってきます。
パターンに沿って考えて導き出された本質的なソリューションは、別の案件でも積極的に使っていきます。我々は多種多様なプロジェクトを抱えていますが、横串で指してみると共通点が見つかることが多いです。
先ほどの早来学園様でのソリューションは、過去のオフィスビル案件で使ったソリューションと類似しています。
そのときのナレッジがあったので、早来学園様から相談があったときもスムーズに提案することができました。
まとめ
まとめると、本質を考え抜いたアウトプットをみんなで照らし合わせていきましょう。
答えが1人1人まったく違うものになってしまうと、クオリティも上がらずナレッジとして共有することも難しくなってしまいます。全体で一貫性を保って標準化することで、アウトプットの底上げをしていく＝それが思考の体系化です！プロセスを体系化するのは何においても可能だと思うので、それを汎用化することが大事です。
最後に、チームラボでは採用note「解体新書」でプロジェクトの裏側なども発信しているのでそちらもご覧ください！
発表は以上です。
伊藤さんありがとうございました！続いてはQ&Aコーナーです。
さん、ありがとうございました！
続いては、Q&Aコーナーです。
Q&Aコーナー
（Q）パーソルさん大グループ企業かと思いますが、UX・デザイン関連で横串の組織ってありますか？
松森：パーソルキャリアには「Nution」と言うデザイン組織があります。各事業を横断する形でデザイナーが所属している組織です。
https://nution.persol-career.co.jp/
（Q）「揺れ」を明確に気付けるようになるためには、経験を積むのみなのか、センスなのか、どのようにすればよいでしょう？
松森：先ほどご説明した通り、収集とグルーピング、観察・分類を粘り強く行っていけば、揺れが明確になってくると思います。
（Q）命名規則には、まさに困ってました。こちらパーソルさんも揉めにもめてだんだん昇華されてきた〜みたいな感じですか？社内でのUXデザイン関連の変革とか歴史とか聞いてみたい
松森：社内でも実現が難しいところです。チームが一丸となってUXづくりにコミットできる状態をめざすには、職能を横断する共通言語作りは不可欠だなという思いから、デザイントークンやデザインシステム構築に携わってきました。命名規則においても、いいルールを作りたいけど、難しいなぁと思い、調べてみた結果が今回の発表となります。
（Q）パーソルキャリアさん、UXデザイン関連の体制ってどのようになってますでしょうか？参考までにお聞きしたいです
松森：正確な人数は把握していないですが、デザイン職として、UI/UXデザイナーのほかに、サービスデザイナーとUXリサーチャーがおり、三職能が連携しつつ、企画職やエンジニア職の方たちと協力して開発を進めています。
（Q）パーソルキャリアさんに聞きたいです。 弊社にはデザイナーがおらず、エンジニアの感覚で実装されることが多いです。そういう状況下でデザイントークンを入れるメリットはあると思いますか？
松森：フロント周りのブレやデザインとの差異を減らすというメリットは出せると思います。社内でデザインに対して、どれくらいシビアに考えているかで導入するかどうかを検討してみてください。
（Q）UIUX改善に関する外部パートナーによる支援は受けておられますか？ 受けておりましたらどういった部分をお任せしていることが多いでしょうか？
松森：リサーチフェーズや、情報設計からUI設計フェーズで外部パートナーさんに委託する時があります。
（Q）UIUXデザインにおいてよく用いる専門知識として何かあったりしますか？ (心理学でも統計学でも何かしらの規格でも何でもOKです
松森：デザイン思考、OOUI、ユーザビリティ、ユーザ思考、人間中心設計、情報設計、ユーザーリサーチなどなど・・・・。他にもマーケやプロダクト開発に関する知見、エンジニアリングへの理解等書き出したらキリがなさそうですが、なにかを学ぶキッカケになれば幸いです。
伊藤：無限にあって書き切れないですが、デザインの世界においては、専門知識ではなくとも日々暮らしているだけでヒントが山ほどあると思っています！
（Q）過去に、UIUX改善したから大きく◯◯◯で成果が出た！といった事例はございますか？ ユーザー体験をよくすること自体は社内でも賛成してくれますし予算もつけてくれますが、どれくらい踏み込めるかがまだ不透明です。 出だしから滑らないようにしたいのですが、定番の改善ポイントはあるでしょうか？
松森：僕の場合0-1フェーズ＆1-10フェーズでの経験が多く、グロースフェーズの経験は多くないのですが、僕の場合、ドカ！っと大幅に数値が改善された！というより、徐々に数字に現れていったような経験が多いように思います。おそらく質問内容を読む限り、事業/ビジネスサイドにわかりやすく理解されるような成果を上げたいのかなと見受けられます。こういった場合具体の施策にいきなり手を出すより、まずはKPI、事業が追いかけている数字が何に紐づいているか？等、KPIを分析して理解することから初めてみると良いかもしれないですね。プロダクトが追い求めている数字＝ユーザーに行ってほしい行動なので、UIがそれらを促すように設計されているか？といった具合に事業成果とUIUX改善が噛み合っていくと思います。
伊藤：「定番」の施策はあるにはあると思いますが、定番に頼っていると次第に思考停止しはじめてそれこそ「滑る」ことになるので、その定番がほんとうにハマるかどうかの仮説を、面倒くさがらずに毎回じっくり検証するとよいと思います。
（Q）デザイナーと開発部署や他部署との連携はどのように円滑にされてますでしょうか？手段、ツール、頻度等アドバイスお聞きしたいです
松森：各職能の責任領域を明確にして、お互いがお互いに齟齬のない責任を果たし合うような体制を整えるのが仕組みからアプローチするチームづくりとしてお伝えしやすいかなと思いました。職能定義を各々作ってみて見せ合い、それぞれの職能から職能定義に対して付箋等でコメントをもらい齟齬を埋めるみたいなワークをやると円滑にいったりしました。あとはお互いにリスペクトする心を忘れないことですかね。
伊藤：ミーティングとレビューを頻繁に設けたり、席に直接話しに行くなど、全職種がひとつのビルに集まっているからできる柔軟なコミュニケーションが特徴だと思っています。チームラボはみんな出社スタイルですが、オンラインより対面で擦り合わせる方がコミュニケーションの解像度を高くできると考えています。
（Q）登壇者様のUIUXデザインの社内事情をお伺いしたいです。
Q1.UIUXデザイン改善への取り組みは既にかなり長いですか？
Q2.UIUXデザイン改善は何がきっかけでスタートされましたか？
Q3.社内では日々様々なWebマーケ施策が走っているUIUXデザインはどれくらいの位置づけで実施されていますか？
Q4.何か施策が実施されるときは常にUIUXデザインチームが参加する感じでしょうか？
松森：
Q1.私は1-0か1-10のプロジェクト経験が多いので、改善施策をガッツリ経験したかで言うとそんなに経験豊富なほうではないかと思います。
Q2.基本的に何かしらの方法でユーザーからの要望を企画/ディレクターが察知して改修を提案する流れが多いと思います。
Q3.施策内容にもよりますが、弊社の場合、UIUX領域が関与する場合は声がかかって一緒に進める形になると思います。
Q4.こちらも内容によりますが、UIUX領域が関与する場合は基本的に声がかかり一緒に進めることになります。
伊藤：
Q1.多くのプロジェクトにおいて、リリースしたあとの保守運用と改善施策は、長期で手掛けさせていただいております。
Q2.クライエント内で検討されてから相談を受けることもありますし、定期的に集まって議論することもあれば、自主提案することもあるなど柔軟に考えています。
Q3.フロント要件に関係する場合は、相談レベルでもデザイナーに声がけしてもらうことが多いです。
Q4.エンジニアだけで完了される施策には参加しないことが多いです。
（Q）弊社ではUXはなんとなくUIに含まれてきちんと検討せず流されてしまうことがあります。UX/UIデザインのプロセスで住み分け方であったり関わり方でよい例があれば教えてください。
松森：なぜ、このUIがそうあるべきか？を証明するためにUXは存在します。なんの目的で、どういった行動を促すためにこのUIになったのか？という問いに答える存在がUXです。
UIは手段であって目的ではないので、目的を明確化し、チームメンバーと共有することがUXの役割です。
伊藤：「UXコンセプトを定義する」をフローに組み込むことで、いやでも言語化のために思考および検討するステップを実現でき、UIデザイン決定における拠り所にもできます。
（Q）UIUXの勉強は何から始めたらいいと思われますか？ 私は4月からUXCoEに移動、チームも1月に立ち上がったばかりなので案件が少なく、チーム内のナレッジもない状況です。
松森：UIUXで有名な書籍を読んでみるとか、UIUX界隈のインフルエンサーのTwitter/Xを辿ってWebセミナーに参加してみる等してみるのはどうでしょうか
伊藤：勉強の前提として、課題と目的、そもそも何故やるのかを明確に定義することが超重要です。その目的にむかってインプット（知見を得る）→アウトプット（形にしてみる、分析する）をひたすら繰り返すしかないと思います。時間はかかりますが、近道もないと思っています。
（Q）UXデザイン関連のナレッジは社内でどのように管理・共有される仕組みになってますでしょうか。
松森：社内勉強会を定期的に開催し、プロジェクトを横断したナレッジ共有を促しています。有益なナレッジをシェアし続けるって地味に大変で、弊社でもずっと試行錯誤を繰り返して運用しています。ナレッジって自分自身で価値を判断できなかったり、そもそもそれがナレッジだと思っていないことがあり、そういった観点でナレッジを生む仕組みって難しいなと考えています。
伊藤：共有会が行なわれているのと、メンバー間での伝達が多いです。ナレッジを活かそうというマインドセットが大事です。
（Q）現在、UIUXデザインを学校で勉強しています。ポートフォリオはどういった点を重視しますか？
松森：
・ユーザーリサーチに興味関心があり、課題を発見できているか。
・課題に対してUXの仮説を論理的に組み立てられているか。
・仮説をプロダクトやUIに落とし込めているか
・表層表現にこだわりを持って作り抜いているか。
・PDCAが回せているか。（やって終わりではなくちゃんと振り返りをして次につなげているか）
弊社の場合、論理的思考とクリエイティブマインドの両立みたいな塩梅を気にしているかもです。
伊藤：
・ロジカルにデザインを組み立てているか
・そのデザインを通してどういう事象を起こしたいかをイメージできているか
・「こういうデザインを作るぞ」という意志が滲み出ているか
・そのデザインは美しいかどうか（見た目も、操作感も）
・ものづくりが好きそうかどうか
などを見ます。
あとは、ポートフォリオ自体のUXというか、見る人＝採用担当者の体験を考えて構成されているとおトクだと思います。
（Q）プロジェクトによりけりとは思いますが、UX設計にかける期間というのはおおよそどのぐらいでしょうか？もし目安があれば教えていただきたいです
松森：0-1フェーズですとかなり長めに取られると思います。1-10からグロースにかけて、徐々に減っていくと思いますが、大きな機能開発や、プロダクトのリニューアル等になるとまたUX設計の期間が必要になっていくようなイメージです。
伊藤：現実的かどうかはさておき、構想策定から要件定義まで半年くらいかけたいと思っています。運用を含めた広義で言うと、プロダクト自体の経年に合わせて細かい配慮まで考えていくとエンドレスです。
（Q）アプリ関連のイメージは全くなかったです。驚き。社内ではアート関連の部署との連携も濃密なのですか？
伊藤：頻度は多くないですが、随所で連携はします。アプリのデザインはUIUXチームが請け負い、CGアーティストに3Dイラストを作ってもらったりなどのコラボレーションは発生しています。
（Q）空間に対するUXデザインの考えは、アプリのUXデザインにおいてもどの程度ハマる・共通しますか？
伊藤：空間を訪れるまでから、空間に没入して、出ていった後のことまでを考える点では、UIUXデザインでも体験が分断しないように意識しているので、ハマる・共通するところはあると思います。
（Q）チームラボさん、新しい技術をいち早く取り入れているイメージなのですが、最新技術の研究開発専門の部署等はあるのでしょうか？それとも各部署がそういった意識をもって普段から企画開発取り組まれているのでしょうか？
伊藤：できるだけチェックしており、とくにエンジニアは新技術をさわることはやっています。
ただ新技術が目的になることはなく、よい体験を考えた時に、新技術でユーザーのメリットが増すのであれば提案・採用することはあります。
（Q）安全性という面では、あらゆる危険性を考えると何もアクションできないということになってしまうかと思います。学園の件では、クライアントから懸念される状況はありませんでしたか？
伊藤：セキュリティ面については念入りに検討し、スマートロックに落ち着きました。また、生徒用の下駄箱と大人の入り口を物理的に分けるなどしています。
（Q）UX改善についてはどういった材料をもとに改善に取り組むことが多いですか？ よくあるのはエンドユーザーへのインタビューでしょうけども、社内でUXの現状把握としてアンケートやインタビューの話をすると「ぶっちゃけ手間だしコストかかるしこの改修規模なら別にインタビューまでは・・・」「アンケートの結果が本当にUX改善につながるの？」みたいな雰囲気がよく出てしまいます。
松森：「ユーザーの声をきく」はないがしろにしてはいけないことだと思っています。ユーザーが本当に使いやすいかは、実際に聞いてみないと、本当のUX改善にはつながらないので、
手間がかかるのはその通りですが、コストと手間をかけたリサーチはした方がいいと思います。
伊藤：ユーザーインタビュー、ユーザーテストは大事です。コストかけていきましょう！
お叱りの声もいただくけど、それも貴重な意見で、とても参考にしています。
またアンケート自体も、インサイトを深掘りできるよう設計することが大事です。
（Q）登壇各社様にお伺いしたいです。 ユーザーと自社の両者にとって「良いユーザー体験」はどう定義されていますか？
松森：ビジネス的にこうしたいという要求が強くある反面、それはユーザーが本当に求めていることか？という議論はよく起こります。ビジネスとユーザーの求めているものが合致して、ユーザーが価値を感じられるか。この両軸が実現できていることが作り手側としては良いユーザー体験なのかなと思います。
伊藤：全く同意見です！我々はクライアントワークになるので、ユーザーとクライアントの関係性がビジネス面も含めて最適化できていることかなと。現代であればインターネットやスマートフォンというテクノロジーがあるのでそれを活用して、最適な関係性を作り出していく。それに尽きると思います。
（Q）専属のUIデザイナー、UXリサーチャーなどは在籍されていますか？ もしいらっしゃれば、どういった経験や技能、ポートフォリオ、面談結果を経て採用に至りましたか？
松森：UXリサーチャーは在籍していますが、UI専属のデザイナーはおらず、UIUXデザイナーとして在籍しています。元エンジニアやショップ店員から転職された方もいたりします。ポートフォリオも入念に見させていただいています。
伊藤：チームラボでは、デザインにまつわる職種はUIUXデザインとして一つにまとめています。今いるメンバーのバックグラウンドはバラバラで、デザイン畑じゃなかった人が独学で……ということもあります。採用ではポートフォリオを重視して見ており、光るものがあるな、と感じた方を採用します。面談では、ポートフォリオの作品に対して根掘り葉掘り訊かせていただいています。
（Q）UX改善しつくした末にサービス成長があるようにもある一方で、必ずしもそうでないところもあるかと思います。 ビジネス目標とUX改善との兼ね合いはどういったバランス感で施策の実施判断とされていますか？
松森：作った当初はこの機能がユーザーに絶対ウケる、と思っていたとしても、リリースしてみると、反応がよくないことも多々あります。自分たちがこれだと信じ込んでいる価値が、ユーザーに求められているものなのかどうかは難しいところだと感じています。
伊藤：ビジネス側の意見が勝つことはあります、UXが至らない中でもユーザーに使ってもらえているという事実があるなら、ビジネスの要求が優先される局面はあります。でも、ユーザーのことを念頭に置きましょう、といつも口酸っぱく話しています！
（Q）UIデザインの企画時に社内で意見がわかれてしまった場合はどうされていますか？ どちらもデザインとして優れていて、ユーザーの便益にもつながり、企業としての方向性も一致しているとします。 下記のようなABテストをかけて決着、とかでしょうか？
松森：ユーザーに聞いてみようと思う反面、自分自身の経験としてあるのは、サービスオーナー目線で、ここにこだわりたいという直感的な判断がユーザーに受け入れられるみたいなことがあったりしますので、最終判断はサービスオーナーに委ねているところが多いです。ただ、これも仮説でしかないので、最終的な答えはユーザーに聞いてみるしかやっぱりないのかなと思います。
伊藤：複数の意見が出ることはあっても、割れて決まらないことはないです。主観で考えるのはやめよう、ロジックで決めようというカルチャーがあるためです。細かい粒度でもすべてロジックに沿って決めています。
（Q）両社さんにお聞きしたいのですが、UXデザイン周りの情報収集はどのようにしているのか。また、時代の変化でどの程度変化を感じられていますでしょうか？そのために情報収集や学びの継続はどの程度必要なのが現状でしょうか。
松森：率先して体験しにいっていますが、社内のメンバーが発端で、こういうのあるんだ！という発見が多かったりします。チームの人数分アンテナが立つので、そこでの学びも多いです。
最近だとAIだとか、主力だったサービス・プロダクト、例えばTwitterがXになったり、状況は刻一刻と変化しています。その影響も受けて、いろんなことがちょっとずつ変わっていっていることはあると思います。そういう事象に対して、定点観測し、情報収集していかないと、劣化していくなとは感じています。
伊藤：個人的に自分の体験の範疇でしか体験は考えられないと思っているので、耳にするサービスやプロダクトを使ってみて、所感を自分のデザインに照らし合わせて言語化してみたり、普段の生活のなかでも「このイス座りづらいな、なんでだろう」「ここからあそこまで移動しなきゃいけないのか」など身体的な感覚を常に考えてナレッジをストックしています。
動画を用いた表現やスマホ画面の大きさなど、時代の推移もみています。ニュースもよく見ます。
（Q）「ユーザーのため」をブレないように突き詰めるための一番重要なことは何でしょうか。ぜひアドバイスお願いします。
松森：UXコンセプトとして、メンバーが立ち戻れるものを作るようにしています。それらの資料化と周知もやるように心がけています。
伊藤：身も蓋もないですが「いつでもユーザーのことを考えましょう」ということになります。アプリを使う時以外のユーザーの人生にも思いを馳せてデザインを思考しています。
いかがでしたでしょうか、レポートの内容は以上です。
次回のイベントレポートもお楽しみに♪
