AI時代のUX ─ RapiQを作りながら考えてきたこと
前回の記事では、対談形式で「AI開発とUX担保の両立」についてお話ししました。
今回は改めて、RapiQというプロダクトそのものについて、私自身の言葉で書いてみたいと思います。Dealでプロダクトリードとして、RapiQの開発をリードしてきました。プロダクトをリリースし、実際にユーザーに使ってもらう中で、想定通りだったこともあれば、想定していなかったこともありました。
そして、その経験を通じて、私の中で「UX」という言葉の意味も少し変わったと思っています。
RapiQをつくる中で何が見えてきたのか。そして、AIによってプロダクト開発そのものが変わっていく中で、UXには何が求められるのか。
今回は、RapiQの開発を通じて考えるようになったことを、自分なりに整理してみます。
1. リリースして見えた、「想定通り」と「想定外」
RapiQをリリースして、まず想定通りだったのは、顧客理解に対するニーズです。
特にITやデジタル領域で事業をやっている方たちは、「顧客理解を大事にしなきゃ」という意識が強い。「できるだけ早くユーザーの声を知りたい」「もっと頻繁に調査したい」「予算が許すなら、もっとガンガン調査して、顧客にいいものを出したい」そういう声は実際に多くて、「最短24時間でユーザー調査ができる」というRapiQのコンセプトも、「まさしくそういうものが欲しかった」と受け入れていただけた印象があります。
一方で、想定外だったこともありました。それは、「調査を簡単にすること」と「調査を継続できること」は、別の問題だったということです。
できれば毎月やりたい。もっとユーザーの声を聞きたい。そう思っていても、実際には社内の他の施策と優先順位を競うことになります。予算も必要だし、調査をした後には分析や社内共有も必要になる。
結果として、調査をすること自体が「仕事を増やすこと」になってしまうんですよね。
RapiQによって、調査そのものは簡単になりました。でも、簡単にできるようになったからこそ、別の課題が見えやすくなった。それが、「調査をして、課題が見つかった。その課題を、組織としてどう処理するのか？」という問題です。
これは、リリースして実際に使ってもらったからこそ分かったことでした。
2. リサーチツールから、「事業の動かし方」を考えるプロダクトへ
こうした発見を経て、RapiQを単純に「ユーザー調査を効率化するプロダクト」として捉えることに、少し違和感を持つようになりました。
もちろん、調査にかかる時間やコストを削減することは大きな価値です。
でも、それだけではない。たとえば、これまで数週間かかっていた調査が短時間でできるようになると、単純にリサーチのコストが下がるだけではありません。不要な施策を打たなくてよくなるかもしれない。ユーザーのニーズに合わないものを作り続ける時間を減らせるかもしれない。
限られた人員を、別の仕事に配置できるかもしれない。そう考えると、リサーチの効率化は、最終的には事業のリソース配分や意思決定にもつながっていきます。
「どの課題に向き合うのか」「どの施策を優先するのか」「どこに人を配置するのか」「何をやめるのか」「次に何を検証するのか」そういう、事業そのものの判断に影響する。だから最近は、RapiQは「調査をするためのプロダクト」ではなく、顧客理解を起点に、事業の動かし方を考えるためのプロダクトなんじゃないかと思っています。
RapiQを入れることで、リサーチのやり方だけではなく、事業の進め方そのものを考え直す。
ちょっと無理やりですけど、AIと一緒に売上をつくっていく体験ができるプロダクトとも言えると思っています。
単に作業をAIに任せるのではなく、ユーザーの声をもとにAIと一緒に考えて、次のアクションにつなげていく。
使っている人が、AIと一緒に何かをつくっている感覚を持てる。そこまで含めて、RapiQの面白さだと思っています。
3. 「調査の民主化」で、本当に変えたかったもの
RapiQをつくる上で、私たちが目指していたのは、単純にリサーチを自動化することではありませんでした。
専門家だけのものだった顧客理解を、もっと日常的なものにすること。ここを目指していました。
従来のリサーチでは、調査設計、対象者の選定、インタビュー、分析、レポーティングなど、それぞれに専門的な知識や経験が必要です。
そのため、リサーチ自体がどうしても「特別なイベント」になりやすい。RapiQでは、もっと気軽に、日常的に顧客の声を聞けるようにしたかった。特別な知識がなくても調査できる。調査結果を、誰でも理解できる形で受け取れる。
そして、その結果をもとに次のアクションを考えられる。そこまでを一つの体験としてつなげたかったんです。
だからこそ、「調査結果を出して終わり」にはしたくありませんでした。
4. UXで設計していたのは、「画面」だけではない
RapiQを設計する中で、特に意識していたことがあります。
ひとつは、リサーチに慣れていない人でも、日常的に見られる粒度や分量にすることです。
RapiQは、最終的には意思決定を支えるプロダクトです。だから、調査結果を見て「結局、何が分かったの？」となってしまっては意味がない。承認を取りに行くときに、「一言でいうと何ですか？」と聞かれても答えられる。「なぜこの結論なのか」も分かる。
そして、「だから何をするべきなのか」につながる。そういう情報の粒度やまとめ方を、かなり細かく考えていました。
もうひとつ意識していたのが、世の中のユーザーが調査会社に依頼したときに感じてきた、小さなストレスをできるだけなくしたいということです。「レポーティングが、レポーティングになっていない」「数字だけ並べられている」「結局、この調査結果をどう使えばいいのか分からない」「最初のヒアリングではちゃんと目的を伝えたのに、最後に出てきたものが少し違う」そういうストレスって、一つひとつは小さいかもしれない。
でも、それが積み重なると、サービス全体の体験が悪くなる。だから、そこは全部なくしたかった。むしろ、これまで調査会社に依頼したときに感じていた期待値を超えたかったんです。
特に大事にしていたのが、最初のヒアリングで聞いた「なぜこのリサーチをしたいのか」という目的や背景です。
そこを聞いて終わりではなくて、その目的を調査設計から実査、分析、最後のアウトプットまでちゃんと持っていく。
私がUXを考えるときは、目の前の画面だけを見ているわけではありません。その人が何をしたいのか。何を期待しているのか。どこで迷うのか。
何を見たら安心して次に進めるのか。人の心理をかなり大事にしています。見えている体験だけではなくて、その裏側でユーザーに何が起きているのかまで考える。
だから、私の中では「表の体験」と「裏の体験」があるんですよね。画面上でどう見えるかだけではなく、その体験の裏側にあるユーザーの気持ちや判断まで考える。この両方を考えることが、私にとってのUXです。
5. Claudeに「最後の1mm」を伝える難しさ
そして、4章で書いたような「見えないUX」をAIに伝えることが、開発の中でも特に難しい部分でした。
私たちの開発プロセスは少し特殊で、ワイヤーフレームを細かく書いてから実装する、というやり方ではありませんでした。
Claudeと対話しながら、言葉を中心に仕様や体験をつくっていく。ワイヤーを描いて、指示書と一緒に絵で伝えれば、もう少し早く伝わったかもしれません。でも、それはそれでワイヤーをつくる時間がかかる。AIを使うことで、その手前の時間も含めて短くしたかったので、私たちは言葉で伝えながらつくっていきました。このやり方は、思いついたことをすぐに形にできる。修正のサイクルも速い。
「まずつくってみる」ということが、以前より圧倒的にやりやすくなりました。
一方で、言葉だけではどうしても伝えにくいものがあります。
たとえば、「この文章、ちょっと長い」「この単語は絶対使わない方がいい」「この情報は正しいけれど、ここに置くと一瞬で読み解けない」「機能としては合っているんだけど、なんか気持ちよくない」みたいなこと。
理由を説明しようと思えば説明できるんですが、最後は「本当にここに合っているんだっけ？」という感覚値のところもある。
ここが、かなり難しかったです。人間同士なら、実際に画面を見ながら「なんか違うよね」と言えば伝わることもある。
でも、AIに伝えるとなると、その「なんか違う」を言葉にしないといけない。「ユーザーがここで迷うと思う」「この順番だと、次に何をすればいいのか一瞬考えてしまう」「正しい情報だけど、今このタイミングで見せる必要はない」そういう細かい違和感まで、ひとつずつ言葉にして伝えていく。だからRapiQの開発では、AIにプロダクトをつくらせるだけではなく、自分がこれまで感覚的にやっていたUXの判断を、言葉にしていく作業がすごく多かったんですよね。この「最後の1mm」をどうAIに伝えるのか。
RapiQの開発は、私自身がUXをどう考えているのかを、改めて言語化するプロセスでもありました。
6. 「品質はプロ、やっている人はプロじゃない」という矛盾
もうひとつ、大きな難しさがありました。
それが、「品質はプロなんだけど、やっている人はプロじゃない」という状態をどうつくるかです。プロがつくる調査設計書を「そのままお願いします」とAIに渡せば、かなりのところまで作れると思うんです。
世の中にあるUXリサーチの手法や知識を読み込ませれば、一定の品質にはできる。
でも、私たちがつくりたかったものは、それとは少し違いました。私たちがつくりたかったのは、プロじゃない人がリサーチをするときのやり方で、でも裏側にはプロレベルの品質があるものです。「プロじゃない人がやったのに、プロの仕上がりになった」。これを実現したかった。
言葉にすると、ちょっと矛盾していますよね。品質はプロ。でも、使っている人はプロじゃない。当然、そこにはスキルの差が生まれます。
その差をどう埋めるのか。AIだけに任せるのではなく、プロダクトの中にプロフェッショナルが持っている判断基準をどう組み込むのか。
ここは、重ねに重ねてつくっていきました。
以前、調査会社に外注した経験がある方がRapiQを使ってくださって、「すごく嬉しかった」と言っていただいたことがあります。
理由は、最後に出てくるものが、次のビジネスにそのまま使える形になっていたからです。調査会社から数字やレポートを渡されて、「あとは自分たちで好きに使ってください」と言われても、実際の事業の中では、そこからまた仕事が発生します。数字を見て、意味を読み解いて、社内で説明して、次のアクションに落とし込む。
事業の中では、すでにいろんなことが動いているので、そこまでやるのは意外と大変なんですよね。
RapiQでは、回答が集まってきた段階で、何が起きているのか、どんな傾向があるのか、何を考えた方がいいのかが見えてくる。
しかも、それを誰でも読み解ける文章で見ることができる。つまり、「情報を渡す」のではなく、「次の行動につながる状態まで持っていく」。
この部分は、RapiQをつくる上でかなり大事にしていたところです。
7. 縛らないチームと、「決める人」の両立
RapiQの開発を振り返って、「この判断は良かった」と感じるものがあります。
それは、チームの体制です。チームは3人。私を含めて企画・開発が2人、UXリサーチャーが1人という体制でした。
人数が少なかったからこそ、何かを決めるときの距離がすごく近かったんですよね。いい意味で、あまり細かいルールや役割に縛られていませんでした。「こうしなきゃいけない」と最初から決めすぎず、まずやってみる。「これ面白そうだからやってみよう」と思ったら試してみる。違ったら変える。そういう動き方がしやすかった。
一方で、何でも感覚だけで進めていたわけではありません。
特に、プロダクトの重要な仕様やビジネスモデルについては、何時間も話し合いました。つまり、自由に試すところと、絶対に揃えるところを分けていたんです。これは、3人だったからこそできたことだと思っています。企画・開発とUXリサーチの視点が近い距離にあって、それぞれの視点からすぐに議論できる。「これをつくろう」と決めたら、実際につくってみる。つくったものを見て、UXの観点から違和感があればすぐに戻す。このサイクルをかなり速く回すことができました。
そして、AIを使った開発では、この体制がさらに重要だったと思っています。AIによって、実装そのものはどんどん速くなっていく。
だからこそ、「何をつくるのか」「何を捨てるのか」「どこまでやるのか」という判断の比重が大きくなる。すべてを細かく管理する必要はない。
むしろ、自由に試せる余白は残した方がいい。でも、プロダクトの軸に関わる重要な意思決定だけは、ちゃんと全員で揃える。
すべてを細かく管理するのではなく、重要な意思決定だけは徹底的に揃える。このバランスは、AI時代のチームづくりでもかなり大事なんじゃないかと思っています。
8. RapiQをつくって、「UX」の意味が変わった
RapiQをつくる前と後で、私の中で「UX」という言葉の意味は変わったと思います。
よりUXの大事さを知ったというか、実感したところがあります。その根っこにあるのが、「AIはUXそのものを考えているわけではない」という気づきです。もちろん、裏側でかなり細かくプロンプトを書いて、AIにいろいろな判断をさせることはできます。でも、AIにいろいろなものをつくらせていると、結局最後には、似たようなものができてくる感覚がある。
だからこそ、これから「選ばれる理由」になるのは、「ユーザーは何を求めているのか」「なぜこの人はこれを選ぶのか」「どういう体験なら、また使いたいと思うのか」という部分なんじゃないかと思っています。AIによって、つくること自体はどんどん簡単になっていく。
だからこそ、何をつくるべきなのかを考えることの価値は、むしろ上がっていく。そして、その「何をつくるべきか」を考える上で、UXがすごく重要になる。RapiQをつくって、私はそう考えるようになりました。
9. RapiQを、AI時代の意思決定の質を変えるプロダクトへ
これからRapiQを、どんなプロダクトにしていきたいか。
AI時代の、企業の意思決定の質そのものを変えるプロダクトにしたいと思っています。AIによって、情報を集めたり、整理したり、分析したりすることは、これまでより圧倒的に速く、安くできるようになりました。そうなると、これから企業の中で重要になるのは、「情報を持っているか」だけではなくて、その情報をもとに、どう考えて、どう伝えて、どう決めるのかという部分なんじゃないかと思っています。
RapiQを使うのは、必ずしもリサーチャーである必要はありません。むしろ、事業を動かしている人や、日々意思決定をしている人に使ってほしい。たとえば、何か新しい施策を提案したり、承認を取りに行ったりするときに、「この仮説って、ちゃんと顧客の声をもとに考えられているよね」「なぜこの施策をやるのか、ちゃんと説明できる」「この人のレビューは、話が早いし、納得できる」と思ってもらえる。
その裏側には、ちゃんと顧客の声やデータがある。でも、単純に数字を並べているわけではない。「何が起きているのか」だけではなくて、「なぜそうなっているのか」「だから何を考えるべきなのか」まで整理されている。
そして、それを自分の考えとしてどう伝えるのかまでつながっている。私は、ここまで含めてRapiQが支えられるといいと思っています。
情報を集める。そこから考える。考えたことを、相手に伝わる形にする。そして、意思決定する。その一連の流れが、これまでよりスムーズになる。そういう状態を、組織の中につくりたいと思っています。そのためには、RapiQは「調査をする場所」ではなくなっていく必要があります。
一回の調査結果だけを見るのではなく、「過去にこの顧客について何が分かっていたのか」「以前はどんな仮説を持っていたのか」「その仮説は今も変わっていないのか」「これまでの顧客理解と今のユーザーの声をつなげると、どんな変化が見えてくるのか」まで考えられる。
つまり、その組織がこれまで積み重ねてきた顧客理解を、次の意思決定に使える状態にする。ここが、これからのRapiQでやりたいことです。
AIによって、調査や分析のスピードが上がれば上がるほど、企業の中にはこれまで以上に多くの情報が蓄積されていくと思います。
でも、情報が増えるだけでは、意思決定は必ずしも良くならない。むしろ、「情報はたくさんあるけれど、結局何を信じて、何を決めればいいのか分からない」という状態になる可能性もある。だからこそ、これからは情報を「組織の知」に変えていくことが重要になる。
今までは、リサーチをすると、その時点で得られた「情報」が残っていました。でも、本当に組織に残すべきなのは、情報そのものだけではないと思っています。その情報から何を学んだのか。そこからどんな仮説を持ったのか。その仮説を、組織の中でどう伝えたのか。その仮説をもとに、何を決めたのか。そして、その決定の結果、何が起きたのか。こうした一連の学びが蓄積されていけば、組織は一つひとつの調査を「点」で終わらせず、次の意思決定につなげられるようになる。そして、AIはその蓄積された知識を横断して、人間だけでは見つけにくかった変化やつながりを見つけることができる。
私は、ここにAI時代のRapiQの可能性があると思っています。RapiQに問いかければ、その会社がこれまで積み重ねてきた顧客理解をもとに、「今、何が起きているのか」「過去と比べて何が変わっているのか」「これまでの仮説と矛盾しているものはないか」「今、何を考えるべきなのか」「それをどう伝えれば、組織の中で理解してもらえるのか」「次に何を検証するべきなのか」まで、一緒に考えてくれる。
そうすると、意思決定のために毎回ゼロから情報を集めなくてもよくなる。過去の調査や、これまでの顧客との対話、そこから生まれた仮説や学びが、次の判断の土台になる。そして、AIがその情報を整理してくれるからこそ、人は「情報を探すこと」ではなく、「その情報をどう解釈して、どう伝え、何を決めるのか」に時間を使えるようになる。
これは、単に「意思決定が速くなる」という話ではありません。意思決定の根拠が、個人の頭の中だけではなく、組織の中に蓄積されていく。
私は、ここがAI時代の組織にとって、かなり重要な変化になると思っています。もちろん、最後に決めるのは人です。AIが「正解」を決めるわけではない。むしろ、AIには情報を集め、整理し、過去の知識とつなげてもらう。そして、それを人が理解し、周囲に伝え、最後は自分たちで考えて決める。私は、AI時代の意思決定は、そういう役割分担になっていくんじゃないかと思っています。
顧客の声を集める。 AIがそこから学びを整理する。学びを組織の知として蓄積する。その知を、伝わる形にする。そして、次の意思決定につなげる。この循環を、RapiQでつくっていきたい。そして、それによって最終的に変えたいのは、リサーチのやり方だけではありません。
AIとともに、企業が顧客を起点にどう考え、どう伝え、どう決め、どう事業を動かしていくのか。その意思決定のあり方そのものを、変えていきたい。それが、これからのRapiQで目指していることです。
10. これからAIと向き合う方へ
最後に、これからAIプロダクトをつくろうとしている方に向けて、伝えたいことがあります。
私は、とりあえず作ってみることがいいと思っています。私はもともと、人に「これ分からない」と言ったり、苦手なことをお願いしたりするのが、あまり得意ではありませんでした。でも、AIには「これできないからやって」と気軽に言えるんですよね。
だから、「なんでもAIにやってもらおうよ」くらいの精神から始めればいいと思っています。
「これやりたいからやって」「これできないからやって」「こういうものが欲しい」「なんか違うから変えて」みたいな、ちょっとわがままなくらいのことをAIに言っていい。あとは、自分が使いやすいようにカスタマイズしていく。
そうやって、やりたいことや、やってほしいことをどんどんAIに投げて作っていくと、もしかしたら誰も考えついていなかったプロダクトができているかもしれない。これは、かなり面白いです。
そして、もうひとつ。AIで何かを相談するだけではなくて、もっと自分の事業や仕事そのものをAIに渡してみてほしいと思っています。そうすると、今まで見えていなかった、自分がいる組織の「不純物」がすごく見えてきます。「これって、本当に人間がやる必要あるの？」「この承認プロセスって、何のためにあるんだっけ？」「これ、AIでやった方がいいんじゃない？」「自分の上司がずっと悩んでいることって、これで解決できるんじゃない？」そういうものが、いっぱい見つかってくる。
効率化できるところだけじゃなくて、「なんで人間同士でこんなことをやり合っているんだろう」という部分まで見えてくる。
AIを使うことで、今まで当たり前だと思っていた仕事の中にある違和感を、初めて客観的に見られるようになることもあると思います。
やっぱり、誰かが変えていかなきゃいけない。だから、まずは自分のところからやってみる。そして、それが自分のチームに浸透していく。さらに、その先の組織にも広がっていく。私は、AIを使って仕事をするというのは、単に自分の生産性を上げることだけではなくて、自分たちがどう働くのか、どう事業を動かすのかを問い直すことでもあると思っています。
RapiQをつくったことで、私自身もAIを「何かをつくるための技術」だけではなく、人や組織が、自分たちの仕事や意思決定そのものを問い直すための技術として見るようになりました。AIによって、つくることのハードルは確実に下がっています。だからこそ、これから問われるのは、「何をつくれるか」ではなく、「何をつくるべきか」。そして、その答えを考えるために、UXがある。
RapiQの開発は、私にとって、そんなことを考え直すプロセスでもありました。