AI駆動開発の実運用ノート

本編の目次 › 第3部 実装→検証イテレーション › 検証の規律はどう生まれたか

AI駆動開発の実運用ノート No.66開発フローは3ヶ月かけて検証だけが厚くなった

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第3部「実装→検証イテレーション」から、「検証の規律はどう生まれたか」のお話です。

実録開発フローの形成史

3ヶ月の改訂はすべて「検証側の強化」だった
時期何が変わったか観察
初期ブラウザテストは1ステップだけ・「マージ = 完了」検証の場(staging)がまだ無かった
検証環境の構築直後の5日間開発→検証環境の2段検証・失敗時の入れ子イテレーション・「完了は検証後」——20ステップの骨格が固まる検証の場が生まれた瞬間に型が定義された
以降3ヶ月文書同期と一括検証の但し書きのみ追加実装手順はほぼ不変。厚くなったのは検証だけ

このプロジェクトの開発フローは、最初はブラウザテストが1ステップだけで、「マージしたら完了」でした。

ところが、検証環境の構築直後のたった5日間で、開発とステージングの2段検証、失敗時のやり直し、「完了は検証の後」という今の骨格が固まりました。

そして以降3ヶ月の改訂は、すべて「検証側の強化」でした。

実装の手順はほとんど変わっていません。厚くなったのは検証だけです。 このプロジェクトが何を大事にしたのかが、この形成史にそのまま出ています。実測は構築年表第4章にあります。

つづく