discovery-research-synthesis

ディスカバリーリサーチの統合

リサーチの成果物を意思決定につなげる、シニア PM の実践ガイドです。顧客インタビュー、ユーザーリサーチのメモ、サポートチケットのレビュー、営業電話の記録、アンケートデータ、アプリ内フィードバックをすべて統合し、本来それらが導くべきプロダクトの方向性を定めます。

ディスカバリーリサーチのほとんどは、意思決定を生み出しません。チームがインタビューを実施し、記録が積み上がり、リサーチャーが生の成果物をプロダクトチームに渡す（データの垂れ流し）か、見栄えのよい報告用スライドを作成します（洞察を装った演出）。そのスライドは30分のレビュー会議で取り上げられた後、二度と参照されません。2か月後、チームはリサーチが導くはずだったのと同じプロダクト上の意思決定を、リサーチによって置き換えられるはずだったのと同じ勘頼みの材料を使って行っています。

肝心なのは統合です。リサーチが真価を発揮するのは統合の段階です。記録がタグ付けされた観察結果になり、観察結果がパターンにまとまり、パターンに名前が付き、名前の付いたパターンからプロダクトへの示唆が浮かび上がり、その示唆が具体的な意思決定を導きます。この流れがなければ、リサーチはパフォーマンスアートです。

このスキルでは、単発のディスカバリーリサーチプロジェクトを扱います。12週間の顧客開発スプリント、オンボーディングの再設計に向けた営業電話のレビュー、ロードマップの四半期計画に役立てるサポートチケットの監査などが該当します。継続的なフィードバックの流れを扱う user-feedback-aggregation とは異なります。また、統合の際によく使われるものの、対象範囲がより狭い特定のフレーミング手法である jtbd-framing とも異なります。

このスキルの語り手は、統合をうまく実践し、その過程で多くのチームが失敗する様子も見てきたシニア PM またはスタッフ・プロダクトリサーチャーです。見栄えのよさが単なる演出になる境界や、パターンの命名がパターンの捏造に陥る境界について、率直に語ります。

このスキルを使う場面：最近実施した一連の顧客インタビューを統合するとき、過去のリサーチがなぜプロダクトの意思決定につながらなかったのかを監査するとき、数週間にわたるディスカバリースプリントの成果物を設計するとき、またはチームに不足している統合の規律を確立するときです。

---

このスキルの目的

このスキルでは、リサーチから意思決定に至るまでの統合を扱います。PM スキルとの違いは次のとおりです。

• **discovery-research-synthesis（このスキル）**は、単発のリサーチ統合です。ひとまとまりの成果物を、ひとまとまりの意思決定につなげます。
• user-feedback-aggregation は、サポート、NPS、アプリ内、営業など、常時稼働するチャネルからの継続的なフィードバックを、継続的に統合します。
• jtbd-framing は、統合の際によく使われるフレーミング手法です。このスキルのほうが対象範囲は広いです。
• pm-spec-writing は後続の工程です。仕様書では、統合された洞察をインプットとして使用します。
• roadmap-planning は後続の工程です。ロードマップでは、統合された優先事項をインプットとして使用します。
• experiment-design は、定性的な統合の後によく行われる、定量的な検証の規律です。

対象読者：シニア PM、プロダクトディレクター、社内のプロダクトチーム、クライアント向けのディスカバリー業務を行うエージェンシー、プロダクトチームに成果を引き継ぐリサーチャーです。

対象外：リサーチの実施そのもの（インタビューの設計、参加者の募集、進行）、どのリサーチを依頼するかを決める、より広範なディスカバリー戦略、または user-feedback-aggregation が扱う長期的なフィードバックチャネルです。

---

データの羅列 vs インサイトの演出 vs 実行につながる統合

中核となる枠組みです。2つの失敗パターンと、それを防ぐための規律を示します。

データの羅列。 調査成果物をそのままプロダクトチームに渡すことです。「インタビューの記録が47件と、タグ付けしたスプレッドシートがあります。あとは考えてください」。統合も、シグナルの抽出も、示唆の導出もありません。プロダクトチームが自ら統合するか（多くの場合、質が低く、数か月後になります）、あるいはそれを省略します（最もよくある結果です）。成果：成果物は生み出したものの、インサイトにはつながらない調査投資です。

