verify-project

実装が終わったプロダクトに対して、「作ったものを評価する」ための検証 と ピッチ発表の準備 を同じ流れで行うスキル。成果物は projects/<プロジェクト名>/verification.md。

目的

• Claude Code で速く作れる時代だからこそ、「動くもの」と「本当に課題を解けているか」を参加者自身の目で確かめる時間を作る
• 検証の過程で気づいたことを、そのままピッチ発表の骨子として残す
• ペアフィードバックで「触ってもらう」ではなく「verification.md を元に3分ピッチを相互にやる」リハーサル素材にする

前提

起動時に .claude/skills/workshop-premises.md（標準構成）を読み、時間枠・技術・成果物・有料 API の扱いはそれに従う。このファイル内には固定値を置かない。前提ファイルが見つからない場合は、標準構成（1日完結・Next.js・デプロイなし・成果物は動くアプリ + LP）を前提にして進める。あわせて .claude/skills/conversation-principles.md（対話の共通原則）も読み、聞き方・書き方・ファイルの扱いはそれに従う。

書き出し先

• projects/<プロジェクト名>/verification.md

起動時のふるまい

1. 対象プロジェクトのディレクトリを確認（現在地 or 参加者に聞く）。確認できたら progress.log に start 行を追記する（共通原則 14。書き出し時は write 行）

2. input.md と scope.md を読んで文脈を把握する。apps/<アプリ名>/README.md があれば起動手順を確認し、次の案内に添える

3. 最初に、このスキルの目的と流れを伝える（参加者が「何のために・何を聞かれるか」を先に把握できるようにする）：

   「これから、作ったプロダクトを 『動く』ではなく『課題を解けているか』の目で検証 して、その内容をそのままピッチの骨子（verification.md）にします。1問ずつ聞くので、自分の言葉で答えてください。私は代筆しません。

   聞くことは6つです：

   1. ワンライナー — このプロダクトを一言でいうと
   2. 課題と解決策の再確認 — 最初の想定とずれた点、特に効いた機能
   3. デモシナリオ — 想定ユーザー1人と、その人が使う流れ
   4. 作り方と、公開するなら変える点 — 前提の中で自分が決めた作り方。世に出すなら何を変え、何は変えなくてよいか
   5. 限界と次の一手 — できていないこと、時間があれば足すこと
   6. 最終整形 — 3分で話せる形に整える

   各セクションが終わるたびに verification.md に書き足していきます。途中で『触ってみてください』と何度も戻しますが、それが検証の本体です」

4. 続けて、以下を必ず促す：

   「まず自分のプロダクトを起動して（起動手順: apps/<アプリ名>/README.md）、1〜2分触ってみてください。input.md に書いた課題文を見ながら、『この課題を本当に解けているか？』と自問してみてください。触り終えたら、気づいたことを何でもいいので教えてください」

   参加者の気づきをメモして、以降の対話で引用する。

対話の大原則

共通原則（1問ずつ・代筆しない・逐次書き出し・実物を触らせる・「Claude Code に書かせればいい」への対応）は conversation-principles.md に従う。このスキル固有の原則：

• 「触ってみて」の基準は input.md の課題文。「動く」ではなく「この課題を本当に解けているか」を実物で確かめさせる
• 「ずれ」と「限界」は発見として歓迎する。当初の想定と違った点、できていない点を正直に挙げるほどピッチの説得力が増す、というトーンで聞く
• verification.md はそのままピッチ原稿になる。参加者が 声に出して3分で話せる言葉 で残す

---

Phase 1: ワンライナー

質問1

「あなたのプロダクトは、誰のどんな課題を解くものですか？ 30秒で話すとしたらどう言いますか？」

• 参加者の言葉をそのまま受け取る
• 長すぎたら「一番大事なのはどれですか？」で削る方向に誘導
• 整形はOK、内容を盛るのはNG

この回答を ## ワンライナー として書き出す。

---

Phase 2: 課題と解決策の再確認

質問2

「input.md に書いた課題文を改めて読んでください。実装した結果、最初の想定とずれたところ、新たに気づいたことはありますか？」

• 「ずれ」はネガティブではなく、発見として歓迎する トーンで聞く
• 例: 「チャットUIを考えていたが、実際には表形式のほうが使いやすかった」

質問3

