価値実現哲学

ステータス: Production Ready ✅ バージョン: 1.2.4 最終更新: 2026-05-05 タイプ: 分析フレームワーク

概要

このスキルは、エンドユーザーがプロダクトを通じて達成できる価値を「知る」ことができるかどうかを評価するための哲学的フレームワークと分析方法を提供します。チェックリストを提供するのではなく、価値発見の視点から分析をガイドします。

このスキルが提供するもの:

• 不確実性がある場合のプロダクトアイデアを評価するフレームワーク
• エンドユーザーの価値発見を評価するための分析方法
• 実際のプロダクト成功と失敗からのパターン
• プロダクト設計、ポジショニング、および価値伝達の分析方法

コア問題: エンドユーザーは、その価値の実現に時間がかかったとしても、プロダクトを通じて達成できる価値を明確に理解できるか？

主要用語:

• ユーザー: このスキルを使用している人（プロダクト作成者、PM、デザイナー、起業家など）
• エンドユーザー: 議論するプロダクトを実際に使用する人
• 価値: 主体とオブジェクト間の有益な関係的特性。エンドユーザーがプロダクトを通じて達成する結果として表現される（アイデンティティ、経済的利益、能力向上、時間節約など）
• 機能: プロダクトの技術的能力
• 価値シナリオ: エンドユーザーが特定のタスクまたは目標を持ってプロダクトを使用し、理解、検証、認識可能な結果を得る具体的なコンテキスト
• 使用シナリオ: プロダクトが使用される可能性のある具体的なコンテキスト
• ユースケース: エンドユーザーが特定のコンテキストでプロダクトを使用して完了する特定のタスクまたはワークフロー

コア区別:

• 機能は価値ではない
• 機能はプロダクトができることであり、価値はエンドユーザーが得る結果である
• 分析は機能を特定のエンドユーザー結果に変換する必要がある
• 価値分析は価値を具体的なシナリオに配置すべき
• 使用シナリオはプロダクトが使用される場所を説明し、ユースケースはエンドユーザーがそれを使用してタスクを完了する方法を説明し、価値シナリオはそのコンテキストでエンドユーザーが得る結果を説明する

コア洞察

エンドユーザーは、得られる価値を知っているときにプロダクトを採用します。この「知っている」ことが重要です：

• エンドユーザーが価値を達成することを知っている場合（長期的であっても）、彼らはそれを使用する
• エンドユーザーが達成できることを知らない場合、プロダクトがどんなに優れていても使用しない

「知っている」ことの意味:

• エンドユーザーは、自分たちまたは他人に対してなぜプロダクトを使用しているのかを説明できる
• エンドユーザーは、存在する機能だけでなく、何を達成するかを説明できる
• エンドユーザーは、時間がかかったとしても、その結果を理解している

観察されるパターン:

• エンドユーザーが明確な価値を説明できる場合 → 導入率が高い
• エンドユーザーが価値を説明できない場合 → 革新的な機能があっても導入に課題がある
• 一部のエンドユーザーは完全な明確性なしに採用し、使用を通じて価値を発見する（段階的発見）

エンドユーザーが求める価値の種類（これらに限定されない）:

• アイデンティティと帰属意識
• 経済的利益
• 短期的利益
• 長期的利益
• ステータスと認識
• 能力向上
• 時間節約
• 問題解決

価値シナリオの役割: プロダクト属性そのものはエンドユーザーの価値ではありません。分析はシナリオを使用して、プロダクト属性をエンドユーザー結果に結びつけ、価値が発生するコンテキストを定義し、価値が保持されるかどうかを判断する根拠を提供すべきです。

属性は依然として重要です。属性は証拠を提供し、シナリオは属性とエンドユーザー結果間の関係を確立するのに役立ちます。

チャレンジ

ほとんどのプロダクト作成者が直面する隠れた問題：エンドユーザーは通常、自分たちが本当に何を求めているかを知らず、それを表現する方法が間違っている可能性があることです。