インサイトの演出。 インサイトを装った、過剰に磨き上げられた統合です。見栄えのよい引用文の羅列、作り込まれたペルソナ、ブランド化された報告用スライド。しかし、意思決定を促す結論はありません。30分のレビューで取り上げられた後、二度と参照されない調査資料です。プロダクト側には役立たず、経営層に向けたパフォーマンスに終始する統合です。代償：実際の調査予算がスライド資料に変わり、組織は調査を「実施した」ものの、調査を実践していません。

実行につながる統合。 意思決定を促す統合です。各パターンに「つまり、何を意味するのか」を添え、各発見をプロダクトへの示唆につなげます。そのドキュメントは、ロードマップの議論、仕様書の草案、優先順位付けの議論で参照されます。統合は簡潔で、明確な見解があり、判断の拠り所となります。6か月後、チームメンバーは、リリースされたものや見送られたものを形作ったパターンを引用できます。

判断基準です。統合を公開して3か月後、チームメンバーは、その統合がどの意思決定に役立ったかを挙げられるでしょうか。挙げられるなら、実行につながる統合です。資料を覚えていても、どの意思決定に役立ったかを挙げられないなら、インサイトの演出です。統合が行われず、誰も何も覚えていないなら、データの羅列です。

---

ディスカバリー調査の種類

よくある5種類の調査です。それぞれ、必要な成果物と統合の方法が異なります。

顧客インタビュー。 30〜90分の、構造化または半構造化された対話です。記録、モデレーターのメモ、録音で構成されます。質的データとして最も品質が高く、収集コストは最も高い一方、うまく実施すれば統合の価値も最も高い調査です。一般的な調査サイクルでの件数：インタビュー8〜15件です。

サポートチケットのレビュー。 最近のサポートチケットを監査し、パターンを探します。個々の成果物の情報量はインタビューより少ないものの、件数が多くなります。また、ユーザーが実際に直面した摩擦を明らかにします（インタビューで語られる内容だけではありません）。一般的な監査での件数：チケット100〜500件です。

営業通話の分析。 最近の営業通話の録音や記録をレビューします。反論、価格に関する会話のパターン、競合への言及、マーケティング上のポジショニングと営業が実際に強調する内容とのギャップを明らかにします。一般的な監査での件数：通話15〜30件です。

アンケートデータ。 任意の自由記述コメントを含む定量的な回答です。質的なパターンを大規模に検証するのに最適ですが、探索の主な手段としては不向きです（アンケートからわかるのはユーザーが何を言うかであり、何をするかではありません）。一般的な調査での回答数：100〜2,000件です。

アプリ内フィードバック。 プロダクト内のチャネルを通じてユーザーから寄せられるフィードバックです。件数は多く、品質にはばらつきがあります。手間のかからない投稿を多数集めたとき、そのパターンの中にシグナルが現れます。一般的な実施形態：継続的に収集し、定期的な監査で統合します。

異なる種類の調査を組み合わせることもできます。ディスカバリーサイクルでは、インタビュー（深さ）、サポートチケットのレビュー（量）、アンケートデータ（大規模な検証）を組み合わせることがよくあります。統合では、これらを組み合わせます。

詳細は references/research-types-and-when-each-fits.md を参照してください。

---

統合の手順

生の資料から意思決定までの6つの段階です。段階を飛ばすと、統合は失敗します。

1. 文字起こしして準備する。 資料を統合可能な形式に変換します。インタビューの録音は文字起こしに、営業電話は要約に、サポートチケットはタグ付きデータセットにします。準備作業は地味ですが、ここを省くチームは後続の段階に進めません。

2. 資料単位でタグ付けする。 それぞれの文字起こしやチケットを読み、表面化したトピック、問題、引用にタグを付けます。初回のタグ付けでは、内容を記述します。この人は何を言ったのか、どんな問題に直面したのか、何をしようとしていたのか。タグが整理されていなくても問題ありません。

3. 資料を横断してクラスタリングする。 タグをテーマごとにグループ化します。複数のユーザーが同じ不満に言及し、複数のチケットが同じワークフローに触れ、複数のインタビューで同じ苦労する場面が話題に上がります。クラスタからパターンが見えてきます。

4. パターンに名前を付ける。 各クラスタを、名前の付いたパターンにします。命名こそが作業の要です。名前の付け方が悪いパターンは統合の中に埋もれますが、うまく名付けられたパターンはチームが参照する枠組みになります。「オンボーディング設定の不満」はパターン名ですが、「ユーザーが苦労した」はそうではありません。

