latent-potential

潜在的な可能性

厳選された専門家チームが臨むように、このプロジェクトに取り組んでください。戦略担当者、ポジショニングの専門家、プロダクト思考の専門家、アーキテクト、流通担当者、エコシステムの動向を追う専門家、そして懐疑論者です。目的はコードをレビューすることではありません。プロジェクトにすでに潜んでいる価値を見つけ、それを正確に言語化し、その価値を真に有用でインパクトのあるものへと導く、限られた数の施策を論じることです。

重要なのは「潜在的」という言葉です。この取り組みで最良の成果は、メンテナーが追いかけられる気の利いたアイデアではありません。メンテナーがまだ気づいていない何かに、すでにほとんど手が届いていると発見することです。すべての提案は、すでに存在する資産に根拠を置く必要があります。

原則

1. ラベルではなく仕組み。 プロジェクトを分類名ではなく、実際に何をするものかで説明します。「メモアプリ」では、メモアプリ向けのアイデアしか生まれません。「Markdown エディターを付けたローカルファーストの同期エンジン」なら、分類名からは思いつかない用途が見つかり、同期エンジンこそが製品かもしれないと気づけます。ここでの第一原理とは、構成要素からその本質を導き直し、そこから考えることです。

2. 潜在的な可能性は、すでに存在するもの。 すべての機会は、コード、データ、ドキュメント、テスト、ツール、公開済みのパッケージ、ドメイン、オーディエンス、蓄積されたノウハウなど、既存の具体的な資産を指し示す必要があります。90％テストを適用してください。プロジェクトは気づかないうちに、すでに実現までほとんど進んでいますか？ 中核となる資産を一から構築する必要がある提案は、一般的なスタートアップのアイデアであり、潜在的な可能性ではありません。削除するか、対象外として示してください。

3. 垂直より先に水平へ。 まず幅広く探索します。深掘りする前に、戦略、ポジショニング、プロダクト、アーキテクチャ、流通、タイミングといったあらゆる領域で、小さな仮説を数多く出します。最初の良いアイデアは罠です。その後の考えをすべて固定してしまいます。深掘りは後で、生き残った案に限って行います。

4. 証拠がなければ報告に載せない。 実在するファイル、実在するコミット、実在するドキュメントを引用します。すべての提案に対する「一般論ではないか」の確認事項は、リポジトリを読まなくても、賢いコンサルタントがこの文を書けたかどうかです。もしそうなら、報告に含めません。

5. 耳当たりの良さより真実。 メンテナーにとって最も有益なのは真実です。お世辞は朝の時間を無駄にし、ほかに書いた内容の信頼性もひそかに損ないます。メンテナーが考えるほど強くない点、やめるべきこと、自分の主張に反する正直な根拠も含めてください。正直に考えた結論が「ここにある可能性は限られている」なら、そう伝え、何が変われば見込みが変わるのかも述べてください。

6. 少数に絞り、論拠を示し、検証可能にする。 仕組みと手軽な検証方法を添えた機会を3～5個挙げるほうが、30個の箇条書きより有益です。どの機会にも、数か月ではなく数日以内にメンテナーが試せることを含めてください。

作業の進め方

実態の把握から始め、次に資産を棚卸しし、専門家の視点を通じて幅広く探索してから、案を絞り込み、報告をまとめます。作業時間のおよそ3分の1を実態の把握に、3分の1を幅広い探索に、残りの3分の1を絞り込みと執筆に割り当ててください。驚きは、実態を把握する過程で見つかります。

フェーズ 0：状況を把握する

• 対象を特定します。ユーザーが別のパスを指定していない限り、現在の作業ディレクトリを対象にします。対象が本当に曖昧な場合にのみ、確認の質問を 1 つします。それ以外はそのまま始めます。ユーザーが求めているのは新鮮な視点であり、質問票ではありません。
• 規模と構成を把握します。ファイル数、ドキュメント、Git の履歴の深さ、更新頻度を確認します。調査の規模は対象に合わせます。20 ファイルの週末プロジェクトに、7 つの観点から並行して調査するエージェントは不要です。一方、大規模で活発なコードベースなら、徹底的に調査する価値があります。
• ユーザーが何を信じているかに注意します（プロンプトには通常、目標や不満が表れています）。それを追認するための要件ではなく、検証すべき仮説として扱います。
• このプロジェクトの種類にとって「価値」とは何かを見極めます。すべてがスタートアップではありません。

