value-realization

価値の実現

タイプ：分析フレームワーク

概要

このフレームワークは、製品、機能、コピー、利用シナリオ、その他あらゆる価値提案が、具体的な状況で実際に価値を生み出すかどうかを判断します。チェックリストでも、一度実施して報告書を提出する評価フォームでもありません。相互に独立した複数の分析軸と、継続的に対話するための手法を組み合わせたものです。曖昧な「これは良いのか」という判断を、「どのシナリオで、何を根拠に、いつ、知覚できる価値として生み出せるのか、そしてこうした結論のどれほどが信頼できるのか」という問いへと変え、最終的に本当に通用する価値やビジネス機会を引き出すまで、何度も対話を重ねられるようにします。

このフレームワークの前提は一つです。価値とは、伝えて説明するのを待っている固定されたメッセージではなく、具体的なシナリオにおいて、双方の状態によってともに生み出される関係です。したがって、価値を判断するとは、それを明確に説明することではなく、この有益な関係が実際に成り立つ具体的なシナリオ構成を見つけることです。価値の発見につながるのは、合意や言い換えではなく、鋭い反証と絶え間ない掘り下げです。この考え方は、実際のユーザーと話すときも、AI との対話を繰り返すときも、フレームワーク全体を貫いています。

重要用語

• ユーザー：このスキルを使用する人（プロダクトクリエイター、プロダクトマネージャー、デザイナー、創業者など）です。
• エンドユーザー：検討対象のプロダクトを使用する人です。
• 経験：変化し続ける歴史的な期間の中で、特定の条件下において特定の問題を解決し、その問題を正しく解決する方法を生み出した過去の出来事です（その方法には、それ自体の前提条件と使用方法が含まれます）。経験は特定のシナリオに依存し、選択的に適用されます。使用する前に、条件が変化していないかを判断する必要があります。
• 価値：主体と客体の間にある有益な関係的特性です。両者の状態を条件とする、重み付けされた主観的な特性です。主体と客体がどちらも人である場合、その価値は両者の認識の重み付けされたバランスによって決まります。
• 価値シナリオ：有益な関係が成立する具体的な構成です。誰が、どのような状態で、どのような状況や条件のもとで、これを使うことでどのような結果を得るのかを示します。
• 価値関係の構成：価値シナリオにおける「主体 — 客体 — 状態 — 条件」の具体的な組み合わせです。価値を発見するとは、突き詰めれば、この構成を確定することです。
• 価値関係の位置：関係のどこで価値の確認や結果の実現が起きるかを示します。少なくとも次の3種類があります。エンドユーザーが外部のオブジェクト、コンテンツ、または機能に自分にとっての価値があると確認すること、エンドユーザーがプロダクトを通じて自身の結果を達成すること、他者や集団、システムからのフィードバックを通じて、エンドユーザー自身、その行動、またはその成果に価値があると確認されることです。この3種類は共存できますが、互いに置き換えることはできません。
• 第二層の条件：具体的な経験から抽出された、より抽象的で、複数のシナリオで再利用できる、表面的な実践より上位の制約です。ミクロな条件が変わり続けるときは、これを抽出して記録する必要があります。
• 利用シナリオ：プロダクトが使われる可能性のある具体的な状況です。
• ユースケース：ある状況において、エンドユーザーがプロダクトを使って完了する具体的なタスクやフローです。
• 機能：プロダクトの技術的な能力です。

次の区別を明確にしておく必要があります。

• 機能は価値ではありません。機能とはプロダクトができることであり、価値とは具体的なシナリオにおいてエンドユーザーが結果として得るものです。
• 利用シナリオはプロダクトが使われる可能性のある場所を示し、ユースケースはユーザーがどのように使ってタスクを完了するかを示します。価値シナリオは、関係がどこにあり、どのような根拠によって有益な特性が生じるかを示します。使えることと価値を生み出すことは同じではありません。
• 価値について語るには、具体的なシナリオに当てはめる必要があります。シナリオから切り離された価値が真か偽かを判断することはできません。
• すべての結論には、独立した2つの軸があります。方向性（成り立つかどうか）と確かさ（どれほど証拠に基づいているか）です。この2つは互いに置き換えることができません。

3つの基本定義

フレームワーク全体は3つの定義に基づいています。分析中は繰り返し立ち返ってください。

経験

経験とは、過去に起きた出来事であり、特定の条件下で特定の問題を解決し、その問題を正しく解決する方法を生み出したものです（その方法には、それ自体の前提条件と使用方法が含まれます）。重要な点は3つあります。過去に起きたことであり、未来についての予測は含まれません。特定の条件と特定の問題に結び付いています。永遠に通用するのではなく、変化し続ける歴史的な期間の中で成り立ちます。

その歴史的な期間の中でもミクロな条件は変わり続けるため、具体的な経験から、より抽象的で変化に強い第二層の条件を抽出して記録する必要があります。つまり、経験は特定のシナリオに依存し、主観的な判断に基づいて選択的に適用されます。使用する前に、条件が変化していないかをまず判断する必要があります。

価値

価値とは、主体と対象の間にある有益な関係的特性です。つまり、双方の状態に応じて変化する、重み付けされた主観的な特性です。主体と対象の両方が人である場合、双方の認知の重み付けされたバランスによって決まります。

価値は双方の状態と特定のシナリオに基づくものであり、プロダクトが一方的に持ち、ユーザーと切り離されても変わらない固定的な特性ではありません。経験もまた、特定のシナリオにおいてのみ価値を生み出します。条件が変われば、経験が役に立たなくなることもあります。過去の経験を実際のシナリオで再利用するには、通常、その時点で状況を再分析し、手法の使い方を調整する必要があります。

