プロダクト開発におけるスクラム（）は複雑な問題への適応型ソリューションをチームで開発し価値を生み出すための軽量級フレームワークである"スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。" scrum guide 2020 JP。
概要 複雑な問題に対する完璧なソリューションを一度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。
スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである"スクラムとは次の環境を促進するため ... 1. ... 問題に対応するための作業をプロダクトバックログに並べる。 2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。 3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。 4. 繰り返す。 スクラムはシンプルである。" scrum guide 2020 JP。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。
スクラムはチームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。
背景
複雑な問題と適応型ソリューション 複雑な問題は難しい。もし1回で問題への完璧な解決策/ソリューションを提供できれば大きな価値を提供できる。しかし「完璧に計画されたソリューション」は往々にして不完全に終わる。そうでないやり方の1つが適応型ソリューション（）である。すなわち最初は不完全だが段階的に学び改善されていくソリューションである。
ソリューション開発と目的 ソリューションの別名はプロダクトである。なぜならプロダクトは価値を提供する手段（ソリューション）だからである"プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド.。例えばカップラーメンというプロダクトは空腹という問題を解決し満腹という価値を提供するソリューションである。プロダクトはあくまで手段であり、価値こそが目的である。
プロダクトは人の手によって開発される。プロダクトが手段ということは、プロダクト開発もまた手段である（手段を生み出す手段）。言い換えれば、ソフトウェア開発は出力（output）としてプロダクトを生み出し、プロダクトは利用された成果（outcome）として価値を生み出す。スクラムはソリューション/プロダクト開発の方法論である"スクラムとは、複雑な問題に対応する適応型のソリューションを通じて … 軽量級フレームワークである。" scrum guide 2020 JP。ゆえにスクラムの目的は（ソリューションを生み出すことではなく）生んだソリューションを介して価値を生み出すことである"スクラムとは ... 価値を⽣み出すための軽量級フレームワークである。" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド.。
軽量フレームワーク 適応型ソリューションを開発するために厳密で重厚なプロセス・手法を用意することも可能だが、スクラムは異なるアプローチをとる。スクラムは最低限で軽量な工程の枠組み（プロセスフレームワーク）のみを提供するScrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. SCRUM GUIDES 2017。すなわちスクラムは開発の流れ、ポイントとなるイベントのみを定義する"スクラムフレー ムワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。... スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。" scrum guide 2020 JP。実際のソリューション開発ではスクラムフレームワークに則った上で全体の具体的手順を構築する。このようにスクラムは軽量級フレームワークである。
歴史 1986年に野中郁次郎と竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載される。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum（スクラム）」として紹介した。
野中、竹内の論文に着想を得たJeff Sutherland、John Scumniotales、Jeff McKenna が、1993年にラウンドトリップ・エンジニアリング（一種の反復型開発）を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築し、実践したのがソフトウェア開発手法としてのスクラムの最初である。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。同じころ、ケン・シュエイバーが自社 (ADM) でのソフトウェア開発にこの手法を用いた。スクラムは産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としてのスクラムの元となった。
このプラクティスは2003年に『アジャイルソフトウェア開発スクラム』としてまとめられた。
スクラムの定義と解説はスクラムの創設者Ken SchwaberとJeff Sutherlandによる「The Scrum Guide」にまとめられておりScrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum. SCRUM GUIDES 2020-08-16閲覧、スクラムの改良に伴ってこのガイドも更新されている。
スクラムは適応型ITソリューションすなわち適応型ソフトウェアを開発する（ソフトウェア開発）ために発明され、のちにアジャイルソフトウェア開発手法の1つに分類された。現在ではソフトウェアに限らずあらゆる適応型ソリューション/プロダクトの開発に適用される"スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。" scrum guide 2020 JP。
背景理論 スクラムは経験主義に基づいている。スクラムでは、小さい実践を繰り返して経験を生みその経験に基づいて判断し知識を得ることで、製品の将来をより正確に予測し不確実性を制御できるという哲学をもっているScrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. SCRUM GUIDES 2017。これは綿密かつ巨大な計画で将来を事前に見通そうとする態度と対比される。
この哲学に基づいた実践をおこなうために、スクラムには3つの柱があるThree pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. SCRUM GUIDES 2017。
透明性/transparency 検査/inspection 適応/adaptation
スクラムでは透明性によりチーム全体に現状が正しく共有され、製品が頻繁に検査されて異常が素早く見つかり、それに適応して製品・プロセスが修正されることを期待する。これが実現できればチームへ経験が蓄積し、製品はより良い方向へ向かう。
検査 検査（）は現状把握、すなわち目標と現状の比較・評価である。検査により開発の進行に伴う変化・問題を検出する"これは、潜在的に望ましくない変化や問題を検知するためである。" scrum guide 2020 JP。検査の目的は適切な方向への適応である"検査によって適応が可能になる。適応のない検査は意味がないとされる。" scrum guide 2020 JP。目標が示されていないと比較対象がいないため、十分な検査がおこなえない（例: 発生した問題は検査できても方向性のズレに気づけない）。ゆえに目標の透明性が良い検査の前提となっている"Transparency enables inspection. Inspection without transparency is misleading and wasteful." Scrum Guide 2020.。PDCAサイクルの Check 段階に相当する。
スクラムチーム スクラムチーム（）はスクラムの基本単位となる小さなチームである"スクラムの基本単位は、スクラムチームという⼩さなチームである。" scrum guide 2020 JP。
スクラムチームはスポーツチームのように機能しなければならない。各メンバーは高い専門性を持ちながら自らのポジションに拘泥せず、1つのゴールを目指し全員が1つのチームとして協力する。つまり専門分野（例: マネジメント、エンジニアリング、デザイン）をもつ様々なプロフェッショナルが分野にとらわれず、1つのプロダクトゴールへ焦点を合わせプロダクト開発を行うチームがスクラムチームである"⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。... スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。" scrum guide 2020 JP。
スクラムチームはプロダクトゴール達成に必要な全ての活動を責務とする（必要な権限とそれを行使する責任を持つ）"The Scrum Team is responsible for all product-related activities" scrum guide 2020。すなわち開発において、どのメンバーが何（what）をいつどのように（how）行うかはスクラムチーム自身が決定し自己管理する"⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。... 2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できる" scrum guide 2020 JP。価値ある成果物を生み出す（プロダクトゴールを達成する）ことに関して、チームとしてステークホルダーに対する説明責任を負う例えば完成したプロダクトが売れなかった場合、そうなった経緯を社長へ正しく報告する責任がある。チームの失敗はチームとして責任を負う。"The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." scrum guide 2020。
スクラムチームは適応型プロダクトを開発する。ゆえに適応に必要な速度を担保できるサイズの小ささが必要であり、1チーム10人以下が推奨される"スクラムチームは、敏捷性を維持するための⼗分な⼩ささ ... があり、通常は 10 ⼈以下である。"。
スクラムチームには以下の3つの明確な役割・責任が定義される。
プロダクトオーナー プロダクトオーナー（）は製品の総責任者である。 顧客の意思の代表としての役割を担う。 ビジネスの視点（ROI等）においてプロジェクトに問題がないことを保障する役割を持つ。 顧客の要望をプロダクトバックログに優先順位を付けて反映させる。
スクラムマスター スクラムマスター（）はスクラムフレームワークが正しく適用されていることを保証する役割である。権限としては間接的である。主な作業は、チーム内外の組織間調停(ファシリテーション)と外部妨害を対処することとされる。従来のプロジェクトマネージャがこの役割を担うことが多いが、プロジェクトそのものを管理するわけではない。
開発者 開発者（）は各スプリントにおいて、利⽤可能なインクリメントの あらゆる側⾯を作成することを確約する役割を担う。開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。
方法論 スクラムは経験主義（透明性・検査・適応）を実現するために、以下の作成物とイベントを定義する"Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required." Scrum Guide 2020.。これらのフレームワークに則ることでチームとプロダクトの透明性が向上し、正しい検査が定期的におこなわれ"Events are used in Scrum to create regularity" Scrum Guide 2020.、素早い適応がおき、良いプロダクトが生み出される。 +表. 検査と適応の機会イベント/頻度頻度検査対象確約/検査基準適応反映先デイリースクラム日次"The Daily Scrum ... is held ... every working day of the Sprint." Scrum Guide 2020.日次進捗"Daily Scrum ... inspect progress" Scrum Guide 2020Spゴール"Daily Scrum ... inspect progress toward the Sprint Goal" Scrum Guide 2020.Spバックログ"Daily Scrum ... adapt the Sprint Backlog" Scrum Guide 2020.Spレビューn週次Sp成果"Sprint Review ... inspect the outcome of the Sprint" Scrum Guide 2020（インクリメンツ）Pdゴール"Sprint Review ... progress toward the Product Goal is discussed." Scrum Guide 2020Pdバックログ"Sprint Review ... The Product Backlog may also be adjusted to meet new opportunities." Scrum Guide 2020 スクラムの作成物は1つの確約（）をもつ。目標たる確約を明示することで進捗測定すなわち検査が可能になる"Scrum Artifacts ... contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured ... These commitments exist to reinforce empiricism" Scrum guide 2020。プロダクトバックログにおけるプロダクトゴール、スプリントバックログにおけるスプリントゴール、インクリメントにおける完成の定義がそれぞれ検査基準となる確約である"Each artifact contains a commitment ... : For the Product Backlog ..." Scrum Guide 2020.。確約はプロダクトの理想状態を示しており、開発者にこの達成を求める（ゆえに検査される）。プロダクトそのもの状態を明示された検査対象とすることで、逆説的に、スクラムは開発過程の大きな自由度を開発者にもたらしている"Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it." Scrum Guide 2020.（「この状態が目標だ、完成度を検査する。作り方は君に任せる」という方式、ミッション・コマンド）。
プロダクトゴール プロダクトゴールはプロダクトの将来の状態である"プロダクトゴールは、プロダクトの将来の状態を表している。" scrum guide 2020 JP"The Product Goal describes a future state of the product" scrum guide 2020。すなわち将来のプロダクト利用が生み出すべき価値である。ゴールは評価可能であり、全員に共有され、一度に1つのみ設定される。
プロダクトゴールはプロダクトの目標である。これによりスクラムチームはプロダクトゴールの実現を目標として計画を立案できる"プロダクトゴールは、スクラムチームの⻑期的な⽬標である。... プロダクトを全体的なプロダクトゴールに近づける" scrum guide 2020, JP。プロダクトゴールは評価可能である"優れたプロダクトゴールは、達成に努めるものであり、測定可能であり" Ben Linders, Ken Schwaber, Jeff Sutherland. (2020). スクラムガイド 2020の変更点: Ken Schwaber氏とJeff Sutherland氏とのQ＆A. InfoQ.。これによりプロダクトの進捗が検査可能になり、プロダクトが適応できる"スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。… 各作成物には、透明性と集中を⾼める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。・プロダクトバックログのためのプロダクトゴール … プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり" scrum guide 2020 JP。プロダクトゴールはチームとステークホルダーに共有される"優れたプロダクトゴールは…スクラムチームとそのステークホルダに可視化されます。" Ben Linders, Ken Schwaber, Jeff Sutherland. (2020). スクラムガイド 2020の変更点: Ken Schwaber氏とJeff Sutherland氏とのQ＆A. InfoQ.。これによりチームは提供すべき価値を把握して「なぜ（why）これを開発するのか」を理解でき、目的意識を持った自律的な開発が可能になる"プロダクトゴールは、プロダクトバックログのコンテキストを提供します。これは、プロダクトバックログが存在する「なぜ (Why)」と、スクラムチームが作業を行っているなぜ (Why) と考えることができます。… なぜチームにバックログを与えているのかについてのビジョンがないプロダクトオーナに大きな問題があると言いました。これは、チームにとって重要な意欲を削ぐものです。" Ben Linders, Ken Schwaber, Jeff Sutherland. (2020). スクラムガイド 2020の変更点: Ken Schwaber氏とJeff Sutherland氏とのQ＆A. InfoQ.。プロダクトゴールは一度に1つのみ設定される。これによりチームは単一のゴールへ向け集中できる"スクラムチームは ... ⼀度にひとつの⽬的（プロダクトゴール）に集中している" scrum guide 2020 JP。
例えばタクシーサービスが掲げる「顧客は平均7分でタクシーを捕まえられる」は定量評価可能なユーザー体験であり、プロダクトゴールに相応しい。
プロダクトバックログ プロダクトバックログ（）はプロダクトが目指す姿とそうなるための要素の一覧である。プロダクトバックログはプロダクトゴールとプロダクトバックログアイテムからなる"プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。" scrum guide 2020, JP。
プロダクトバックログアイテム（PBI）はプロダクトゴールを達成する「何か（what）」の定義であり、理想形に必要な要素を示す。PBIはコストと顧客価値が見積もられ優先順位をもつ。プロダクトに対する要求は常に変化する。例えば変化を引き起こす物事としてプロダクトの利用・成長、市場からのフィードバック、ビジネス要求・環境の変化、技術の登場などがあるAs a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. SCRUM GUIDES 2017Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog. SCRUM GUIDES 2017。プロダクトに対する要求の変化に対してプロダクトバックログは「適応」する。すなわちプロダクトバックログの項目は要求の変化に応答して変化する。プロダクトバックログを更新していくことで、製品は常に適切で競争力をもち便利な方向へ開発されていくRequirements never stop changing, so a Product Backlog is a living artifact. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. SCRUM GUIDES 2017。
プロダクトバックログの最終的な決定と責任はプロダクトオーナーにあり尊重される。そこに至るまでのバックログへの関わり方（オーナー主体かチーム取り組みか）はプロジェクト次第である。またPBIがもつべき具体的項目は各プロジェクトごとに定義される（スクラムはあくまでフレームワークである）。
プロダクトバックログリファインメント スプリント期間中、チームはプロダクトバックログの健全性を保つための会議を開く。プロダクトバックログの健全性を示す指標として、INVESTが用いられることが多い。
インクリメント インクリメント（）はプロダクトゴールへの一歩となる、具体的な成果物である"An Increment is a concrete stepping stone toward the Product Goal." scrum guide 2020。インクリメント（増分）を積み上げていくことで理想形のプロダクトが実現する。インクリメントの原料はPBIである。いわばアイデアであるPBIを開発者が実装することでインクリメントとなる。作業中の途中産物はインクリメントではなく、"完成の定義"を満たした段階でインクリメントとなる"プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。... 完成の定義を満たさない限り、作業をインクリメントの⼀部と⾒なすことはできない。" scrum guide 2020 JP。インクリメントはリリース可能である"スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。 ... プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。" scrum guide 2020 JP。
完成の定義 完成の定義（）はPBIの完成品が満たすべき品質基準である。
スプリント スプリントはアイデアを価値に変換する、すなわち実際に開発が行われる工程である"スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わる。" scrum guide 2020 JP。
スクラムは適応型プロダクトを開発する。つまりプロダクトは短期間で開発・実践投入・学習・適応を繰り返す必要がある。開発工程として計画・開発・日次見直し・レビュー・調整を含んだ一定期間の区切りがスプリント（）である。スプリントを設定することでプロダクトが目標とする価値へ定期的に適応するように誘導される"スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。" scrum guide 2020 JP。素早い適応のためにスプリント長は1ヶ月以下に設定される"スプリントは 1 か⽉以内の決まった⻑さとする。" scrum guide 2020 JP。
スプリント内では、決まった順序は存在しない。必要に応じて、プロダクトバックログの項目を開発し、まとめ、レビューする。また、項目によっては、単にレビューと調整だけで済む場合もある。どのように開発されるかは、そのバックログ項目の内容によるが、プロダクト全体として、インクリメンタル／イテレーティブに開発されることが多い。
スプリントでは検査と適応のために以下の4つのイベント（プロセス）を組み合わせて用いる"スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。" scrum guide 2020 JP。
スプリントプランニング: スプリント期間の最初に行われる。スクラムチームでスプリントバックログを生成する。この過程でチームメンバー間の認識差異がないことを最終確認する。