5. プロダクトへの示唆を導き出す。 各パターンはプロダクトにどのような示唆を与えるでしょうか。示唆は、観察から意思決定への架け橋です。示唆のないパターンは発見事項ですが、示唆のあるパターンは実行可能なインプットです。

6. それが何を意味するのかを明確にする。 各示唆が、具体的にどの意思決定に役立つのかを明確にします。「Q2にオンボーディングの再設計を優先すべきか？」これが明確になって初めて、統合は意思決定に使えるものになります。

この手順は必ず守る必要があります。タグ付けを省いてパターンの命名に飛びつくチームは、存在しないパターンを見いだしてしまいます。示唆を省くチームは、プロダクトの方向性を伴わない発見事項を生み出します。それが何を意味するのかを省くチームが作るのは、統合ではなくドキュメントです。

詳細は references/synthesis-sequence-walkthrough.md を参照してください。

---

タグ付けとクラスタリングの規律

統合の手順の中盤には、特有の失敗要因があります。

まず資料単位でタグ付けし、分類体系を事前に設計しないでください。 タグは資料から生まれます。あらかじめタグの分類体系（「ユーザビリティ、パフォーマンス、価格、サポートのタグを付ける」など）を用意しているチームは、データに合わないカテゴリに資料を無理に当てはめ、分類体系では想定していなかったパターンを見逃してしまいます。

タグは増えるままにし、後からまとめます。 最初のタグ付けで、1つのまとまりに80〜150個のタグができることがあります。それで問題ありません。クラスタリングの段階でタグを整理します。早い段階で統合すると（「オンボーディングのタグが4つあるので、まとめましょう」）、後になって重要だとわかる違いが失われます。

タグの重なりではなく、パターンを基準にクラスタリングします。 多くの資料で同時に出現する2つのタグが、同じパターンを示すとは限りません。根底にある観察を基準にクラスタリングします。これは同じ苦労する場面なのか、それともタグの定義が曖昧だったために同じタグが付いただけなのかを見極めてください。

クラスタリングの後に名前を付け、前には付けません。 クラスタ名は仮説ではなく、データから導き出します。あらかじめクラスタに名前を付け、データをそこに当てはめるチームは、仮説を裏付けるだけになります。一方、データからクラスタ名を付けるチームは、新たな発見につながります。

異論や矛盾には明示的にタグを付けます。 支配的なパターンに反するユーザーもいます。そうした矛盾は重要なシグナルです。異なるニーズを持つサブセグメントが存在するか、あるいは件数から想像するほどパターンが強くない可能性があります。統合で扱えるよう、異論にもタグを付けてください。

詳細は references/tagging-and-clustering-discipline.md を参照してください。

---

パターンの命名

統合とドキュメント作成を分ける作業です。

パターン名はカテゴリーラベルではありません。「オンボーディング」はカテゴリーです。「3つ目の設定手順で手元にないデータが必要になるため、成功状態に到達する前にユーザーが設定を途中でやめてしまう」はパターンです。パターン名は、データが明らかにする具体的な行動を示します。

**名前から示唆が読み取れるようにします。**パターン名だけを見た読者が、プロダクトへの示唆を推測できるようにします。名前が抽象的すぎると、読者は示唆にたどり着けません。具体的すぎると、統合が細かな観察結果の羅列になってしまいます。

**カテゴリーの肥大化を避けます。**名前の付いたパターンが30個ある統合は、通常、クラスタリングが不十分です。その多くは、より少数の根本的なパターンのバリエーションです。名前の付いたパターンが4個の統合が適切なことが多く、6〜8個が一般的です。12個を超える場合は、通常、カテゴリーが肥大化しています。

当たり前のことに名前を付けるのは避けます。「ユーザーは高速なパフォーマンスを求めている」はパターンではなく、陳腐な真理です。パターンとは、プロダクトチームがすでに知っていたわけではない、具体的な観察結果です。調査前から誰もが言えたような内容に見えるなら、それはパターンではありません。

確信を持って命名します。「ユーザーはときどき、もしかすると苦労しているように見える……」のように曖昧なパターン名は、データが示したことを研究者が断定できなかったと伝えてしまいます。多少大げさでも、確信を持って名付けられたパターンのほうが役に立ちます。異論を促し、意思決定につながるためです。

詳細はreferences/pattern-naming-patterns.mdをご覧ください。

---

パターンからプロダクトへの示唆へ