異なるシナリオにいるエンドユーザーは、アイデンティティや帰属意識、経済的利益、地位や評価、能力の向上、時間の節約、問題の解決など、さまざまな価値を求めることがあります。こうしたリストはあくまで検討のきっかけであり、そのまま適用するテンプレートではありません。

情報の損失

経験は、当事者を主体として生まれます。また、人は当事者と第三者を同時に兼ねることができないため、経験には本質的な限界と損失があります。

• 書面での要約は、記録者の文章力に左右され、損失が生じます（出来事を100％再現することはできません）。ただし、並外れた表現力があれば、情報が増えることもあります。
• 人と人とのコミュニケーションは、双方の認知、表現、認識に大きく左右されます。話し手1が100点分を伝えようとしても、口に出せるのは80点分かもしれません。それが話し手2の認知と認識の中で60点分に縮まり、間で40点分の損失が生じます（逆に、情報が増えることもあります）。

核となる洞察

価値とは、特定のシナリオにおける双方の状態によって共に生み出される関係であり、プロダクトが一方的に持ち、ユーザーに渡すのを待つものではありません。ここから、本文全体を貫くいくつかの判断が導かれます。

• 価値の発見とは、価値関係の構成を特定することです。「これには価値があるか」という問い自体が不適切です。正しく問うべきなのは、「誰が、どのような状態にあり、どのような条件のもとで、どの構成なら有益な特性を生み出すのか」です。その構成を見つければ価値を見つけたことになり、見つけられなければ、どんな主張も空虚です。
• **一人では価値の全体を算出できません。**価値は双方の認知の重み付けされたバランスによって決まるため、一人で分析しても、自分側の半分しか把握できません。もう半分、つまりエンドユーザーの状態や認知、そのユーザーが置かれたシナリオの条件は、実際の、かつ条件に合致するエンドユーザーから得る必要があります。
• **価値には度合いがあり、オンかオフかではありません。**価値は重み付けされたバランスであり、本質的に連続しています。そのため、判断は「当てはまる／当てはまらない」という二択では表せません。どこまで深く調査したのか、どの程度が証拠に基づいているのかも示す必要があります。
• **条件には時間が関わります。**経験も価値も特定の条件のもとでのみ成り立ち、条件は動的に変化します。2年前には妥当だった判断も、今日では条件が変わっているかもしれません。同じように見えても、実際には異なります。

2つのメタ原則

具体的な観点よりも優先される2つの規律があります。それぞれの分析では、まずこの2つに照らして立場を調整し、その後で各観点に進みます。これらは、よく見られる2つの分析上の偏りに対処するものです。

1：具体的なものから始め、「本質」を見抜こうとする習慣を持たない

何かがすでに具体的な形で現れ、はっきり認識できるようになった時点で、価値や問題はすでに形を成し、目の前に現れています。その場合は、習慣的に「本質」へ抽象化するのではなく、その具体的なものを直接使って構築すべきです。

本質に近づこうと掘り下げるほど、価値を支える具体的な条件がそぎ落とされていきます。情報損失の観点から見ると、抽象化とは条件を取り除くことであり、それは損失です。一方、現象は条件が最も完全で、損失が最も少ない状態です。それを見抜いて認識するだけで行動に移さなければ、実現も検証もできない、見栄えのよい評価に終わってしまいます。

必要な抽象化は、複数のシナリオで再利用できる第2層の条件を抽出することだけです。したがって、抽象化は第2層までにとどめ、本質まで掘り下げて、手元にある具体的で使えるものを失わないでください。

分析するとき：ユーザーがすでに具体的な現象――実際のフィードバック、実際の利用行動、実際のデータセットなど――を示し、それについて話せる場合は、まずその具体的なものから始めてください。先に壮大な真理へ抽象化してから議論してはいけません。

2：矢を放つ前に的を定める

価値は特定のシナリオでのみ生み出されます。そのため、的がなければシナリオもなく、価値が生まれる場所もありません。

明確な期待を定めないまま投資を続け、効果があれば続け、なければやめるというのは、的もなく矢を放ち続けるようなものです。条件が変わると、以前は有効に見えたものがすぐに通用しなくなります。通常は、まず的を定め、価値が生まれる具体的なシナリオ設定を固定してから、矢を放つべきです。一方で、的を見つけるための探索的なケースもあります。環境が動的に変化する場合は、的そのものを見つけなければなりません。このフレームワークはどちらの進め方にも対応していますが、的が定まっているふりをせず、どちらの段階にいるのかを明確に区別する必要があります。

分析するとき：まず、的があるか（価値が生まれるシナリオが明確か）を確認してください。ない場合は、まずユーザーとともに的を定めるか、現在は探索的な目標探索モードにあると明示してください。的がないのに価値を評価するふりをしてはいけません。

分析フレームワーク：相互に直交する4つの次元

現在の価値シナリオを軸に、相互に独立した4つの次元から評価します。直交しているとは、各次元が他の次元の答えを前提としない問いに答え、ある次元の結論が別の次元の結論の代わりになったり、そこから導かれたりしないことを意味します。

