このブログはCloud Partner Advent Calendar 2025の3日目の記事です
スクラムはアジャイルのフレームワークとして有名ですが、スクラム開発を成功させるには、
各イベントを適切に進めていく必要があります
そこで今回は、各スクラムイベントの具体的な進め方とアウトプットするものについてまとめていきます
さらに、それを踏まえて弊社で取り入れているスクラムをより効率的に進めるための取り組みも紹介します！
- 各スクラムイベントで具体的に何を行うのかを知りたい方
- 各スクラムイベント毎の成果物を理解したい方
- スクラム開発を進めているが、うまく成果が出ない方
スクラムとは？
スクラムとは、高い価値のプロダクトを生産的かつ素早くデリバリーするためのアジャイルフレームワークです
開発は一定の期間である「スプリント」を繰り返す形で進めていきます
スクラムイベントとは？
スクラムイベントとは、プロダクトの透明性を確保し、
検査と適応の機会を作るために定められた以下の5つのイベントを指します
- スプリント（他のイベントを内包するイベント）
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
- バックログリファインメント
バックログリファインメントは、厳密には公式的なスクラムイベントではありませんが、
スプリント期間内で必ず行う重要な作業となります
①スプリントのプロセスと成果物
スプリントは、利用可能なプロダクトインクリメントを作成するための1週間〜4週間の決められたサイクルです
スプリントの期間は一度決定したら、基本的に一定である必要があります
| プロセス |
| ①他イベントを、このサイクル内で行います ②開発者は、スプリントバックログの作業（タスク）を実施し、スプリントゴールの達成を目指します |
| 成果物 |
| ☑️ プロダクトインクリメント |
- スプリントで新たに完成したいくつかのプロダクトバックログアイテム（PBI）を、既存のプロダクトに追加して動作可能な状態にしたもの
- 完成の定義（Definition of Done）を満たしている必要がある
- プロダクトを完成させるためのチームでなすべき仕事
- プロダクトバックログは、複数のPBIの優先順位をつけて管理するダッシュボード
- プロダクトバックログは、プロダクトオーナーが優先順位を常につけて管理
②スプリントプランニングのプロセスと成果物
スプリントプランニングは、スプリント内での作業を計画するイベントです
スプリントの長さが1週間あたり最大2時間です
| イベント前の準備 |
| ☑️ このスプリントにおけるチームの目標ベロシティは？ ☑️ 欠勤、休日、休暇のために調整する必要があるか？ ☑️ チームはこのスプリントでどんな価値を提供したいのか？ |
| プロセス |
| ①POがスプリントゴールの候補を提案し、なぜこのスプリントを行う価値があるのかを表すスプリントゴールを定義します ②POが優先順位付けられたPBIを提示し、開発者はPOと相談しながら、スプリントゴールを達成するためのPBIを選択します ③開発者は、タスクに分解するなどの方法で作業をどのように行うかの計画を立てます ④チームとしてスプリントゴールとスプリントバックログにコミットします |
| 成果物 |
| ☑️ スプリントゴールの設定 ☑️ スプリントバックログの作成 ☑️ スプリントゴール達成のための計画 |
- PBIを具体的にどのように開発するか書き出したもの
- スプリントバックログは、SBIをリスト化して管理するダッシュボード
- スプリントバックログは開発者が管理する
③デイリースクラムのプロセスと成果物
デイリースクラムはスプリントゴールを達成するために、進捗を検査し、作業を再計画（適応）するためのイベントです
毎日15分間で行われます
| イベント前の準備 |
| ☑️ スプリントゴールとスプリントバックログの現在の状況は、チームにとって見える化され、更新され、明確になっているか？ ☑️ 前回のデイリースクラムでチームから提起された障害物について、アップデートを提供する必要があるか？ |
| プロセス |
| ①前日に行った作業、今日行う作業、特定されている障害物を共有します ②スプリントバックログで作業中のSBIを確認します ③スウォーミング（Swarming）する作業（優先順位の高い一つの仕事に群がって取り組む仕事の進め方）を決めます ④15分の制限時間に収まらない議論をフォローアップする（いつ、誰が集まるか）ことを決めます |
| 成果物 |
| ☑️ チームの進捗を阻害する障害物の一覧 |
④スプリントレビューのプロセスと成果物
スプリントレビューは、スプリント最終日に行い、ステークホルダーからフィードバックを得て、プロダクトの方向性が正しいかを検査し、適応するためのイベントです
スプリント期間中の1週間あたり最大1時間です
スクラムチーム全体と、ステークホルダーが共同で行う作業です
| イベント前の準備 |
| ☑️ スプリントレビューで何を見せる予定か？ ☑️ スプリントレビューには、どのようなステークホルダーを招待すればよいか？ ☑️ どんな情報を伝えればいいのか？ ☑️ 今回のスプリントで、ステークホルダーに聞いておきたいことはあるか？ |
| プロセス |
| ①スクラムチームは、ステークホルダーを招き、スプリントゴールを説明します ②チームメンバーは、完成の定義に合致したプロダクトインクリメントのデモンストレーションを行い、スプリント&プロダクトゴールに対する進捗を示します ③完成しなかった作業がある場合、その影響を説明します ④ステークホルダーは建設的なフィードバックと方向性を示します ⑤プロダクトオーナーは、ステークホルダーのフィードバックをプロダクトバックログに反映させます |
| 成果物 |
| ☑️ ステークホルダーからのフィードバック、方向性、アイデアを反映させたプロダクトバックログ |
⑤スプリントレトロスペクティブのプロセスと成果物
スプリントレトロスペクティブは、スプリント最終日のスプリントレビュー後に行い、チームのプロセスを検査し、次のスプリントの改善施策を決定するイベントです
スプリントの長さで1週間あたり最大45分です
| イベント前の準備 |
| ☑️ スプリントに関するどのようなデータが、チームのふりかえりに役立つか？ ☑️ チームが事前に準備できることはあるか？ ☑️ 実行可能な解決策と仮説に焦点を当てたイベントを続けるにはどうすればいいのか？ |
| プロセス |
| ①チームメンバー全員から今回のスプリントに対するフィードバック（何がうまくいったか、何を変えたいか）を集めます ②そのフィードバックを振り返り、共通のパターンやトピックを探します ③チームとして、最も価値のあるカイゼンのアイディアに優先順位をつけます ④少なくとも1つのカイゼンのアイディアを選択し、次のスプリントにコミットするための具体的で測定可能なアクションや試みを決定します ⑤カイゼンのPBI（受け入れ条件付き）を作成し、次のスプリントバックログに組み入れます |
| 成果物 |
| ☑️ 次のスプリントのための継続的なカイゼンのPBI ☑️ 意見として上がったカイゼンアイディアの記録 |
⑥バックログリファインメントのプロセスと成果物
バックログリファインメントは、次以降のスプリントで着手する可能性のあるPBIを準備完了にするためにスクラムチームが協力して行う活動です
基本的にスプリント期間中の10%までの時間を割り当てると良いです
| イベント前の準備 |
| ☑️ 次の2〜3スプリントで着手する可能性のあるPBIを事前に準備しているか？ ☑️ チームは事前にどのPBIに目を通すべきか？ ☑️ 各PBIの前提条件や依存関係をどのように把握するか？ |
| プロセス |
| ①プロダクトオーナーは、望まれる成果や、なぜ重要なのかを含めたPBIをチームに提示します ②チームは質問をすることで作業を明確化し、必要であれば分割し、作業を開始するために必要な不足情報を特定します ③PBIを完成させるために必要な労力を見積もります |
| 成果物 |
| ☑️ 明確に記載されたReady（準備完了）なPBI |
- 以下の内容を定義したPBIがReady（準備完了）なPBIとなります
- PBIの目的・背景が定義されている
- 適切な受け入れ条件が定義されている
- PBIを完成させるための労力が見積もられている
- 完成の条件が定義されている
- 準備完了のチェックが満たされている
- スプリントレビューで、ステークホルダーにレビューしてもらう内容が明確になっている
スクラム開発をより効率的に進めるための取り組み
ここからはスクラムを効率的に進める為に、スクラムガイドには定義されていませんが、
クラウドパートナーで取り組んでいることを一部、ノウハウとして紹介します
①スプリント0の実施
スプリント0は、スクラムの公式なフレームワークとして定義されているものではありませんが、
スクラム開発において、最初のスプリントを開始する前の、プロジェクトの準備活動としてよく実践されます
| 準備 |
| ☑️ プロジェクトの存在意義と予算が組織内で承認されているか？ ☑️ 誰のためにプロダクトを作るのか（ペルソナ）、解決すべき課題は何か明確にしているか？ ☑️ プロダクトがカバーする大まかな範囲と、カバーしない範囲の見通しが立っているか？ ☑️ プロダクトに影響を与える主要な関係者（ユーザー、経営層など）が特定されているか？ |
| プロセス |
| ①プロダクトの目指すべき方向性であるプロダクトビジョンを明確にし、 プロダクトゴールを策定します ②スクラムチームの編成を完了し、ワーキングアグリーメントを作成します ③開発環境やツールをセットアップします ④ユーザーストーリーマッピングを実施し、エピックや主要なユーザーストーリーを作成します ⑤準備完了の定義（Definition of Ready）と完成の定義（Definition of Done）をスクラムチーム全体で合意して定義します ⑤プロダクトのMVPを決定し、リリース計画を立てます |
| 成果物 |
| ☑️ プロダクトビジョン、プロダクトゴール ☑️ 初期プロダクトバックログ ☑️ 完成の定義（DoD） ☑️ 準備完了の定義（DoR） ☑️ ワーキングアグリーメント |
- スクラムチームとして一緒に働くための約束事や、大切にする価値観などを記述したものです
- 例えばレトロスペクティブでは意見を必ず1つは言う。誹謗中傷しない。など
- PBIが完成したかを明確に判断する基準
- この基準は全てのPBIに共通するものとして作成
- 例えば、単体テストが実装されているか。脆弱性診断で高レベルなものがないか。など複数のチェックを定義
- PBIをSBIに切り出して、スプリントバックログに入れることができるかを判断する基準
- 例えば、他のPBIによる依存関係が無く直ぐに始められるか？本PBIによって提供できる価値は明確になっているか？など複数のチェックを定義
- DoDと同じく、全てのPBIに共通する基準として作成する
- 開発が進む中で適宜、見直しを行う
②バックログリファインメントにおける重要な作業
PBIをReadyにすることはバックログリファインメントで行いますが、
そのPBIがReady（準備完了）になっているかを判断する基準に、
- 「技術的に実現する方法の見通しが立っているか」
- 「この実装にはどれくらいの時間がかかるか見通しが立っている」
というものがあります
これは技術的な見通しが立っていない状態で、PBIを開始させることは危険だからです
そうした技術的な検証や確認を行う作業は、バックログリファインメントにおける重要な作業です
これによって、スプリント（開発作業）に入る前に、具体的な開発作業の見通しを立てた状態にしておくことが可能になります
具体的に話し合う内容は、以下などがあります
- 開始前時点でまだ見えていない作業は無いか洗い出す
- 開発作業にかかる時間を大まかに見積もり、PBIに定義する労力を正確に見積もれるようにする
- 着手予定の開発に技術的な依存関係がないかチェックする
- フロントとバックエンドの境界部分など、作業範囲の境界になりうる箇所を確認し、作業範囲を明確にする
これによって、スプリント終了時に手戻りが発生することや、開発者同士の作業範囲の齟齬を軽減することに繋がります
まとめ
今回は、スクラム開発における主要なイベントについて、それぞれ具体的なプロセス、そしてアウトプットとなる成果物を解説しました
またスクラムフレームワークに則る以外にも、チーム体制や状況に応じて、適宜プロセスを工夫する柔軟性も重要となります
是非このまとめを参考に、各スクラムイベントを適切に実行し、より高いレベルのプロダクト開発を目指して頂ければと思います
お知らせ
アジャイル・スクラム開発にお悩みではありませんか？
- 弊社では、スクラム×GitLabを活用したアジャイル開発導入支援サービスを提供しています。
GitLabの基本的な使い方から、アジャイル・スクラムの実践的な進め方までを体験的に習得することができます。詳しくはサイトをご確認ください。
https://www.cloud-partner.jp/insource/
