スクラム入門｜スクラムガイド2020準拠の役割・イベント・進め方

スクラムとは、複雑な問題に対応しながら、価値のあるプロダクトを少しずつ届けていくための「軽量級フレームワーク」です。1か月以内の決まった期間（スプリント）を繰り返し、そのたびに動くものを作って、結果を見て計画と進め方を調整します。スクラムの公式な定義は、考案者のケン・シュウェイバー氏とジェフ・サザーランド氏が公開している「スクラムガイド」にまとめられており、現在の最新版は2020年11月版です（日本語版も公式サイトで公開されています）。

スクラムについての解説は多くありますが、2017年以前の版の用語（「開発チーム」「ロール」など）のまま書かれたものも少なくありません。この記事は、スクラムガイド2020年版の日本語版の用語と定義に沿って、3つの責任、5つのイベント、3つの作成物と確約を整理し、よくある誤解、ウォーターフォールとの比較、受託開発・SIでの取り入れ方、1スプリントの具体的な流れまでを一続きで解説します。

スクラムの早見表

スクラムの土台：経験主義と3本柱

スクラムは「経験主義」と「リーン思考」に基づいています。経験主義とは、「知識は経験から生まれ、意思決定は観察に基づく」という考え方です。最初にすべてを予測して計画するのではなく、短い期間で実際に作り、その結果を見て次を決めることを繰り返します。

経験主義を支えるのが、次の3本柱です。

さらに、スクラムチームが大切にする5つの価値基準は「確約・集中・公開・尊敬・勇気」です。ガイドでは、これらの価値基準を体現することで、3本柱が実現されると説明しています。

3つの責任：スクラムチームの構成

スクラムチームは、1人のスクラムマスター、1人のプロダクトオーナー、複数の開発者で構成されます。チームの中に、サブチームや上下関係はありません。人数は通常10人以下で、チームは自己管理型（誰が何を、いつ、どのように行うかをチーム内で決める）です。

2020年版では、2017年版までの「ロール（役割）」という表現が、「責任（accountabilities）」に変わりました。日本語版では「責任」と訳されており、一般には「説明責任」と呼ばれることもあります。「肩書き」ではなく「何に責任を持つか」を表している、と捉えるとわかりやすくなります。

押さえておきたいポイント

• プロダクトオーナーは委員会ではなく1人の人間です。多くの関係者の要望をまとめることはあっても、判断の窓口は1人です
• スクラムマスターは、チームと組織に奉仕する「真のリーダー」とガイドで説明されています。作業を割り振る管理者ではありません
• 「開発者」はプログラマーだけを指すのではありません。テスト、デザイン、分析など、インクリメントを作るために必要な専門性を持つ人すべてを含みます
• 2017年版の「開発チーム」という呼び方は、2020年版で「開発者」に変わりました。プロダクトオーナーと開発者が別のチームのように分かれないよう、1つのスクラムチームとして扱うための変更です

5つのイベント

イベントは、作成物を検査し、適応させるための公式な機会です。決まった時間と場所で行うことで、ほかの会議を減らすことも狙いの1つです。

スプリントが1か月より短い場合、各イベントの時間も通常はそれより短くなります。

スプリント

スプリントは、ほかの4つのイベントをすべて含む「器」です。スプリント中は、次のことを守ります。

• スプリントゴールの達成を危険にさらすような変更はしない
• 品質を低下させない
• 必要に応じてプロダクトバックログをリファインメント（後述）する
• 学びが増えるにつれて、スコープ（範囲）はプロダクトオーナーと交渉して明確にしてよい

スプリントゴールが役に立たなくなった場合、スプリントは中止されることがあります。中止できる権限を持つのはプロダクトオーナーだけです。

スプリントプランニング

スプリントの最初に、スクラムチーム全体で次の3つのトピックを扱います。

スプリントゴール、選んだアイテム、その実行計画をまとめたものが「スプリントバックログ」です。

デイリースクラム

デイリースクラムは、開発者のための15分のイベントです。目的は、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることです。複雑さを減らすため、毎日同じ時間・同じ場所で行います。

• 進め方（何を話すか、どんな形式か）は、スプリントゴールへの進捗に焦点が当たり、次の1日の実行計画ができるなら、開発者が自由に選べます
• 2017年版にあった「昨日やったこと・今日やること・障害」の3つの質問は、2020年版では必須ではなくなりました
• プロダクトオーナーやスクラムマスターがスプリントバックログのアイテムに取り組んでいる場合は、開発者として参加します
• 細かい調整や計画の見直しは、デイリースクラムの後にも一日中行ってかまいません

スプリントレビュー

スプリントの成果を検査し、今後の適応を決めるイベントです。スクラムチームが主要なステークホルダーに作業の結果を見せ、達成したことや環境の変化を踏まえて、次に何をするかを一緒に考えます。ガイドでは、スプリントレビューを「プレゼンテーションだけ」に限定しないようにすると書かれており、関係者と一緒に考える作業の場として位置づけられています。

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

スプリントを締めくくるイベントで、品質と効果を高める方法を計画します。人・相互作用・プロセス・ツール・完成の定義について、何がうまくいき、どんな問題があったかを話し合います。最も効果の大きい改善は、できるだけ早く対処し、次のスプリントのスプリントバックログに追加してもよいとされています。

3つの作成物と確約

2020年版では、3つの作成物それぞれに「確約（コミットメント）」が1つずつ対応づけられました。確約は、その作成物の進み具合を測るための「目指す先」や「基準」です。