次元	その次元だけが答える問い	独立した軸
価値シナリオ	どのような関係性の構成で価値が生まれるのか。誰が、どのような状態で、どのような状況において、この関係性から有益な特性を得るのか。	場所（そこにあるか）
価値条件	この価値は何を基盤として成り立つのか。それを支える前提条件は今も存在しているのか、また、時間とともに崩れる可能性はあるのか。	基盤（安定しているか）
価値のタイムライン	価値はいつ生まれるのか。すぐに生まれるのか、遅れて生まれるのか、それとも継続的な蓄積が必要なのか。双方は価値が生まれることを認識しているのか。	時間（いつか）
価値の提供	生み出す側から受け取る側へ、価値は損失を抑えて認識・理解・検証できる形で届くのか。それともバックエンドに埋もれ、表に出せないのか。	提供（届くか）

この4つの次元は、価値が生まれてからユーザーに届くまでの経路にある、互いに切り離された4つのつながりに対応しています。どこで生まれるのか、何を基盤として成り立つのか、いつ生まれるのか、どのように届くのかです。いずれかのつながりを変えても、他のつながりの状態が前提になるわけではないため、これらは相互に独立しています。 4 つの次元は同じ重みではありません。価値シナリオが重心です。真の価値を見いだすことは、本質的には、便益をもたらす関係が成り立つシナリオ構成を確定することです。残る 3 つの次元では、そのシナリオが現実的で安定しているか、いつ成果につながるのか、そして実現可能かを検証します。

各次元では、同じ流れに沿って進めます。

1. この次元が重要な理由：定型文ではなく、現在の対象にとってこの次元が重要な理由を、根拠を示して説明します。
2. 現状の評価：この次元の手法を現在の製品、機能、コピー、またはシナリオに体系的に適用し、判断の前提条件と適用範囲の限界を明確に示します。分析を飛ばして、いきなり質問に進んではいけません。分析で矛盾を指摘すべき場合は、率直に指摘します。婉曲な説明に埋もれさせず、「ここでの緊張関係は…」と 1 行で示し、現在の構想がどこで自らと衝突しているのかを明らかにします。
3. 実在する製品名を挙げた比較（すべての次元で必須。任意ではありません）：実在する製品を 1 つ、または複数、現在の対象を照らし合わせる鏡として取り上げます。「あるツール」のように曖昧にせず、名前を挙げます。Grammarly なのか Google Analytics なのか、Duolingo なのか Mixpanel なのかを明示し、この次元でその製品が成り立つ前提条件を示してから、現在の対象と比較します。実在する製品の価値提案は、最も明確な参照点です。Grammarly が売るのは「間違いを表示すること」（データ）ではなく「間違いを修正すること」（結果）です。Duolingo のユーザーが目指すのは語学の流暢さであり、XP は補助的な接点にすぎません。この具体的な比較によって、現在の対象がこの次元で通用するかを明らかにします。本当に比較可能な製品がない次元では、曖昧な「類似ツール」でごまかさず、「この次元には直接比較できる製品がありません」と述べます。
4. 見出しには記号、本文には論拠：この次元の方向性を示すライト（🔴🟡🟢の丸）と確実性（🟩🟨🟧🟥の四角）は、次元の見出しの直後に置きます。例：### 3. Value Timeline 🟡 🟧。記号だけで意味が伝わり、一目で確認できます。方向性には丸、確実性には四角を使い、形を変えて混同を防ぎます。「なぜこの評価なのか」を独立したラベル行にしてはいけません。「現状は…」「ここでの緊張関係は…」などの表現を使い、判断を十分に述べながら、この次元の論拠の本文に組み込みます。この 2 つの評価を判断する前に、references/scoring-rubric.md を確認してください。
5. 鋭い質問（各次元の末尾に 1./2./3. の番号付きで 1 グループ）：鋭い質問を段落に埋め込んでぼかしてはいけません。この次元で特に核心を突く 2～3 個の質問を選び、番号付きのグループとして抜き出して、畳みかけるように提示します。それぞれの質問は現在の判断の弱点を突き、相手に真正面から答えさせるものでなければなりません。曖昧に受け流せる質問ではいけません。狙うべき鋭さの例：「XP システムはユーザーが優れたマーケターになるのを助けているのですか。それとも、エンゲージメントを演出しているだけですか。」「ユーザーがすでに Google Analytics を使っているのに、なぜ別の分析ツールが必要なのですか。」価値の発見につながるのは、反証と厳しい問いかけであって、同意ではありません。この鋭い質問のグループこそ、相手にボールを投げ返し、次のやり取りへ進むための取っ手です。

各次元では、診断のように、短く、率直に、遠慮なく述べます。報告書のようにしてはいけません。まず論拠、次に比較、見出しに記号、最後に鋭い質問のグループという順序を守ります。要約する前に 4 つすべての次元を完了し、論理の飛躍を避け、推論の全過程を示してください。

1. 価値シナリオ（重心）

まず、どの関係構成において価値が生まれるのかを確認します。つまり、誰が、どのような状態で、どのような状況や条件のもと、このものを使うことでどんな結果を得るのかを明確に述べられるでしょうか。ここでは、価値シナリオと利用シナリオを区別する必要があります。使えることと、価値を生み出すことは同じではありません。また、構成の精度も確認します。大まかなセグメントを定めるだけではシナリオをかすめるにすぎません。セグメント、その状態、そして具体的にどんな問題に行き詰まっているのかまで特定できれば、十分に精度の高い構成です。

また、価値関係における位置づけも明確にします。この価値は、ユーザーが外部の対象を自分にとって有用だと確認するものなのか、ユーザーがプロダクトを通じて自分自身の成果を達成するものなのか、それともユーザー自身やユーザーの成果が、他者やシステムから価値あるものとして認められるのか。これら3つはしばしば混同されますが、それぞれまったく異なるプロダクトの主張を支えます。

