AI駆動開発

2026年9月13日

🐧 要するにどういう話か

仕様駆動開発とAI駆動開発はほぼ同じ意味で使われていることがあるが、厳密にはAI駆動開発は「AIが進行を駆動（drive）し、人間が責任を負うソフトウェア開発手法」である。仕様駆動開発はそれに組み込まれうる実践のひとつである。なお、AI駆動開発は、エージェンティックエンジニアリングの実践のひとつである。

1. AI駆動開発とはなにか

AI駆動開発（AI-Driven Development, AIDD）とは、AIを意図的なパートナーとして開発に組み込む手法である。開発者はAIとともに計画し、タスクを分解し、すべての変更をレビューしながら、リリースするものに対して最終的に責任を負うアーキテクトとしての役割を維持する。

AIDDに関連する実践として、AI支援開発（AI-assisted development）、AIペアプログラミング、エージェント型コーディング、仕様駆動開発（spec-driven development）、コンテキストエンジニアリングがある。

1.1 AIDDとVibe Codingの違い

Vibe Codingは、コード品質を要求条件としないまま出荷速度を最適化する手法である。AIDDは同じ加速を維持しつつ、品質・レビュー・保守性をデリバリのプロセスそのものに組み込む。

  • AIDD: 品質をプロセスに組み込みながら素早くリリースする。手法は「学習 → 意図 → 仕様 → 計画 → 実装 → レビュー＋テスト → リリース」という循環を踏む。
  • Vibe Coding: コード品質を気にせずに素早くリリースする。手法は「プロンプト → 本番」である。

時間経過とともにこの差が顕在化する。AIDDは時間の経過とともに価値を蓄積する。Vibe Codingは出力のスパイクの後に、技術的負債の蓄積が生じる。

1.2 AIDDとAI支援開発・AI自律開発の違い

現在の組織は、ソフトウェア開発において主に2つのアプローチでAIを活用している。

  • AI支援開発: AIがドキュメント作成、コード補完、テストなどの特定のタスクを強化する。人間が知的な重労働を行い、AIが拡張機能を提供する。
  • AI自律開発: ユーザー要件に基づき、人間介在なしにAIがアプリケーション全体を生成することを期待する。

どちらのアプローチも、速度とソフトウェア品質の面で最適でない結果を生み出してきた。AIDDはこれらの中道をとる。AIが開発プロセスを能動的に進行させ、人間は検証・意思決定・監督に対する最終的な責任を維持する。

1.3 AI-DLCの位置づけ

AI-Driven Development Lifecycle（AI-DLC）は、2025年にAWSが提唱した、このアプローチの最も体系的な定式化である。AI-DLCはAIネイティブな方法論であり、AIの能力をソフトウェア開発の根幹に統合することで、ソフトウェアエンジニアリングの次の進化の基盤を築くことを目指す。

1.4 AI駆動開発と仕様駆動開発（SDD）の関係

仕様駆動開発（Spec-Driven Development, SDD）とは、開発が始まる前に実装の詳細な仕様が作成され、合意されるソフトウェア開発の手法である。仕様は「何を、どのように構築するか」の単一の情報源（single source of truth）として機能する。

SDDはスペクトラム上に存在する。

  • Spec-first: コード生成の前に仕様を書く。初期の明確さが提供され、コードが生成された後は、仕様のメンテナンスが必ずしも行われない。「SDDの入り口」と位置づけられる。
  • Spec-anchored: 仕様がソフトウェアとともに進化していく。要件が変化し、機能が追加されるたびに仕様が更新され、システムの現状を反映する。自動テストはドキュメントと実装の橋渡し役となる。
  • Spec-as-source: 仕様の変更が自動的にコードの変更をトリガーする。人間が直接コードをリファクタリングしない。最もAIファーストな形態である。
  • ハイブリッド: 仕様をバージョン管理された成果物として扱う、外部システムを情報源とする、複雑度の高いプロジェクトでは重い自動化を避ける、など複数の要素を組み合わせる。

