AI×アジャイル開発探検記 Vol.3 PBIだけでは不十分？複雑な機能をDDDの考え方で乗り越えた話

本記事は、AI×アジャイル開発探検記シリーズの3本目です。
前回の記事はこちら

AI×アジャイル開発探検記#2「PBI-based AI Driven Development」ー”なんか違う”をなくすためにPBI起点でAIと人間の認識を合わせる

はじめに：順調だったAI駆動開発に立ちはだかった壁

Vol.2で紹介した通り、私たちはPBIを起点にしたAI駆動開発に取り組んできました。
ログイン機能や一覧表示、登録・更新といった機能は、PBIを渡すだけでAIがかなりの精度で実装してくれました。
割と順調に開発できていたように思います。

ところが、ある機能の開発をきっかけに、私たちは壁にぶつかりました。
そこでこの経験を、ドメイン駆動設計（DDD）の視点で捉え直してみることにしました。
まず最初に、これまで順調だった理由を整理してみます。

---

汎用サブドメインでは、AIは“空気が読める”

まずは、なぜPBIだけで回っていたのかを分解します。
DDDでいうと、いわゆる「汎用サブドメイン」寄りの領域です。ここでは“世間一般のWebアプリの前提”が通用します。

これまでうまくいっていた機能は、今考えてみると比較的汎用的な機能でした。

たとえば、

• データの一覧表示
• データの登録・更新・削除
• ログイン・ログアウト

こうした機能には「世間一般のWebアプリとしての前提」があります。
つまり「一覧とはこういうもの」「編集できるとはこういう意味」「ログインとはこういうこと」といった暗黙の前提を、AIは過去の学習データから補完できます。
そのため、PBIレベルの情報でも「こちらが求めているであろう機能」を、かなりの精度で作ってくれていました。

---

コアサブドメインでは、AIに「よしなに」が通じない

問題になったのは、独自性が高く、業務ルールを包含しているコアサブドメインともいうべき機能です。
機能自体はよくあるものでも、ルールが複雑だったり、その機能が業務内容に深く絡んでいる場合、AIは過去の学習データから補完することが難しくなります。
同じプロジェクトのメンバー同士であれば、業務や漠然としたユースケースの文脈を共有しているため「このシステムでは、そういう意味だよね」で済んでいた部分が、AIには通じませんでした。

結果として、AIが「よしなに」作った実装は、動いてはいるものの、業務の期待とはズレているという状態になっていました。
動作確認のたびに仕様の穴が見つかり、AIへの修正指示が中々通じない状態になっていました。

---

象徴的だったのが、「ファイルを移動する」という操作です。

システム的に見れば、これは単に置き場所を変えるだけの操作です。
しかし業務の文脈では、それは「共有範囲を変える」「関係者に公開する」といった意味を持っていました。
しかも「公開」と一言でいっても、役割の異なるペルソナごとに想定している業務シナリオが複数あり、操作の意図や前提が変わっていました。

つまり、単なる操作ではなく 業務上のイベント でした。
ここが、PBIだけではAIに伝えきれていませんでした。

---

PBIでは表現しきれない“業務ルール”があった

ここで強調したいのは、PBIの書き方が悪かったわけではないという点です。

PBIには、以下の情報を記載していました。

• ユーザーストーリー
• 受入基準
• やらないこと

（PBIをどのように書いているかは、前回の記事を参考にしてください。）

ただ、コアサブドメインのようにロジックが複雑になると、PBIレベルの情報だけでは、そのロジックをAIが理解しきれません。
結果として、AIが出すコードは「動きはするが、POの期待とはズレる」コードになってしまいました。

汎用サブドメインでは暗黙の前提を補完できていたのに対し、ここでは「その操作が何を意味するのか」「業務上なにが変わるのか」といった前提まで含めて言語化する必要がありました。

---

AIに叩き台を作らせ、論点を洗い出す