価値は特定の構成においてのみ成立します。構成が明らかでなければ、残りの3つの側面には結びつける先がありません。誰に提供するのか、どのような条件のもとで何を検証するのかが分からないためです。これこそが、メタ原則2の対象です。

方法：抽象的な価値を具体的な構成へと落とし込みます。誰が、どのような状態で、どのような状況や条件のもと、どんな結果を得るのか。具体化できないなら、まだ対象が定まっていないということです。それ自体が重要な結論です（方向 🔴 または確実性「空」）。次にすべきことは、対象を定めるか、話を聞きに行くことであり、さらに下へと分析を続けることではありません。

2. 価値条件

まず、この価値はどのような根拠にもとづいて成立するのか、それを支える前提条件は何か、その条件は今も存在するのか、時間の経過や市場、テクノロジー、ユーザー習慣の変化に伴って崩れる可能性はないかを確認します。また、他者の経験や事例を借りている場合は、応用可能な第2層の条件を抽出できているのか、それとも表面的な実践だけを模倣しているのかを確認します。経験も価値も、特定の条件下でのみ成立し、条件は動的に変化します。この側面は、「条件が変わったのに、判断はそのまま」という事態を防ぐためにあります。

この側面で重要なのは、条件には時間の要素があることです。2年前に成り立っていたプロダクトに関する判断と、今日「同じ条件に見える」判断は、実際には異なる条件にもとづいていることがよくあります。競合の密度、プラットフォームの成熟度、ユーザー習慣、テクノロジーの利用可能性、トラフィックのコストはいずれも変化しているため、以前は成功しても、今回は成功しないかもしれません。過去の経験、事例、自分自身の過去の成功を引き合いに出す前に、まず、それが成立するために必要だった条件は今も存在するのかを確認します。これこそが、「経験」の定義にある「動的に変化する歴史的時期」の意味です。

方法：価値の成立が依存する重要な前提条件を列挙し、それぞれについて「存在する」「変化した」「不明」のいずれかを判断します。特に、時間の影響を受ける条件には印を付けます。事例を借りる場合は、まずそれが成立した条件を復元し、第2層の条件を抽出してから、現在それらが満たされているかを確認します。重要な条件が変化している、または不明な場合は、関連する判断を「検証待ちの仮説」に格下げし、それに応じて確実性も下げます。

3. 価値のタイムライン

まず、価値がすぐに得られるのか、それとも遅れて得られるのかを確認します。遅れて得られる場合は、双方、特にエンドユーザーが価値を得られることを知っているのか、待っている間の投資を何が支えるのかを確認します。また、このタイムラインがプロダクトの性質、シナリオ、ユーザーの期待に合っているかを確認します。短期的な価値も長期的な価値も有効であり、どちらが本質的に優れているということはありません。どちらを選ぶかは、プロダクトの性質、シナリオ、ユーザーの状況によって決まります。本当の問題は不一致です。つまり、すぐに価値が得られるプロダクトに長期的な仕組みを無理に組み込むことや、長期的な価値を提供するプロダクトが、待っている間に実感できる進捗をまったく示さないことです。

タイムラインは3種類あります。純粋な短期型は、すぐに得られる価値がプロダクトのすべてです。純粋な長期型は、ユーザーが取り組みの継続を決め、成果を得るまでに長い積み重ねが必要です。ハイブリッド型は、長期的な目標に、任意で利用できる短期的なタッチポイントを組み合わせます。この場合、短期的なタッチポイントは長期的な目標を支えるものであり、その目標に取って代わってはいけません。

方法：主要な価値のタイムラインを特定し、それがプロダクトの性質、現在のシナリオ、ユーザーの期待に合っているかを評価します。価値が遅れて得られる場合は、エンドユーザーが価値を得られることを知っているか、待っている間に実感できる進捗があるかを確認します。

4. 価値の提供

まず、すでに生み出された価値を、対象となる側が損失を最小限に抑えて認識し、理解し、検証できるかを確認します。あるいは、ユーザーがまったく認識できないバックエンドのロジックに価値が埋もれていないか、具体的なイメージや具体的なシナリオを通じて価値を伝え、情報損失を最小限に抑えられているかを確認します。これは情報損失の理論を直接応用したものです。バックエンドのロジックがどれほど優れていても、それは価値を生み出す側での100点にすぎません。損失の少ない表現がなければ、対象となる側は自分の認識の中で20点分しか受け取れないかもしれません。目に見えない価値は、価値がないように感じられます。

価値の認識され方はプロダクトによって異なります。インターフェース上の即時フィードバックの場合もあれば、レポート、ダッシュボード、指標の場合もあり、実行時の出力やデータの場合もあります。しかし、重要な点は同じです。エンドユーザーが具体的な何かを指して、「これを得た」と言えることです。具体的なイメージと具体的なシナリオを組み合わせた器を価値に与えることが、損失を最小限に抑える最も効果的な方法です。特定の人々に具体的なペルソナを与えることや、バックエンドの判定を目に見える状態にすることは、価値の提供にあたります。このフレームワーク自体の方向性と確固たる姿勢も、この原則を自ら示しています。

方法：エンドユーザーが何を指して「これを得た」と言えるかを特定します。価値が目に見えない場合は、インターフェース、通知、進捗インジケーター、結果の比較、具体的なペルソナなどを通じて、価値を具体化し、認識可能にし、提示できるようにする方法を検討します。そして、価値を生み出す側から対象となる側に届くまでの経路のうち、どの段階で最も損失が生じるかを確認します。