AIDDとSDDの本質的な違いは以下の通りである。

  • SDDは指示の質の問題を扱う。「AIは受け取る指示の質に比例する」。AIが正しく実行できるよう、何を構築するかを十分に明確に定義することに焦点を当てる。
  • AIDDはプロセス全体の質の問題を扱う。計画・分解・レビュー・テスト・リリースまでをカバーし、AIをパートナーとしていかに開発するかに焦点を当てる。

Manifestoでは、仕様駆動開発はAIDDの関連実践としてリストされている。SDDは、より広いAIDDフレームワークの中に存在しうる構成要素である。

2. AI駆動開発が登場した背景

2.1 ソフトウェア開発の進化

ソフトウェアエンジニアリングの進化は、低レベルの定型タスクを抽象化し、開発者が複雑な問題の解決に集中できるようにするための継続的な試みであった。初期の機械語から高級言語へ、APIやライブラリの採用を経て、LLMの統合に至るまで、各段階が開発者の生産性を大幅に向上させてきた。

LLMの統合により、コード生成、バグ検出、テスト生成などのタスクに対して、対話的な自然言語インタラクションが可能となった。これがAI支援時代であり、AIが細粒で特定のタスクを強化する時代である。

AIの進化に伴い、その応用はコード生成を超えて、要件の明確化、計画、タスク分解、設計、開発者とのリアルタイムな協働まで拡張されている。この変化はAI駆動時代の始まりであり、AIが開発プロセスを能動的に進行させる時代である。

2.2 既存手法にAIを組み込むことの限界

既存のソフトウェア開発手法——SDLC、アジャイル、スクラム——は、人間主導の長時間プロセス向けに設計されている。プロダクトオーナー、開発者、アーキテクトは、計画、会議、その他のSDLCの儀式といったコア外の活動に多くの時間を費やしてきた。

これらの手法にAIを「助手」として組み込む（retrofit）だけでは、AIの能力を制限するだけでなく、古くなった非効率を強化してしまう。従来の手法は手動のワークフローと硬直的な役割定義に依存しており、AIの速度・柔軟性・エージェント的な能力を十分に活用できない。

これがAI-DLCの第1原則「Reimagine rather than retrofit（組み込むのではなく再想像する）」の核心的洞察である。必要なのは、速い馬車ではなく自動車である。

2.3 2つの失敗したアプローチ

AI駆動開発が登場する以前、組織はAIを2つの方法で活用しようとしてきた。

  • AI支援開発は、知的な重労働の大部分を人間に残したままだったため、AIの完全な可能性を引き出せていなかった。
  • AI自律開発は、人間介在なしにAIに動作することを期待していたが、複雑なシステムにおいてまだ信頼できる状態にはなかった。

AI駆動開発はこれらの中道をとる。AIがワークフローを進行させ、人間は重要な節目で承認者として機能し、検証し、選択肢を選び、意思決定を確認する。

3. AI駆動開発の考え方

3.1 4つの価値観（Manifesto）

以下の4つの非技術的な価値観が、すべてのAI支援コーディングセッションを導く。

  1. 手法をモデルより重んじよ（Method over Model） — モデルではなく手法に賭けよ。どのLLMリリースも移ろいゆく。手法は残り、モデル・ベンダー・バージョンを横断してチームの実践を標準化する。
  2. 所有を委譲より重んじよ（Ownership over Delegation） — AIが書いたものも含め、自分がリリースするものは自分が所有する。すべてのコミットは人間が署名する。AIは加速し、人間が決める。
  3. 理解を承認より重んじよ（Understanding over Acceptance） — 理解できないものは受け取らない。AIは共同作業者であり、代替者ではない。
  4. 成果を出力より重んじよ（Outcome over Output） — コードを書くのは容易だ。有用な成果を生み出すのは容易ではない。小さくリリースし、素早く学び、ユーザー・製品信頼性・ビジネスに対する結果を測れ。行数・トークン数・コミット数ではなく。

3.2 10の原則（AI-DLC）

