スクラム (ソフトウェア開発)

プロダクト開発におけるスクラム（英: scrum）は複雑な問題への適応型ソリューションをチームで開発し価値を生み出すための軽量級フレームワークである。 複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。 スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。 スクラムはチームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。 複雑な問題は難しい。もし1回で問題への完璧な解決策/ソリューションを提供できれば大きな価値を提供できる。しかし「完璧に計画されたソリューション」は往々にして不完全に終わる。そうでないやり方の1つが適応型ソリューション（英: adaptive solutions）である。すなわち最初は不完全だが段階的に学び改善されていくソリューションである。 ソリューションの別名はプロダクトである。なぜならプロダクトは価値を提供する手段（ソリューション）だからである。例えばカップラーメンというプロダクトは空腹という問題を解決し満腹という価値を提供するソリューションである。プロダクトはあくまで手段であり、価値こそが目的である。 プロダクトは人の手によって開発される。プロダクトが手段ということは、プロダクト開発もまた手段である（手段を生み出す手段）。言い換えれば、ソフトウェア開発は出力（output）としてプロダクトを生み出し、プロダクトは利用された成果（outcome）として価値を生み出す。スクラムはソリューション/プロダクト開発の方法論である。ゆえにスクラムの目的は（ソリューションを生み出すことではなく）生んだソリューションを介して価値を生み出すことである。 適応型ソリューションを開発するために厳密で重厚なプロセス・手法を用意することも可能だが、スクラムは異なるアプローチをとる。スクラムは最低限で軽量な工程の枠組み（プロセスフレームワーク）のみを提供する。すなわちスクラムは開発の流れ、ポイントとなるイベントのみを定義する。実際のソリューション開発ではスクラムフレームワークに則った上で全体の具体的手順を構築する。このようにスクラムは軽量級フレームワークである。 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」にまとめられており、スクラムの改良に伴ってこのガイドも更新されている。 スクラムは適応型ITソリューションすなわち適応型ソフトウェアを開発する（ソフトウェア開発）ために発明され、のちにアジャイルソフトウェア開発手法の1つに分類された。現在ではソフトウェアに限らずあらゆる適応型ソリューション/プロダクトの開発に適用される。 スクラムは経験主義に基づいている。スクラムでは、小さい実践を繰り返して経験を生みその経験に基づいて判断し知識を得ることで、製品の将来をより正確に予測し不確実性を制御できるという哲学をもっている。これは綿密かつ巨大な計画で将来を事前に見通そうとする態度と対比される。 この哲学に基づいた実践をおこなうために、スクラムには3つの柱がある。 透明性/transparency 検査/inspection 適応/adaptation スクラムでは透明性によりチーム全体に現状が正しく共有され、製品が頻繁に検査されて異常が素早く見つかり、それに適応して製品・プロセスが修正されることを期待する。これが実現できればチームへ経験が蓄積し、製品はより良い方向へ向かう。 検査（英: inspection）は現状把握、すなわち目標と現状の比較・評価である。検査により開発の進行に伴う変化・問題を検出する。検査の目的は適切な方向への適応である。目標が示されていないと比較対象がいないため、十分な検査がおこなえない（例: 発生した問題は検査できても方向性のズレに気づけない）。ゆえに目標の透明性が良い検査の前提となっている。PDCAサイクルの Check 段階に相当する。 スクラムチーム（英: Scrum Team）はスクラムの基本単位となる小さなチームである。 スクラムチームはスポーツチームのように機能しなければならない。各メンバーは高い専門性を持ちながら自らのポジションに拘泥せず、1つのゴールを目指し全員が1つのチームとして協力する。つまり専門分野（例: マネジメント、エンジニアリング、デザイン）をもつ様々なプロフェッショナルが分野にとらわれず、1つのプロダクトゴールへ焦点を合わせプロダクト開発を行うチームがスクラムチームである。 スクラムチームはプロダクトゴール達成に必要な全ての活動を責務とする（必要な権限とそれを行使する責任を持つ）。すなわち開発において、どのメンバーが何（what）をいつどのように（how）行うかはスクラムチーム自身が決定し自己管理する。価値ある成果物を生み出す（プロダクトゴールを達成する）ことに関して、チームとしてステークホルダーに対する説明責任を負う。 スクラムチームは適応型プロダクトを開発する。ゆえに適応に必要な速度を担保できるサイズの小ささが必要であり、1チーム10人以下が推奨される。 スクラムチームには以下の3つの明確な役割・責任が定義される。 プロダクトオーナー（英: Product Owner）は製品の総責任者である。 顧客の意思の代表としての役割を担う。 ビジネスの視点（ROI等）においてプロジェクトに問題がないことを保障する役割を持つ。 顧客の要望をプロダクトバックログに優先順位を付けて反映させる。 スクラムマスター（英: Scrum Master）はスクラムフレームワークが正しく適用されていることを保証する役割である。権限としては間接的である。主な作業は、チーム内外の組織間調停(ファシリテーション)と外部妨害を対処することとされる。従来のプロジェクトマネージャがこの役割を担うことが多いが、プロジェクトそのものを管理するわけではない。 開発者（英: Developer）は各スプリントにおいて、利⽤可能なインクリメントの あらゆる側⾯を作成することを確約する役割を担う。開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。 スクラムは経験主義（透明性・検査・適応）を実現するために、以下の作成物とイベントを定義する。これらのフレームワークに則ることでチームとプロダクトの透明性が向上し、正しい検査が定期的におこなわれ、素早い適応がおき、良いプロダクトが生み出される。 スクラムの作成物は1つの確約（英: commitment）をもつ。目標たる確約を明示することで進捗測定すなわち検査が可能になる。プロダクトバックログにおけるプロダクトゴール、スプリントバックログにおけるスプリントゴール、インクリメントにおける完成の定義がそれぞれ検査基準となる確約である。確約はプロダクトの理想状態を示しており、開発者にこの達成を求める（ゆえに検査される）。プロダクトそのもの状態を明示された検査対象とすることで、逆説的に、スクラムは開発過程の大きな自由度を開発者にもたらしている（「この状態が目標だ、完成度を検査する。作り方は君に任せる」という方式、ミッション・コマンド）。 プロダクトゴールはプロダクトの将来の状態である。すなわち将来のプロダクト利用が生み出すべき価値である。ゴールは評価可能であり、全員に共有され、一度に1つのみ設定される。 プロダクトゴールはプロダクトの目標である。これによりスクラムチームはプロダクトゴールの実現を目標として計画を立案できる。プロダクトゴールは評価可能である。これによりプロダクトの進捗が検査可能になり、プロダクトが適応できる。プロダクトゴールはチームとステークホルダーに共有される。これによりチームは提供すべき価値を把握して「なぜ（why）これを開発するのか」を理解でき、目的意識を持った自律的な開発が可能になる。プロダクトゴールは一度に1つのみ設定される。これによりチームは単一のゴールへ向け集中できる。 例えばタクシーサービスが掲げる「顧客は平均7分でタクシーを捕まえられる」は定量評価可能なユーザー体験であり、プロダクトゴールに相応しい。 プロダクトバックログ（英: Product Backlog）はプロダクトが目指す姿とそうなるための要素の一覧である。プロダクトバックログはプロダクトゴールとプロダクトバックログアイテムからなる。 プロダクトバックログアイテム（PBI）はプロダクトゴールを達成する「何か（what）」の定義であり、理想形に必要な要素を示す。PBIはコストと顧客価値が見積もられ優先順位をもつ。プロダクトに対する要求は常に変化する。例えば変化を引き起こす物事としてプロダクトの利用・成長、市場からのフィードバック、ビジネス要求・環境の変化、技術の登場などがある。プロダクトに対する要求の変化に対してプロダクトバックログは「適応」する。すなわちプロダクトバックログの項目は要求の変化に応答して変化する。プロダクトバックログを更新していくことで、製品は常に適切で競争力をもち便利な方向へ開発されていく。 プロダクトバックログの最終的な決定と責任はプロダクトオーナーにあり尊重される。そこに至るまでのバックログへの関わり方（オーナー主体かチーム取り組みか）はプロジェクト次第である。またPBIがもつべき具体的項目は各プロジェクトごとに定義される（スクラムはあくまでフレームワークである）。 プロダクトバックログリファインメント スプリント期間中、チームはプロダクトバックログの健全性を保つための会議を開く。プロダクトバックログの健全性を示す指標として、INVESTが用いられることが多い。 インクリメント（英: Increment）はプロダクトゴールへの一歩となる、具体的な成果物である。インクリメント（増分）を積み上げていくことで理想形のプロダクトが実現する。インクリメントの原料はPBIである。いわばアイデアであるPBIを開発者が実装することでインクリメントとなる。作業中の途中産物はインクリメントではなく、"完成の定義"を満たした段階でインクリメントとなる。インクリメントはリリース可能である。 完成の定義（英: Definition of Done）はPBIの完成品が満たすべき品質基準である。 スプリントはアイデアを価値に変換する、すなわち実際に開発が行われる工程である。 スクラムは適応型プロダクトを開発する。つまりプロダクトは短期間で開発・実践投入・学習・適応を繰り返す必要がある。開発工程として計画・開発・日次見直し・レビュー・調整を含んだ一定期間の区切りがスプリント（英: Sprint）である。スプリントを設定することでプロダクトが目標とする価値へ定期的に適応するように誘導される。素早い適応のためにスプリント長は1ヶ月以下に設定される。 スプリント内では、決まった順序は存在しない。必要に応じて、プロダクトバックログの項目を開発し、まとめ、レビューする。また、項目によっては、単にレビューと調整だけで済む場合もある。どのように開発されるかは、そのバックログ項目の内容によるが、プロダクト全体として、インクリメンタル／イテレーティブに開発されることが多い。 スプリントでは検査と適応のために以下の4つのイベント（プロセス）を組み合わせて用いる。 スプリントプランニング: スプリント期間の最初に行われる。スクラムチームでスプリントバックログを生成する。この過程でチームメンバー間の認識差異がないことを最終確認する。 デイリースクラム: スプリント期間中、チームは、毎日スクラム会議を開く。デイリースクラムは、平日の決まった時間に決まった場所で行う。また、15分以内で完了させなければならない。また、スクラムマスターは、必ず出席しなければならず、チーム全員に対して、「前回のスクラム会議以降、何をしたか」「問題はあるか」「次回のスクラム会議までに何をするか」などの質問をする。会話は、これらの質問への応答に限られる。その質疑応答の結果によっては、即座に別の会議を開くこともある。問題があると報告された場合、スクラムマスターは、即座に意思決定する責任を負う。問題が外的要因によるものである場合、スクラムマスターが、その解決の責任を負う。デイリースクラムの目的はスプリントゴールを基準とした検査と適応である。 スプリントレビュー: スプリント最終盤にはスプリントレビューが行われる。このプロセスではスプリント成果の検査と適応をおこなう。すなわち生み出されたプロダクト/ソリューションが目標とする価値（プロダクトゴール）を実現しているかレビューする。インクリメントを中心にプロダクトが評価され、必要に応じてPBIが追加・変更される。このレビューには顧客・プロダクトオーナー・開発者（場合により営業・マーケター）が参加する。レビュー対象はインクリメントであり、未完で終わったPBIは含めない（ソリューション評価にならないため）。 スプリントレトロスペクティブ（振り返り）: スプリント終了時には振り返りが行われる。このプロセスでは開発工程の検査と適応をおこなう。スプリントで発生した問題とその改善策などを検討し、必要に応じてプロセス改善のPBIを追加する。 スプリントではPBIがインクリメントへ実装される。インクリメントは完成の定義を満たしリリース可能な状態にある。ゆえにスプリントの途中、スプリントレビューより前の段階でデプロイされうる。デプロイ判定（受け入れテスト）は"完成の定義"でなされるべきであり、スプリントレビューが障害物となって適応を遅くする事態を招いてはいけない。 スプリントバックログはスプリントの計画である。このスプリントで実現したい成果（スプリントゴール）、そのために必要なPBI、PBIを生成する手順計画からなる。スプリントバックログはデイリースクラムで進捗を検査可能な程度の詳細度が必要である。スプリントプランニングで生成され、状況の変化に応じて適応する。 スプリントゴールはスプリントがプロダクト改良を通じて提供する価値の目標である。スプリントの目的はスプリントゴールそのものである。作られるプロダクト（what）やプロダクト開発手順（how）のみでなく、生み出したい成果すなわち価値（why）に注目するためにスプリントゴールは設定される。状況の変化により設定されたスプリントゴールがもはや役に立たなくなった場合、そのスプリントは中止される。 スクラムは工程の枠組み・フレームワークである。すなわちスクラムの上に具体的なプロセスを配置し完成形のシステムとなる。ゆえに様々な技法・プロセス・パターンをスクラムとともに採用できる。以下が技法の例である。 テスト駆動開発 受け入れテスト駆動開発（英語版） リファクタリング 継続的インテグレーション ユーザーストーリー: 顧客要望の対話的分析、プロダクトゴール・スプリントゴールの表現 開発工程というブラックボックスを管理可能にする手法がある。結果を分析することで、プロジェクトマネージャは何らかの意思決定を行う。例えば、 バックログ項目数によりプロジェクトの規模を見積もる。 実装が完了したバックログ数からプロジェクトの進捗状況を見積もる。 リスクの定量化によってプロジェクトの複雑度を見積もる。 スクラムの制御はメタデータモデルで表される。 ベロシティは前回スプリントで達成したプロダクトバックログの相対見積り合計である。 スクラムはプロダクトゴール達成を唯一の目的とし、優れたソリューション/プロダクトの開発を可能にする。しかしその前提として、プロダクトゴールすなわち提供する価値の質はすべてを左右する。価値のないプロダクトゴール（無価値な価値）を達成する完璧なプロダクトが完成しても、それは価値を生み出さない。そのため良いプロダクトゴールを設計する様々な技法がスクラムフレームワークと共に採用されうる。 プロダクトゴールはしばしばプロダクトのビジョン（英: Vision）から演繹される。プロダクトのビジョンは企業が掲げる理想像である。プロダクトは徐々に改善されながらビジョンへ向かうため、いくつもの状態を経ることになる。プロダクトゴールはその1つ1つの状態に対応する。 提供すべき価値が不確かな段階ではプロダクトゴール自体を探索する必要がある（c.f. 商品開発）。その場合、適応的な価値探索をおこなう。プロトタイピングを通してMVPを作成し価値を探索する。リーンスタートアップはそれを実現する方法論の1つである。プロダクトマネジメントは価値探索から開発までを含んだマネジメントである。 プロダクトゴールが不確かな場合、プロダクトゴールを設定すること自体が意味を持つ。なぜならプロダクトゴールのもつ特性（長期目標・単一・可測・公開）は具体的であり、ステークホルダーとの議論を中身あるものにするからである。 プロダクトゴールの最終決定はプロダクトオーナーの責務である。その過程でスクラムチームを巻き込むことは現場の感覚・知恵を取り入れまたチームの更なる自己管理を促進する意味で有意義である。ゴールは達成すべき目標であるが、実際にユーザーが手にするのは開発されたインクリメントの総体たるプロダクトである。 Ken Schwaber and Jeff Sutherland. (2017). The Scrum Guide. スクラム創始者によるスクラムの定義と解説 (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process (PDF) Dr. Sutherland, J. (October 2004) Agile Development: Lessons learned from the first scrum 西村直人・永瀬美穂・吉羽龍太郎『スクラム・ブート・キャンプ・ザ・ブック――スクラムチームではじめるアジャイル開発』翔泳社、2013年。 『アジャイルソフトウェア開発スクラム』ピアソンエデュケーション、2003年。ISBN 978-4894715899。  Dynamic systems development method（英語版） (DSDM) ユーザ機能駆動開発 (FDD) エクストリーム・プログラミング (XP) - 複数あるXPのプラクティスの一部を、スクラムと組み合わせて使われることが多い en:Comparison of Scrum software -スクラム（ソフトウェア）の比較（英語） ^ "スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。" scrum guide 2020 JP ^ "スクラムとは次の環境を促進するため ... 1. ... 問題に対応するための作業をプロダクトバックログに並べる。 2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。 3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。 4. 繰り返す。 スクラムはシンプルである。" scrum guide 2020 JP ^ "プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド. ^ "スクラムとは、複雑な問題に対応する適応型のソリューションを通じて … 軽量級フレームワークである。" 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 ^ Takeuchi, Hirotaka; Nonaka, Ikujiro (Jan 1, 1986). “New New Product Development Game”. ハーバード・ビジネス・レビュー. https://cb.hbsp.harvard.edu/cbmp/product/86116-PDF-ENG 2017年8月24日閲覧。.  ^ a b 伊藤真美 (2013年2月1日). “「実践知リーダーシップとアジャイル／スクラム」－野中郁次郎氏が国内最大のスクラムイベントで講演”. EnterpriseZine（翔泳社）. 2017年8月24日閲覧。 ^ a b c “スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法 (1/2)”. ITmedia (2011年4月13日). 2017年8月24日閲覧。 ^ Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum. SCRUM GUIDES 2020-08-16閲覧 ^ "スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。" 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 ^ Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. SCRUM GUIDES 2017 ^ "これは、潜在的に望ましくない変化や問題を検知するためである。" scrum guide 2020 JP ^ "検査によって適応が可能になる。適応のない検査は意味がないとされる。" scrum guide 2020 JP ^ "Transparency enables inspection. Inspection without transparency is misleading and wasteful." Scrum Guide 2020. ^ "スクラムの基本単位は、スクラムチームという⼩さなチームである。" scrum guide 2020 JP ^ "⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。... スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。" scrum guide 2020 JP ^ "The Scrum Team is responsible for all product-related activities" scrum guide 2020 ^ "⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。... 2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できる" scrum guide 2020 JP ^ 例えば完成したプロダクトが売れなかった場合、そうなった経緯を社長へ正しく報告する責任がある。チームの失敗はチームとして責任を負う。 ^ "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." scrum guide 2020 ^ "スクラムチームは、敏捷性を維持するための⼗分な⼩ささ ... があり、通常は 10 ⼈以下である。" ^ "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 2020 ^ "Daily Scrum ... inspect progress toward the Sprint Goal" Scrum Guide 2020. ^ "Daily Scrum ... adapt the Sprint Backlog" Scrum Guide 2020. ^ "Sprint Review ... inspect the outcome of the Sprint" Scrum Guide 2020 ^ "Sprint Review ... progress toward the Product Goal is discussed." Scrum Guide 2020 ^ "Sprint Review ... The Product Backlog may also be adjusted to meet new opportunities." Scrum Guide 2020 ^ "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 ^ a b "プロダクトゴールは、スクラムチームの⻑期的な⽬標である。... プロダクトを全体的なプロダクトゴールに近づける" 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) と考えることができます。… なぜチームにバックログを与えているのかについてのビジョンがないプロダクトオーナに大きな問題があると言いました。これは、チームにとって重要な意欲を削ぐものです。" Ben Linders, Ken Schwaber, Jeff Sutherland. (2020). スクラムガイド 2020の変更点: Ken Schwaber氏とJeff Sutherland氏とのQ＆A. InfoQ. ^ "スクラムチームは ... ⼀度にひとつの⽬的（プロダクトゴール）に集中している" scrum guide 2020 JP ^ a b "プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。" scrum guide 2020, JP ^ 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 2017 ^ Changes 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 ^ "An Increment is a concrete stepping stone toward the Product Goal." scrum guide 2020 ^ "プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。... 完成の定義を満たさない限り、作業をインクリメントの⼀部と⾒なすことはできない。" scrum guide 2020 JP ^ "スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。 ... プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。" scrum guide 2020 JP ^ "スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わる。" scrum guide 2020 JP ^ "スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。" scrum guide 2020 JP ^ "スプリントは 1 か⽉以内の決まった⻑さとする。" scrum guide 2020 JP ^ "スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。" scrum guide 2020 JP ^ "The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog" Scrum Guide 2020. ^ "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations." Scrum Guide 2020. ^ "プロダクトバックログアイテムが完成の定義を満たしていない場 合 ... スプリントレビューで提⽰することもできない。" scrum guide 2020 JP ^ "スプリ ント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。" scrum guide 2020 JP ^ "スプリントレビューのことを価値をリリースするための関⾨と⾒なすべきではない。" scrum guide 2020 JP ^ "スプリントの計画（スプリントバックログ）" scrum guide 2020 JP ^ "スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。" scrum guide 2020 JP ^ "スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。 " scrum guide 2020 JP ^ "スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。... 作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。" scrum guide 2020 JP ^ "プロダクトの価値と有⽤性を今回のスプリントでどのように⾼める ... そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。" scrum guide 2020 JP ^ "スプリントゴール（なぜ）" scrum guide 2020 JP ^ "スプリントゴールはスプリントの唯⼀の⽬的である。" scrum guide 2020 JP ^ "これまでのスプリントプランニングのトピックである「What」と「How」に加えて、スクラム ガイド 2020 年版では、3 つ⽬のトピック「Why」に重点を置いた。これはスプリントゴールで ⾔及されている。" scrum guide 2020 JP ^ "スプリントゴールがもはや役に⽴たなくなった場合、スプリントは中⽌されることになるだろう。" scrum guide 2020 JP ^ "スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。... スクラムを利⽤していると、本⽂書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発⾒・適⽤・考案することもあるだろう。" scrum guide 2020 JP ^ "誤解を恐れずに言えば、アジャイルでは「正しく」ソフトウェアを作っても、それがリーン・スタートアップが目指す「正しい」ソフトウェアにならないことが起こり得るということになります。" 新規事業のイノベーションを加速するリーン・スタートアップ適用とアジャイル開発. PROVISION No.87, 2015. ^ "いくつものプロダクトゴールを積み上げていくことで、プロダクトビジョンに到達する、という考えです。" Jeff Sutherland & Scrum Inc. Japan. (2021). スクラムガイド2020解説ビデオ オンライン上映会 開催レポート. ^ "Involving Stakeholders to build consensus using your Product Goal" Fábio Leandro Lazo Sanches. (2021). Leveraging the Product Goal to Engage with Stakeholders. Scrum.org. 2021-09-03 viewed. Agile business Institute SCRUMワークショップ体験記 @IT 情報マネジメント Scrum （有）メタボリックス Implementing Scrum Scrum Alliance Scrum et al - Google Techtalk with Ken Schwaber（ビデオ） Scrum in five minutes Scrum articles directory Agile Alliance's Scrum library InfoQ.com / Agile Tackle - a web-based Scrum Tracking Tool スクラムチュートリアル（オンライン）