Agile 原則とスクラム
PMP試験の 約50% がアジャイル / ハイブリッド系。スクラム用語は 完全暗記必須。
1. アジャイル宣言(Agile Manifesto)
2001年、17人のソフトウェア開発者が制定。
4つの価値観
左より 右 を重視:
| 左(伝統) | 右(アジャイル) |
|---|---|
| プロセスとツール | 個人と対話 |
| 包括的なドキュメント | 動くソフトウェア |
| 契約交渉 | 顧客との協調 |
| 計画に従う | 変化への対応 |
→ 左にも価値はあるが、右により価値を 置く。
12原則(要点)
- 顧客満足を最優先・早期かつ継続的提供
- 要求の変更を歓迎(後期でも)
- 短いタイムスケールで動くソフトウェア提供
- ビジネスと開発者が 日々協働
- やる気のある個人を中心に、必要環境と支援を与え信頼する
- 対面コミュニケーション が最も効率的
- 動くソフトウェアが進捗の主指標
- 持続可能な開発ペース
- 技術的卓越性と良い設計
- シンプルさ — やらない仕事を最大化
- 自己組織化チームから良いアーキテクチャ
- 定期的な 振り返り と適応
試験のヒント
- アジャイル系問題は左より右の価値観で判断
- 「契約より協働」「プロセスより対話」「文書より動くもの」
- 「変化への対応」が中心思想
2. スクラム概要
最も広く使われるアジャイル・フレームワーク。
3つの役割(Roles / Accountabilities)
Product Owner(PO)
- プロダクトの 価値最大化 に責任
- プロダクトバックログの管理(優先順位付け)
- ステークホルダーの代表
- 「何を作るか」を決める権限
Scrum Master(SM)
- スクラムの エキスパート、コーチ
- 障害除去(impediments removal)
- チームの自己組織化を促す
- サーバントリーダー
- 命令者・進捗管理者ではない
Development Team(Developers)
- 自己組織化 で「どう作るか」決定
- クロスファンクショナル
- 通常 3〜9人
- スプリントゴールにコミット
5つのイベント(Events)
| イベント | タイムボックス | 内容 |
|---|---|---|
| Sprint | 1〜4週間 | すべての他イベントの容器 |
| Sprint Planning | 8h max(4週時) | 何を/どう作るか計画 |
| Daily Scrum / Daily Standup | 15min | 計画と進捗、障害共有 |
| Sprint Review | 4h max | ステークホルダーとデモ・フィードバック |
| Sprint Retrospective | 3h max | チーム内で振り返り・改善 |
3つの成果物(Artifacts)
| 成果物 | コミットメント |
|---|---|
| Product Backlog | Product Goal |
| Sprint Backlog | Sprint Goal |
| Increment | Definition of Done(DoD) |
Definition of Ready(DoR) vs Definition of Done(DoD)
- DoR: バックログがスプリントに取り込める状態(INVEST等)
- DoD: インクリメントが完成と認められる状態(テスト・コードレビュー等)
スクラムの価値観(Values)
- Commitment(コミットメント)
- Focus(フォーカス)
- Openness(オープン)
- Respect(尊重)
- Courage(勇気)
3. スクラムの実行ポイント
スプリントプランニング
2部構成:
- What: スプリントゴール定義、バックログから取り込み
- How: タスク分解、見積もり
Daily Standup の3問
- 昨日何をしたか
- 今日何をするか
- 障害は何か
→ Scrum Master が障害を取り除く。
スプリントレビュー
- 動くインクリメントをデモ
- ステークホルダーからフィードバック
- バックログ調整
スプリントレトロスペクティブ
- 何が良かったか / 悪かったか
- 改善アクション(1〜3個 に絞る)
4. Backlog Refinement / Grooming
スプリント中に随時実施。バックログを:
- 詳細化
- 見積もり更新
- 優先順位調整
- 大きすぎるアイテムを分割
ProductOwnerが主導、チーム全体で参加。スプリント時間の 5〜10% が目安。
5. 見積もり手法
Story Point
複雑性・工数・不確実性を 相対値 で見積もる。Fibonacci数列(1, 2, 3, 5, 8, 13, 21)を使うことが多い。
- 絶対時間でなく相対値
- チーム内で意味を共有
Planning Poker
各メンバーが Story Point カードを伏せて出し、議論で合意。
T-shirt Sizing
S / M / L / XL で粗く見積もる。初期段階向け。
Velocity
1スプリントで完了するStory Pointの平均。
- 過去数スプリントで計算
- 残作業量 / Velocity でリリース時期予測
Affinity Estimation
バックログを並べてグルーピング、相対的に見積もる。
6. Burndown / Burnup チャート
Burndown Chart
- 縦軸: 残作業
- 横軸: 時間
- 右肩下がりが理想
Burnup Chart
- 縦軸: 完了作業 + スコープ
- スコープ変動を 見える化 できる(Burndownでは見えない)
Velocity Chart
過去スプリントのVelocity推移で、安定性・成長を見る。
7. ユーザーストーリー
形式
As a [ユーザー], I want [機能], so that [価値]
例: As a 顧客, I want カートに商品を追加できる, so that 後でまとめて購入できる
INVEST 原則(良いストーリーの条件)
- Independent: 独立性
- Negotiable: 交渉可能
- Valuable: 価値がある
- Estimable: 見積もり可能
- Small: 小さい
- Testable: テスト可能
Acceptance Criteria
ストーリー完了の基準。Given-When-Then 形式で書くことが多い。
8. アジャイルでのリスク管理
スクラムでは 継続的にリスク識別。
- スプリントレビューでリスク再評価
- 高リスク項目を 早期 にスプリントへ
- リトロでプロセスリスクを議論
- 透明性(Information Radiator: タスクボード等)
9. アジャイルでのコンフリクト・チーム
伝統PMと同じ手法(Tuckman, Conflict Resolution)が使える。 ただしスクラムマスターが サーバントとして行動:
- チームの障害除去
- ファシリテーション
- 強制せず引き出す
10. 試験での頻出ポイント
スクラム用語の正確な定義
- POはプロダクトの責任、SMはプロセスの責任
- DailyScrumは15分 に limited
- Sprintは1〜4週
- Velocity は 過去実績から計算、コミットメントではない
よくある誤答
- Scrum Master が進捗管理 → NG(命令者ではない)
- POが開発タスクを直接割り当て → NG(自己組織化)
- スプリント中にスコープ追加 → NG(次スプリントへ)
- Daily Scrumを部長が主導 → NG(チームのもの)
アジャイル文脈で問われがちな選択肢
- 命令する vs 支援する → 支援
- スコープ守る vs 価値創出 → 価値
- 計画通り vs 変化対応 → 変化
- 個人責任 vs チーム責任 → チーム
チェック問題
Q1
スクラムの3つの役割に 含まれない のは?
A) Product Owner B) Scrum Master C) Project Manager D) Developers
Q2
Daily Scrum のタイムボックスは?
A) 5分 B) 15分 C) 30分 D) 1時間
Q3
Velocity の正しい使い方は?
A) チームへの目標 B) 過去実績ベースの予測指標 C) 評価指標 D) コミット強制
Q4
スクラムマスターの役割で 正しくない のは?
A) 障害除去 B) スクラムのコーチ C) チームメンバーへタスク割り当て D) サーバントリーダー
Q5
ユーザーストーリー の INVEST の "I" は?
A) Important B) Independent C) Insightful D) Iterative
解答
- C — スクラムにPMはいない(PO/SM/Dev)。
- B — 15分。
- B — 予測指標、コミットメントではない。
- C — タスク割り当てはチーム自身。
- B — Independent。