観察から意思決定へつなぐ橋渡しです。

**パターンから示唆への変換は、ユーザーの発言ではなく、書き手の分析作業です。**ユーザーはプロダクトへの示唆を述べるのではなく、自分の体験を説明します。統合を行うPMがパターンを解釈し、示唆を提案します。この解釈こそが、単なる書き起こしを超える価値を統合にもたらす部分です。

**各パターンから複数の示唆が導かれることがあります。**オンボーディングの摩擦に関するパターンからは、設定フローの再設計、デフォルトデータの事前入力、段階的なオンボーディングなどが示唆されるかもしれません。統合では選択肢を明らかにし、優先順位付けの判断でそのうちの1つを選びます。

示唆は反証可能であるべきです。「オンボーディングを改善すべき」のような曖昧な示唆は、実行に移せません。「ユーザーが最初の成功状態に到達した後まで、3つ目の設定手順を延期する段階的なオンボーディング」のような具体的な示唆なら実行可能です。具体的な示唆は、議論し、範囲を定め、優先順位を付けることができます。

**示唆にはコストへの言及が必要です。**パターンは解決策を示しますが、解決策にはプロダクトの対応能力が必要です。30件の変更を示唆しながら、すべてを実現するのは不可能だと認めない統合は、統合ではなく、願望のリストです。

**行動しないことが示唆されるパターンもあります。**パターンによって、チームが対処すべきではない摩擦が明らかになることもあります。影響を受けるユーザーが少なすぎる、セグメントとのミスマッチを示している、対処すると他の優先事項を損なう、といった場合です。行動しないという示唆に名前を付けることは、誠実な統合です。

詳細はreferences/from-pattern-to-product-implication.mdをご覧ください。

---

プレゼン映えではなく、意思決定に役立つ文章を書く

統合結果は、プレゼンテーションではなく、意思決定に役立つよう最適化します。

スライドではなく文書にします。 スライド形式は統合結果の提示に適していません。スライドには十分な論旨を盛り込めず、読者は後からスライドを参照できず、デッキはアイコンや箇条書きばかりになってしまいます。短い文書（4～12ページ）のほうが、60枚のデッキより実用的な統合結果を多く伝えられます。

パターンと示唆を先に示し、根拠は付録に回します。 意思決定の材料を探している読者が最初に知りたいのは、パターンと示唆です。根拠（引用、チケットの抜粋、データ表）はパターンを裏付けるものですが、先頭に置くものではありません。引用を大量に並べて始まるデッキは、読者のニーズを取り違えています。

パターンごとにセクションを設けます。 各パターンについて、パターン名、根拠の要約（2～3文と付録の詳細な根拠へのリンク）、示唆、意思決定に向けた要点を含む短いセクションを作成します。

明確な見解を示します。 すべてのパターンに対して歯切れの悪い言い方をする統合結果は、責任を避ける研究者のように読めてしまいます。明確な立場を示す統合結果は、異議を促し、意思決定につながります。統合を行う PM は推奨事項を提示しています。読者は異議を唱えられますが、意見の相違こそが重要です。

意思決定に向けた提言のセクションを設けます。 この統合結果は、チームに何をするよう勧めていますか？ 優先順位をどこで変更すべきですか？ どのロードマップ項目を裏付け、どの項目に異議を唱えていますか？ 意思決定に向けた提言のセクションこそ、この統合結果が作成される理由です。

詳細は references/writing-for-decisions-not-decks.md を参照してください。

---

統合結果のレビューと検証のサイクル

意思決定に活用する前に、統合結果をどのように厳しく検証するかを説明します。

可能であれば、調査参加者を交えた内部レビューを行います。 調査参加者の一部に統合結果を見てもらいます。パターンに、自分たちの経験や状況が反映されていると感じますか？ 認識のずれは、統合結果が実際には存在しないパターンを作り出したり、データで裏付けられていない解釈を投影したりした兆候です。

関連チームによるレビューを行います。 プロダクト、エンジニアリング、サポート、営業の各チームに統合結果を見てもらいます。パターンは、それぞれの領域で見られる状況と一致していますか？ 関連チームは、調査チームが見落とした統合上の誤りに気づけます。

可能であれば、定量的に検証します。 定性的な統合で見いだしたパターンは、分析、アンケート、アプリ内データを使って大規模に検証できる場合がよくあります。パターンが X を示しているなら、その発生頻度や深刻度は、パターンが示唆するものとデータ上でも一致していますか？ 定量的な手法については、experiment-design と product-analytics-setup を参照してください。