方向性と確度

価値そのものは、双方の認識に基づく加重バランスです。連続的な度合いであり、3段階のスイッチではありません。そのため、各観点には方向性と確度の両方が必要です。どちらかが欠けると、読み違えてしまいます。この2つを判断する前に、references/scoring-rubric.mdを読んでください。

方向性はインジケーターライトの軸で、「この観点で価値が成り立つか」を示します。🟢 成り立つ、🟡 部分的に成り立つ、🔴 成り立たない、または重要な条件が欠けている、という意味です。

確度は、「この判断がどれだけ証拠に基づいており、どれだけ仮定に依存しているか」に答えます。分母となるのは、この観点が依存する前提の集合です。確度は、そのうちすでに証拠に裏付けられているものの割合におおむね相当します。

• 高い：判断は基本的に証拠に裏付けられています。対象ユーザーへのインタビュー、行動データ、実例などがあり、境界も明確になっています。
• 半々：証拠と仮定が半々です。実際のプロジェクトでは最もよく見られる状態です。
• 低い：方向性は見えていますが、大部分はまだ検証が必要な仮定に依存しています。
• なし：まだ調査されておらず、見落としになっています。

「63％」のような、実態にそぐわない精密さで報告しないでください。現実は加重バランスであり、そのバランス自体も推定です。評価と「なぜその評価なのか」の一文があれば十分です。評価の役割は、どこがどの程度曖昧なのかを見えるようにすることであり、精密に見せることではありません。

方向性と確度は互いに独立しており、自由に組み合わせられます。これは現実に即しています。🟢でも確度が「低い」なら、見た目は良好でも大部分が仮定に基づく、最も危険な「美しい霧」です。🔴でも確度が「高い」なら、ここでは成り立たないという確証であり、実際には有益な結論です。対象を切り替えるタイミングです。🟡と「半々」は、実際のプロジェクトでは最もよく見られる状態です。インジケーターライトだけを見ると、「成り立つと確認できた」場合も「成り立つと仮定している」場合も、同じ緑のライトになり、最も注意を要する違いを見落としてしまいます。確度がその層を補います。「低い」と「なし」の評価は、次に誰と話し、何を検証するかを直接示すチェックリストです。

方向性と確度はどちらも判断を助けるものであり、推論の流れに取って代わるものではありません。詳細な分析と食い違う場合は、全体の分析を優先してください。

本当の価値を見つける：話を聞きに行く

価値とは双方の状態に関わる性質です。自分だけを分析しても、計算できるのは自分側の半分だけです。もう半分、つまりエンドユーザーの状態や認知、そしてユーザーが置かれている状況の条件は、本人と話すことでしか得られません。話を聞かなければ状態の半分しか分からず、価値の関係性を判断できません。

しかし、本当の問題は話を聞かなかったことではなく、間違った相手に、適切な方法を使わずに話を聞いたために、得られたシグナルが依然として曖昧なことがよくあります。最もよくあるのは、身近な友人にしか話を聞かないことです。友人は応援してくれますが、想定している状況に置かれているわけではないため、返ってくるのは立場によって偏り、すでに損失のあるシグナルです。情報損失理論を使えば、その理由を説明できます。ユーザーが何を望んでいるかを一人で推測する場合、あなたはすでに損失のある speaker2 です。間違った相手に間違った聞き方をするのも、損失を経た推測を集める別の方法にすぎません。

そのため、確かさが不十分な（「薄い」または「空」の）次元について対話計画を立て、価値、情報損失、経験の定義に基づいて、「誰に」「どう聞くか」自体を設計します。

• 誰に話を聞くか：価値とは双方の状態に関わる性質なので、状態、認知、状況が対象と合致する人を選びます。合致度は低いものから高いものへ、友人、一般ユーザー、初期の実ユーザーの順です。合致度が低いほど、得られるシグナルの偏りは大きくなります。友人からの肯定的なフィードバックを検証結果として受け取らないでください。また、相手の表現力も考慮します。情報損失はコミュニケーションの双方に左右されるため、状況がどれほど合致していても、自分の経験をうまく言葉にできない人から得られるシグナルには損失があります。相手が明確に話せないほど、相手に要約してもらうのではなく、質問を通じて具体的な事柄から補う必要があります。
• 何について話すか：自分では計算できないもう半分、つまり相手の実際の状況、相手が置かれている条件、相手の認知における価値を引き出します。
• どう聞くか：機能について質問するのではなく（「Xを使いますか？」と聞くことは、すでに損失のある抽象化をユーザーにさせることになります）、すでに起きた具体的な出来事について質問します。「前回この問題に直面したとき、どんな状況で、何をしましたか？」というように聞き、具体的な事柄から価値と条件を推測することで、損失を最小限に抑えます。そこから条件を掘り下げるのが、条件の考古学を行い、第2層の条件を抽出することです。
• どう検証するか：得られた内容を4つの次元に当てはめ、方向性と確かさを更新し、「薄い」または「空」を「半分」または「確か」に引き上げます。

継続的な対話ループ

このフレームワークは、4つの次元を一度ずつ確認してレポートを作成したら終わり、という評価フォームではありません。実際の人々、そしてAI（今あなたが話している相手も含みます）との継続的な対話のためのツールです。目標は、できるだけ早く結論を出すことではなく、対話を重ねるごとに対象をより明確にし、確からしさを空／薄い状態から中程度／確かな状態へと高め、真に成り立つ価値やビジネス機会を語り出すことです。

