はじめに
保育士向け転職サイトと、ホテル向け転職サイトの開発チームにて、スクラムマスターを担当しているfurusawaです。
2025年6月、スクラムの共同考案者であるJeff Sutherlandらによって 「スクラムガイド拡張パック（Scrum Guide Expansion Pack）」 が公開されました。2020年版スクラムガイドを補完するものとされています。
この記事では、拡張パックの概要と、2020年版スクラムガイドとの違いを整理し、現場での活用ポイントをまとめてみます！
「スクラムガイド拡張パック」とは？
スクラムガイド拡張パックは、2020年版スクラムガイドの 「補完ドキュメント」 です。スクラムガイドを置き換えるものではなく、現代の複雑なプロダクト開発環境に合わせた実践的なガイダンスを追加するものです。
著者: Jeff Sutherland、John Coleman、Ralph Jocham など
主な特徴を整理すると、以下の通りです。
| 特徴 | 内容 |
|---|---|
| ボリューム | 2020年版スクラムガイドの 約10倍 |
| ライセンス | オープンソース、GitHubで公開 |
| 更新頻度 | 四半期ごと に更新されるリビングドキュメント |
| 日本語版 | scrumexpansion.org/ja/ で公開中 |
| カテゴリ | Strategy / Teams / Engineering / Leadership / AI / Product / Value |
2020年版スクラムガイドがベースとなる考え方の 「ルールブック」 だとすれば、拡張パックは 「実践の事例集」 という位置づけです。スクラムの「何をするか」だけでなく、「なぜそうするのか」「どう応用するか」までカバーしています。
また、Jeff Sutherlandが最も重視した点として、 「固定的で変わらないスクラムガイド」という状態を終わらせること があります。GitHubでコミュニティからのフィードバックを受け付け、四半期ごとに更新していく「生きたドキュメント」として設計されています。
2020年版のスクラムガイドは2026年現在も新しいものに更新されることはないため、四半期ごとに更新される点は大きな違いと言えます。
2020年版スクラムガイドとの主な違い
拡張パックでは、2020年版スクラムガイドに対して多くの概念追加・用語変更が行われています。主要な違いを比較表にまとめました。
| 観点 | 2020年版スクラムガイド | 拡張パック |
|---|---|---|
| フレームワークの性質 | 不変（immutable） | 適応的（"曖昧さ"を許容） |
| 開発者の呼称 | 開発者（Developers） | プロダクト開発者（Product Developers） |
| 責任の表現 | 責任（responsibility） | 説明責任（accountability） |
| 完成の定義 | 1つ（Definition of Done） | 2つ（Output Done / Outcome Done） |
| ステークホルダー | 言及あり | 正式な役割 として定義 |
| AIの扱い | なし | プロダクト開発者としてのAI、リスク管理 |
| 複数チームへの対応 | 言及なし | スケーリングの指針あり（特定フレームワーク非依存） |
| 理論的背景 | 経験主義とリーン思考 | Cynefin、OODA、First Principles、Beyond Budgeting等を追加 |
この中から、特に現場へのインパクトが大きい変更点を掘り下げます。
（※余談ですが、弊社でもエンジニアの呼称をWebエンジニアからプロダクトエンジニアに変更しました）
Output Done と Outcome Done
2020年版スクラムガイドでは 完成の定義（Definition of Done） は1つでしたが、拡張パックではこれを 2つ に分けています。
- Output Done（アウトプットの完成）: インクリメントが品質基準を満たし、リリース可能な状態であること
- Outcome Done（アウトカムの完成）: リリースした結果、期待した 価値が実際に実現 されたこと
例えば、「新しい検索機能をリリースした」は Output Done です。しかし、「その検索機能によってユーザーの離脱率が下がった」ことが確認できて初めて Outcome Done となります。
この区分は、いわゆる 「機能工場（Feature Factory）」 ── ただ機能を作り続けるだけで価値を検証しないチーム ── というアンチパターンへの明確な対策です。
Outputにのみフォーカスを当てすぎると、プロダクト価値の低い、自己満足的な機能開発ばかりしてしまい、本質的に大切なOutcomeの意識が薄れてしまうため、この完成の定義の変更は重要だと感じます。
プロダクト思考（Product > Project）
拡張パックでは、 プロジェクト（一時的）よりもプロダクト（長期的） という考え方が強調されています。
ここでいう「プロジェクト」とは、期限と終わりが決まった一過性の活動のことです。一方「プロダクト」は、ユーザーへの価値提供を目的として継続的に育て続けるもの──つまり「作って終わり」ではなく「リリース後もフィードバックをもとに進化させ続けるもの」を指します。
2020年版スクラムガイドは汎用的なフレームワークとして様々な領域に適用できるよう書かれていましたが、拡張パックではプロダクト開発に焦点を当て直しています。「開発者」が 「プロダクト開発者」 に改称されたのも、この文脈です。
プロダクトオーナーの役割も変化しており、単なるバックログ管理者ではなく、 長期的な価値を見据えた戦略的リーダー としての側面が強調されています。
AIの統合
拡張パックでは、AIに関する独立したセクションが設けられています。
AIを プロダクト開発者の一員 として捉え、チームが自分たちの 「AIスタンス」 を明確に定義することが推奨されています。つまり、AIをどの程度活用するか、どのようなリスクを許容するか（あるいはしないか）をチームとして意識的に決めるということです。
Jeff Sutherlandは「AIを効果的に活用するには、むしろ より高度なアジャイル対応が必須 であり、スクラムの重要性は増す」と述べています。AIが台頭する時代においてスクラムが時代遅れだという見方に対する、明確な回答といえるでしょう。
弊社でもClaude CodeやGeminiなどAIを活用する環境が用意されていますが、まだまだ発展途上という段階で、各スクラムチームごとに利用の仕方はまちまちです。
このAI周りの記述は、拡張パックにおける四半期ごとの更新で目まぐるしく変わっていくのではないかと思います。
複雑性理論とCynefinフレームワーク
2020年版スクラムガイドでは「経験主義」と「リーン思考」が理論的背景でしたが、拡張パックでは Cynefin（クネビン）フレームワーク を用いた複雑性理論が追加されています。
スクラムが 「なぜ」有効なのか という概念的な背景が、初めて公式に語られた形です。複雑な領域では従来型の計画が機能しないこと、 安全に失敗できる実験（safe-to-fail experiments） を通じて学習していくことの重要性が述べられています。
現場への活用ポイント
拡張パックは2020年版スクラムガイドの約10倍のボリュームがあり、すべてを一度に読み込むのは現実的ではありません。現場で活用するためのポイントを4つご紹介します。
1. 全部読まなくて大丈夫
拡張パックはカテゴリ（Strategy / Teams / Engineering / Leadership / AI / Product / Value）ごとにドキュメントが分かれています。チームが今直面している課題に関連するセクションから読み始めるのがおすすめです。
2. レトロスペクティブで1トピックずつ取り上げる
例えば「今スプリントは、Output DoneとOutcome Doneの違いについてチームで話してみよう」というように、レトロの場で1つずつ概念を取り上げていくと、自然にチームの共通言語として浸透していきます。
3. チームのAIスタンスを決める
拡張パックが推奨するアクションの一つです。AIをどの程度活用するか、どんなリスクを許容するかをチームで明示的に議論し、合意を形成することで、日々の開発判断がスムーズになります。
4. リビングドキュメントとして付き合う
四半期ごとに更新されるため、公式サイトやGitHubリポジトリをブックマークしておき、定期的にチェックすると良いでしょう。2020年版スクラムガイドのような「一度読んだら終わり」ではなく、継続的に付き合っていくドキュメントです。
まとめ
スクラムガイド拡張パックは、2020年版スクラムガイドの簡潔さを維持しつつ、現代のプロダクト開発に必要な実践的ガイダンスを提供する重要なドキュメントです。
私たちのチームでも、まずは Output Done / Outcome Doneの考え方 から取り入れてみようと思っています。「機能をリリースしたら終わり」ではなく、「その結果どんな価値が生まれたか」までをチームの完成の定義に含めることで、プロダクトへの意識がさらに高まるのではないかと期待しています。
拡張パックの日本語版は以下から無料で読むことができます。チームの状況に合ったセクションから、ぜひ読んでみてください。
拡張パックとは言え、根底にはやはりアジャイルソフトウェア宣言の思想は感じられる内容だとも思いました。こちらも今一度、読み直しておきたいですね。
Discussion