ピットイン方式参照モデル
フェーズ4: AI協調型ソフトウェア開発プロセス標準／ 本ページは本標準が規定する構造の機械可読表現です
フェーズ1〜3の分析を踏まえて本プロジェクトが設計した提案プロセス。外側は日本の決裁文化と整合する事業ゲート、内側はAIと人が高速で回す協調ループの二層構造で、5つのギャップへの打ち手を構造に織り込んだ参照モデル
ひとことで言うと: 外側は日本の決裁文化に合わせた節目のゲート、内側はAIと人が高速で回す実装ループ。技術の判断と事業の決裁を分け、決める人を1人にし、作った本人以外がレビューする——この4つの原則で「AIは速いが承認で詰まる」を防ぐ
全体マップ(第1階層)
各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。
graph LR ph0["企画・立ち上げ"] ph1["要件・仕様定義"] ph0 -->|"企画承認"| ph1 ph2["反復構築"] ph1 -->|"要件合意 / 技術設計判断"| ph2 ph3["リリース準備"] ph2 -->|"機能仕様承認(反復内) / 自動検証(CI) / 独立レビュー"| ph3 ph4["運用・改善"] ph3 -->|"出荷判定 / リリース決裁"| ph4 click ph0 "/process-compass/phase4-process-design/process-model/kickoff/" "企画・立ち上げの詳細へ" click ph1 "/process-compass/phase4-process-design/process-model/requirements/" "要件・仕様定義の詳細へ" click ph2 "/process-compass/phase4-process-design/process-model/construction/" "反復構築の詳細へ" click ph3 "/process-compass/phase4-process-design/process-model/ship/" "リリース準備の詳細へ" click ph4 "/process-compass/phase4-process-design/process-model/operate/" "運用・改善の詳細へ"
目的と成果
目的(purpose): 生成AIの生産性と日本企業の統制(品質保証・決裁・検収)を両立させ、企業の品質管理部門・プロセス部門へ提案・承認可能な形で AI 協調開発を運用できるようにする
成果(outcomes):
- AI生成の速度を殺さずに、すべての成果物に単一の人間の責任者が紐づいている
- 技術判断と事業決裁が分離され、承認滞留が構造的に抑制されている
- コア機能を人が理解し続ける状態が作業として維持されている(事業継続性)
- 暗黙知がコンテキスト基盤に蓄積され、チケットごとの明文化負担が減っていく
原典: Process Compass フェーズ4(2026)。ウォーターフォールの工程ゲート、スクラムの反復、SDD の人間承認ゲート、AIDLC の AI 協調、GitHub 式独立レビュー、日本の出荷判定制度を意図的に組み合わせた設計
ISO/IEC/IEEE 12207 対応: 主に「合意〜組織〜テクニカルマネジメント〜テクニカルを横断(統合モデルのため)。特に意思決定管理と品質保証の再設計が中心」プロセス群をカバー
ロール
| ロール | 責任 | 日本の現場での実態 |
|---|---|---|
| 価値責任者(Value Owner) | What/Why の決定と価値の説明責任を単独で持つ。要件合意・仕様承認の判定者。委譲しても結果責任は残る | 「1つの成果物に責任者は1人」の原則(ギャップG2対応)。事前の根回し・非同期コメントは歓迎するが、判定は単独で行い合議体にしない |
| 技術判断者(Tech Lead) | アーキテクチャ・技術選定・技術的トレードオフの判定を単独で持つ。技術設計ゲートの判定者 | 職位ではなく技術力量で任命する(ギャップG3対応)。事業決裁者は技術判断に関与しない |
| 開発者(検証者) | AI生成物の検証、挙動の理解、実装の細部判断。コア機能では設計レベルまで読み解き判断記録を残す | 役割の重心が「書き手」から「検証者・理解の維持者」へ移る。検証は承認の儀式でなく理解を保つための読み込み |
| AIエージェント | 仕様の起案支援、実装、テスト生成、ドキュメント生成、負債候補の検出。席の担い手として実行(R)を担う。提案はするが、判定と承認はしない | 結果責任(A)はAIでなく、席ごとの責任者(記名の自然人。席ごとに1名)が負う。AIの確認は検出の層であり、承認として扱わない |
| 独立レビュア | 作成を指示した本人とは別の人間として PR をレビューし、仕様との一致と理解可能性を確認する | 作成を指示した本人の承認は、独立した人の確認に数えない。ブランチ保護は最後に push した本人の承認を止め、PR の作成者が AI・bot の場合に残る指示者の承認は出荷の証跡の集約が数えない(第3章 3.5 の2つの層)。既存のレビュー文化と整合し、QA部門が担ってもよい。ただし G-6 を第三者検証とは呼ばない(附属書D) |
| 品質保証(出荷判定者) | 開発ラインの外の人として出荷判定を行い署名する。プロセス実行記録と品質エビデンスの確認が任務(再テストではない) | 既存のQA部門が担う席・判定者・時点は変えない。署名の意味は改める(出荷基準の充足と、記録と保証の開示の完備の確認。出荷判定の規程の改定を要する)。判定を「記録の確認」に限定して滞留を防ぐ |
| 事業決裁者 | 予算・スコープ・リリース可否という事業判断のみを行う。技術判断には関与しない | 既存の決裁権限規程どおりの職位でよい(制度を変えない)。関与を事業判断に限定することで専門性の乖離(G3)を無害化する |
| コンテキストオーナー | 恒久層コンテキスト(規約・用語・判断基準・判断記録)の保守と正しさに責任を持つ | コンテキスト基盤の要件R5。オーナー不在だと文脈が陳腐化しAIの品質が劣化する |
| AI維持管理者(AI Maintainer) | エージェント指示資産の一貫性と鮮度に責任を持つ。矛盾の除去・統合・削除の権限を単独で持ち、エージェントが用いる外部ツールの採用可否を承認する | 追加の権限を絞るのではなく削除の権限を集約する。追加を制限すると共有されない個人設定が増える |
| AI運用担当者(AIOps) | 全社のAI実行基盤(モデル接続・実行予算・セキュリティ統制)の可用性と適合性に責任を持つ。開発組織へは規程ではなく実行環境として統制を届ける | 案件の外側に置く。AI維持管理者との兼務は禁止(案件の都合で全社統制が緩むため) |
ゲート(決裁・レビュー)
| ゲート | 種別 | Deliverables | 判定基準 | 判定者 | 判定結果 |
|---|---|---|---|---|---|
| SG-0 探索完了(ステージ移行) ※既存の投資決裁制度に載せる。判断は go / hold / kill の三択とし、判断しないまま継続する状態を作らない | 決裁(Go/Kill) | 検証結果報告 / 事業仮説の更新 / 技術的実現性の評価 / 意思決定体制図(D-0) | 事業仮説が実証データで支持されている / 技術的実現性が確認されている / 次ステージの投資規模と体制が示されている | ステアリングコミッティ(B-2) | S1へ移行 / 継続検証 / 中止 |
| SG-1 価値確立完了(ステージ移行・部門間移管) ※部門間移管を伴う場合、移管は文書の受け渡しでは完了しない。受入側の再構成完了をもって成立する | 決裁(Go/Kill) | 利用実績と価値の実証データ / アーキテクチャ設計と判断記録 / 恒久層コンテキスト / 移管記録 | 実利用者における価値が実証されている / 拡大に耐えるアーキテクチャが確定している / 受入部門が要求を自らの言葉で再構成できている | ステアリングコミッティ(B-2)および受入部門の責任者 | S2へ移行 / 継続 / 中止 |
| SG-2 スケール完了(定常運用へ移行) ※このゲートを設けない場合、プロジェクト体制のまま運用が続き、負債の返却主体が消える | 決裁(Go/Kill) | 運用実績 / 運用体制と引き継ぎ文書 / 技術負債台帳と返却計画 | 対象利用者層に対する品質基準を満たしている / 運用体制が定常運用として成立している / 受容した負債の返却計画が承認されている | 事業決裁者および運用責任者 | 定常運用へ移行 / 改善継続 |
| G-1 企画承認 ※既存の稟議・決裁制度をそのまま使う(ここは変えない)。頻度が低いゲートなので多段決裁の遅さを許容できる | 決裁(Go/Kill) | 意思決定・エスカレーション体制図(D-0。承認済みであることが審議開始の前提条件) / AIエージェント安全リスクアセスメント表(適用条件に該当する案件のみ。審議開始の前提条件) / 企画書(事業意図) / コンテキスト基盤の整備計画と予算 | 投資対効果が事業基準を満たす / リスクと受容方針が明示されている / コンテキスト基盤の初期整備コストが予算に含まれる / 指標の閾値と予算区分が合意され記録されている | 事業決裁者(決裁権限規程どおりの職位) | 承認 / 差し戻し |
| G-2 要件合意 ※判定は単独(合議体にしない=G2対応)。関係者の意見は判定前の非同期コメントで集める(根回しの構造化) | 決裁(Go/Kill) | 機能仕様書(受入基準付き) / 更新済みコンテキスト基盤(案件層) | 受入基準が検証可能な形式で書かれている / 曖昧語が残っていない / 暗黙の前提が案件層コンテキストに登録済み / スコープ外事項が明記されている / 合意した範囲がスコープ3層へ割り当てられている | 価値責任者(単独。目安48時間以内に判定) | 合意 / 差し戻し |
| G-3 技術設計判断 ※事業決裁(予算)と完全に分離する(G3対応)。技術判断に決裁階層を通さない | 決裁(Go/Kill) | アーキテクチャ設計・技術選定案(AI生成+人レビュー済み) / 判断記録(ADR)案 | 非機能要件の充足見込みが示されている / 既存資産・コンテキスト基盤と整合している / 選択の可逆性が評価されている / 代替案が最低1つ比較されている / 事業影響が観測可能な事象で記述されている | 技術判断者(単独。目安48時間以内に判定) | 承認 / 代替案の要求 |
| G-4 機能仕様承認(反復内) ※SDD 式の人間承認ゲート。ここを飛ばすと vibe coding 化する(統制強度の要) | 決裁(Go/Kill) | 機能単位の仕様(AI起案) / 実装計画(タスク分解) | 機能仕様に検証可能な受入基準が含まれる / タスク分解の粒度が1タスク=1レビュー単位 / 対象機能のコア/非コア指定が明示されている / 各タスクの規模が分割基準の範囲内である / 合意した範囲の内か外かの判定が記入されている | 価値責任者(または明示的に委譲された機能責任者。委譲しても結果責任は価値責任者に残る) | 承認して実装へ / 修正 |
| G-5 自動検証(CI) ※合意済みルールはすべて機械化してここに載せる(人の目を通さない)。人間の検証帯域を判断業務に温存するための設計 | 検査と適応 | コード+テスト一式 | 全テストが GREEN / 静的解析・脆弱性スキャンの重大指摘 / テストカバレッジ / 曖昧語チェック(仕様変更を含むPRの場合) / 依存関係のライセンス検査 / 文脈ファイルの形式検査 / 秘匿情報の混入検査 / 依存関係の追加・更新の識別 | CI(機械判定) | 通過 / 差し戻し(マージ不可) |
| G-6 独立レビュー ※日本のレビュー文化をAI時代の統制として再利用する。G-6 は同じ開発ラインの別の人による確認であり、第三者レビューとは呼ばない。レビューの目的は儀式でなく「人間側の理解の維持」(BCP) | 決裁(Go/Kill) | PR(コード・テスト・判断記録) | 仕様(受入基準)と実装が一致している / レビュアが挙動を自分の言葉で説明できる / (コア機能のみ)設計意図の記録が完備 / レビュアが作成の指示者本人でない / (依存の追加・更新を含む場合)追加の必要性を確認した | 独立レビュア(作成指示者本人の承認は数えない。ブランチ保護と出荷の証跡の集約の2つの層で止める) | 承認 / 差し戻し |
| G-7 出荷判定 ※既存の出荷判定制度を活かす。判定は「記録と基準の突合」に限定し、ここで再テスト・再レビューを始めない(滞留防止=G5対応) | 決裁(Go/Kill) | 品質レポート / 技術負債台帳 / 全ゲート通過記録 | 計画したテストの消化率 / 未解決の欠陥 / 受容した負債の台帳記録 / 運用引き継ぎ文書 / 全ゲートの通過記録 / AI 品質指標の確認 / (安全関連ソフトウェアのみ)安全適合性の検証記録 / 知財潔白性の検査記録 / 保証の開示の完備 | 品質保証(開発ラインの外の人。署名する) | 出荷可 / 出荷不可 |
| G-8 リリース決裁 ※技術判定の通過が前提なので、ここは純粋な事業判断のみ。目安48時間以内。技術品質を蒸し返さないことを規程に明記する | 決裁(Go/Kill) | 出荷判定結果 / 事業影響評価 | 出荷判定(G-7)を通過している / 事業リスクの受容判断 | 事業決裁者 | Go / Hold |
成果物(information items)
| 成果物 | 作成者 | 説明 |
|---|---|---|
| 意思決定・エスカレーション体制図(D-0) | 価値責任者(Value Owner) | 決定の権限・権限境界(トレランス)・平常時と障害時のエスカレーション経路を1文書で確定させる。案件で最初に作る成果物であり、企画承認ゲートの前提条件 |
| AIエージェント安全リスクアセスメント表 | 技術判断者(Tech Lead) | 危険源の同定・リスクの見積り・3段階のリスク低減策・残留リスクの受容を記録する。適用条件に該当する案件で企画承認ゲートの前提条件となる |
| 企画書(事業意図) | 価値責任者(Value Owner) | 目的・価値仮説・概算予算・リスク。企画承認ゲートの入力 |
| コンテキスト基盤(恒久層・案件層) | コンテキストオーナー | 規約・設計標準・ドメイン用語・判断基準。AIと新規参加者への共通文脈。継続的に更新される |
| 機能仕様書(検証可能な受入基準付き) | AIエージェント | AI が起案し人が確定する。受入基準は検証可能な形式(例: EARS 記法)で書き、曖昧語を残さない |
| 実装計画(タスク分解) | AIエージェント | AI がタスク分解・依存関係・並列可否を生成し、人が承認する |
| 検証済みインクリメント(コード+テスト) | AIエージェント | AI が生成し、CI と人の検証・独立レビューを通過したもの |
| 判断記録(ADR) | 技術判断者(Tech Lead) | 設計判断・技術選定・リスク受容の理由。コア機能では必須。コンテキスト基盤へ還流する |
| 品質レポート | 品質保証(出荷判定者) | テスト消化率・欠陥状況・ゲート通過記録。出荷判定の入力。AIが生成しQAが確認する |
| 技術負債台帳 | 開発者(検証者) | 生成過程で検出・受容した負債の記録。返却計画とセットで管理し、運用フェーズで計画的に返す |
暗黙の前提条件(これが崩れると成立しない)
- 価値責任者・技術判断者に、名目でなく実際の決定権が委譲されている(組織がその決定を尊重する)
- CI 基盤(自動テスト・静的解析・脆弱性スキャン)が整備されている(g-ci の前提)
- 独立レビューを成立させる体制がある(作成を指示した者と別の人が確認する。2名で成立する)。出荷判定者まで分ける3者の兼務禁止は3名以上で成立し、3名未満では出荷判定の兼務を逸脱として表示する
- コンテキスト基盤の初期整備コストが企画時に予算化されている(明文化はただではない)
アンチパターン(建前 vs 実態)
ゲートの合議化
| 建前(あるべき姿) | 各ゲートは単独の判定者が期限内に判定し、関係者の意見は判定前の非同期コメントで集める |
|---|---|
| 実態 | 判定が会議体になり、全員の合意を待って滞留する |
| なぜ起きるか | 責任分散文化の慣性。単独判定への心理的抵抗 |
| 弊害 | ギャップG5(承認滞留)の再発。AIの速度が意味を失う |
独立レビューの形骸化
| 建前(あるべき姿) | レビュアが挙動を自分の言葉で説明できる状態まで読み込む |
|---|---|
| 実態 | 差分を眺めて即承認する(rubber stamp) |
| なぜ起きるか | レビュー量が増え、儀式として処理される |
| 弊害 | 人間側の理解が失われ、事業継続性(BCP)が崩れる |
コア指定のインフレ / ゼロ化
| 建前(あるべき姿) | 事業上致命的な機能だけをコア指定し、理解維持コストを集中させる |
|---|---|
| 実態 | 全部コア指定して理解維持が破綻するか、全部非コアにして BCP が崩壊する |
| なぜ起きるか | 線引きの判断を避け、一律にする方が楽だから |
| 弊害 | 理解維持が形骸化するか、障害時に誰も直せなくなる |
コンテキスト基盤の放置
| 建前(あるべき姿) | オーナーが保守し、運用の学びが書き戻され続ける |
|---|---|
| 実態 | 初期整備だけで放置され、実態と乖離した文脈をAIが参照し続ける |
| なぜ起きるか | オーナー不在(責任の割り当てを設計しなかった) |
| 弊害 | AI生成物の品質が静かに劣化し、原因が特定しにくい |
建前と実運用(日本の現場)
- 既存制度を壊さない設計を意図している。稟議・決裁権限規程(企画承認・リリース決裁)と、出荷判定の席・判定者・時点は変えず、その間に AI 協調ループを挟む。出荷判定者の署名の意味と、リリース決裁での残存リスクの受容の記名は改める(出荷判定の規程の改定を要する)
- 変えるのは4点。(1)技術判断を決裁階層から分離して単独判定者に委ねる、(2)ゲート判定を合議でなく「単独判定+事前の非同期コメント」にする、(3)出荷判定者の署名の意味を定め、残存リスクの受容を事業決裁者の記名へ置く、(4)トップマネジメントが品質保証の方針と受容の基準を記名する。3点目は出荷判定の規程の改定を、4点目はトップマネジメントの記名を要する。この4点が既存文化との最大の交渉点になる
- 独立レビュー・出荷判定という日本の検証文化は、AI時代にはむしろ統制上の資産になる(生成AIは人が承認し責任を持つ構造を要求するため)
フェーズ一覧(第2階層へ)
- 企画・立ち上げ — 事業意図を言語化し、AIと人の共通文脈(コンテキスト基盤)を整備する。ここでの明文化投資が以降の全フェーズの速度を決める
- 要件・仕様定義 — AIの問いを人が検証する協働セッションで仕様を固め、受入基準を検証可能な形式にする。技術設計判断もここで行う(事業決裁とは分離)
- 反復構築 — 機能単位のAI協調サイクル(仕様承認 → AI実装 → 自動検証 → 独立レビュー)を数時間〜数日の粒度で反復する。3つのゲートはサイクルごとに機能単位で通過する
- リリース準備 — 統合検証と品質エビデンスの整備。出荷判定(開発ラインの外の人)とリリース決裁(事業)を別の人が通過させる
- 運用・改善 — 運用しながら負債を計画的に返し、学びをコンテキスト基盤へ書き戻す。プロセス自体も検査と適応の対象