以下の10の原則は、AI-DLCの定義の基盤を形成し、そのフェーズ・役割・成果物・儀式を形づくっている。

  1. 組み込むのではなく再想像する（Reimagine rather than retrofit） — 既存の手法（SDLCやアジャイル）にAIを組み込むのではなく、開発手法を再想像する。従来の手法は長いイテレーション期間（月・週）向けに設計されており、デイリースタンドアップやレトロスペクティブといった儀式が生み出された。AIの適切な活用は時間・日で計測される急速なサイクルをもたらし、継続的なリアルタイムの検証とフィードバックを必要とする。
  2. 会話の方向を反転する（Reverse the conversation direction） — 人間がAIにタスクを指示するのではなく、AIが人間との会話を開始・主導する。AIは上位の意図を実行可能なタスクに分解し、推奨を生成し、トレードオフを提案することでワークフローを進行させる。人間は承認者として機能する。Google Mapsの比喩が役立つ。人間が行き先（意図）を設定し、システムがステップバイステップの道順（AIのタスク分解と推奨）を提供する。
  3. 設計技法をコアに統合する（Integration of design techniques into the core） — スクラムなどのアジャイルフレームワークは設計技法（DDDなど）をスコープ外としている。AI-DLCは設計技法をコアに統合する。DDD・BDD・TDDそれぞれに従うチーム向けに、異なるバリエーションのAI-DLCが存在する。AIは計画とタスク分解の際にこれらの技法を本質的に適用する。
  4. AIの能力に合わせる（Align with AI capability） — 現在のAIは進歩しつつあるが、上位の意図を実行可能なコードに自律的に変換したり、人間介在なしに動作したりすることはまだ信頼できない。一方で、AI支援のパラダイムではAIの完全な可能性を引き出せていない。AI-DLCは、人間の関与と現在のAIの能力・限界のバランスをとるAI駆動のパラダイムを採用する。
  5. 複雑なシステムの構築に対応する（Cater to building complex systems） — AI-DLCは、継続的な機能の適応性、高いアーキテクチャの複雑さ、多数のトレードオフの管理、スケーラビリティ、統合要件を必要とするシステムを対象とする。低コード/ノーコードアプローチがより適する単純なシステムはスコープ外である。
  6. 人間とAIの協働を強化する要素を残す（Retain what enhances human symbiosis） — 手法を再想像しつつ、人間の検証とリスク軽減に不可欠な既存手法の成果物・接触点を残す。例えば、ユーザーストーリーは人間とAIの「何を構築するか」の理解を揃える。リスクレジスターは、AIが生成した計画が組織のリスクフレームワークに準拠していることを保証する。
  7. 既存用語の親近性で移行を容易にする（Facilitate transition through familiarity） — 新しい手法は広範な訓練を要求すべきではない。AI-DLCは既存の用語間の関係性を保持しつつ、モダンな用語を導入する。例えば、スクラムのスプリントの概念を、Boltという新たな名称で再定義し、急速で集中したサイクルを強調する。
  8. 役割を統合し効率化する（Streamline responsibilities for efficiency） — AIのタスク分解・意思決定能力を活用することで、開発者はインフラ・フロントエンド・バックエンド・DevOps・セキュリティといった従来の専門化の壁を越えられる。この役割の統合は、複数の専門職の必要性を減らす。プロダクトオーナーと開発者は不可欠であり、監督・検証・戦略的意思決定の重要な責任を維持する。
  9. 段階を減らし、フローを最大化する（Minimize stages, maximize flow） — 自動化と役割の統合を通じて、AI-DLCはハンドオフと移行を最小化し、継続的な反復フローを可能にする。人間の検証と意思決定は、AIが生成したコードが将来のイテレーションに対して適応可能であることを保証するために引き続き不可欠である。これらの検証は「損失関数」として機能し、下流の無駄な作業が発生する前に特定・剪定する。
  10. 固定されたワークフローを課さない（No hard-wired, opinionated SDLC workflows） — AI-DLCは異なる開発パス（新システム開発、リファクタリング、障害修正、マイクロサービスのスケーリング）に対して固定的なワークフローを規定しない。代わりに、AIが与えられた意図に基づいてLevel 1 Planを推奨する。人間は対話的にAIが生成した計画を検証・調整し、その後の階層レベルでもこの過程を続ける。

