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

---

1. はじめに

前回（第1回：仕様化・文章化・ルール化で見えてきたこと）の記事では、

• Issueテンプレート
• README / .cursorrules
• DoDやCIなどの品質保証の仕組み
• AIによるMR・コミット生成

といった、「AI駆動開発を支えるルール作りと土台づくり」について紹介しました。

今回はその続編として、開発の現場で最も頻繁に行われる「AIへのタスク依頼」にフォーカスします。

スクラム開発では、タスクの単位として PBI（Product Backlog Item：プロダクトバックログアイテム） を使いますが、AI駆動開発ではこのPBIがそのまま「AIへの依頼書」になります。

AIにコードを書いてもらう中で、

• 「指示したつもりなのに、意図と違うものができてしまった」
• 「なんか違う……」
• 「こういうのじゃない……」

という経験はないでしょうか？

この記事では、私たちが実践している「PBI-based AI Driven Development」 というアプローチを通じて、AIと認識齟齬をなくすための具体的なテクニックを紹介します。

---

2. AI駆動開発の「あるあるBad体験」

AIを使って開発していると、「あるあるBad体験」によく出会います。

• 「なんか違う……」
• 「こういうのじゃない……」
• 「修正しようとしたら、コードが崩壊した……」

ここでのポイントは、これらの原因が必ずしも「AIの能力不足」ではない ということです。

多くの場合、真犯人は 「コンテキスト（文脈）の曖昧さ」 です。

• 人間： 「これくらい言えば、あとは察してくれるだろう」
• AI： 「（渡された情報だけをもとに、それっぽくベストエフォートで出力する）」

AIは 「推測」より「確定情報」が得意 です。

人間の頭の中にある暗黙の了解や、チーム内の “なんとなくの共通認識” をよしなに補完してくれるわけではありません。

つまり、Bad体験を減らすカギは、AIに渡すコンテキストを、どれだけハッキリ言語化できるかにあります。

そこで登場するのが、今回のテーマである「PBI-based AI Driven Development」 です。

---

3. PBI-based AI Driven Developmentとは？

スクラム開発などのアジャイル開発において、PBIは

• 開発する機能や価値を定義する
• プロダクトオーナーと開発チームの共通理解をつくる

ための単位として使われています。

PBI-based AI Driven Developmentは、PBIを基盤にソフトウェア開発プロセス（分析・設計・実装・テスト）をAIで駆動する考え方です。

この開発手法においては、

• プロダクトオーナーは、PBIを通して「価値」や「期待する振る舞い」を言語化する
• 開発者は、PBIをもとにAIとペアプロをしたり、テスト自動生成をさせたりする
• AIは、PBIを 「コンテキストのAPI」 として読み取り、コードやテスト、設計案を返す

という関係になります。

このとき、PBIはもはや「チケット管理ツールの1行」ではなく、「人間とAIが同じ方向を向くための共通インターフェース」として機能します。

では、その「良いPBI」とは具体的にどんなものなのか？

次の章で、PBIに入れておきたい 3つの要素 を紹介します。

---

4. PBIに明記すべき「3つの要素」

AIに誤解なくタスクを依頼するために、

私たちはPBIに以下の3つを明記することを推奨しています。

1. ユーザーストーリー (User Story)
2. 受け入れ基準 (Acceptance Criteria)
3. やらないことリスト (Not-To-Do List)

それぞれ、スライドで紹介した「良い例・悪い例」とともに見ていきます。

---

4-1. ユーザーストーリー (User Story)

原則：

「As a / I want / So that」でユーザーの行動と目的を示す

単に「機能」を書くのではなく、

• 誰が（As a）
• 何をしたくて（I want）
• なぜそれをしたいのか（So that）

をセットで書きます。

特に 「So that（目的・価値）」 を書いておくことで、

AIは実装の方向性をより正確に推測しやすくなります。

Bad例

売上レポートが確認できる

一見それっぽく見えますが、

• どのロールの人が
• どんな意思決定のために
• どの粒度や期間の情報を知りたいのか

が、まったく分かりません。

Good例

店舗マネージャーとして（As a）
日次の来店者数を確認したい（I want）
スタッフの人数を調整するために（So that）

ここまで書いてあると、AIは

• ターゲットは「店舗マネージャー」
• 目的は「人員調整」という運営上の判断のため
• 日次レベルの情報が重要

といった前提を読み取りやすくなります。

結果として、

• どんな項目を表示すべきか
• どのくらいの期間を扱うべきか
• どのようなUIだと意思決定に使いやすいか

といった提案を、ユーザーの文脈に沿って出しやすくなります。

ポイント

• 「As a / I want / So that」の3つを必ず揃える
• 実装詳細ではなく、ユーザーの目的や価値を書く
• 読んだだけで「誰が嬉しいのか」が分かるようにする

