「作ってみないと精度が分からない」AI開発では、最初に完璧な計画を立てること自体が困難です。だからこそ、短いサイクルで試作と改善を繰り返すアジャイル開発が力を発揮します。G検定第7章では、ウォーターフォール開発との対比でAIプロジェクトに適した進め方として問われる重要キーワードです。

📖 ひと言でいうと

アジャイル開発とは、短期間の反復作業(スプリント)を繰り返しながらシステムを構築するソフトウェア開発手法です。「アジャイル(agile)」は「俊敏な」という意味で、変化への素早い対応を重視します。

例えるなら、地図のない山道を進むときの歩き方です。最初に全ルートを決め切るのではなく、少し進んでは現在地を確かめ、必要なら進路を修正する。AI開発のように「やってみないと分からない」要素が多い道のりでは、この小刻みな確認と軌道修正が遭難(プロジェクトの失敗)を防ぎます。

🖼 1枚でわかるアジャイル

アジャイル開発
  • 定義 — 短期間の反復(スプリント)を繰り返しながらシステムを構築する開発手法
  • 由来 — 2001年発表の「アジャイルソフトウェア開発宣言」に基づく
  • 強み — 顧客のフィードバックを迅速に取り込み、方向性を柔軟に修正できる
  • AIとの相性 — 技術・市場の変化が速く試行錯誤が必須のAI開発に適する
  • 対の概念 — 各工程を順番に進めるウォーターフォール開発
つくもち屋「G検定対策」SUMMARY

📘 公式テキストの説明

アジャイル開発は、ソフトウェア開発手法の一つで、短期間の反復作業を繰り返しながらシステムを構築する方法である。この手法は、2001年に発表された「アジャイルソフトウェア開発宣言」に基づいており、変化の激しい環境下での柔軟な対応を重視している。従来のウォーターフォール型開発が各工程を順次進めるのに対し、アジャイル開発では短いサイクル(スプリント)を繰り返し、各サイクルごとに機能の追加や改善を行う。これにより、顧客からのフィードバックを迅速に取り入れ、開発の方向性を適宜修正することが可能となる。特にAI開発においては、技術の進歩や市場の変化が速いため、アジャイル開発の柔軟性が適しているとされる。例えば、AIモデルのトレーニングや評価をスプリントごとに行い、その結果を基にモデルの改良を重ねることで、精度の高いシステムを効率的に構築できる。また、アジャイル開発ではチーム内のコミュニケーションが活発になり、各メンバーが積極的に意見を交換することで、より良い成果物の作成が期待できる。ただし、アジャイル開発を導入する際には、チーム全体の理解と協力が不可欠であり、適切なプロジェクト管理が求められる。

押さえるべき軸は3つです。①ウォーターフォールが「各工程を順次進める」のに対し、アジャイルは「短いサイクル(スプリント)を繰り返す」という進め方の違い。②その効果として「フィードバックの迅速な取り込み」と「方向性の適宜修正」ができること。③AI開発では技術・市場の変化が速いため、この柔軟性が適しているという結論です。

2001年の「アジャイルソフトウェア開発宣言」という出典年も、試験で問われうる具体的な事実として覚えておきましょう。

🔍 しっかり理解する

スプリントという「小さな一周」

アジャイル開発では、1〜4週間程度の固定期間をスプリントと呼び、その中で「計画→開発→評価→振り返り」を一通り回します。スプリントが終わるたびに動くもの(機能の一部やモデルの試作版)ができあがり、それを顧客や関係者に見せてフィードバックをもらい、次のスプリントの計画に反映します。

スプリント計画
今回の期間で作るものを決める
開発・改善
機能追加やモデル改良を実施
評価・フィードバック
成果物を確認し意見を集める
方向修正して次へ
学びを次のスプリントに反映

この構造の利点は、「間違いに気づくのが早い」ことに尽きます。数週間ごとに現物を確認するため、要望とのずれや技術的な行き詰まりが小さいうちに発見・修正できます。

なぜAI開発と相性が良いのか