3.3 12の原則（Manifesto）

  1. 検証済みのインクリメントでリリースする（Ship in verified increments） — 動くソフトウェアは、仕様・計画・テスト・レビュー・リリースの出力である。
  2. 明確な仕様から始める（Start from a clear spec） — ストーリ、PRD、仕様は、人間が検証できるAI作業の契約となる。
  3. 生成の前に計画する（Plan before generation） — 計画は、人間の判断とエージェントの実行の間の引き継ぎである。
  4. 委譲可能になるまで分解する（Decompose until delegable） — 小さなタスクは非同期作業、モデルの変更、チームの引き継ぎに耐える。
  5. コードと同じ丁寧さでコンテキストを扱う（Craft context with the care we give code） — 仕様、Markdown、ルール、スキル、メモリは、ソフトウェアと同じ品質基準に値する。
  6. 学習を再利用可能に蓄積する（Capture learning for reuse） — 各教訓は、他者が使えるメモリ・ルール・決定・スキルになる。
  7. リリースしたすべての変更を所有する（Own every shipped change） — AIが生成しても、人間が承認・マージ・保守する。
  8. 評価できないものは委譲しない（Do not delegate what you cannot evaluate） — AIは、トレードオフを判断でき、出力を読み、挙動を証明できる場面で使う。
  9. モデルを逼迫させる前にシステムを改善する（Improve the system before forcing the model） — 出力が悪化したら、より強く要求する前に、境界・名称・テスト・コンテキストを明確にする。
  10. 一貫性が低下したらコンテキストを再構築する（Rebuild context when coherence drops） — 即興で進めるのではなく、メモリ・ドキュメント・ルール・現在の計画からリセットする。
  11. AIの失敗をシグナルとして扱う（Treat AI failure as a signal） — モデルが詰まったら、より強く押す前に、スコープ・コンテキスト・前提・テストを検査する。
  12. 実践を移転可能にする（Make the practice transferable） — 共有された手法により、異なる人物が異なるツールで同じ品質のコードを生み出せる。

4. AI-DLCの仕組み

4.1 2つの軸

AI-DLCは2つの強力な次元を強調する。

  • 人間の監督によるAI駆動実行（AI-Powered Execution with Human Oversight）: AIが体系的に詳細な作業計画を作成し、能動的に確認とガイダンスを求め、重要な意思決定を人間に委ねる。文脈的理解とビジネス要件の知識は、情報に基づいた選択を行うために人間にしか持ち合わせていない。
  • 動的なチーム協働（Dynamic Team Collaboration）: AIが定型作業を引き受けることで、チームはリアルタイムの問題解決・創造的思考・迅速な意思決定のために協働空間に集う。孤立した作業から活発なチームワークへのこの変化が、イノベーションとデリバリーを加速させる。

4.2 基本概念（アーティファクト）

  • Intent — ビジネス目標・機能・技術的成果（例: パフォーマンスのスケーリング）を包括する上位の目的ステートメント。AI駆動による実行可能タスクへの分解の出発点となる。
  • Unit — Intentから派生し、測定可能な価値を交付するために設計された、自己完結的な作業要素。スクラムのエピックやDDDのSubdomainに相当する。各Unitは機能スコープを記述するタスクセット（ユーザーストーリー）を含む。Unit間は疎結合であり、自律的な開発と独立したデプロイを可能にする。
  • Bolt — AI-DLCにおける最小のイテレーション。UnitまたはUnit内のタスクセットの急速な実装のために設計される。スクラムのスプリントに相当するが、時間〜日で計測されるビルド・検証サイクルで、集中と高速度のデリバリーを強調する。Unitは1つ以上のBoltで実行され、並列または逐次で進められる。
  • Domain Design — Unitのコアビジネスロジックを、インフラ要素から独立してモデル化する。AIはDDD原則を用いて、アグリゲート・値オブジェクト・エンティティ・ドメインイベント・リポジトリ・ファクトリといった戦略的・戦術的モデリング要素を作成する。
  • Deployment Units — パッケージ化された実行可能コード（コンテナイメージ、サーバーレス関数など）、設定（Helm Chartsなど）、インフラ要素（TerraformやCloudFormationスタックなど）を含む運用成果物。機能受入・セキュリティ・非機能要件・運用リスクの観点でテストされる。

4.3 3つのフェーズ

AI-DLCにおけるソフトウェア開発は3つのフェーズで進行する。