そこで私たちは、いきなり実装に進むのではなく、まずPBIレベルで分かっていることを材料に、AIにドメインモデルの「叩き台」を作らせました。
具体的には、ロール・操作・状態・許可/禁止を箇条書きにし、権限マトリクスの叩き台に落としました。

その叩き台を前にして、POと開発者で会話しながら「誰が」「どのフォルダで」「何をしたいのか」「その操作で何が変わるのか」を一つずつ具体化していきました。

すると、細かいユースケースや例外を、洗い出しきれていなかったことが分かりました。
ある人には許される操作が別の人には許されてはいけない、ある状況ではOKだが別の状況ではNG――頭の中では分かっていたつもりでも、言語化されていなかった前提が次々と出てきました。

---

合意したモデルを仕様書にし、AIに実装させる

ここでやったのは「仕様書を作ること」だけではなく、業務の前提をドメインモデルとして合意し、それをチームの共有資産として固定することでした。

洗い出した論点とユースケースを踏まえて、AIに権限管理の仕様（モデル/ルール/データ構造）を更新させました。
このとき意識したのは、次のような情報を仕様として固定することです。

• 用語の意味を揃える（ユビキタス言語）
• 状態の変化を整理する
• 業務シナリオとシステム操作の対応を明確にする

合意した内容は、ドメインモデルを含む設計仕様書としてリポジトリに配置しました。中身は例えば次のようなものです。

• 用語集（ロール/権限/公開などの言葉の定義）
• データモデル（ER図）
• 権限マトリクス（ロールごとに「何ができるか/できないか」）
• 業務シナリオ一覧（ペルソナごとの代表ユースケースと成功条件）

（例）権限マトリクス（抜粋）

アクション	閲覧者	編集者	管理者
一覧/閲覧	✅	✅	✅
アップロード	❌	✅	✅
削除	❌	✅	✅
権限変更	❌	❌	✅

このような仕様書を前提にAIに開発させました。

---

結果として、うまく開発できた

叩き台を起点に論点とユースケースを詰め、権限管理の仕様を設計仕様書として整理した上でAIに実装を任せたところ、それまでうまくいかなかった機能が、かなり素直に形になりました。

ここで感じたのは、AIに渡すべき情報量は、機能の性質によって変わるということです。
汎用的な機能であればPBIレベルの情報でも通じますが、複雑で独自性の高い機能ではそれだけでは前提が足りません。

こうした「複雑で独自性の高い機能」に対しては、業務の前提を洗い出して仕様として明文化することが効きました。具体的には、

• 叩き台を作って論点を可視化する
• 業務シナリオとシステム操作を対応づける
• 合意した内容を仕様書として固定し、AIに渡す

すべての機能に同じやり方を取る必要はなく、機能の性質に応じてアプローチを変えることが大事だと感じました。

今回の経験から、判断基準として参考になるのは、

• 業務ロジックに独自の意味づけがあるか
• ロジックや状態遷移が複雑か
• AIに3回以上修正指示を出しても、想定通りの挙動にならないか

といった点です。
このうち一つでも当てはまるなら、「モデルの合意と前提の固定」を先に行うことを検討してみると良いかもしれません。

---

まとめ：PBI × AI が通じる領域／通じない領域

これまで、PBIを起点にしたAI駆動開発で、多くの機能をスムーズに開発できていました。
その延長線上で、今回のような壁にぶつかったのは、ある意味自然だったのかもしれません。

汎用的な機能は、PBIレベルの情報でもAIが補完して実装できる一方で、複雑で独自性の高い機能は、前提が不足すると「動くが期待とズレる」状態になりやすいと分かりました。
そういうときは、叩き台を起点に論点とユースケースを詰め、合意した内容を仕様書として固定してAIに渡すのが効きました。

「今までうまくいっていたやり方が、通用しない場面もある」
それに気づけたのが、今回の一番の収穫でした。

そして個人的には、この経験をきっかけに、ドメイン駆動設計について腰を据えて勉強しようと思いました。