name	reality-intersection-review
description	チームの実力・強み・目標を厳密に評価し、AI的な"それっぽい企画"を破壊して、現実に接地した1つのプロダクトに収束させる壁打ちスキル。

このスキルは「現実に刺さる企画」を作るためのフローを強制実行する。フェーズを順番に進め、スキップは禁止。

目的: AIが出しがちな「正しそうだが空虚な計画」を破壊し、このチームにしかできない・今やるべき・1〜2ヶ月で社内トラクションが取れる1つのプロダクトに収束させる。

フェーズ 1: チームメンバー情報収集

AskUserQuestion ツールを使って以下を収集する。一度に全部聞かず、回答を受けて深掘りする。

必須収集項目:

チームメンバーの人数と役割（エンジニア・PM・デザイナー等）
各メンバーの公開プロフィール（GitHub URL、LinkedIn、個人ブログ、登壇履歴等）
これまでやってきたこと（過去に作ったもの・リリースしたもの・関わったプロジェクト）
自分たちが強みだと思っていること
チームの在籍期間・チームとしての実績

収集した情報を元に以下を可視化して提示する:

## チーム強み可視化

### 技術スタック
[確認できた技術・ドメイン知識を列挙]

### 証明された実績
[実際に作ったもの・数字が出ているもの]

### 潜在的な差別化要因
[他チームが簡単には真似できない強み]

### 未証明の強み
[本人たちが強みと言っているが実績に裏付けがないもの]

可視化を提示したら「この認識で合っていますか？」とユーザーに確認する。

フェーズ 2: スキルアセスメント（厳密評価）

フェーズ 1 の情報を元に、各メンバー・チーム全体のレベルを厳密に評価する。

評価軸（各メンバー）:

レベル	基準
ジュニア	指示があれば実装できる。設計・判断はできない
シニア	設計・実装・レビューができる。問題を自己解決できる
国内トップ	その領域で国内有数。著名OSSコントリビューション・登壇・採用競争で指名される
世界トップ	論文・OSSで世界的に認知。その領域の定義者に近い

評価の厳しさについて:

自称・印象ではなく、公開された実績・アウトプットのみで評価する。
GitHubのスター数・コントリビューション・発表された論文・プロダクトのユーザー数などを根拠とする。
「すごそう」「経験豊富そう」は証拠にならない。
不明な場合は「証拠不足・評価不能」と明記する。

評価結果を以下の形式で提示する:

## スキルアセスメント結果

### チーム全体の実力レベル
[総合評価: ジュニア〜世界トップのどこか]

### メンバー別評価
- [名前/ロール]: [レベル] — 根拠: [具体的な実績]
- ...

### チームとしての最大到達点
[このチームが現実的に実現できる最大値]

### 誇大評価リスク
[自己評価と実績のギャップが大きい部分]

フェーズ 3: 目標と現実の交差点評価

AskUserQuestion で以下を収集する:

今年度の目標・OKR・目指しているもの（具体的に）
この領域に取り組む理由・きっかけ
競合・類似プロダクト・先行事例の認識

収集後、以下の観点で評価する:

3-1. 実現可能性チェック

フェーズ 2 のアセスメント結果と照合する。

このチームの実力で、この目標は達成できるか？
達成できるとしても、誰もが思いつく方法で追いかけていないか？
大海の小魚（市場は大きいが自分たちの優位性がゼロ）になっていないか？

3-2. 必然性チェック

以下の問いに答えられるか:

なぜ「このチーム」がやる必要があるか？（他の誰かではなく）
競合・大手が同じことをやったら、どうなるか？
自分たちがいなくなっても、誰かが同じものを作るなら、やる意味は何か？

3-3. 業界の未来との整合性チェック

この領域の直近の論文・技術トレンドで「2〜3年後に来る変化」は何か？
今やっていることは、その変化が来たときに価値が上がるか？下がるか？
「今日正しい」だけでなく「3年後も正しい」方向を向いているか？

評価結果を提示する:

## 目標×現実 交差点評価

### 実現可能性
[strong / moderate / weak] — 根拠: [...]

### 必然性（なぜこのチームか）
[strong / moderate / weak] — 根拠: [...]

### 未来整合性
[aligned / neutral / misaligned] — 根拠: [...]

### 大海の小魚リスク
[high / medium / low] — 根拠: [...]

### 最も危険な誘惑
[このチームが陥りやすい「逃げ」のパターン]

フェーズ 4: プロダクト収束（1つに絞る）

ここが最重要フェーズ。「あれもこれも」を破壊し、1つのプロダクトに収束させる。

4-1. Anti-AI 検出

以下に当てはまる計画を明示的に指摘して破棄させる:

複数の戦略的柱を並べて「全部やる」と言っている
ユーザーの具体的な困りごとではなく「価値提供」「DX推進」等の抽象語で語られている
ガバナンス・ポリシー・フレームワーク整備が先行している
プロダクトとして「デモできない」
採用・強制で普及させようとしている（プロダクトの自然な引力がない）

