UbieのResearchOpsの現在地
大家好、Ubieのデザインリサーチャーのawa(@n_awamura)です。
赤福食べたいです。
今年3月の入社からしばらく経ちまして、久々に発信してみようかなと。
UbieのResearchOpsについて書きます。
動機は2つあります。
まず、UbieのResearchOps、この1年でけっこう進化したな〜と思っていること。
次に、記事の後半で触れるように、生成AIで次の非連続っぽいフェイズが見えてきているので、その前がどのようであったかを忘れ去られる前に残しておきたいな、という気持ち。です。
デジタルプロダクトのプロダクト組織やマーケティング組織に興味がある方には、あるいは参考にしていただける内容も含まれているのかもしれません。
前置きが3つあります。
ユビーには事業がいくつかあり、僕はそのうちtoC事業に入っているので、以下の記事もその視点で書かれています。ですので、ResearchOpsの全体像という意味では別の記述余地があるかもしれません。単純に入社10ヶ月やそこらでの経験総量がそうだ、ということです
定性リサーチ(インタビューやエスノグラフィなど)とアンケート調査のOpsを念頭に進めさせてください。これも単純に、現時点で、筆者の力が及ぶのがその範囲であるためです
ResearchOpsの発展には、僕だけではなくいろんな人が関わっています。僕は全体に濃淡はあれど参加している人として (入社前については伝聞ですが)、概説的に書いていきます。個々のテーマのさらなる深掘りは先であるとかないとか？
それでは、行きましょう。
ResearchOpsとその重要性
前提として、ResearchOpsとはなんぞや、から始めるのが良いでしょう。
概念は以下の記事にひと通り押さえられていると思います。
個人的な実務的定義は「デザインリサーチ、UXリサーチ、マーケティングリサーチなどの円滑な進行を可能とする間接業務すべて」で、間接業務と言っていることは、ざっくりと
案件マネジメント (会いたい人に会いたいときに会えるようにすること)
知識マネジメント (知識を得たい人が得られるようにすること)
の2領域で理解しているかなと。
直接と間接に優劣はないです。というか、むしろResearchOpsとしての動き方にそのリサーチャーの経験値が一番よく出るのでは、と思っています。
Opsの見立てが、プロジェクトマネジメントの核に他ならないためです。
ResearchOpsの重要性が相対的にまだ認知されていない理由に、デザインリサーチャーへのイメージがあると考えています。
どの会社に行っても、リサーチャーへのイメージは、端的に「優れたインタビュアー」に近いと感じます。
実査(インタビューなどを実際に行なうことを指す業界用語)の場で、相手の話を引き出して、それを見通しのよい形でまとめ、なんらかの提案なりに繋げる。これら一連の行為が上手い人、それがリサーチャー。
というわけで、そこに光が当たるわけです。
実査が上手いのは、まあ、リサーチャーと名乗るからにはそうでなくてはならない、のですが、実査、分析、提案を仮に直接業務としたときに、それらを円滑に成立させるための膨大な間接業務も発生します。
たとえば、予算取り、アポ取りリストの作成、実際のアポ取り、機密情報関係、謝礼の手配、リサーチ結果の集約、などなど・・。
各ケースでどうするかはリサーチに用いる手法によっても変わってくるし、その時点の目的によって優先度、着手順、スケジュールのバッファなどもダイナミックに組み替えなければなりません (スタートアップにおいては、1週間に2回くらいテーマが変わることなど日常茶飯事です)。
この全体が、上でプロジェクトマネジメントと言っていることです。
リサーチの種類や総量が少ないうちはまだリサーチャー自身がOpsを担当できますが、増えてくるとだんだん認知と気遣いの限界を超え、いろんなことが後回しになったり、結果こぼれていったりします。
リサーチを仕組みとして継続していくぞ、と決めた時点で、ResearchOpsの専任スタッフを作る必要が出てくるでしょう。
いまのUbieのResearchOpsの形
Ubieには、プロダクト組織に「toCユーザーに連絡を取るチーム」がプラットフォーム的に存在し、そのチームの一部としてResearchOpsの機能が存在しています。
実際のチーム名の説明は本筋ではないので、本記事ではResearchOpsで行きます。
リサーチ担当者との役割分担の大枠は、
という感じで、割とスタンダードだと思います。
もちろん、縦割りではなく、各ケースで最も進めやすい形に合わせて都度調整・連携しながら進めます。
UbieのResearchOpsの発展史
どのように発展してきたか、を書いていきます。
リサーチ担当者ががんばるが・・
もともとUbieには長らく主にデザイナーが頻度高くユーザーインタビューをする文化がありました。
案件と知識のマネジメントの仕組みもあったのですが、僕が入社した時点(2024年3月)ではそのアップデートは追いつかなくなっていました。
PoC含めたプロダクト数が増加の一途をたどる中、毎日勤務するOpsスタッフはおらず、リサーチ担当者は実査の成立および事業の進行を優先せざるを得ない、という文脈において、仕組みのアップデートには手が回らなかったためです。
とくに、知識マネジメントに手が回らなくなっていました。
具体的には、
プロジェクトやリサーチ担当者によりドキュメント形式も保管場所も違う。検索性にもばらつきが出る
検索性と法令遵守のバランスを取らなければならない
得られたインサイトなどを書き留めたドキュメントがハイコンテクストで、プロジェクト外の人が読んでもよくわからない
データベースの構築や維持が有志の空き時間に寄っており、業務の繁閑に応じてムラが出たり、各時点のプロジェクトに最適化されたデータベース項目のままになったりしている
といった課題がありました。
これらはむしろあるあるで、大部分のデザインリサーチ実践者は身に覚えがあると思われます。
前職でも同じことに直面しました。
僕が入社した時点(2024年3月)では、有志デザイナーがなんとか仕組みをアップデートしたり作ろうとしていたりするけれど、なかなか進んでいないような状況でした。
しかしながら「なかなか解消されない課題があって、このままだと損っぽい」というところまでデザインリサーチが盛り上がっているのがまず大事で、これらの認識がこの後の取り組みの土台となっていきます。
案件マネジメントを切り出し、業務フローやチームなどを最適化する
「安心してインタビューできないと始まらない」ので、案件マネジメントのアップデートがまず行なわれました。
ここで中心的な役割を果たしたのが、カスタマーサクセスの背景を持つメンバーです。
Ubieにはもともと、ユーザーの方にアンケートをお願いするチームがありました。
このチームとインタビューのアポ取り業務は事業史的な理由で分かれていたのですが、「toCユーザーに連絡を取る」ということでは共通しているので、ResearchOpsもその整備に合流させてもらえることになったわけです。
「こうなればいいと思うんですよね」をそのメンバーに持っていくと、
業務フロー
業務ツールセット (Slack、Notion、Google Driveなどで構成。ワークフローやデータベースなど)
業務マニュアル
業務チーム
が次々と形になっていきました。
今後を見据えて、必要十分にセキュリティを守りつつ、持続・拡張可能な感じにバランスを取って設計されているのがプロの仕事で、側で見ていてすごかったです。
案件マネジメントに知識マネジメントを埋め込む
案件マネジメントの整備の中で、その中への知識マネジメントの埋め込みも行なわれました。
「プロジェクトお疲れさまー。ちょっと結果をデータベース化してほしいんで、次のプロジェクトまで時間をさしあげます」とは通常ならないです。
むしろ、次のプロジェクトへの速やかな着手が求められるため、動画をフォルダに入れることさえ後回しになりがち、なのが自然状態での現場力学ではないでしょうか。
そこで、Opsメンバーがアウトプット(発話録や録画データなど)収集の手綱を持つことで、案件マネジメントの一環として知識マネジメントが行なわれることとなりました。
ドキュメントの散らばり具合がまだそれでも小さい企業フェイズでこれが仕組み化され、当たり前のことになりつつあることは、必ずや今後に活きていくのだろうと思います。
学び
ResearchOpsの環境面は今日までのところ、以上のように整備されてきました。
汎用的な学びを引き出すとすると、
まずは「リサーチ担当者がとにかくがんばる」では限界があるしもったいないよ、というところまで機運を盛り上げる
直接業務と間接業務を必要十分に分離する。とくに後者については、可能な限りカスタマーサクセスなどのBiz的なオペレーションに入っている人、かつ、オペレーション構築スキルがある人に整備の座組みに入ってもらう。そして、既存の仕組みも活用しながら、業務フローなどを作る
案件マネジメントに知識マネジメントを埋め込む 。実査が済めばよしとしない
あたりが振り返ってみてポイントだったと言えるでしょう。
今後 〜 生成AIを活用した知識マネジメントとデザインリサーチ民主化
以上のように、環境はかなり整ってきました。
一方で「検索性そのものはある程度上がったが、過去のコンテクストがわからないので、どう検索していいのか今ひとつ当たりがつかない」という課題はまだ残っています。
過去にこれを「発掘」と呼んだことがあります。
「発掘」の実際のところはかなり原始的で、
「事情を知っているっぽい人に声をかけてキーワードをもらう → がんばって検索したりなんだりで解像度を上げる → インサイトを引き出す」
という流れになると思います。
ここには、時間の壁、この種の検索慣れの壁、分析スキルの壁、の3つの壁があります。
ところが、このところの生成AIの発展により、「発掘」の自動化が非連続に進む可能性が出てきました。
ごくごく簡単に言うと、生成AIにデータをインプットしたら、生成AIがかなりのところまで「発掘」してくれるということです。
現在、生成AIとデザインリサーチ民主化にとりわけ熱意のあるデザイナーがリードして、内製プロジェクトが進んでいます。
生成AIの取り込みが進むことにより、以下のようなメリットが出てくるのだろうな、と予想しています。
ファクトのあるなしがわかったり、ざっとグルーピングができればいったん必要十分なテーマについて、分析のかなりの自動化が可能となる
もう一歩複雑なテーマについても、これまでスキル面で手を出しづらかったメンバーが手を出せるようになる
リサーチスキルが高いメンバーは、「もう1人(複数でもいいかも)のチームメンバー」に生成AIを迎えた仮想リサーチチームを編成できるようになる
そうなったときのデザインリサーチャーの役割には、各時点の生成AIではできない実査とインサイト出しを行なうのはもちろんのこと、生成AIで必要十分なのかそうではないのかのトリアージだとか、生成AIに支援されたリサーチプロジェクトの設計やサポートだとか、生成AIで見えなくなりそうなことのカバーだとか、が少なくとも付け加わることになるでしょう。
まさに、ドン・ノーマンが新著『より良い世界のためのデザイン』において「オーケストラの指揮者」と表現したような動き方へのシフトが加速していくと予想されます。
リサーチャーに限らず、きっと多くの職種がそうなっていくのでしょう。
生成AIの進化による仕事内容の変容への適応を不断に求められる時代に自分がどう仕事をするのか、できるのか、は、なかなかスリリングではあります。
おわりに
UbieのResearchOpsの現在地はこんな感じでした。
ResearchOpsと言いつつ、最後のほうはデザインリサーチャーの未来みたいなことを書きましたが (まあ、そもそもは一体のものなのでして)、実際のところ、まさにいま生成AIへの取り組みが盛んな組織で働くことは、キャリアを考える上で非常に重要なポイントになるのではないかということをヒリヒリと体感しています。
リサーチに関わらず、あらゆる職種が生成AIと渾然一体となった新たな働き方へとシフトしていく今。
さらにヘルスケアというドメイン。
「自分の、そして人間の未来とは」を深く考えられる、ヘルスケア × 生成AIのスタートアップで働くことに興味のある方は、あまり考え込まず、お気軽にXでDMをいただければ幸いです。
ええ感じにできます。
1人めデザインリサーチャーの1年めがどんな感じだったかも、来年、機を見て発信しようかなと思っています。
その頃には、デザインリサーチャーという職種の未来予測みたいなところももうちょい精度が上がっているかも。
それでは、またどこかで。
再見。