完成の定義（Definition of Done）

完成の定義を満たしたアイテムだけが、インクリメントになります。満たしていないアイテムは、リリースもスプリントレビューでの提示もせず、プロダクトバックログに戻して検討し直します。

• 組織の標準として完成の定義がある場合は、すべてのスクラムチームが最低限それに従います
• 組織の標準がない場合は、スクラムチームがプロダクトに合った完成の定義を作ります
• 完成の定義の例：「コードレビュー済み」「自動テストが通っている」「ステージング環境にデプロイ済み」「利用者向けの説明が更新済み」など

インクリメントは、スプリントの中で複数作ってもかまいません。ガイドには「スプリントレビューを、価値をリリースするための関門と見なすべきではない」とあり、完成したものはスプリントの途中でもステークホルダーに届けられます。

プロダクトバックログリファインメント

リファインメントとは、プロダクトバックログアイテムを、より小さく、より詳細にしていく継続的な活動です。説明・並び順・サイズなどを詳しくしていきます。サイズを見積もるのは、その作業を行う開発者です。リファインメントはイベントではありませんが、スプリント中に継続して行うことで、次のスプリントプランニングがスムーズになります。

よくある誤解

ウォーターフォールとの比較

ウォーターフォールとは、要件定義→設計→実装→テスト→リリースを、工程ごとに順番に進める開発の進め方です。どちらにも向いている状況があり、プロジェクトの性質で選びます。

ウォーターフォールは「予測できること」を着実に進めるのに強く、スクラムは「やってみないとわからないこと」に強いと考えると、使い分けの判断がしやすくなります。

受託開発・SIでの取り入れ方

受託開発やSIでは、発注者と受注者が別の会社であるため、契約・要件定義・体制の3つを、スクラムの考え方とそろえておくことが大切です。

契約との関係

IPA（情報処理推進機構）は2020年3月に「情報システム・モデル取引・契約書（アジャイル開発版）」を公開しており、準委任契約を前提としたモデル契約書と、契約前に双方で確認するためのチェックリストが用意されています。ただし、実際の契約形態はプロジェクトの事情によってさまざまで、どの形態を選ぶかは、双方の法務担当を交えて確認するのが確実です。

要件定義との関係

• 最初にすべての要件を固めるのではなく、プロダクトゴールと、最初の数スプリント分のプロダクトバックログを合意して始める進め方がよく取られます
• 発注者側からプロダクトオーナーを出すか、受注者側が支援する形にするかを決め、並び順の最終判断を誰がするかをはっきりさせます
• 全体の予算や期限がある場合は、「期限内に、並び順の上から完成させていく」という形で、範囲を調整できる余地を合意しておくと進めやすくなります

体制と進め方の工夫

1スプリントの流れの例

2週間スプリント、スクラムチーム7人（PO 1人、スクラムマスター 1人、開発者 5人）で、社内向けの「会議室予約アプリ」を作る架空の例です。

2週間スプリントの時間の目安は、1か月スプリントの上限（8時間・4時間・3時間）から比例的に短くしたものです。スクラムガイドが定めるのは最大の時間で、それより短く終わってもかまいません。

よくある質問

Q. スクラムとアジャイルは何が違いますか？ A. アジャイルは、2001年の「アジャイルソフトウェア開発宣言」に代表される価値観と原則の総称です。スクラムは、その考え方を実践するための具体的なフレームワークの1つです。

Q. スクラムマスターとプロダクトオーナーは兼任できますか？ A. スクラムガイドは兼任を明示的に禁止してはいませんが、2つの責任は性質が異なります。価値の最大化（PO）とスクラムの確立（SM）に、それぞれ十分な時間を割けるかを基準に判断するとよいでしょう。

Q. スプリントの長さは何週間がよいですか？ A. ガイドの決まりは「1か月以内の固定の長さ」だけです。フィードバックを早く得たい場合や、見通しが立ちにくい場合は短め（1〜2週間）にする例が多く見られます。一度決めたら、しばらく同じ長さで続けると、チームのリズムができます。

Q. スクラムガイド2017年版から、何が大きく変わりましたか？ A. 主な変更は、「開発チーム」から「開発者」へ、「ロール」から「責任」へ、プロダクトゴールと3つの確約の追加、デイリースクラムの3つの質問の削除、「自己組織化」から「自己管理」への表現の変更などです。全体として、ソフトウェア開発以外の分野でも使いやすい、より簡潔な内容になりました。

まとめ

• スクラムは、経験主義に基づき、短いスプリントで検査と適応を繰り返す軽量級フレームワークです
• 3つの責任はプロダクトオーナー（価値の最大化）・スクラムマスター（スクラムの確立）・開発者（インクリメントを作る）です
• 5つのイベントはスプリント・プランニング・デイリースクラム・レビュー・レトロスペクティブで、それぞれにタイムボックスがあります
• 3つの作成物には、プロダクトゴール・スプリントゴール・完成の定義という確約が対応します
• デイリースクラムは進捗報告会ではなく、開発者が計画を調整する場です
• 受託開発・SIでは、契約・要件定義・体制をスクラムの進め方とそろえることが大切です
• 迷ったら、最新のスクラムガイド（2020年版）の日本語版に立ち返りましょう

株式会社RJCでは、チームで短い周期の振り返りを重ねながら、より良い進め方を仲間と一緒に探しています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。