product-research

product-research

運用分野としてのプロダクト／ユーザーリサーチ：適切な手法を選び、規模を誠実に見積もり、調査結果をガバナンスの効いたインサイトへと統合します。基本ルールは、手法は目標に適合させること、そしてインサイトには独立した参加者間での再現性が必要であることです。引用が1つだけなら、それは逸話です。

目的

手法の厳密さと、信頼できるインサイトリポジトリを必要とするプロダクトリサーチャー、ResearchOps チーム、ディスカバリーを実施する PM 向けのスキルです。このスキルは、次の3つの判断を体系化します。

3つの決定論的なツール：

1. study_designer.py — （調査目標 × プロダクトの段階）から適切な手法を割り出し、手法に合った計画のひな形（目的、参加者の条件、ガイドの構成、成功基準）を出力します。実施中の A/B テストは product-team/experiment-designer に誘導します。
2. saturation_planner.py — 明示的な確信度ラベル付きで、手法に基づくサンプル数の目安を示します。Nielsen の問題発見（セグメントごとに5人）、Guest らのテーマ飽和（約12人）、評価的カバレッジを扱います。少数サンプルのユーザビリティテストから有病率を主張することはありません。
3. insight_synthesizer.py — タグ別にコード化された観察結果をクラスタリングし、参加者の実人数を数え、参加者間の再現性に基づいて順位付けします。ソース数が基準に満たない候補には逸話のフラグを付け、インサイトには決して昇格させません。

使用するタイミング

次の場合にこのスキルを使用します。

• 調査を計画していて、目標（生成的、評価的、検証的）に手法を適合させる必要がある場合。
• 根拠を示せるサンプル数／飽和の判断材料と、明記された確信度が必要な場合。
• 生のコード化済み観察結果があり、過大な主張をせずにインサイトへ統合する必要がある場合。
• リサーチリポジトリを構築または監査しており、インサイトと観察結果を厳密に区別する必要がある場合。

このスキルを使用してはいけない用途：ペルソナ／カスタマージャーニーマップの作成（product-team/ux-researcher-designer を使用）、ディスカバリースプリントの計画や機会の検証（product-team/product-discovery を使用）、実施中のプロダクト A/B テストの設計または分析（product-team/experiment-designer を使用）、市場規模の推定／アンケート調査（関連スキルの market-research を使用）。

ワークフロー

1. 調査の枠組みを定める — assets/research_plan_template.md に記入します（調査の質問、手法の根拠、参加者の条件、分析計画、リポジトリのタグ付け方式）。
2. 手法を選ぶ — study_designer.py --goal {discovery|evaluative|validation} --stage {concept|prototype|beta|live} --profile {b2b-saas|consumer-app|enterprise|marketplace|hardware|platform} を実行します。experiment-designer に誘導された場合は、その指示に従います。
3. 規模を見積もる — saturation_planner.py --method {usability|thematic|evaluative-coverage} --segments N を実行します。確信度ラベルと制限事項を記録します。
4. 統合する — 調査実施後、観察結果をコード化し、insight_synthesizer.py --input observations.json --min-sources 3 を実行します。ANECDOTE のフラグが付いたクラスタは、リリースする調査結果ではなく、さらに調べるべきシグナルとして扱います。
5. リポジトリに登録する — 統合時に、根拠と確信度を添えて、アトミックなスキーマに沿ってインサイトにタグを付けます。

スクリプト

スクリプト	目的	プロファイル
scripts/study_designer.py	（目標 × 段階）→ 手法 + 計画のひな形	b2b-saas、consumer-app、enterprise、marketplace、hardware、platform
scripts/saturation_planner.py	手法に基づくサンプル数の目安 + 確信度	該当なし（手法に基づく）
scripts/insight_synthesizer.py	観察結果をクラスタリングし、逸話にフラグを付ける	該当なし（根拠に基づく）

3つすべて：標準ライブラリのみ、--help、--sample、--output {human,json}。

オンボーディングとカスタマイズ

