プロセス横断比較表
フェーズ1で調査した各プロセス(プロセス体系)を、共通スキーマのデータから自動集計した比較表です。個別の詳細は各プロセスのページを参照してください。
本プロジェクトが設計したピットイン方式参照モデルは、この比較表に含めていません。調査対象の既存プロセスと同じ表に並べると、比較の公平性が問われるためです。別表として末尾に示します。
既存プロセスの一覧比較
| プロセス | 種別(粒度) | フェーズ数 | ロール数 | ゲート数 | 意思決定の性格 |
|---|---|---|---|---|---|
| AIDLC(AI-Driven Development Life Cycle) | ライフサイクル | 3 | 6 | 4(4決/0検) | 決裁(事前承認・集中) |
| ウォーターフォール開発プロセス(日本の SIer 標準形) | ライフサイクル | 8 | 6 | 9(9決/0検) | 決裁(事前承認・集中) |
| スクラム(Scrum) | ライフサイクル | 1 | 3 | 4(2決/2検) | 混在 |
| アジャイル(Agile) | 価値観の傘 | 1 | 3 | 1(0決/1検) | 検査(事後適応・分散) |
| テスト駆動開発(TDD) | プラクティス | 2 | 2 | 3(0決/3検) | 検査(事後適応・分散) |
| 仕様駆動開発(SDD, Spec-Driven Development) | プラクティス | 5 | 4 | 4(4決/0検) | 決裁(事前承認・集中) |
| イベント駆動(Event-Driven Architecture / イベント駆動開発) | 設計手法 | 3 | 4 | 4(0決/4検) | 検査(事後適応・分散) |
| ドメイン駆動設計(DDD) | 設計手法 | 3 | 3 | 3(0決/3検) | 検査(事後適応・分散) |
| ハイブリッド開発(なんちゃってアジャイル / ウォーター・スクラム・フォール) | ハイブリッド実態 | 3 | 4 | 3(3決/0検) | 決裁(事前承認・集中) |
ゲート数の「決」=決裁型(Go/Kill の事前承認)、「検」=検査型(検査して適応、承認を伴わない)。
軸1: 意思決定は「集中」か「分散」か
最も本質的な違いは、意思決定をフェーズ末の関門に集中させる(決裁型)か、反復のたびに分散・常時化する(検査型)かです。
- 決裁型(事前承認・集中): ウォーターフォール、AIDLC、仕様駆動開発(SDD)、ハイブリッド開発。節目で人間が Go/Kill を判断する。日本の稟議・DR 文化と構造的に親和する
- 検査型(事後適応・分散): スクラム、アジャイル、TDD、DDD、イベント駆動。事前に固めて承認するのではなく、作ってから検査して直す。原典は決裁ゲートを意図的に持たない
生成AI時代の SDD・AIDLC が決裁型に「回帰」している点は示唆的です。AIが高速に生成するからこそ、人間が要所で承認するゲート(Human-in-the-loop)を明示的に置く——これが「場当たり生成(vibe coding)」との分かれ目になっています。
軸2: 粒度(どの層の話か)
同じ「開発プロセス」でも扱う層が違います。ウォーターフォール・スクラム・AIDLC は開発の全工程(ライフサイクル)ですが、TDD は開発者の数分単位の技法、DDD・イベント駆動は設計手法です。比較や導入判断のときは、まず粒度を揃えて考える必要があります。
軸3: ロールは「承認者」か「協働者」か
決裁型プロセスのロールは承認者・判定者(誰が Go を出すか)を中心に定義されます。一方、DDD やイベント駆動は「ドメインエキスパートと開発者の協働関係」をロールとして定義し、承認者を置きません。この違いは、日本企業がプロセスを導入する際に「既存の職位階層・決裁権限規程」とどう噛み合うかを左右します(詳細は日本企業の組織論の整理ページで扱います)。
参考: 本プロジェクトの提案
次は本プロジェクトが設計した参照モデルであり、調査した既存プロセスではありません。上の比較表と同じ軸で集計していますが、 既存プロセスとの優劣を示すものではない点に注意してください。本体はフェーズ4(本標準)の一部であり、設計の根拠は附属書Aにあります。
| 参照モデル | フェーズ数 | ロール数 | ゲート数 | 意思決定の性格 |
|---|---|---|---|---|
| ピットイン方式参照モデル | 5 | 10 | 11(10決/1検) | 混在 |
この比較の使いみち
この比較軸(意思決定の集中/分散、粒度、ロールの性格)は、フェーズ3のギャップ分析で「理想(AIDLC 等)と現状(日本の決裁文化)の差分をどこで埋めるか」を考える土台になります。各プロセスの暗黙の前提条件とアンチパターンも、そのまま導入時のリスクチェックリストとして使えます。