リサーチデザインのすゝめ｜スタートアップで学んだ高速で効果的なアウトプットの出し方
どうすれば限られた時間内で最高のリサーチアウトプットが出せるのか
どうすればリサーチを効率的に進めることができるのか
どうすればリサーチをデザインできるのか
というテーマで今回は、僕がスタートアップで実践しているリサーチ手法を紹介したいと思います。
＊タイトルを「新卒に知ってもらいたいリサーチデザインのすゝめ」からより多くの人に読んでもらいということで「リサーチデザインのすゝめ」に変更しました。
まずは簡単に自己紹介。
ARスタートアップ MESONでディレクターをしているトミー(＠KurokoTom)といいます。AR技術を扱うプロジェクトの進行に携わりながら、企画段階でのリサーチなども担当しています。ビジネス・UX系や技術系のリサーチなど幅広く行っています。
この記事は、リサーチタスクで苦しんでいる方々、特に新卒でリサーチに苦しんでいる方々に向けて書きました。3つのフェーズに分けて、ステップごとにリサーチ手法を説明しています。
それらのベースとなる考え方が、問題解決の手法としてのリサーチ。
与えられた依頼を「問い」と捉えて、その問いに対してどのように答えを見つけていくのか、どのようにアウトプットを生み出すのかを考えるためにリサーチをデザインしていきます。
今回はそんな『リサーチのデザイン』をテーマに綴っていきます。
【念の為の注意】
このnoteはマーケティングリサーチやユーザーリサーチなど特定の目的に応じたリサーチの手法ではなく、より汎用的に様々な場面で使えるようなリサーチデザインの手法の紹介になります。そのため、リサーチ以外の場面でも参考になるかと思う一方で、特定の用途に応じたリサーチに関しては他の記事を参照していただければと思います。
では早速、高速で効果的なリサーチを始めましょう！
【設計】 「問い」の特定とリサーチの設計
リサーチにおいて最も大事なフェーズで、リサーチを苦手をする人が最も意識ないフェーズがこの『設計』です。この段階で「問い」となるリサーチテーマの特定と問題解決の指標となる仮説を立てていきます。
大きく以下の図のような流れで進めていきます！
■ リサーチタスクの認識合わせは入念に！
リサーチタスクの起き得る問題の一つは、「アウトプットが依頼時のイメージと違う...」ことです。そんなケースを避けるためにも、リサーチの依頼を受けた時点で、アウトプットの認識合わせは入念に行いましょう。
僕は以下の3つの項目を意識して認識を合わせています。
【Expectation：アウトプットの想定】
・ どのプロジェクトに使われるものか
・インナー用か外部共有用か
・最終アウトプットの形式は何か
・どれくらいの分量を想定しているのか
実際のリサーチアウトプットを使う場面を想像することは、アウトプットの方向性を確認し、「問い」を具体的に設定するために重要です。さらに、想定されるアウトプットの形式や用途によって、まとめ方やタスクとしての時間配分が変わってくるので入念に確認しましょう。
【Scope：リサーチ範囲の確認】
・国内外、業界の内外のどこまでリサーチの範囲を広げればいいのか
・リサーチの用途としてどの領域にフォーカスすればいいのか
言ってしまえば、この世の中全てがリサーチ対象です。
だからこそ、「問い」の範囲を絞って関連する対象にリサーチを集中させる範囲を絞って対象にリサーチを集中させることが必要となります。用途に合わせて、事例や研究、ユーザーインタビューなど特定の領域にフォーカスを当ててリサーチの骨格を設計します。
【Priority：期間と優先順位の確認】
・いつまでに必要なのか？
・他のタスクと比較した際の優先順位は？
リサーチには終わりはないです。そのため、意識をしないと時間を使いすぎてしまします。
基本的にリサーチの期間は、主にプロジェクト全体のスケジュールに依存しているため、いつまでにその情報が必要なのかを明らかにしてから、スケジュールを調整することが重要です。リサーチを依頼された時点で、現在抱えている他のタスクとの優先順位を考えて、俯瞰的に時間配分を考えましょう。
■ 『仮説』の設計
『仮説』はリサーチを加速させる線路のようなものです！
この仮説を立てるか立てないかで、リサーチの効率が段違いに変わってきます。具体的になった「問い」を解消する'可能性のある'仮説を立てて、リサーチの方向性をデザインします。
そんな仮説には3つのレイヤーが存在します。
【アウトプットの仮説設計】
最終アウトプットに必要な項目・情報をイメージして洗い出す。
【リソースの場所の仮説設計】
必要な項目・情報はどこにあるのかをイメージして洗い出す。
【アプローチとクエリの仮説設計】
リソースの場所にたどり着くために、クエリの選択や
どのようなアプローチを取ればいいのかをイメージして洗い出す。
上から順に十分な仮説を立てることで、ロジカルにリサーチの戦略を組むことができます。アプローチとクエリの仮説設計まで終了すれば、あとは実際に手を動かし始めるだけです！この時にも、設計した仮説をどの順番で検証していくのかを考えて、仮説検証の優先順位づけを行います。
例えば、「スマートシティ」に関するリサーチであれば、以下のような仮説がまず考えられます。
【アウトプット】
評価インデックスをもとにスマートシティを評価する
スマートシティに必要な主要な技術を網羅的に説明する
・・・
【リソースの場所】
どこかの企業がおそらく評価インデックスを元に総合的に整理している
スマートシティがプロモーションのために使用技術をまとめている
・・・
【アプローチとクエリ】
複数あるインデックスを探す（→評価軸を整理する）
スマートシティの主要コンセプトと必要な技術を思いつく限りリスト化
・・・
このような形で段階に分けて仮説を書き出していきます。
通常のアイデア出しのように、頭を柔らかく可能性のある仮説をアイデアのように整理すると、この後のリサーチの方向性が見えてきます。
ただし、これはあくまでも仮説です！
あとで説明をしますが、この段階で立てる仮説は、個人の妄想という面も多く含んでいるので、リサーチをしていく上でどんどん修正を加える必要があります。
■ リサーチスケジュールの設計
リサーチアウトプットの認識合わせと仮説立てが終わったら、実際に取り組むスケジュールを簡単に立てます。
スケジュールは前述の通り、他の抱えているタスクとの優先度の兼ね合いで組んでいきます。リサーチはだらだら時間をかけてしまいがちなので、自分のスケジュールにしっかりと予定を書き込みながら組み上げましょう。
僕はマイルストーンとして『2割報告』と『7割報告』を設定しています。
『2割報告』は、仮説立てが終わり次第、想定アウトプットイメージを共有します。この段階では、軽めのリサーチはしてもよいですが、リサーチ結果の共有はこの段階では特にやりません。『2割報告』の目的はあくまでも、リサーチに移る前の最終すり合わせです。
『7割報告』では、リサーチタスクが70%ほど終わったタイミングで、リサーチの現状と残り30％の進め方の方向性を確認します。リサーチがある程度進んでから、「気がつかなかったけど、この方向性に興味がある！」と言ったことが往々にして起きるため、この段階でのチェックをオススメします。
スケジュールまで組み終わったら、あとは実際にリサーチを始めましょう！
＊この章のおまけとして、リサーチの依頼が来る際に使われるテンプレをちょい見せします！
シンプルですが、社内で情報を共有するために必要な「依頼主とリサーチ担当者」や「デッドライン」、そしてアウトプットイメージに必要な「ゴールと背景」が載っています。共有されたこのドキュメントを元に、認識のすり合わせやリサーチ初期の仮説設計などを行っています！
【実行】 検証と蓄積と分類で問題解決への準備
設計フェーズをもとに、実際に「問い」を解決するために必要なリサーチを実行するフェースです。
以下の図のように仮説検証と情報を集めていきます！
■ 仮説検証
リサーチの実行は「PDCAサイクル」を高速で回す作業に似ています！
仮説を検証して、結果を評価して、仮説の改善をした新しい仮説を立てて、新しい仮説を検証して、......とこのサイクルをひたすら繰り返します。
順を追ってみてみましょう！
【1. 設計段階で立てた仮説を検証する】
設計段階の「アプローチとクエリの仮説設計」で立てた仮説を信頼度の高い順に検証していきます。ここからゴリゴリ手を動かして、仮説ベースでリサーチを始めます。
【2. 仮説をCriticalに評価する】
仮説をもとにリサーチをして、その仮説が妥当がどうかを判断します。
もちろん、自分の探している情報が掘り出されれば、その仮説は「妥当」と評価し、ある程度やってみても堀り出なければ、その仮説は「不当」と評価します。そして「不当」と評価した仮説は、そもそも的外れなのか、それともフォーカスがズレていただけかを判断する必要があります。
【3. 評価をもとに仮説をブラッシュアップする】
それぞれの仮説の「妥当」と「不当」の評価をベースに、新しく仮説を立てていきます。この段階ではすでに行ったリサーチの蓄積があるので、より信頼度の高い仮説を立てることができます。
水平思考を盛り上げて、信頼度の高い領域から円周を広げるように、仮説のフォーカスを絞りつつ幅を広げていきます。
このステップを図にすると↓のようなイメージです。
最初の仮説は小さな点のようなイメージで、検証の過程でいらない点を削り、深堀たい点・水平に展開できる点を広げていきます。この仮説検証プロセスを繰り返すことで、アウトプットに必要な情報がそろっていきます。
■ 情報蓄積
仮説をベースにリサーチをしている際に、もちろん多くの情報を発見できるかと思います。その時、情報の蓄積方法で作業のしやすさに影響してきます。なので、僕が気をつけているポイントを3つ紹介したいと思います。
まず最初に、見つけた情報は一文でまとめる。
膨大なサイズのリサーチをすると、自分の記憶力だけでは内容を把握仕切れなくなります。それを避けるためにも、発見した情報やソースは一文で、その特徴とアウトプットでの活用方法をまとめておくと後々便利です。
二つ目に、情報にタグ付けをする。
僕は情報を蓄積している表（もしくは場所の側）に、タグ付けのようにキーワードやカテゴリを書き出しています。この後の分類で役に立ちます。
最後に、関連しそうな情報はとりあえず蓄積する。
使えるか使えないか判断できない情報資料はとりあえず蓄積しておきましょう！どこかのタイミングで振り返るかもしれません。ただし、優先度は明確に必要な情報よりは下がるので、ドラフトの下、もしくは別のドキュメントに追記するような形で蓄積していきます。
一色単にするのではなく、優先度に応じて分けて蓄積していくと全体像を見失うことを避けることができます。
■ 情報分類
リサーチを実行して情報を蓄積した最後に情報の分類を行います！
僕の場合、大きく2つのステップで情報の選別を行っています。
1. 「今回使える情報」と「今回は使わない情報」
2. 3〜5ほどのMECEな大カテゴリ
まずは集めた情報を「今回使える情報」と「今回は使わない情報」に分類します。情報量が多いリサーチアウトプットが必ずしもいいとは限りません。リサーチアウトプットの目的は必要な情報を適切に届けることだからです。
なので、分類時には「今回使える情報」のみをピックアップする必要があります。ただし、「今回は使わない情報」もせっかく集めた情報ですから、別のドキュメントに合わせた形で保存しておくのがおすすめです。
また「今回は使わない情報」には複数の類似する情報・事例も含まれます。
類似の事例を複数説明しても大きな価値にはならないので、複数ある場合は、その中から最もリサーチテーマに近く説得力を生むことのできるものを選びます。
次に、情報から大きく3〜5個の大カテゴリに分類します。
大カテゴリの数が多くなりすぎた場合、最終アウトプットで全体を俯瞰的に見れなくなってしまうので、3〜5が適切な数かと思います。（マジックナンバーというわけではありませんが）
この時に、できる限りMECE（Mutually Exclusive, Collectively Exhaustive）を意識することも重要です。断片的なアウトプットを避けるため、より説得力のあるアウトプットを出すために、リサーチのテーマ全体を大きな漏れなく見渡せる分類方法を見つけることができるとベストです！
■ 実践例）スタジアムで活用されたARリサーチ
この章の最後に簡単に以前僕が担当したリサーチを紹介したいと思います。
その時のテーマは「スタジアムで活用されたAR事例」。
まずは以下のような仮説を設計しました。
1. 「スマートスタジアム構想」にARが組み込まれている。
2. 観戦体験のアップデートへの需要がある。
3. 来場者参加型のAR応援が増えている。 etc.
これらをもとに、実際にリサーチをはじめ、その後仮説の評価を行います。
1. 【妥当】→ スマートスタジアム構想には通信キャリアが積極的に投資をしていて、その中でARを取り入れている。
2. 【妥当】→ 観戦体験のアップデートはスタジアム側で様々な施策がすでに行われており、テクノロジーを総合的に使った企画が進められている。
3. 【不当】→ 来場者が直接参加できるAR応援はまだ少ない。 etc.
その後、仮説検証と情報の蓄積をゴリゴリ進めていき、最終的に3つのカテゴリに分類しました。現状を見る限り、かなりMECEに事例を整理できたのではないかなと思います。
・観覧型ARコンテンツ
・説明型ARコンテンツ
・エンタメ型ARコンテンツ
そして、それぞれに過不足のない量の事例を載せて、このフェーズは終わりです！
【説明】 チームでの問題解決に向けてアウトプット整理
最後のフェーズは、実行フェーズのリサーチで集めた素材を問題解決のためのアウトプットに変えていきます。このアウトプットは自分に向けたアウトプットではなくチームに向けたアウトプットになることを意識します。
以下の図のように、分析とアウトプット作成を進めていきます！
■ 分析
分析を丁寧に行うことで、本当に意味のあるリサーチアウトプットになります。リサーチを通じてプロジェクトチームとしての知見を蓄積するためには、事例の羅列ではなく、分析が必須となります。
カテゴリごとに分類された情報を一旦抽象化して、そこから何が言えるのかを考えます。つまり、今回の「問い」の要素を改めて考えます。領域における共通認識や業界のトレンド、将来分析などなど、必要なアウトプットに応じて方向性を決めて「問い」の分析を行います。
各事例にも、それぞれ「どのように分析に関連しているか」「どのように分析をサポートしているのか」を明記しながら、説明を加えていきます。
そして最後にリサーチ全体の分析を行います。
全体の分析で抑えておく内容は2つ。
まずは、リサーチの前提の分析です。
「そもそもそのリサーチテーマはどのような構図なのか」「今回のリサーチでどのようにフォーカスを絞ったのか」など、リサーチアウトプットに入る前に「問い」のテーマと自分が行ったリサーチの外観を分析します。
2つ目は、カテゴリの繋がりの分析です。
「複数のカテゴリを繋げてどのような結論が導けるのか」「それぞれどのように異なり、どのように関連しているのか」などを明確にすることで、問題解決に繋がるアウトプット全体の外観を整えていきます。
それでは、最後にこの分析を
アウトプットの形に落とし込んでいきます！
ポイントは以下の2つ。
『前提知識0の人が簡単に理解できること』と『外観を俯瞰できること』
レポートとプレゼンテーションに分けて見ていきましょう！
■ レポート
まずは、レポートとしてアウトプットを提出する場合、以下の2つが必須になります。
・ドキュメントの目次
・リサーチの要約
前提として、レポートを最初から最後まで読んでもらえる前提で考えないほうが無難です。基本的に読み手は、ざっと外観を知れて、気になる点のみ深ぼって読むと想定する方がいいでしょう。
そのためにまず必要な要素が『ドキュメントの目次』です。
先頭に配置することによって、読み手に興味のあるトピックを探してもらい、瞬時に目的の内容を確認してもらうように設計をすることができます。そのためにも目次のタイトルはそれぞれ、一目で内容が予測できるものをお勧めします！
次に『リサーチの要約』です。
読み手は、まずは概略を抑えたいと考えています。
なので「このリサーチでどのようなことが発見できたのか」「プロジェクトに活かせる内容はあるのか」をドキュメントの冒頭で伝えます。
この要約は3パラグラフ構成（トピックの概要＋カテゴリ紹介＋プロジェクトとの関連性）ほどにまとめられるとベストかなと思います。
また、この時に『読み手は前提知識0である』という前提で、可能な限りわかりやすく伝えることが超重要です！
リサーチが一通り終えると、前提知識のレベルが上がり（すぎ）、自分にとってだけの「当たり前」が生まれてしまいます。その状態で伝えると、前提認識の共有がおそろかになるため、十分にリサーチ内容を伝えることが難しくなります。
そのためにも「リサーチの要約」には、簡潔かつ前提知識が含まれている必要があります！
■ プレゼンテーション
プレゼンテーションもレポートと同様の『聞き手は前提知識0である』という前提で組み立てます。それに加えて、『聞き手は要点のみを知りたい』という前提も考慮に入れることで、よりスマートなプレゼンテーションになります。
プレゼンテーションでは、レポートを最初から最後まで読むことはせずに、全体の内容を1〜2分で把握できるように要約を整えます。簡潔に述べれば述べるほどインパクトの強いプレゼンになり、伝えたいメッセージをしっかりと伝えることができます。
その一方で、口頭プレゼンで網羅性を追求しすぎると、結局要領を得ないプレゼンになってしまうので、注意した方がいいと思います。
(＊) ただし、これに関してはプレゼンの種類にも関係があると思いますので、臨機応変に対応してもらえると。
また、事例紹介なども、プロジェクトの参考になりそうな最も有益な情報をキュレートして伝えることを意識することも重要です。事例を紹介する際には、事例の詳細も重要ですが、リサーチの中でのそれぞれの事例の役割やポジションを明確に説明することの方が重要だと考えています。
ー ・ー ・ー・ー・ー ・ー ・ー・ー・ー
これでリサーチデザインの流れの紹介になります！
だいぶ長文になってしまいましたが、
お付き合いいただきありがとうございます！
ー ・ー ・ー・ー・ー ・ー ・ー・ー・ー
最後に、少しだけ僕の持つリサーチの所感について簡単にお話しします。
日常をリサーチの舞台に
「設計フェーズ」での仮説立てやクエリの発見には、事前の知識の多さが鍵となります。すでに知識があれば、それだけ確度の高い仮説が立てられ、クエリを発見できますから。
なのでリサーチを任される人は、人一倍アンテナを周囲に張り巡らせておく必要があります。
スタートアップなどの企業では特に動きが早いため、毎回違った角度と領域へのリサーチ依頼が来るかと思います。それに対応するためにも、可能な限り手持ちの知識の量と層を増やして、来るべき日に備ることが、最高のアウトプットを出すための秘訣になります。
日常をリサーチの舞台として考えて、貪欲に情報と知識を蓄えて行く。
これが最高のアウトプットを出すための第一歩です。
プロジェクトとしてのリサーチ
■ リサーチはプロジェクトの起点
リサーチはプロジェクトが本格始動する前の企画段階に依頼されることが多いかと思います。つまり、リサーチはプロジェクトの起点に位置すると言っても過言ではないです。
プロジェクトメンバーが最初に参考にする資料として最高のアウトプットを出すことは、個人（特に新卒）がチームにコントリビュート出来る最もやりがいを感じるタスクと考えています
さらには、プロジェクトの起点として、開始前のプロジェクトの行き先を考えることは、リサーチタスクの醍醐味の一つです！
■ リサーチはプロジェクトの柱
リサーチがプロジェクトの起点ということは、プロジェクトのこれからの道筋が、このリサーチによって少なからず影響を受けるということでもあります。
中途半端なリサーチはプロジェクトに後々まで悪影響を及ぼす可能性があるために、リサーチャーにはそれなりの責任がのしかかります。そのために、リサーチの設計フェーズでしっかりと認識をすり合わせ、ロジカルにリサーチを進めることが大事です。
ロジカルでMECEなリサーチアウトプットは、プロジェクトの最後までチーム内で共有されて、最後までプロジェクトの柱として役に立つ。と信じています！
■ リサーチはプロジェクトの縮図
お気づきの方もいるかも知れませんが、リサーチはプロジェクトの縮図でもあります。
依頼主から依頼をもらい、
設計フェーズで企画を考え、
仮説を立てて、
検証をしながら進めていき、
最後には成果物としてアウトプットを提出する。
この一連の流れを個人でこなすことで、本格的なプロジェクトの流れをシミュレートしながら学ぶことができます。特に仮説検証プロセスは、企業では日常的に繰り返す作業であり、社会人にとっては必須のスキルです。
新卒でプロジェクトの流れを把握しきれていない人にとって、リサーチはもってこいのタスクなのではないでしょうか。
ー ・ー ・ー・ー・ー ・ー ・ー・ー・ー
おわりに
偉そうに長々と書いてしまいましたが、僕自身も最高のリサーチアウトプットを出すために道半ばです。リサーチの深さや網羅性など改善できる点は多くあり、今後もリサーチデザインの手法を改善していくための研鑽を積んでいこうと思っています。
MESONのCEOカジさんをはじめとする方々にリサーチを教えてもらったように、この記事が読んでくれた方に少しでも助けになればいいなと思っています。
最後まで読んでいただきありがとうございました！
ー ・ー ・ー・ー・ー ・ー ・ー・ー・ー
僕が所属しているMESONは「Spatial Computing時代のユースケースとUXをつくる」をテーマに掲げて活動しています。MESONで一緒に働いてくれるメンバー、プロジェクトをご一緒できる企業を募集中です！
僕のTwitter（@KurokoTom）も同じくよろしくお願いします！