AIプロジェクトには「要件を最初に確定できない」という宿命があります。モデルの精度はデータ次第で、目標精度に届くか、どんな前処理が効くか、そもそもその課題がAIに向いているかは、作って評価してみるまで分かりません。最初に全工程の計画を固めるウォーターフォール型は、この不確実性と根本的に相性が悪いのです。

アジャイルなら、スプリントごとにモデルのトレーニングと評価を行い、結果を見て「特徴量を変える」「データを追加する」「目標自体を見直す」といった軌道修正を重ねられます。公式テキストの「AIモデルのトレーニングや評価をスプリントごとに行い、その結果を基にモデルの改良を重ねる」という記述は、まさにこの試行錯誤のループを指しています。PoC(概念実証)で実現可能性を確かめつつ段階的に開発を進めるAIプロジェクトの標準的な進め方は、アジャイルの発想と地続きです。

万能ではない——導入の条件

公式テキストは「チーム全体の理解と協力が不可欠であり、適切なプロジェクト管理が求められる」と釘を刺しています。アジャイルは計画書や指示を待たず、メンバーが自律的に判断し密に意見交換することを前提とするため、活発なコミュニケーションが機能しないチームでは「計画がないだけの行き当たりばったり」になりかねません。柔軟さは、規律ある反復と振り返りがあって初めて成立します。

💡 具体例で考える

コールセンターの応対品質を分析するAIを開発する場面を考えます。発注元は当初「オペレーターの応対を自動採点したい」と言っていたとします。第1スプリントで通話テキストの分類モデルを試作して見せたところ、「採点よりも、クレームに発展しそうな通話をリアルタイムで検知するほうが価値が高い」と現場から声が上がりました。

アジャイルであれば、この気づきを次のスプリントからすぐ開発に反映できます。もし1年がかりのウォーターフォール型で「自動採点システム」の要件を確定していたら、完成後に「欲しかったのはこれではない」と判明する最悪の展開になっていたでしょう。数週間ごとに現物とフィードバックを往復させる進め方が、要件のずれを早期に吸収した例です。

⚠️ よくある誤解・紛らわしい用語

💡 ポイント
  • 「アジャイル=計画を立てない」ではない — スプリントごとに綿密な計画と振り返りを行います。長期の詳細計画を最初に固定しない、というだけです。
  • ウォーターフォールとの対比 — ウォーターフォールは要件定義→設計→実装→テストと各工程を順次進める手法。アジャイルは短いサイクルの反復で、対の概念として頻出です。
  • PoCとの違い — PoCは開発着手前に実現可能性を検証する工程、アジャイルは開発の進め方そのものです。AIプロジェクトでは両者が組み合わせて使われます。
  • 「アジャイルが常に優れている」わけではない — 要件が明確で変更が少ない大規模プロジェクトでは、計画性に優れるウォーターフォールが適する場合もあります。両者を組み合わせたハイブリッド型も存在します。

📝 試験でのポイント

💡 ポイント
  • 定義問題では「短期間の反復作業(スプリント)を繰り返す」「2001年のアジャイルソフトウェア開発宣言」が正解の目印になります。
  • ウォーターフォールとの対比問題が最頻出パターンです。「各工程を順次進める」=ウォーターフォール、「短いサイクルを繰り返す」=アジャイルの対応を確実に。
  • 「AI開発にアジャイルが適する理由」として、技術・市場の変化の速さと試行錯誤の必要性を挙げる選択肢が想定されます。
  • 導入時の留意点(チーム全体の理解と協力、適切なプロジェクト管理)まで問われることがあります。

📚 まとめ

💡 ポイント
  • アジャイル開発は、短期間の反復(スプリント)を繰り返しながらシステムを構築する手法で、2001年の「アジャイルソフトウェア開発宣言」に基づきます。
  • サイクルごとに機能追加・改善とフィードバック反映を行うため、変化の激しい環境で方向修正しやすいのが強みです。
  • 精度が事前に読めず試行錯誤が必須のAI開発とは特に相性が良く、スプリント単位でモデルの学習・評価・改良を重ねます。
  • 対の概念はウォーターフォール開発。導入にはチームの理解・協力と適切なプロジェクト管理が不可欠です。