AI駆動開発とビジネスアナリスト
最近AI駆動開発という言葉を聞きます。またAI-DLCもあります。この2つは同じことでしょうか、それとも別の意味があるのでしょうか。またビジネスアナリストとはどのような関係があるのでしょうか。
「AI駆動開発」と「AI-DLC」はかなり近い概念ですが、同義ではありません。
- AI駆動開発＝「AIを開発プロセスの中心的な協働者として位置づける開発スタイル全般」を指す包括的な概念です
- AI-DLC＝AWSのRaja SPが2025年に提唱し、「AI-Driven Development Lifecycle (AI-DLC) Method Definition」というホワイトペーパーで定義した、具体的なソフトウェア開発メソドロジーです
1. まず「AI駆動開発」とは何か
「AI駆動開発」という言葉は、現時点ではかなり広く使われています。典型的には、
- ChatGPT / Claude / Geminiによるコード生成
- GitHub Copilotによるコーディング支援
- Cursor / Windsurf等によるAIコーディング
- Claude Code等によるAgentic Coding
- AIによるテストコード生成
- AIによるコードレビュー
などを総称して「AI駆動開発」と呼ぶケースが多いです。
つまり従来の、
- 人間 → コードを書く → AIが支援 から
- 人間＋AI → AIがコードを生成・修正・テストする
へ変わったものです。
2. しかし、ここには大きな段階差があります
AI駆動開発を、4段階に分けて考えると分かりやすい。
| 段階 | AIの役割 | 人間の役割 |
| 第1段階 AI支援 | コード補完 | 開発する |
| 第2段階 AI協働 | コード・テスト・設計を生成 | 指示・レビューする |
| 第3段階 AIエージェント開発 | タスク分解→実装→テスト | 目的・制約を与え監督する |
| 第4段階 AI駆動開発 | 開発プロセスそのものをAIが進行 | 意思決定・承認・責任 |
現在、多くの企業が「AI駆動開発」と呼んでいるものは、実際には L2～L3 くらいです。
例えば、「ログイン機能を作って」とClaude Codeなどに指示すると、
- ソースコードを調査
- 必要なファイルを特定
- コードを書く
- テストを書く
- テストを実行
- エラーを修正
- 再テスト
までやってくれます。これは明らかに従来の「AIコーディング支援」より格段進んでいます。
3. そこで登場するのがAI-DLC（AI-Driven Development Lifecycle）。
AI-DLCの具体的な構造：
- 3フェーズ構成:Inception(方向づけ)、Construction(構築)、Operations(運用)の3フェーズに、人間の意思決定ゲートを組み込んだ構造になっています
- 「Mob Elaboration」：Inception時にチーム全員でAIの質問・提案に答えながら要件定義を行います。
「Mob」とは、ソフトウェア開発の既存プラクティスであるモブプログラミング(1台のPCの前にチーム全員が集まり、1人がドライバー(入力担当)、残り全員がナビゲーター(思考・指示担当)として同時に1つのタスクに取り組む手法)の考え方をAI協働に転用したものです。ペアプログラミングの「2人版」をチーム全体に拡張したイメージです。AI がビジネス意図を詳細な要件、ストーリー、ユニットに変換し、チーム全体が AI の質問や提案を積極的に検証します。作業そのものは全てAIが行い、そのアウトプットの是非をチームが判断します。意思決定能力のあるメンバーが参加することが本質的に重要です。AIが作成したものをその場で意思決定するので、要件定義が爆速で行われるわけです。 - 「Mob Construction」：AI が論理アーキテクチャ、ドメインモデル、コードによる実装、テストを提案し、チームメンバーがリアルタイムで技術判断を行います。ここでも意思決定能力のあるメンバー（アーキテクトやテスターなど）が必須です。その結果爆速で構築が可能になります。
- 独自用語:「Bolt」：従来の「スプリント」に相当しますが数時間~数日単位の短サイクルです。爆速開発を実現するためにはスプリント（2週間）では間に合いません。
- ガバナンスの課題:誰がAIの計画したものを承認する権限を持つか、本番投入前にAIが書いたコードがクリアすべき評価基準は何か、といった点は文書化されておらず、組織側で承認者・レビュー基準・評価基準を自前で用意する必要があります
両者の関係整理を整理します
| 観点 | AI駆動開発 | AI-DLC |
| 性質 | 総称・潮流(業界トレンド全体) | AWSが定義した具体的方法論 |
| 定義の明確さ | 曖昧・多義的 | フェーズ・用語・成果物が明文化 |
| 位置づけ | 概念的 | AI駆動開発の具体的な実装形態 |
| 類似・競合 | — | ForresterのAgentic Software Development(ASD)、Cycode社のADLCなど、同種の概念が乱立している状況で、AWSのAI-DLCはあくまで「AWSエコシステム前提」の枠組みです |
ビジネスアナリシスとの関係
AI-DLCの構造は、BABOKの要求分析プロセスと重なりつつ、BAの役割を進化させます。
- Inceptionフェーズ=要求の引き出しを再定義します:
AIが対話を開始し、ビジネス上の意図を実行可能なタスクに分解し、ドメインモデル・コード・テストを生成する一方で、開発者やプロダクトオーナーは重要な意思決定ポイントでの戦略的検証者として機能します。つまり従来BAが担っていた「要求の言語化」の初動をAIが代行し、BAはAIが生成した要求の妥当性検証・優先順位付け・ステークホルダー調整という、より上流の判断業務にシフトします。 - Mob Elaboration=BAのファシリテーション能力が問われる場です:
AIへの質問・提案にチーム全体で応答する形式は、従来のワークショップ型引き出し(BABOKの「引き出しとコラボレーション」知識エリア)のAI版と言えます。BAには、AIの提案の曖昧さや漏れを見抜き、適切な追加質問を即座に投げる能力が求められます。 - 要求のトレーサビリティ:
金融や医療などの厳格な業界において、AWS AI-DLCは「ビジネスの目的」から「最終的にデプロイされたコード・テスト結果」までを1つのチェーンで自動記録します。 ビジネスアナリストが「この機能は法改正の条項Aを満たすため」と定義（Inception）すれば、AIはその要件に紐づくテストケースと実装を作成し、監査用ログを残します。ビジネスガバナンスとAIの爆発的なスピードを両立させる要となります。これはBABOKの「要求ライフサイクルマネジメント」知識エリアそのものであり、AI-DLC導入企業ではBAがこのトレーサビリティ設計の責任者になる可能性が高いです。 - Inception フェーズ/Mob Elaborationや要求のトレーサビリティを考慮するとBAの役割が最重要と言えます。BAなくしてAI-DLCはあり得ないと言えます。
更にAI-DLCを高度に実装しようとすると「技術的な問題のみならず組織的・政治的な問題」がAI-DLCの実装局面で大きく顕在化します。それはInception フェーズで意思決定の権限を持たない開発者やプロダクトオーナーだと効果が薄れてしまうからです。そこには組織そのもののAI-Readyな成熟度モデルを理解する必要があります。
成熟度レベルとAI-DLC適用度の対応
| 成熟度 | 開発現場の実態 | AI-DLCとの関係 | 支配的な問題領域 |
| レベル1 (実験) |
個人のエンジニアがCopilot等を自己判断で利用。コーディング支援止まり | AI-DLCの語彙(Bolt、Mob Elaboration)は未導入。「AIアシスト付きSDLC」に過ぎない | 技術的(ツール選定・個人スキル) |
| レベル2 (ツール活用の定着) |
チーム単位でAIツールを標準化。コード生成は速いが、要求定義・設計は依然として人間が個別に行う | Constructionフェーズの一部だけがAI化。InceptionのMob Elaborationは形骸化しがち | 技術+一部組織的(ツールガバナンス) |
| レベル3(組織変革) | Inception〜Operationsの3フェーズが通しでAI協働型に再設計される。BoltがAgileのスプリントに置き換わる | AI-DLCが「開発チームの意思決定構造そのもの」として機能し始める | 完全に組織的・政治的(権限・評価基準・役割の再定義) |
| レベル4以降 | 複数プロダクトラインでPersistent Contextが横断的に蓄積・再利用される。BA/BAAが標準化されたガバナンス設計者として制度化 | AI-DLCが企業の開発標準そのものになる | 制度・ガバナンス |
成熟度レベル2→3移行の核心 ― なぜ「組織的」なのか
AI-DLCの3フェーズ構造自体は技術的にはレベル2でも動かせます。しかし、それが機能するかどうかを分けるのは以下の非技術的な壁です。
- 承認権限の再配置が必要 — 従来「誰が要件を承認するか」は明確な組織階層(スポンサー→BA→開発リード)に沿っていました（BABOKでは「BAガバナンスを計画する」タスクで決めておく）。AI-DLCのMob Elaborationでは、AIの提案に対してチーム全員がリアルタイムで応答するため、承認権限が「役職」から「その場で判断できる専門性」へと移行します。これは人事評価・責任の所在という政治的問題そのものです。持ち帰って上司の判断を仰いでいる時間はありません。
- 評価基準の空白を誰が埋めるか — 前回触れたとおり、AWS自身のドキュメントもここは示していません。「AIが書いたコード/生成した要求モデルがどの品質基準をクリアすれば本番適用可か」を決める権限を、開発リードが持つのか、BAが持つのか、新設のCAIOが持つのか——これは技術選定ではなく権力配分の設計です（BABOKでの「BAガバナンスを計画する」タスク）。
- BoltへのAgile組織の抵抗 — 2週間単位のスプリント運用に最適化された評価制度・報告ライン・予算サイクルが、時間~数日単位のBoltと衝突します。人事考課制度や予算承認プロセスという「制度の慣性」が変わらない限り、現場はAI-DLCの速度についていけません。
このように、AI駆動開発（特にAI-DLC）を効果的に機能させるためには組織のAI成熟度もそれなりに高めておく必要があります。その中心的役割を果たすのがビジネスアナリストです。AI駆動開発（特にAI-DLC）を効果的に実装するためには早期にビジネスアナリストを育成する必要があります。