ガイド
アジャイル開発とスクラム開発の違い
「アジャイル」と「スクラム」は混同されがちですが、異なる概念です。アジャイルは開発思想・価値観であり、スクラムはその思想を実践するための具体的なフレームワークです。
アジャイル開発とは
アジャイル（Agile）は2001年に「アジャイルソフトウェア開発宣言」として発表された開発思想です。4つの価値観と12の原則から構成されます。
プロセスやツールより個人と対話を優先する
包括的なドキュメントより動くソフトウェアを優先する
契約交渉より顧客との協調を優先する
計画に従うことより変化への対応を優先する
※ 右側の価値を優先するが、左側に価値がないというわけではない
ウォーターフォール vs アジャイル
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 要件定義→設計→開発→テスト→リリースを順番に | 小さなサイクル（スプリント）を繰り返す |
| 要件変更 | 変更コストが高い（後工程ほど高くつく） | 変更を歓迎・スプリントごとに優先度を見直す |
| 顧客関与 | 初期の要件定義と最終受け入れのみ | スプリントごとにフィードバックをもらう |
| リスク | 最終工程まで動くものが見えない | 早期から動くものを確認できる |
| 向いているプロジェクト | 要件が固定・変更が少ない大規模SIer案件 | 要件が変化する・スピードが重要なプロダクト開発 |
| ドキュメント | 詳細なドキュメントを重視 | 必要最小限のドキュメント |
スクラムとは — アジャイルの代表的フレームワーク
スクラムはアジャイルの思想を実践するフレームワークのひとつです。2〜4週間の「スプリント」を繰り返す反復型開発で、3つの役割・5つのイベント・3つの成果物で構成されます。
3つの役割
プロダクトオーナー（PO）
プロダクトバックログを管理し、ビジネス価値の優先順位を決定する。顧客・ステークホルダーの代表。
スクラムマスター（SM）
スクラムの実践を支援するファシリテーター。チームの障害を取り除き、プロセスを改善する。
開発チーム
3〜9名の自己組織化されたチーム。スプリントゴールの達成に責任を持つ。
5つのイベント（セレモニー）
スプリント（Sprint）
2〜4週間すべての作業が行われるタイムボックス。スプリントゴールに向けて開発を進める。
スプリントプランニング
スプリント開始時スプリントで完了させるバックログアイテムを選定し、スプリントゴールを設定する。
デイリースクラム
毎日15分昨日やったこと・今日やること・障害を共有する。進捗確認ではなく協調のための場。
スプリントレビュー
スプリント終了時動くソフトウェアをステークホルダーにデモし、フィードバックを得る。
スプリントレトロスペクティブ
スプリント終了時チームのプロセスを振り返り、改善策を特定する。「Keep・Problem・Try」で整理することが多い。
スクラム vs カンバン
スクラムと並んでよく使われるアジャイルフレームワークがカンバン（Kanban）です。
イテレーション
スプリント（固定長）
なし（継続的フロー）
チーム役割
PO・SM・開発チームが必要
役割定義なし
作業量制限
スプリントバックログで管理
WIP制限（進行中タスク数上限）
向いている場面
新規プロダクト開発・機能追加
運用保守・サポート・継続的改善
アジャイル開発とアーキテクチャ設計の関係
「アジャイルはドキュメントを書かない」は誤解です。アジャイルで重要なのは「変化に対応できる設計」を「必要なときに必要なだけ設計する」ことです。
- ▸アーキテクチャは最初に大枠を決める: スプリント0（またはインセプションデッキ）でシステム全体のアーキテクチャ方針・技術スタック・非機能要件の優先度を決定しておく。後から変更が難しい決断ほど早期に行う。
- ▸詳細設計はJust-in-Time: 機能の詳細設計は、そのスプリントで実装する直前に行う。先々の実装まで詳細に設計しても、要件変更で無駄になることが多い。
- ▸ADRで意思決定を記録: アーキテクチャ上の重要な決定はArchitecture Decision Record（ADR）として記録する。スプリントをまたいでチームの認識を統一するために有効。
- ▸リファクタリングを計画に含める: 技術的負債が積み重なるとアジャイルの速度が低下する。スプリントバックログにリファクタリングタスクを定期的に組み込む。
ArchitectAI でアジャイル開発に必要なアーキテクチャ設計書・ADR・非機能要件定義書を素早く生成できます。
無料で始める（10クレジット）