「統合結果に異議を唱える」セッションを実施します。 関連チームが、統合結果で見落としたパターン、誇張した示唆、強引に進めようとしている意思決定を見つけるための、専用のセッションです。建設的な意見の相違は、統合結果を強化します。

公開前に反復して改善します。 レビューのサイクルを踏まえて、統合結果を改訂します。初稿のまま公開される統合結果には、認識されていない盲点が残っていることがよくあります。

詳細は references/synthesis-review-and-validation.md を参照してください。

---

追加のデータを収集するために立ち止まるタイミング

統合によって、調査で十分なデータを収集できていなかったことが明らかになる場合があります。

パターンの根拠が薄い。 2〜3件の成果物にパターンが見られるものの、立場を定めるには5〜8件必要です。そのパターンを追加データが得られるまで暫定的なものとして示すか、統合をいったん中断して調査を追加します。

セグメントの代表性が不足している。 調査であるユーザーセグメントに偏りがあり、意思決定に関わる別のセグメントが十分に含まれていません。代表性のあるセグメントで見られたパターンが、代表性の不足しているセグメントにも当てはまるとは限りません。

相反するクラスター。 2つのクラスターが正反対の方向を示しており、データから矛盾を解消できません。多くの場合、調査で十分に検証されなかったサブセグメントの違いを示しています。

意思決定の期限が迫っている。 統合でデータの不足が明らかになっても、追加調査を行う前に意思決定を進める必要があります。誠実な対応は、統合でデータの不足を明示し、それを認めたうえで推奨事項を示し、妥当性の検証や見直しにつながる追加調査を計画することです。

「これで十分だ」という落とし穴。 調査に投資してきたチームは、統合で不足が明らかになっていても、データは十分だと宣言したくなることがあります。不都合な場合でも不足を明示することが重要です。

詳細はreferences/when-to-gather-more-data.mdをご覧ください。

---

よくある失敗パターン

手短にまとめています。診断についてはreferences/common-discovery-synthesis-failures.mdをご覧ください。

• 「調査はしたものの、そこから何も決定しませんでした。」データの羅列、またはインサイトの演出です。統合の手順を省略したか、調査結果の段階で止めています。
• 「統合資料は丁寧にレビューされましたが、その後二度と参照されませんでした。」インサイトの演出です。成果物は実務を支えるものではなく、見せかけのものになっていました。
• 「名前を付けたパターンが30個もあるのに、優先順位が明確ではありません。」カテゴリの肥大化やクラスター化の不足です。対処法は、根底にある4〜8個のパターンに再分類することです。
• 「どのパターンも、すでに知っていたことのように読めます。」統合でパターンではなく、ありきたりな事実を示していました。実際に意外だったことをデータから見直してください。
• 「パターン同士が矛盾していて、整合性を取れません。」多くの場合、セグメントの不適合です。矛盾が、ニーズの異なるサブセグメントを示していないか検討してください。
• 「調査参加者が、統合の内容に自分たちが反映されていると感じませんでした。」統合でパターンを捏造したか、データにない解釈を投影していました。証拠をより丁寧に追跡するところからやり直してください。
• 「統合は詳細ですが、チームは何をすべきか判断できません。」示唆が欠けているか曖昧です。対処法は、各パターンに具体的で反証可能な示唆を付けることです。
• 「すべてのパターンに留保を付けたため、統合が歯切れの悪い内容になりました。」留保の重ねすぎです。統合で立場を明確にすることを避けていました。確信を持って書き直してください。
• 「引用を並べたページは見栄えがしましたが、資料は60枚になりました。」インサイトの演出です。対処法は、引用を付録にまとめた8ページの文書にすることです。
• 「統合ではプロダクト変更を20件推奨しましたが、実施できたのは1件でした。」願望リストのような統合で、コストを考慮していませんでした。対処法は、統合の中で優先順位を付けることです。
• 「関連チームがパターンに異議を唱えましたが、話し合いませんでした。」レビューのプロセスが省略されていました。対処法は、公開前に関連チームのレビューを必須にすることです。

---

フレームワーク：発見段階の統合に関する12の検討事項

統合結果を設計または監査する際は、次の12項目を確認します。

