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

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

AI駆動開発の実運用ノート No.52人間が出すのは答えではなく原則と反例

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

人間側の作法人間は「答え」でなく「原則」を与える

実装案を自分で書かず判断の材料を渡して AI に設計させる
人間がやること実際に言った言葉・とった行動なぜ効くか
方針だけ伝える「この2社の商品は、互いのサイトに出さない」と原則だけ示す細部は AI が自分で設計し直せる
具体例でダメ出しする「その方式だと、店が退会したら返金を回収できないですよね?」抽象的な「ダメ」より速く正解に近づく
資料に立ち返らせる「まず既存の仕様書を読んで」と調べさせる答えは大抵もう文書に書いてある
自分で確かめる完成報告を鵜呑みにせず、自分で画面を操作する報告の外にある欠陥(他社商品が買える等)が見つかる

ほかに: 中途半端でなく最も徹底した案を選ぶ / 承認は仮とし裏取り後に確定 / 着手の時期を管理する / 決定を記録に残させる(配布資料に全8型)

では、大規模変更のとき人間は具体的に何をするのか。 ポイントは実装案を自分で書かないことです。判断の材料を渡して、設計そのものはAIにさせます。

やることは4つあります。 方針だけ伝えます。「この2社の商品は、互いのサイトに出さない」。 具体例でダメ出しします。「その方式だと、店が退会したら返金を回収できないですよね」。 資料に立ち返らせます。「まず既存の仕様書を読んで」。 そして、自分で確かめます。完成報告を鵜呑みにせず、自分で画面を触ります。

抽象的な「ダメ」より、具体例によるダメ出しのほうがAIは1桁速く正解に近づきます。

人間が出すのは答えではなく、原則と反例です。

つづく