サービスやプロダクトの担当者が、UXデザイナーに頼らずに、自力でUXを考えるためのヒント
このnoteは、UXデザイナーがアサインできないサービス/プロダクトでUXを実践するための(それなりに)プラクティカルなガイドを目指したものです。私の考える「良いUX人材の選び方」なども書いています。
本記事では具体的なリサーチ手法やUIデザインのようなUXの専門知識や技術ではなく、UXデザイナーがあまり言語化してこなかった、UXデザイナーの"肌感"や"モノの見方"について書いています。
プロダクトマネージャーやサービス開発担当者にとって特に価値があるのではないでしょうか。
「UXってどういうもの？」を初歩から知りたい方には少し重たい内容ですが、一方でなんとなく知っていれば十分学びがあるものと思います。
はじめに
サービスやプロダクトの開発、あるいはDX（デジタルトランスフォーメーション）の推進を考えるとき、最初のうちは「システムを導入すれば解決する」「AIで自動化できたら効率が上がる」というように、どの技術を使うかが先行して議論されがちです。
しかしながら、いざ実際にリリースしてみると、「誰も使わない」「思ったほど効果が出ない」という事態が陥るのはなぜでしょうか。
手前味噌ですが、それは作るものがユーザーにとって良いものかどうか、を筋よく考えられてないから-自分が今回書く「UXの視点」というものが欠如しているからではないでしょうか。
本来ならここで「UXデザイナー/UXリサーチャーを入れましょう！」というのですが、実のところ全てのプロジェクトでUXデザイン/リサーチにお金をかけられるわけでもないので、サービスやプロダクトの担当者が自力でUXを考えるためのヒントについて考えていきましょう。
1.「UX視点を取り入れること」は必ずしもUXリサーチャー/デザイナーのアサインを意味しない
今回話すUXデザインについて
まず、今回いうUXデザインは、「UIを作ること」の話ではありません。
というか、UIを作るまで要件が降りてきた時点で、もうすでにUXデザイナーが貢献できることは限られていて、実は画面を決める前に考えなければいけないことが膨大にあります。
ではそれ以外にどういうUXデザインがあり得るかといえば、
例えばどんな機能を作るべきか-機能はどうあるべきかや、どんなフローがユーザーにとって幸せか、あるいはそもそも誰が使ってくれそうか、どんな人が課題を抱えているか、そういったことを考えることができます。
UXデザインは2ステップ
まず、UXデザインをものすごくざっくりいうと2ステップに分けられます。
最初のステップは課題を見つける。なんらかの方法でリサーチを行うことですが、UXデザインのために行われるインタビューやアンケートや、その他の手法などをまとめて、UXリサーチと呼ぶことがあります。
そして次のステップは、課題の解決方法を考え(ジャーニーマップやWFなどあの手この手で)可視化することです。狭義としてここだけをUXデザインということもあります。
このステップにはUIデザインが含まれ、これだけ切り出しいわゆるUIデザイン、ないしUIUXデザインと呼ばれています。
UXデザインの役職について
そんなUXデザインには大きく、UXデザイナー/UXリサーチャー/UIUXデザイナーの3つの職種があります(派生職は他にも無数にあります)。
UXリサーチャーはこのうちのUXリサーチを専門とする…つまり課題発見屋さん、UIUXデザイナーはUIデザインを専門とする…つまり画面デザイン屋さんです。
UXデザイナーはこの全体をさすことも一部を指すこともあり、あまり決まった定義はありません。
UX職を一言で言うと何やってるの？
では、それらの仕事に共通することははなんでしょうか？
役職として分化してしまったUX職を理解するのは非常に難しいですが、考えていることを見ると一つにまとまると思っています。
それは「ユーザーが抱える真の課題は何か？」「どういう形で解決するのがユーザーにとって最善か？(それは本当に最善の解決か？)」という2つの視点で物事を問い、考えることです。これが今回話すUX視点です。
この視点を携え、それぞれの立場で関わることでUX職は成り立っています。
真の課題をユーザーから拾い上げる専門家がUXリサーチャー、それらを解決するサービスやプロダクトの流れを設計するがUXデザイナー、個別画面の使いやすさまで落とし込むのがUIUXデザイナー、というような感じです。
UX職をアサインしなくても、UX視点を取り入ることで補えるものがある
つまり、UXに大事なのはプロセスのやり方を知っていることだけではなく、それをUXの視点をもちながら進められることです。
逆にこの視点さえ持てれば他のどのタイミングでも、UXデザイナーとして一貫して立ち振る舞うことができます。
自分は事業戦略レイヤーでも、新規サービスデザインでも、プロダクト改修でも、画面のUIデザインでも、機能定義やAPI開発などでも、いろんなタイミングでもレビューやディスカッションに加わったことがありますが、その全てでバリューを発揮できるのはこのUXの視点を持って話すことができるからだと思っています。
このUX視点を持つ人がプロジェクトにいれば、(理想的ではないものの)UXデザイナー/UXリサーチャーなどをプロジェクトに入れずとも一定のものをできるでしょう。
もちろん私たちは本職なので、頼んでいただければより高度に課題発見/提案できるように努めます。
2.UX視点が欠けたプロジェクトの典型的なミス
というわけで、まずはUX視点がかけると何がいけないか？から考えていきましょう。
手段が目的化する
いきなり耳が痛いであろう話をすると、DXプロジェクトや新規サービス開発の現場では、よくよく手段が目的化します。
「○○ツールを入れれば効率化される」「AIを使えば問い合わせが楽になる」「Slack連携しよう」…などといった議論が盛んに行われます。
たしかに技術的には魅力的ですが、そこで終わってしまうと“導入自体がゴール”になりがちです。しかし、いくら素晴らしい仕組みを整えてもそれがユーザーにとって適したものでなければユーザーには使われません。
それをもって「使えばわかるのに…」だったり「最初は慣れがいるけど」と憤ることもあるかもしれません。
「使えば」…それ本当にユーザーにとって必要な機能でしょうか？
必要な機能じゃないから使われない可能性はありませんか？
価値を感じられなかったから使われなかった、と捉えましょう。
「使えば便利」などというナイーブな発言はやめるべきです。
(もし本当に最高に便利だと信じられるなら、機能の存在が伝わってないのかもしれません。その場合は認知度を高めるべきです)
真の課題が明確ではない
今みたいな話はなんとなくイメージがついてる方も多く、なので現場やユーザーにリサーチをしている方もいるでしょう。
さて、リサーチとはざっくりいえば「何に困っていますか？/どんな機能使いたいですか？」を問うことです、が、
では、そのインタビューで得られた回答は本当に真の課題でしょうか？
これは何も回答者が嘘をついているわけではなく、人間はそもそも自分の普段の行動や感情に自覚的ではないため、回答時点で実態と異なる回答をしたり、あるいは深層に抱えているものに思い当たらず、表面的な課題を答えてしまうことがあるからです。
ここはユーザーが本当のことを言っているかを判断する、ある程度の肌感が必要です。
解決策がイケてない
課題選びは妥当だったとしましょう。ただ、課題は「何が課題か」もそうですが「どうやって解決できるようにするか」も大きな問題です。
デザインに正解はありません。
これをやれば万人が喜ぶクリティカルなものはありません。だから、常に「より多くの人がより幸せになりそうな」ものを考えて選びます。(もちろん戦略によっては少数の人がめちゃくちゃ幸せになるものを選ぶこともあります)
その時に、ユーザー視点がなければ、あるいはユーザーがどのように解決して欲しいかの勘所がなければ、幸せなものを選べません。
実装が楽な方法、あるいは単に自分が知ってる方法を選ぶでしょう。
ではなぜそんなに全力で「ユーザーが幸せになれるもの」を目指さないといけないんでしょうか？
理由はシンプルで、「解決策がイケてる競合に取られる」からです。
本来であれば、解決策のエレガントさでそこにmoatを築けるはずなのに、築いてないことを意味します。
ここを考慮せず先行者利益で稼ぎ抜ける算段があるなら、そんなことは考慮しなくてもいいかもしれません。
プロダクトやサービスができた後に課題に気づくと、大規模なピボットが必要になる
最後の失敗は、UX視点を後から取り入れようとすることです。
なぜこれが問題かざっくりいうと、そもそも根ざした場所や伸ばす方向が間違っている可能性があるから、です。
確かにマーケティングは市場規模や温度感の算定に役立ちます。
ですが、あなたが根差そうと思った場所、マーケットの中の位置どりは本当にユーザーが欲しいものでしょうか？
「ロジカルに」市場の中での位置どりを計画しても、それがユーザーにとって「必要とされている」という証明になりません。
ユーザーにとって必要とされているかは、ユーザーに聞かないとわからないんです。
そして、プロダクトの方向性が固まってから「実はユーザーはそこまで困っていないらしい」「別の箇所に大きな障壁があった」という事実が判明すると、大規模なピボットが必要になりかねないからです。
3.最初からUX視点を持って進めると、何がよいか
後戻りコストを最小化できる
最初の段階からUXリサーチャーやデザイナーが入って、例えば「この機能が本当に必要なのか？」「ユーザーは何に最も不便を感じているのか？」といジャッジが入り、後戻りコストを最小化できます。
もちろんリリースしてからじゃないとわからないことがあり、あるいはUXリサーチを行わなくてもそのサービス/プロダクトは十分効果的かもしれません。
このようにUXリサーチもデザインも万能には程遠いのですが、どちらかといえばUXリサーチ/UXデザインはプロジェクト成功のためのリスクヘッジの方法と捉えた方がいいでしょう。
UX視点がバイアスに気づかせ、アイデア創発を後押しする
UXリサーチ/デザインでは「ユーザーは何を本当に求めているのか？」「行動変化を起こすとしたら、どんな体験が必要か？」など、比較的抽象度の高い話が繰り返し出てきます。
これが技術や解決策を超えて、新たなアイデアを誘発するきっかけになります。
「これが課題/解決策だと思っていたけど、もっと別の課題/アイディアがあるかもしれない」と気づくことが、イノベーションの種になります。最初からUX視点を取り入れておくと、こうした新しい発見やアイデアが初期段階で整理・検討されるため、結果として“単なる機能改善”を超えた価値あるサービスづくりにつながるのです。
今までは技術的制約が大きくのしかかっていましたが、実現することが爆発的に増えています。今日できなくても3ヶ月後に、1年後にできることも沢山あるでしょう。
こうした時代では、いかに固定観念を緩ませ、アイデアを創発できるかの価値が高まっていると思います。
今まででは地に足のついたアイディアを考えることが大事でしたが、地に足のつきそうなアイディアを考えるのがこれから求められることです。
2つの「UXの視点」
というわけで本題です。
本記事でいう「UXの視点」とは、下記の２つの問いを持って物事を考えることです。
ユーザーが抱える真の課題は何か？(それは本当に真の課題か？)」
どういう形で解決するのがユーザーにとって最善か？(それは本当に最善の解決か？)
これらの問いを適切に投げることで、「これはユーザーにとって本当に良いのか？」が多面的に考えられるようになります。
それは誰かの深い課題に刺さっているかだろうか？
そしてユーザーにとってそのアプローチは一番幸せかなものだろうか？と
4.UXの視点①：「ユーザーが抱える真の課題は何か？(それは本当に真の課題か？)」
まず一つ目の視点「ユーザーが抱える真の課題は何か？(それは本当に真の課題か？)」ついて話します。
なぜ真の課題を見つけないといけないか
例えば、会社での仕事の進め方にルールがあり、それの問い合わせが多いから改善するプロジェクトがあり、DX部門で「Slackと連携すれば検索しやすくなるから便利だろう」と考えたとしましょう。
アンケートで「資料が検索しにくい」「情報が探しづらい」という意見が出てきました。
これは一見明確な課題に思えますが、しかし、実際にユーザーへヒアリングすると以下のような事実が判明するかもしれません。
新入社員：「どのキーワードで検索すればいいか分からないから、そもそも検索機能があっても使えない」
ベテラン社員：「必要なときはSlackや口頭で聞けば済むから、わざわざ新システムを覚えるメリットが感じられない」
中途社員：「ドキュメントが散らばっているので、どれが最新で信頼できる情報か分からない。検索精度だけの問題じゃない」
こうした具体的な行動パターンや感情面の障壁が分かると、単なる検索機能の改良ではなく、「会話ややりとりの中で自然にナレッジが蓄積される仕組み」「どれが正しい情報か判断基準を提示する仕組み」のほうが必要かもしれません。UXデザインでは、このようにユーザーのリアルな様子を丁寧に観察することで、初めて“有効な施策”が導き出せると考えます。
このようにユーザーの状況をよく調べずに「Slack化すれば価値がある」と決め込むと、導入後に「使われないシステム」「形だけのDX」として失敗に終わりがちです。
真の課題もわからない状態-つまりユーザーの解像度が低いままデザインしても、上手くいかないことが多いです。
課題っぽく見えるものを掘り下げる
「資料が検索しにくい」「情報が探しづらい」というのは一見課題っぽく見えます。
“課題っぽく聞こえるもの”は分かりやすいので、ついそこにソリューションを当てはめようとしがちですが、UXデザインでは「本当に困っているかどうか」「優先度は高いかどうか」を絶えず問い直すことが重要です。
大規模投資した結果、「ユーザー的にはそれほど必要でもなかった」となれば、導入コストばかりかかって誰も得をしません。こうしたリスクを避けるためにも、本質的な課題を確かめる姿勢が重要です。
なので、(リサーチをすることも含め)それって本当にユーザーがやりたいことなの？をちゃんと考えることが必要です。
どのようにして「真の課題」を見つけるか
真の課題…真の課題という単語はいってて難しいですね。
よく、マーケティングやUXデザインの世界では「ニーズ」「潜在ニーズ」「ウォンツ」とかそういう言葉が使われますが、今日はそれらの言葉を使いません。
大事なのは問いの観点やどういう時に回答と実態に齟齬が起きうるかの肌感です。安易に言葉に踊らされるとそういうものを見失います。
肌感はすぐに身につけられるものではありませんが、観点は言語化できるはずで、今回は観点の言語化にトライしてみます。
私はよくこんなことを観点として考えたりFBしています。
最初の“問い”立ては正しいか？
例えばユーザーが求めていたのは「情報を効率よく探せること」ではなく「適切なタイミングに適切な情報を提示されること」だったかもしれない。だからそもそも「情報を効率よく探せるシステムを作ろう！」という問い立て自体も間違っているのかも。
もっと大きな、前提にしてたものが間違っている/妥当でないこともよくある。
解くべき問いを間違えると、どれだけ頑張っても意味がない。
これが一番重要な目線で、これが一番難しい。
ユーザーの状況や課題を起点にして語っているか？
解決策やシステムの話をする前に、まず「ユーザーは何に困っているか？」「ユーザーはこれをやりたいか？」を深掘りするべき。
ユーザーの目的や障壁を明確にしたうえで、解決策を考える流れが重要。
これも徹底。私たちが何を実装したいかではなく、ユーザーが何が欲しいかが全て。ユーザーの欲しいもの中にやりたいことを見出す。
ユーザーの状況を解像度高く理解できている？
単に「情報共有がうまくいっていない」といった抽象的な話ではなく、「何をしようとして、どこで止まっているのか？」を細かく分析する。
課題を整理する際は、ユーザーの「行動」「状況」「障壁」を具体的に考える(リサーチする)
「現在の行動」「理想の状態」を言語化し、解決策を導き出す。
真因まで掘り下げられているか？
人間は真因まで掘り下げずに表面的な課題に飛びつきがちなので冷静になって考える。これも難しい。常に疑いの目。
人間はそもそも自分の普段の行動や感情に自覚的ではないため、回答時点で実態と異なる回答をしたり、あるいは深層に抱えているものに思い当たらず、表面的な課題を答えてしまうことがある。
開発は大きな決断。慎重なぐらいが丁度いい。
それは本当に深刻で、解くに値する課題か？
課題や真因が分かっても、それは運用で解決されていて深刻な困り事ではないかもしれない。
ツールで全てを解決する必要はない。時には人力でフォローした方がずっと楽なこともある。この辺はツールに何を要求するかと、どのくらい開発にリソースをかけられるかなども課題を解くかの判断材料にするべき。
5.UXの視点②：「どういう形で解決するのがユーザーにとって最善か？(それは本当に最善の解決か？)」
次に二つ目の視点「どういう形で解決するのがユーザーにとって最善か？(それは本当に最善の解決か？)」ついて話します。
1.「最善」を問い続ける。
「最善」と私はしれっと書きましたが、まず最善は非常に多義的な言葉です。人によって、タイミングやシチュエーションによっても違います。
「最善」は一意ではありません。
なので苦しいことにこれ全てを問い続ける必要があります。
「これが最善だ！」と思った瞬間から、プロダクトが、サービスがそれ以上に成長することはありません。哲学的ですね。
「これは今考えうる最善の案だ！」なら言ってもいいと思います。
2. 「感情の動き」を無視しない
さらに見落としがちなのが、“感情”を扱うことです。合理的に考えれば便利なシステムでも、ユーザーが「分からないのが不安」「やり方を変えるのが面倒」と感じたら、結局使われません。
逆に、「新しい仕組みを使えば仕事が評価されやすくなる」「安心感を得られる」と思えば積極的に利用してくれるかもしれません。
これを「合理的でない！」と憤るのは勝手ですが、そういうものです。
人間はロボットではありません。
この事実をちゃんと受け止めないと、UXデザインは失敗します。
UX視点では、単に「行動がどう変わるか」だけでなく、「どの瞬間でユーザーはストレスを感じ、解消されるときにどんな喜びを味わうのか」といった感情面も重要な評価軸となります。ここまで考慮することで、表面的な効率化だけでなく、ユーザーが本当に「これを使いたい」と思う設計につながります。
3. 運用や組織文化を無視した設計は使われない
システムの完成形を想定したところで、実際の運用が伴わなければ価値を生みません。たとえば「新しいツールを導入すれば簡単に情報共有ができる」と思っていても、メンテナンスをするのは誰か、情報更新のフローをどうするかが曖昧なままでは、数カ月後に機能しなくなる可能性大です。
社内でExcelを使う文化が根強ければ、たとえSlack連携を進めても、誰も乗り換えないかもしれません。
この点を見越すのがUXデザインの役割です。UXリサーチャーやデザイナーは、「実際に現場で誰がどう動くか」「業務フローや慣習を踏まえて、自然に導入できるか」を調べます。
あるいはどうすればそれを心地よくメンテナンスすることができるか、そういった仕組みを設計します。
何が現場を動かすモチベーションなのかを把握し、運用フローを設計することで、プロダクトやサービスが無理なく受け入れられる確率を高めるのです。
ゲーミフィケーションなんてのもその差異たる例ですね。
4.現実を見る
開発会議や要件定義書では、理想的なフロー図が描かれます。しかし、現場のユーザーは必ずしも合理的には動きません。慣れたやり方を手放さない、忙しくて新しい操作を覚えられない、エラーが起きたらどうしていいか分からない。
こうした要素が積み重なると、いくら技術的に優れた仕組みでも「誰も使わない」という結果になりがちです。
UXデザインが実践するのは、次のような問いをこまめに立てる姿勢です。
「本当にユーザーはその通りに動くか？」
「最初の導入時に嫌がられるポイントはないか？」
「失敗したときのリカバリー策をユーザーは理解できるか？」
などなど
この問いがあるからこそ、設計や導線、チュートリアルなどに厚みが生まれ、実際の利用を促す工夫ができます。
できること（機能）とやること（実際の行動）には大きな溝があると常に認識しておくのが、UX的なアプローチです。
5.短期的な便利さと長期的な価値のバランス
UXデザインでは「すぐに手間を省ける」だけでなく、「長期的にユーザーがどんな付加価値を得られるか」も検討するべきです。
たとえば、レポート作成をAIで自動化すれば短期的には楽になるかもしれませんが、使い方によっては「チーム内で議論する場が失われ、結果としてノウハウが溜まらない」だったり「自分の行動を振り返るチャンスを失う」というリスクもあります。
もちろん効率化を否定するわけではありませんが、技術の導入によって「ユーザーの成長機会や創造的な取り組みが奪われないか？」を問うのもUXの重要な視点です。長期的に価値が積み上がる仕組みこそ、ユーザーの満足や組織の持続的な発展につながります。
6.AIは“導入すれば万能”ではない
別段これもかくことではありませんが、一応。
AIがもたらす可能性は非常に大きいですが、「AIを入れればすべて自動化できて楽になる」ということもありません。機械的にチャットボットをつければいいわけじゃないんです。短絡的な発想にも注意が必要です。
6.具体的な問い
ここまで述べた内容を踏まえ、これらをさらに実際にプロジェクトで投げかけられる問いやフィードバックの例にしてみました。
いずれも「なぜ、どうして」を繰り返すUX的アプローチの要素が色濃いものです。
「アプローチ先行になっていないか？」
例えば「Slackと統合」「AIで自動化」といった手段ばかり先行し、本質的な課題を深掘りしていない可能性はないか？
「それって本当にみんな困ってるのか？」
「情報共有が難しい」と言うが、現場の対処行動が十分に確立されていて優先度が低い場合がある。表面的には課題に上がっているが、深刻ではないかもしれない。
「行動変化は何を狙っているか？」
ただ“効率化”というだけでなく、具体的に「どの行動をどう変えたいのか」を明確にする。
「感情の動きやモチベーションは考慮してるか？」
ストレスや不安、あるいは期待や達成感など、感情をデザインしないとシステムは使われにくい。
「運用フローと文化に適合するか？」
誰がメンテナンスする？ 組織の習慣と衝突しない？ ツールの“使われ方”を考慮しているか。
「短期の便利さと長期的価値のバランスはとれているか？」
短期的な手間を省くことが、中長期な運用を毀損しないか？
あるいは展望だけ見すぎて、直近のユーザーへの負荷が大きすぎないか？
「理想と現場のズレはないか？」
機能的にはできても、ユーザーが実際に“やる”とは限らない。裏技や既存フローを好む人が多いかも。
「AIの導入理由はどこにあるか？」
一応AI時代なので。AIを任意の技術やツールと読み替えても良い。
ただ「AIを使えば便利」ではなく、ユーザーが行動を変える必然性があるか。本当に必要？
7.二つの思考の使い方
これまで説明してきた「ユーザーが抱える真の課題は何か？(それは本当に真の課題か？)」と「どういう形で解決するのがユーザーにとって最善か？(それは本当に「最善」の解決か？)」という二つの思考は、別々に存在するものではなく、相互に影響し合う関係にあります。
これらをフレームワークとして整理すると、プロジェクトの現状把握や方向性の設定に非常に役立ちます。
UXの二軸フレームワーク
このフレームワークは、「課題の本質理解」と「解決策の最適化」という二つの軸で構成しています。それぞれの軸において、取り組みが十分かどうかによって、プロダクトやサービスの状態が4つの象限に分類されます。
(まぁこれに似たようなフレームワークは世の中に沢山あるので、より良いものを知ってる場合はそれを使ってください)
左上：誰も使わない機能-サービス（両方の視点が欠けている）
この象限は、ユーザーの真の課題を捉えられておらず、かつ解決策も最適化されていない状態です。
例：
・AIチャットボットがあれば便利だろう」と導入したものの、ユーザーが本当に困っていたのは情報の信頼性だった
・ダッシュボードを作れば業務効率化できる」と思って作ったが、データ入力の手間が増えて誰も使わなくなった
この象限のプロダクトは、「使えば便利なのに…」とチーム内で嘆かれがちですが、実際には「そもそも必要とされていない」という厳しい現実があります。
右上：課題を理解はしているが実装が最適でない
この象限では、ユーザーの真の課題は正しく理解できているものの、その解決方法がユーザーにとって最適ではない状態です。
例：
・社内の情報共有問題を解決するために新システムを導入したが、UIが複雑すぎて定着しない
・顧客が求める機能を実装したが、使い方が直感的でなく、学習コストが高すぎる
こうしたケースでは、「良いものを作ったはずなのに使われない」というフラストレーションが生まれます。課題理解は正しくても、ユーザーの行動パターンや感情を考慮した実装ができていないのです。
左下：使いやすいが価値が低い
この象限は、見た目や操作性は洗練されているものの、ユーザーにとって本質的な価値が低い状態です。
例：
・デザイン的には美しいアプリだが、ユーザーの根本的な問題を解決していない
・既存機能の改善に注力したが、ユーザーが本当に欲しかった新機能は後回しにされた
「いらない機能が使いやすい」という状態は、短期的には満足度を得られるかもしれませんが、長期的には利用頻度の低下や離脱につながります。
右下：UX最適化された製品（両方の視点がある）
理想的な状態であるこの象限では、ユーザーの真の課題を正確に捉え、かつ最適な解決策を提供できています。
例：
・ユーザーの暗黙知を丁寧に調査し、本当に必要な機能だけをシンプルなUIで提供
・ユーザーの作業フローに自然に溶け込み、余計な操作を強いることなく課題を解決
この象限のプロダクトは「使っていて気持ちいい」「これがないと仕事ができない」と言われるような、真の価値を提供できます。
フレームワークの実践的な活用法
現状の診断
プロジェクトの現状を診断するには、以下の2つの問いを投げかけてみましょう。
課題理解の軸
「私たちは誰のどんな問題を解決しようとしているか、明確か？」
「その課題はユーザーにとって本当に重要か、確認したか？」
「仮説ではなく、実際のユーザーの声や行動から課題を導き出したか？」
解決策の軸
「私たちの解決策はユーザーの行動パターンに沿っているか？」
「感情面や使用文脈を考慮しているか？」
「ユーザーが自然に使いこなせる設計になっているか？」
右下象限への移行戦略
各象限から右下の理想象限へ移行するための具体的なアプローチは次のとおりです：
左上からの移行：最も根本的な見直しが必要です。ユーザーリサーチを一から行い、本当に解くべき課題を特定しましょう。
右上からの移行：課題理解は正しいので、解決策の最適化に注力します。プロトタイプテストやユーザビリティテストを繰り返し、ユーザーにとって自然な体験を設計しましょう。
左下からの移行：デザインスキルはあるので、それを活かしつつ、より本質的な課題に焦点を当て直します。「なぜこの機能が必要か？」を問い直し、真の価値を提供できる部分に注力しましょう。
継続的な思考の習慣化
このフレームワークを一度使って終わりにするのではなく、プロジェクトの各フェーズで定期的に立ち戻ることが重要です。特に方向性の転換や大きな決断を行う前には、必ずこの二軸で現状を確認しましょう。
また、最初は自分たちのやっていることは右下だと思っていたら…よくよく確かめると左上だったみたいなことも本当によくあります。
最終的には、「ユーザーが抱える真の課題は何か？(それは本当に真の課題か？)」と「どういう形で解決するのがユーザーにとって最善か？(それは本当に最善の解決か？)」という二つの問いが、チーム全体の共通言語となり、自然と意思決定の基準となることが理想です。
こうした思考習慣が定着することで、UXデザイナーがいなくても、ユーザー中心の判断ができるチームへと成長していくでしょう。
8.UX職が果たす役割
UXリサーチャーやUXデザイナーが、こういったUX視点を持ってできる立ち回りは自分の業務やプロセスにどう生かされるでしょうか？
1. ユーザーの行動・感情を“深掘り”する
UXデザイナーやリサーチャーは、インタビューや観察などの手法を使い、ユーザーの日常行動や感情の動きを把握します。あるいは時には自分自身で体感してみたり。
どの瞬間にストレスを感じ、逆にどんなときに満足感や達成感を得るのかを可視化します。
これにより、「検索機能を高めればいい」と思っていた課題が、実は「検索自体をユーザーが求めていなかった」という事実に行き当たるかもしれません。
2. チームがユーザー視点を持てるようにファシリテート
プロジェクト初期の段階では、具体的な機能や要件の話が先行しがちです。UXデザイナーがそこに介在する価値は「なぜそれが必要か？」「本当にユーザーはそこに困っているか？」と問いかけることで、チームの思考が一段深まります。抽象的な問いをしつこく繰り返すようにも思えますが、このプロセスが抜け落ちると“解決策先行”のまま突っ走ってしまう危険が高まるのです。
また、「この仕組みは運用や文化とぶつからないか」「AIが失敗したときのリカバリーはどうするか」といった運用面の検討も含め、最終的に“ユーザーが自然に行動を変えられる”状態になるよう、チーム全体を導くのがUXリサーチャー／デザイナーの大きな役割です。
9.UXを後から考えようとするケースへの具体的な対応策
そうは言っても最初からUX視点を取り入れられなかったプロジェクトもあるでしょう。
プロジェクトが進行した後にUXの視点を取り入れようとすると、設計の根本を見直す必要が出てきたり、すでに開発された機能の修正が必要になるため、コストが増大しがちです。
なので下記のような進め方が良いでしょう。
影響範囲の整理と優先度付けをしよう
すべてを修正するのは現実的ではないため、現状の設計の中で「ユーザーの離脱や不満の要因になっている部分」「影響が大きい部分」を特定する。
ユーザーテストやインタビューを行い、優先的に修正すべき課題を特定。
優先度は工数や期間だけじゃなくて、ユーザーの深刻度もちゃんと考慮しよう！
短期間でできるUX改善施策の実施をしよう
すぐに修正可能な要素（例：ナビゲーションの見直し、エラーメッセージの改善、フローの単純化など）を見つけ、短期間で実施しよう
A/Bテストを活用し、UX改善がどれだけ影響を与えるかを素早く検証。
ただし、短期的な解決案だけでなく、バケツの穴を探す/閉じるような抜本的な解決策も考える必要がある。
ユーザーの行動データを活用しよう
既存のプロダクトがあるなら、ユーザーの行動データ（ヒートマップ、クリック分析など）を解析し、改善すべきポイントを明確にする。
定性データ（ユーザーインタビューなど）と定量データ（アクセス解析など）を組み合わせ、仮説検証を行う。
長期的な改善計画を組もう
今回のプロジェクトで修正しきれなかったUXの課題について、ロードマップに組み込み、次回の開発フェーズで対応する。
機能追加やリニューアルの際には、UXリサーチを事前に組み込む体制を整える。
そもそもロードマップを過度にビジネスに寄せすぎない。ビジネス的に○○と言っても、使ってもらえなかったら元も子もないので・
チーム内でUX視点を育てよう
デザイナーやエンジニア、PMがUXの考え方を学び、最初からUXを考慮する文化を作る。
ワークショップや勉強会を開催し、プロジェクトメンバー全員がUX視点を持つことを促す。
担当者一人一人がその見方ができれば最強
10.良いUX人材の判断のしかた
こういう視点を持ちながらUXリサーチ/UXデザインを行えば、必ずしもプロジェクトにUX職がいなくても品質が担保されるでしょう。
とはいえ、実際のところ今日の話を回すのは難しく、読んで頭で理解できても、現場でなかなか問いには落ちません。(この問いの難易度ゆえUX専門職が成り立っていると思います)
多くの場合はUXリサーチャー/デザイナーをアサインした方が良いでしょう。
しかしながら、UXリサーチやデザインに知見がない、あるいはUX視点がUピンときてない人が、こういった問いを回せる良いUX人材を判断することも、また非常に難しいと思います。
というわけで、自分ならこういう質問をして判断してみるかも…というのをまとめてみました。
良いUX人材を判断するための質問
自分の思う良いUX人材は「UX視点を携え、的確な問いを投げられる人」です。何ができるかではなく、その視点があれば、初めてのところに投げ込んでも大体成功します。
※ただし、これ全部明確に答えられないといけないとすると、人材要求のハードルはめちゃくちゃ高いです。あくまで参考程度に
1. UXの本質的な理解を問う質問
「あなたの考えるUXデザインとは何ですか？」
UXを単なるUIの話として捉えていないかを確認する。
回答が「ユーザー体験を最適化すること」「行動変容を促すこと」など、UI設計だけに偏っていないかをチェック。
「あなたがUXリサーチで最も重要だと思うのは何ですか？」
UXリサーチの意義や、データの活かし方を理解しているかを見る。
具体的なリサーチ手法（ユーザーインタビュー、A/Bテスト、定量データ分析など）が挙がるかを判断。
2. 実践経験を問う質問
「これまでのプロジェクトで、ユーザーの意見をどのように反映しましたか？」
UXリサーチの活用経験があるかを判断。
具体的な施策の変化（UIの変更、機能追加、プロセス改善など）があったかを確認。
「UXリサーチの結果が、自分の仮説と異なっていた場合、どのように対応しましたか？」
バイアスに囚われず、柔軟に考えられるかを確認。
実際にデータをもとに意思決定を修正した経験があるかを見る。
3. 問題解決能力を問う質問
「ある機能が使われていないことがデータで分かりました。あなたならどのように調査し、解決策を導きますか？」
UXデザイナーとしての分析力や仮説構築力を確認。
「データの種類」「ユーザーの行動分析」「インタビューによる原因特定」などのアプローチが出るかを判断。
「ユーザーが気づいていない課題をどのように発見しますか？」
単に「聞けばいい」とならず、観察・行動データ分析の視点があるかを確認。
「ペインポイントの深掘り」「潜在的な課題を発掘する手法」が挙がるかを見る。
4. チームワークと説得力を問う質問
「エンジニアやPMと意見が対立した際、どのようにUX視点を伝えますか？」
チーム内での協調性や交渉力を評価。
「データや事例を用いる」「プロトタイピングで実証する」など、客観的なアプローチが出るかをチェック。
「経営層にUX投資の必要性を説明するなら、どのように説得しますか？」
UXのビジネス的価値を理解しているかを確認。
「ROIの算出」「コスト削減・売上向上への影響」など、具体的な数値を交えて説明できるかを見る。
5. 思考の深さを問う質問
「もし『この機能は必要ない』と言われたら、どうしますか？」
感情的にならず、論理的な説明と適切な再評価ができるか。
「ユーザーの声」「データの裏付け」「競合分析」など、多角的な視点で考えられるかを判断。
「UXデザインで最も過小評価されている要素は何だと思いますか？」
UXデザインの幅広い視点を持っているかを確認。
「情報設計」「マイクロインタラクション」「エラー処理」など、一般的に見落とされがちな要素が挙がるかをチェック。ここはまぁ判断難しいかも。
このように、表面的な回答が可能な質問ではなく、候補者の思考の深さを引き出せる質問を投げかけることで、より優れたUX人材を見極めることができるでしょう。
補足：UXとビジネスの関係性
本記事ではUXの視点についてフォーカスし、ビジネスとの兼ね合いについては深く掘り下げませんでした。最後にこの関係性について、特にAI時代における変化と課題に触れておきます。
UXがビジネス価値の創出に直結する傾向は、AI時代においてさらに顕著になっています。その理由は単純です。—「サービスはユーザーに使われることでこそ収益を生み出す」からです（投資による利益などを除けば）。
この傾向はAIの普及によって加速しています。AIによって技術的な実装のハードルが下がり、従来なら多大なリソースを要した機能開発が比較的容易になっています。つまり「作れるかどうか」よりも「使われるかどうか」が決定的な差別化要因となりつつあるのです。
しかし、UXとビジネス価値のこの新たな関係性を適切に捉えるビジネスフレームワークやモデルは、残念ながらまだ十分に発展していません。多くの組織では「作ることへのハードルが高い」あるいは「競合がいない」中でサービスをローンチすることができた時代の考え方をしていると思っています。
こういったケースでは、従来の枠組みの中でUXを「コスト」として位置づけ、その投資対効果を短期的なKPIで測ろうとする傾向が見られます。この既存の思考モデルと変化しつつある市場現実のギャップが、多くの組織がUX投資の判断に苦しむ一因となっています。
本記事ではそうしたビジネス論の構築には踏み込まず、まずはUX視点そのものの理解に注力しました。これは現時点での限界でもありますが、確固としたUX視点の理解こそが、新たなビジネスモデルの土台になると私は考えています。
むすび：私たちは「良い」を問い続けなければならない
というわけで、今日はUXの視点について見ていきました。
こういう視点を持ちながらUXリサーチ/UXデザインを行えば、必ずしもプロジェクトにUX職がいなくても品質が担保されるでしょう
しかしながらUX視点は知識ではありません。ものの見方です。
ものの見方が変わるのは、息をするように問いが出てくるには、一朝一夕ではなく、このnoteを見ても必ずしもできるようにはなりません。
これはできないな…と思うなら素直にUXデザイナーやリサーチャーをチームに入れた方が良いでしょう。
最初はできなくても、できる人を入れて問いを投げかけてもらうちに見方がわかってくるかもしれません。
そうした上プロセスを回すことでずっと良いものに辿り着ける可能性が高まります。
私たちは「良い」を問い続けなければならない
これからの時代、AIでアイディア出しをサポートすることができますが、「そのアイディアが本当に良いのか？」という問いは人間が考え続ける必要があります。
AIがいくら便利になっても、UX視点を持たずに意思決定すると、ユーザーの課題を見誤り、価値のないプロダクトを作るリスクが高まります。
だからこそ、私たちは「何が最善か？」という問いから逃げられません。
最終的に、UXデザインの役割は「より良い問いを立て、妥当な解決案を模索すること」です。
この記事を読んで、少しでもUXの視点を取り入れるきっかけになれば幸いです。
関連記事
デザインが未だ民主化できていない理由｜デザイン的姿勢（Design Attitude）について考える
これのデザイン版です。合わせて読むと理解が深まるかと思います。
いいなと思ったら応援しよう！