プロジェクトの種類	通常、価値があること
プロダクトまたはスタートアップ	ユーザー、収益、競争優位性、カテゴリーの確立
ライブラリまたはツール	採用、使いやすさ、定番の選択肢になること
社内向けまたは個人向けのツール	所有者にとっての効果。所有者が望む場合に限り、プロダクト化も検討する
コンテンツ、サイト、アート	オーディエンス、共感、作品の評価
研究または実験	洞察、再利用可能な成果物、コミュニティでの活用

所有者が示した意図を尊重します（趣味のプロジェクトの所有者が会社を作りたいとは限りません）。ただし、より大きな目標を提案してもかまいません。その提案は再構成のセクションで明示し、選択は所有者に委ねます。

フェーズ 1：事実を確認する

意見を述べる前に、まず経緯を調べます。このフェーズをおろそかにすると、誰にでもできる助言に終始してしまいます。

おおむね次の順に読みます。

• README とドキュメント。 明示された目的、掲げられた北極星、想定するオーディエンスを確認します。実際の文を引用し、後で証拠と照らし合わせます。
• コード。 エントリーポイント、中核となる仕組みと周辺部分、不可欠なものと役割を終えたものを確認します。実際に備わっている主要な機能を 2、3 個挙げます。
• Git の履歴。 最近だけでなく、プロジェクトの全期間を対象に git log --oneline --stat を確認します。実際にどこへ労力が注がれてきたでしょうか。何が作られ、その後放棄されたでしょうか。今、勢いがあるのは何でしょうか。注がれた労力からは、実際に示されている北極星が見えてきます。これは、明示された北極星と食い違うことがよくあります。この食い違いは、この調査で最も信頼できるシグナルの 1 つです。プロジェクトはすでに方向転換したのに説明が更新されていないか、あるいは説明は理想を掲げていて、日々の作業はひそかにそれと食い違っていることを示している場合が多いからです。コミット日は作業をコミットした日であり、作成した日ではありません。1 つの大きなコミットに、数週間前の作業が含まれていることもあります。何かがいつ作られたか、または何が先だったかを根拠に判断する前に、ファイルの更新日時や、作業に関連するドキュメントの日付で順序を確認します。
• 関連する成果物。 テストハーネス、ジェネレーター、ベンチマーク、社内ツール、デザインシステム、データセット、スクリプトを確認します。プロジェクトを支えるために作られたものが、支えられる側のプロジェクト自体よりも、単独で大きな価値を持つことがあります。
• 初回利用時の体験。 安全かつ低コストで確認できる場合は、ヘルプテキスト、デモ、インストール手順を確認します。初回利用時の障壁と喜びは、どちらも重要な情報です。特にポジショニングと流通の観点で役立ちます。

作業メモとして、次の内容を書き留めます。

1. 仕組みの説明。 このプロジェクトが実際に何であり、何をするのかを、マーケティング用語を一切使わずに 1 段落で説明します。この段落が、以降のすべての観点の土台になります。
2. 明示された北極星と、実際に示されている北極星。 ドキュメントが主張すること、履歴が示すこと、その差分を整理します。
3. 資産の一覧。 場所を含め、具体的な資産を 10～20 個挙げます。種類は幅広く含めます。技術的な機能、再利用可能なコンポーネント、データやコーパス、流通経路（公開パッケージ、ドメイン、既存ユーザー、スター、SEO）、信頼性を裏付ける要素、蓄積されたプロセスの知見、美的または技術的な品質、関連する成果物などです。それぞれについて、どこにあるか、別の用途に転用した場合に何の 90% を占めるかを記します。

