Scrumフレームワーク：ロール、イベント、アーティファクトの解説（実例付き）

多くの人はScrumを誤った方法で学びます。スケジュールすべきミーティングと割り当てるべきロールのチェックリストとして扱い、数回Sprintを実施してから、なぜチームのリリース速度が上がらずProduct Backlogが一向に減らないのかと疑問を持ち始めます。Scrumフレームワークは一度実装すれば忘れられるメソドロジーではありません。毎Sprintごとに適応させるフィードバックループです。そしてその違いは非常に重要です。

Scrumは意図的に軽量です。問題を素早く表面化し、それが積み重なる前に修正できるだけの構造を提供します。Scrumから真の価値を引き出しているチームは、スタンドアップを「Daily Scrum」と改名するだけのチームではなく、検査と適応の原則を真剣に受け止めているチームです。

Scrumフレームワークとは何か

Scrumは、Sprintと呼ばれる短いタイムボックス型の反復サイクルを通じて複雑なプロダクトを届けるための軽量なAgileフレームワークです。特定のエンジニアリングプラクティスやツールを規定しません。代わりに、透明性を生み出し、頻繁な検査を可能にし、迅速な適応を実現するための最小限のロール・イベント・アーティファクトを定義します。

Jeff SutherlandとKen Schwaberは1990年代初頭、リーン製造と経験的プロセス制御の概念を基にScrumを開発しました。1995年のOOPSLAカンファレンスで初めて公開発表し、最初の正式なScrum Guideは2010年に発行されました。最新版である2020年版Scrum Guideでは、フレームワークをさらに絞り込み、規定的な要素を除いて、経験主義の3本柱である透明性・検査・適応に焦点を当てています。

リーン思考がフレームワーク全体を貫いています。Scrumチームは短いサイクルで作業し、動くソフトウェアへの実際のフィードバックを得ることで無駄を排除し、プロダクトゴールに近づかない作業を止めます。

Key Facts

• SutherlandとSchwaberは1995年のOOPSLAカンファレンスでScrumを初めて公開発表し、定義されたロールを持つタイムボックス型の反復というコンセプトを紹介しました。
• 2020年版Scrum Guide（scrumguides.orgで公開）が正式な参照元です。「Development Team」という用語を廃止し、以前のバージョンと比較してフレームワークを大幅に簡素化しました。
• 第17回State of Agile Report（Digital.ai、2023年）によると、ScrumはAgileチームの87%がScrumまたはScrumハイブリッドを使用しており、最も広く採用されているAgileアプローチであり続けています。

Scrumサイクルの全体像

Scrumサイクルは経験的なループです。チームが取り組む可能性のある全作業を順序付けたリストであるProduct Backlogから始まります。各サイクルはまずスプリントプランニングで開始され、チームはProduct Backlogからアイテムを選択し、次のSprintで完了させる具体的な作業を含むSprint Backlogを作成します。

Sprint自体は1〜4週間の期間で進みます。その間、チームは毎日Daily Scrumを開催します。開発者がSprintゴールに向けた進捗を確認し、次の24時間の計画を再調整するための15分間の調整ミーティングです。

Sprintの終わりに、チームはDefinition of Doneを満たし、原則としてリリース可能な動くIncrementを提供します。スプリントレビューは、チームとステークホルダーがIncrementを確認し、次に何をすべきかを話し合うインフォーマルなセッションです。続いてスプリントレトロスペクティブが行われ、チームは自分たちの働き方を振り返ります。どのように作業したか、何を改善すべきか、次のSprintに何を持ち込むかを考えます。

そして繰り返されます。Product Backlog → スプリントプランニング → Sprint → Increment → スプリントレビュー → スプリントレトロスペクティブ → Product Backlog。このループがフレームワークです。短いからこそ、ミスのコストが低く、学習が速いのです。

Scrumの3つのロール（Scrumチーム）

2020年版Scrum Guideではサブチームの概念が廃止されました。Scrumチームは1つで、階層はなく、その中に3つの責任があります。

Product Owner

Product Ownerはプロダクトの価値を最大化することに責任を持ちます。Product Backlogを所有し、作成・順序付けを行い、開発者が内容を理解できるようにします。Scrum Guideからの重要な制約として、Product Ownerは1人の人間であり、委員会ではありません。何を作るかについての決定は、1つの声から来なければなりません。

実際には、Product Ownerはビジネス戦略と開発作業の交点で働きます。常に判断を下しています。次に作る価値がある機能はどれか、どのユーザーニーズを優先するか、どのBacklogアイテムをカットするか。こうした決断を素早く下せない弱いProduct Ownerは、Scrumチーム全体が毎Sprint感じるボトルネックを生み出します。

