PJR-NYZR SpecDojo の普及戦略を決める
1. 背景
v0.3.0 の公開に向けて、SpecDojo の位置づけ、入口、最初に狙う利用者、段階的な計画と指標を決める。根拠は prj-0001:pjr-36qg-competitive-landscape-and-release の「v0.3.0 の機能と SDD のツールの比較（2026-10-08）」と「設計文書・判断の記録・文書の維持の領域の比較（2026-10-08）」である。
比較の要点は次のとおり。
- Spec Kit（115k star、1.0 公開済み）などの SDD のツールは、1 つの機能を実装するまでを扱う。SpecDojo の主な機能は、プロジェクトの仕様と設計を成果物の体系として作るまでであり、それを運用・保守へつなぐ。工程として Spec Kit の上流に立ち、競合は薄い。
- 設計書を作る（arc42 Toolkit）、判断を残す（ADR の skill）、文書を保つ（Swimm）、トレーサビリティ（RTMX）には、それぞれ専門の道具がある。仕様の判断から設計書の体系、品質の継続評価、運用・保守までを 1 つにつないだものは見つからなかった。
- 実行基盤の規模と成熟度では Gas City などに勝てない。導入の軽さでは Spec Kit や plan 機能に劣る。
2. 検討した選択肢
| 選択肢 | 内容 | 利点 | 懸念 |
|---|---|---|---|
| A: SDD のツールとして打ち出す | Spec Kit・OpenSpec・Kiro と同じ「仕様駆動開発」の枠で比べられる形で出す | 市場の言葉に乗れ、検索で見つかりやすい | 入口の機能と導入の軽さで勝てない。本来の価値（設計書の体系と保守）が比較の軸に入らない |
| B: 仕様と設計の基盤として、register を入口にする（推奨） | 「仕様を決め、仕様を保つ判断台帳」として register から入り、設計書の型（kata）、品質の継続評価（grade）へ順に進める。実装は Spec Kit などへ引き渡す | kata なしで始められる。判断から設計書、保守までの一本の流れが他にない価値になる | 「登録簿」が課題管理と受け取られやすい。打ち出す言葉と、設計書の更新まで通すクイックスタートが要る |
| C: 設計書の型の一式を入口にする | 規模別の kata の組（例: 小規模の Web システムの基本設計の一式）を最初に見せる | 設計書文化のある利用者に直接響く | 最初から型を選ぶ負担があり、導入が重い。判断の記録の価値が後回しになる |
2.1. 推奨案 B の内容
| 観点 | 内容 |
|---|---|
| 位置づけ | 「AI で作り、運用まで保つ仕様と設計の基盤」。SDD のツールとは名乗らず、Spec Kit などの上流に立つ |
| 入口 | register を「仕様の判断台帳」として打ち出す。question を起票 → decision で決める → 設計書を 1 つ更新 → 後日 change-request で直す、までを最初の 10 分で見せる |
| 最初に狙う利用者 | 設計書を作って保守する文化のある日本のチーム（受託開発・SIer・社内システム）。kata の多さが「必要な設計書の型が揃っている」強みになる |
| 将来の市場 | EU AI Act などで技術文書の維持と監査証跡が求められる英語圏の領域 |
| 実装の道具との関係 | Spec Kit などは引き渡し先として連携する（設計書を /specify の入力にする橋渡しなど） |
段階的な計画は次のとおり。
| 段階 | 時期 | 施策 |
|---|---|---|
| 0. 公開の準備 | 公開前 | exec の安定化の期間を取る。「仕様の判断台帳」のクイックスタートと駄菓子屋のサンプルリポジトリのデモ。規模別の kata の組（3〜5 種類から始める組）。npm の公開（docs-lint・docs-site を含む）と既知の脆弱性の整理 |
| 1. 日本語での発表 | 公開〜1 か月 | Zenn・Qiita での連載（判断台帳、設計書の継続評価、agent に設定を書き換えさせない保護）。デモ動画。3〜5 人の試用で、最初の起票までの時間と 1 週間後の継続を測る |
| 2. 連携と英語 | 1〜3 か月 | Spec Kit などへの引き渡しの連携、VS Code 拡張の Marketplace、README と主要な文書の英語版 |
| 3. 実績づくり | 3 か月〜 | 本リポジトリの運用の実例の公開。試用者の声でチーム向けの機能を判断する |
指標は、npm の週間ダウンロード数、クイックスタートの完了率、最初の起票までの時間、1 週間後の継続率、外部からの issue と star とする。
主なリスクは、成熟度（実行まわりの不具合の多さ）、学習のコスト、開発体制が 1 人であること、破壊的な変更、agent の CLI の仕様変更への依存である。
3. 決定内容
選択肢 B を採る。SpecDojo を、AI で作り運用まで保つ仕様と設計の基盤として位置づけ、register を「仕様の判断台帳」として入口にする。設計書の型（kata）、品質の継続評価（grade）へ順に進める流れを打ち出し、実装は Spec Kit などへ引き渡す。最初に狙う利用者は、設計書を作って保守する日本のチームとする。段階的な計画と指標は「推奨案 B の内容」のとおりとする。
SpecDojo を何と呼ぶか（現在の「仕様駆動開発のためのドキュメントフレームワーク」を改めるか）は、本決定の位置づけを受けて別に決める。
4. 採択理由
- 仕様の判断から設計書の体系、品質の継続評価、運用・保守までを 1 つにつないだものは、比較の範囲で見つからなかった。
- register から入れば kata を用意せずに始められ、導入の重さという劣位を避けられる。
- Spec Kit などの SDD のツールとは工程が前後の関係にあり、同じ土俵で比べられることを避けられる。
5. 承認
| 項目 | 内容 |
|---|---|
| 決定者 | indie |
| 決定日 | 2026-10-08 |
| 承認方式 | commit |
| 証跡 | 利用者が orchestrator との対話で選択肢 B を指示し、本個票の更新を commit した |
- 承認方式は
commitまたはPRを記載する。PRの場合は証跡に PR URL と merge SHA を本文テキストで記載する。 - 不可逆・高リスク・framework schema 破壊的変更に該当する決定は
PR方式で承認する。
6. 影響範囲とフォローアップ
| 項目 | 内容 |
|---|---|
| 影響範囲 | README・docs サイトのトップ・概要ガイドの打ち出し方、クイックスタート、デモ、kata の組、公開の準備 |
| 必要な対応 | 呼び方の決定、段階 0 の施策の todo の起票（クイックスタート、デモのリポジトリ、規模別の kata の組、公開前の安定化）。npm の公開は既存の項目で扱う |
| 追跡先 | 呼び方は PJR-QGP4（仕様道に決定）。段階 0 は PJR-XMQH（クイックスタート）、PJR-DQ9E（デモのリポジトリ）、PJR-5TZS（規模別の kata の組）、PJR-P8TK（公開前の安定化）。npm の公開は PJR-7VKR・PJR-WJZD・PJR-CBQV |