Inception（萌芽）フェーズ

Inceptionフェーズは、Intentを捉え、開発に向けたUnitに変換することに焦点を当てる。Mob Elaboration（モブ精査）という儀式を用いる。これは、要求の明確化と分解のための協働セッションである。

Mob Elaborationでは、以下のことが行われる。

  • AIが中心的な役割を果たし、ドメイン知識と疎結合・強結合の原則を用いて、Intentをユーザーストーリー・受け入れ基準・Unitへの初期分解を提案する。
  • プロダクトオーナー、開発者、QA、その他のステークホルダー（「モブ」）が、AIが生成した成果物を協働してレビュー・洗練し、過不足のある部分を調整する。
  • AIが確認質問を行う（例: 「主なユーザーは誰か？」「達成すべき主なビジネス成果は何か？」）。目的の包括的な理解を確保し、意図の曖昧性を最小化する。
  • AIが明確化された意図をユーザーストーリー・非機能要件（NFR）・リスク記述に展開する。

成果物として、よく定義されたUnitとそのコンポーネント（PRFAQ、ユーザーストーリー、NFR定義、リスク記述、ビジネス意図に追跡可能な測定基準、Unitの構築に用いるBoltsの提案）が得られる。

Mob Elaborationは、数週間〜数ヶ月の逐次作業を数時間に圧縮し、モブ内およびモブとAIの両方で深い合意を得る。

Construction（構築）フェーズ

Constructionフェーズは、Inceptionフェーズで定義されたUnitを検証済み・運用可能なDeployment Unitsに変換する反復的な実行を含む。以下の段階を経て進む。

  • Domain Design: AIがDDD原則を用いて、技術的考慮から独立したビジネスロジックをモデル化する。
  • Logical Design: AIがDomain Designを非機能要件に対応するよう拡張し、適切なアーキテクチャ設計パターン（CQRS、Circuit Breakerなど）を適用する。AIがArchitecture Decision Records（ADR）を作成し、開発者が検証する。
  • コード生成: AIがLogical Designから詳細なコードを生成し、Well-Architected原則への準拠を確保する。
  • テスト: AIが機能・セキュリティ・パフォーマンスのテストを生成・実行し、結果を分析して修正の推奨を提供する。

チームはMob Construction（モブ構築）という儀式で協働する。全チームが同じ部屋に集まり、統合仕様を交換し、意思決定を行い、Boltを納品する。

Brown-field（既存アプリケーション）のシナリオでは、Constructionフェーズはまず既存コードをセマンティックに豊かなモデル表現に昇華させる。これによりAIへのコンテキストが簡潔で正確になる。静的モデル（ドメインコンポーネント、責務、関係）と動的モデル（コンポーネントが重要なユースケースを実現するためにどう相互作用するか）を含む。

Operations（運用）フェーズ

Operationsフェーズは、デプロイ・オブザーバビリティ・メンテナンスの中心となる。

  • AIがモジュールをDeployment Unitsにパッケージ化する。
  • AIがテレメトリデータ（メトリクス・ログ・トレース）を分析し、パターンの検出、異常の特定、SLA違反の予測を行い、先制的な問題解決を可能にする。
  • AIが事前定義されたインシデントランブックと統合し、リソースのスケーリング、パフォーマンスチューニング、障害の分離といった実行可能な推奨を提案する。
  • 開発者が検証者として機能し、AIが生成したインサイトと提案アクションがSLAとコンプライアンス要件に沿っていることを確認する。

4.4 ワークフローの仕組み

ワークフローは再帰的なパターンで動作する。

  • ビジネス意図が与えられたとき、AIが意図を実装するためのワークフローを概説したLevel 1 Planを生成する。
  • 人間が透明性をもって計画をレビュー・検証・洗練し、ビジネス目標とエンジニアリング制約との整合性を確保する。
  • Level 1 Planの各ステップが、人間の監督のもとでAIにより、より細粒の実行可能サブタスクに分解される。
  • この分解が、その後の階層レベルでも再帰的に繰り返される。

