カンリー、AI-DLC 3回でPBI日数3割減

カンリーの福利厚生チームは、この記録を書く前にすでにAI-DLCを3回実施していた。1回目はレビュー済みのモックから始まり、そのため詳細化がUIを言葉にする後ろ向きの作業になったとチームは述べ、エンジニアからは固定されたUIに縛られている感覚が報告された。2回目は、ユーザーに提供されコンテンツも保持するマスタを無効化する作業に取り組んだ。この変更では全画面とAPIにわたる確認が必要で、セッション中盤にチームはそのマスタが2つの役割を持つことに気づき、役割ごとにテーブルを分割する提案は、出席していなかったプロダクト側の意思決定者の懸念を招いた。エンジニアはその後3案を比較し、作業量が最小の中間案がプロダクト側の同意を得た。これは開発チームが当初想定していたものと一致したため、手戻りは起きなかった。チームはまた、もし見積もりが方向性を変えていたら、エンジニア3人の約2日分の作業が手戻りになった可能性があると注記している。

2回目の振り返りから5つのステップが追加され、3回目ではそれらを3件のアカウント発行PBIで試し、APIとDB設計を3日で終えた。本文はむらのある領域と成果の両方を報告している。意思決定の記録とQ&Aは散在して見つけにくかったが、19件の意思決定は保持された。ブラウザで読める成果物により、質の低い画面共有による苦労が減った。AIへの質問は、長所と短所を求めたときにだけ選択肢を出した。チームはまた、ドメインモデリング中に違和感を覚え、実装で吸収できると仮定したが、後に発行側の実装がドメインモデルの扱いと衝突していることが分かり、仕様への影響がないことを確認した上でドメインモデル側で修正した事例も述べている。

本文自体、完了日数の短縮を参考値と位置づけている。複雑さとサンプル数はそろっておらず、短縮の原因も特定されておらず、実作業時間も記録していないため、チームはベースラインから始める。AI-DLCを検討するチームにとって、ここでの価値は3割という数字よりも、Tierベースの影響判断、詳細化と構築の分離、意思決定の記録といった具体的なプロセス改善にあるのかもしれない。本文によれば、これらは3回目にも引き継がれたという。