スクラムの定義
スクラムはアジャイルのやり方の1つで、最も普及しているとIPAのモデル契約も述べています [G3]。
スクラムの公式のガイド（スクラムガイド、2020年11月版）は、スクラムを「複雑な問題に対する適応的な解決策を通じて、人やチーム、組織が価値を生み出すのを助ける軽量な枠組み」と定義しています [G2]。
ガイドは、スクラムの流れを次のように要約しています [G2]。
- プロダクトオーナーが、複雑な問題に対する作業を「プロダクトバックログ」に並べる
- スクラムチームが、その中から選んだ作業を「スプリント」の間に、価値のある「インクリメント」に変える
- スクラムチームと関係者が結果を確認して、次のスプリントに向けて調整する
- これを繰り返す
3本柱：透明性・検査・適応
スクラムは、経験から学ぶ考え方（経験主義）と、ムダを減らす考え方（リーン思考）にもとづいています。ガイドは、スクラムの土台として3つの柱を挙げています [G2]。
- 透明性：作業の進み方が、実際に作業する人にもその成果を受け取る人にも見えていること
- 検査：成果物と目標に向けた進み具合を、頻繁に、注意深く確認すること。透明性がなければ検査は誤解のもとになる
- 適応：検査の結果問題があれば、できるだけ早くやり方や成果物を調整すること
スクラムチーム：3つの役割
スクラムチームは、1人のスクラムマスター、1人のプロダクトオーナー、そして開発者で構成されます。チームの中に、サブチームや上下関係はありません。
チームは通常10人以下で、必要なスキルを全部持ち（機能横断）、誰が、何を、いつ、どうやるかを自分たちで決めます（自己管理） [G2]。
| 役割 | 責任（スクラムガイドより） |
| プロダクトオーナー | プロダクトの価値を最大にすること。 プロダクトゴールを示し、バックログの項目を明確に伝え、並び順を決める。 1人であって、委員会ではない [G2]。 |
| スクラムマスター | スクラムが、ガイドに書かれたとおりに行われるようにすること。 チームが、より効果的になるよう支える。 障害物（妨げ）の除去、会議（イベント）が良い形で行われるようにする [G2]。 |
| 開発者 | 各スプリントで、使えるインクリメントを作ること。 スプリントの計画（スプリントバックログ）を作り、「完成の定義」を守って品質を作り込み、毎日計画を調整する[G2]。 |
注記：表の内容は、スクラムガイドの原文（英語）を、私が日本語に要約したものです。
公式の日本語版（スクラムガイド）と、表現が異なる場合があります。
スプリントと、4つの会議
スプリントは、スクラムの心臓にあたる固定された長さの期間です。長さは1か月以内で、前のスプリントが終わるとすぐに次が始まります。
スプリントの間は、次のことが守られます [G2]。
- スプリントゴールを危うくする変更はしない
- 品質は下げない
- プロダクトバックログは必要に応じて見直す
- わかってきたことに応じて、範囲をプロダクトオーナーと調整する（再交渉する）ことはある
スプリントの中で、次の4つの会議が行われます [G2]。
| 会議 | 時間の上限 （1か月のスプリントの場合） | 目的 |
| スプリントプランニング | 8時間 | スプリントの目的（なぜ価値があるか）、何ができるか、どうやるかを決める。 |
| デイリースクラム | 15分（毎日） | スプリントゴールに向けた進み具合を確認し、計画を調整する。 開発者のための会議。 |
| スプリントレビュー | 4時間 | スプリントの成果を確認し、今後の調整を決める。 関係者と一緒に、次に何をするかを協議する。 |
| スプリントレトロスペクティブ （振り返り） | 3時間 | 品質と効果を高める方法を計画する。 人、関係、プロセス、道具、完成の定義を見直す |
スプリントレビューは単なる発表ではなく、「作業の場」であるとガイドは述べています。また、レビューは価値をリリースするための関門であってはならない、とも書かれています [G2]。
3つの成果物と、それぞれの約束
スクラムガイドは、3つの成果物とそれぞれに付いている「約束（コミットメント）」を挙げています [G2]。
| 成果物 | 約束 | ひとことで言うと |
| プロダクトバックログ | プロダクトゴール | プロダクトを良くするために必要なものを並べた、変化し続ける一覧。 チーム作業の唯一の出どころ。 |
| スプリントバックログ | スプリントゴール | そのスプリントの目的、選んだ項目、実行の計画。 開発者が自分たちのために作る。 |
| インクリメント | 完成の定義 （Definition of Done） | 目標に向かう具体的な一歩。 使える状態で、確認が済んだもの。 |
「完成の定義」は、インクリメントがプロダクトに必要な品質の基準を満たした状態を、正式に説明したものです。
ガイドは、完成の定義を満たさない項目はリリースもスプリントレビューでの提示もできず、プロダクトバックログに戻る、と書いています [G2]。
発注側にとっては、この「完成の定義」をあらかじめ共有することが、「できた」の認識違いを防ぐ大切な点です。
注記：「発注側にとって、完成の定義を共有することが大切」という部分は、
ガイドの記述から私が導いた実務上の整理です。ガイドの文言そのものではありません。
「スクラムの一部だけ」はスクラムではない
スクラムガイドは、スクラムの枠組みは変更できない（immutable）と述べています。スクラムの一部だけを実践することは可能ですが、その結果はスクラムではない、とも書いています [G2]。
また、ガイドの冒頭でも、スクラムの核となる設計を変える・要素を省く・ルールに従わないという行為は、問題を覆い隠し、利点を制限し、場合によってはスクラムを役に立たなくする、と警告しています [G2]。
「スクラムでやっている」と言われたときは、実際にこの3つの役割、4つの会議、3つの成果物が揃っているかを確認すると、実態がわかります。
発注の前に確認したいこと
- 3つの役割（プロダクトオーナー、スクラムマスター、開発者）は、それぞれ誰か。自社からは誰が参加するか
- スプリントの長さはどれくらいか（基本1か月以内）。レビューの日程に発注側が参加できるか
- 「完成の定義」は書かれているか。品質（テスト、セキュリティ、文書など）の基準は含まれているか
- プロダクトバックログは、誰が管理し、どう優先順位を決めるか。発注側が見られるか
注記：この4点は、スクラムガイドの内容から私が整理した確認項目です。
ガイドがこの形のチェックリストを示しているわけではありません。
参照元
[G2] Ken Schwaber & Jeff Sutherland, The Scrum Guide（2020年11月版） — https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
[G3] IPA・経済産業省, 情報システム・モデル取引・契約書＜アジャイル開発版＞ アジャイル開発外部委託モデル契約 R1（2020年3月、2025年4月 R1） — https://www.ipa.go.jp/digital/model/ug65p90000001ldr-att/000081484.pdf
コメント