U過去問を解いていて「スクラムマスターって何をする人だっけ？」と選択肢の前で固まったことがあります。ロール・イベント・作成物、それぞれの名称と役割が頭の中で混線していたのです。この記事では、スクラムの構造をまるごと整理しています。
この記事では、アジャイル開発の基本思想からスクラムの全構造（3ロール・5イベント・3作成物）、ベロシティとバーンダウンチャートの読み方、XPの主要プラクティス、そして過去問での出題パターンまでを一気に整理します。「なんとなく知っている」状態から「選択肢で迷わない」状態に持っていくことを目指しています。
アジャイル開発とは何か
アジャイル（Agile）とは「機敏な・素早い」を意味する英語です。2001年に発表された「アジャイルソフトウェア開発宣言」によって体系化されました。従来のウォーターフォール型と比較すると、開発の思想そのものが異なります。
ドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
| 観点 | ウォーターフォール | アジャイル |
|---|---|---|
| 要件定義 | 開始前に全要件を確定する | 開発しながら継続的に精緻化する |
| 変更への対応 | 困難（後工程での変更コストが大きい） | 歓迎する（スプリント単位で柔軟に対応） |
| リリース | 最終工程で一括リリース | 各スプリントで部分的にリリース |
| 品質確認 | テスト工程で一括確認 | 各スプリントで随時確認 |
| 向いている場面 | 要件が明確で変化が少ない大規模システム | 要件が不明確で変化が多いWebサービス等 |
スクラムの3つのロール
スクラムでは「プロダクトオーナー」「スクラムマスター」「開発チーム」の3つのロールが明確に定義されています。試験では各ロールの責任範囲を問う問題が頻出です。
スクラムの5つのイベント
スクラムのイベントは、スプリント自体を含めて5つあります。それぞれの目的と所要時間を整理しておくと、試験での選択肢の判断が速くなります。
プランニング
スクラム
レビュー
ペクティブ
| イベント名 | 目的 | 参加者・時間 |
|---|---|---|
| スプリント（Sprint） | 1〜4週間の固定開発サイクル。期間中は目標を変更しない | スクラムチーム全員 |
| スプリントプランニング | スプリントのゴールを設定し、スプリントバックログを作成する | 全員／スプリント期間×2時間が目安 |
| デイリースクラム | 毎日15分の短い同期会。昨日の成果・今日の計画・障害を共有する | 開発チーム主体／15分上限 |
| スプリントレビュー | スプリントで完成したインクリメントを顧客・ステークホルダーに示し、フィードバックを得る | 全員＋ステークホルダー |
| スプリントレトロスペクティブ | チームのプロセス改善を話し合う振り返り。「何がうまくいったか・次に改善するか」を検討する | スクラムチーム全員 |
U「レビュー」と「レトロスペクティブ」の違いが最初わかりにくかったのですが、レビューはプロダクト（成果物）を見せる場、レトロスペクティブはチームのプロセスを振り返る場、と整理したら混同しなくなりました。
スクラムの3つの作成物（アーティファクト）
ベロシティとバーンダウンチャート
ベロシティ = 3 + 5 + 2 = 10ポイント
活用方法：過去数スプリントの平均ベロシティをもとに、「残りのバックログを消化するのに何スプリント必要か」をおおよそ予測できます。ベロシティが安定してくることがチームの成熟を示す指標の一つです。
XP（エクストリームプログラミング）の主要プラクティス
XP（Extreme Programming）はスクラムと並ぶアジャイル手法の代表格です。技術的なプラクティスに特に注力しており、以下の項目が試験で問われます。
| プラクティス | 内容 | 試験ポイント |
|---|---|---|
| テスト駆動開発（TDD） | 先にテストを書き、そのテストをパスするコードを書く | 「テストを先に書く」が最重要。実装前にテストが存在する。 |
| ペアプログラミング | 2人で1台のPCを共有し、1人がコードを書き1人がレビューする | レビューコストの削減とナレッジ共有が目的。生産性は短期的に下がることもある。 |
| 継続的インテグレーション（CI） | コードを頻繁にリポジトリへ統合し、自動テストを実行する | 「頻繁な統合」「自動テスト」がキーワード。結合コストを小さく保つ。 |
| リファクタリング | 外部から見た動作を変えずに内部構造を改善する | 「機能を変えずに構造を改善」が定義。バグ修正や機能追加とは異なる。 |
| 小さなリリース | 価値を小さな単位で頻繁にリリースする | フィードバックサイクルを短縮し、リスクを分散する。 |
| シンプルな設計 | 現時点で必要な機能だけを実装する（YAGNI原則） | YAGNI = “You Ain’t Gonna Need It”。過剰設計を排除する考え方。 |
| 顧客代表（オンサイト顧客） | 顧客の代表がチームに常駐し、優先度決定やフィードバックを行う | スクラムのプロダクトオーナーと役割が近いが、XPでは常駐が強調される。 |
| 共同所有 | コードの特定部分を担当者が占有せず、誰でも変更できる | 属人化を防ぎ、バス係数（キーパーソン離脱リスク）を下げる。 |
UTDDは「テストを後から書く」と勘違いしていた時期がありました。「テスト→実装→リファクタリング」の順番（Red-Green-Refactorサイクルとも呼ばれます）をそのまま覚えておくと選択肢で迷わなくなりました。
身近な場面で整理するスクラムの構造
スクラムの構造が抽象的に感じられたとき、「ケーキ屋の新商品開発」に置き換えてみると整理しやすくなりました。
過去問で確認する
スクラムに関する記述として最も適切なものを選ぶ形式の問題。スプリント・バックログ・スクラムマスター・デイリースクラムの説明がそれぞれ選択肢に並ぶ。
スプリント：「固定期間（1〜4週間）の開発サイクル。期間中の目標は変更しない」
プロダクトバックログ：「POが管理する優先順位付きの要求リスト」
スクラムマスター：「プロセスサポート役。開発を指揮するわけではない」
誤答選択肢は「スクラムマスターが優先順位を決める」「スプリント中に目標を変更できる」などが典型です。
エクストリームプログラミング（XP）のプラクティスに関する記述。TDD・ペアプログラミング・継続的インテグレーション・リファクタリングの説明として適切なものを選ぶ。
リファクタリング：「外部動作を変えずに内部構造を改善する」。「機能追加」や「バグ修正」はリファクタリングではない。
継続的インテグレーション：「頻繁にコードを統合し自動テストを実行する」。手動テストとの区別に注意。
アジャイル開発における進捗管理の指標に関する問題。ベロシティの定義またはバーンダウンチャートの読み方を問う形式。
バーンダウンチャート：縦軸＝残作業量（ストーリーポイント）、横軸＝日数。グラフが右下に向かって減少するのが理想的な形。実績線が理想線より上にある＝遅延。
「燃え尽きる（Burn Down）」チャートなので、完了に向かって残作業量が減っていく点を押さえておきましょう。
また「カンバン」と「スクラム」の違いも試験で問われることがあります。スクラムはスプリントという固定の時間枠（タイムボックス）を持つのに対して、カンバンはフロー型（作業が終わったら次を引き取る）で固定サイクルを持ちません。詳しくはシステム開発手法の比較記事もあわせてご覧ください。
- アジャイルはウォーターフォールと対になる概念。変化への対応・短いサイクルでのリリースが核心
- スクラムの3ロール：PO（バックログ管理）・SM（プロセスサポート）・開発チーム（自己組織化）
- スクラムの5イベント：スプリント・プランニング・デイリースクラム・レビュー・レトロスペクティブ
- スクラムの3作成物：プロダクトバックログ（PO管理）・スプリントバックログ（開発チーム管理）・インクリメント
- ベロシティ＝1スプリントで完了したストーリーポイントの合計。バーンダウンチャートは残作業量を可視化する
- XPのプラクティス：TDD（テスト先行）・ペアプログラミング・CI・リファクタリング（動作を変えず構造改善）
U各用語の「誰が何をするか」「何が目的か」を一言で言える状態になると、選択肢の迷いがかなり減ります。同じように学習を進めている方のお役に立てましたら幸いです。
