見出し画像

新卒時代によくやっていたデスクトップリサーチの失敗と、現在の対処法

こんにちは、note株式会社UXリサーチャーの仙田です。

社会人になってからデスクリサーチをすることが度々あり、たくさん失敗をしてきました。2年間の失敗や学びを踏まえて、今デスクリサーチをするときに気をつけていることを書こうと思います。

1年目によくやっていた失敗と、だから今こうして対策してる!という話をセットで書いてみました。

我流な部分がおおいですが、もしデスクリサーチやリサーチに苦戦している誰かの参考になればと思います。

※ここで言う「デスクリサーチ」は主にインターネットで市場調査や競合調査をすることをイメージしてます🙏

1.目的設定のコツ

関係者と目的をきちんとすり合わせる

リサーチを指示・依頼されたら、つい「はい!分かりました!」と返事をしたものの、いざ調べ始めると「やっぱり何を集めたらいいか分からん…どうしよう…」と混乱。
方向性があやふやなまま1日かけて集めた情報は結局的外れ。1日が無駄になってしまった…みたいなことがしょっちゅうありました(進捗共有もド下手でした)

当時は目指すゴールの理解が浅かったり詰めれていないことが多く、目的と集めるデータが結びついていないことが多かったです。

今は誰が何の意思決定するためのリサーチなのか明確にして、そこから逆算して集めるデータを決めるようにしています。

例)【目的】動画投稿できる機能を開発するか決めたい

→【判断材料】動画市場が伸びているのかが客観的に分かれば、開発する

→【集めるデータ】動画投稿機能をつけているサービス数の推移、動画コンテンツで収益化しているクリエイター数の推移

今回は例だったのでかなり適当に書きましたが、本来なら「そのデータを集めて本当に目的が達成になるのか」きっちり詰めていく必要があります。

これがきちんと定まるまで関係するメンバーと議論するようにしています。

また、依頼する側で目的を整理してくれることもあれば、ふわっとた状態で相談されることもあります。(まだ依頼者も詰めきれいない場合など)
そこでもふわっとしたままにせず、どうしたら目的が達成できるのか壁打ちしながら明確にします。

自分の言葉で目的を言語化する。

目的を聞いてちゃんと理解した気になっても、調べていると途中からだんだん目的がずれてきて、あとで見返したら「このデータ何に役立つんだろう?」とガックリしたり。
あとは自分では合っていると思って情報を集めていても、他の人に進捗共有したらそもそも自分と目的がずれていたり。ということもよくありました。

なので、今は最初に目的を自分の言葉で言語化し、リサーチのステートメントシートを作るようにしました。

実際のステートメントシートがこんな感じ↓
この項目はフォーマット化して、いつも使い回しています。

場合によって多少の項目は変わりますが、だいたいこんな感じ↓

Google Docsで要点をまとめて箇条書きに。簡単でいいのでとりあえず書いておくことが大事。

■リサーチの目的
目的を完結に書いておく。だらだら書きすぎず、大事なことを完結に書くようにしています。

■誰のどんな意思決定/アクションに役立つ
このリサーチ結果をみて誰の役に立って、どんなふうにpjtや事業が前に進むかを明確にする。

■明らかにすること・知りたいこと
目的と意思決定を踏まえ、具体的にどんなデータを集めるか候補を出しておく。「逆にこれは調べない」ことも書いておくと脱線を防ぐことができる

■現状の仮説
すでに依頼者の中で仮説があれば先に聞いておく。確度の高い調査ができるし時短にもなる。もちろん自分でも仮説を出す

■調査手法
知りたいことに合わせた調査手法を考えておく。果たして今回知りたいことはデスクリサーチだけでわかるのか?専門家に直接聞いたり、ユーザーにインタビューした方がいい場合もある。目的より先に手法を決めないように注意。

■スケジュール
いつまでにゴールを達成するか、どのタイミングで誰に進捗を共有するかなどアバウトでもいいのでロードマップを敷いておく。

■関連資料
関係する会議の議事録や、SlackのやりとりのURL等を貼っておくと自分も見返しやすいし、他者への文脈の共有に役立つ。

ステートメントシートを作るようになってから感じるメリットはいくつかあります。どれも大事なことなのでステートメントシート最高です。

①目的から逸れるのを予防できる
目的を明文化することでズレを減らすことができます。
僕は議事録やレポートの冒頭にリンクやスクショを貼って、定期的に確認する癖をつけています。
また、もしここで決めた手法で調べて手応えがなかった場合、ここに立ち戻って別の手法を試すことができます。ベースとなる目的を明文化することで、やり直しがしやすくなります。

