ドキュメント駆動（DocDD）で失敗して見えてきた AI時代のアジャイルにおける2つのキーワード

Transcript

1. ドキュメント駆動（DocDD）で失敗して見えてきた AI時代のアジャイルにおける2つのキーワード 2026年7月21日 株式会社アトラエ 田上 将吾
2. 自己紹介 株式会社アトラエ 田上 将吾 Tagami Shogo 経歴 非エンジニアとして大手企業からキャリアスタート、その後エンジニアに転向してスタート アップを経て、2020年に株式会社アトラエに入社。現在ではエンジニアとしてFrontendから Backendまでカバー。PJではPMやデザイナーとエンジニアの橋渡しとしてAI駆動開発の仕組 みの構築に取り組む。 現在なにをしているか 組織力向上プラットフォームのWevoxにて、巨大機能のフルリプレースPJを担当。中長期的 なプロダクト展開、グローバル展開を見据えた設計や品質のために日々格闘中。
3. 自己紹介 株式会社アトラエ 田上 将吾 Tagami Shogo
4. 前提 1 2 3 4 PM、デザイナー、エンジニア含めて9名のチーム 大規模な機能のフルリプレースを目的としたWevoxでも最も大きい開発チームのひとつ。特に中長期的なプロダクト の発展を考えた要件定義や仕様策定およびデザインの工数、そして設計から実装の手戻りなどが課題だった。 二週間のスプリントでスクラム開発 長期的な開発によって疲弊しないためのリズム作り、そして短期間での振り返りによる改善を見越して二週間単位の スクラム開発を採用。小さいユーザーストーリーに切ってスクラムイベントを回している。 使っているのはClaude Code、Notion、Figma、CodeRabbit エンジニアはClaude Codeを全員使っており、コミュニケーションや仕様整理はNotion、デザインなどを含めた仕様 ドキュメントとしてはFigmaを利用。Pull RequestのレビューにはCodeRabbit。 仕様駆動開発、DocDDは素晴らしいアプローチだが、工夫が必要 本発表は開発手法の是非を問うものではなく、あくまでこれらの開発手法をそのまま取り入れただけではうまくいか なかったというだけで、「私たちはこう実践している」などの経験があれば、ご教示ください。
5. 1Sprint(2週間) Sprint Planning Planning Poker 仕様策定 デザイン QA 実装 受入基準 仕様書 UIデザイン テスト計画書 リリース ...
6. 実装 Frontend DB Backend BFF Design System
7. 結論
8. 結論 AI駆動開発においてはこの２つが重要 質の高いAI駆動開発PJにおいて重要な考え方 境界づけられたコンテキスト (Bounded Context) + シフトレフト
9. ここに至るまでの 失敗
10. ここに至るまでの失敗 1 チームでの仕様駆動開発 仕様とコードを同期し続けるコストが高く、更新漏れ・ 不整合が発生。Gitベース管理は非エンジニアが参照・ レビューしづらいという問題があった。 3 ドキュメントの作りすぎ・共有しすぎ DocDDによって生まれたドキュメントをエンジニア以 外にも共有しても、職種やドメイン知識の偏りによって 分かりにくく、過度な情報共有になっていた。 2 プロセス高速化と認識のズレ拡大 AIによってコーディングが高速化した結果、「あれ、思 ってた成果物と違う」という事象が起きてしまいレビ ュー、コミュニケーションコストが増える... 4 早期でのモック作り込みの失敗 要件定義の段階でClaude Designなどでモックを作るも 「動くもの」はできても「いいもの」にするために要 件の見直しが必要になることが多かった
11. 失敗からの学び(1) チームでの仕様駆動開発の難しさ 「厳密な仕様駆動開発(SDD)」は、私たちのチーム開発ではワークしなか った...。 理由として、 ・完璧な仕様がないと実装を始めづらい ・コードとドキュメントの二重管理になり、メンテコスト増 ・コードが複数リポジトリに分かれているドキュメントも分散する そこで SDDからスピードを重視した軽量DocDDへ
12. 失敗からの学び(2) 従来のプロセスの効率化はチームに混乱を招く モックを作ったり、仕様書〜コードを自動生成するなどスクラムイベント 全体をAIで効率化しようとするも手戻りが発生することが多かった...。 既存コードや設計、デザインなどのコンテキストとプロダクトオーナーの 要件をもとに、AIがスクラムイベントを全て行うというのを試すも、質は 上がらず...。 そこで AIによって早められるところで境界を区切って効率化
13. 失敗からの学び(3) コーディングは早くなったけど、手戻りが発生していた コーディングがAIによって効率化されたものの、アウトプットに対しての 根本的なレビュー(設計、デザイン)で指摘されることで手戻りが発生する ことが多発...。 そこで 設計レビューをDay1に組み込む
14. そして、 こうなった
16. 例えば 担当者が注文状況を確認したい
17. 例えば 担当者が注文状況を確認したい 注文(Order) 在庫(Inventory) BE ドメインロジック(ex. 数量計算、税金, etc) ドメインロジック(ex. 在庫数、マイナス, etc) BFF 集約ロジック(ex. 値の合成、ステータス, etc.) BFF 集約ロジック(ex. フィルタ、整形, etc.) FE FE レイアウト、ロジック FE レイアウト、ロジック
18. 例えば 担当者が注文状況を確認したい BE BFF 注文(Order) 在庫(Inventory) ドメインロジック(ex. 数量計算、税金, etc) ドメインロジック(ex. 在庫数、マイナス, etc) スキーマ(Huma) スキーマ(Huma) 集約ロジック(ex. 値の合成、ステータス, etc.) BFF 集約ロジック(ex. フィルタ、整形, etc.) BEエンジニア FEエンジニア スキーマ(Hono) FE FE レイアウト、ロジック FE レイアウト、ロジック FEエンジニア、 デザイナー デザインシステムComponent
19. インターフェース・契約など決定論的な要素を超早期に設計する
20. 結果的に 変わったこと
21. 具体的にこう変わった 実装、レビュー段階の手戻りが激減 事前にドキュメントで方向性と外部境界を固定 内部規約はCIで担保し、想定外の出力を抑制 開発方針を覆す大きな手戻りがほぼゼロに、品質のブレも縮小 メンバーのナレッジ、カバー範囲が拡大 暗黙知が形式知になり、ナレッジが非属人化 ドキュメント中心で専門領域を横断（例：FEがBEの調査・設計に参画） 「なぜ作るのか」を意識し、顧客価値の理解が深化 自然と意思決定のドキュメントが溜まっていく 早期にドキュメントを作り、ドキュメントをもとにプログラミングをすることで意思決定履歴が追いやすい 設計からドキュメント作成をSKILLで定義することで、チーム状況に依存しすぎずアウトプットをつくれる テスト計画や単体/結合テストにも再利用でき、継続的な品質担保にも役立つ
22. 結論 AI駆動開発においてはこの２つが重要 質の高いAI駆動開発PJにおいて重要な考え方 境界づけられたコンテキスト (Bounded Context) + 軽量DocDD シフトレフト
23. そして お決まりの
24. We’re hiring!
25. Appendix
26. FAQ Q: 早期に設計しても、あとで仕様変更したら設計が変わるのでは？ A: 変わります。そしてそれでもOKです。設計が変わることも想定してラフな設計 を超早期に作ってメンバーのの認識をチームの土台に載せることが目的です。 Q: どうやってコンテキストごとに分離してる？ A: 現状は、ドメインエキスパートやエンジニアがユーザーストーリーをみて分離 の判断をしています。理想としてはこれをAIができるように土台を整えています。 Q: 設計レビューに時間がかかって後工程が遅れるのでは？ A: その場合は、早めに切り上げる判断をします。ただし、設計の精度やレビュー の粒度が原因の場合もあります。
27. FAQ Q: コードレビューの負荷は体感どれくらい変わった？ A: AIコーディングやハーネスの精度によるところも大きいのですが、そもそもの設 計に対するコードレビューはほぼゼロになりました。 Q: 仕様策定、デザインはどう変わった？ A: 早期に技術的観点がチーム全員に伝わることで仕様・デザインの“負荷”はあが ったものの、使用を決めた後の手戻りは大きく減りました。QAも同様です。 Q: どのようなドキュメントを作っているか A: 要件フェーズでは要件を表すモック画像、受入基準ではラフなAPI仕様書。複雑 な仕様の設計書は数SprintかけてNotion/Claude Artifactでドキュメント作成し、 それをチーム/AIでレビュー。
28. EOF