1. データの羅列や洞察を装ったものではなく、行動につながる統合です。 意思決定を促す統合にします。
2. 調査の種類を質問に合わせます。 インタビュー、サポート対応、営業電話、アンケート、アプリ内調査を意図的に組み合わせます。
3. 統合の手順は、文字起こし、タグ付け、クラスタリング、命名、示唆の導出、「それで何をするのか」の明確化です。 どの段階も省略しません。
4. タグは成果物から生まれるものであり、分類体系を事前に設計しません。
5. タグの増加は許容し、クラスタリングによってまとめます。
6. パターンには確信を持って名前を付けます。単なるカテゴリや陳腐な一般論にはしません。
7. 各パターンから、具体的で反証可能なプロダクト上の示唆を導きます。
8. 各示唆には、実際の意思決定に結び付く「それで何をするのか」を示します。
9. 成果物はスライド資料ではなく、文書です。 パターンを先に示し、エビデンスは付録にまとめます。
10. 統合には明確な見解を持たせます。 歯切れの悪い表現には印を付け、確信度を示します。
11. 公開前にレビューを行います。 参加者、隣接チーム、可能であれば定量的な検証も含めます。
12. データの不足は隠さず、明示します。 調査で裏付けられなかった立場があれば、統合結果にそう記載します。

このフレームワークの成果物は、チームが行動に移せる統合です。簡潔で、明確な見解があり、エビデンスに基づき、意思決定を促し、異論や批判を受け止められるものです。

---

参考ファイル

• references/research-types-and-when-each-fits.md - 5種類の調査と、それぞれが統合に与える影響。発見サイクルにおける調査の種類の組み合わせパターン。
• references/synthesis-sequence-walkthrough.md - 6段階の手順と具体例。各段階の成果物、よくある省略による失敗、各段階にかける時間。
• references/tagging-and-clustering-discipline.md - 成果物単位でタグを付ける規律、タグの増加を許容すること、重複ではなくパターンに基づいてクラスタリングすること、クラスタリング後に命名すること、異論をタグ付けすること。
• references/pattern-naming-patterns.md - 効果的なパターン名と、そうでないパターン名。カテゴリの肥大化を避けること、確信を持って命名すること、示唆の明確さを確かめるテスト。
• references/from-pattern-to-product-implication.md - パターンから示唆への橋渡し。反証可能性、複数の示唆をもたらすパターン、コストの明示、行動しない場合の示唆。
• references/writing-for-decisions-not-decks.md - スライド資料ではなく文書にすること、パターンを先に示すこと、エビデンスを付録にまとめること、明確な見解を示す語調、意思決定へのインプットとなるセクション。
• references/synthesis-review-and-validation.md - 参加者レビュー、隣接チームのレビュー、定量的な検証、統合結果に異議を唱えるセッション、公開前の反復。
• references/when-to-gather-more-data.md - パターンの裏付けが薄い場合、セグメントの代表性が不足している場合、クラスタ間に矛盾がある場合、意思決定までの時間が限られている場合、「もう十分だ」という落とし穴。
• references/common-discovery-synthesis-failures.md - 11以上のよくある失敗パターンと、その診断および改善策。

---

まとめ：リサーチの価値は統合で決まります

探索的リサーチは、プロダクトチームが依頼する活動の中でも、特にコストのかかるものです。そのコストの大部分は表面化しません。顧客の時間、リサーチャーの時間、探索サイクルそのものに伴う機会費用、参加者の募集やスケジュール調整にかかる管理コストです。こうしたコストの大半は、統合が始まる前に発生します。

リサーチへの投資から成果を得るチームは、統合を重視します。プロセスを最初から最後まで実行し、パターンを確信を持って名付け、検証可能な示唆を導き出し、具体的な意思決定につなげ、チームが何カ月にもわたって参照する、判断の拠り所となるドキュメントにまとめます。成果を得られないチームが生み出すのは、データの羅列や洞察の演出です。リサーチは、これから行う仕事へのインプットではなく、行った仕事の記録になってしまいます。

統合が完了したかどうか判断に迷ったら、次の点を確認してください。パターンを確信を持って名付けているか。プロダクトへの示唆にまで掘り下げているか。その示唆を具体的な意思決定につなげているか。参加者や関連チームによるレビューを受けているか。データの不足を率直に明示しているか。すべてに「はい」と答えられるなら、その統合は実質を伴っています。どれか一つでも「いいえ」なら、その不足こそが、リサーチへの投資が意思決定につながらない原因になります。