<CodeLearn/>
アジャイル レッスン2

スクラム入門

スクラムの3つのロール、スプリント、セレモニーを理解しよう

スクラムの3つのロール

スクラムはアジャイル開発で最も広く使われるフレームワークです。 チームは以下の3つのロールで構成されます。

プロダクトオーナー(PO)

  • プロダクトの価値を最大化する責任者
  • プロダクトバックログの管理・優先順位付け
  • ステークホルダーとの橋渡し
  • 「何を作るか」を決める

スクラムマスター(SM)

  • スクラムプロセスの促進・障害除去
  • チームが自律的に動けるよう支援
  • スクラムの正しい実践を指導
  • 「どう進めるか」を支える

開発チーム(Dev Team)

  • プロダクトを実際に開発するメンバー
  • 自己組織化されたクロスファンクショナルチーム
  • 理想は3〜9人程度
  • 「どう作るか」を決める

スプリントとは

スプリントは、スクラムの開発サイクルの単位です。 通常1〜4週間(多くは2週間)の固定期間で、計画から振り返りまでを一通り行います。

【スプリントの流れ(2週間の例)】

Day 1(月曜)
  ┌──────────────────────────────┐
  │  スプリントプランニング(2〜4時間) │
  │  - スプリントゴールの設定         │
  │  - バックログから項目を選択        │
  │  - タスクの分解・見積もり         │
  └──────────────────────────────┘

Day 1〜9(毎日)
  ┌──────────────────────────────┐
  │  デイリースクラム(15分)          │
  │  - 昨日やったこと              │
  │  - 今日やること               │
  │  - 困っていること(障害)         │
  └──────────────────────────────┘

Day 10(金曜)
  ┌──────────────────────────────┐
  │  スプリントレビュー(1〜2時間)     │
  │  - 成果物のデモ               │
  │  - ステークホルダーからフィードバック │
  ├──────────────────────────────┤
  │  スプリントレトロスペクティブ(1時間)│
  │  - 良かったこと / 改善したいこと   │
  │  - 次のスプリントへのアクション     │
  └──────────────────────────────┘

スクラムの4つのセレモニー

1. スプリントプランニング

スプリントの最初に行い、何を達成するか計画する。

  • スプリントゴールを決定
  • プロダクトバックログから項目を選択
  • タスクに分解して見積もる

2. デイリースクラム(スタンドアップ)

毎日15分の短い同期ミーティング。

  • 昨日やったこと
  • 今日やること
  • 障害になっていること

3. スプリントレビュー

スプリントの成果物をデモし、フィードバックを受ける。

  • 動くソフトウェアを見せる
  • ステークホルダーと意見交換
  • バックログの調整

4. スプリントレトロスペクティブ

チームのプロセスを振り返り、改善する。

  • Keep: 良かったこと
  • Problem: 問題だったこと
  • Try: 次に試すこと

バックログの管理

スクラムでは2種類のバックログを使い分けます。プロダクトバックログは全体の要望リスト、スプリントバックログは今回のスプリントで取り組む項目です。

【プロダクトバックログ】           【スプリントバックログ】
POが管理・優先順位付け             開発チームが管理

優先度高 ┌─────────────────┐    ┌─────────────────┐
  1.  │ ログイン機能      │ ──→│ ログイン機能      │
  2.  │ ユーザー登録      │ ──→│ ユーザー登録      │
  3.  │ プロフィール編集   │ ──→│ プロフィール編集   │
  4.  │ パスワードリセット  │    └─────────────────┘
  5.  │ 検索機能         │    ↑ 今回のスプリントで
  6.  │ 通知機能         │      取り組む項目
  7.  │ ダッシュボード     │
優先度低 └─────────────────┘

【ユーザーストーリーの形式】
「<ユーザーの種類>として、
  <達成したいこと>をしたい。
  なぜなら<理由>だからだ。」

例: 「一般ユーザーとして、
     メールアドレスでログインしたい。
     なぜならSNSアカウントを持っていないからだ。」

Definition of Done(完了の定義)とベロシティ

Definition of Done(DoD)は、バックログアイテムが 「完了」と見なされる条件をチームで合意したものです。 品質基準を統一し、「できたつもり」を防ぎます。

【Definition of Done の例】
✅ コードが実装されている
✅ ユニットテストが書かれている(カバレッジ80%以上)
✅ コードレビューが完了している
✅ CIが全てパスしている
✅ ステージング環境で動作確認済み
✅ ドキュメントが更新されている

【ベロシティ(Velocity)】
チームが1スプリントで完了させるストーリーポイントの合計

Sprint 1: 18ポイント
Sprint 2: 22ポイント
Sprint 3: 20ポイント
→ 平均ベロシティ = 20ポイント/Sprint

ベロシティを使って:
- 次のスプリントで取り込む量の目安にする
- プロジェクト全体の完了見込みを予測する
- チームのキャパシティを把握する

まとめ

  • スクラムは3つのロール(PO・SM・開発チーム)で構成される
  • スプリントは1〜4週間の固定期間で、計画からレトロスペクティブまでを繰り返す
  • 4つのセレモニー(プランニング・デイリー・レビュー・レトロ)でチームを同期する
  • プロダクトバックログとスプリントバックログで作業を管理する
  • Definition of Doneで品質基準を統一し、ベロシティでキャパシティを把握する