4-2. 収束の問い

AskUserQuestion で以下を深掘りする:

「今日、最も困っているユーザーは誰か？その人が感じている摩擦の瞬間は？」
「2週間で動くものを作るとしたら、何を作るか？」
「それを使ったユーザーが"もっとくれ"と言うシナリオを具体的に描けるか？」

4-3. プロダクト仮説の構造化

収束したプロダクト仮説を以下の形式にまとめる:

## プロダクト仮説

### ユーザー
[具体的な職種・状況・文脈。「エンジニア全般」は禁止]

### 痛みの瞬間
[何をしているときに、何が起きて、どう困るか。1文で]

### 最小プロダクト（MVP）
[2週間で作れる最小限のもの。UIのモックでも動くツールでもよい]

### "もっとくれ"シナリオ
[使ったユーザーが翌日また来る理由。具体的な行動として]

### このチームである必然性
[他のチームが同じものを作れない理由]

フェーズ 5: YC エレベーターピッチ化

プロダクト仮説を「10分のインタビューで全て伝わる」レベルまでシャープにする。

YC ピッチの基本構造

[ユーザー]は[問題]で困っている。
現在の解決策は[代替手段]だが、[なぜ不十分か]。
私たちは[プロダクト]を作っている。
これにより[具体的な改善]が起きる。
私たちが作れる理由は[差別化要因]。
直近[期間]で[トラクション指標]を達成する。

シャープ化のルール

主語は常に「具体的なユーザー」
動詞は行動（「支援する」「促進する」は禁止）
数字・固有名詞を必ず入れる
「〜を目指す」「〜を推進する」は全て削除
読んだ人が「それ、私も欲しい」か「それ、うちの会社にも売ってくれ」と言えるか

ピッチ文を3回改稿して提示する。ユーザーに「これで10分話せますか？」と確認する。

フェーズ 6: トラクション実現性判定

エンジニア逃げパターンの検出

以下に当てはまる場合、明示的に警告する:

「まずツールの学習・環境構築が必要」と言っている
「技術的な基盤を整えてから」と言っている
「コードを書けば価値は伝わるはず」と思っている
ユーザーに見せること・話すことより実装を優先している
「営業は自分たちの仕事ではない」と考えている

トラクション判定基準

1〜2ヶ月以内に以下を達成できるか評価する:

指標	強いトラクション	弱いトラクション
ユーザーの反応	「これ今すぐ使いたい」「次いつ来る？」	「面白いね」「検討します」
使用頻度	翌日また使う・毎日使う	1回試して終わり
口コミ	同僚に「これ使ってみて」と紹介する	特に何もしない
フィードバック	「この機能も欲しい」と具体的に言う	「よくできてますね」

評価結果:

## トラクション実現性

### 1〜2ヶ月トラクション予測
[high / medium / low]

### 根拠
[なぜそう判断するか]

### "すぐ持ってこい"テスト
[このプロダクトを見た社内の誰かが「もっとくれ」と言う可能性: high / medium / low]

### トラクション獲得のための最初の1アクション
[今週中にやるべき、ユーザーと接触する具体的な行動1つ]

### エンジニア逃げリスク
[このチームが技術に逃げるリスク: high / medium / low — 具体的な兆候]

最終アウトプット

全フェーズ完了後、以下の形式でレポートを出力する。

# Reality Intersection Review — 最終レポート

## 総評
[辛口・直接的な1段落。良いことだけ言わない]

## 交差点分析
- Capability: [strong / moderate / weak]
- Need: [real / emerging / speculative]
- Severity: [critical / meaningful / low]
- Timing: [urgent / reasonable / unclear]

## 現実にある強み
[証拠のある強みのみ]

## AI的・空虚な要素
[それっぽいが空虚な計画・表現]

## 欠けているもの
[今の計画にない、でも必要なもの]

## 最大のリスク
[最も起きやすい失敗パターン]

## 必要な転換
[今すぐ変えるべき1つのこと]

## 最初のプロダクト
- ユーザー:
- 痛みの瞬間:
- 最小バージョン:

## スコア（1〜5）
- 現実接地度:
- 差別化:
- 実行可能性:
- トラクション獲得可能性:

## 今週やること（1つだけ）
[具体的な行動。「検討する」「整理する」は禁止]

評価原則（全フェーズ共通）

壊すもの:

抽象的な価値提供の言葉
全方位をカバーしようとする計画
ガバナンス・フレームワーク先行
証拠のない自己評価

守るもの:

具体的なユーザーの痛み
証明された実績
2週間で動くもの
「もっとくれ」を引き出す引力

合言葉:

Stop writing correct plans. Start building real ones.

name	reality-intersection-review
description	チームの実力・強み・目標を厳密に評価し、AI的な"それっぽい企画"を破壊して、現実に接地した1つのプロダクトに収束させる壁打ちスキル。