PJR-QGP4 SpecDojo の呼び方を仕様道（Spec-Dō）にする
1. 背景
README・docs サイトのトップ・概要ガイドは、SpecDojo を「仕様駆動開発のためのドキュメントフレームワーク」と呼んでいる。仕様駆動開発（Spec-Driven Development, SDD）は、2026 年の市場では仕様から AI にコードを書かせる手法を指し、Spec Kit・Kiro・OpenSpec が代表である。prj-0001:pjr-nyzr-adoption-strategy で SpecDojo を「仕様と設計を作り、運用まで保つ基盤」と位置づけ、SDD のツールとは名乗らないと決めたため、この呼び方は位置づけと矛盾する。
利用者の要望は、SDD のように一言で分かり略しても分かりやすいこと、道場の比喩を使うことである。調べた結果、英語圏で「spec」を軸にした言葉（Specification Engineering、SpecOps、Spec as Code、Living Specs）は、いずれも SDD の文脈で既に使われていた。日本語の「型駆動」は Type-Driven Development と、略語の KDD はデータマイニングの国際会議と、Dojo-Driven Design は DDD（Domain-Driven Design）と衝突する。「SpecDo」「Spec-Do」という名前のツールや方法論は見つからなかった。
2. 検討した選択肢
| 選択肢 | 内容 | 利点 | 懸念 |
|---|---|---|---|
| A: 要求・設計のライフサイクル管理 | BABOK の知識エリア（Requirements Life Cycle Management）にそろえる | 確立した概念で、PM やビジネスアナリストに説明しやすい | 硬い。一言で覚えにくい |
| B: 仕様と設計を育てるフレームワーク | 日常の言葉で「作って保ち続ける」を言う | やわらかく伝わる | 略語にならない。道場の比喩が入らない |
| C: Kata-Driven Specification（KDS） | 型に沿って仕様を作る手法として SDD に似た略語にする | SDD と並べて理解されやすい | 日本語では「型」を避ける必要がある。SDD の仲間と見られる |
| D: 仕様道（Spec-Dō）（採用） | 柔道・剣道のように仕様を「道」として稽古する。SpecDojo は仕様道の道場 | 一言で覚えやすく、衝突しない。名前の由来がそのまま方法論になり、道場の比喩が仕組みを説明できる | 英語の話者は動詞の do と読みがち。和風の演出が過剰に見えるおそれ |
3. 決定内容
選択肢 D を採る。SpecDojo を「仕様道（Spec-Dō、the way of specification）の道場」と呼ぶ。「仕様駆動開発のためのドキュメントフレームワーク」という呼び方はやめ、仕様駆動開発には「そのツールの上流で仕様と設計の体系を担う」と関係として触れるにとどめる。
表記と比喩の規則は次のとおりとする。
| 項目 | 規則 |
|---|---|
| 日本語 | 仕様道（Spec-Dō） |
| 英語 | Spec-Dō — the way of specification。冒頭で「dō（道）は judō や kendō と同じく the way の意味」と 1 行説明する |
| 記号を使いにくい場所 | Spec-Do。説明の文では Spec-Dō に統一する |
| ツールとの関係 | SpecDojo is the dojo where you practice Spec-Dō. |
| 標語 | 決めて、書いて、鍛え続ける。（英語: Decide. Write. Keep sharpening.）。2026-10-08 に「決めて、書いて、腐らせない」から変更した。説明の文では「判断を記帳し、型に沿って実戦で書き、評定で鍛え続ける」と仕組みを語る |
| 使う比喩 | dojo・kata・dō・shu-ha-ri（守破離）・稽古に限る。ninja・samurai・zen などは使わない |
道場の比喩と仕組みの対応は次のとおりとする（2026-10-08 に利用者との対話で確定。当初案の「稽古・審査・稽古日誌」を改めた）。既存の Kata・Waza・Ryu（型・技・流）の体系に合わせ、技（CLI の機能）の名前は活動の言葉でそろえる。
| 道場の言葉 | SpecDojo の仕組み |
|---|---|
| 型（Kata） | rulebook・recipe・sample・template |
| 技（Waza） | specdojo CLI |
| 流（Ryu） | approach |
| 記帳 | register。起票から状態の遷移・決定・完了までを記録し続ける。最初の操作（register add）は「起票」と呼ぶ |
| 実戦 | exec。型に沿って実際の成果物を作る |
| 評定 | grade。型に照らして品質を 0〜4 で評価する |
| 講評 | review。評定を入力に、タスクの完了を判断する |
各流（approach）には、表示と文書で使う名前を付ける。CLI と設定の値は互換性のため変えない。
approach | 名前 | 意味 |
|---|---|---|
fully-guided | 守 | 型をそのまま守る。rulebook・recipe・sample・template をすべて使う |
recipe-guided | 破 | 型を崩して工夫する。recipe の問いと観点だけを基準にする |
freeform | 離 | 型から離れ、完了条件と根拠から組み立てる |
bootstrap | 型起こし | 成果物と、その型を同時に初めて作る |
retrofit | 見取り | 見取り稽古のように、既存の実装を読み取って成果物に反映する |
cross-deliverable-dedup | 型寄せ | 複数の成果物の重複を、正本の 1 つへ寄せる |
*-maintenance | 手入れ | rulebook などの型を見直す（例: rulebook の手入れ） |
finalize | 免許 | 人が確かめ、成果物を ready と認める |
bootstrap-finalize | 皆伝 | 型起こしで作った成果物と型を、まとめて認める |
4. 採択理由
- 一言で覚えやすく、略語を作らなくても短い。調べた範囲で衝突がない。
- 名前の SpecDojo（Spec の道場）の由来がそのまま方法論の名前になり、道場の比喩が飾りではなく仕組み（kata・grade・register・approach）を説明できる。
- 武道の言葉（code kata、coding dojo、Shu Ha Ri）は英語圏のソフトウェア開発で既に定着しており、日本人以外にも受け入れられやすい。英語圏での受け止め方は、英語の README を出す段階で実際の反応を確かめる。
5. 承認
| 項目 | 内容 |
|---|---|
| 決定者 | indie |
| 決定日 | 2026-10-08 |
| 承認方式 | commit |
| 証跡 | 利用者が orchestrator との対話で仕様道（Spec-Dō）を指示し、本個票の更新を commit した |
- 承認方式は
commitまたはPRを記載する。PRの場合は証跡に PR URL と merge SHA を本文テキストで記載する。 - 不可逆・高リスク・framework schema 破壊的変更に該当する決定は
PR方式で承認する。
6. 影響範囲とフォローアップ
| 項目 | 内容 |
|---|---|
| 影響範囲 | README、docs サイトのトップ、概要ガイド、package.json の説明、philosophy や waza ガイドなど比喩を使う文書 |
| 必要な対応 | 冒頭の文と説明を直す todo を起票する。英語圏の反応の確認は、普及戦略の段階 2 で行う |
| 追跡先 | PJR-0WYM（README と概要の呼び方の反映） |