新規プロダクトの開発や、既存機能のカイゼン、さまざまなシーンで実施されるユーザーインタビュー。

ユーザーインタビューの実施方法やTipsなど、「実施前」「実施中（実査）」のフェーズは多く語られる一方で、「その後」については、重要なのにもかかわらずほとんど語られません。

実はユーザーインタビューの「実施後」をどうするかによって、チームの納得度や、意思決定の質、スピードは大幅に変わります。

本ドキュメントでは、ユーザーインタビューの「その後」に着目し、十分にデータを活用するための「データのまとめ方」をご紹介します。

ユーザーインタビューの「実施後」が重要な理由

ユーザーインタビューは、課題の特定や、状況の把握、ソリューションの見極めにおいて非常に役立つアプローチの1つです。

そして、ユーザーインタビュー実施後の動き方によって、得られるものが大きく変わります。

• チームの納得度

• 意思決定の質

• 意思決定スピード

• 今後のリサーチコスト

実施後のフェーズがうまくいかない場合は、せっかくインタビューをしたのに、チームや事業にポジティブな影響を与えられないことも多くあります。

• 低い納得度 … チームで共通認識がつくれず、特定の人のみが解像度が高い状態に陥る

• 筋の悪い意思決定 … インタビュー結果を都合よく解釈してしまい、間違った意思決定を生む

• 手戻りの多さ … 共有したつもりができておらず、開発やデザインがスムーズに進まない

• 似たインタビューの繰り返し … データが参照されず、車輪の再発明のように似たインタビューが繰り返される

「せっかくユーザーインタビューしたのに、なぜか認識が揃わない」「自分だけ解像度が高まったが、チームで同じユーザー像を見られていない」などの状況が発生する場合は、ほとんどの場合において実施後のフェーズがうまくいっていないと考えられます。

ユーザーインタビューにおける最も大きな失敗の1つは、インタビューの実施自体を目的化してしまい、実施後のプロセスに力を入れないこととも言っていいほど、実施後は非常に重要なプロセスなのです。

議事録のままでは不十分な理由

ユーザーインタビューの実施後、よくある動き方として、インタビューの議事録（ローデータ）を、そのまま共有・保管することがあります。

このような議事録ベースの共有・データ管理には、（簡単さの一方で）いくつも問題があります。

1. 解釈のブレやすさ

2. 賞味期限の短さ

解釈のブレやすさ

まず、議事録のまま放置しておくと、人によってバラバラな解釈が生まれるリスクが高くなります。

既存のユーザーがほとんどおらず、1人や2人を対象としたインタビューで、チームの全員が対象ユーザーのことを知っている場合ならあまり問題ないかもしれません。

しかし、サービスが成長しユーザー/顧客が増えてきた場合や、インタビュー対象者が数人〜十数人になる場合、もしくは対象者についての理解がチーム内でそれぞれ違う状態では、ますます解釈がバラバラになる可能性が高くなります。

なぜなら、インタビューの議事録自体が、さまざまな話題を含んでおり、共通の認識をつくるには、複雑な文脈であることが多いからです。

• この発言は、こういう意図で...

• この行動は、このような背景があって...

など、1つの議事録の中には、複数の発言や行動が絡み合っているため、認識のズレ（エラー）が起きやすいのです。

賞味期限の短さ

議事録のまま放置しておくことは、もう1つのデメリットがあります。それが「賞味期限の短さ」です。

複雑な文脈を抱えた議事録をそのまま残しておくと、後から見返す際やその場に参加していなかった人が参照したい場合に、非常に扱いづらいものになってしまいます。

• どの議事録を見れば、知りたいことが分かるのか不明

• 見返すのに時間がかかる（録画の共有等も同じく）

• サマリーはあるものの、欲しい情報でなかったり、情報が不十分で理解しづらい

• 結果として「議事録は溜まっているものの、誰も見ていない」状態に

• 誰も見ないことで、似たインタビューが別のタイミングで行われ非効率に

議事録のまま放置しておくことで、その場限りのアウトプットになってしまい、組織に残る資産（= 誰でも取り出せる状態）にならないのです。

ちょうど良い情報のまとめ方とは

では、実施後の最適なアクションとはどのようなものなのでしょうか？

