【発展編 第1回】SDDを"雰囲気"で回さない——「二階層SDLC」という提言

本連載では、品質を3つの軸で捉えます——
①設計書適合（仕様どおりか）
②暗黙要件（仕様に書かれない当たり前）
③本質要件（本当に達成したい目的）

SDDは広まった。だが「ちゃんと回せているか」は別問題

AIコーディングエージェントの普及で、SDD（Spec駆動開発。仕様をソースオブトゥルースとし、コードはそこから派生する二次成果物として扱う開発）が主軸になりつつある。これは歓迎すべき流れだ。

ただ、現場を見ていると気になることがある。SDDツール（GitHub Spec Kit 等）が示す「Specify → Plan → Tasks → Implement」の4フェーズを回すこと＝SDD、と捉えて、なんとなく走り出しているケースだ。この4フェーズは強力だが、1機能／1ユーザーストーリー単位で設計されている。プロジェクト全体をこの粒度だけで回そうとすると、無理が出る。

"雰囲気SDD"が壊れる場所

全体を一枚のフラットなSDLCとして描くと、本来プロジェクト全体で決めるべきこと——アーキテクチャ、体制、全体のテスト戦略、機能間の境界——まで、機能単位の Specify が抱え込むことになる。結果、Specify が肥大化し、Specify と Tasks の粒度バランスが崩れる。戦略的なアーキテクチャ判断と、戦術的なタスクリストが、同じ機能フォルダに同居してしまう（Krishnan, 2026）。

そして品質の観点で最も痛いのは、②③をどこで作り込むか、全体の品質戦略をどこで決めるかの「場所」が無くなることだ。機能サイクルを速く回すほど、戦略が宙に浮いたまま大量のコードが流れていく。

提言：SDDは「二階層」で回す

ではどうするか。本編の立場はシンプルだ。SDDを二階層のSDLCとして明示的に分ける。

階層1：プロジェクト全体サイクル——プログラム／リリース／システム全体のガバナンス層。骨格は従来工程（要件定義→基本設計→開発→結合→ST/UAT→リリース→運用）と大きく変わらないが、各フェーズにAI時代の要素が入る。要件定義で多層バリデーション戦略・QEハーネス戦略・Reference Oracle戦略・全体テスト計画を定め、基本設計で仕様横断の境界を切り、運用ではShift Right（テレメトリ・ドリフト検知・カオス）を回す。全体の品質戦略とアーキテクチャは、この層で決める。

階層2：機能単位サイクル——おなじみの Specify → Plan → Tasks → Implement。1機能ずつ仕様から実装まで通し、UTやIntra-Feature ITはサイクルに内在化してAIが自動生成する。速さは、この層が生む。

二つの層は、こうつながる

二階層は別々に動くのではなく、接続点で噛み合う。

• 階層1の要件定義で多層バリデーション戦略を決める＝階層2の各機能を「何で検証するか」を先に定める

• 階層1の基本設計で仕様横断境界を切る＝階層2の機能が独立して並行発動できる境界をつくる

• 階層1のSDD開発フェーズの中で、階層2の機能サイクルが並行発動する

• 階層2でできた成果物が、階層1のCross-Feature IT・ST/UATへ積み上がる

つまり、全体層が「何を・どう検証するか」と「どこで切るか」を決め、その枠の中で機能サイクルを高速に回す。この分担があってはじめて、Specifyを肥大化させずに速さを得つつ、②③を作り込む場所を確保できる。

まとめ

SDDをちゃんとやる、とは、4フェーズを回すことではない。機能単位サイクルを速く回しつつ、その上にプロジェクト全体のガバナンス層を必ず置くことだ。全体層が品質戦略・アーキテクチャ・境界を決め、機能サイクルが速さを担う。この二階層を分けないまま"雰囲気"で走ると、Specifyが膨れ、品質戦略は宙に浮く。SDDの速さを活かすほど、上の層の設計がものを言う。

▼連載の全体像と各回へのリンク（連載インデックス）

本稿および本編は個人の見解であり、所属する組織を代表するものではありません。
問い合わせ先：terumitsu.takahashi.qe [at] gmail.com