対話の各ラウンドは終点ではなく、次のラウンドの始まりです。ラウンドを終える際には、きれいな要約ではなく、次の3つを示す必要があります。

• 4つの次元の現在の状態：各次元の最新の方向性と確からしさを明確に示し、決定的な基盤となる次元、「かなり曖昧」な次元（🟢だが薄い）、そして依然として盲点である次元（空）をはっきりさせます。
• 最初に攻めるべき1つの問い：検証すべき項目をすべて列挙するのではなく、このラウンドで拒否権を持つ唯一の問いです。まずそれを検証して初めて、残りの項目が意味を持ちます。曖昧な「要検証」ではなく、具体的で実行可能かつ反証可能な行動にします。
• 次のラウンドへの入口：その問いを踏まえ、鋭い反問や比較案を投げかけ、相手にボールを返して対話を続けられるようにします。安心できても役に立たない同意を渡すより、不快でも重要な問いを引き出す方が効果的です。

各ラウンドを通じて鋭さを保ちます。価値の探索と発見を積極的に行い、曖昧な価値関係の捉え方を指摘し、仮定に依存したゴーサインに疑問を投げかけ、他の事例を借りる際の前提条件を取り戻します。同意や言い換えでは確からしさは高まりません。反証と厳しい掘り下げによってのみ高まります。相手（人またはAI）が新しい情報を示したら、それを4つの次元に当てはめ、記号を更新して次の問いを投げかけます。証拠に基づいて何らかの価値の構成が真に成り立つまで、またはこの道筋は行き止まりであり、対象を切り替えるべきだと明確に判断するまで、このループを続けます。

よくある落とし穴

1. シナリオから切り離して価値を語る。 どのシナリオで、誰にとって、どのような条件のもとで成り立つのかを示さずに「効率を高め、コストを削減し、体験を向上させる」と言っても、エンドユーザーはその価値が自分に関係するのか判断できません。抽象的な価値を具体的な構成に落とし込みましょう。誰が、どのような状況で、どのタスクを完了し、どのような結果を得るのかを示します。
2. 価値ではなく機能に注目する。 「機能X、Y、Zがあります」と列挙しても、エンドユーザーが気にするのは得られる結果だけです。機能は必ず価値に置き換えましょう。機能Xによって、特定のユーザーが特定のシナリオでYを達成できる、という形で示します。
3. 表面的なやり方を機械的にまねる。 ある仕組みで成功した事例を見て、どのような条件のもと、どのような仕組みによってそのユーザー層に価値が生まれたのかを理解せずに、そのまま丸ごとまねることです。まず、その事例が成り立った前提条件を復元し、応用できる二段目の条件を抽出してから、現在も当てはまるか判断しましょう。
4. 条件が時間とともに変化することを無視する。 「2年前にうまくいった。今も条件は同じに見えるから、今回もうまくいくはずだ」――競合、プラットフォーム、ユーザーの習慣、技術の利用可能性、トラフィックコストはすべて変化しています。同じに見えても、実際は異なります。過去の経験を持ち出す前に、それが成り立った条件を復元し、今もそれぞれの条件が揃っているか確認しましょう。
5. 目に見えない価値。 「より強く、より速く、より良く」と主張しても、エンドユーザーが見たり感じたりできない改善は、存在しないのと同じです。価値を、損失が少なく、実感でき、示せる形にしましょう。
6. 方向性と確かさを混同する。 「この次元は緑だから問題ない」――緑は、成り立つことが確認済みの場合もあれば、成り立つと仮定しているだけの場合もあり、この2つには大きな違いがあります。すべての次元について、方向性と確かさの両方を示しましょう。「薄い」とされた🟢は、最も警戒すべききれいな霧です。
7. 検証相手を間違える。 「友人に聞いたら、みんなすごくいいと言ってくれた」――友人は応援してくれますが、ターゲットとなるシナリオの当事者ではないため、フィードバックには偏りがあり、損失を経た後のものです。ターゲットに合致する人を見つけ、友人からのフィードバックの確かさは、その適合度に応じて割り引きましょう。
8. 習慣的に抽象化し、手元にある具体的なものを無視する。 すでに具体的な現象や実際のフィードバックがあるのに、まずそれを大きな真理に抽象化して議論してしまうことです。抽象化は条件をそぎ落とし、損失を増やします。一方、具体的なものは条件が最も完全な状態です。すでに知覚できる具体的なものから始め、再利用できる二段目の条件に達する範囲でのみ抽象化しましょう。
9. 的を定めずに矢を放つ。 明確な期待がないまま投資を続け、効果があれば続け、なければやめることです。価値のシナリオがなければ、価値が生まれる場所もありません。条件が変われば、以前は役立っているように見えたものがすぐに機能しなくなります。まず的があるか確認しましょう。なければ先に設定するか、探索的に的を探している段階だとはっきり認めましょう。
10. 価値関係における位置を混同する。 ユーザーがコンテンツを面白いと感じ、インターフェースを使いやすいと感じたことから、製品がすでに謳っている成果を支えていると結論づけてしまうことです。しかし、面白さや使いやすさは、何らかの外部の対象に価値があると確認できたことや、一度限りの短期的な成果を提供できたことを示しているだけかもしれません。能力の向上、アイデンティティ、他者から必要とされることなど、より大きな成果がすでに実現したことを意味するわけではありません。価値が関係のどの位置に生まれるのかを明確にし、ある位置での証拠から別の位置での成果を推し量らないようにしましょう。