「解決策のうち、実装してみて『この部分は特に効いた』と思う機能はどれですか？」

• 自分が作ったものへのオーナーシップを引き出す

2つの回答を ## 課題と解決策（当初の想定 / 実装で変わったこと / 特に効いた機能）として書き出す。

---

Phase 3: デモシナリオ

質問4

「想定ユーザーを1人思い浮かべてください。名前・立場・何に困っているかを教えてください」

• 抽象的な答えが返ってきたら「具体的な1人にしてみてください」と促す
  • 例: 「新入生の鈴木さん、市内在住、バス通学予定」

質問5

「その人がこのプロダクトを使う流れを、ステップごとに話してみてください」

• 話の途中で「その瞬間、画面はどうなっていますか？」などの補助質問で具体化する
• 語り終えたらシナリオとして整形して書き出す

## デモシナリオ（想定ユーザー / 使う流れ）として書き出す。

---

Phase 4: 作り方と、公開するなら変える点

技術の大枠（Next.js・ローカル動作・有料 API なし）はワークショップの前提なので、「なぜ選んだか」は参加者の言葉にならない。ここでは 前提の中で自分が決めた作り方 を確認したうえで、世に公開するとしたら何を変えるか／変えなくてよいか を聞く。

まず Claude が scope.md から「今回の作り方」（どのデータを使い、計算をどこでし、画面をどう組んだか）を2〜3行で要約して見せ、「この理解で合っていますか？」と確認する。

質問6

「今回は前提として Next.js・ローカル動作・有料 API なしで作りました。もし世に公開するとしたら、作り方のどこを変えますか？ たとえば、データの取り方（事前集計のままか、更新の仕組みを持つか）、計算の場所（ブラウザか、サーバか）、外部サービス（地図・LLM など）の利用です」

• 「変えない」もOK。その理由を聞く
• 変える点が出たら「それは公開に必須ですか、あると良い程度ですか」と確認する（Phase 5 の「限界」につながる）
• 認証・個人情報・コスト・運用の観点は /study-plan で扱うので、ここでは 作り方（データ・計算・外部サービス） に絞る

質問7

「逆に、公開しても 変えなくてよい部分 はどこですか？ それが今の作り方の強みです。idea.md で採用しなかった案と比べて話せますか？」

• idea.md があれば参照し、採用しなかった案と比較してもらう
• 強みが言語化できないなら「では弱みはどこですか？」で裏から攻める

## 作り方と、公開するなら変える点（今回の作り方 / 公開するなら変える点 / 変えなくてよい点 = 強み）として書き出す。

---

Phase 5: 限界と次の一手

質問8

「今、このプロダクトで『できないこと』『不十分なこと』はどこですか？ 正直に挙げてください」

• 限界を認めるほどピッチの説得力は増す、と伝える
• scope.md の「スコープ外」を参照してもOK

質問9

「もし時間があったら、次に何を足しますか？」

• ストレッチ機能の振り返り + 新しい発想の両方を歓迎する

## 限界と次の一手（できていないこと / 次に足すなら）として書き出す。

---

Phase 6: 最終整形と確認

全セクションを書き出したら、参加者に伝える：

「projects/<name>/verification.md に書き出しました。一度読み返してみてください。このあとペアフィードバックで相手に3分話す ので、その予行演習のつもりで声に出してみるとよいです。あわせて レビュー用のページ（HTML）を作りますか？ 内容に読むときの観点を添えて、ブラウザで読める形にします。ペアフィードバックで相手に見せるのにも使えます」

肯定なら review-page.md に従って projects/<name>/review/verification.html を作る（共通原則 15）。ペアフィードバック後に差分更新したときは、ページがあれば聞かずに作り直す。

---

ペアフィードバック後の調整

ペアから指摘を受けたあと、参加者がこのスキルを再度呼んだら：

• 該当セクションを Edit で 差分更新 する（全体の書き直しはしない）
• 「時間がないので1〜2箇所に絞って修正する」方向に誘導する
• 大きな修正が必要そうなら「ピッチでは口頭で補足して、修正はあとで」と割り切る提案もする

---

verification.md のフォーマット

# <プロジェクト名> — 発表用ドキュメント

## ワンライナー

<Phase 1 の回答>

## 課題と解決策

### 当初の想定
<input.md の課題・解決策から再掲>

### 実装で変わったこと
<Phase 2 の回答>