仕事は、エンドユーザーが求めるものを構築することだけではなく、エンドユーザーが実際に求めている価値を発見するのを助けることです。

このスキルの使い方

このスキルは会話分析を通じて動作します。ユーザーがプロダクトアイデア、機能、コピー、使用シナリオ、またはユースケースを提示するときは：

1. エンドユーザーを特定する - プロダクトを使用する人を決定する
2. 価値シナリオを特定する - 価値が発生する具体的なコンテキストを決定する
3. 4つの次元で評価する - 価値の明確性、タイムライン、認識、発見
4. リクエストに出力を調整する - 完全な分析、コピー、使用シナリオ、ユースケース、または診断評価
5. コンテキストを検討する - 各プロダクト、市場、およびエンドユーザーグループは異なる

このフレームワークは思考をガイドします。ソリューションを規定するものではありません。

分析アプローチ:

• 現在の価値シナリオの周りで4つの次元を通じて評価する
• 現在のリクエスト形式に出力形式を調整する：
  • プロダクトアイデアを評価する場合、すべての4つの次元を完全に分析する
  • コピー、使用シナリオ、またはユースケースを作成する場合、まず価値が明確か、価値がいつ発生するか、結果が認識可能か、エンドユーザーが使用を通じて価値を発見する必要があるかを判断してから、4つの次元を評価する
  • 既存のコピーまたは価値提案を診断する場合、4つの次元を使用して有効性を評価する
  • ユーザーがプロダクトを最適化するか改善の方向性を提供するよう求める場合、まず4つの次元を使用して、分析対象の現在のオブジェクトがエンドユーザーが具体的な価値シナリオで結果を取得、理解、検証、または認識する方法に影響を与える方法を説明し、その後、価値実現または価値伝達に関連する調整を提案する；調整は価値シナリオと分析結論から導き出されるべき、および現在の証拠で支持される判断と検証が必要な仮説を区別すべき
• 4つの次元分析の状態指標を出力する前に、references/scoring-rubric.md を読む
• 各次元の分析プロセス：
  1. この次元の分析的推論を説明する（この次元がなぜこのプロダクトにとって重要なのか）
  2. この次元の分析方法を現在のプロダクトアイデア、機能、コピー、使用シナリオ、またはユースケースに体系的に適用し、判断が依存する前提条件と適用可能性の境界を述べる（分析をスキップして質問に直接ジャンプすることはできない）
  3. 次元分析を完了した後、状態指標（🔴🟡🟢）を使用して状態評価を提供し、現在の状態の具体的な説明を提供する（曖昧な一般化ではなく）。references/scoring-rubric.md に対して状態を確認する
  4. プロダクトケースを引用する場合、検証可能な情報に基づき、現在のプロダクトとの関連性を説明する（「研究方法論」セクションのケース適用可能性評価）
  5. プロダクトの必要性を直接的に異議を唱えるか、既存のソリューションとの比較を必要とする鋭い質問を提示する
• すべての4つの次元を完了した後、サマリーを提供する
• 論理的ギャップを避け、完全な推論チェーンを表示する
• ユーザーが分析に基づいて決定を下すようガイドする

分析フレームワーク

現在の価値シナリオの周りでこれら4つの次元を分析し、エンドユーザーが価値を発見するかどうかを評価します：

1. 価値の明確性

検討事項:

• エンドユーザーは自分たちが何を達成するかを説明できるか？
• 価値提案はエンドユーザーにとって明確または曖昧か？
• エンドユーザーは、機能だけでなく、結果を理解しているか？
• エンドユーザーは、具体的なシナリオでプロダクトとタスク間の関係を説明できるか？

なぜこれが重要なのか: エンドユーザーがなぜそれを使用しているかを自分たち（または他人）に説明できない場合、プロダクトを採用しません。

実例 - Dropbox （詳細データは references/real-cases.md を参照）:

