スクラムガイドに適応する
開発者として働いていると、スクラムガイドを読む機会が何度か訪れます。
でも正直、スクラムマスターでもなければ「ちゃんと読んだ」「しっかり理解している」という人は、あまり多くない気がします。
個人的にその背景には、おそらくこんな壁があるのではないかとぼんやり思っていました。
- ふだん使わないインテリっぽい表現（「漸進的」とかググらないと意味がわからない）
- 翻訳特有の読みづらさ（語順や構文の違い、抽象的な表現など）
- カタカナアレルギーの発症（専門用語の多さ）
僕自身も何度か読み返す中で、もっと馴染みやすい言葉でだったらなと感じたことがあります。
そこでこの記事では、スクラムガイドの内容をなるべくやさしい言葉に置き換え、一部を整理しながらアウトプットします。
スクラムマスターの認定は取得していますが、自分の解釈を通じて、公式の定義とは少し違うこともあることをご容赦ください。
公式文書：
スクラムガイド（2020年版）日本語版
前提として
導入で“壁”について触れましたが、その前に、どうしても先にお伝えしておきたい大切なことがあります。
スクラムガイドの日本語訳は、とても丁寧で誠実な仕事だと感じています。原著の意図を正確に伝えようとする姿勢があり、プロフェッショナルな翻訳が提供されていることに、心から感謝しています。僕のように英語が苦手な日本人にとって、スクラムという考え方に触れるハードルを大きく下げてくれていると実感しています。
それでもなお、部分的ではありますが、翻訳された日本語特有の読みづらさや引っかかりを感じる瞬間があります。
たとえば「自己管理型」「透明性」「漸進的や反復的」などの表現は、理屈では理解できても、実感としてすっと腑に落ちないことがあります。
これは翻訳の良し悪しというよりも、英語と日本語の語順や構文の違い、文化的背景、そして抽象的な表現に対する慣れの差などが影響しているのだと思います。英語に親しんでいる人にとっては、特に違和感を覚えることなく読めるのかもしれません。
この記事では、スクラムガイドの公式文書の内容を尊重しつつ、「英語も難しい日本語も少し苦手な自分」が、現場で理解しやすい言葉に置き換えながら再整理してみようと思います。
これはあくまでひとつの解釈ですが、もしスクラムガイドを読んで「なんだか難しいな」と感じた方がいたら、その方が読み進めやすくなるための補助として役立てたらうれしいです。
スクラムの定義
スクラムとは？
スクラムは、変化が多くて複雑な問題に対応するための 「シンプルなチームの働き方に関するフレームワーク」 です。誤解してはならない点は、 「複雑さを排除」するのではなく、「複雑さに対応する」 フレームワークである点だと思います。スクラムは、複雑さに対応しチームや組織が価値ある成果を出すために、柔軟に対応できるよう仕組み化されています。
スクラムマスターの役割とは？
スクラムマスターは、チームがスムーズにスクラムを使えるように支える役割を持った人です。
簡単に言えばスクラムを行う上で必要な流れを助け、チームにスクラムが浸透しその効果を発揮できるようコーチングします。
- プロダクトオーナーは、やるべき作業をプロダクトバックログ（開発チームが取り組む作業の優先順位をつけたリスト）にまとめる
- スクラムチーム（開発を担当するチーム）がその中から選んでスプリント（短い開発期間の単位）で価値ある成果（インクリメント）を作る
- スクラムチームとステークホルダー（関係者）は、結果をみんなでチェックし、次のスプリントに活かす
- この流れをくり返す
スクラムのルールは指示ではなく「ガイドライン」
スクラムのルールは「こうしなさい」という命令ではなく、チームが自分たちに合った形で進められるように作られたガイドラインとして機能します。チームが複雑な問題に直面したとき、どのように対応していくべきか、その方向性を示すものです。具体的な方法や手順については、チームが自ら考え、決定し、進行していく必要があります。スクラムは、そうした実践者たちの集合知によって構築されています。
このような背景から、スクラムでは理論の実現に必要な最小限のルールのみが定義されています。あえて不完全な形で提示されており、その曖昧さこそが、状況に応じた柔軟な対応を可能にする仕組みとなっています。
スクラムでできること
シンプルなスクラムのルールは、様々な環境で使うことができます。スクラムを使うことで、そのさまざまなプロセス、技法、手法を使用することができ。スクラムで今あるやり方をそのまま活かしたり、逆に不要なものを見つけたりできます。スクラムによって何がうまくいっていて、何がうまくいっていないかが見えるようになり、改善しやすくなります。
スクラムの理論
スクラムが大切にしている２つの考え方
スクラムは 「経験主義」 と 「リーン思考」 という２つの考え方を大切にしている為、そのルールや仕組みはそういった考えに基づいています。
-
経験主義（経験から学ぶ）
「経験は知識から生まれ、意思決定は観察に基づく」
つまり実際にやってみて、観察して、そこから学ぶことを大切にし意思決定を行う。 -
リーン思考（ムダを減らす）
「無駄を省き、本質に集中する」
つまり必要なことに集中して、ムダを減らそう。
スクラムの進め方：2つのアプローチ
スクラムでは、「イテレーティブ（反復的）」 と 「インクリメンタル（漸進的）」 という2つのアプローチを組み合わせて開発を進めます。ちなみに漸進的（ぜんしんてき）と読みます。
-
イテレーティブ（反復的）
「同じことを何度も繰り返すこと」
つまり小さく区切り、同じようなサイクルを何度もくり返すことで改善を図ります。 -
インクリメンタル（漸進的）
「手順を経て徐々に目的や理想を実現しようとする傾向にあること」
つまり少しずつ価値を積み上げ、プロダクトを段階的に完成へ近づけいきます。
この２つのアプローチを組み合わせることで、スクラムでは予測可能性（予測しやすくする可能性） を高めていきます。
スクラムは、「変化が起きるのが当たり前」という前提に立ち、イテレーティブな手法と経験主義を通じて、実体験に基づいた計画と調整を繰り返すことができます。同時にインクリメンタルな手法で各スプリント（短い開発期間の単位）で価値のある成果（インクリメント）を積み上げることができます。
これにより、「今どこまで進んでいて、何が起こりそうか」といった現実的な見通しを持てるようになります。逆にイテレーティブやインクリメンタルのアプローチがないと、複雑性が増し、全体像を見失いやすくなり、どこに問題があるのかさえ掴めないまま開発が迷走してしまう危険性があります。
この２つのアプローチがあることで、進捗や状況をチーム全体で把握しやすくなり、納期の遅れや品質のばらつき、手戻りなど、開発におけるさまざまなリスクを制御することにつながります。
スクラムの土台となる3つの柱
スクラムでは、スプリントプランニング（スプリントの計画）などのイベント（定期的な場）が全部で４つ存在します。このイベントを機能させるために必要なことが 「経験主義のスクラムの３本柱」 と呼ばれる 「透明性」 「検査」 「適応」 です。「透明性の確保」は現場で聞いたことがあるのではないでしょうか？
1. 透明性（見える化）
厳密には単なる見える化とは異なるのですが、イメージとしては近いと思います。透明性があることでチームは無駄なく、正確かつ迅速に意思決定し、価値を最大化していくことができます。つまり、チームの作業や成果がしっかり見えて、みんなが正しく判断できる環境です。
スクラムにおける「透明性」とは、作業の進捗、成果物の状態、ルールや基準などが、誰にとっても明確である状態を指します。これらが曖昧なままだと、正しい判断や適切な対応ができなくなってしまいます。逆に、透明性が確保されていれば、チーム内外のメンバーが共通の情報をもとに状況を正しく把握し、素早く調整できるようになります。
スクラムでは、状況に応じて最適化されていく 「創発的」 な性質があるため、何が起きているのかを実行者（開発チーム）と受け手（ステークホルダーやプロダクトオーナーなど）の双方が把握 していることが極めて重要です。後に登場するスクラムで定義された3つの作成物も、常に透明であることが前提になっています。それらの状態が不明瞭であれば、認識のズレから誤った判断を引き起こし、価値の低下やリスクの増大につながるおそれがあります。
さらに、透明性があるからこそ「検査」が可能になります。もし検査対象が曖昧なままであれば、検査そのものが意味を失い、誤解や手戻り、不要なやりとりを招く原因となってしまいます。
2. 検査（チェック）
チームが正しい方向に進んでいるか、こまめにチェックしてズレを早めに見つけます。
スクラムでは、チームの作成物（プロダクトバックログ・スプリントバックログ・インクリメント）や、ゴールに対する進捗状況が頻繁かつ熱心に検査されることが求められます。これは、潜在的な問題や望ましくない変化に早く気づくためです。
この検査のリズムを支えるために、スクラムには、チームの進み具合を確認し、より良くするための 「５つのイベント（定期的な場）」 があります。これらのイベントは単なる会議ではなく、検査と改善のチャンスを意図的に仕込んだ仕組みです。イベントによって、検査と適応が自然とできるようになります。
- スプリント（Sprint）
- スプリントプランニング（Sprint Planning）
- デイリースクラム（Daily Scrum）
- スプリントレビュー（Sprint Review）
- スプリントレトロスペクティブ（Sprint Retrospective）
3. 適応（すぐに変える）
適応とは、問題やズレに気づいたらすぐにやり方を調整することです。スクラムでは、「見つけた問題はすぐに対処する」 姿勢がとても大切になります。
たとえば、進め方がうまくいっていない、プロダクトの品質が低い、成果が受け入れられない、といったことが明らかになった場合、スクラムチームは、プロセスそのものや作っているものの一部を速やかに調整する責任があります。この「すぐに変える」ことができれば、問題の広がりやダメージを最小限に抑えることができます。
ただし、適応を機能させるには前提条件があります。
それは、チームや関係者が自分たちで判断し、自由に変えていい権限を持っていること（自己管理） です。もし関係者に権限がなかったり、トップダウンの指示待ち状態であれば、せっかく問題を検出しても、行動に移すことができず、スクラムの良さを活かせません。
スクラムでは、「検査によって新しいことを学んだら、すぐに適応する」という姿勢が求められます。
スクラムの価値基準
スクラムが成功するかどうかは、５つの価値基準を実践できるかどうか
スクラムがうまく機能するかどうかは、チームが5つの価値を実践できるかにかかっています。
この価値観は、チームの行動や判断のものさしになります。
スクラムの5つの価値(ものさし)
-
確約（コミットメント）
チーム全員が「ゴールを達成すること」と「お互いを支え合うこと」をしっかり約束（確約）します。価値のある成果を生み出すこと、品質を保つこと、経験主義を大切にするなどスクラムチーム全員がそれぞれ責任を持って取り組みます。 -
集中（フォーカス）
今やるべきことに集中し、スプリントのゴールに向けて全力で取り組みます。価値を作り出すことに注力し「今、最も重要なこと」にフォーカスする姿勢を大切にします。 -
公開（オープンネス）
チームの中でも外でも、作業の進捗や問題・課題をオープンに共有します。困難な状況も隠さず共有し、フィードバックを通じて互いに学び合い、改善に繋げます。 -
尊敬（リスペクト）
メンバー同士がお互いを一人の専門家として尊重し、信頼し合って協力します。異なる視点や専門性を尊重し、意見の違いにも礼儀と敬意を持って向き合います。 -
勇気（カーレッジ）
正しいことを選び、難しい問題にも向き合う勇気を持ちます。未知の領域への挑戦や、必要な方向転換、率直な意見共有、意見の対立に礼儀正しく向き合う勇気が求められます。
この価値基準がチームを強くする
スクラムの価値基準をチームが大切にし、実践できるようになると判断がぶれません。その結果、「チームが自律的に、変化に柔軟に対応しながら、継続的に価値を生み出す」 スクラムらしい動きができるようになります。
また、チームがスクラムのイベント（スプリント、レビューなど）を進めていく中で、この5つの価値を少しずつ身につけたり、深く理解したりしていくことが大切です。この価値基準がチーム全体や関わる人たちの中で自然に表現されているとき、スクラムの３つの柱である「透明性」「検査」「適応」が本当に意味のあるものとして機能します。結果として、チームの中に信頼と安心感が生まれます。
スクラムチーム
スクラムの基本単位は「スクラムチーム」
スクラムでは、作業の中心となる単位は「スクラムチーム」と呼ばれる少人数の自律したチームです。
スクラムチームの基本構成
スクラムチームには、3つの役割があります。
-
プロダクトオーナー（Product Owner）
作るべき価値や優先順位を決める人（ビジネス的な責任を持つ） -
スクラムマスター（Scrum Master）
チームがうまくスクラムを使えるように支援する人（進行役・改善役） -
開発者（Developers）
実際にプロダクトを作る人たち（エンジニア、デザイナー、QAなど含む）
この3つの役割を合わせた1つのチームが「スクラムチーム」です。
スクラムチームの特徴
-
少人数（10人以下が目安・7人前後が推奨）
敏捷性を維持するため十分な小ささが必要です。プロダクトオーナー、スクラムマスター、開発者を含めて10人以下であることで小回りがきいて、話し合いやすい規模になります。人数が多すぎる場合は、複数のスクラムチームに分けることも検討します。開発者は3〜9人程度、全体で7人前後が最も効果的とされています。 -
サブチームや上下関係がない
スクラムチームには役職や階層がありません。全員が対等で、一つの目標（プロダクトゴール）に向かって協力します。 -
自己管理型
「誰が・何を・いつ・どうやるか」は、スクラムチーム内で話し合って決めます。
上からの命令ではなく、チームで主体的に動くのが基本です。 -
機能横断型
チームの中に「必要なスキル」をすべて揃えており、1つのスプリントの中で価値を生み出せる状態です。 -
権限と責任がある
チームには「自分たちで作業を決めて進める権限」が組織から与えられています。
同時に、スプリントごとに価値ある成果（インクリメント）を完成させる責任もあります。
このように、スクラムチームは少人数でフラットな構造を持ち、自律的かつ柔軟に動けるチームです。必要なスキルを内包し、自分たちで計画し、実行し、成果を出していくことで、変化の激しい状況にも対応（適応）できる強さを持っています。
スクラムチームが担う活動の範囲
スクラムチームは「ただ作るだけのチーム」ではありません。
以下のような広い活動にも責任を持ちます
- ステークホルダー（関係者）とのコラボレーション
- 検証・保守・運用・実験・研修開発
- その他、プロダクトに関して必要となり得るすべての活動
必要なことはすべてチームの中で完結できる、そんな自立したチームを作ることです。
そのために1つの目標に向かって、スキルのある少人数が対等に協力し、自分たちで考えて動けるようにします。その活動に必要な権限が与えられることも大切です。
スクラムチーム全体が、スプリントごとに価値ある成果（インクリメント）を生み出すために必要なことにはすべて責任を持つ必要があります。
スクラムチームの3つの役割
先に述べたようにスクラムチームには、スプリントごとに価値ある成果（インクリメント）を生み出す責任があります。そのためにスクラムチームでは、それぞれに大切な役割を担うポジションが3つあり、それぞれ明確な責任が定義されています。
- 開発者（Developers）
- プロダクトオーナー（Product Owner）
- スクラムマスター（Scrum Master）
それぞれの役割や責任を順番に見ていきます。
開発者（Developers）
スクラムチームの中で、実際にプロダクトを作るメンバーたちのことです。つまり各スプリント（短い開発期間）において、利用可能なインクリメントを作成します。
エンジニアやデザイナー、テスターなど、役職名は関係なく、すべて「開発者」と呼ばれます。
開発者の主な責任
- スプリントバックログ（スプリントの計画）を作成する
- 完成の定義を忠実に守って、品質の高い成果物を作る
- スプリントゴール（スプリントの目標）に向かって、毎日計画を見直し、柔軟に対応する
- 開発者はそれぞれの専門性を活かしながら、お互いに協力し合い、チームとしての成果にも責任を持つ
開発者に必要なスキルはチームやプロダクトによってさまざまですが、「スプリントで価値ある成果（インクリメント）を作成すること」 が共通のゴールです。
プロダクトオーナー（Product Owner）
プロダクトオーナーは、「何を作るか」を決めてチームを導く人です。
価値のあるプロダクトを作るために、作業の優先順位を決め、チームに明確なゴールを伝えます。
プロダクトオーナーの主な責任
- プロダクトゴールを考え、明示的に伝える
- プロダクトバックログアイテムを作成し、明確に伝える
- プロダクトバックログアイテムを並び替える
- プロダクトバックログに透明性があり、見える化され、理解されるようにする
プロダクトオーナーは「一人」である必要があります。チームの中でも、関係者の中でも、最終判断をする責任ある人です。
そのため、組織全体でプロダクトオーナーの決定を尊重する必要があります。
関係者が意見を出したり、作業を手伝うこともできますが、最終決定はプロダクトオーナーが行います。
スクラムマスター（Scrum Master）
スクラムマスターは、チームがスクラムを正しく活用できるよう支援する人です。
進行役であり、コーチであり、チームを守る存在でもあります。
スクラムチームと組織に、スクラムを確立させることの結果に責任を持ちます。
スクラムマスターの主な責任
- スクラムの理解・実践をチームや組織に広める
- チームが自己管理できるようコーチングする
- 完成の定義に基づいたインクリメントの作成を支援する
- スクラムイベントが適切に行われるよう促す（進行手法や時間管理）
- チームの進行を妨げる障害を取り除くために動く
スクラムマスターが支援する対象
- 開発者：自己管理・価値ある成果に集中できるようサポート
- プロダクトオーナー：プロダクトゴールやバックログ管理の支援、関係者との調整
- 組織全体：スクラムの導入・理解促進、現場との橋渡し、障害の除去
スクラムマスターは「チームの上司」ではなく、スクラムチームと、より大きな組織に奉仕する真のリーダーである必要があります。
役割に関するよくある誤解
プロダクトオーナーはチームの上司ではない
プロダクトオーナーは何を作るのかを決める人ですが、どう作るかを命令したり、管理したりする上司ではありません。スクラムチームは自己管理型なため、自分達でやり方を決めて動きます。
プロダクトオーナーは、プロダクトの方向性や優先順位を示して、チームに明確なゴールを伝えるガイド役です。
スクラムマスターはプロジェクトマネージャーではない
スクラムマスターは管理者ではなく、チームを支える存在です。タスクを割り振ったり、進捗を細かくチェックするのではなく、チームが自立して動けるように環境を整えることを目的として動きます。障害を取り除いたり、スクラムを正しく実践するためのコーチやファシリテーター役です。
スクラムチームに上下関係はない
スクラムチームはフラットな関係です。全員がプロフェッショナルとして対等に尊重される存在なため上下関係はありません。スクラムでは全員がそれぞれの役割に応じた責任を持ち、役割に応じた専門性を発揮するよう集中します。上下関係ではなく、役割分担と協力が基本です。
スクラムイベント
スクラムイベントは検査と適応のための大切な機会
スクラムでは、チームがうまく協力して価値を生み出すために、4つの公式イベント（決まった場・タイミング） が用意されています。これらのイベントは、スクラムの作成物の検査と適応をするための大切な機会です。
スプリントはすべてのイベントの入れ物
スクラムでは、「スプリント」 という短い開発期間（1ヶ月以内）が基本の単位になります。このスプリントは、1つの小さく短なプロジェクトのようなもので、その中ではスクラムで行われる以下の4つの公式イベントが含まれています。
- スプリントプランニング（計画）
- デイリースクラム（毎日の確認）
- スプリントレビュー（成果の発表）
- スプリントレトロスペクティブ（ふりかえり）
つまり、スプリントはこれらのイベントの入れ物であり、この中でチームは計画・実行・確認・改善のサイクルを回していきます。
各イベントの目的は「検査と適応」
スクラムイベントは検査と適応のための大切な機会であるため。その最大の目的は、「今の状況をチェックして、必要ならすぐに方向を修正する」 こと。つまり検査と適応です。
- 作業や成果がプロダクトゴールに向かっているかを検査する
- もしズレていたら、その場で調整・改善する
このサイクルが毎スプリントごとに行われることで、ムダを減らし、柔軟な開発が可能になります。
イベントは「透明性」と「規則性」のための公式の機会でもある
スクラムにおける各イベントは、チームや関係者が状況を正しく把握できるように設計・ガイドされています。これによって、スクラムの三本柱の一つである透明性が保たれます。
また、イベントを決まったタイミング・場所で定期的に実施することで、チームに自然なリズムが生まれ、スクラムで定義されていない会議の必要性を最小限に抑えるためにも用いられます。その結果、余計な打ち合わせや調整の必要が減ります。これは規則性（一定のルールやパターン）のメリットです。
その結果、スクラムで定義されていない会議や追加の確認作業など、不要なコミュニケーションの発生を最小限に抑えることができます。
イベントを軽視するとスクラムの効果が落ちる
スクラムイベントをうまく活用しないと、検査と適応のチャンスを失い、問題に気づかないまま進んでしまうリスクがあります。
たとえば、デイリースクラムを省略すると、進捗共有や課題の発見が遅れ、問題が大きくなってから気づくということも起こりかねません。
スクラムは、複雑なソフトウェア開発において、チームが様々な問題を検査・適応しながら価値を生み出すためのシンプルで柔軟なフレームワークです。だからこそ、各イベントを単なる形式的な会議として扱うのではなく、プロダクトゴールを達成するためにチームが成長と改善を行うチャンスとして前向きに活用する意識が大切です。
スプリント
スプリントは、スクラムにおける開発サイクルの基本単位であり、まるでスクラムの 「心臓の鼓動」 のように、アイデアを価値へと変えていくリズムを生み出します。
スプリントの期間とリズム
一貫性を保つため、スプリントは、1ヶ月以内の一定の期間で行います。前のスプリントが終わり次第、次のスプリントが始まります。一貫したリズムを保つことで、予測可能性と継続的な改善が実現できます。
スプリントが定期的なリズムで繰り返されることで、チームはどれくらいのペースで進めるか（ベロシティ）を把握できるようになります。これにより、次のスプリントでどれだけのタスクがこなせそうかが見えてきます。この「見通しの立てやすさ」が、スクラムにおける予測可能性を高めます。
予測可能性が高まると、例えば以下のようなメリットがあります。
・チームや関係者の信頼関係が強まる
・ビジネス側も現実的な計画を立てやすくなる
・万が一の遅れや問題にも、早めに気づいて対処できる
こうしたメリットがあるからこそ、スプリントの期間を一定に保ち、規則的なリズムを保つことが大切です。
スプリント内で行うこと
先に紹介したようにスプリントの中では、プロダクトゴールを達成するために、4つの公式イベントを含むすべての作業が行われます。
- スプリントプランニング（計画）
- デイリースクラム（毎日の確認）
- スプリントレビュー（成果の発表）
- スプリントレトロスペクティブ（ふりかえり）
これらを通じて、継続的な検査と適応が実現され、アイデアが実際の価値（インクリメント）になります。
スプリント中のルールと注意点
スプリントでは、次のようなルールを守ることが求められます。
- スプリントゴールを危険にさらす変更は避ける
- 品質を下げない
- 必要に応じて、プロダクトバックログをリファインメント（洗練・改善）する
- 学びが深まることでスコープ（作業範囲）が見直されることがあり、プロダクトオーナーとの再交渉が必要になる場合がある
スプリントの目的と効果を高めるための期間
スプリントは、プロダクトゴールに向かって着実に進むための短い開発サイクルです。
この限られた期間の中で、チームはアイデアを形にし、進捗を検査し、必要に応じて方向を調整（適応） します。このプロセスにより、少なくとも月に一度はプロダクトの進み具合を見直すことが可能になります。
スプリントの期間が長すぎるとリスクや複雑さが増し、問題に気づくのが遅くなったり、プロダクトゴールがぼやけて、途中で方向性が変わってしまったり、ステークホルダーとの期待値のズレが大きくなります。結果として、価値のある成果につながりにくい可能性を高めます。
一方で、スプリントを短くすることで、学びのサイクルが増え、リスクやコストを抑えられます。早期に価値のあるフィードバックを得られたり、少しずつ価値を積み上げていく（インクリメンタル）ことで、チームの集中力とモチベーションを保ちやすくなります。短いスプリントは、スクラムが大切にしている２つの考え方（経験主義、リーン思考） にマッチしています。
進捗の見える化
スクラムでは、チームの課題や作業の進み具合などをチーム内外で正しく把握すること（透明性の確保） がとても重要です。進捗の見える化により、状況を早期に把握し、適切な判断や調整につなげることができます。通常、進捗状況を見える化するためには、以下のようなプラクティスがよく使われます。
- バーンダウンチャート
- バーンアップチャート
- 累積フロー図
これらのツールは、スプリントレビューやスプリントレトロスペクティブなどで、検査・分析の材料として活用される補助的な手段です。ただし、これらのチャートはあくまで判断のサポートツールであり、スクラムの根本にある経験主義（実際に起こったことに基づく判断）に代わるものではありません。
スクラムが扱うような変化が多くて複雑な問題に対応すべき環境では、未来を正確に予測することは困難です。だからこそ、すでに起こった事実だけが、信頼できる意思決定の土台となります。
スプリントの中止について
スプリントの中止は、例外的な判断であり、頻繁に起こるべきものではありません。しかし、スプリントの途中でスプリントゴール（今回達成したい目的）が意味を失ってしまった場合には、スプリントを中止することがあります。たとえば、以下のような状況が考えられます。
- プロダクトの方向性が大きく変更された
- ゴールとなる機能が市場や顧客から不要と判断された
- ビジネス上の優先順位が大きく入れ替わった
このような場合、スプリントを続けてもチームの努力が無駄になる可能性があるため、中止して計画を立て直す方が有益と判断されることがあります。
ただし、スプリントを中止できるのは、プロダクトオーナーだけです。
プロダクトオーナーは、スクラムチームの中で唯一、プロダクトの価値と方向性に責任を持つ役割を担っています。「今このゴールに向かって進み続けることに、まだ価値があるか？」というビジネス的な判断を下す権限と責任を持っています。
中止の際は、単に作業を止めるのではなく、なぜ中止に至ったのかをチームに共有し、次にどのように進むかを再計画することが重要です。このプロセスもまた、スクラムの核となる考え方である経験主義に基づいています。
スプリントプラニング
スプリントプランニングは、スプリントの最初に行う計画会議です。
スクラムチーム全員が集まり、今回のスプリントで「なぜ価値があり、どうやってできるのか？」を話し合います。ここで立てた計画は、スクラムチーム全体の共同作業によって作成されます。
スプリントプラニングを行う前に、プロダクトオーナーは、今回のスプリントで扱うべき最重要のプロダクトバックログアイテム（作業項目）と、それらがプロダクトゴール（プロダクトの将来あるべき姿）とどう関係しているかを明確にする準備をしておきます。
また、スプリントプランニングのタイミングで必要があれば、スクラムチーム以外の人（例えばその道の専門家やステークホルダー）にも参加してもらって、アドバイスをもらったり状況を共有したりすることも可能です。これにより、チームがより良い計画を立てやすくなります。
スプリントプランニングで話し合う3つのこと（トピック）
1. このスプリントは「なぜ」価値があるのか？
プロダクトオーナーが、今回のスプリントでどのようにプロダクトの価値や有用性を高めるかを提案します。そのうえで、スクラムチーム全体で協力して、このスプリントになぜ価値があるのかをステークホルダーに伝えるスプリントゴール（今回のスプリントで達成したい目的）を定義します。スプリントゴールは、スプリントプランニング終了時までに必ず確定しておきます。
2. このスプリントで「何ができる」のか？
開発者は、プロダクトオーナーとの対話を通じて、プロダクトバックログからプロダクトバックログアイテム（作業項目）を選びます。必要に応じて、その場でアイテムのリファインメント（細かく明確にする作業）を行うこともあります。
作業の規模を見積もる方法として、ストーリーポイントという単位を使うことがあります。これは実時間（例：3時間、1日など）で見積もる絶対見積もりではなく、過去の実績や、事前に用意したテンプレートと比較して見積もる相対見積もりです。
たとえば、「小さい機能追加は2ポイント」「中規模のバグ修正は3ポイント」「画面単位の作り込みは5ポイント」など、チームで定義したストーリーポイントのテンプレート（ストーリーポイントマトリクス）を用意しておくことで、よりブレの少ない見積もりが可能になります。
見積もりを行う際には、プランニングポーカーという手法がよく使われます。これはチームメンバーがそれぞれ見積もり値（たとえば1、2、3、5、8など）を書いたカードを出し合い、意見のばらつきがあれば理由を話し合うことで、認識のズレを解消しながら合意形成を目指します。
ストーリーポイントはあくまでチームごとの尺度なので、過去のスプリントでの実績（ベロシティ）を見ながら、「今回どれくらいのタスクをこなせそうか？」を判断する材料になります。
どれくらいの量をスプリント内で完了できるかを見極めるのは簡単ではありませんが、スプリントで検査と適応の経験を積み重ねて学習していくことで、過去の実績・現在のキャパシティ・完成の定義をもとに予測できるようになっていきます。
3. 選択した作業を「どうやって」成し遂げるのか？
開発者は、選んだ各バックログアイテムを、完成の定義を満たす形で完了させるには何が必要かを計画します。多くの場合、それぞれのアイテムを1日以内に終わるくらいの小さなタスクに分解します。この分解・具体化の仕方は、開発者の裁量に任されています。このようにして選ばれた作業アイテムと、それをどうやって進めるかという計画をまとめたものを スプリントバックログと呼びます。
スプリントプランニングの所要時間（タイムボックス）
スプリントの長さが1ヶ月の場合、最大で8時間までをスプリントプランニングに使うことができます。
スプリントの期間が短い場合は、それに応じてプランニングの時間も短くなります。2週間スプリントなら、プランニングはおおよそ4時間以内が目安です。タイムボックスが守れない場合は、なぜ守れないのかを考えて対処します。
タイムボックスの例
| スプリントの長さ | プランニングの最大時間（タイムボックス） |
|---|---|
| 1週間 | 最大 2時間 |
| 2週間 | 最大 4時間 |
| 3週間 | 最大 6時間 |
| 4週間 | 最大 8時間 |
デイリースクラム
デイリースクラムは、開発者がスプリントゴールの達成に向けて進捗を確認・調整するための15分間のイベントです。スプリント中は、毎日、同じ時間・同じ場所で実施することが推奨されており、日々の複雑さを減らし、チームのリズムを整えるのに役立ちます。
15分を超えてしまう場合、チームの話し方や構成を見直す必要があります。
デイリースクラムの目的
デイリースクラムの目的は、スプリントゴールに対して計画された今後の作業を検査・調整しながら、
必要に応じてスプリントバックログを見直す（適応） ことです。
この場を活用することで、チームは一体感を保ちつつ、計画的に前へ進むことができます。
誰が参加する？
デイリースクラムは、スクラムチームの開発者が中心となって行います。
ただし、プロダクトオーナーやスクラムマスターが深く開発作業に参加している場合は、開発者の一員として参加します。
進め方と自由度
開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの１日の作業の実行可能な計画を作成する限り。この15分間をどう使うかを自分たちで決めることができます。例えば、毎回同じフォーマットで話してもよいし、課題ベース・ボードベースでもかまいません。
必要な構造とやり方は開発者が自由に選択することができます。
大切なのは、「スプリントゴールに集中し、今日何をやるかの実行可能な計画を立てること」 です。この自由度が、集中を生み出し、自己管理を促進します。
デイリースクラムがもたらす効果
デイリースクラムは、チーム内のコミュニケーションを円滑にします。円滑になることで、障害や課題を早く発見でき、迅速な意思決定が可能になります。結果として、デイリースクラム以外の会議を減らすことができ作業に集中することができます。
ただし、開発者が作業計画を調整するのは、デイリースクラムの場だけに限りません。
チームは1日の中でも必要に応じて、より深い議論や再調整を随時行います。
日々のチェックポイントとしての役割は、デイリースクラムが担っているという点が重要です。
スプリントレビュー
スプリントレビューは、スプリントの成果を確認し、今後の方向性をステークホルダー（関係者）と一緒に考えるためのイベントです。スクラムチームとステークホルダーが集まり、今回のスプリントで何を達成できたのかを共有し、プロダクトゴールに対してどれくらい前進したのかを一緒に検討します。
このイベントを通じて、開発チームだけでなくビジネス側や関係者も状況を把握できるようになり、今後のプロダクトに対する意思決定がスムーズに行えるようになります。
スプリントレビューで話し合うこと
スプリントレビューでは、スクラムチームとステークホルダーが一緒に集まり、今回のスプリントで何が達成されたのかを確認・議論します。ここでは、実際に完成の定義を満たした成果物（インクリメント）をチームが示し、その内容を具体的に説明します。
あわせて、プロダクトや周辺環境にどのような変化があったのかも共有されます。たとえば、市場の動向、技術の進化、ユーザーからのフィードバックといった、スプリント中に得られた新たな情報が対象です。
それらの成果や変化を踏まえて、今後チームが何に取り組むべきかを一緒に検討し、必要に応じてプロダクトバックログの見直しや優先順位の再調整が行われます。
このように、スプリントレビューは単なる「成果発表会」ではなく、参加者全員でプロダクトの未来について協力して考える対話と共創の場として位置づけられています。
スプリントレビューの所要時間（タイムボックス）
スプリントの長さが1ヶ月の場合、スプリントレビューには最大で4時間までを使うことができます。
スプリントの期間が短い場合は、それに応じてスプリントレビューの時間も短くなります。
たとえば、2週間スプリントであれば、レビューの所要時間はおおよそ2時間以内が目安になります。
もしタイムボックスを超えてしまうようであれば、「準備不足だったのか？」「議論の進め方に課題があったのか？」など、なぜ時間内に収まらなかったのかをふり返り、次回に向けて改善することが大切です。
タイムボックスの例
| スプリントの長さ | レビューの最大時間（タイムボックス） |
|---|---|
| 1週間 | 最大 1時間 |
| 2週間 | 最大 2時間 |
| 3週間 | 最大 3時間 |
| 4週間 | 最大 4時間 |
スプリントレトロスペクティブ
スプリントレトロスペクティブは、スプリントの最後に行うふりかえりのイベントです。
その目的は、スクラムチームの働き方やプロセスを見直し、品質と効果を高めるための改善策を計画することです。
このイベントでは、スクラムチームが集まり、今回のスプリントがどのように進んだかを振り返ります。
レトロスペクティブで話し合うこと
スプリントレトロスペクティブでは、スクラムチームが一堂に会し、今回のスプリントの進め方や働き方を多角的にふりかえります。
具体的には、個人とチームの関わり方（相互作用）、作業の進め方や使用したツールの有効性、
プロセスがどれほど効果的だったか、そして「完成の定義」に対する理解と実践状況について話し合います。
また、スプリントの中で立てた仮説や前提が正しかったかどうかを検証し、何がうまくいき、どのような問題が発生し、それらがどう解決されたか（またはされなかったか）も重要なふりかえりポイントです。
表面でなく本当の原因を探る
表面的な現象だけではなく、チームを迷わせた思い込みや仮説の正否を探り、本当の原因を明らかにすることが大切です。議論を通じて、表面的な出来事にとどまらず、チームが無意識に抱えていた思い込みや仮説の誤りを明らかにし、問題の真因を探ることが求められます。
根本的な原因に気づくことで、同じ失敗の繰り返しを防ぎ、より効果的なチーム運営につなげることができます。
実行可能な改善に落とし込む
レトロスペクティブの目的はふりかえることそのものではなく、そこから得られた気づきをもとに、チームの品質と効果を高める具体的な改善策を決めることです。
特に、影響の大きいものやすぐに実行できる改善案は優先的に取り組むべきです。
場合によっては、その改善内容を次のスプリントのスプリントバックログに追加し、実行計画に組み込むこともできます。
レトロスペクティブの所要時間（タイムボックス）
スプリントレトロスペクティブの所要時間は、スプリントの長さに応じて調整されます。
スプリントが1ヶ月の場合、レトロスペクティブのタイムボックス（最大所要時間）は3時間とされています。
スプリント期間が短ければ、それに応じてレトロスペクティブの時間も短く設定するのが一般的です。
たとえば、2週間スプリントなら1.5時間以内を目安にするとよいでしょう。
時間が足りない、または長すぎると感じる場合は、チームで進め方を見直し、「何を目的に、どこに時間を使うか」を明確にすることが大切です。
タイムボックスの例
| スプリントの長さ | レトロスペクティブの最大時間（タイムボックス） |
|---|---|
| 1週間 | 最大 45分 |
| 2週間 | 最大 1.5時間（90分） |
| 3週間 | 最大 2.25時間（135分） |
| 4週間 | 最大 3時間 |
スクラムの作成物
スクラムでは、開発プロセスの中で作成物と呼ばれる3つの重要なアウトプットが定義されています。
これらの作成物は、作業の進捗や価値を明確に見える化（透明性の最大化）するために設計されています。作成物をチェックする人（チームやステークホルダー）が、同じ基準で判断・適応できるようにすることがスクラムにおけるポイントです。
作成物に含まれる「確約（コミットメント）」
各作成物には、透明性と集中力を高めるための確約（コミットメント） が含まれています。
これは、スクラムチームがどこに向かっているのか、どのくらい進んでいるのかを判断する基準となります。
| 作成物 | 確約（コミットメント） |
|---|---|
| プロダクトバックログ | プロダクトゴール |
| スプリントバックログ | スプリントゴール |
| インクリメント | 完成の定義 |
これらの確約は、スクラムチームとステークホルダーが経験主義に基づいて判断し、行動するための指針となります。また、スクラムの価値基準（尊敬・勇気・集中・公開・確約）を強化する土台にもなります。
プロダクトバックログ
プロダクトバックログは、プロダクト（製品やサービス）を改善・進化させるために必要な作業やアイデアを一覧化したリストです。
これはスクラムチームが行うすべての作業の唯一の情報源となります。
このリストは、必要に応じて追加・変更・削除される「創発的」なものです。
また、優先順位が付けられており、価値の高いものから順に取り組めるように並べられています。
リファインメント（細かく明確に洗練する）の重要性
スプリントプランニングで作業を選ぶ際、プロダクトバックログアイテムは選択できる状態になっている必要があります。そのために、スクラムチームはリファインメントという作業を日常的に行います。
リファインメントとは、バックログアイテムをより小さく、具体的に、理解しやすく分割・定義していく活動です。これにより、以下のような情報が明確になり透明性を獲得することができます。
- 説明（どんなことをするのか）
- 並び順（優先度）
- サイズ（どのくらいの作業量か）
- その他の詳細（作業領域によって異なる）
開発者とプロダクトオーナーの役割
開発者は、それぞれの作業項目の規模や難易度の見積もりに責任を持ちます。
プロダクトオーナーは、必要に応じて開発者にトレードオフ（優先順位や選択肢のバランス）について情報提供や支援を行います。
プロダクトゴール：バックログに対する「確約」
プロダクトバックログには、1つの「プロダクトゴール」が設定されます。
これはプロダクトの将来的な目標や到達したい姿を表しており、スクラムチームの長期的な活動のターゲットになります。
プロダクトバックログに含まれる各アイテムは、このプロダクトゴールを達成するために必要な「何をやるか」を示すものです。
このゴールは、スクラムチームの活動の中心であり、チームはひとつのプロダクトゴールを達成する（または放棄する）までは、次のゴールに進むことはできません。
プロダクトとは？
ここでいう「プロダクト」とは、価値を提供する手段のことを指します。
これは以下のように多様な形をとります。
- サービス
- 物理的な製品
- 抽象的なソリューションなど
いずれも、明確な境界、既知のステークホルダー（関係者）、明確に定義されたユーザーや顧客を持っていることが特徴です
プロダクトゴールとプロダクトバックログの関係
プロダクトゴールは、プロダクトバックログの中に含まれている確約（コミットメント）です。
バックログに記載されたひとつひとつのアイテム（作業項目）は、このプロダクトゴールを達成するために「何をするか（what）」を定義するものとなります。
スプリントバックログ
スプリントバックログは、現在のスプリントでチームが取り組む作業計画をまとめたものです。
具体的には以下の3つで構成されています。
- スプリントゴール（なぜやるのか）
- スプリントで取り組むプロダクトバックログアイテム（何をやるのか）
- それらを完了させるための実行可能な計画（どうやってやるのか）
このバックログは、開発者自身が作成・管理する、開発者のための計画ツールです。
リアルタイムで更新される作業リスト
スプリントバックログは、スプリント期間中も学びや状況の変化に応じて更新される生きた計画です。
開発者がスプリントゴールを達成するために行う作業は、随時このリストに反映されていきます。
そのため、スプリントバックログはデイリースクラムなどで進捗を確認・調整できる程度の詳細さを持っている必要があります。
スプリントゴール：バックログに対する「確約」
スプリントバックログに含まれる確約（コミットメント）は、スプリントゴールです。
スプリントゴールとは、そのスプリントの唯一の目的を明確にするものです。
これは、開発者がスプリント期間中に目指す方向性であり、チームの一貫性・集中力・団結を生み出す基準にもなります。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加されます。
柔軟な対応も可能
開発者はスプリント中、スプリントゴールを意識しながら作業を進めます。
もし作業の内容が当初の予想と大きく異なった場合は、プロダクトオーナーと相談のうえ、スプリントバックログのスコープ（範囲）を調整することも可能です。
ただし、スプリントゴールそのものを変えないよう注意しながら調整します。
インクリメント
インクリメントとは、スプリントの中で完成された「動く成果物」のことです。
これはプロダクトゴールに向かって前進するための、目に見えるステップとも言えます。
スプリントでのインクリメントの扱い
スプリントでは、複数のインクリメントを作成することも可能です。完成したインクリメントは、通常スプリントレビューでまとめて提示されます。これにより、チームとステークホルダーが現状を検査・適応できるようになります。
ただし、スプリントが終わる前に価値を届けられる場合は、インクリメントを早めにステークホルダーに提供することも可能です。
スプリントレビューは「価値をリリースするための関門」ではありません。必要に応じて、スプリント中でもリリースして構いません。
インクリメントが成立する条件
インクリメントとして扱うためには、「完成の定義」を満たしている必要があります。
この定義を満たさない作業は、インクリメントとは認められず、あとで扱うためにプロダクトバックログに戻すことになります。
インクリメントの積み重ねと検証
新しいインクリメントは、これまでに完成したすべてのインクリメントに追加されます。
すべてのインクリメントは一貫して連携し、動作することが求められます。
そのために、徹底的な検証（テスト）が必要です。
また、インクリメントを価値として提供するには、実際に「使える状態（利用可能）」にすることが前提となります。
確約（コミットメント）：完成の定義
完成の定義とは、インクリメントが「完成」と認められるための品質基準を示した正式な定義です。
プロダクトバックログアイテムがこの定義を満たしたとき、初めて「インクリメントが誕生した」と見なされます。
完成の定義があることで、作業が完了しているかどうかをチーム全員が共通認識として持てるようになり、透明性が保たれます。
完成の定義を満たしていないものは、リリースもレビュー提示もできません。
完成の定義は誰がどう決める？
組織で統一された完成の定義がある場合、すべてのスクラムチームがそれを最低限守る必要があります。
組織に共通ルールがない場合は、スクラムチームの 開発者（Developers） が、自分たちのプロダクトに適した完成の定義を作成します。
複数のスクラムチームが同じプロダクトに関わる場合は、関係するすべての開発者が協力し、共通の完成の定義を作成・共有する必要があります。
最終的に、この完成の定義を守りながら作業を進めるのは、開発者自身の責任です。プロダクトオーナーやスクラムマスターは、そのプロセスを支援したり整えたりする役割ですが、定義の作成そのものは開発者が主導します。
最後に
以下すべて引用です。
スクラムは無料であり、本ガイドで提供されるものである。
ここで概要を述べたように、スクラムフレームワークは不変である。
スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。
すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れものとして機能するものである。
用語集
| 英語（English） | 日本語（Japanese） | 定義（簡単な説明） |
|---|---|---|
| General Terms | 一般用語 | |
| Scrum | スクラム | 複雑な問題に対応するためのシンプルなチームの働き方に関するフレームワーク |
| Theory | 理論 | スクラムの背景にある考え方や原則 |
| Empiricism | 経験主義 | 経験を通じて学び、改善するという考え方 |
| Lean Thinking | リーン思考 | 無駄を省き、本質に集中するという考え方 |
| Transparency | 透明性 | 単純にいうと見える化。状況や進捗が誰から見ても分かる状態 |
| Inspection | 検査 | 単純にいうとチェック。状況を定期的に見直して確認すること |
| Adaptation | 適応 | 単純にいうとすぐに変える。問題に気づいたときにやり方を変えること |
| Roles | 役割 | |
| Scrum Team | スクラムチーム | スクラムの基本単位。プロダクトを開発する少人数の自立したチーム |
| Scrum Master | スクラムマスター | スクラムを正しく運用できるよう支援する人 |
| Product Owner | プロダクトオーナー | プロダクトの価値最大化に責任を持つ人 |
| Developers | 開発者 | 実際にプロダクトを作るメンバー |
| Artifacts | 作成物 | |
| Product Backlog | プロダクトバックログ | プロダクトに必要な作業の一覧（要求リスト） |
| Sprint Backlog | スプリントバックログ | スプリントで実施する作業の一覧 |
| Increment | インクリメント | 完成の定義を満たし、スプリントの成果として完成したプロダクトの一部 |
| Events | イベント | |
| Sprint | スプリント | 時間を区切って作業する短い開発サイクル（通常1～4週間） |
| Sprint Planning | スプリントプランニング | スプリント開始時の計画会議 |
| Daily Scrum | デイリースクラム | 毎日の短い進捗確認ミーティング |
| Sprint Review | スプリントレビュー | スプリントの成果を関係者に見せてフィードバックを得る場 |
| Sprint Retrospective | スプリントレトロスペクティブ | スプリントの振り返りと改善の場 |
| Misc | その他 | |
| Definition of Done | 完成の定義 | 作業が「完了」と言える条件の明確な基準 |
Discussion