スクラムの3つの作成物 完全解説|プロダクトバックログ・スプリントバックログ・インクリメントと3つの確約
スクラムの3つの作成物(プロダクトバックログ・スプリントバックログ・インクリメント)と、スクラムガイド2020で追加された3つの確約(プロダクトゴール・スプリントゴール・完成の定義)を徹底解説。各作成物の定義・管理方法・よくある失敗を現役コンサルマネージャー視点で1本に整理しました。
※ 本記事はアフィリエイト広告(Amazon アソシエイト等)を含みます
スクラムの3つの作成物が機能しない根本原因は、「各作成物に紐づく確約(コミットメント)が設定されていないこと」にあります。 結論から言えば、スクラムガイド2020が定義する作成物(プロダクトバックログ・スプリントバックログ・インクリメント)は、それぞれ「プロダクトゴール・スプリントゴール・完成の定義」という確約とセットで初めて機能します。たとえば「プロダクトバックログはあるけれどプロダクトゴールが未定義」では、バックログが際限なく肥大化してチームの方向性が定まりません。本記事では、スクラムガイド2020をもとに、3つの作成物の定義・管理方法・よくある失敗を1本に整理します。
スクラムの3つの作成物と確約 一覧
スクラムには3つの作成物(アーティファクト)があり、それぞれに透明性と集中を高めるための確約(コミットメント) が結びついています。この「確約」は、スクラムガイド2020で正式に追加された重要な概念です。
| 作成物 | 役割 | 所有者 | 確約(コミットメント) |
|---|---|---|---|
| プロダクトバックログ | プロダクトに必要なものの優先リスト | プロダクトオーナー | プロダクトゴール |
| スプリントバックログ | 今スプリントのゴール・選択・計画 | 開発者 | スプリントゴール |
| インクリメント | 完成した価値ある成果物 | スクラムチーム全体 | 完成の定義(DoD) |
① プロダクトバックログ + プロダクトゴール
プロダクトバックログとは
プロダクトバックログは、プロダクトを改善するために必要なすべてのものを、優先順位順に並べた唯一のリストです。スクラムガイドでは「プロダクトに必要なことが分かった瞬間にバックログに入れる、絶えず進化するリスト」と定義されています。
- 所有者はプロダクトオーナー(PO) — 追加・削除・並べ替えを行う
- 上位の項目ほど詳細化・小分け・見積もり済みで、すぐに取り組める状態
- 下位の項目は大まかで、将来のスプリントに向けて順次詳細化される
- プロダクトバックログは完成することがない — プロダクトが存在する限り進化し続ける
バックログに入るものの例:
| 種類 | 例 |
|---|---|
| ユーザーストーリー | 「ユーザーとして注文履歴を1クリックで確認したい」 |
| バグ修正 | 「ログイン時にエラーが出る問題の修正」 |
| テクニカルタスク | 「APIのレスポンスタイムを0.5秒以内に改善」 |
| スパイク(調査) | 「決済APIの選定調査(期間:1スプリント)」 |
プロダクトゴールとは(確約)
プロダクトゴールは、スクラムチームが目指す長期的なゴールです。スクラムガイド2020では「プロダクトの将来の状態を記述するもので、スクラムチームの長期目標となる」と定義されています。
プロダクトゴールの特徴:
- 1つのプロダクトゴールに集中する — 次のゴールは現在のゴールを達成または諦めてから
- 各スプリントは、このゴールに向けたステップとして設計される
- ゴールが不明確だと「バックログが全方位に膨らむ」という典型的な失敗が起きる
記入例(Webシステム導入プロジェクト):
「2026年10月末までに、受注〜在庫連携〜帳票出力の一連の業務フローを自動化し、担当者の月次作業時間を現状比50%削減した状態を実現する」
バックログリファインメント(洗練)
バックログリファインメントとは、プロダクトバックログを継続的に詳細化・整理する活動です。スクラムガイドでは「スクラムチームがプロダクトバックログの項目を分割し、定義を追加する継続的な作業」と定義されています。
| 項目 | 内容 |
|---|---|
| 頻度 | 1スプリントあたりキャパシティの10%以内が目安(毎週30〜60分) |
| 参加者 | PO+開発者(スクラムマスターは任意) |
| 活動内容 | 項目の詳細化・分割・見積もり・優先度確認 |
| 目的 | 次のプランニングでスムーズに選択できる状態にする |
② スプリントバックログ + スプリントゴール
スプリントバックログとは
スプリントバックログは、今回のスプリントで取り組む内容と実行計画を束ねた作成物です。スクラムガイドでは「スプリントゴール(なぜ)・スプリントのために選ばれたプロダクトバックログの項目(何を)・成果物を提供するための実行可能な計画(どのように)で構成される」と定義されています。
- 所有者は開発者 — 開発者のみが内容を変更できる
- プロダクトバックログとは別物 — スプリント中の作業計画を詳細に示す
- タスクを時間単位で分割し、誰が何をいつやるかを可視化することが多い
- リアルタイムに更新される — スプリント中に学んだことをすぐ反映できる
スプリントゴールとは(確約)
スプリントゴールは、そのスプリントで達成すべき単一の目的です。スクラムガイドでは「スプリントゴールはスクラムチームに対してある程度の柔軟性を与えながらも、一貫性と集中を生み出す」と定義されています。
スプリントゴールの特徴:
- スプリントプランニングでPOが提案し、チーム全体で確定する
- スプリント中は変更できない — デイリースクラムでの日々の判断の軸になる
- 1つの文で表現でき、チーム外のステークホルダーにも説明できるレベル
記入例:
「受注入力・在庫照会の2機能をDoD基準で完成させ、担当者が実際の業務フローで試せる状態にする」
スプリントバックログはどう作るか
スプリントプランニングの3トピック(Why・What・How) の順序で作成します。
| ステップ | トピック | 内容 |
|---|---|---|
| ① | Why(スプリントゴール) | POが価値を提案 → チームで1文に確定 |
| ② | What(選択) | 開発者がキャパシティと優先度を見てバックログ項目を選ぶ |
| ③ | How(計画) | 選んだ項目をタスクに分割し実行計画を立てる |
スプリント中のスプリントバックログ変更
| 変更の種類 | 変更できるか |
|---|---|
| タスクの追加・削除(実行計画の調整) | ✅ 開発者が随時可能 |
| 担当者の変更・作業順序の変更 | ✅ 開発者が随時可能 |
| スプリントゴールの変更 | ❌ スプリント中は変更不可 |
| 選択したバックログ項目の入れ替え(スコープ変更) | ⚠️ POとの交渉で可能(ゴール危害なく・等価交換) |
③ インクリメント + 完成の定義(Definition of Done)
インクリメントとは
インクリメントは、プロダクトゴールに向けて積み上がる、価値ある具体的な一歩です。スクラムガイドでは「インクリメントはプロダクトゴールへ向かうための踏み台であり、各インクリメントは以前のすべてのインクリメントに追加され、検証されたもの」と定義されています。
インクリメントの重要な特徴:
- 1スプリントで複数のインクリメントが生まれても良い — スプリントレビュー前でも随時届けられる
- インクリメントとして認められるには完成の定義(DoD)を満たしていることが条件
- DoDを満たさない成果物は「インクリメント」と呼べない(単なる”作業の途中”)
- リリースとインクリメント認定は別の判断 — DoD満たすかどうかと、リリースするかどうかは独立した判断
完成の定義(Definition of Done)とは(確約)
完成の定義(DoD)は、インクリメントが使用可能な状態にあることを証明するための品質基準です。スクラムガイドでは「DoDはインクリメントの状態を記述する正式な形式であり、プロダクトバックログの項目がインクリメントの要件を満たしているかを確認するために使われる」と定義されています。
DoDの例
| レベル | 項目例 |
|---|---|
| コード品質 | ユニットテスト全件通過・コードレビュー実施・カバレッジ80%以上 |
| 機能動作 | 受入条件(アクセプタンスクライテリア)を満たす・手動テスト通過 |
| 非機能要件 | レスポンスタイム3秒以内・モバイル対応確認済み |
| ドキュメント | API仕様書・操作手順書を更新済み |
| デプロイ | ステージング環境にデプロイ済み・煙テスト通過 |
DoDは誰が作るか
| 状況 | DoDの作成者 |
|---|---|
| 組織全体でDoDがある | 組織のDoDを最低基準として採用し、チームがより厳しい基準を追加可能 |
| チーム独自のDoDがない | スクラムチーム全員で合意してDoDを作成する |
| DoDが未定義 | スクラムマスターがチームを支援して定義する(最優先事項) |
インクリメントのリリースについて
DoDを満たすこと と リリース(本番公開) は別の判断です。
| 判断 | 基準 | 決定者 |
|---|---|---|
| インクリメントとして認定 | DoDを満たすか | スクラムチーム(開発者) |
| リリースするか | ビジネス価値・タイミング・リスク | プロダクトオーナー |
スクラムガイドでは「スクラムチームは、いつでもプロダクトオーナーの意向でインクリメントをリリースできる」と述べており、DoDを満たしていればリリースは技術的にいつでも可能な状態になっていることが求められます。
3つの作成物の連動関係
3つの作成物は独立して存在するのではなく、プロダクトゴールを頂点とした一本の流れでつながっています。
プロダクトゴール(長期目標)
↓ 「このスプリントで何に近づくか」
スプリントゴール(スプリントの目的)
↓ 「ゴールのために選ぶ・計画する」
スプリントバックログ(今スプリントの作業)
↓ 「DoDを満たして完成させる」
インクリメント(価値ある成果物)
↓ 「プロダクトバックログに反映・更新」
次のスプリントへ → ゴールへ近づく
この流れがスムーズに回るかどうかを判断するためのチェックポイント:
| チェックポイント | OKの状態 | NGの状態 |
|---|---|---|
| プロダクトゴールの存在 | 1文で言える・チーム全員が知っている | 定義なし・人によって解釈が違う |
| バックログの優先順位 | 上位項目が明確・リファインメント済み | 全件同じ優先度・500件肥大化 |
| スプリントゴールの質 | 1文で表現・価値が伝わる | 項目の列挙・「がんばります」止まり |
| DoDの明確さ | 全員が同じ基準を知っている | 人によって違う・未定義 |
スクラム3作成物のメリット・デメリット
スクラム3作成物のメリット
- 作成物それぞれに確約(ゴール)が紐づき、チームの方向性が常に可視化される
- プロダクトバックログ1本に絞ることで、複数リストの整合確認が不要になる
- DoDがあることでスプリントをまたぐ技術的負債の蓄積を防げる
- インクリメントが毎スプリント生まれることで、ステークホルダーへの見せ方が柔軟になる
スクラム3作成物のデメリット
- プロダクトゴールの設定には経営・ビジネス視点が必要で、PM・POの力量に依存する
- DoDの合意に時間がかかり、チームが多い場合は組織横断での標準化が必要になる
- スプリントバックログが「タスクリスト化」すると、ゴール思考が失われやすい
- バックログリファインメントの習慣がないとプランニングが毎回長時間化する
よくある失敗5選
❌ 失敗①:プロダクトゴールを決めずにバックログだけ作る
バックログが存在しても、「何のために」という確約(プロダクトゴール)がないと、優先順位の軸がなく「どれも重要」という状態になります。バックログの件数だけが増え続け、上位100件を選ぶだけで議論が発散します。まずプロダクトゴールを1文で合意してから、バックログを整備する順序が正しいです。
❌ 失敗②:スプリントゴールを「完了する機能の一覧」にする
「今スプリントのゴール:機能A・機能B・バグ5件」という記述はゴールではなく完了リストです。スプリント中に予期せぬ問題が起きたとき「どれを優先すべきか」という判断軸がなく、チームが立ち往生します。スプリントゴールは「なぜそれを作るか」の価値を1文で表現することが本来の目的です。
❌ 失敗③:DoDを決めずに「完成」を宣言する
DoDが未定義のまま「できました」を積み上げると、スプリントレビュー直前や本番リリース直前に「テストがない」「ドキュメントがない」が発覚します。これはスプリントをまたぐ技術的負債の典型です。DoDはプロジェクト開始直後(理想はキックオフ時)に合意することが原則です。
❌ 失敗④:プロダクトバックログとスプリントバックログを混在させる
「スプリントで決まったけどバックログに戻ってしまった」「どこに書いたか分からない」というのは、2つのバックログを1つのシートで管理しているケースによく起きます。プロダクトバックログ(何を作るか全体) と スプリントバックログ(今スプリントの計画) は明確に分離します。
❌ 失敗⑤:インクリメントをスプリントレビューまで「隠す」
スクラムガイドでは「スプリントレビューを待たずにインクリメントを届けられる」と明記されています。「スプリント中は見せない」という文化があると、2週間ぶんの成果を一度にデモすることになり、フィードバックが遅くなります。DoDを満たしたら、POの判断でいつでもリリース可能という運用を目指しましょう。
よくある質問(FAQ)
Q. プロダクトバックログは何のツールで管理すればいい?
JiraやBacklog、NotionのデータベースなどのITツールが多く使われますが、スクラムガイドはツールを指定していません。チームが少人数でシンプルに始めるならスプレッドシートやホワイトボードカードでも十分です。重要なのは「1つのリストに優先順位順に並んでいる」ことであり、ツールの種類より全員がアクセスできる透明性を優先してください。
Q. DoDは一度決めたら変えられない?
変えられます。チームが成熟するにつれて品質基準を高めるのは理想的です。たとえばスタート時は「ユニットテスト60%以上」としたDoDを、半年後に「80%以上+CI/CDパイプライン通過」に厳格化することはむしろ推奨されます。ただしスプリント中にDoDを変更してはいけません(変更はスプリント開始前に行う)。
Q. プロダクトゴールとスプリントゴールの違いは?
プロダクトゴールは長期的な方向性(数か月〜1年以上)、スプリントゴールは短期的な目的(1〜4週間)です。「Webシステムで月次作業を50%削減する」がプロダクトゴールなら、「受注入力フローをDoDで完成させてステークホルダーがデモできる状態にする」がスプリントゴールです。スプリントゴールはプロダクトゴールへ近づく1つのステップとして設計します。
Q. スプリントバックログは誰でも変更できる?
スプリントバックログの所有者は開発者です。POはスプリントバックログを直接変更できません(介入してはいけない)。スコープ(選んだ項目)の変更が必要な場合は、POと開発者が交渉します。ただしスプリントゴール自体はスプリント中に変更できない点に注意してください。
Q. 1スプリントで複数のインクリメントを作っていい?
はい。スクラムガイドでは「1スプリントに複数のインクリメントが生み出される場合がある」と明記されています。たとえば「機能A」がスプリント8日目にDoDを満たしたら、14日目の終了を待たずPOが判断してリリースできます。この柔軟性がスクラムの強みの一つです。
まとめ|3作成物は「確約」とセットで初めて機能する
スクラムの3つの作成物を整理すると、次のように覚えられます。
| 作成物 | 一言でいうと | 確約(ゴール) |
|---|---|---|
| プロダクトバックログ | 「何を作るか」の全体リスト(POが管理) | プロダクトゴール = 長期の方向性 |
| スプリントバックログ | 「今スプリントで何をどう作るか」の計画(開発者が管理) | スプリントゴール = 今回の目的 |
| インクリメント | 「DoDを満たした完成品」 | 完成の定義(DoD)= 品質基準 |
3作成物の関係性:プロダクトゴールという北極星 があり、各スプリントがその方向に進む。スプリントごとに スプリントゴール を決め、DoDを満たしたインクリメント を届ける。この繰り返しがスクラムの本質です。
次のステップとして、以下の関連記事も参照してください。
- スクラムガイド2020完全解説|3つの役割・5つのイベント・3つの作成物(スクラムの全体像)
- スクラムの5つのイベント完全解説(各イベントの目的と進め方)
- アジャイルとウォーターフォールの使い分け(どちらを選ぶか)
出典・参考情報
関連記事
- カンバンとスクラムの違い|どちらを採用すべきか
カンバンとスクラムの違いが分からない方へ。フロー型(カンバン)とイテレーション型(スクラム)の本質的な差異を7軸の比較表で整理し、向くプロジェクト・チームの特性とScrumban(組み合わせ運用)まで現役コンサルマネージャー視点で解説します。
- プロダクトオーナーの役割 完全解説|プロダクトバックログ管理・優先順位付け・ステークホルダー対応を担う「価値の番人」
プロダクトオーナーが機能しない根本原因は「委員会型・伝書鳩型」にあります。スクラムガイド2020に基づき、3つのアカウンタビリティ・POとPM・SMの違い・バックログ優先順位付けの4軸・よくある失敗を現役コンサルマネージャー視点で解説します。
- スクラムマスターの役割 完全解説|チームのコーチ・障害除去・組織変革を担うサーバントリーダー
スクラムマスターが機能しない根本原因は「PMと同じように指示・管理しようとすること」にあります。スクラムガイド2020に基づき、3つのアカウンタビリティ(チーム・PO・組織への奉仕)・SMとPMの違い・4つのスタンス・よくある失敗を現役コンサルマネージャー視点で解説します。
- アジャイル契約の進め方|準委任・SES・成果報酬の比較と選び方
アジャイル開発で「請負契約でいいか」と迷っているPMへ。準委任・SES・成果報酬型の違いと選択基準、IPA公式モデル契約書の要点、偽装請負を防ぐベンダーマネジメントの工夫を現役コンサルマネージャー視点で解説します。