• エンドユーザーにとっての明確な価値：「任意のデバイスからファイルにアクセスできる」
• エンドユーザーは、達成できることを即座に理解した
• 「クラウドストレージ」（技術的）ではなく「どこからでもアクセス可能」（価値）
• 洞察：技術的機能をユーザー向け価値に変換する

実例 - Google Wave （詳細分析は references/real-cases.md を参照）:

• エンドユーザーにとっての曖昧な価値：「統一されたコミュニケーション」
• エンドユーザーは、達成できることを説明できなかった
• リリース後14ヶ月でシャットダウン。革新的な機能にもかかわらず
• 教訓：明確な価値のない機能 = 採用なし

分析方法: 「なぜこれを使用しているのか？」と聞かれたときにエンドユーザーが何と言うかを尋ねてください。答えが不明確または機能に焦点を当てている場合（「Xがあるから」）、実際の価値提案を掘り下げてください。その後、答えが具体的なシナリオにマップされるかを確認してください：どのような条件下で、どのタスクを完了するために、そしてどの結果を得るために。

2. 価値のタイムライン

検討事項:

• エンドユーザーにとって価値は即座か遅延か？
• 遅延の場合、エンドユーザーはそれが来ることを知っているか？
• ジャーニー中にエンドユーザーをエンゲージされたままにするもの？
• 価値シナリオでは、価値は即座、後で、または継続的な蓄積を通じて発生するか？

なぜこれが重要なのか: 短期的価値と長期的価値の両方が有効なアプローチです。選択はプロダクトの性質、特定のシナリオ、およびエンドユーザーのコンテキストに依存します。どちらが本質的に優れているわけではありません。

短期的価値プロダクト（エンドユーザーが数分/数時間で結果を見る）:

• Dropbox：アップロード → 他のデバイスでファイルを表示（< 5分）
• Zoom：リンクをクリック → ミーティングに参加（< 30秒）
• Stripe：テスト支払いを実行 → それが機能することを確認（< 1分）
• 主要な検討事項：即座の価値は完全なプロダクトです

長期的価値プロダクト（エンドユーザーが数週間/数ヶ月で結果を見る）:

• Duolingo：言語流暢性（6-12ヶ月）
• フィットネスアプリ：体の変身（3-6ヶ月）
• 投資アプリ：富の構築（数年）
• 主要な検討事項：エンドユーザーはジャーニーにコミットします

利用可能な設計アプローチ:

• 純粋な短期：即座の価値を提供。それが完全なプロダクトです
• 純粋な長期：エンドユーザーはジャーニーにコミットされており、短期的なタッチポイントは必要ありません
• ハイブリッド：長期目標と短期的なタッチポイント（XP、ストリーク、マイルストーン）
• 3つのアプローチすべてが有効です。プロダクトの性質とエンドユーザーのコンテキストに基づいて選択してください

分析方法: 主要な価値タイムラインを特定します。アプローチがプロダクトの性質、現在の価値シナリオ、およびターゲットエンドユーザーの期待と一致するかを評価します。エンドユーザーが既に長期目標にコミットしている場合、短期メカニズムを強要しないでください。

3. 価値認識

検討事項:

• エンドユーザーは、自分たちが達成したことを見たり感じたりできるか？
• エンドユーザーにとって進捗は有形か抽象的か？
• エンドユーザーは、他人に達成したことを示せるか？
• 価値シナリオでは、エンドユーザーが「これを達成した」と指摘できる具体的な結果は何か？

なぜこれが重要なのか: 見えない価値は、エンドユーザーにとっては価値がないように感じます。進捗は認識可能でなければなりません。

注記: 「認識可能」はプロダクトタイプ全体で異なる形を取ります：

• コンシューマープロダクト：UI内の即座のビジュアルフィードバック（ファイルが表示される、写真が強化される）
• エンタープライズソフトウェア：レポート、ダッシュボード、メトリック、分析
• 開発者ツール：ビルド出力、テスト結果、パフォーマンスメトリック
• 重要なのは、エンドユーザーが価値が提供されたことを示す具体的なものを指摘できることです

