アジャイル開発

アジャイル開発とは

アジャイル開発は、短い期間(1〜2週間)で動くソフトウェアを作り、フィードバックを得て軌道修正を繰り返す開発手法の総称です。「最初に全部決めて、そのとおり作る」[[ウォーターフォール開発]] と対比されます。

「アジャイル」は特定の手順書の名前ではありません。2001年に「アジャイルソフトウェア開発宣言」としてまとめられた価値観の呼び名であり、その下に [[スクラム]] や XP といった具体的な実践方法が並びます。

3つの中核

• 反復(イテレーション) — 決まった長さの期間を区切り、その中で計画・開発・確認・改善を一巡させます。入りきらない作業のほうを次のサイクルへ回し、期間は動かさないのが原則です。期限を延ばして詰め込むと、サイクルを回す意味が失われます
• 動くソフトウェアで確かめる — 進捗を資料の完成度ではなく「実際に動く機能がどれだけ増えたか」で測ります。設計書の上では正しく見えても、触ってみて初めて分かる認識のずれを早い段階で拾うためです
• 変化への対応 — 要求が途中で変わることを、失敗ではなく前提として扱います。だからこそ遠い先の分まで作り込まず、次のサイクルで捨て直せる程度の小ささを保ちます

初学者向けポイント

• 核心は「計画どおり作ることより価値ある物を届けること」。要求は変わるのが前提
• スクラムが最も普及したフレームワーク: スプリント(固定期間)ごとに計画→開発→レビュー→振り返りを回す
• 「アジャイル=ドキュメントを書かない・計画しない」は誤解。むしろ頻繁に計画する

スクラムの基本要素

[[スクラム]] は、アジャイルを実践するための代表的な [フレームワーク]です。「何を・いつ話し合うか」の型だけを定め、具体的なやり方はチームに委ねます。

XP(エクストリームプログラミング)由来の技術プラクティス

アジャイルの「頻繁なリリース」は技術の裏付けがあって初めて成立します。その裏付けを最初に体系化したのが XP(エクストリームプログラミング)です。1990年代後半に提唱されたアジャイル手法の1つで、良いとされる開発習慣を極端なまでに徹底する、という発想で組み立てられています。

チームの運営方法を主に扱うスクラムと違い、XP はコードの書き方そのものに踏み込むのが特徴です。今では手法の名前を意識せずに使われている次のプラクティスは、いずれも XP が広めたものです。

• ペアプログラミング — 2人で1つのコードを一緒に書く(→ [[ペアプログラミングとモブプログラミング]])
• [[テスト駆動開発]] — テストを先に書いてから実装する
• [[CI/CD]] — このうち CI(継続的インテグレーション)が XP 由来。変更を頻繁に統合して壊れていないかを確かめる
• [[リファクタリング]] — 外から見た動作を変えずに内部構造を改善し続ける

これらはいずれも [[自動テスト]] と [[Git]] を土台にしています。スクラムを採用したチームが、日々の作業のやり方として XP のプラクティスを併用することもよくあります。

関連技術とのつながり

• [[スクラム]] — アジャイルを実践する最も普及したフレームワーク
• [[ウォーターフォール開発]] — 対比される計画重視の開発モデル
• [[CI/CD]] — アジャイルを支える自動化基盤
• [[Git]] — 短いサイクルの開発を支えるバージョン管理

Q: アジャイル開発で進捗を測る主な基準はどれ?
- [x] 実際に動くソフトウェアがどれだけ増えたか
- [ ] 設計書などのドキュメントが何ページ書けたか
- [ ] 当初の計画から何日遅れていないか
解説: 動くソフトウェアで確かめるのがアジャイルの中核です。資料の完成度ではなく、動く機能の増え方で進捗を測ります。

Q: 反復(イテレーション)に作業が入りきらないと分かったときの原則はどれ?
- [ ] 期限を延ばして予定した作業をすべてやりきる
- [x] 期間は動かさず、入りきらない作業を次のサイクルへ回す
- [ ] その反復を中止して計画からやり直す
解説: 期間を固定し、作業量のほうを調整します。期限を延ばして詰め込むと、短いサイクルを回す意味が失われます。

Q: ペアプログラミング・テスト駆動開発・リファクタリングといった技術プラクティスを体系化したアジャイル手法はどれ?
- [ ] ウォーターフォール開発
- [ ] スクラム
- [x] XP(エクストリームプログラミング)
解説: XP はコードの書き方そのものに踏み込む手法で、これらのプラクティスを広めました。スクラムは主にチーム運営の枠組みを扱います。