フレームワーク活用ガイドひとことで言うと#
1〜2週間の「スプリント」 という短い期間でゴールを設定し、計画→実行→レビュー→振り返りのサイクルを回す開発フレームワーク。「半年後に完成」ではなく「2週間後に動くものを見せる」を繰り返すことで、変化に強いチームを作る。
押さえておきたい用語#
- スプリント（Sprint）
- 1〜2週間の固定された開発期間のこと。スクラムの最小単位で、計画・実行・レビュー・振り返りの4イベントで構成される。
- プロダクトバックログ（Product Backlog）
- プロダクトに追加したい機能や改善をすべてリスト化した優先順位付きのやることリストのこと。プロダクトオーナーが管理する。
- ベロシティ（Velocity）
- 1スプリントで消化したストーリーポイントの合計値のこと。チームの開発速度の目安として将来の計画に使う。
- レトロスペクティブ（Retrospective）
- スプリント終了後に行うプロセスの振り返りミーティングのこと。「うまくいったこと」「改善すべきこと」を議論し、次に活かす。
- スクラムマスター（Scrum Master）
- チームがスクラムをうまく回せるようサポートするファシリテーター的な役割のこと。障害を取り除き、プロセスを改善する。
スクラムの全体像#
こんな悩みに効く#
- 開発プロジェクトがいつも予定通りに終わらない
- 途中で要件が変わって、手戻りが発生しまくる
- チームメンバーが何をやっているか見えない
基本の使い方#
スクラムには3つの明確な役割がある。
- プロダクトオーナー（PO）: 「何を作るか」の責任者。プロダクトバックログ（やることリスト）の優先順位を決める。ビジネス側の代表
- スクラムマスター（SM）: チームがスクラムをうまく回せるようにサポートする人。障害を取り除き、プロセスを改善する。マネージャーではなくファシリテーター
- 開発チーム: 実際に「作る」人たち。3〜9人が理想。自己組織化されたチーム
注意: プロダクトオーナーとスクラムマスターの兼任は避ける。「何を作るか」と「どう作るか」の責任は分ける。
スクラムの心臓部はスプリント（通常1〜2週間）。以下の4つのイベントで構成される。
- スプリントプランニング: スプリントの最初に、今回のゴールと取り組むバックログアイテムを決める
- デイリースクラム: 毎日15分。「昨日やったこと」「今日やること」「困っていること」を共有。問題解決の場ではなく同期の場
- スプリントレビュー: スプリント最終日に、作ったものをステークホルダーにデモする
- スプリントレトロスペクティブ: スプリント終了後に、プロセスの振り返り。「うまくいったこと」「改善すること」を話し合う
鉄則: スプリント中にスコープを変更しない。新しい要望が来たら次のスプリントで対応する。
プロダクトバックログは「やりたいこと全部」のリスト。プロダクトオーナーが優先順位を管理する。
バックログアイテムはユーザーストーリー形式で書くと伝わりやすい: 「〇〇（ユーザー）として、△△したい。なぜなら□□だから」
例: 「営業担当として、顧客の過去の問い合わせ履歴を一覧で見たい。なぜなら電話対応中に素早く状況を把握できるから」
各アイテムには見積もりをつける。ストーリーポイント（相対見積もり）を使うと、チームのベロシティ（速度）が把握でき、将来の計画精度が上がる。
具体例#
顧客管理SaaSを開発する5人チーム。以前はウォーターフォールで3ヶ月単位の開発をしていたが、要件変更のたびに大混乱していた。
スクラム導入後の1スプリント（2週間）の流れ:
月曜（プランニング）: プロダクトオーナーが「今スプリントは検索機能の強化」とゴール設定。チームで5つのユーザーストーリーを選択。
毎朝10:00（デイリースクラム）: 15分で状況共有。3日目に「検索のレスポンスが遅い」という技術的な壁が発覚。スクラムマスターがインフラチームとの調整を即座に開始。
金曜（レビュー）: 営業チームの前で新しい検索機能をデモ。「絞り込み条件を保存したい」というフィードバック → バックログに追加。
金曜午後（レトロスペクティブ）: 「デイリーが形骸化していた」という反省 → 「困っていること」を毎回必ず1つ以上出すルールに変更。
結果: 導入3ヶ月後、チームのベロシティが安定し、「今スプリントで何が完成するか」が高い精度で予測できるようになった。スプリント達成率が45%→82%に改善。
ヘルスケアSaaSスタートアップ（従業員20名、開発8名）。これまで「やることリスト」をSlackで管理し、各自がバラバラに動いていた。
Before:
| 指標 | 数値 |
|---|---|
| リリースサイクル | 不定期（2〜3ヶ月に1回） |
| スプリント達成率 | 測定なし |
| 要件変更の影響 | 毎回プロジェクト延長 |
| チームの可視性 | 「誰が何をしているか不明」 |
導入プロセス:
- 2週間スプリントに決定。POは創業者、SMはテックリードが兼任（暫定）
- 最初の3スプリントは「スクラムに慣れる」こと自体がゴール
- 4スプリント目からベロシティ計測を開始（平均42ポイント/スプリント）
After（6ヶ月後）:
| 指標 | Before | After |
|---|---|---|
| リリースサイクル | 2〜3ヶ月 | 2週間ごと |
| スプリント達成率 | - | 78% |
| バグ発見タイミング | リリース後 | スプリントレビュー時 |
| チームの可視性 | 不明 | デイリーで全員把握 |
結果: 2週間ごとにリリースする文化が根付き、顧客フィードバックの反映が平均6週間→2週間に短縮された。
従業員300名の食品メーカー。IT部門5名が在庫管理システムの内製化プロジェクトでスクラムを試行。製造業特有の課題に直面。
課題と対応:
| 製造業特有の課題 | スクラムでの対応 |
|---|---|
| 工場の操業が止められない | スプリント期間を3週間に延長し、工場との調整時間を確保 |
| 現場担当者のIT理解度が低い | スプリントレビューに工場長を毎回招待。動く画面でフィードバック |
| 「完璧に仕上げてから導入」文化 | MVP（最小限の在庫照会機能）から段階リリース |
6スプリント（18週間）後の成果:
- 在庫確認にかかる時間: 1件あたり15分 → 30秒
- 在庫差異率: 5.2% → 1.8%
- 現場からの改善要望: 累計47件のうち32件をスプリント内で対応
結果: 「完璧なシステムを1年かけて作る」よりも「2割の機能を3ヶ月で使い始める」ほうが、現場の納得感も業務改善効果も大きかった。
やりがちな失敗パターン#
- スクラムイベントを「会議」として扱う — デイリースクラムが30分の報告会になったり、レトロスペクティブが愚痴大会になったりする。各イベントの目的を理解してタイムボックスを守る
- プロダクトオーナー不在 — POが忙しくて判断してくれない。その結果、開発チームが「たぶんこれでいいだろう」で進めてしまう。POのコミットメントはスクラム成功の前提条件
- 振り返りを飛ばす — 忙しいとレトロスペクティブが「今回はスキップ」になりがち。しかしこれがないとチームは改善しない。レトロスペクティブこそスクラム最大の価値
- 形だけスクラムを導入する — イベントは全部やっているが、チームに自己組織化の権限がない。マネージャーがタスクを割り振るだけの「なんちゃってスクラム」は改善効果が出ない。チームが自分で判断できる環境を作ることが本質
まとめ#
スクラムは「短いサイクルで確実に価値を届ける」ための開発フレームワーク。形式を導入するだけでは意味がなく、「透明性・検査・適応」の3本柱を理解してチーム全体で実践することが大事。まずは2週間のスプリントを1回やってみることから始めよう。その2週間で見える世界が変わるはず。