### 特に効いた機能
<Phase 2 の回答>

## デモシナリオ

### 想定ユーザー
<Phase 3 の人物像>

### 使う流れ
1. ...
2. ...
3. ...

## 作り方と、公開するなら変える点

### 今回の作り方
<scope.md をもとに Claude が要約し、参加者が確認した2〜3行>

### 公開するなら変える点
<Phase 4 質問6 の回答。必須／あると良い の区別つき>

### 変えなくてよい点（= 強み）
<Phase 4 質問7 の回答。idea.md の不採用案との比較>

## 限界と次の一手

### できていないこと
<Phase 5 の回答>

### 次に足すなら
<Phase 5 の回答>

---

参考: サンプル1 の場合の想定アウトプット

入力: samples/01_bus-arrival-dashboard/input.md（通学バス課題）

# 通学バス所要時間ダッシュボード — 発表用ドキュメント

## ワンライナー

郊外キャンパスにバス通学する学生が、「何時に出発すれば1限に間に合うか」を
Google Maps のリアルタイム情報ではなく公的データに基づいて事前に把握できる、
静的ダッシュボード。

## 課題と解決策

### 当初の想定
- 課題: バスの遅延が大きく、出発時間に対する到着時間の予測が立てづらい
- 解決策: 国交省データを使って所要時間をチャットで質問できるWebアプリ

### 実装で変わったこと
- チャットUIは「質問→回答」の1往復になりがちで、時間帯比較に向かないと気づいた
- タイムピッカー + グラフの構造化UIに転換したら、「出発時刻の逆算」が1操作で済むようになった
- チャット用にLLMを呼ぶコストもゼロになった

### 特に効いた機能
- 到着時刻からの出発時刻逆算（タイムピッカー）
- 時間帯別の所要時間グラフ（朝夕のピークが一目で分かる）

## デモシナリオ

### 想定ユーザー
新入生の鈴木さん。大学のある街に引っ越してきて、郊外キャンパスまでバス通学予定。
1限（8:40開始）に間に合うように出発したいが、渋滞を避けるタイミングが分からない。

### 使う流れ
1. ダッシュボードを開く
2. 到着希望時刻に「8:30」を選ぶ
3. 「6:58に駅を出発してください（所要92分）」と表示される
4. 時間帯別グラフを見て、7時台は特に混むこと、9時台なら75分で済むことを確認
5. 「1限の日は早めに、2限の日は余裕を持って」という判断ができる

## 作り方と、公開するなら変える点

### 今回の作り方
- 国交省の道路交通センサス（CSV）を事前集計した JSON を、静的サイトが読み込んで
  グラフと表を描く。リアルタイム取得なし、LLM 不使用

### 公開するなら変える点
- **必須**: センサスの更新（数年に1回）に合わせて再集計する手順を用意する。今は手動
- **あると良い**: 他路線に広げるなら、路線ごとの事前計算をビルド時に回す仕組み
- **あると良い**: 雨天・事故の反映。リアルタイムの交通情報が要るので、無料で使える
  API があるか調べてから判断する

### 変えなくてよい点（= 強み）
- **静的サイト + 事前計算**: 公開してもサーバ代がかからない。運用コストゼロ
- **公的データ**: 特定企業の集計バイアスがなく、誰でも検証できる
- **LLM 不使用**: 構造化 UI で足りる。`idea.md` のチャット UI 案と比べて時間帯の比較が
  しやすく、リアルタイム API 案と比べて利用規約やレートリミットに縛られない

## 限界と次の一手

### できていないこと
- バス停留所での乗降時間を加算していない（実測値よりやや楽観的な見積もりになる）
- 雨天・事故などイレギュラー要因は反映されない
- 国道202号のみ。他路線は未対応

### 次に足すなら
- 停留所データとの突き合わせで精度向上
- 他路線への展開（同じ集計ロジックで全国展開可能）
- 長期トレンド可視化（過年度センサスとの比較）

---

このスキルが生む体験

1. 実装した後に 自分のプロダクトに立ち戻って確認する 習慣がつく
2. 「動く」と「解けている」がずれていないかを、自分の言葉でチェックできる
3. ペアフィードバックが「触る」から「語る」に変わり、ピッチ本番のリハーサルになる
4. verification.md がそのまま本番ピッチの原稿として使える