🐬
AI駆動型アジャイル開発のススメ

2025/10/17に公開
 AI駆動型アジャイル開発のススメ
 AI駆動型アジャイル開発とはAI駆動型アジャイル開発とは、AI駆動型開発とアジャイル開発を掛け合せた開発プロセスです。

ソフトウェア開発には、ウォータフォール開発やアジャイル開発、その両方を組み合わせたハイブリッド・アジャイル開発などの開発プロセスが存在しますが、今回は、アジャイル開発へAI駆動型開発を取り入れた開発プロセスをご紹介いたします。

このプロセスを創出するきっかけとなった背景や本プロセスの特徴、目指しているところなどを共有しますので、ご一読いただけると幸いです。

 AI駆動型アジャイル開発を構築した背景まず、某案件にて、以下のような要求をいただきました。
アジャイル開発を積極的に取り入れたいが、アジャイル開発の場合、システム管理部で確認できるドキュメントがない（作成されない）ケースが多く、プロジェクトの進捗が把握しづらい。
一方、ウォーターフォール開発だと、要求変更によるオーバーヘッドが大きいため、アジャイル開発のアジリティは活かした開発を実現したい。
上記を聞いて、最初に想像したのが、ハイブリッド・アジャイル開発で、ウォータフォール開発の一部の工程（例：基本設計～結合テスト）をアジャイルのプラクティスを使って回すことでした。
ですが、詳しく要望を聞いていくと、「よりアジャイル寄りな開発で、ウォーターフォール開発のように、必要なドキュメントを確認できるようにしたい」ということだったので、アジャイル開発のプラクティスを維持しつつ、必要最小限のドキュメント（システム管理部が確認する上で必要なもの）は作成するという方針となりました。
そこで、アジャイル開発のアジリティを維持するため、生成AIを活用して、これまでのアジャイル開発では作成していなかった必要最小限のドキュメントを作成する「AI駆動型アジャイル開発」を創出することになりました。
上図に示すように、AI駆動型アジャイル開発は、アジャイルのアジリティ（敏捷性）とウォータフォール開発の計画性・スケーラビリティを両立したプロセスを目指しています。

 対象とするプロジェクト本開発プロセスは、基本的に、どのようなプロダクト開発にも適用できるとは思っていますが、創出された背景から、以下のようなプロジェクトに適用することを考えています。
1. PMOなどの管理部門が、開発内容をしっかり確認しているプロジェクト

2. 金融系や医療系、企業系などのカッチリしたシステムを開発しているプロジェクト

3. 得意先と開発ベンダーが組織として分かれているプロジェクト
1については、ある程度の規模の企業ではよくあるケースで、社内規定に準拠しているか、会社としての品質が保たれているかを確認する際、一定のドキュメントが必要となります。

2については、今までウォーターフォール開発でドキュメントが存在していたのに、アジャイル開発になり、必要最小限のドキュメント（スクラムチーム内では理解できているレベル）しか作られないため、チーム外のステークホルダーや関係者がプロジェクト状態を把握できないケースとなります。

3については、アジャイル開発を企業間に跨って実施するケースで、企業間の契約や互いの企業のリスクヘッジが働き、一定のドキュメントが求められます。
このアプローチは、純粋なアジャイルの思想とは少し異なるかもしれません。しかし、現実の多様なプロジェクトではこのような体制が求められることも多々あります。本プロセスは、そうした実用的なニーズに応えるために創出しました。

 『アジリティ』と『ドキュメント』を両立させる2つのアプローチ「アジャイル開発の敏捷性を維持しつつ、必要最小限のドキュメント（システム管理部の確認に必要なもの）は作成する」という、相反する課題に対応するため、以下の2つの方針を取りました。

 1. ユースケース（機能）単位で、必要なドキュメントを網羅する。ウォーターフォール開発モデルでは、要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト・システムテストと、各工程ごとにフェーズゲートがあり、包括的なドキュメントが求められます。

一方、アジャイル開発では、スプリント毎に機能実装（設計・実装・テスト）が行われ、最終的には、プロダクトバックログに記載されたクライテリア（受入基準）を元に、POが動くシステムを確認し、受け入れを行います。
そこで、考えたのが、ユースケース（機能）単位で、必要なドキュメントを網羅するというアプローチでした。
上記に、ウォーターフォールとアジャイル開発の工程を示します。通常のアジャイル開発では、PBI（Product Backlog Item）にて、スプリントで実施するタスク一覧は詳細に定義するのですが、永続的で整合性の取れたドキュメントは、開発者間で理解できるレベルでしか管理していませんでした（基本的に、POとは動くシステムで認識を合わせ、合意形成します）。