②自ら書き出すことで目的への解像度が上がる。
自分の言葉で目的を書き出すことで理解度を確認できます。
自分で書けなかったらまだ理解度が浅い証拠なので、もう一度話をしにいきます。

③関係者との認識を共通化するのに役立つ
会議やスラックのやりとりではなく、一枚のシートにまとめることで共通の議論の土台ができ、お互いの認識の齟齬を減らすことができます。

④準備段階の考慮漏れを防ぐことができる
スケジュール決め忘れてた!みたいなことが防げます。僕はスケジュールを敷くのが得意じゃないので、強制的に組むようにしています。

⑤他者への共有がしやすい
途中からプロジェクトに参加した人や他部署の人が簡単に情報を把握することができます。

進捗や状況に応じてステートメントは適宜アップデートしながらリサーチを進めています。

同僚の松下さんはチームで施策ドキュメントのテンプレ化をしています↓(めっちゃいいです)


2.調べ方のコツ

調べ方のコツは無限にあると思うので、特に僕が忘れがちだったり大事にしていたことを書きます。

ググる前に社内のデータを漁る!

いよいよ調査だ!と息巻いて1時間ほどデスクリサーチをしたけども…
自分が1時間かけて集めた情報は、既に社内の誰かが調べていてレポートにまとまっている!(しかも自分のより圧倒的に情報量が多い)なんてことがありました。

まずは社内のデータベースをチェック。Googleドライブやmiroをキーワード検索。自分が知らないだけで実は過去に仲間が調べてくれてる情報があるかもしれない。

