# Sdlc

> SPEC.mdを中心に、仕様、設計、Test Contract、TDD、レビュー、セキュリティ、デプロイをリスクに応じて段階的に進めるSDLCオーケストレーター。開発タスクを規律あるプロセスで進める時や仕様駆動開発を求められた時に使う。

- Skill: `nob-git-dev/sdlc` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add nob-git-dev/sdlc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nob-git-dev/sdlc/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nob-git-dev (https://skillmd.com/u/nob-git-dev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nob-git-dev/sdlc

---


# SDLC オーケストレーター

開発タスクを、検証可能な作業契約、段階的な実装、品質ゲート、証拠つきの完了確認へ導く。プロセスの重さは変更リスクに合わせ、文書作成そのものを目的にしない。

## ポータブル実行ルール

- 現在のユーザー依頼、利用中クライアントの権限規則、リポジトリ内の指示を優先する。特定製品の呼び出し構文、サブエージェント、Kanban、ディレクトリ構成を前提にしない。
- `SPEC.md` があれば目的、受け入れ条件、固定要件の正典として読む。無ければタスクの規模に応じて作成するか、現在の依頼から軽量な作業契約を明示する。
- `spec`、`architect`、`ddd`、`ui`、`test-contract`、`tdd`、`review`、`security`、`deploy`、`sre`、`observe`、`refactor` は任意の連携先である。利用できれば適切な局面で使い、無ければ同じ観点をこのワークフロー内で確認する。
- ユーザーが明示的に依頼しない限り、`git add`、`git commit`、`git push`、デプロイ、外部への書き込み、破壊的操作を行わない。
- 環境、依存関係、サービス状態、バージョン、資源量など変わり得る事実は、記憶や古い文書だけで決めず、実際の設定と読み取り専用の観測で確認する。
- 未コミットの変更はユーザーの作業として保全する。範囲外の変更を戻さない。

詳細な判断原則が必要な場合は [references/work-constitution.md](references/work-constitution.md) を読む。

## 1. リスクに応じた進め方

最初に変更の影響を分類する。複数に該当する場合は最も高い区分を使う。

| 区分 | 例 | 必要な統制 |
|---|---|---|
| 軽量 | 文言、局所的なバグ、既存挙動を変えない小変更 | 目的・範囲・確認方法を短く明示し、関連テストを実行 |
| 標準 | 新機能、複数ファイル、APIやデータモデルの変更 | 受け入れ条件、影響範囲、設計、テスト、レビューを記録 |
| 高リスク | 認証、認可、決済、個人情報、移行、本番、不可逆操作 | SPEC、脅威分析、事前資源確認、段階実行、中断基準、ロールバック、明示承認 |

次の場合は高リスクとして扱う。

- 外部API、永続データ、権限境界、ネットワーク公開範囲を変える
- データ削除、不可逆なマイグレーション、広範囲の置換を含む
- 本番サービス、他ユーザー、長時間のGPU・CPU・メモリ・ディスク利用へ影響する
- 障害時の復旧方法が未確認である

## 2. 作業契約を確立する

実装前に最低限、次を明確にする。

```markdown
## 目的
なぜこの変更が必要か

## 期待する振る舞い
入力、処理、出力、失敗時の扱い

## 受け入れ条件
- [ ] 観測可能な条件と期待結果

## スコープ外
- 今回は行わないこと

## 固定要件
- ユーザー承認なしに変えてはならない制約

## 検証方法
- 実行するテスト、確認コマンド、レビュー観点
```

- 標準・高リスクの変更、またはユーザーが仕様駆動を求めた場合は、原則としてプロジェクトの `SPEC.md` を作成または更新する。
- 軽量変更では、同じ内容を作業計画に短く示せばよい。既存運用が求めない文書を増やさない。
- 既存 `SPEC.md` とユーザーの最新指示が矛盾する場合は、勝手にどちらかを採用せず、差分と影響を示して確認する。
- 固定要件を満たせない場合は、代替案へ黙って切り替えない。

## 3. 現状と影響範囲を確認する

変更前に次を読み取り専用で確認する。

1. リポジトリ内の指示、README、既存仕様、設計記録
2. `git status` と対象差分。ユーザーの既存変更と重なるか
3. 変更対象から参照先・利用元を双方向に辿った影響範囲
4. テスト、ビルド、静的解析、デプロイ方法
5. 外部サービスや実行環境へ依存する場合は、その現在状態と確認日時

移行やインターフェース変更では、影響マップを残す。

| コンポーネント | 現在の契約 | 変更後の契約 | 対応 | 検証 |
|---|---|---|---|---|
| 対象 | ... | ... | 変更する / 不要（理由） | ... |

## 4. 必要なフェーズだけを選ぶ

| フェーズ | 選ぶ条件 | 主な成果 |
|---|---|---|
| 仕様 (`spec`) | 目的や受け入れ条件が曖昧、標準以上 | 作業契約、SPEC.md |
| 設計 (`architect`) | 境界、依存、技術選定、移行を変える | 構造、影響マップ、ADR |
| ドメイン (`ddd`) | 複雑な業務概念や整合性境界がある | 用語、コンテキスト、集約 |
| UI (`ui`) | 画面、操作、アクセシビリティを変える | UX設計、状態、操作テスト |
| Test Contract (`test-contract`) | 振る舞いを実装する前 | Required Observable、Evidence要件、Proof Obligation |
| 実装・TDD (`tdd`) | 未達Proof Obligationを実装する | Red-Green-Refactor、Minimum Sufficient Change、Evidence |
| リファクタ (`refactor`) | 振る舞いを保って構造を変える | 小さな変更、回帰確認 |
| レビュー (`review`) | コードまたは設定を変更した | 重要度・根拠つき指摘、判定 |
| セキュリティ (`security`) | 信頼境界、機密データ、高リスク変更 | 脅威、対策、残余リスク |
| 観測 (`observe`) | 運用・調査可能性が必要 | ログ、メトリクス、トレース |
| 信頼性 (`sre`) | SLO、障害対応、運用設計が必要 | SLI/SLO、障害モード、手順 |
| デプロイ (`deploy`) | リリースを明示的に依頼された | 段階実行、検証、ロールバック |

すべてのフェーズを機械的に実行しない。省略するフェーズは、リスク上不要である理由を短く記録する。

標準的な新機能は `spec -> 必要なdesign -> test-contract -> tdd -> review` の順で進める。軽量変更ではExpected behavior、Observable、Verification commandだけの簡易Contractでよい。認証、認可、金銭、個人情報、永続化、移行、破壊操作、外部副作用、本番、高負荷を含む場合は、Security / Reliability / Outer Gateを含む詳細Contractを要求する。

## 5. 実装を小さく進める

1. 変更前の基準となるテストまたは観測結果を取る。
2. Test ContractでRequirementからRequired Observable、Evidence、Proof Obligationを固定する。
3. 未達Proof Obligationを1つ選び、必要な制約、現在Evidence、関連ファイルだけへコンテキストを絞る。
4. 対応する失敗テストを実行してRedを確認する。
5. Minimum Sufficient ChangeでGreenにし、対象テストと必要な回帰テストを実行する。
6. 構造改善が必要なら、テストが通る状態で小さく行う。
7. EvidenceとObservable状態を更新し、Stop Conditionを満たしたPOへの追加変更を止める。
8. Required Outer Gateを適切な時点で実行し、Acceptance MatrixからVerdictを決める。
9. 各段階で、目的・固定要件・スコープから逸脱していないか照合する。

品質はコストとのトレードオフ対象ではない。Required Observable、固定要件、Required Regression、Required Security / Reliability Gateを満たすことをHard Constraintとし、その範囲でだけ変更量、探索範囲、コンテキスト、トークン、テスト時間、修復回数を最適化する。

別のエージェントやスキルへ作業を渡す場合、全文の貼り付けを固定ルールにしない。受け手が参照できるファイルパス、対象範囲、受け入れ条件、固定要件、既存変更、期待する成果物を欠落なく伝える。

## 6. 品質ゲート

| ゲート | 進行条件 |
|---|---|
| 設計へ | 目的、受け入れ条件、固定要件、スコープが判断可能 |
| Test Contractへ | 影響範囲と設計判断が、変更リスクに見合う粒度で記録済み |
| 実装へ | Required Observable、Proof Obligation、Evidence要件、固定制約が判断可能 |
| レビューへ | 対象POと回帰テストが通り、未検証Observableが明記済み |
| リリースへ | Must相当の指摘が解消し、高リスク変更はセキュリティ確認済み |
| 完了へ | すべてのRequired ObservableとRequired Outer GateがEvidence付きでPASSし、残課題と既知の制約を明記済み |

ゲートを満たさない場合は、未達理由と次の安全な行動を示す。期限を理由に品質ゲートを黙って外さない。

## 7. デプロイと破壊的操作

デプロイ計画の作成と実行許可を分ける。実行はユーザーが明示的に求め、対象と影響を確認できた場合だけ行う。

高リスク操作の前に次を提示する。

- 正確な対象と操作
- 影響を受けるサービス、データ、利用者
- 現在の資源余裕と必要量
- 中断条件
- バックアップ、スナップショット、またはロールバック手順
- 実行後のヘルスチェック

不可逆で安全余裕が不足する場合は実行せず、代替案を提示する。

## 8. 完了報告

```markdown
## 完了結果

- 目的: <何を達成したか>
- 変更: <主要なファイル・契約・判断>
- 検証: <コマンドと結果>
- Acceptance Matrix: <Requirement × Observable × Evidence の PASS / FAIL / UNVERIFIED / BLOCKED / INVALID_EVIDENCE>
- セキュリティ・運用: <確認内容または対象外の理由>
- 残課題: <既知の制約、次の安全な手順>
```

「動いた」だけで完了としない。実行していないテストや確認できなかった外部状態は、そのまま明記する。

## アンチパターン

- 仕様や成功条件が不明なまま実装を始める
- 小変更にも重い儀式を強制し、実装より文書が目的になる
- 古い文書の環境情報を現在の事実として扱う
- ユーザーの未コミット変更を自分の変更として上書きする
- 専門スキルが無いことを理由に必要な品質確認を省く
- トークンや時間を理由にRequired TestまたはRequired Observableを省く
- GreenにするためTest Contract、Required Test、Expected Resultを弱める
- テスト成功だけで、受け入れ条件・影響範囲・運用健全性を確認しない
- 計画の承認を、デプロイや破壊的操作の実行許可とみなす