反復構築(ピットイン方式参照モデル)

機能単位のAI協調サイクル(仕様承認 → AI実装 → 自動検証 → 独立レビュー)を数時間〜数日の粒度で反復する。3つのゲートはサイクルごとに機能単位で通過する

ワークフロー(第2階層)

各アクティビティをクリックすると、個別作業(第3階層)へ移動します。

graph LR
  a0["機能仕様サイクル"]
  a1["実装と検証"]
  a0 --> a1
  a2["独立レビュー"]
  a1 --> a2
  a3["コア機能の理解維持"]
  a2 --> a3
  a4["負債の記録"]
  a3 --> a4
  click a0 "/process-compass/phase4-process-design/process-model/construction/spec-cycle/" "機能仕様サイクルの詳細へ"
  click a1 "/process-compass/phase4-process-design/process-model/construction/build-verify/" "実装と検証の詳細へ"
  click a2 "/process-compass/phase4-process-design/process-model/construction/independent-review/" "独立レビューの詳細へ"
  click a3 "/process-compass/phase4-process-design/process-model/construction/core-understanding/" "コア機能の理解維持の詳細へ"
  click a4 "/process-compass/phase4-process-design/process-model/construction/debt-recording/" "負債の記録の詳細へ"

アクティビティ一覧

機能仕様サイクル — 機能ごとに AI が仕様と実装計画を起案し、人が承認してから実装に入る(SDD 式)(担当: 価値責任者(Value Owner)、AIエージェント)
実装と検証 — AI が実装・テスト生成し、CI 通過後に開発者が挙動を検証して理解を記録する(担当: AIエージェント、開発者(検証者))
独立レビュー — 作成を指示した本人ではない人間がレビューする。人間側の理解を組織に分散させる工程でもある(担当: 独立レビュア)
コア機能の理解維持 — 企画時にコア指定した機能は、開発者が設計レベルまで読み解き、判断記録を残す(事業継続性の担保)(担当: 開発者(検証者)、技術判断者(Tech Lead))
負債の記録 — 生成過程で見つけた負債・受容した妥協を台帳に記録する(見なかったことにしない)(担当: 開発者(検証者)、AIエージェント)

このフェーズの出口ゲート

機能仕様承認(反復内)

Deliverables	機能単位の仕様(AI起案) / 実装計画(タスク分解)
判定基準	機能仕様に検証可能な受入基準が含まれる / タスク分解の粒度が1タスク=1レビュー単位 / 対象機能のコア/非コア指定が明示されている / 各タスクの規模が分割基準の範囲内である / 合意した範囲の内か外かの判定が記入されている
判定者	価値責任者(または明示的に委譲された機能責任者。委譲しても結果責任は価値責任者に残る)
判定結果	承認して実装へ / 修正

※ SDD 式の人間承認ゲート。ここを飛ばすと vibe coding 化する(統制強度の要)

自動検証(CI)

Deliverables	コード+テスト一式
判定基準	全テストが GREEN / 静的解析・脆弱性スキャンの重大指摘 / テストカバレッジ / 曖昧語チェック(仕様変更を含むPRの場合) / 依存関係のライセンス検査 / 文脈ファイルの形式検査 / 秘匿情報の混入検査 / 依存関係の追加・更新の識別
判定者	CI(機械判定)
判定結果	通過 / 差し戻し(マージ不可)

※ 合意済みルールはすべて機械化してここに載せる(人の目を通さない)。人間の検証帯域を判断業務に温存するための設計

独立レビュー

Deliverables	PR(コード・テスト・判断記録)
判定基準	仕様(受入基準)と実装が一致している / レビュアが挙動を自分の言葉で説明できる / (コア機能のみ)設計意図の記録が完備 / レビュアが作成の指示者本人でない / (依存の追加・更新を含む場合)追加の必要性を確認した
判定者	独立レビュア(作成指示者本人の承認は数えない。ブランチ保護と出荷の証跡の集約の2つの層で止める)
判定結果	承認 / 差し戻し

※ 日本のレビュー文化をAI時代の統制として再利用する。G-6 は同じ開発ラインの別の人による確認であり、第三者レビューとは呼ばない。レビューの目的は儀式でなく「人間側の理解の維持」(BCP)