社内Slackも必ず確認します。(Slackは結構高度な検索ができます
Googleドライブで検索漏れしていた昔のデータが見つかるかもしれませんし、有益なサイトを誰かが共有してくれているのに引っかかるかもしれません。

自分ひとりで探そうとしない

未知の専門領域や実際にサービスを長期間使ってみないとわからない体験などは、自分でゼロから調べると時間がかかってしまいます

そんな時は社内の人や詳しい人に協力を仰ぐことも視野に入れます。(エキスパートインタビューと呼びます)

既に知見を持っている人に聞いたほうがやっぱり早いですし、とっかかりが分かればその後の調査の精度も上がります。

特に事例をたくさん知りたい時などは人数がたくさんいるチャンネルで呼びかけることが多いです(みんなよくやってる)

ほぼ塗り潰しですみません。呼びかけるときは目的と欲しい情報を明確に。可能なら具体例をあげることを意識します。(呼びかけ方の正解は未だ模索中)

また、もっと複雑な文脈を知りたい場合は詳しい人に直接15分ほど話を聞きます。(短くミーティングを設定するの意識しています。長いとハードルが上がってしまう気がしてる)
その時もステートメントシートをベースにアジェンダを組み立てます。

その他デスクリサーチで意識していること

  • この世の誰かが既に調べてまとめてくれてることを祈って、知りたいことが網羅的にまとまっている資料やブログ、記事をまず探す。

  • いろんな媒体でいろんなキーワード検索を試す(Google検索、note、Medium、Youtube、Twitterなどなど)

  • 一次情報までちゃんと調べる

  • 良いサイトが見つかったらそこのリンクをたどっていくと有益情報や一時情報にたどり着きやすい

3.資料作りのコツ

情報をまとめるツールを先に決めておく。

いざ焦って情報収集を始めて、miroにスクショやリンクをたくさん集めたはいいものの、資料をまとめている途中で「これスプレッドシートにまとめたほうが見やすくない??」と気づくことがありました。
そこから引っ越すのはかなり面倒。時間もメンタルも削られます。

今は共有の仕方を見据えて先にツールを決めるようにしています。後からやり直しや引っ越しを防ぎます。ステートメントシート作るときに決めておいてもいいくらい。

個人的なツールの使い分けはこんな感じ↓

■Googleドキュメント
基本はドキュメント。ストーリーで情報をまとめられるので初見の人も文脈を把握しやすい。ドキュメントは意外とそのままプレゼンもできる

■miroとかFigma
アプリの画面遷移やグラフィックなど、画像が多いリサーチに向いている。ただ口頭補足がないと見方がわかりにくいかも。

■スプレッドーシートやエクセル
比較項目が多いとき。サービスごとにどんな機能があるか細かく比較したい時など。

テーブルはGoogleドキュメントやmiroで作れたりしますけどね。

場合によってはこれ以外のツールが向いてることももちろんあるので、目的と情報共有の仕方を意識して臨機応変に。

フォーマットを先に作る

さっきの話とつながりますが、たくさんデータを集めたはいいものの、ごちゃごちゃに集めすぎて後から情報を整理するのに時間をかけてしまう…という失敗をよくやっていました。

そこで先に資料の構成を作っておき、調べている時はデータやリンクをどんどん書き込めばいいだけにしています。
雑に突っ込んでも自然とまとまった資料ができるはず。

例えば「動画プラットフォームの動向調査」だったら下のように項目を先に書いておきます。(例なのでめっちゃ雑です)

ゴミを全部捨ててから分別するより、最初からゴミ箱を分けておいたほうが分別が楽みたいなイメージです(?)

調べて分かったことがあったらとりあえずここにリンクを貼ったり参考になりそうな部分をコピペしていきます。
途中で項目を増やしたり調整したりしますが、基本このまま集めて、最後に整理したりまとめたりします。

また、この構成を作る時は共有の方法や相手を意識して。
全社員に知って欲しいテーマなら予備知識も細かく書いたほうがいいし、自チームに向けたリサーチだったら予備知識を端折ってもいいかもしれません。

前提を忘れない。事実と解釈を分ける

リサーチ結果を見せた時に「これってそもそもサービス思想の話なの?ユーザー体験の話なの?」「これは根拠のあるデータなの?君の解釈なの?」と相手を混乱させてしまうことがよくありました。

リサーチにのめり込むとつい自分視点で情報をまとめがち。
初見の人が「ここは根拠のあるデータで、ここは調べながら気づいたことなんだな」と理解できるようにフォーマットを作っています。

特に注意しているのが事実と解釈を分けること。
自分の仮説を事実として共有してしまう恐れがあるので、混同しないように明示します。
「気づき」だけ段落を分けたり、解釈だけ文字の色を変えたり、miroだったら付箋の色で分けたりとかしています。

4.共有のコツ

Slack共有は忙しい人のことを考える。

Slackで情報共有する時は忙しい人が内容を瞬時に把握できるような投稿を意識してます。
自分の言いたいことばかりを詰め込んで冗長な文章になるとみんなが読みづらいです。

適宜小見出しや箇条書きを交えながら、想定している読み手が知りたい情報がすぐに理解できる投稿を心がけています

リサーチ結果を共有する会のslack告知も、誰にどんなメリットがあるのかを先出し。↓

参加してくれたらどんないいことがあるかを職種別に明示しています。最終的に20名くらいのメンバーが参加してくれました。

こまめな進捗共有

どちらかというと進め方の話ですが…
迷ったらすぐに先輩やプロジェクトメンバーに相談!と頭では分かっていても、もう少しマシな状態にしてから共有したい!と相談を後回しにしがちでした。(そういう時こそ進捗相談をするべきなのに。自信の無さからすぐに共有・相談ができない人間でした)

なので自分締め切りを決めて「何時までにSlackで進捗見せます!」と先輩に宣言したり、先に進捗共有ミーティングをセットしたりしていました。

共有の仕方は「今全体の何%くらい調べたのか」「これから調べようとしてること」「悩んでいること」とかは明示するようしています。

さいごに

自分のメモを振り返りながら書いてみました。

どちらかというと設計や準備よりの話が多くなってしまいましたが、結果的に他の業務でも応用が効く学びについて多く書けた気がしています。
特に「目的設定」をリサーチを通してたくさん経験できたことができたのは大きな財産だったな〜と思っています。いまだに要件定義は苦手ですが、昔に比べれば考えられるようにはなったかな…笑

同時に、調べるだけではなく、その先どうやったら関係者に活用してもらえるか、見てもらえるかを意識するようになってきたなあと思いました。リモート下だからこそ、意識しないと情報を知ってもらえないので。

note社で1人目のUXリサーチャーとして活動しているのですが、ここでも「みんなに活用してもらうには?」はずっと考えているので、ある意味一貫しているのかもしれません。

ただ、最適な手法は組織の状況や環境によって変わってくると変わってくると思いますし、僕のやり方も改善の余地はありまくりです。
一年後の自分がこの記事を読んだとき、「この時の自分はまだまだだな」と思えるようにこれからも頑張るぞい。





▼noteではデザイナーを募集しています。ご興味あればぜひ。


この記事が気に入ったらサポートをしてみませんか?