discovery-process

discovery-processの概要

discovery-process は、あいまいなプロダクト課題を、フレーミング、インタビュー、統合、実験を通じて検証済みの方向性へと落とし込むための、構造化されたワークフローです。一般的なブレスト用プロンプト以上のものが必要で、UX Research とプロダクト判断のために再現性のある discovery-process がほしいプロダクトマネージャー、UXリサーチャー、クロスファンクショナルチームに最適です。

このスキルの用途

discovery-process は、問題が本当に存在するのか、それがなぜ起きているのか、そして実装前に次に何をすべきかを見極めたいときに使います。
「ユーザーは X でつまずいているはずだ」という仮説から、根拠に基づく次のアクションへ移るのを助けます。

最も価値が出る人

この discovery-process skill は、継続率、離脱率、アクティベーション、オンボーディング、あるいは顧客の痛点がはっきりしない領域に取り組むチームに向いています。特に、関係者は確信を求めているのに、まだビルドを正当化できるだけの証拠が足りない場面で役立ちます。

何が違うのか

最大の価値は、流れがあることです。
このスキルは、問題のフレーミング、インタビュー設計、統合、解決策のテストを別々の一回限りのプロンプトとして扱うのではなく、一連の流れとしてつなげるよう設計されています。そのため、単独で LLM に「リサーチアイデア」や「ユーザーインタビューの質問」を尋ねるよりも、はるかに実務向きです。

discovery-process skill の使い方

まずインストールして、正しいファイルを読む

discovery-process install の手順をリポジトリの skill loader で実行し、最初に skills/discovery-process/SKILL.md を開きます。次に template.md と examples/sample.md を確認して、期待される出力の形と、完全な一連の流れがどう記録されるかを把握してください。

実際の discovery brief を渡す

このスキルは、問題領域、対象ユーザー、ビジネス上の背景、そして結果によってどの意思決定が左右されるのかが入力に含まれていると、もっとも効果を発揮します。弱いプロンプトは「オンボーディングを手伝って」とだけ書くものです。より強いプロンプトは、「セルフサーブの SMB ユーザーでアクティベーションが 15% 下がっており、主因が理解不足なのか、設定の摩擦なのか、価値訴求の弱さなのかを見極める必要がある」といった形です。

実務で使えるプロンプト例

discovery-process usage のパターンは、次のように使えます。

Run discovery-process for UX Research on our onboarding drop-off problem. Audience: first-time SMB admins. Goal: identify the biggest friction point, draft interview questions, propose a synthesis structure, and suggest one testable solution hypothesis.

すでに証拠があるなら、それも入れてください。まだないなら、その点を明示します。
このスキルは、仮説起点なのか、既存データ起点なのか、それともステークホルダーの問いから始めるべきなのかを把握できるほど、より有用になります。

読んで再利用すべきもの

まず examples フォルダを開き、一連の流れを通した参考例を確認します。そのうえで、template を自分のメモに合わせて写してください。discovery-process guide は、問題のフレーミング、リサーチプラン、インタビュー、統合、機会領域、実験、意思決定という各フェーズを、そのまま実務用の成果物として再利用するときに最も力を発揮します。

discovery-process skill の FAQ

一般的なプロンプトより discovery-process のほうが良い？

はい。単発の答えではなく、再現可能なプロセスが必要なときに向いています。一般的なプロンプトでもインタビュー質問や要約は作れますが、discovery-process は流れ全体を整え、出力を意思決定につなげやすくします。

どんなときは使わないほうがいい？

すでに問題が検証済みで、実装の詳細だけが必要なら使わないでください。
また、ユーザー向けではない社内限定の問いで、discovery インタビューや統合をしてもあまり価値が出ない場合にも不向きです。

初心者にも使える？

はい。問題を明確に説明できるなら使えます。初心者は、スキルにリサーチ課題を勝手に作らせるのではなく、template に沿って具体的な文脈を埋める使い方をすると、もっとも恩恵を受けやすいです。

UX Research のワークフローに合う？

はい。discovery-process for UX Research は特に強いユースケースのひとつで、インタビュー計画、統合の構成、そして得られた学びを実験や意思決定メモに落とし込む場面で役立ちます。

discovery-process skill を改善する方法

より鋭い問題文から始める

最良の結果は、症状、想定原因、ビジネス影響を切り分けて書いた入力から生まれます。たとえば、「ユーザーは銀行口座を連携した後の設定で離脱している。次に何をすべきかを理解できていないのが原因だと考えており、これがアクティベーション低下につながっている可能性がある」と書くほうが、「ユーザーが混乱している」よりずっと良いです。

リサーチ計画を変える制約を足す

期限がある、ユーザーへのアクセスが限られている、対象セグメントが狭い、という条件があるなら、最初に明記してください。制約があると、スキルが提案すべきなのが、切り替えインタビューなのか、サポートチケットの確認なのか、軽めの統合なのか、より速いコンセプトテストなのかが変わります。

実行できるアウトプットを求める

より良い discovery-process usage の結果を得るには、具体的な成果物を依頼してください。たとえば、インタビューガイド、統合フレームワーク、機会文、検証可能な仮説です。単に「インサイト」とだけ頼むと、実際の意思決定に進めるには抽象的すぎる出力になりがちです。

最初の出力を踏まえて繰り返す

最初の出力を使って、次のラウンドを絞り込みます。フレーミングが広すぎるなら対象ユーザーを狭めます。インタビュー計画が一般的すぎるなら、行動証拠や具体的なファネル段階を追加します。提案された解決策が早すぎるなら、発想よりもまず問題の検証に重きを置くよう依頼してください。