チームでの導入 ── 個人からエンタープライズまで

SDDは個人でも効果的だが、チームで実践した時に真価を発揮する。この章では規模別の導入ステップを解説する。

なぜチームでSDDが効くのか

チーム開発における最大のコストは「コンテキスト同期」だ。

従来のVibe Codingチームの日常:

PM:「ウィッシュリスト機能、こんな感じで」（曖昧なSlack）
Engineer A:（自分なりに解釈して実装）
Engineer B:（レビューで「あれ、認証の仕様が違う」）
PM:「え、そういうつもりじゃなかった」
→ やり直し

SPEC.mdがあると：

SDDチームの日常:

PM:「ウィッシュリストのSPEC.md書きました → PR #42」
Engineer A:（SPEC.mdを見てAIに実装依頼）
Engineer B:（SPEC.mdを見てレビュー「仕様通りです」）
PM:（Verificationチェックリストで完了確認）
→ 手戻りなし

仕様が共通言語になることで、PM・Engineer間の「解釈の差」が消える。

規模別の導入ガイド

個人・1〜2人（入門フェーズ）

目標：SPEC.mdを書く習慣をつける。

Week 1: 理解
  - 本書を読む
  - 既存プロジェクトにCLAUDE.mdを追加

Week 2: 実践
  - 次の機能からSPEC.mdを書いてから実装する
  - テンプレートを使って6要素を埋める

Week 3: 改善
  - 書いたSPEC.mdを見直す
  - 「これは書かなくてもよかった」「これは書くべきだった」を把握

よくある最初の壁：「SPEC.mdを書く時間がない」

対策：小さく始める。OutcomesとOut of Scopeだけでも書く。SPEC.mdは完璧でなくていい。「ゼロよりあるほうが圧倒的にいい」。

小規模チーム（3〜10人）

目標：チームでSPEC.mdのルールを統一する。

ステップ1: 共通のSPEC.mdテンプレートを作る

# プロジェクト構成
my-app/
├── CLAUDE.md           # チーム全員が合意した「憲法」
├── specs/
│   ├── TEMPLATE.md     # 共通テンプレート
│   ├── auth/
│   │   └── login.md
│   └── wishlist/
│       └── basic.md

ステップ2: SPEC.mdのレビューをPRフローに組み込む

機能開発フロー:
  1. PM・テックリードがSPEC.mdを書く（または書き始める）
  2. GitHubのPRとしてSPEC.mdを提出
  3. エンジニアがSPEC.mdをレビュー（実装可能性・曖昧さチェック）
  4. PMがフィードバックを反映して承認
  5. [locked] SPEC.mdが確定
  6. AIを使って実装・テスト生成
  7. Verificationチェックリストで完了確認
  8. 実装PRをマージ

ステップ3: CLAUDE.mdをチームで管理する

CLAUDE.mdはチームの「プロジェクト憲法」だ。個人ルールを書くのではなく、チームで合意したことだけを書く。

# CLAUDE.md（チーム合意版）

## テックスタック
（全員が合意した選択のみ記載）

## コーディング規約
（linterで自動化できないルールのみ記載）

## アーキテクチャルール
（チームでレビューして決定したもののみ記載）

## 変更ルール
このファイルへの変更はPRレビューが必要（CODEOWNERS設定推奨）

中〜大規模チーム（10人以上）

目標：SPEC.mdをチームの標準プロセスに組み込む。

仕様レジストリの構築

my-org/
├── specs-registry/           # 仕様の一元管理リポジトリ
│   ├── auth/
│   ├── payments/
│   ├── notifications/
│   └── APPROVED.md           # 承認済み仕様の一覧
├── frontend/
│   └── CLAUDE.md             # frontend固有のコンテキスト
├── backend/
│   └── CLAUDE.md             # backend固有のコンテキスト

SPEC.mdの承認フロー

graph LR
  A[PMがSPEC.md草稿] --> B[Tech LeadがレビュP]
  B --> C{実装可能性チェック}
  C -->|問題あり| A
  C -->|OK| D[EngineeringチームがレビューP]
  D --> E{承認}
  E -->|承認| F[SPEC.md locked]
  F --> G[AIで実装]
  G --> H[Verification]
  H --> I[マージ]

GitHub Spec Kitの活用（大規模チーム向け）

GitHub Spec Kitを使うと、SPEC.mdからGitHub ActionsのCIが自動でVerificationを実行できる。

# .github/workflows/spec-verify.yml
name: Spec Verification

on:
  pull_request:
    paths:
      - 'src/**'
      - 'tests/**'

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/spec-kit@v1
        with:
          spec-path: specs/
      - run: npm test
      - run: npm run coverage -- --threshold 80

PRのたびにSPEC.mdのVerification基準が自動確認される。

SDD導入の失敗パターン

チームへのSDD導入が失敗するよくある理由：

失敗パターン	原因	対策
「PMが仕様を書かない」	PMがSPEC.mdフォーマットを知らない	PMにもテンプレートのトレーニングを提供
「SPEC.mdが形骸化する」	誰もSPEC.mdを見ないうちに実装が始まる	PRフローにSPEC.md承認を必須にする
「AIが仕様を無視する」	SPEC.mdが長すぎてAIが大部分を読み飛ばす	1機能のSPEC.mdは1〜2ページ以内に抑える
「仕様が多すぎて管理できない」	全ての機能に完全なSPEC.mdを要求する	小機能はOutcomes + Scopeだけで可

導入の計測と評価

SDDが効いているかどうかを測る指標：

定量指標:
  - PRの手戻り率（Before/After SDDで比較）
  - テストカバレッジ（SDD前後）
  - レビュー通過率
  - 本番バグ件数

定性指標:
  - PM・エンジニア間の認識ズレが減ったか
  - 新メンバーのオンボーディング時間
  - 「仕様を見ればわかる」と言える機能の割合

導入初期の目安：最初の1ヶ月で「手戻り件数が減った」と感じられれば、SDDは機能している。

SDDを定着させる文化

ツールやプロセスだけでは定着しない。文化的な変化が必要だ。

「仕様ファースト」の考え方を広める3つの習慣：

1. 「まず仕様を書いてみて」をデフォルトにする 機能開発の話が出たら「SPEC.mdを書いてからにしよう」が自然に出るチームにする。

2. 仕様レビューをコードレビューより重視する 仕様が間違っている時のコスト > コードが間違っている時のコスト。仕様レビューに時間をかけることを文化にする。

3. SPEC.mdの「良い例」をチームで共有する 「このSPEC.mdはわかりやすい」という例をWikiやSlackで共有する。ベストプラクティスが自然に広まる。

---

次の章では、仕様駆動開発の本質的な意味を問い直すエピローグを書く。

＋ － ⟳ ✕