エンドユーザーに見える結果:

• Dropbox：ファイルが別のデバイスに表示される（有形）
• Instagram：いいねで美しい写真（有形）
• GitHub：貢献グラフ（有形）
• Duolingo：ストリーク カウンター（有形）
• 観察：これらのプロダクトは達成を見える化し、シェア可能にします

見えない結果（エンドユーザーにとって問題）:

• 「データが同期されています」（抽象的。見えません）
• 「セキュリティが改善されました」（見える変化なし）
• 「アルゴリズムが最適化されました」（見た目が異なりません）
• 観察：技術的改善は、見える表現なしでエンドユーザーが認識するのは難しい

分析方法: エンドユーザーが「これを達成した」と指摘できるものを特定します。価値が見えない場合、UI、通知、進捗指標、結果比較、またはシナリオフィードバックを通じて有形にする方法を探索してください。

4. 価値発見

検討事項:

• エンドユーザーは既にこれが欲しいことを知っているか？
• またはエンドユーザーは使用後に価値を発見するか？
• エンドユーザーが認識していない価値を発見するのをどう支援するか？
• エンドユーザーはシナリオに入る前に価値を知っているか、またはシナリオを経験する前にそれを認識する必要があるか？

なぜこれが重要なのか: 場合によっては、エンドユーザーは経験するまで何が欲しいかを知りません。プロダクトは彼らが迅速にそれを発見するのを支援する必要があります。

発見パターン - Instagram （成長データは references/real-cases.md を参照）:

• エンドユーザーが思ったこと：「写真を共有する」
• エンドユーザーが発見したこと：「フォトグラファーになる」（アイデンティティ）
• Instagramはフィルター、いいね、社会的検証を通じて発見を支援した
• 洞察：Instagramの成功は、写真共有の効用ではなく、アイデンティティ変身を可能にすることから来た

発見パターン - Notion:

• エンドユーザーが思ったこと：「メモを取る」
• エンドユーザーが発見したこと：「整理される」（アイデンティティ）
• Notionは柔軟なデータベースとテンプレートを通じて発見を支援した

分析方法: エンドユーザーが既に何が欲しいかを知っているか、それとも発見する必要があるかを判定します。発見が必要な場合、オンボーディング、チュートリアル、例シナリオ、または段階的な機能の開示を通じて「Aha」モーメントへの最速パスを特定します。

実際のプロダクトからのパターン

これらは従うべきルールではありません。特定の状況を分析するときに検討するべき観察されたパターンです。

詳細なケーススタディと実際のデータは、references/real-cases.md（英語）または references/real-cases-zh.md（中文）を参照してください。

パターン：価値伝達

具体的な結果説明を使用しているプロダクト:

• Dropbox：「任意のデバイスからファイルにアクセス」
• Instagram：「フォトグラファーになる」（アイデンティティ変身）
• 観察：これらのプロダクトは具体的で達成可能な結果説明を使用しています

技術的またはプロダクト説明を使用しているプロダクト:

• Google Wave：「統一されたコミュニケーション」（技術的なコンセプト）
• 一部のプロダクト：「クラウドストレージ、2GB無料」（機能リスト）
• 一部のプロダクト：「分散ファイル同期」（技術用語）
• 観察：これらの説明により、エンドユーザーが達成できることを理解するのが難しくなります

実例

メトリック付きの完全なケーススタディについては、references/real-cases.md を参照してください。

このフレームワークが適用される場合

最も適用可能:

• コンシューマープロダクト（B2C）
• 競争的市場（エンドユーザーは代替手段がある）
• 採用と保持が必要なプロダクト
• 新しいプロダクトカテゴリー（エンドユーザーは期待を知らない）
• 価値提案、使用シナリオ、または機能から価値への説明を明確に表現する必要がある状況

適用可能性が低い:

• エンタープライズソフトウェア（意思決定者 ≠ エンドユーザー。切り替えコスト高）
• 独占プロダクト（エンドユーザーは選択肢がない）
• 価値が本質的に遅延しているプロダクト（投資、保険）

一般的な落とし穴

落とし穴1：エンドユーザーが何を求めているかを知っていると仮定する

罠: エンドユーザーが求めるものを正確に構築する 現実: エンドユーザーは通常、自分たちが実際に何を必要とするかを知らない アプローチ: 会話と探索を通じてエンドユーザーが実際の価値を発見するのを支援する

落とし穴2：機能ではなく価値に焦点を当てる

罠: 「私たちのプロダクトはX、Y、Z機能があります」 現実: エンドユーザーは機能について気にしません。彼らが達成できることについて気にします アプローチ: 常に機能を価値に変換する：「機能XはエンドユーザーがYを達成するのを支援する」

落とし穴3：機械的にパターンをコピーする

罠: 「Duolingoはストリークを使用しているため、私たちも使用すべき」 現実: 他のプロダクトの機能またはパターンを価値そのものとして扱うが、これらの機能がその特定のエンドユーザーに対して価値を生成するメカニズムを理解していない アプローチ: これらの機能またはパターンが彼らのエンドユーザーのために価値を生成する理由を理解する：どのシナリオで、どのような問題を解決し、どの結果を達成するか。その後、現在のエンドユーザーに適用するかどうかを判断する

落とし穴4：見えない価値

罠: 「私たちのアルゴリズムは10倍優れています」 現実: エンドユーザーが改善を見たり感じたりできない場合、それは重要ではありません アプローチ: 価値をエンドユーザーに有形かつ見える化する

落とし穴5：クロスコンテキストの誤用

罠: 「Dropboxは明確な価値で成功したため、同じ結論を直接適用できる」 現実: 結論は特定の前提条件下でのみ保持される。元のコンテキストと現在のコンテキストが異なる場合、元の結論は失敗する可能性がある アプローチ: 結論の背後にある前提条件を復元し、現在の状況がそれらを満たすかどうかを確認する

落とし穴6：クロスレベルの誤用

罠: 「機能レベルで判断が保持されるため、全体のプロダクトが既に検証されている」 現実: ローカル的、戦術的、短期的な結論は全体的、戦略的、長期的な結論と等しくない アプローチ: 結論がどのレベルに属しているかを決定し、それが上方向に一般化できるかどうかを判断する

落とし穴7：シナリオなしで価値について議論する

罠: 「この機能は効率を改善し、コストを削減し、経験を改善する」 現実: 価値が発生するシナリオが指定されていない場合、エンドユーザーはその価値が自分たちに適用されるかどうかを判断するのに困難を感じる アプローチ: 抽象的な価値を具体的なシナリオにマップする：誰がどのような条件下でどのタスクを完了し、プロダクトを通じてどの結果を得るか

落とし穴8：文脈的確実性を普遍的確実性として扱う

罠: 「この判断は別のコンテキストで保持されるため、現在のコンテキストに直接適用できる」 現実: 判断は多くの場合、特定の条件に依存する。現在のコンテキストがこれらの条件を満たさない場合、元の判断が保持されるかどうかは検証が必要な仮説である アプローチ: 元の判断が依存する主要な条件を復元し、現在のコンテキストがそれらを満たすかどうかを確認する。主要な条件が保持されていないか変更された場合、元の判断を検証が必要な仮説にダウングレードし、それを検証するために必要な証拠を特定する

研究方法論

情報精度を検証する

実際のプロダクトケースを引用する場合、検証可能な情報に基づき、現在のプロダクトとの関連性を説明してください。

ツール可用性:

• 情報検証のためにWebFetchとWebSearchが利用可能
• 研究が失敗した場合、フレームワークに基づいて分析を進め、どの情報が検証を必要とするかを明確に示す

価値シナリオを検証する

価値シナリオは分析仮説として提案できますが、直接的に事実として扱うことはできません。

以下を区別する:

• 仮説的価値シナリオ：プロダクト、エンドユーザー、機能から推測される可能な使用コンテキスト
• 検証済み価値シナリオ：ユーザーインタビュー、行動データ、実際のケース、市場資料、またはプロダクト使用証拠で支持されるコンテキスト

価値シナリオが未検証の場合、それが分析仮説であることを明確に述べ、それを検証するために必要な証拠を特定してください。

条件考古学

なぜそれが重要なのか: 理論とケースは具体的な経験から抽出され、伝達を容易にするために文脈的要因を削除しています。削除されるものは多くの場合、ノイズではなく、結論が保持されるために必要な制約です。

「Dropboxは明確な価値で成功した」ことを聞いたときに、結論そのものは受け取りますが、それを機能させた前提条件は受け取りません：競争的市場、自発的選択、個人ユーザー、即座の価値提供。

一般的な問題: ユーザーは「法則」を理解したと思い、新しいコンテキストに直接適用しますが、新しいコンテキストは必要な制約を欠く可能性があります。失敗すると、条件が一致するかどうかを確認する代わりに、実行またはラックを非難します。

適用方法: 理論、パターン、またはケース結論を引用する前に：

1. 元の結論が依存する必要な制約を復元する
2. これらの条件が現在のコンテキストで保持されるかどうかを確認する
3. 結論が適用される範囲と境界を決定する

主要な検討事項:

• 条件は変わります。1つの段階で保持される判断は、条件が変わった後に失敗する可能性がある
• すべての条件を尽くしようとしないでください。決定的な条件、主要な失敗条件、および不一致リスクを特定してください
• 理論は特定の条件下で保持され、それを超えて失敗する可能性があります

分析中に確認する:

• 元のケースまたは結論が依存した前提条件と制約
• これらの条件が現在の状況で保持されているかどうか
• 結論が保持される範囲、およびそれが保持を停止する範囲
• 現在の議論がローカル判断、全体的プロダクト判断、短期判断、または長期判断に関係するかどうか
• 条件が変わった後、結論がまだ保持されるかどうか

一般的な誤用:

• クロスコンテキスト誤用：1つの前提条件セットが保持される結論を取り、異なる前提条件がある状況に直接転送する
• クロスレベル誤用：ローカル判断、戦術的判断、または短期判断をプロダクト全体判断、戦略的判断、または長期判断として扱う

条件確実性不一致

定義: 条件確実性不一致は推論バイアスを説明する：現在の結論を形成するときに、特定の条件下でのみ保持される事前判断が、現在のコンテキストでも保持されるかのように扱われ、検証がまだ必要な仮説が判断の前提に変わります。ここで、確実性は無条件に有効な命題を意味しません。特定の条件下で使用可能な前提としての判断のステータスを意味します。

適用方法: 事前判断を現在のコンテキストで使用する必要がある場合：

1. 判断が依存する主要な条件を復元する
2. これらの条件が現在のコンテキストで保持されているか変更されているかを確認する
3. 条件の違いが現在のコンテキストでの判断の適用可能性に影響するかどうかを決定する
4. 現在の条件で支持されていない部分を検証が必要な仮説にダウングレードする

主要な検討事項:

• 主要な条件が保持されない、変更された、または十分な証拠がない場合、事前判断は現在の結論の前提として直接使用されるべきではない
• 条件の違いは事前判断が無効であることを意味しません。違いが現在の判断にどう影響するかを説明してください
• 結果だけでは原因を確立できません。帰因は推論根拠を述べ、どの追加証拠が必要かを特定すべき

ケーススタディ適用可能性を評価する

references/real-cases.md のケース（Dropbox、Instagram、Duolingo、WeChat、Google Wave、Quibi）はパターンを例示するのであって、普遍的なルールではありません。使用する前に、これらのケースの背後にある前提条件を復元し、転送されるかどうかを判定してください。

適用可能性を評価する:

• プロダクトタイプマッチ：B2Cコンシューマーアプリ対B2B開発者ツール対エンタープライズソフトウェア
• 市場コンテキストマッチ：競争的市場対ニッチ市場対独占状況
• ユーザー行動マッチ：日常使用対エピソード的使用対一回限りのトランザクション
• 価値提供マッチ：即座のユーティリティ対長期的変身対ハイブリッドアプローチ

ケースが適用されない場合: ユーザーのプロダクトが参照ケースから大きく異なる場合（例えば、B2Bインフラストラクチャツール対C2Cソーシャルアプリ）、関連するドメインの同等のプロダクトを検索します。異なるコンテキストにコンシューマーアプリのパターンを強要する代わりに、ドメイン固有の例を分析してください。

ドメイン間の例を借りる必要がある場合、まず元のケースが依存する前提条件を復元し、その後、現在のプロダクトで共有される条件と異なる条件を判定し、比較がローカル判断、全体的プロダクト判断、短期判断、または長期判断に関するかどうかを区別してください。

例:

• ユーザーが議論：開発者インフラストラクチャツール（Temporal、Kubernetesなど）
• 参照ケース：コンシューマーアプリ（Dropbox、Instagram）
• アクション：同様の開発者ツールを検索。それらの価値提案と採用パターンを分析
• 避ける：インフラストラクチャソフトウェアへのInstagramのアイデンティティ変身パターンの適用

探索と証拠のバランス

探索的思考（適切な場合）:

• エンドユーザーが求める可能性のある価値タイプを特定する
• 価値を見える化またはいただける方法をブレーンストーミングする
• 複数のポジショニングアプローチを検討する
• プロダクト方向のための仮説的価値シナリオを探索する

証拠ベースの分析（必要な場合）:

• 特定の採用パターンまたはメトリックを主張する
• 実際のプロダクトまたは市場例と比較する
• 実践で「機能する」または「機能しない」ことを述べる
• 業界の先例に基づいて分析を実施する

プロセス:

1. 議論とブレーンストーミングを通じて可能性を探索する
2. 特定の主張または比較が生じた場合、研究で検証する
3. 検証済みパターンに基づいて分析を実施する。仮定ではなく
4. 証拠が限定的またはコンテキストが既知のケースと異なる場合を認める

研究ソース

第一次ソース（推奨）:

• 公式プロダクトウェブサイトと文書
• 企業ブログ投稿または発表
• 公開されたメトリック、ユーザー数、または成長データ
• 学術研究または業界レポート

二次ソース（注意して使用）:

• テック ニュース記事または分析記事
• ユーザーレビューまたはコミュニティディスカッション
• 第三者の市場調査またはエスティメート

避ける:

• 記憶またはジェネラルナレッジのみに依存する
• 1つのドメインからのパターンが普遍的に適用されると仮定する
• 検証可能なソースなしで主張する
• 参照ケースを規定的なテンプレートとして扱う

ガイド原則

コア区別

ユーザー対エンドユーザー:

• ユーザー：このスキルを使用している人（プロダクト作成者、PM、デザイナー、起業家など）
• エンドユーザー：議論するプロダクトを実際に使用する人
• これらは異なる役割であり、異なるパースペクティブがあります

機能対価値:

• 機能：プロダクトが行うこと（技術的能力）
• 価値：エンドユーザーが具体的なコンテキストでプロダクトを通じて達成するもの（結果、利益）
• エンドユーザーは機能ではなく価値に基づいてプロダクトを採用する

価値認識のタイミング:

• 即座の認識：エンドユーザーは使用中または直後に何かを得たことを認識する
• 遅延認識：エンドユーザーは時間をかけて継続的に使用した後に何かを得たことを認識する
• これらは相互に排他的ではありません。プロダクトは両方を提供できます
• どちらが本質的に優れているわけではありません。各々は異なるエンドユーザーニーズに対応します

研究アプローチ

見慣れないコンセプトに遭遇したときの対応方法:

• 言及されたプロダクト、テクノロジー、またはドメイン固有の用語を調査する
• WebFetchまたはWebSearchを使用して現在の情報を収集する
• 公式ドキュメント、公開されたメトリック、および検証済みソースを求める

探索と証拠のバランス:

• 探索的思考：可能な価値タイプを特定するか、アプローチをブレーンストーミングする場合に適切
• 証拠ベースの分析：特定のパターン、実際のプロダクトとの比較、または実践で機能するものを主張する場合に必要

ケース適用可能性を評価する:

• 参照ケースはパターンを例示する。規定的なルールではない
• プロダクトタイプ、市場コンテキスト、ユーザー行動、価値提供が一致するかどうかを評価する
• ケースが適用されない場合、関連するドメインの同等のプロダクトを調査する

このスキルの使い方

このスキルは会話で最も効果的です。ユーザーがプロダクトアイデア、機能、コピー、使用シナリオ、またはユースケースについて議論する場合：

1. 価値シナリオを特定する：エンドユーザーがプロダクトを使用するコンテキストと、どのような結果を得るか？
2. 価値の明確性を探索する：エンドユーザーは、達成できることを説明できるか？
3. タイムラインを検討する：価値はエンドユーザーにとって即座か遅延か？このプロダクトに何が適切か？
4. 認識を評価する：エンドユーザーは進捗を見たり感じたりできるか？
5. 隠れた価値を発見する：エンドユーザーがまだ認識していない可能性のある価値は何か？

これはチェックリストではありません。考え方です。各プロダクトは異なります。各市場は異なります。目標は、エンドユーザーが具体的なシナリオで達成できる価値を知っているかどうかについて明確に考えることです。

分析中の研究：ユーザーが特定のプロダクト、テクノロジー、またはコンセプトについて言及する場合、このスキルは仮定ではなく、現在の情報に基づいたコンテキスト適切な分析を提供するためにWebFetchまたはWebSearchを通じてそれらを調査する場合があります。

主要原則

1. エンドユーザーは、達成できる価値を「知る」必要があります。時間がかかったとしても
2. 価値タイプは多様です：アイデンティティ、お金、利益、ステータス、能力など
3. エンドユーザーは多くの場合、何が欲しいか知りません。それを発見するのを支援しましょう
4. 認識はエンドユーザーにとって重要です：見えない価値は価値がないように感じる
5. コンテキストがすべてです：1つのプロダクトからのパターンは他のプロダクトに適用されない可能性がある
6. 実際のエンドユーザーでテストします。仮定しないでください：特定のシナリオで検証する
7. 短期的も長期的も有効です：どちらが優れているわけではありません。プロダクトの性質に基づいて選択してください

追加資源

参照ファイル

ケーススタディには定量的データとデータソースが含まれます：

• references/real-cases.md - Dropbox、Instagram、Duolingo、WeChat、Google Wave、Quibiのケーススタディ（英語）
• references/real-cases-zh.md - Dropbox、Instagram、Duolingo、微信、Google Wave、Quibiの案例分析（中文）

状態指標参照基準：

• references/scoring-rubric.md - 4つの次元全体での状態指標（🔴🟡🟢）の参照基準：価値の明確性、タイムライン、認識、発見（英語）
• references/scoring-rubric-zh.md - 价值清晰度、价值时间线、价值感知、价值发现四个维度的状态指示符（🔴🟡🟢）参考标准（中文）

方法論研究文書：

• references/learning-methodology.md - 基礎優先型および問題駆動型学習アプローチの動作メカニズム、リスク、環境での表現、および統合方法の分析（英語）
• references/learning-methodology-zh.md - 基础优先型和问题驱动型学习方式的运作机制、风险、环境表现及结合方式分析（中文）

注意

このスキルは価値について考えるのを支援します。ソリューションを規定するものではありません。すべてのプロダクトはユニークです。すべての市場は異なります。目標は、エンドユーザーが明確に理解できるかどうかを発見することです。なぜなら、その理解は採用を促進するからです。