AI駆動開発による“脱・ドキュメント”のすゝめ

なぜ私たちは「包括的なドキュメント」を辞められなかったのか？

ビジネス側で働く身として、なぜドキュメントの作成・提出を求めることを辞められなかったのか、そして、AI駆動開発によってどう変化したか。

Transcript

1. なぜ私たちは「包括的なドキュメント」を辞められなかったのか？ AI駆動開発による“脱・ドキュメント”のすゝめ
2. アジャイル、なのに「設計書をください」 “ 包括的なドキュメントよりも、 動くソフトウェアを。 — アジャイルソフトウェア開発宣言 ところが、大企業でアジャイル開発に取り組むと — ビジネス部門は、アジャイル原則に反して、 「包括的なドキュメント」仕様書・設計書を辞めることがなかなかできない。 01
3. なぜ、ビジネス部門はドキュメントを求めるのか 要件定義書 基本/詳細設計書 テスト仕様書 「このシステムが、何を、どう処理 するのか」が表現されたドキュメント 責任 ステークホルダーから日々さまざまな質問を受け、 それに回答する責任を負っている。 対処 質問を受けたら、ドキュメントから該当箇所を探す。 分からなければ開発者に質問する。 恐怖 時が経って、メンバーが入れ替わると、 当時の決定事項はドキュメントからしか分からない。 02
4. 03 しかし、ドキュメントは陳腐化する ドキュメントは作られた瞬間から、陳腐化が始まる。 長い運用を経て、仕様変更や機能の追加を重ねることで、 現実の挙動と更新漏れのドキュメントのズレが積み重なり、ドキュメントへの信用はだんだんと損なわれていく。 100 50 0 ▲ 要件定義 ▲ 設計 ▲ 実装 ▲ テスト ▲ 半年後 ▲ 1年後 ▲ 3年後 独自調査に基づく時間経過に伴うドキュメント信用度の変化(2026) 設計の不備を 実装で吸収 テストをパスするために 仕様の変更が始まる 初期メンバーの 離脱が始まる 動いているものが 公式の仕様となる
5. 04 AI駆動開発によって生じた変化 Issue / MR マークダウン形式で 詳細に記述する ADR コードに表現されない 重要な決定はADRを作成し 記録として残す TDD / DoD 受け入れ基準を明確にし テストコードに表現 AI駆動開発を実践する中で、AIに正しいコードを書かせるために、 「価値あるドキュメント」をGitLab内に作成・保管するようになった。 — 通常これらは、開発者が使うドキュメント。ビジネス側のPOが読むものではなかった。
6. 05 GitLab Duoが、POに「質問する自由」をくれた BEFORE “それらしい”設計書を探す日々 • ステークホルダーからの質問を理解する • それらしい処理の設計書を開く • それらしい箇所を眺める • 信用できるかは、わからない AFTER 最新のコードに、自然言語で聞く › いつでも、最新のコードを根拠に質問できる › 自然言語でピンポイントに答えが返る › 出どころは“いま動くリポジトリ”そのもの › 信用ならないドキュメントからの卒業