Product Ownerはプロキシでも仲介者でもありません。ステークホルダーが何かを求めるときは、Product Ownerを通じて作業します。Product Ownerを迂回する形では機能しません。組織がその境界線を尊重しなければ、Scrumはうまく機能しません。

Scrum Master

Scrum MasterはScrumチームと組織全体に奉仕します。チームの効果性に責任を持ちます。開発者がうまく協力できるよう支援し、Product OwnerのBacklog技法を補助し、障害を取り除き、Scrum採用について組織をコーチングします。

Scrum Masterはプロジェクトマネージャーではありません。タスクを割り当てたり、稼働時間を追跡したり、チームのアウトプットについてエグゼクティブに報告したりしません。その役割はコーチとサーバントリーダーに近いものです。チームを外部からの干渉から守り、イベントをファシリテートし、フレームワークを損なう形でチームを迂回しようとする人（シニアリーダーシップを含む）に対して反論します。

Scrum Masterのロールをパートタイムで、通常のSprint作業と並行して開発者が担うという誤りは一般的です。経験豊富なチームなら機能することもありますが、Scrumを初めて採用するチームは、システムを実際に観察できる専任のScrum Masterの恩恵を受けます。

開発者

開発者は各SprintでIncrementを作成する人たちです。2020年版Scrum Guideでは「Development Team」から「開発者」という名称に変更され、責任はサブチームではなく作業を行う全員に帰属することが示されています。

開発者はクロスファンクショナルです。Scrumチーム全体として、動くプロダクトIncrementを届けるために必要なすべてのスキルを持っています。同じチームにデザイナー・エンジニア・テスター・ライターが含まれることもありますが、Scrum Guideは特定のスキルセットを義務付けていません。

開発者はSprint Backlogを所有し、自分たちの作業を自己管理します。Scrumチームの外部の誰もが、彼らのやり方を指示したり、個人にタスクを割り当てたりすることはありません。Sprint BacklogのアイテムをIncrementに変える方法を決めるのは開発者自身です。

Scrumの5つのイベント

すべてのScrumイベントはタイムボックス型であり、目的があります。タイムボックスは効率化のためだけではありません。予測可能なリズムを生み出し、意思決定を促します。公式な最大時間とともに、5つのイベントすべてを紹介します。

Sprint

Sprintは他のすべてのScrumイベントのコンテナです。1か月以下の固定長の反復です。Sprint中は、Sprintゴールを危険にさらすような変更は行われず、チームが学ぶにつれてスコープは明確化される可能性があり、Sprintゴールが陳腐化しない限りSprintはキャンセルされません。

Sprintの一定の長さがリズムを作ります。チームはいつプランニングがあり、いつレビューがあり、次のリリースの機会がいつあるかを把握しています。ほとんどのチームは2週間Sprintを採用しますが、適切な長さはリスク許容度・プロダクトの変化頻度・チームに必要なフィードバック量によって異なります。

スプリントプランニング

スプリントプランニングはSprintを開始し、2つの問いに答えます。このSprintで何を提供できるか、そしてどのように作業を進めるか。Product OwnerがProduct Backlogの最上位を提示し、チームは完了できると信じる作業を選択します。

アウトプットはSprintに一貫性を与える単一の目標であるスプリントゴールと、選択された具体的なアイテムとそれを届けるための計画であるSprint Backlogです。

タイムボックス：1か月Sprintで最大8時間。短いSprintでは比例して短くなります。

Daily Scrum

Daily Scrumは、開発者がSprintゴールに向けた進捗を確認し、次の24時間の計画を適応させるための15分間のイベントです。Scrum Masterへの進捗報告ではありません。開発者間の調整です。

2020年版Scrum Guideでは、規定されていた3つの質問（昨日何をしたか、今日何をするか、ブロッカーはあるか）が廃止され、目的が達成される限り、チームがどのように実施するかについて柔軟性が与えられました。目標は、開発者がお互いの作業内容とブロッカーの所在を把握した状態で終えることです。

スプリントレビュー

スプリントレビューはIncrementの検査とProduct Backlogの適応です。Scrumチームとステークホルダーが何が達成されたかを確認し、市場やビジネスの変化について議論し、次に何をすべきかについて合意します。

デモではありません。ただしデモが行われることはよくあります。この違いは重要です。デモはプレゼンテーションですが、スプリントレビューは作業セッションです。ステークホルダーは観客ではなく、参加者です。

タイムボックス：1か月Sprintで最大4時間。

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

スプリントレトロスペクティブはScrumチームが自分たち自身を検査する場です。何がうまくいったか、何がうまくいかなかったか、次のSprintで変えることは1〜2つ何か。アウトプットはチームが実行すると約束する具体的な改善計画です。