一方、AI駆動型アジャイル開発では、プロジェクト関係者が必要となる最小限のドキュメントを設計書・コード・テスト仕様書など工程毎で網羅するのではなく、ユースケース単位で網羅するように作成しています。具体的には、基本的には動くシステムやコードで管理することが前提で、プロジェクト関係者が現状のままでは、どうしても把握しづらいドキュメントのみ、追加で作成しています（この部分では、システム管理部側にも大幅に妥協いただいており、ソースをそのまま見ていただく場合もあります）。

 2. AI駆動型開発を取り入れ、効果的に適用する。上記のアプローチにより、プロジェクトとしてのドキュメント最適化はできたものの、結局のところ、スクラムチーム（特に、開発チーム）のタスクは純増となり、アジリティが下がってしまいます。そこで、取り入れたのがAI駆動型開発による効率化でした。
その際、反復的な作業から、AI駆動型開発を導入するというアプローチを取りました。

具体的には、設計書・コード・単体テスト・PBIテスト仕様書（※1）の初期生成、および、自己レビューにAI駆動型開発を適用しています。

※1 PBIテスト仕様書：内部結合テスト仕様書相当のもの。
つまり、機能開発における開発者（テックリードやアーキテクト以外）の作業が対象となります。まずは、この部分にAI駆動型開発を適用することで、大幅な生産性向上が見込めると判断しました。

 AI駆動型アジャイル開発プロセス上記のアプローチに則り、構築したプロセス（AI駆動型アジャイル開発プロセス）を以下に示します。
次に、本開発プロセスの特徴は以下となります。
少数チーム型のプロセス（アジャイル寄り）
スクラムのプラクティスの適用（アジャイル寄り）
ユースケース単位での整合性の取れたドキュメント（WF寄り）
開発メンバーの入れ替え・増減ハードルの軽減（WF寄り）
生成AI活用による生産性・品質の向上（AI駆動型開発）
さらに、以下のようにドキュメント管理を行っています。
プロセスとプロダクトで管理を分離しています。
Confluence：プロセス系。一時的なドキュメント（バックログ・PJ管理ドキュメントなど）
GitLab：プロダクト系。永続的なドキュメント（設計書・コード・テスト仕様書など）

AI駆動型開発を効果的に適用するために、Markdown形式によるテキストで管理しています。
全体図などの画像は何枚か作成していますが、それ以外の図はMermaid記法で作成しています。
Office文書によるドキュメント管理は行っていません。


 プロンプトの整備AI駆動型アジャイル開発では、以下の方針を元にプロンプトを整備しています。
プロンプトを作り込みすぎない（できるだけシンプルにする）。
インプット（要件や仕様など）は極力テキストにする（PBI→設計書のみ画像入力）。
Few-Shotプロンプティングで、記載粒度と出力フォーマットを整える。
なお、「プロンプトを作り込みすぎない」は、以下の観点から特に重視しています。
チーム成長の余白を持つ（開発チームで改善しながら、学習・成長していく）。
生成AIの加速度的な精度・性能向上を意識する（数ヶ月で、AIの性能は大幅に上がってしまう）。
汎化・標準化して、他のプロジェクトにも適用しやすくする（システム特性への依存度を下げる）。
上記、システム開発のプロダクトには同じものはほぼ存在しないため、スクラムチームやプロダクト毎に、プロンプトを成熟させる方がよいと判断しており、基盤としてはベースのみを用意しています。
そのため、標準的なプロンプトだけ整備しており、その状態でも80～90％くらいの精度が出ていますが、よりシステム特性やプロジェクト特性を加味したプロンプトの成熟は、各スクラムチームに任せています。こうすることで、チームの成長とともに、チームメンバーが生成AIの使い方を覚え、生成AIがチーム内・組織内へ浸透していくことを図っています。
なお、標準的なプロンプトは、主に以下の2つの分類で構成されています。
生成系プロンプト：既に存在しているドキュメントやコードによるプロンプト
レビュー系プロンプト：規約やルール、共通仕様などをレビュー観点とするプロンプト
以下に、プロンプトの一例を示します。
■ 生成系プロンプト
あなたは優秀なソフトウェアエンジニアです。
以下の仕様に基づいたコードを生成してください。
コード生成時には、以下の参考コードを参考に生成してください。

- 仕様
{設計書の記載}　← オブジェクト情報や振る舞い、チェック仕様などを入力

- 参考コード
{既に存在しているコード（できるだけ処理の似ているコード）}
■ レビュー系プロンプト
あなたは優秀なソフトウェア開発のレビューアです。
以下のテスト仕様に対して、レビューを行ってください。
レビュー時は、以下のテスト観点を参考にしてください。

‐ テスト仕様
{テスト仕様書の記載}　← テスト観点 ｘ テストケース、期待値などを入力

‐ テスト観点
{チームで管理しているテスト観点の一覧}

 得られた効能AI駆動型アジャイル開発を適用した結果、実際に以下のような効能が得られました。
1. プロジェクト関係者（スクラムチームの1層外のメンバー）の積極的な参加

2. スクラムチームの認識統一によるチームビルディングの促進

