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

本編の目次 › 第2部 要件定義と設計 › 大規模な要件追加・仕様変更の作法

AI駆動開発の実運用ノート No.54「小さな変更」が実測で12ファイル40箇所になった

AI と併走してチケット販売サービスを本番運用まで到達させた記録を、そのまま文字に残しています。今回は第2部「要件定義と設計」から、「大規模な要件追加・仕様変更の作法」のお話です。

失敗事例「小さな変更」が実測で別物になった

プランの承認は「差分規模」への承認を含意する
事故

「影響は一部のみ」の見積もりで承認されたスキーマ変更が、実測12ファイル・40箇所超に化けた

根本原因

影響範囲を実測せず印象で見積もった。型の波及はコンパイラを回さないと分からない

ルール

提案前に読取箇所を数え、5箇所超はコンパイラ試走で実数確認。プランに「N ファイル/M 箇所(実測)」を明記

強制する仕組み

実測が承認時の前提を超えたら、進めずに戻って再承認(運用ルール)

設計メモに「実測」を書け、という理由がこの失敗です。

あるスキーマの変更について、AIが「影響は一部だけ」と見積もり、その前提で承認を得ました。 ところが実装してみると、12ファイル・40箇所以上に影響が出ました。

原因は、影響範囲を実際に測らず、印象で見積もっていたことにあります。 そこで、5箇所以上の影響が予想されるなら、コンパイラを試しに走らせて実数を確認してからプランに書く、という対策になりました。

プランを承認するというのは、実は「その差分の規模」を承認していることでもあります。 「小さな変更」という言葉を鵜呑みにしないでください。実録は事例12にあります。

つづく