代替案比較: SpecDojo
本書は、シビックテックで SpecDojo を継続運用するため、運営・開発戦略、SDD 実装支援、作業状態管理を分けて比較する。
1. 比較目的と前提条件
1.1. 決定すること
本書では、抽象度の異なる次の三つを順に決定する。
| 決定ID | 比較レイヤー | 決定すること | 決定しないこと |
|---|---|---|---|
| D-01 | 運営・開発戦略 | P-01〜P-03 をどの原則と統制の組合せで解くか | 個別製品、IDE、Issue 管理ツール |
| D-02 | SDD 実装支援 | 採択戦略の仕様・計画・タスク化を何で支援するか | プロジェクト全体の運営戦略 |
| D-03 | 作業状態管理 | 人と AI Agent の作業、依存、判断根拠の正本をどこに置くか | 要求・設計文書の内容と開発方式 |
D-01 を先に決め、D-02 と D-03 はその実現を支える候補として評価する。SDD ツールやタスク管理ツールが備えるワークフローを、プロジェクト戦略そのものとはみなさない。
1.2. 前段文書から引き継ぐ条件
- 当事者の社会課題と期待価値を、要求・仕様・検証結果へ追跡できること。
- OSS、再利用、AI 支援により、現金支出と参加者の作業負荷を抑えられること。
- 判断、作業、負荷を共有し、特定個人へ依存せず分担・継承できること。
- 人間が判断責任を保持し、特定製品へ過度に固定されないこと。
内部の根拠資料は、初期公開の境界を定める プロジェクトスコープ、P-01〜P-03 と必要能力を定める プロジェクト課題と解決アプローチ、判断責任と外部依存を定める 前提・制約・依存関係 である。
1.3. 外部候補の調査範囲と選定基準
候補は、利用者が例示した製品や現在利用中の方式だけから選ばず、次のカテゴリを先に定めて公式資料を調査する。
| 比較レイヤー | 調査カテゴリ | 候補に含める基準 |
|---|---|---|
| D-01 | 予測型、適応型、ハイブリッド型、最小統制 | 単独でも目的達成への道筋と統制原則を説明できる |
| D-02 | OSS・ベンダー中立型、プラットフォーム提供型、IDE 統合型、包括的 Agent 開発型 | 仕様から計画・タスク・実装への接続を公式資料で確認できる |
| D-03 | リポジトリ内管理、Git ホスティング統合、汎用 SaaS、Agent ネイティブ | 状態、依存、履歴、担当または Agent の引継ぎを管理できる |
各候補は、標準・方法論と製品を区別し、管理対象、データ保管場所、対応環境、既存資産との重複、移行・復旧可能性を確認する。普及度だけで採択せず、成熟度は公式情報と試行結果で継続評価する。
現時点では客観的な市場占有率の比較を行っていないため、本書の「有力候補」は「各カテゴリの差異を評価するための比較候補」を意味し、「市場を代表する唯一の標準」を意味しない。
1.4. 外部資料の位置づけ
- 戦略: PMI Standards、PMBOK Guide のテーラリング資料、アジャイルソフトウェア開発宣言 と 背後にある原則。
- SDD: GitHub Spec Kit、OpenSpec、Kiro Specs、BMAD Method。
- 作業状態管理: GitHub Issues、Jira、Linear、Beads。
Spec Kit、OpenSpec、Kiro、BMAD、Beads は標準ではなく、特定カテゴリの実装候補として扱う。Loop Engineering は maker/checker、外部化した状態、検証、停止条件などの実行パターンとして扱い、Spec Kit の拡張機能だけに定義を依存させない。
2. 比較対象案
2.1. D-01: 運営・開発戦略
| 案ID | 案 | 目的達成への道筋 | 主な構成要素 | 対象範囲 |
|---|---|---|---|---|
| STR-01 | 予測型・ガバナンス先行 | 初期公開の成果、依存、計画、レビューゲートを先に定義し、統制された段階で完成させる | スコープ、WBS、役割、成果物、レビュー、変更統制 | 初期公開までの全活動 |
| STR-02 | アジャイル・価値提供先行 | 小さな成果を短い反復で提供し、フィードバックで次の優先順位を決める | バックログ、短期反復、動く成果、レビュー、振り返り | 価値の高い機能・文書から順次 |
| STR-03 | ツール非依存の仕様駆動ハイブリッド | Why、仕様、判断根拠を共有知識基盤にし、リスクに応じた統制と短い反復を組み合わせる | 選択可能な成果物、rulebook、メタデータ、トレース、品質ゲート、人間の承認 | 文書体系、補助ツール、公開・継続改善 |
| STR-04 | Agent 自律実行先行 | Agent が作業発見、実装、検証、状態保存を反復し、人間は例外と最終承認を扱う | Agent 実行ループ、maker/checker、外部状態、停止条件 | 自動化可能な開発・保守作業 |
| STR-05 | 既存ツールによる最小統制 | README、Issue / PR、CI に限定し、新たな仕様体系を設けず公開を優先する | 最小ガイド、汎用 Issue、コードレビュー、CI | 公開に必要な最小範囲 |
STR-01〜STR-05 は同じ課題に対する戦略パッケージである。SDD 製品や Issue 管理製品は含めず、採択後に D-02、D-03 で選ぶ。
2.2. D-02: SDD 実装支援
| 方式ID | 方式 | カテゴリ | 仕様・変更モデル | 強み | 主な制約 |
|---|---|---|---|---|---|
| SDD-01 | SpecDojo ネイティブ | リポジトリ内・ツール非依存 | 成果物、rulebook、メタデータ、参照関係を正本にする | 既存資産を維持でき、特定 Agent / IDE に依存しない | 対話的な仕様生成やタスク分解を自前で整備する必要がある |
| SDD-02 | GitHub Spec Kit | OSS・プラットフォーム提供型 | Spec → Plan → Tasks → Implement | 明確な段階と複数 Agent 連携を持つ | 固定ワークフローと SpecDojo 成果物の対応付けが必要 |
| SDD-03 | OpenSpec | 軽量 OSS・ベンダー中立型 | 変更単位の spec delta を正本へ反映する | 既存プロジェクトへ段階導入しやすく、変更意図をレビューしやすい | 全体の成果物体系、役割、統制は別途必要 |
| SDD-04 | Kiro Specs | IDE 統合型 | Requirements → Design → Tasks | IDE 内で仕様と実行タスクを一体化できる | Kiro への依存とリポジトリ側正本との境界が生じる |
| SDD-05 | BMAD Method | 包括的 Agent 開発型 | 企画・アーキテクチャ・ストーリーを専門 Agent で展開する | 開発ライフサイクルを広く支援する | SpecDojo と責務が大きく重複し、導入・移行範囲が広い |
| SDD-06 | 専用 SDD ツールを採用しない | 最小構成 | 現行 Markdown と手動手順のみ | 新規依存と学習負荷がない | 生成・差分管理・Agent 連携の改善機会を得にくい |
Spec Kit を SDD の唯一の代表とはせず、OpenSpec を直接比較し、Kiro と BMAD は異なる統合範囲の境界確認に用いる。
2.3. D-03: 作業状態管理
| 方式ID | 方式 | カテゴリ | 正本候補 | 強み | 主な制約 |
|---|---|---|---|---|---|
| TSK-01 | Schedule / Register | リポジトリ内管理 | 成果物、実行イベント、依存、リスク、判断 | 仕様と同じリポジトリで人と Agent が参照でき、復旧しやすい | 外部参加、通知、対話的操作が弱い |
| TSK-02 | GitHub Issues / Projects | Git ホスティング統合 | Issue、担当、議論、状態、PR 接続 | 公開 OSS の参加導線とコード変更を接続できる | GitHub 依存が生じ、仕様正本との二重管理に注意が必要 |
| TSK-03 | Jira | 汎用プロジェクト管理 SaaS | Issue、workflow、計画、依存、レポート | 複雑な組織運用や統制を構成できる | 小規模 OSS には管理負荷が大きく、外部 SaaS が正本になる |
| TSK-04 | Linear | 製品開発向け SaaS | Issue、Project、依存、開発連携 | 軽量な操作と製品開発の計画を接続できる | 外部 SaaS とリポジトリ内成果物の同期が必要 |
| TSK-05 | Beads | Agent ネイティブ | Agent の永続状態、依存グラフ、ready work | 長期・複数セッションの Agent 作業に特化する | 一般的な外部協働基盤ではなく、成熟度と復旧運用の試行が必要 |
| TSK-06 | 正本と外部ツールの同期・投影 | 統合方式 | リポジトリ側正本から必要項目を投影 | 内部トレースと外部協働を両立できる | 同期方向、競合解決、ID 対応、障害時復旧の設計が必要 |
Beads は汎用代表製品ではなく、Agent ネイティブという専門カテゴリの試行候補として扱う。
3. 評価軸と評価基準
3.1. D-01 の評価軸
| 評価軸 | 重み | 判定基準 | 主に対応する課題・制約 |
|---|---|---|---|
| 効果 | 5 | P-01〜P-03 を横断して改善し、初期公開の価値へ寄与できるか | P-01〜P-03 |
| コスト | 3 | 個人・小規模体制で導入・維持できる作業量か | P-02 |
| 期間 | 3 | 初期公開前に有効な成果とフィードバックを得られるか | 初期公開範囲 |
| リスク | 4 | 現場との乖離、負荷転嫁、責任不明、公開不備を抑えられるか | P-01〜P-03、公開制約 |
| 運用適合 | 4 | 少人数で費用と負荷を管理し、分担・継承できるか | P-02、P-03 |
| 技術実現性 | 4 | 既存資産と OSS を再利用し、過度な外部依存なく始められるか | P-02、外部依存 |
| 適応性 | 4 | 当事者の学びと参加者の変化を仕様と作業へ反映できるか | P-01、P-03 |
| 追跡性 | 5 | 社会課題、期待価値、要求、仕様、判断、検証を追跡できるか | P-01、P-03 |
| AI 適合 | 5 | Agent が文脈を解釈し、作業と費用の削減に寄与できるか | P-01、P-02 |
| 成熟度 | 3 | 標準、実績、運用知見、回復方法を利用できるか | 継続運用、外部依存 |
3.2. D-02 の評価軸
| 評価軸 | 判定基準 |
|---|---|
| 成果物適合 | SpecDojo の Why、要求、設計、検証、決定記録へ無理なく対応できるか |
| 変更追跡 | 変更意図、差分、影響範囲、正本への反映を追跡できるか |
| Agent / IDE 中立性 | 特定 Agent、IDE、ベンダーへ固定されず交換可能か |
| 人間の統制 | 仕様レビュー、承認、検証証拠を完了条件にできるか |
| 導入・移行負荷 | 既存文書の重複や一括変換を避け、段階導入できるか |
| 可逆性 | ツール停止後も標準的なファイルから情報を復旧できるか |
| 成熟度 | 仕様、互換性、更新方針、運用知見を確認できるか |
3.3. D-03 の評価軸
| 評価軸 | 判定基準 |
|---|---|
| 正本性 | 現在の状態、理由、判断者、履歴を一意に確認できるか |
| 依存表現 | blocker、順序、成果物間依存、ready work を表現できるか |
| Agent 適合 | セッションをまたいで Agent が状態を取得・更新できるか |
| 人間可読性 | 追加ツールなし、または一般的な UI で状態を確認できるか |
| 外部協働 | Issue / PR、外部参加者、通知、議論と接続しやすいか |
| 運用負荷 | 同期、競合、復旧、権限、スキーマ更新を維持できるか |
| ロックイン | データをリポジトリへ保持・移行し、ツールを交換できるか |
| 成熟度 | 更新継続性、互換性、障害時の回復手段を確認できるか |
評価は High / Middle / Low とし、採択に有利なほど高くする。重みは D-01 の優先順位を示すが、機械的な合計だけで決定しない。D-02 と D-03 は、追跡可能な正本、人間の判断責任、可逆性を必須条件とする。
4. 比較結果と採択理由
4.1. D-01: 運営・開発戦略
| 案ID | 効果 | コスト | 期間 | リスク | 運用適合 | 技術実現性 | 適応性 | 追跡性 | AI 適合 | 成熟度 | 総合評価 | 判定 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| STR-01 | Middle | Low | Low | High | Middle | High | Low | High | Middle | High | Middle | 一部採択 |
| STR-02 | Middle | High | High | Middle | High | High | High | Low | Middle | High | Middle | 一部採択 |
| STR-03 | High | Middle | Middle | High | High | High | High | High | High | Middle | High | 採択 |
| STR-04 | High | Middle | High | Low | Middle | Middle | High | Middle | High | Low | Middle | 限定採択 |
| STR-05 | Low | High | High | Middle | Middle | High | High | Low | Low | High | Low | 非採択 |
STR-03 のツール非依存の仕様駆動ハイブリッドを採択する。STR-01 の責任分担、レビューゲート、変更統制と、STR-02 の短い反復、利用者フィードバック、振り返りを取り込む。STR-04 の実行パターンは、境界、検証、停止条件を定義できる反復作業だけに限定する。
採択理由は、社会課題から検証までの追跡、OSS・AI の再利用、必要な成果物の選択、負荷を抑えた反復を組み合わせられるためである。また、戦略を個別製品から分離し、人間の承認と機械検証を Agent 実行のゲートにできる。
STR-01 単独は継続改善、STR-02 単独は永続的な追跡性が弱く、STR-04 単独は誤収束への統制が不足する。STR-05 は初期費用を抑えられるが、P-01 と P-03 を体系的に解けないため採択しない。規制領域、反復頻度、自動検証、小規模向け最小構成の要求が変わった場合に各案を再評価する。
4.2. D-02: SDD 実装支援
| 方式ID | 成果物適合 | 変更追跡 | Agent / IDE 中立性 | 人間の統制 | 導入・移行負荷 | 可逆性 | 成熟度 | 判定 |
|---|---|---|---|---|---|---|---|---|
| SDD-01 | High | Middle | High | High | High | High | Middle | 正本として採択 |
| SDD-02 | Middle | Middle | High | High | Middle | High | Middle | 比較試行 |
| SDD-03 | Middle | High | High | High | High | High | Middle | 優先試行 |
| SDD-04 | Middle | Middle | Low | High | Middle | Middle | Middle | 非採択 |
| SDD-05 | Middle | Middle | Middle | Middle | Low | Middle | Middle | 非採択 |
| SDD-06 | Low | Low | High | Middle | High | High | High | 非採択 |
SDD-01 の SpecDojo ネイティブ成果物を正本とし、外部 SDD ツールを正本にしない。初期試行は、変更差分を既存成果物へ反映する適合性を確認するため SDD-03 の OpenSpec を優先し、同じ課題を段階型ワークフローで解く SDD-02 の Spec Kit と比較する。
Kiro は IDE 依存、BMAD はプロジェクト方式との責務重複が現時点の制約に合わないため採択しない。ただし、IDE 統合または包括的 Agent 役割分担が必須になった場合は再評価する。
試行では同じ小規模な変更要求を処理し、成果物の重複と反映手順、要求から検証までの追跡漏れ、人間のレビューによる意図保持、ツールや Agent / IDE を外した場合の再開可能性を測定する。
試行を終えるまでは、OpenSpec または Spec Kit を「SpecDojo の採用ツール」や「標準」と表現しない。
4.3. D-03: 作業状態管理
| 方式ID | 正本性 | 依存表現 | Agent 適合 | 人間可読性 | 外部協働 | 運用負荷 | ロックイン | 成熟度 | 判定 |
|---|---|---|---|---|---|---|---|---|---|
| TSK-01 | High | High | High | High | Low | Middle | High | Middle | 正本として採択 |
| TSK-02 | Middle | Middle | Middle | High | High | High | Middle | High | 段階採用 |
| TSK-03 | Middle | High | Middle | High | High | Low | Low | High | 非採択 |
| TSK-04 | Middle | Middle | Middle | High | High | Middle | Low | High | 非採択 |
| TSK-05 | Middle | High | High | Middle | Middle | Low | Middle | Low | 条件付き試行 |
| TSK-06 | High | High | High | High | High | Low | Middle | Low | 保留 |
初期段階は TSK-01 の Schedule / Register を実行状態と判断根拠の正本にする。公開・外部協働では TSK-02 の GitHub Issues / Projects を受付、議論、PR 接続に用いるが、正本を二重化しない。
Jira と Linear は汎用 SaaS カテゴリの有力候補として比較したが、現時点の個人・小規模 OSS では外部管理と同期の負荷が便益を上回るため採択しない。組織横断の計画・権限制御・レポート、または既存組織基盤との統合が必須になった場合に再評価する。
Beads は、同時実行や長期中断を伴う Agent 作業で依存見落としや引継ぎ失敗が発生した場合に限り試行する。事前にデータの移行・復旧と正本への反映方向を確認する。自動同期は競合・復旧規則が必要になるまで保留する。
4.4. 技術的実現性と影響
| 決定ID | 技術的実現性 | 主な影響 |
|---|---|---|
| D-01 | 現行の文書体系、メタデータ、検証を拡張して実現可能 | 適用条件と必須ゲートを rulebook 等へ反映する |
| D-02 | 隔離した変更要求で既存成果物を変換せず試行可能 | 対応表、評価記録、試行生成物の削除規則が必要になる |
| D-03 | リポジトリと GitHub の責務を分離して運用可能 | Issue と正本の ID 対応、転記・クローズ条件が必要になる |
5. リスクとトレードオフ
| 区分 | 内容 | 軽減策 |
|---|---|---|
| トレードオフ | ツール非依存の正本を維持するため、外部ツールの専用機能をそのまま正本にできない | 外部ツールを生成・受付・投影に限定し、正本への反映条件を定める |
| トレードオフ | 予測型と適応型を組み合わせるため、単一方式より適用条件の説明が必要になる | リスク、規模、成果物ごとの必須ゲートと反復単位を定義する |
| リスク | SDD ツールの試行が目的化し、重複仕様が生じる | 同一変更要求と終了条件を固定し、SpecDojo への反映・削除規則を定める |
| リスク | 複数の状態管理方式に情報が分散する | 正本、受付、投影、実験の責務とデータ方向を固定する |
| リスク | 外部ツールの更新・障害・終了によって運用を継続できなくなる | 標準形式での保存、エクスポート、復旧、離脱手順を採択条件にする |
| リスク | 候補の普及度や成熟度を印象で評価する | 公式資料、更新状況、試行証拠を記録し、未確認事項を High と評価しない |
| リスク | Agent が検証なしに状態や仕様を更新する | maker/checker、機械検証、回数上限、停止条件、人間の承認を必須にする |
6. 決定と見直し
- D-01 はツール非依存の仕様駆動ハイブリッド、D-02 は SpecDojo 成果物を正本とする。OpenSpec と Spec Kit は同一条件で比較試行し、それまでは正式採用しない。
- D-03 は Schedule / Register を正本、GitHub Issues / Projects を外部協働の入口とする。Jira、Linear は現段階では採用せず、Beads は Agent 固有の実課題が確認された場合だけ試行する。
- 採択案の最終判断は人間の
POが行う。BAは利用者価値、ARCは方式境界と外部依存、PMは計画・リスク、QEは検証証拠を確認し、AI Agent は調査、比較、隔離試行を支援する。 - 比較試行は入力・評価軸・完了条件を固定し、結果をプロジェクト登録簿または技術検証結果に記録する。
- 長期 Agent 作業の依存問題、組織横断の統制要求、または外部候補の重要な変更が生じた場合、該当カテゴリ全体を再評価する。特定製品の自動採用条件とはしない。
- 方針変更は、評価結果、影響範囲、移行・撤退方法とともにプロジェクト登録簿または決定記録へ残す。