開始前にオンボーディング用の質問に一度だけ回答してください。デフォルト設定が保存され、このスキルのすべてのツールに事前設定されます。カスタマイズが重要です。回答によって、ツールの動作が実際に変わります（たとえば、インサイトに必要な情報源の閾値など）。

python3 scripts/onboard.py            # interactive (also: --defaults, --set key=value, --reset)
python3 scripts/onboard.py --show     # see the questions + current effective config

回答は ~/.config/research-ops/product-research.json（グローバル）または ./.research-ops/product-research.json（--scope project）に保存され、config_loader.py によって自動的に読み込まれます。デフォルトのプロダクトプロファイル、インサイトに必要な情報源の閾値（ある発見を単なる逸話ではなくインサイトとみなすために必要な、独立した参加者の人数）、デフォルトの飽和度の判定方法、およびハイステークスフラグを設定します。CLI フラグは常に保存済みの設定より優先され、RESEARCH_OPS_NO_CONFIG=1 を指定すると設定が無視されます。

4 つの質問： プロダクトプロファイル · インサイトに必要な情報源の閾値 · 飽和度の判定方法 · ハイステークスフラグ。

autoresearch で最適化（オプトイン）

このスキルには、engineering/autoresearch-agent への分離されたオプトイン方式のブリッジが含まれています。「合成を最適化して」または「ループを実行して」と依頼した場合に限り、autoresearch の実験によって、固定されたエビデンスセットのコーディング／クラスタリングを反復的に改善し、参加者間にまたがるパターンをさらに明らかにします。scripts/ar_evaluator.py は正解データに基づく評価ツールで、validated_insights: <int>（値が大きいほど良好）を出力します。最適化するのはコーディングであり、エビデンスを捏造することはありません。

/ar:setup --domain custom --name insight-synthesis \
  --target observations.json \
  --eval "python3 ar_evaluator.py --target observations.json" \
  --metric validated_insights --direction higher
/ar:loop custom/insight-synthesis

分離されています。必須の依存関係はなく、autoresearch は必要なときにのみ実行されます。ループが編集するのは observations.json であり、評価ツールは編集しません。

参考資料

• references/research_methods_canon.md — Portigal Interviewing Users、Christensen／Ulwick の JTBD、Rohrer の UX リサーチ手法の概観（NN/g）、Sauro と Lewis の Quantifying the User Experience、Goodman／Kuniavsky。
• references/sampling_and_saturation.md — Nielsen の「5 人のユーザーでテストする」、Guest、Bunce、Johnson の飽和度、5 人を超える人数に関する Faulkner の研究、Sauro のユーザビリティテストのサンプルサイズ、Braun と Clarke のテーマ分析。
• references/repository_and_synthesis.md — ResearchOps／アトミックリサーチ（Tomer Sharon の「Polaris」）、インサイトと観察事項を区別する規律、リポジトリのガバナンス、親和図法、民主化のためのガードレール。

前提

• 手法の選定には、目標を正直に言語化できることが前提です。目標が曖昧なら、まず徹底的に問い直してください（目標がすべてを左右します）。
• 飽和度に関する指針は手法に基づくものであり、検出力の計算に基づくものではありません。ユーザビリティテストで見つけるのは問題点であり、発生率ではありません。
• シンセサイザーが数えるのは、提示されたエビデンスです。コーディングの品質はその上流で決まります。タグが粗雑なら、クラスタも粗雑になります。
• インサイトの閾値（--min-sources）のデフォルトは 3 です。ハイステークスの調査や、対象者の特性にばらつきがある場合は、値を上げてください。

アンチパターン

