附属書A(参考) 設計の背景と由来

本附属書は、第1章から第8章に規定した要求事項について、その構造を採用した理由と検討の経緯を記録するものです。本附属書は参考です(第1章 1.5)。要求事項は本文に規定しており、本附属書の記述は適合の条件に数えません。

本標準の構造はピットイン方式参照モデルとしてスキーマ駆動のデータで保持しており、全体マップからフェーズ・個別作業へ掘り下げられます。本附属書と同じくフェーズ4に属します。既存プロセスの調査結果を集めたカタログとは別のものです。

A.1 二層構造を採用した理由

本標準は、事業判断の階層と開発反復の階層を分離した二層構造を採用しています(第2章)。

この構造は Water-Scrum-Fall と同型です。ただしフェーズ1で確認したとおり、ハイブリッドは「境界を意図的に設計すれば有効な形」になります。本標準は、その境界(どこまでが事業ゲートで、どこからが AI協調ループか)を明示的に設計した意図的ハイブリッドとして構成しています。

設計原則	内容	対応するギャップ
1. 判定者は1人	各ゲートは単独の判定者が期限内に判定する。意見は判定前の非同期コメントで集める	G2 責任主体の欠落
2. 技術と事業の分離	技術設計判断(技術判断者)と事業決裁(決裁者)を別ゲートにする	G3 職位ゲートと専門性の乖離、G5 承認滞留
3. 作成者は承認しない	AI成果物は、作成を指示した本人ではない人間がレビューする	G2、事業継続性(理解の分散)
4. 文脈は基盤に一度書く	恒久層・案件層のコンテキスト基盤に一度書き、AIが補完する	G1 明文化の壁、G4 兼務(文脈が人でなく基盤に宿る)

このモデルは新発明ではなく、フェーズ1〜2で体系化した各プロセスの実証済みの部品を意図的に組み合わせたものです。

要素	由来	参照
節目の決裁ゲート・出荷判定	ウォーターフォール(日本のSIer標準形)・JUSE型品質ゲート	ウォーターフォール
機能単位の反復・検査と適応	スクラム / アジャイル	スクラム
仕様承認→AI実装の流れ	SDD(Spec-Driven Development)	仕様駆動開発
AI協調・人間チェックポイント	AIDLC	AIDLC
「作成者は承認不可」の独立レビュー	GitHub Copilot coding agent の統制設計	エージェント型開発
自動検証ゲート(機械判定)	TDD / CI文化	TDD
コンテキスト基盤	コンテキストエンジニアリング	コンテキスト補完基盤

フェーズ2で確認したとおり、AI協調の最大の律速は人間の検証帯域です。このモデルは、次の設計で帯域を守ります。

運用の中で帯域が不足したときの手段は、第4章「帯域を理由に判定を省略しない」によります。

既存制度への変更は4点です。変更を小さく見せません。

変えない: 稟議・決裁権限規程(企画承認・リリース決裁)、QA部門が出荷判定を行う体制、作成者以外がレビューする文化(G-6 は同じ開発ラインの別の人による確認であり、第三者レビューとは呼ばない。語の定義は第1章 1.4 参照)
変える(4点):
- (1)技術判断を決裁階層から分離し単独判定者へ
- (2)ゲート判定を合議から「単独判定+事前の非同期コメント」へ
- (3)出荷判定者の署名の意味を定め、残存リスクの受容を事業決裁者の記名へ
- (4)トップマネジメントが品質保証の方針と受容の基準を記名し、組織として品質を保証すると主張できる形へ

3点目は、出荷判定の規程の改定を要します。品質保証部門の署名が何を意味するかを改める変更だからです(附属書H)。4点目は、トップマネジメントの記名を要します(ADR-0057)。この4点が、品質管理部門・プロセス部門への提案時の最大の論点になります。

参照モデルには前提条件があります(決定権の実質委譲、CI基盤、3者の兼務禁止が成立する体制規模、明文化コストの予算化)。前提を満たさない組織への調整方法は、テーラリングガイドで扱います。

本標準の限界は、次の箇所に書いています。

本節は所在だけを示します。限界の内容は、上の各箇所が正本です。