AI駆動開発で、
要件からUATまでをつなぐ。

PROCESS SHIFT

工程をなくすのではなく、検証の循環を短くする

実行基盤：版管理した仕様・リポジトリ・隔離実行環境・CI・課題管理を接続。失敗が続く場合は回数・費用の上限で停止し、未解決事項とログを担当者へ返します。

PHASE BY PHASE

全9工程：進め方と成果物の比較

AI側の成果物は、既存の検収・監査に必要な文書も含めて維持します。各工程名を選ぶと該当する比較へ移動できます。

PROCESS DEFINITION & EDITABLE SAMPLES

全工程定義と成果物サンプルを、自社の開発へ

全工程定義書＋9工程の成果物文稿＋企業別カスタマイズガイド、全11文稿。架空の経費申請システムを共通例に、要件・設計・テスト・UATを同じIDでつなぎます。

企業内でコピー・編集して利用できます。記入済みの設計例と、企業固有の記入欄を収録。コード例は説明用で、稼働するアプリ一式ではありません。テスト結果・証跡・承認は未実施として記載しています。

自社向けに改善する手順

1. 企業設定を決める企業名、対象業務、責任者、技術構成、品質基準、AI実行上限、正式成果物を定義。
2. 例文と記入欄を変更する企業別ガイドに沿って例示条件を置換。変更した要件に合わせてAPI・データ・テストも更新。
3. 1機能で検証し、企業版として保存する実測結果と承認を登録し、手戻り・品質・総費用を確認。改善理由と版を記録して次案件へ再利用。

ONE REQUIREMENT, END TO END

実践例：経費申請の承認機能をつくる

架空の社内アプリの例。要件ID「REQ-014」を、すべての成果物の共通キーにします。

1. 仕様を確定「申請者は自分の申請を承認できない」。承認権限、代理承認の対象外、監査ログの保存項目を業務担当者と合意。
2. AIが設計・実装権限表、API契約、DB変更、UI、PRを生成。REQ-014に設計と変更差分を紐づける。
3. AIが検証・修正正常承認、自己承認の拒否、権限なしアクセス、二重承認を検証。失敗時は修正し、関連テストも再実行。
4. 成果物を束ねる仕様の版、コミット、環境、テストデータ、実行日時、合否と証跡を受入レポートに記録。
5. 利用部門がUAT実際の申請業務で確認。未解決事項を確認して承認を記録。受入後の本番反映は別のリリース判断として扱う。

要件変更時：REQ-014の仕様を更新 → 影響する設計・コード・テストを抽出 → 再生成と回帰テスト → 変更後の条件で再受入。古い合格結果を流用しません。

TEAM & DELIVERABLES

担当者の仕事を、作成から定義と検証へ

受入時にそろえる成果物セット

合意済み仕様と変更履歴 ／ 設計判断とAPI・データ定義 ／ ソースとビルド手順 ／ 自動テストと実行証跡 ／ 要件追跡表 ／ 残存不具合と対応方針 ／ 運用・移行・復旧手順 ／ UAT承認記録。

90-DAY TRANSITION

既存案件から移行する4ステップ

コード生成量より、受入までの成果を測る

• リードタイム：要件合意からUAT承認までの経過時間。
• 総作業時間：仕様整理・レビュー・修正・再試験・受入を含めた人の時間。
• 品質：要件の検証網羅率、UAT一発合格率、重大な残存不具合、受入後の流出不具合。
• 総費用：人件費＋AI利用料＋CI・検証環境費＋導入費＋運用・手戻り費。削減率は実測して判断。