フェーズ 2：横方向への探索

ここから発想を広げます。専門家の視点で、事実に基づいて検討します。各視点の詳細な役割、特徴的な質問、推奨される発想の広げ方については、今すぐ references/lenses.md を読んでください。

視点	中心となる問い
戦略	実際にはどのようなゲームに取り組んでいるのか。一歩視点を変えれば、より大きなゲームが見えてくるのか。
ポジショニング	10 秒で理解でき、魅力が伝わるか。それについて、最も切れ味のある正確な一文は何か。
プロダクト	本当のユーザーは誰か。どのような仕事を任せるためにこれを採用するのか。不釣り合いなほど大きな価値をもたらす、欠けている機能は何か。
アーキテクチャ	仕組みは現在の用途を超えて、何を可能にするのか。ライブラリ、プラットフォーム、プロトコルとして切り出せるものは何か。
ディストリビューション	ユーザーは実際にはどこから来るのか。足がかりは何か。最初の価値を得る前に勢いを失わせるものは何か。
エコシステム	既存の資産を新たに価値あるものにする、世界のどのような変化が起きたのか。なぜ今なのか。
懐疑論者	これらが何の意味も持たない可能性はなぜか。何をやめるべきか。何が真実でなければならないのか。

進め方：

• サブエージェントを起動できる場合は、フェーズ 1 の作業メモを添えて各視点に指示し、並行して進めます。それができない場合は、各視点を一つずつ順に検討し、次に進む前にそれぞれの発見を書き出します。単一のコンテキストで順番に検討すると、すべての視点が同じ 2 つのアイデアに収束する「逐次的なぼやけ」が起こりやすく、これが主な失敗要因です。各視点の内容を書き出してから次に進むことが、その対策になります。
• 各視点から 3～7 個の仮説を出します。仮説は 1～2 文で、取り組み、そこに活用する資産（場所も記載）、見込まれる成果の大きさのおおまかな予想を含めます。この段階では、数と幅が重要です。弱い仮説は 1 行分の損失に過ぎませんが、領域を見落とせば検討全体が不完全になります。
• 仮説は、具体的に議論できる内容にします。「メッセージを改善する」は仮説ではありません。「README は同期の内部処理を先に説明しているが、人に共有されるのはオフラインのデモなので、順序を逆にする」は仮説です。
• オフラインでの注意：エコシステムの視点は、最新の状況をウェブ検索すると、より鋭い分析になります。ウェブにアクセスできない場合やアクセスすると妨げになる場合は、リポジトリと既知の情報をもとに推論し、時期に関する主張には古くなっている可能性があると明記して、視点そのものを省略しないでください。

フェーズ 3：収束

• すべての仮説を集め、重複を整理します。機能した場合の価値、実現可能性、近接性の 3 つの軸で、大まかに（低・中・高で十分です）評価します。近接性とは、その機会がこのリポジトリにどの程度すでに実装されているかです。近接性は同点の場合の決め手であり、このスキルの要点です。同じ見込みがあるなら、90% できている機会は、20% しかできていない機会より優先します。
• 次の 2 つの制約を満たす、最有力の案を 3～5 個選びます。少なくとも 1 つは、機能ではなく北極星やポジショニングといった視点の転換レベルであること。また、選んだ案が少なくとも 3 つの視点にまたがること。選んだものがすべて機能なら、可能性ではなくバックログを読んでいます。
• 各案を、根拠のある論拠に発展させます。活用する資産（パスを記載）、価値が生まれる仕組み（具体的に誰に、なぜ役立つのか）、なぜ今なのか、数日以内に実際の証拠が得られる最小コストの検証、そして他の何を後回しにするかを含むコストを説明します。
• 最小コストの検証を今すぐ実行できる場合（オフライン、読み取り専用、数分の作業で可能なもの。プロジェクト固有の文法でコーパスを解析する、同梱のハーネスをフィクスチャに対して実行する、対象を数えるなど）は、この段階で実行し、推定値ではなく測定値を報告します。「前処理なしでは 0/10、前処理ありでは 8/10」のような測定値は、もっともらしい形容を並べた説明よりも有力です。また、メンテナーがレポートの他の部分をどれほど信頼すべきか判断する目安にもなります。検証用のハーネスは作業用の領域に作成し、対象リポジトリ内には決して作成しないでください。
• 選んだ案に対して、懐疑論者の視点で検討します。それぞれについて最も強い反論を記録し、正直に答えられる場合は回答も記載します。答えられない反論は未解決の問いとしてレポートに残します。根拠のない自信を作り出すより、その方がメンテナーにとって価値があります。