主要なメカニズムは以下の通りである。

  • 人間の監督が損失関数として機能する: 各ステップは戦略的な意思決定点であり、人間の監督が損失関数として機能して、下流に雪だるま式に拡大する前にエラーを早期に検出・是正する。
  • コンテキストメモリ: 生成されたすべての成果物（Intent、ユーザーストーリー、ドメインモデル、テスト計画）は永続化され、AIがライフサイクル全体で参照する「コンテキストメモリ」として機能する。
  • 双方向トレース: 全成果物がリンクされており、後方・前方のトレースが可能である（例: ドメインモデル要素と特定のユーザーストーリーを結ぶ）。これにより、AIが各段階で正確で最も関連性の高いコンテキストを取得する。
  • 反復的洗練: AI-DLCは本質的に反復的であり、継続的な洗練と適応を可能にする。

5. AI-DLCと従来のSDLC

SDLCの各フェーズにおいて、AI-DLCではAIが中心的な役割を果たす。

  • Planning（計画）: 従来のSDLCでは、人間がビジネス目標をプロジェクト計画に手動で翻訳する。AI-DLCでは、AIエージェントが確認質問を行い、曖昧性を特定し、提案を行い、見逃されうる機会を提示する。これらがストーリーやプロジェクトロードマップに変換される。エージェント型AIがこのコンテキストをプロジェクト全体で維持する。
  • Analysis（分析）: AIは会議の要約を行うだけでなく、メール、サポートチケット、トランスクリプト、ドキュメントを分析し、開発が始まる前に矛盾やギャップを特定する。これにより、個人やチームでは維持が困難な、プロジェクト全体にわたる包括的な理解が得られる。
  • Design（設計）: AIがソフトウェア設計を反復的な協働に変える。アプリケーションアーキテクチャ、データベーススキーマ、API、インフラ設定、UIデザインを提案し、異なるアプローチ間のトレードオフを説明する。インタラクティブなプロトタイプを迅速に生成し、代替設計を比較し、プロジェクトの進化に伴ってアーキテクチャドキュメントを改訂できる。
  • Coding（コーディング）: AIコーディングエージェントがプロジェクトコンテキスト、コーディング規約、ビジネスロジックを理解し、これらを踏まえて自律的に構築できる。開発者が意思決定を検証し、AIが生成したコードを洗練する。
  • Verification（検証）: テストはより広い検証フェーズに置き換えられる。AIが開発完了を待たずに、開発中に継続的にテストを生成・実行する。コードの欠陥を分析し、回帰を検出し、アーキテクチャ制約への準拠を検証する。これは各ステップでバックグラウンドで発生する。
  • Deployment（デプロイ）: エージェントがリリース計画を準備し、インフラ設定を検証し、ドキュメントを生成し、本番ロールアウトを監視し、CI/CDパイプラインを最適化する。AIはリリースが安定かつ安全であり、運用目標に沿っていることを能動的に保証する。
  • Maintenance（保守）: AI-DLCは従来のソフトウェア保守を超えて、本番環境を継続的なフィードバック源として扱う。ライフサイクル全体で知識を保持することで、AIは各リリースが過去の開発サイクルで得た教訓から恩恵を受けられるようにする。

6. AI駆動開発を始めるには

AI-DLCは既存のアジャイル手法から大きく逸脱しておらず、導入の容易さが重要な成果として設計されている。組織は3つの明確なパスから始められる。

6.1 実践して学ぶ

AI-DLCは本質的に、Mob ElaborationやMob Constructionなどの儀式の集合体であり、グループで実践できるものである。ドキュメントや従来の研修で手法を学ぶのではなく、実践者がAI-DLCのガイドとともに、現在取り組んでいる複数の実際のシナリオで儀式を練習する。AWS Solution Architectsはこのアプローチを「AI-DLC Unicorn Gym」としてパッケージ化し、大規模組織への導入の拡大を実現している。

6.2 開発者体験ツールに組み込む

組織は、SDLCを横断し、開発者に統合された体験を提供する独自のオーケストレーションツールを構築できる。AI-DLCをこれらのツールに埋め込むことで、開発者は大きな導入活動なしにシームレスにAI-DLCを実践できる。AI-DLCをサポートするツールの例として、Amazon Q Developer rules、Kiro custom workflows、IBM Bob、Claude Codeがある。