このイベントはScrumにおける継続的改善のエンジンです。スプリントレトロスペクティブをスキップしたり、形式的に実施したりするチームは改善が止まります。価値は時間とともに複利で積み上がるため、最良のスプリントレトロスペクティブの実践を持つチームが、1年以上にわたって最高のパフォーマンスを発揮する傾向があります。

タイムボックス：1か月Sprintで最大3時間。

Scrumの3つのアーティファクトとそのコミットメント

2020年版Scrum Guideでは、各アーティファクトにコミットメントが対応付けられました。アーティファクトに方向性を与え、進捗を検査できる測定可能な目標です。

Product Backlog（コミットメント：プロダクトゴール）

Product Backlogは、プロダクトを改善するために行われる可能性のあるすべての作業を順序付けた、常に変化するリストです。完成することはありません。新しいアイテムが追加され、古いものが削除され、チームが学ぶにつれて優先順位が変わります。

Product Backlogのコミットメントはプロダクトゴールです。Scrumチームが目指す長期的な目標です。各Sprintはプロダクトをプロダクトゴールに近づけるべきであり、Product Backlogはそこへの道筋を描くために存在します。

Product OwnerがProduct Backlogを所有し、その順序付けと明確さに責任を持ちます。

Sprint Backlog（コミットメント：スプリントゴール）

Sprint BacklogはSprintのために選択されたProduct Backlogのアイテムの集合に、それを届けるための計画とスプリントゴールを加えたものです。開発者が今のSprintで完了しようとしている作業のリアルタイムの全体像です。

コミットメントはスプリントゴールです。Sprintに目的を与える単一の目標です。Sprint中に新しい作業が発生した場合、スプリントゴールを脅かさない限りにおいてのみ、開発者はSprint Backlogに追加します。

Increment（コミットメント：Definition of Done）

Incrementはプロダクトゴールに向けた具体的な一歩です。各Sprintで少なくとも1つのIncrementを生産しなければなりません。使用可能な状態であり、チームの基準を満たしている必要があります。

コミットメントは**Definition of Done（DoD）**です。「完了」の意味についての共通理解です。アイテムがDefinition of Doneを満たしていなければ、Incrementの一部にはなりません。DoDは透明性と一貫性を生み出します。アイテムごとのチェックリストではなく、すべてのIncrementに適用される品質基準です。

一目でわかる：ロール・イベント・アーティファクト

11の要素がScrumの全処方内容です。それがフレームワークの全体です。この11要素以外のものは、補完的なプラクティス（テスト駆動開発やユーザーストーリーマッピングなど）か、別途管理する組織的な追加要素です。

典型的な2週間Sprintのリズム

標準的な2週間Sprintが実際にどのような形で展開されるかを、日ごとに見ていきます。

1日目： スプリントプランニング。チームが集まり、Product OwnerとともにProduct Backlogの最上位を確認し、スプリントゴールを設定してSprint Backlogを構築します。2週間Sprintでは、プランニングは通常2〜4時間です。

1日目から10日目： 開発。1日目を含む毎日、チームは15分のDaily Scrumを実施します。開発者は調整を行い、ブロッカーを表面化し、必要に応じて再計画します。Scrum Masterは障害を取り除きます。Product Ownerは確認対応のために利用可能な状態を保ちます。

10日目午前： スプリントレビュー。チームはステークホルダーにIncrementを提示し、フィードバックを得てProduct Backlogを更新します。2週間Sprintでは通常1〜2時間です。

10日目午後： スプリントレトロスペクティブ。Scrumチームが内省します。何がうまくいったか、何がうまくいかなかったか、次のSprintで試みる変更点は何か。最大1.5時間。

11日目： 新しいSprintが始まります。同じ構造、同じリズム、スプリントレトロスペクティブからの1〜2つの改善点を持ち越して。

一貫性こそがポイントです。すべてのSprintが同じ形を持つとき、調整のオーバーヘッドが下がり、チームは実際の作業に集中できます。Sprintのリズムをより大きなプロジェクトタイムラインに接続する方法については、プロジェクト計画を参照してください。

ScrumとKanbanとWaterfall

ScrumはしばしばKanbanと従来のWaterfallメソドロジーと比較されます。その違いはSprintがあるかボードがあるかよりも深いところにあります。

端的に言うと、複雑なものを構築していて要件が学びとともに変化する場合はScrumを使ってください。作業が継続的に発生し、反復よりもフローの最適化が必要な場合はKanbanを使ってください。スコープが固定されていて変化のリスクが低く、事前に完全な計画が必要な場合はWaterfallを使ってください（建設・コンプライアンス重視の業界・固定入札契約などに一般的です）。

多くのチームはScrum/Kanbanハイブリッドを採用しています。計画的な開発作業にはSprintのリズム、バグや予定外のリクエストにはKanbanボードを使うパターンです。どのシステムがどの作業を管轄するかをチームが明確にしている限り、これは問題ありません。

