リサーチバックログ（組織運営のアウトプット）｜現場のユーザーリサーチ全集

リサーチバックログとは、各部門からの調査依頼をリストアップし、個々の調査の企画要件を期待効果や実施難度の観点から吟味し、全体での重要度や時期感を判断する案件管理用のアウトプットです。（※開発業務の管理方法に倣っています）

主に調査を管轄する部門長＋リサーチャーで通期または半期の期首に取りまとめ、各部門のリサーチ要求の総量を把握しつつ、案件の優先度や実現性を吟味します。本表はその依頼や会議におけるコミュニケーションツールとして機能します。

この表はリサーチ業務のデータベースやフォルダ階層と帳尻合わせることで、リサーチ活動全体の項目や構造を規定していく役割を果たします。言い換えると、索引・看板として活用することができ、単なる依頼受付シートに留まりません。

リサーチバックログの構成要素は以下のようになります。

1.No.

・リスト上の通し番号
・起票受付後、一定期間を経てプロダクト/サービス/ブランド/部門などの単位で整列する

2.起票者

・調査案件の起票者名
・リーダー以上の管理職による記入とし、部課単位で要求するルールを設ける

3.要求内容

・調査の範囲や調査の対象箇所となる機能・施策・情報など
・企画や検証の論点や仮説なども箇条書きで記入してもらう

4.担当所感

・リサーチ責任者による所感
・調査時のポイントや討議、準備が必要な事項を知らせる

5.タイトル

・調査案件の名称
・調査対象の機能or施策or情報＋調査領域/調査手法で構成するとよい

＜記入例＞
・○○利用実態調査
・○○コンセプト受容性調査
・○○企画・機能ニーズ調査

6.案件概要

・調査案件の概要
（調査対象となるプロダクト/サービス/ビジネスに関する情報＋調査内容で構成する）

＜記入例＞
・○○に対するユーザー評価を検証するインタビュー調査
・○○に関する市場のニーズを把握するインタビュー調査

7.トピックス

・調査案件において目玉となる調査項目

8.調査手法

・調査案件で使用する調査手法

＜記入のヒント＞
※定性調査の場合は種類が多いため以下を目安に書き分ける
・ユーザビリティテスト
・ユースケース調査
・デプスインタビュー
・コンセプトテスト

9.調査対象者

・調査案件における調査対象者

10.アウトプット

・調査結果から得られる代表的な成果物
・アウトプットの記載があることで成果の形がわかりやすくなる

＜記入例＞
・カスタマージャーニーマップ
・ペルソナ
・バリュープロポジションキャンバス（VPC）
・ユーザーストーリーマッピング

11.関連KPI

・調査案件が伴奏する個々のプロジェクトに紐づくKPI
（全社KPI・部門KPI・業務KPIなど）

12.調査時期

・記入時点での実施予定時期
（時期に幅がある場合は四半期単位での記入にする）

13.調査主体

・調査業務を実行する担当部門
（発注する場合は調査会社名を、グループ企業に依頼する場合は子会社・親会社・関連会社の名称を記入する）

14.担当体制

・実行者や承認者、協力者の名前

「今はどの調査案件を行っているのか？今期はまだ新規の依頼ができるのか？」
⇒この質問に一枚で答えるためのアウトプット

①リサーチの要求に対して対応稼働が足りないケース

リサーチの対象となる物事は事業成長と共に増していきます。基本的に、展開領域に対応する機能・施策・情報の分だけ調査ニーズがあり、マルチカテゴリ・マルチブランド展開をしている事業者ではなおさら要求は細分化されていきます。

この状況に対して、リサーチ管掌部門では自部門の業務（デザイン部門ならデザイン領域）に集中できれば良いのですが、大抵はそうはいきません。決裁者や関係者からは、「ついでにこれも聞いておいて欲しい」と希望が届くものです。

もちろん担当者クラスでは対応キャパシティが足りません。また、そもそも同じ社内でもリサーチ業務レベルでは互いの調査計画は知らないものです。まず、どのような調査ニーズが組織内にあるのか要求の全量を把握する必要性があります。

②調査の報告・共有資料が各所に点在しているケース

リサーチの仕事は社内にも社外にも多くの関係者が登場します。それゆえに、調査の案件タイトル一つ取っても、「○○項目が出てくる調査」「○○さんの調査」「○○会社の調査」「○○時期の調査」など、微妙な呼び方の違いが発生してきます。

当然、調査のファイル名・フォルダ名も不統一だったり、管理しているデータベース構造も不規則になりがちです。下手をすると、リサーチ担当者自身の中でも一貫性を保てず、そうしたメンバーが組織に複数いる状況も珍しくありません。

組織内にリサーチの長期従事者がいれば良いのですが、担当者の異動や退職が起きると、途端に後追いが難しくなります。もともと取り扱うデータの情報量や秘匿性が高いことも相まって、時間が経つと過去調査実績はわかりづらくなります。

①優先度・難易度・コストの観点で吟味する

・大きすぎるサイズの要求は分割を試みる
・比較的近いテーマの要求は結合を試みる

②フォルダ・ファイルも同じ案件名称を使う

・誰が見ても判別しやすいタイトルを付ける

③質問事項やテスト項目をハイライトで記す

・依頼元の要求をヒアリングによって深める

④リクルーティング要件により具体性を出す

・調査対象者のグループや分析軸を記載する


⑤成果物を記載して業務の実施価値を伝える

・調査の実施価値を担保する（事業目標の達成だと大味になる）


⑥KPIを案件の重要度を測るモノサシにする

・インパクトがある活動かどうか裏取りする

①当期の計画案件全体の優先度判断用に

調査活動では、期首に立てた年間計画のほか、期中に発生する事案にも対応します。バックログでは依頼の全量がリストで可視化されているので、案件間の相対的な重要度や緊急度に照らして対応範囲や対応時期を討議することができます。

個々の案件についても、いきなり内容や時期を詰めるのではなく、リサーチ担当者が企画の骨子をリファインメント（精査）した状態で話し合うので、具体的な実施や成果のポイントを参照しながら双方の関わり方を協議することが可能です。

依頼元の部門でも、軽くで構わない時（例：アイデア探索・最終テスト・実査のみ）、しっかりやりたい時（例：重要決裁に耐え得るデータが欲しい・特定の時期に間に合わせたい）など重みづけが異なるものなので、話し合いに便利です。

②調査データの索引や表記規則参照用に

リサーチバックログは、そのまま事業年度ごとの調査の索引として機能します。よく実施後の課題となるように、フォルダタイトルと調査時期だけで案件を探し当てることがなく、どの案件を誰に問合せたらよいかもリスト内容から明快です。

本表では起票時点から案件名称・案件概要を整理しているので、バラバラになりがちな表記もこのリストを参照することで統一できます。個別案件ごとの管理ではなく、年次規模で組織全体の案件を管理しているからこそ最適化できるのです。