6.3 既存の実践から始める

AI-DLCは、既存の手法における馴染みの深い用語間の関係性を保持しつつ、モダンな用語を導入する。既存の実践者は1日以内に方向性を把握し、実践を始めることができる。連想的学習による導入の容易さをサポートする。

🐟 付録: 用語集

  • Waterfall（ウォーターフォール）: 要件定義→設計→実装→テスト→運用と段階的に進める従来のソフトウェア開発手法。
  • Agile（アジャイル）: 短いイテレーションで価値を交付し、変化に適応するソフトウェア開発の考え方の総称。
  • Scrum（スクラム）: スプリントを反復し、プロダクトオーナー・スクラムマスター・開発チームの3役割で協働するアジャイルフレームワーク。
  • Sprint（スプリント）: スクラムにおける固定期間（通常2〜4週間）の反復サイクル。特定の成果を納品する単位。
  • Epic（エピック）: スクラムやアジャイルにおいて、複数のユーザーストーリーを含む大規模な作業単位。
  • User Story（ユーザーストーリー）: ユーザーの視点から書かれた機能要件の記述。「[役割]として、[機能]が欲しい。それは[恩恵]のためである」の形式が典型。
  • Acceptance Criteria（受け入れ基準）: ユーザーストーリーが完成したと判断するための具体的条件。
  • Product Owner（プロダクトオーナー）: プロダクトの価値を最大化する責任を負う役割。プロダクトバックログの優先順位付けを行う。
  • Backlog（バックログ）: 実施すべき作業のリスト。プロダクトバックログ（機能や改善の候補）とスプリントバックログ（1スプリントで取り組むタスク）に分かれる。
  • Daily Standup（デイリースタンドアップ）: 毎日短時間で行うチームの状況共有会議。「昨日何をしたか」「今日何をするか」「何が妨げになっているか」を共有する。
  • Retrospective（レトロスペクティブ）: 1イテレーションの終わりに行われる、プロセス改善のための振り返り会議。
  • Kanban（カンバン）: ワークフローを可視化し、ワークインプログレスを制限することでフローを最適化するアジャイル手法。
  • NFR（Non-Functional Requirements, 非機能要件）: 機能そのものではなく、スケーラビリティ、セキュリティ、パフォーマンスなどシステム全体の属性を記述する要件。
  • ADR（Architecture Decision Records, アーキテクチャ決定記録）: アーキテクチャ上の重要な決定とその理由を記録したドキュメント。
  • DDD（Domain-Driven Design, ドメイン駆動設計）: ドメイン（ビジネス領域）のモデルを中心にソフトウェアを設計する手法。Subdomain、Bounded Context、Aggregateなどの概念を含む。
  • BDD（Behavior-Driven Development, 振る舞い駆動開発）: ユーザーの視点からシステムの振る舞いを定義し、それをテストに落とし込む開発手法。
  • TDD（Test-Driven Development, テスト駆動開発）: まずテストを書き、それをパスさせるコードを書く開発手法。
  • Subdomain（サブドメイン）: DDDにおいて、ドメインをさらに細かく分割した領域。エピックやUnitに相当する。
  • Bounded Context（境界づけられたコンテキスト）: DDDにおける、ドメインモデルが有効な範囲（境界）。一つの境界づけられたコンテキスト内では用語の意味が一貫し、異なる境界づけられたコンテキスト間では同じ言葉でも異なる意味を持つことがある。
  • Aggregate（アグリゲート）: DDDにおける、一貫性を保証するためのエンティティと値オブジェクトのグループ。トランザクションの境界として機能する。
  • CQRS（Command Query Responsibility Segregation）: 書き込み（Command）と読み出し（Query）を分離するアーキテクチャパターン。
  • Circuit Breaker（サーキットブレーカー）: 障害が拡大することを防ぐために、一定の失敗が続くと呼び出しを遮断するパターン。
  • CI/CD（Continuous Integration / Continuous Deployment）: コード変更を継続的に統合し、自動的にデプロイする開発プロセス。
  • PRFAQ: AI-DLCで用いる、Product Requirements FAQの略。ビジネス意図・機能・期待される効果をまとめた文書。

📚 参考文献