この記事の目次
アジャイル開発
アジャイル開発は、短いサイクルを繰り返しながら開発を進める手法です。Webサービスやスタートアップなど、変化の多い開発でよく使われています。
アジャイルとは
「アジャイル（Agile）」は「俊敏な」「素早い」という意味です。変化に素早く対応しながら開発を進めます。
┌─────────────────────────────────────┐
│ 計画 → 開発 → テスト → レビュー │← スプリント1（1〜4週間）
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ 計画 → 開発 → テスト → レビュー │← スプリント2
└─────────────────────────────────────┘
↓
（繰り返し）
1〜4週間程度の「スプリント」を繰り返し、少しずつ機能を完成させていきます。
アジャイルでも要件定義・設計はある
よくある誤解：「アジャイルでは要件定義や設計をしない」
これは間違いです。アジャイルでも要件定義・設計はあります。やり方が違うだけです。
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 要件定義 | 最初に全部決める | 少しずつ決めていく |
| 設計 | 詳細まで最初に決める | 必要な分だけその都度決める |
| タイミング | プロジェクト開始時にまとめて | 各スプリントで繰り返し |
アジャイルでの要件定義
アジャイルでは「プロダクトバックログ」という形で要件を管理します。
【プロダクトバックログ】
1. ユーザー登録機能 ← 優先度：高
2. 商品検索機能 ← 優先度：高
3. カート機能 ← 優先度：中
4. お気に入り機能 ← 優先度：低
5. レビュー機能 ← 優先度：低
...
- 優先度の高いものから順に作る
- 途中で優先度を変えたり、新しい要件を追加したりできる
- 全部を最初に決める必要はない
アジャイルでの設計
アジャイルでは「今作るものに必要な設計」をその都度行います。
【スプリント1】
「ユーザー登録機能」を作る
→ ユーザー登録に必要な設計をする
→ 実装する
→ テストする
【スプリント2】
「商品検索機能」を作る
→ 商品検索に必要な設計をする
→ 必要なら前回の設計を見直す
→ 実装する
→ テストする
- 大きな設計を最初にするのではなく、必要な分だけ設計する
- 後から設計を見直す（リファクタリング）ことを前提としている
特徴
| 項目 | 内容 |
|---|---|
| 計画性 | 短期間の計画を繰り返し立てる |
| ドキュメント | 最低限にして、動くソフトウェアを重視 |
| 変更への対応 | 変更を前提としている |
| 品質管理 | 継続的にテスト・レビューを行う |
| 進捗管理 | 動く機能の数で測る |
代表的なアジャイル手法
スクラム（Scrum）
最も広く使われているアジャイル手法です。
役割
| 役割 | 責任 |
|---|---|
| プロダクトオーナー | 何を作るかを決める。優先順位を決める |
| スクラムマスター | チームがうまく動けるようにサポートする |
| 開発チーム | 実際に作る人たち（3〜9人程度） |
スプリントの流れ
【スプリント（1〜4週間）】
1. スプリントプランニング
- 今回のスプリントで何を作るか決める
2. 開発作業
- 毎日：デイリースクラム（15分の進捗確認）
- 実装・テストを進める
3. スプリントレビュー
- 作ったものをお客様やステークホルダーに見せる
4. レトロスペクティブ（振り返り）
- チームの改善点を話し合う
イベント
| イベント | 内容 | 頻度 |
|---|---|---|
| スプリントプランニング | スプリントで何を作るか決める | スプリント開始時 |
| デイリースクラム | 短い進捗確認（15分） | 毎日 |
| スプリントレビュー | 成果物を確認してもらう | スプリント終了時 |
| レトロスペクティブ | 振り返りと改善 | スプリント終了時 |
カンバン（Kanban）
ボードを使ってタスクの流れを可視化する手法です。
| To Do | In Progress | Review | Done |
|----------|-------------|----------|----------|
| タスクA | | | |
| | タスクB | | |
| | | タスクC | |
| | | | タスクD |
- タスクを「カード」として管理
- 左から右へ流れていく
- 仕掛かり制限（WIP制限）：同時に作業できる数を制限
スプリントのような固定サイクルはなく、継続的に流れていくのが特徴です。
メリット
- 変化に強い：途中で「やっぱりこうしたい」に対応しやすい
- 早く動くものが見える：スプリントごとに動くものができる
- フィードバックが早い：こまめに確認できるので、認識ずれを早期発見
- 優先度の高いものから作れる：重要な機能を先に完成させられる
- リスクを早期に発見：問題があれば早い段階で分かる
デメリット
- 全体像が見えにくい：最終的な完成形が曖昧になることも
- 見積もりが難しい：「いつ完成するか」「いくらかかるか」が読みにくい
- コミュニケーションコストが高い：頻繁な会議や調整が必要
- メンバーのスキルに依存：自律的に動ける人が求められる
- ドキュメントが残りにくい：後から参加した人が理解しにくい
よく使われる現場
| 種類 | 理由 |
|---|---|
| Webサービス・アプリ | 市場の反応を見ながら改善したい |
| スタートアップ | 何が正解か分からない状態で、試行錯誤したい |
| 自社サービス開発 | 自分たちでスピーディーに改善したい |
| 新規事業 | 要件が不確定で、変化が多い |
| 継続的に改善するプロダクト | 終わりがなく、常に進化させる |
1年目エンジニアの日常
アジャイルの現場では、以下のような仕事が多いです。
デイリースクラム（朝会）
毎日15分程度、チームで進捗確認をします。
- 昨日やったこと
- 今日やること
- 困っていること
「困っていること」を正直に共有することが大切です。
スプリント内のタスク
プロダクトバックログから選ばれたタスクを担当します。
- 機能の実装
- バグの修正
- テストコードの作成
1つのタスクを最後までやりきることが多いです。
レビューやふりかえり
- スプリントレビュー：作ったものを見せる。フィードバックをもらう
- レトロスペクティブ：「もっとこうしたい」を話し合う
1年目でも意見を求められることが多いです。
アジャイルで大切なこと
分からないことはすぐ聞く
アジャイルではコミュニケーションが命です。
- 「たぶんこうだろう」で進めない
- 詰まったら15分で相談
- 聞くことは恥ずかしいことではない
自分から動く
ウォーターフォールより自律性が求められます。
- タスクが終わったら次のタスクを取りに行く
- 改善点があれば提案する
- チームのために何ができるか考える
チームで助け合う
アジャイルではチーム全体で成果を出すことが重視されます。
- 困っている人がいたら助ける
- 自分だけ終わっていればOKではない
- 知識を共有する
ウォーターフォールとの比較
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 計画 | 最初に全体を決める | 短期間ごとに決める |
| 要件定義 | 最初にまとめて行う | 少しずつ決めていく |
| 設計 | 詳細まで最初に決める | 必要な分だけその都度 |
| 変更 | 難しい（コストが大きい） | 前提として受け入れる |
| ドキュメント | 重視する | 最小限にする |
| 動くものができるまで | プロジェクト終盤 | 各スプリント終了時 |
| お客様との関わり | 最初と最後が中心 | 継続的に関わる |
| チームの動き方 | 役割が明確に分かれる | 全員で協力する |
| 向いている案件 | 要件が明確、変化が少ない | 要件が不確定、変化が多い |
ハイブリッド型
実際の現場では、**両方の良いところを取り入れた「ハイブリッド型」**も多いです。
例1：全体はウォーターフォール、一部はアジャイル
要件定義 → 基本設計 → [アジャイル的に実装] → システムテスト → リリース
大枠の計画はウォーターフォールで決めつつ、実装フェーズは柔軟に進める。
例2：アジャイルだがドキュメントも作る
スプリントで開発しつつ、必要なドキュメント（設計書、テスト仕様書）も並行して作成。
まとめ
- アジャイルは短いサイクルを繰り返しながら開発を進める手法
- 要件定義・設計がなくなるわけではない（やり方が違うだけ）
- 変化に強く、早くフィードバックを得られるのがメリット
- スクラム、カンバンなどの手法がある
- 1年目は「デイリースクラム参加」「タスク担当」「すぐ聞く」が大切
- コミュニケーションと自律性が求められる
ウォーターフォールについては ウォーターフォール開発 を参照してください。