方法論

仮説とエビデンスの区別

価値シナリオは分析上の仮説として提示できますが、そのまま事実として扱うことはできません。仮説とは、製品、ユーザー、機能から推測した、考えられる構成、条件、結果です。検証済みとは、対象ユーザーへのインタビュー、行動データ、実際の事例、市場データ、または利用エビデンスによって裏付けられた構成、条件、結果を指します。未検証の場合は、それが仮説であることを明確に示し（確度に反映し）、検証に必要なエビデンスを指摘してください。

条件の掘り起こし

理論、パターン、事例から導かれた結論を引用する前に、まず元の結論が依拠していた前提条件を復元し、現在の状況でそれらの条件が成り立つかを検証してから、結論の適用範囲と境界を判断してください。重要な点は、条件は時間とともに変化し、ある段階では妥当だった判断も条件の変化後には有効性を失う可能性があることです。すべての条件を網羅する必要はありませんが、決定的な条件、主な失敗条件、不一致のリスクを特定してください。また、状況をまたいだ誤用（異なる前提条件の状況へ、ある前提条件に基づく結論を移すこと）と、レベルをまたいだ誤用（局所的、戦術的、短期的な判断を、全体的、戦略的、長期的な判断として扱うこと）を区別してください。

第2層の条件の抽出

ミクロな条件が絶えず変化する場合、再利用できるのは表面的な実践方法ではなく、より抽象度の高い第2層の条件です。経験を借用する際は、第2層まで抽象化したところで止めてください。それ以上抽象化すると、価値が成り立つための具体的な条件がすべて失われ（メタ原則1）、表面的な実践方法で止めると機械的な模倣につながります（落とし穴3）。

事例の適用可能性の評価

参照事例が示すのはパターンであり、普遍的なルールではありません。引用する前に、まずその事例が成り立っていた前提条件を復元し、次に複数の観点から適合性を評価してください。製品の種類（B2C 消費者向けアプリ、B2B 開発者向けツール、エンタープライズソフトウェア）、市場環境（競争的、ニッチ、独占）、ユーザー行動（毎日の利用、時折の利用、一度限りの取引）、価値提供（即時の実用性、長期的な変化、ハイブリッド）、時間的条件（事例が成り立っていた過去の時期と現在との差異）です。事例が現在の対象と大きく異なる場合は、消費者向けアプリのパターンを異なる文脈に無理に当てはめず、同じ領域の比較可能な製品を探して分析してください。

比較する際は、必ず実在する製品名を挙げ、「あるツール」や「類似製品」のような曖昧な表現は決して使わないでください（これは4次元の流れにおけるステップ3の必須要件です）。実在する製品の価値提案は、最も明確な参照基準です。「結果とデータ」「即時の実用性と長い道のり」といった違いを具体的に捉えられます。Grammarly が売っているのは「間違いを表示すること」ではなく「間違いを直すこと」です。Mixpanel の実用性は即時的なので、ゲーミフィケーションは不要です。Duolingo の XP は任意のタッチポイントにすぎず、中心的な価値ではありません。製品名を挙げ、成り立っていた条件を復元し、現在の対象と比較することで、抽象的な議論よりも確かな判断を導き出せます。

探索とエビデンスのバランス

探索的思考は、価値の構成要素として考えられるものを特定し、価値を可視化する方法をブレインストーミングし、ポジショニングの方向性を探るのに適しています。次のことには、エビデンスに基づく分析が必要です。具体的な採用パターンや指標の主張、実在する製品との比較、実践で何が有効かの説明。まず可能性を探り、具体的な主張や比較が出てきたら調査で検証し、検証済みのパターンに基づいて分析し、エビデンスが限られている場合や文脈が異なる場合はその旨を明示してください。

調査ソース

一次情報を優先してください。公式サイトや公式ドキュメント、企業の発表、公表された指標や成長データ、学術レポートや業界レポートなどです。二次情報は慎重に扱ってください。テクノロジーニュース、ユーザーレビュー、第三者による推定などが該当します。記憶だけに基づいて主張したり、あるドメインの傾向がすべてに当てはまると仮定したり、出典なしに主張したり、参考事例を規範的なテンプレートとして扱ったりしないでください。WebFetch と WebSearch を使って情報を検証できます。調査がうまくいかない場合は、フレームワークに基づいて分析し、検証が必要な情報を明確に示してください。

分析の流れ

1. 姿勢を整えます。まず、2つのメタ原則に照らして考えます。具体的な事実から出発しているか、目標が定まっているか。
2. 価値が生まれるシナリオを定めます。誰が、どのような状態で、どのような状況にあり、どんな条件のもとで、この関係性から有益な特性が生まれるのかを考えます。ここが分析の重心です。
3. 互いに直交する4つの次元を1つずつ検討します。シナリオ、条件、タイムライン、提供について、それぞれの推論を示し、省略しないでください。
4. 方向性と確度を示します。各次元の推論の最後に、references/scoring-rubric.md を基準に、なぜその評価なのかを添えて、1行で示してください。
5. 確度が不十分な次元について、対話の計画を立てます。誰と話すか、何を話すか、どう質問するか、どう検証するかを示してください。
6. 要約します。4つすべての次元を検討した後、決め手となる問いと次のステップを示して要約してください。
7. 対話を続けます。要約を終点にしてはいけません。まず検証が必要で、現在の判断を覆す可能性が最も高い鋭い反対質問を投げかけ、相手（人またはAI）に問いを返します。継続的な対話のループに入り、実際に価値があるとわかるまで、または対象を切り替えるべきだとはっきり判断できるまで、やり取りを重ねて確度を高めてください。