• 目標と手法の不一致。 ユーザビリティテストでは未充足ニーズを発見できず、インタビューではタスクの成功率を測定できません。
• ユーザビリティの問題を割合で報告する。 少人数のテストで明らかになるのは問題点であり、母集団における発生率ではありません。
• 逸話をインサイトに格上げする。 参加者 1 人の発言は、深掘りするための手がかりであり、発見ではありません。
• 機能への反応を尋ねる形でインタビューの質問を組み立てる。 仮定に基づく意見ではなく、達成したい仕事と最近の実際の行動を掘り下げてください。
• リポジトリの分類方式を定めずに統合する。 統合時にタグ付けしないと、インサイトは見つからないまま埋もれていきます。

区別対象

関連項目	範囲	違い
product-team/ux-researcher-designer	デザイン成果物に結び付くペルソナ、カスタマージャーニーマップ、ユーザビリティのフレームワーク	こちらは成果物を作成しますが、これは手法とリポジトリの運用規律を扱います
product-team/product-discovery	機会の検証、ディスカバリースプリントの計画	こちらはディスカバリースプリントを計画しますが、これはリサーチを設計し、統合します
product-team/experiment-designer	実際のプロダクトにおける A/B テストの仮説とサンプルサイズ	こちらは実環境での実験を行いますが、これは定性的／評価的リサーチを行います
market-research（姉妹項目）	市場規模の推定、アンケート、セグメンテーション	こちらは市場を調査しますが、これはユーザーを調査します
interview-mapper（姉妹項目）	トランスクリプト単位のコーディング：逐語引用の検証、レンズごとのコーディング、複数回の実施をまたいだ合意形成	こちらはトランスクリプト自体をコーディングしますが、これはすでにコード化された観察結果をインサイトに統合します。生のトランスクリプトには決して触れません

簡単な例

python3 scripts/study_designer.py --sample
python3 scripts/saturation_planner.py --method thematic --segments 3
python3 scripts/insight_synthesizer.py --sample --min-sources 3

シンセサイザーのサンプルでは、「import-confusion」（独立した参加者 3 名）を正しく INSIGHT に昇格させ、「wants-slack」（参加者 1 名）には ANECDOTE のフラグを付けています。

深掘り質問集（Matt Pocock の厳密な質問規律）

/cs-grill-research-ops またはオーケストレーターが、1 問ずつ順に尋ねます。各質問には推奨回答と根拠となる文献を示します。質問をまとめて提示してはいけません。

1. 「この調査は問題を発見する生成的なものですか、それとも解決策を検証する評価的なものですか？」 推奨：まず種類を明確にします。手法は目的によって決まります。 根拠：Rohrer『When to Use Which User-Experience Research Methods』（NN/g）。

2. 「サンプルサイズと飽和の根拠は何ですか。また、どの程度の確信度ですか？」 推奨：手法に基づいて n を決め（セグメントごとのユーザビリティテストでは 5 名、テーマの飽和には約 12 名）、確信度を明記します。 根拠：Nielsen、Guest, Bunce & Johnson（2006）、Faulkner（2003）。

3. 「各インサイトを裏付ける独立した参加者は何名ですか。それとも、単一の情報源による逸話ですか？」 推奨：インサイトと呼ぶ前に、3 件以上の情報源での再現を必須とし、単独の事例にはフラグを付けます。 根拠：アトミックリサーチ／ResearchOps、Braun & Clarke のテーマ分析。

4. 「インタビュー／ユーザビリティテストのタスクは、成果（ジョブ）を軸に設定されていますか。それとも機能への反応を軸にしていますか？」 推奨：仮定に基づく意見ではなく、達成すべきジョブと最近の実際の行動を軸に設定します。 根拠：Christensen／Ulwick の Jobs-to-be-Done、Portigal『Interviewing Users』。

5. 「この内容はリポジトリのどこに保存し、再利用できるようにどのようにタグ付けしますか？」 推奨：後からではなく、統合時にアトミックスキーマに基づいてタグ付けします。 根拠：Tomer Sharon『Polaris』／ResearchOps のリポジトリ運用慣行。

深さ優先で進めます。3〜5 に進む前に 1〜2 を確定します。すべてに回答したら、study_designer.py → saturation_planner.py →（フィールドワーク後）insight_synthesizer.py を呼び出します。