チームの認識を揃え、意思決定の質・スピードを高めるためには、複雑な議事録から「ちょうど良い単位」にまとめ直すことが必要です。

この「ちょうど良さ」とは、2つに分けられます。

1. 特定の文脈に切り出した単位 = インサイト単位

2. 複数の文脈を組み合わせた単位 = インサイトの集合単位

インサイト単位でまとめる

まずはシンプルに、複雑な文脈を切り分けることで理解しやすい情報にまとめることができます（脱文脈化などとも呼ばれます）。

切り分ける際は、以下のようなポイントを押さえることが重要です。

• ユーザー視点のファクトであること

• 議事録に記載されていることを、他の人にも伝わりやすいように適度に抽象化すること

• 抽象化しすぎず、他の人が該当の場面や情景をイメージできるようにすること

このように、特定の文脈における観察結果ごとに切り分けてまとめる、インサイト単位のまとめ方は、チームで最大限インタビュー結果を活用するための、最も基本的な単位と言えます。

また、インサイトベースで蓄積する際のポイントとして、見返しやすく、伝わりやすい状態にしておくことも重要です。

1. インサイトの内容（例 : 〇〇したい）

2. 属性や環境、背景などの周辺情報（例 : これまでのアプリ利用経験）

3. ユーザーインタビューの議事録やお客さまとの会話などの元データ

これら3つが揃うことで、誰が見ても解釈がブレないようなデータ管理を実現することができます。

インサイトの集合でまとめる

さらに、インサイト単位でまとめた上で、さらにプロジェクトや検証したい仮説に合わせて、インサイトを特定の切り口でまとめるアプローチもあります。

特定の文脈に切り出したインサイトを、さらに再編集するようなこのプロセスは、たとえばジャーニーマップやペルソナ、4象限のマップなど、さまざまなフォーマットで表されます。

最適なフォーマットは仮説や施策によってもさまざまですが、もっとも重要なことは妄想やバイアスのかかった成果物をつくらないことです。

ジャーニーマップやペルソナなどのフォーマットは、広く一般的になってきたこともあり、さまざまなツールで表現しやすくなりました。

しかし、想像に頼ったアウトプットになると、信ぴょう性が低いまま偶像崇拝な状態に陥ることも少なくありません。

あくまで、事実 / エビデンスにもとづいた文脈の再編集の結果として、ペルソナやジャーニーマップが存在することに注意しましょう。

さらに詳しい分析プロセスについて知りたい方は、こちらのドキュメントもぜひご覧ください。

優れたデータ管理は、スピードと質の良いとこ取りを実現する

ここまで、ユーザーインタビュー実施後の必要性と、最適なアクションについてご紹介しました。

議事録ベースでまとめることと、特定の文脈ごと（インサイト単位）でまとめる違いを比較すると以下のようになります。

議事録のまま保存しておいても、ほとんどの人にとっては「単によく分からない情報が置かれているだけ」となり、見返されない状態となってしまいます。

ローデータのまま放置することは、まるで絡まった糸のような状態です。

からまった糸を、からまったままにしておいては、価値あるものだと認識できません。

切り離して（分析して）、整理する（データ管理する）ステップを挟んでこそ、価値ある情報へと進化します。この一連の流れがインサイトマネジメントとなります。

うまく「インサイトの引き出し」として整理することができれば、インタビューの目的となる施策はもちろん、その他の施策やプロジェクトにも大きな好影響を与えることができます。

得られた調査結果を、正しく整理・保管することで、チーム全員が同じ方向を向き、ズレを減らせるようになります。

結果として、意思決定は素早くなることはもちろん、各施策の打率も向上したり、チームのエンゲージメントが高くなることも期待できます。

実際に急成長スタートアップカミナシでは、定性データ基盤の構築によって、事業が伸びています : 

参考記事 : 定性データを“主観で終わらせない”仕組みをどう作ったか？ (migi)

意思決定のスピードと質を両立するためには、優れたリサーチデータ管理が鍵だと言えるでしょう。

Centouでは、ユーザーインタビューをはじめとした、定性データを管理するための基盤を提供しています。定性データの管理や基盤づくりをご検討中の方は、ぜひこちらのページからお気軽にご相談ください。