---

4-2. 受け入れ基準 (Acceptance Criteria)

原則：

「Gherkin形式（Given / When / Then）」で振る舞いを明示する

「何ができればOKなのか」を、具体的な振る舞いとして記述します。

Bad例

日次レポートが見れる

こちらもよく見かける書き方ですが、

• どんな画面で？
• いつの期間のレポートが？
• どんな形式で？

という肝心な部分が抜けています。

Good例（Gherkin形式）

Given（前提）：来店者数を知りたいマネージャーが
When（操作）：日次レポート画面を開くと
Then（結果）：直近1週間の日次来店者数が表形式で表示される

この形式で書くと、

• Given：テスト開始前の状態（誰が / どんな状況で）
• When：ユーザー操作やイベント
• Then：観測可能な結果（画面・データ・メッセージなど）

に自然と分解されます。

AIに「このGherkinに沿ってテストを書いて」と依頼すれば、

• 前提条件のセットアップ
• 実行アクション
• アサーション

をかなり機械的に組み立てられるようになります。

ポイント

• 受け入れ基準は、できるだけ Gherkin形式（Given/When/Then） で書く
• Thenでは、テストで確認できるレベルの具体的な結果を書く
• 可能であれば、成功パターンだけでなく、エラーや例外のScenarioも用意する

---

4-3. やらないことリスト (Not-ToDo List)

原則：

「3N（Next Time / Not Now / Never）」で作業の境界線を明らかにする

AIは良くも悪くも「気が利きすぎる」ことがあります。

• ついでに関連機能も作ってしまう
• まだ要件が固まっていない部分まで作り込み始める

といった挙動をすることがあり、結果的に

• スコープが膨らむ
• 変更に弱くなる
• テストやレビューが追いつかない

という問題につながります。

そこで、PBIごとに 「今回は何をやらないのか」 を明示しておきます。

3Nの例

Next Time (Deferred)：次回やるもの
例：週次/月次レポートの作成
Not Now (Out of Scope)：今はやらない・様子見
例：自動メール通知機能
Never (Explicit Exclusion)：やる予定はないもの
例：Internet Explorerへのサポート対応

たとえば「直近1週間の日次来店者数を表示する」PBIであれば、

• 週次・月次レポート → Next Time
• 自動配信機能 → Not Now
• Internet Explorerへの対応 → Never

といった具合に、明確に線を引いておくイメージです。

AI側から見ると、「ここまでは手を出してよくて、これ以上は今回はやっちゃダメなんだな」という 作業範囲の境界線 がはっきりします。

ポイント

• 「やること」だけでなく、「やらないこと」もPBIに載せる
• 境界があいまいになりそうなところほど、Not-To-Doを丁寧に書く
• 3N（Next Time / Not Now / Never）で、優先度と方針を言語化する

---

5. AIに伝わるPBIのチェックリスト

最後に、作成したPBIがAIにとって理解しやすいものになっているか、

簡単にセルフチェックできるリストをまとめます。

ユーザーストーリー

• 「As a / I want / So that」の3項目すべてが記述されているか
• 「So that」で、ユーザー視点の価値・目的が明示されているか
• 実装方法ではなく、ユーザーの目的・行動が書かれているか

受け入れ基準

• 各Scenarioが「Given / When / Then」の形式になっているか
• ドメイン固有の言葉を使い、観測可能な結果として書かれているか
• 成功パターンだけでなく、必要に応じて失敗パターンも網羅しているか

やらないことリスト

• 将来実装する予定の機能が、「今回はやらない」と明記されているか
• スコープ境界が曖昧になりそうな部分について、「やらないこと」が書かれているか
• Next Time / Not Now / Never の3つの観点で整理されているか

---

このチェックリストを通ったPBIは、そのまま

• AIへのプロンプト（コンテキスト）の材料
• テストコード自動生成の材料
• プロダクトオーナーやステークホルダーとの合意形成の材料

として再利用しやすい「良いAPI」になります。

---

6. おわりに

前回の記事でも触れた言葉を、あらためてここで書きます。

「AIに説明できるチケットは、人間にも分かりやすい」

PBIの精度を上げることは、AIのためだけではなく、チーム全体の共通理解を深めることにもつながります。

今回紹介した3つの要素

1. ユーザーストーリー（As a / I want / So that）
2. 受け入れ基準（Given / When / Then）
3. やらないことリスト（Next Time / Not Now / Never）

を意識してPBIを書いていくことで、AIとの「なんか違う」を少しずつ減らしていくことができます。

ぜひ、みなさんのチームでもPBIを「コンテキストのAPI」として育てながら、AI駆動での価値創出を加速させるきっかけにしてもらえたら嬉しいです。