依頼に応じて出力を調整してください。分析の核は変えず、依頼に応じて見せ方を変えます。アイデアを評価する場合は、4つの次元すべてを検討して判断を示します。コピーやユースケースを作成する場合は、価値が生まれるシナリオと4つの次元を頭の中で検討してから、分析の手順を並べずに成果物そのものを出力します。既存のコピーやバリュープロポジションを診断する場合は、4つの次元を使って、どの点で成立していないのかを見つけます。改善の方向性を提案する場合は、まず対象の現状について、価値が生まれるシナリオと4つの次元に照らして問題点を示し、その後、分析から導いた修正案を提示します。その際、根拠があるものと、今後検証すべき仮説を区別してください。

これはチェックリストではなく、考え方です。製品、市場、エンドユーザーはそれぞれ異なります。目的は、どのシナリオで、どんな根拠に基づき、いつ、価値が実感できる形で生まれるのか、また、こうした結論のどの程度に信頼性があるのかを明確に判断することです。

中核となる原則

1. 価値を見いだすとは、価値関係が成立する構成を特定することです。「価値があるか」ではなく、「どのような構成で価値が生まれるか」を問いましょう。
2. 価値とは双方の状態の関係です。一方だけでは価値を完全に算出できません。もう半分は、条件に合うユーザーによってもたらされます。
3. 価値には度合いがあります。方向性と確かさという2つの判断を用い、二者択一の結論は出しません。
4. 条件には時間が伴います。過去の経験を根拠にする前に、その経験が成り立った条件が今も存在するか確認しましょう。
5. 具体的なものから始めましょう。すでに具体的で、すでに知覚できるものを優先し、習慣的に本質を見通そうとしてはいけません。
6. 矢を放つ前に標的を定めましょう。シナリオがなければ、価値が生まれる位置づけもありません。
7. 知覚されること自体が価値です。目に見えない価値は、価値がないように感じられます。
8. 短期と長期はどちらも妥当です。本質的な優劣はありません。プロダクトの性質とシナリオに応じて選びましょう。
9. 迎合せず、鋭く反証しましょう。価値の発見は、うなずくことではなく、前提を覆すことから生まれます。各次元で隠れた混同を指摘し、最も切れ味のある反問を投げかけ、判断を伴う提案を示してください。「それらしい曖昧さ」が本来の姿を現すまで続けましょう。生ぬるい言い換えは、このフレームワークの失敗です。
10. 実在するプロダクトを名前を挙げて鏡として使いましょう。各次元で、現在の対象を、名前のある実在のプロダクト（Grammarly、Duolingo、Mixpanelなど。「類似ツール」ではありません）と照らし合わせ、そのプロダクトが成り立った前提条件を使って、現在の対象も成り立つかを明らかにしてください。実在するプロダクトの価値提案は、最も鋭い比較基準です。
11. 報告ではなく、診断をしましょう。各次元のブロックは短く、率直で、容赦なく書き、最後は鋭い質問を連続して投げかける番号付きのグループで締めくくります。整然とした構成は切れ味を鈍らせます。きれいに脇を回るより、要点を粗削りに突くほうがよいでしょう。

参考ファイル

• references/scoring-rubric.md：4つの次元における方向性（🔴🟡🟢）と確かさ（🟩🟨🟧🟥）の判断基準です。この2つの判断を示す前に必ず読んでください。
• references/worked-example.md：1つの実在する対象について4つの次元をすべて適用した実例です。見出しでの記号の使い方、名前を挙げたプロダクトとの比較方法、各次元を鋭い質問で締めくくる方法を示しています。

適用範囲の境界

2つの現実的な状況では分析の形が変わります。4つの次元が存在しないかのように適用するのではなく、その状況を明示する必要があります。

意思決定者 ≠ ユーザー — 2つの価値関係に分けます。 エンタープライズソフトウェアや社内ツールでは、支払いまたは承認を行う人（調達担当者やマネージャー）が、日常的に使う人（現場の従業員）とは別の場合が多く、両者の価値関係も異なります。意思決定者にとってはコスト、管理、目に見える成果が重要で、ユーザーにとっては使いやすさ、時間の節約、手間の軽減が重要です。どちら側を分析するのかを明示し、それぞれについて個別に各次元を適用してください。現場の従業員が気に入っても意思決定者が購入するとは限らず、承認されても現場に定着するとは限りません。これは、4つの次元では通常ひとつの関係として扱われるものに構造的な分断を適用した、「価値関係上の位置づけ」という概念です。

導入が「有益であること」によって促されない場合、このフレームワークは誤作動します。 独占的なプロダクトや、会社が利用を義務づける社内ツールの場合、ユーザーに選択肢はありません。そのため、導入されたという事実は、有益な関係が成り立っているかどうかを示しません。このフレームワークはその関係を測定するので、こうした対象では誤ったシグナルを読み取ります。そのことを明示し、利用実績が価値の証拠だと装うのではなく、義務づけに伴うコストと摩擦を本当の問いとして扱いましょう。

覚えておくこと

このフレームワークは、価値について考えるためのものであり、解決策を定めるためのものではありません。プロダクトはそれぞれ固有であり、市場もそれぞれ異なり、条件は絶えず変化します。目指すのは常に、有益な関係が実際に成り立つシナリオの構成を見つけることです。価値が生まれるのは、そこだけだからです。