3. ドキュメントの標準化・定型化による、人の流動性のしやすさ
1については、PMOなどのスタッフ部門からの理解が得られ、プロジェクトへ積極的に参加して頂いています。具体的には、単なる進捗確認だけでなく、プロダクトがよくなるための仕様についても議論できるようになっています。

2については、アウトプットするドキュメントを最初に共有できたことで、初期のチームビルディングにおける認識合わせが、想定より早く深くできた感触があります。

3については、ドキュメントを標準化・定型化することで、組織として柔軟な対応が取りやすくなったと感じています。「スクラムチームはできるだけ崩さない」がアジャイル開発の鉄則ではありますが、現場では、よくよく人の入れ替えが発生してしまうので、入れ替え時の負荷軽減に繋がっています。

 目指しているところAI駆動型アジャイル開発で目指しているところは、開発者の意識を変えることであり、以下の2つの意識変革に取り組んでいます。
開発の意識を変える：「AIファーストへ」
まず、開発者には、AIファーストで考えるように、意識変革を促しています。特に、初期生成を生成AIに任せることで、初期品質が均一化され、属人化の排除にも繋がるので、仕様書もコードもテストケースも、最初は生成AIで生成するように伝えており、「開発はAIがメイン（9割）、人がサポート（1割）」くらいの意識を持ってもらっています。そのくらい、AIの進化は早く、現在の最新生成AIを使えば、単純なFewShotプロンプティングだけでも、かなりの精度で生成やレビューを実施してくれます。
レビューの意識を変える：「Why」を問う
次に、レビュー時は、開発者の理解力・言語化力を確認するような「問い」をするよう、意識変革を促しています。生成AIでドキュメントやコードを生成すると、一定の品質が出てしまうため、「その仕様になっている理由や、顧客要求の背景、なぜそれでよいと判断したのか」などを開発者から説明してもらっています。こうすることで、開発者の理解力が確認できたり、より顧客視点で考えられる人材の育成が可能となり、顧客へのヒアリングでも、より深いレベルでの認識合わせができるようになっています。

 育てたいエンジニア像本開発プロセスでは、開発の効率化・生産性の向上を実現するとともに、以下のようなエンジニアを育てていきたいと考えています。

心理的柔軟性が高い

　今起きていることへの気づきを維持し、自分の価値観に集中し、効果的な行動が取れる。

視点・視野・視座がコントロールできる

　複数（顧客・開発者など）の視点を持ちつつ、視座の上下動を意識的にできる（視野が広い）。

自己中心的利他の状態を作り出せる

　自分がやりたい（やっている）ことが、自然とチームや顧客への貢献に繋がっている状態を作り出せる。
今後も、AI・生成AIの加速度的な進化により、ICTエンジニアの役割も大きく変わっていくと思っています。今日使えた技術が、明日には陳腐化している時代になっていく可能性もあります。そんな中、自分の価値観をベースに、自分のやりたいことを実現しながら、他者と共創・協働して、サービスやプロダクトを作り上げ、新しい価値を生み出していく、そんなエンジニアが育つことを願っています。

 今後について1. プロンプトの改善

現在は、単純なFewShotプロンプティングしか用いていないため、ReactやCoT（Chain of Thought）などのプロンプティングを用いることによる精度改善を行います。
2. マルチAIエージェント化

現在は、生成とレビューを個別に実行し、手動で繋いでいますが、生成とレビューをエージェント化し、生成（改善）→レビューのフィードバックループを回すことによる精度向上を実施します。
3. AI適用範囲の拡大

現在は、機能開発の部分しか適用できていないため、共通仕様や開発基盤、非機能要件（セキュリティや性能など）などに対しても適用していきたいと思います。
上記のような対応を粛々と実践していくことで、ゆくゆくは、ある程度きちんとした要件を入れると、生成AIが勝手に設計→実装→テスト→デプロイをして、プロトタイプが動いている状態になることを目指しています。そんな世の中が来るよう、今後も頑張って取り組んでいきたいと思います。

 あとがき今回の記事では、あまり言及はできませんでしたが、本プロセスでは、プロセス定義やドキュメント体系化（関係性やMECEなど）などはきちんと規定しており、アジャイル開発といえど、基本的なプラクティス以外で、ある程度の標準化・定型化は実施しています。
アジャイル開発というと、チーム発足から「どうやって進めるのか？」もチームビルディングに入るケースが多いと思いますが、基本や基準がないとプロジェクトがスムーズに立ち上がらないケースもたくさん見てきています。
そのため、個人的には、一定のガイドラインを用意して、チームに適切な制約を掛けた中で、チームに自由度がある状態（チームに成長の余白がある状態）を目指して、日々取り組んでいます（チームはナマモノなので、うまく制約を設けるのが本当に難しいのですが⋯）。
この辺りの話も機会があれば、投稿していきたいと思います。

最後まで、お読みいただき、ありがとうございました。