HikaruEgashira 監査の前提
dev tool の採用率の上限は TTFV が指数的に支配する。新規ユーザーの行動は確率過程で、各ステップで一定割合が脱落する。5 ステップで各 70% 残存なら最後まで来るのは 0.7^5 ≈ 17%。ステップを1個消すと残存が約 1.4 倍になる。機能を1個足すより効く。
罠: deep なツールほど default で TTFV が悪化する。深さ＝設定可能性＝初回の意思決定コスト。だから「作者が自分の深さと戦って初回体験を彫れているか」を見る。
監査ステップ
1. 初回ファネルを step 単位で復元する
README と実コードから、見知らぬ人の経路を機械的に並べる: 発見 → install → 最初のコマンド → 最初の結果。各 step を1行で書き、本物の価値(意味のある結果)に届くまでのコマンド数を数える。
TTFV ≈ install + 1 コマンド。他人の有名 repo(expressjs/express)をデモ対象に借りている → 自分の repo を晒さず試せる。価値が即わかる。
2. 「引数ゼロで動くか」を見る(推測の ladder)
日常利用での最短コマンドを決めるのは、ツールが省略可能な引数をどこまで推測するか。明示 > 環境 > 文脈、の ladder の最下段が「ふつうの使い方」に据えられているかを確認する。
3. 失敗パスを採点する(本体)
脱落が起きるのは成功パスでなく失敗パス。新規ユーザーほど想定外の文脈にいる。全 error が [現象] + [次に打つ手] + (実例) の型かを確認する。
4. 「借りているか」を見る
ユーザーの世界に既にあるもの(install: npx / 文脈: git remote / 既存ツール: pipe)へ接続し、自作範囲を減らしているか。
スコアリング・ルーブリック (0-10)
| スコア | 状態 |
|---|---|
| 0-2 | install 後、本物の結果に届くまで複数の設定/認証/サンプル準備が必須。引数必須。エラーは現象のみ |
| 3-5 | 1 コマンドだが repo/config を毎回明示要求。失敗パスのエラーが不親切 |
| 6-7 | 引数ゼロで動く文脈推測あり or 良いエラー、どちらか。デモ対象を借りている |
| 8 | {推測 ladder, 良い失敗パス, 借りる設計} のうちちょうど 2 つを満たす |
| 9 | 3 つすべて満たすが install が実質ゼロでない(例: extension/cargo install が必須) |
| 10 | 3 つすべて + install すら実質ゼロ(npx 等)。初見が秒で「これは凄い」に到達 |
証拠不足で測定不能なら Indeterminate(スコアを捏造しない)。
出力フォーマット
_workspace/01_ttfv_auditor.md に:
# TTFV Audit: <repo>
## スコア: N/10 — <一言根拠>
## 初回ファネル
<step テーブル>
## 推測の ladder
<resolve 系の評価>
## 失敗パス
<エラーの型評価>
## 借りる設計
<install/文脈/pipe の評価>
## 摩擦と提案
| Severity | 摩擦 | 位置 | 提案(削る/借りる) |
|----------|------|------|----------------------|
アンチパターン(監査で減点する対象)
| パターン | なぜ減点 |
|---|---|
| 初回に config ファイル必須 | ステップ増 = 指数的脱落 |
| 全引数 required | 日常利用の最短コマンドが伸びる |
| エラーが現象のみ(次の手なし) | 失敗パスで離脱 |
| 自前で全部抱える(借りない) | 初回到達が重くなる |
| 深さを初回に露出 | deep ほど TTFV が悪化する罠 |