AI要件定義は版管理を先に決める
要件定義の場でAIを使うと、版が増える。増え方が速い。
午前中にたたき台を1本出したつもりでも、昼には差分入りの2本目ができる。夕方には、誰が直したのか分からない3本目が残る。しかも見た目はどれもそれらしい。ここで事故が起きる。
AI要件定義の版管理で一番まずいのは、どの版が正なのかを決めないまま、AIだけ速くすることだ。
変更差分の話はすでに AI要件定義は変更差分から始める で整理した。状態の話は AI要件定義は状態遷移を先に決める で触れた。
その上に乗るのが版管理だ。差分が分かっていても、版の扱いが曖昧なら、チームは最後に迷う。
AI要件定義の版管理で最初に決めること
版管理というと、ファイル名に `v1` や `final` を付ける話だと思われやすい。実際はもっと広い。
「どの版を正とするか」「誰が承認したか」「どこへ戻せるか」を先に決めること だ。
この考え方は、変更管理を扱う資料でも共通している。たとえば Acsimの要件定義における変更管理 は、変更を計画的に扱う前提を明示しているし、DreamOnの変更統制 も、変更の入口・影響評価・承認・反映・追跡を分けている。
Azure DevOpsの変更管理 でも、変更要求をバックログに載せ、合意されたプロセスで扱うことが前提だ。要件管理の ONES.com も、要件階層とトレーサビリティを重視している。
つまり、版管理は単なる整理ではない。合意の置き場 だ。
| 決めるもの | 最低限の定義 | 放置すると起きること |
|---|---|---|
| 入口 | 変更依頼はどこに集めるか | Slack DM、口頭、メールで散る |
| 差分 | 何が変わったかを一行で書けるか | 何を直した版か分からない |
| 再合意 | どの版で誰が承認したか | 後から「聞いていない」が起きる |
| 戻し先 | どの版に戻せるか | 誤った修正を残したまま進む |
この4つが決まると、AI要件定義の版管理はかなり実務になる。逆に、ここがないと、AIは速い議事録を量産するだけになる。
版が増えると、議論はすぐ迷子になる
現場では、版が増えるほど「どれを直すか」の会話が長くなる。
人間だけで回していた頃は、多少雑でも追えた。だがAIを入れると、初稿、修正版、確認版、差し戻し版が短時間で増える。ここで版の責任線がないと、レビューが機能しない。
AI要件定義の版管理が効くのは、次のような場面だ。
- 受け入れ条件を書き換えた
- 例外条件を追加した
- 権限境界を変えた
- 画面ではなく運用を先に直した
こうした変更は、差分だけ見ても足りない。どの版に反映したか、どの版を人間が承認したかまで必要になる。
この見方は、AI要件定義は変更差分から始める の次の段階だ。差分が分かっても、版が分からなければ追えない。
だから、AIを使うときは「何を作るか」より先に、「どの版を正とするか」を決めた方がいい。版の正本が決まれば、AIが出した案を止める場所も見える。
実務で使う順番は5つで十分
AI要件定義の版管理は、重いルールにしなくていい。まずはこの5手で十分だ。
- 変更受付の窓口を1つにする
口頭・DM・メールで分散させない。入口が1つなら、版も追いやすい。
- 版名のルールを固定する
`draft`、`review`、`approved` のように、状態が名前で分かるようにする。番号だけだと意味が薄い。
- AIが触る版と、人間が確定する版を分ける
AIは下書きまで。承認済みは人間の責任で固定する。ここを混ぜると事故が起きやすい。
- 差分を版にひもづける
どの変更要求が、どの版に入ったかを残す。変更理由と版が切れると、あとで追えない。
- 戻し先を先に書く
失敗したら、どの版に戻すかを決めておく。戻し先がない版は、実務では不安定だ。
この順番は、AI要件定義は例外条件を先に決める と相性がいい。例外条件がないと止められないし、版管理がないと戻せない。両方そろって、ようやく運用になる。
再合意を楽にするには、版を読める形にする
版管理の本質は、履歴を保存することではない。再合意を短くすること だ。
再合意が長引くチームは、だいたい次のどれかで詰まる。
- 変更理由が消えている
- どの版が確定版か分からない
- 承認者が曖昧
- 版の差分が人間の頭の中にしかない
こうなると、会議は毎回ゼロから始まる。AIがいても、会議は短くならない。
ここで効くのは、版を「ファイル」ではなく「判断の束」として扱うことだ。
たとえば `draft-01` は検討中、`review-02` は差分反映後、`approved-01` は確定済み、と意味を固定する。
名前が意味を持つと、レビューは一気に楽になる。
この考え方は、AI要件定義は状態遷移を先に決める の延長でもある。状態が分かれば遷移が分かる。遷移が分かれば、版の更新地点も見える。
チェックリスト
導入前に、次の5問へ yes/no で答えられるかを見れば十分だ。
- 変更の入口は1つか
- 版名のルールは決まっているか
- 人間が承認する版は固定されているか
- 差分は版にひもづいているか
- 戻し先は事前に書いてあるか
この5問に yes と言えないなら、AI要件定義の版管理はまだ途中だ。
逆に言えるなら、AIが出す案が増えても、チームは迷いにくい。
Atsumellの視点
AI要件定義の版管理は、文書整理の話ではない。運用の話だ。
版を決めるということは、誰が何を見て、どこで止めて、どの版に戻すかを決めることだ。
Kakusill のように、要件や差分をAIが読める構造に寄せると、この版管理はさらに扱いやすくなる。
単に文章を貯めるのではなく、変更理由、差分、承認、戻し先を同じ構造で持てば、AIと人間が同じ版を見やすい。
もし、要件定義をAI前提で回したいのに、版管理が会議ごとに崩れているなら、直す順番は一つだ。
まず版管理を先に決める。そこからなら、変更差分も状態遷移も、ようやくつながる。
Atsumell では、AIが読める要件構造と、変更に強い上流工程の設計を支援している。版管理から見直したいなら、お問い合わせ から相談してほしい。