Scrumを補完する構造化されたスケジューリングツールについては、作業分解構成図、クリティカルパス法、Ganttチャート、PERTチャートを参照してください。

Scrumを壊す一般的なミス

Scrumの失敗のほとんどはフレームワークの失敗ではありません。実装の失敗です。最も一般的なものを挙げます。

• スプリントレトロスペクティブをスキップする。 これはScrumが複利で成果を積み上げるイベントです。スキップするチームは同じ機能不全のレベルに留まり続けます。時間が足りないなら短縮してください。しかしカットしないでください。
• Scrum Masterをプロジェクトマネージャーとして扱う。 タスクの割り当て、Velocityのリーダーシップへの報告、タイムラインの管理はPMの機能です。これらを行っているScrum MasterはScrum Masterの仕事をしていません。両方のロールが損なわれます。
• 実質的なProduct Ownerがいない。 優先順位の決定ができず、3つの委員会の承認が必要で、Sprint中にスプリントゴールを変えるProduct Ownerは、チームの計画とデリバリーの能力を壊します。
• ステークホルダーがProduct Ownerを迂回する。 開発者がエグゼクティブやクライアントから直接機能要望を受けているのは、Product Ownerの権限が尊重されていないサインです。フレームワークではなく組織文化を修正する必要があります。
• スプリントゴールなしでSprintを実施する。 タスクの羅列にすぎないSprintには統一目標がありません。新しい情報が入ったときに適切なトレードオフの判断ができません。守るべき目標がないからです。
• Scrumが完全なソリューションだと思い込む。 Scrumはエンジニアリングプラクティスを含みません。チームはさらに、動くIncrementを実際にリリースするためにテスト自動化・継続的インテグレーション・明確な品質基準（Definition of Done）も必要です。これらがなければ、スプリントレビューは中途半端な機能のパレードになってしまいます。

よくある質問

ScrumとAgileは同じですか？

いいえ。AgileはAgileマニフェスト（2001年）に記された一連の価値観と原則です。Scrumはそれらの原則を実践するための1つのフレームワークです。Scrumなしでもagileにはなれますし、Agileの価値観に反する形でScrumを実施することもできます。Agileを哲学として、Scrumをそれを体系的に実践する1つの方法として考えてください。他のAgileフレームワークにはKanban、Extreme Programming（XP）、SAFe（Scaled Agile Framework）などがあります。

Scrum MasterなしでScrumは機能しますか？

技術的には、ScrumにはScrum Masterが必要です。実際には、成熟したチームはコーチングとファシリテーションの責任をチームメンバー間で分担することで、専任のScrum Masterなしに運営することもあります。しかしScrumを初めて採用するチームは、フレームワークを積極的に守り、チームをコーチングし、組織の障害を取り除く専任のScrum Masterから大きな恩恵を受けます。そのロールがなければ、チームは古い習慣に戻る傾向があります。スタンドアップがステータス報告になり、スプリントレトロスペクティブがスキップされ、Product Ownerがそのバックログ権限を失います。

Sprintの長さはどのくらいが適切ですか？

2020年版Scrum Guideでは1か月以下とされており、ほとんどのチームは1〜4週間を選びます。実際には2週間Sprintが最も一般的です。適切な長さは要件の安定性・外部からのフィードバックの頻度・チームが吸収できるプランニングのオーバーヘッドによって異なります。Sprintが短いほどフィードバックは速くなりますが、開発時間に対してセレモニーの比率が高くなります。Sprintが長いほどセレモニーのオーバーヘッドは下がりますが、フィードバックが遅れます。2週間から始めて、学びに基づいて調整してください。

2020年版Scrum Guideで何が削除されましたか？

2020年のリビジョンでは、以前のバージョンで積み重なっていたいくつかの要素が削除されました。規定されていた3つのDaily Scrum質問（昨日何をしたか、今日何をするか、ブロッカーはあるか）が柔軟なフォーマットに変更されました。「Development Team」という用語が「開発者」に置き換えられました。チーフProduct OwnerとSprint 0のコンセプトが廃止されました。Scrum Masterの「サーバントリーダー」という役割の表現が単に「真のリーダー」に言い換えられました。2020年版ガイドでは3つのアーティファクトコミットメント（プロダクトゴール、スプリントゴール、Definition of Done）も初めて追加されました。これらは削除ではなく、新たな追加です。

Scrumは進化し続けます。それがポイントです。フレームワーク自体が自らが説くことを実践しています。検査し、適応し、より軽量なバージョンをリリースする。

Scrumのロールと並行してRACIマトリクスを使用したいチームへ。RACIはステークホルダー間の意思決定権限のマッピングに優れており、Scrumのロールはチーム内の責任を定義します。2つのフレームワークは対立するのではなく、補完し合います。