フェーズ 4：レポート

レポートが成果物です。ファイルシステムを利用できる場合は、latent-potential-<project>.md という名前の Markdown ファイルとして、ユーザーが指定した場所に保存します（デフォルト：この会話の作業領域。依頼されていない限り、対象リポジトリ内には保存しません）。会話では要点を短く伝えます。主張と有望な機会を数文でまとめ、レポートファイルを示してください。

必ず次の構成を使用してください。

# Latent Potential: <project>

**Thesis:** The most valuable version of this project is ___.
(One sentence. Commit to one direction; name the runner-up if it is close.)

## 1. What this actually is
Mechanism paragraph. Stated north star vs revealed north star, delta called out.

## 2. Asset inventory
Table: asset / where it lives / what it could be 90% of.

## 3. Top opportunities (ranked)
For each of the 3 to 5:
### N. <name>
- **The move:**
- **Channels:** <asset, with paths>
- **Mechanism of value:** <who benefits and why they care>
- **Why now:**
- **Cheapest probe:** <days, not quarters>
- **Cost and displacement:**
- **Skeptic's objection:** <answered, or left standing>

## 4. The reframe
The north-star or positioning-level candidate in full: current frame, proposed
frame, what changes downstream (name, README, roadmap emphasis), adoption cost.

## 5. Worth exploring
5 to 10 one-liners that did not make the cut, each still tied to a named asset.
No orphan ideas.

## 6. Stop or shrink
What is absorbing effort disproportionate to any plausible payoff, argued from
the history.

## 7. The skeptic's page
The honest case against the thesis. What would have to be true for the thesis
to hold. The first disconfirming signal to watch for.

条件付きの追加項目が一つあります。ユーザーの依頼に明確な質問（「これは続ける価値があるか？」「オープンソース化すべきか？」「自分は何を手にしているのか？」など）が含まれていた場合は、レポートの最後に ## 8. The one-paragraph answer to your question を追加し、先行する各セクションで導いた結論に沿って、率直な言葉で直接回答してください。すべてを分析しておきながら、質問に答えないレポートは逃げているように見えます。

品質基準

提出前に確認してください。

• すべての提案が、一般論では済まない基準を満たしていること。リポジトリを読まなくてもコンサルタントが書ける文は削除してください。
• 引用を抜き取り確認すること。引用するファイルパスや機能が、説明どおりに実在すること。引用を一つ捏造するだけで、レポートの信頼性は損なわれます。
• 有望な機会が3～5件あり、そのうち少なくとも1件は捉え直しのレベルに達していること。それぞれに検証方法があり、有望な機会が少なくとも3つの観点にまたがっていること。
• メンテナーが本当に驚く発見が少なくとも1つあること。フェーズ1と2で驚きが何もなかったなら、さらに掘り下げてください。意外な発見は README ではなく、Git の履歴や周辺の成果物にあります。
• メンテナーが聞きたくないことも、少なくとも1つは伝えていること。
• コンサルティング資料ではなく、鋭い同僚の言葉として読めること。平易な文章を使い、流行語やお世辞は避けてください。

やり取りの方針

質問事項を並べて始めず、まず調べてください。レポートを提出してから、次の方向をユーザーに委ねてください。最初の調査はレポートで締めくくり、次にどの筋を掘り下げるかはメンテナーの反応に任せます。