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

出典: フリー百科事典『ウィキペディア(Wikipedia)』
ナビゲーションに移動 検索に移動

プロダクト開発におけるスクラム: Scrum)は複雑な問題への適応型ソリューションをチームで開発し価値を生み出すための軽量級フレームワークである[1]

概要[編集]

複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。

スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである[2]。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。

スクラムはチームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。

背景[編集]

複雑な問題と適応型ソリューション[編集]

複雑な問題は難しい。もし1回で問題への完璧な解決策/ソリューションを提供できれば大きな価値を提供できる。しかし「完璧に計画されたソリューション」は往々にして不完全に終わる。そうでないやり方の1つが適応型ソリューション(: adaptive solutions)である。すなわち最初は不完全だが段階的に学び改善されていくソリューションである。

ソリューション開発と目的[編集]

ソリューションの別名はプロダクトである。なぜならプロダクトは価値を提供する手段(ソリューション)だからである[3]。例えばカップラーメンというプロダクトは空腹という問題を解決し満腹という価値を提供するソリューションである。プロダクトはあくまで手段であり、価値こそが目的である。

プロダクトは人の手によって開発される。プロダクトが手段ということは、プロダクト開発もまた手段である(手段を生み出す手段)。言い換えれば、ソフトウェア開発は出力(output)としてプロダクトを生み出し、プロダクトは利用された成果(outcome)として価値を生み出す。スクラムはソリューション/プロダクト開発の方法論である[4]。ゆえにスクラムの目的は(ソリューションを生み出すことではなく)生んだソリューションを介して価値を生み出すことである[5]

軽量フレームワーク[編集]

適応型ソリューションを開発するために厳密で重厚なプロセス・手法を用意することも可能だが、スクラムは異なるアプローチをとる。スクラムは最低限で軽量な工程の枠組み(プロセスフレームワーク)のみを提供する[6]。すなわちスクラムは開発の流れ、ポイントとなるイベントのみを定義する[7]。実際のソリューション開発ではスクラムフレームワークに則った上で全体の具体的手順を構築する。このようにスクラムは軽量級フレームワークである。

歴史[編集]

1986年野中郁次郎竹内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載される[8][9]。その中で柔軟で自由度の高い日本発の開発手法をラグビースクラムに喩えて「Scrum(スクラム)」として紹介した[9][10]

野中、竹内の論文に着想を得たJeff Sutherland、John Scumniotales、Jeff McKenna が、1993年にラウンドトリップ・エンジニアリング(一種の反復型開発)を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築し、実践したのがソフトウェア開発手法としてのスクラムの最初である[10]。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。同じころ、ケン・シュエイバーが自社 (ADM) でのソフトウェア開発にこの手法を用いた。スクラムは産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としてのスクラムの元となった。

このプラクティスは2003年に『アジャイルソフトウェア開発スクラム』としてまとめられた[10]

スクラムの定義と解説はスクラムの創設者Ken SchwaberとJeff Sutherlandによる「The Scrum Guide」にまとめられており[11]、スクラムの改良に伴ってこのガイドも更新されている。

スクラムは適応型ITソリューションすなわち適応型ソフトウェアを開発する(ソフトウェア開発)ために発明され、のちにアジャイルソフトウェア開発手法の1つに分類された。現在ではソフトウェアに限らずあらゆる適応型ソリューション/プロダクトの開発に適用される[12]

背景理論[編集]

スクラムは経験主義に基づいている。スクラムでは、小さい実践を繰り返して経験を生みその経験に基づいて判断し知識を得ることで、製品の将来をより正確に予測し不確実性を制御できるという哲学をもっている[13]。これは綿密かつ巨大な計画で将来を事前に見通そうとする態度と対比される。

この哲学に基づいた実践をおこなうために、スクラムには3つの柱がある[14]

  • 透明性/transparency
  • 検査
  • 適応/adaptation

スクラムでは透明性によりチーム全体に現状が正しく共有され、製品が頻繁に検査されて異常が素早く見つかり、それに適応して製品・プロセスが修正されることを期待する。これが実現できればチームへ経験が蓄積し、製品はより良い方向へ向かう。

検査[編集]

検査(: Inspection)は現状の把握、すなわち目標と現状の比較・評価である。検査により開発の進行に伴う変化・問題を検出する[15]。検査の目的は適切な方向への適応である[16]

スクラムチーム[編集]

スクラムチーム(: Scrum Team)はスクラムの基本単位となる小さなチームである[17]

スクラムチームはスポーツチームのように機能しなければならない。各メンバーは高い専門性を持ちながら自らのポジションに拘泥せず、1つのゴールを目指し全員が1つのチームとして協力する。つまり専門分野(例: マネジメント、エンジニアリング、デザイン)をもつ様々なプロフェッショナルが分野にとらわれず、1つのプロダクトゴールへ焦点を合わせプロダクト開発を行うチームがスクラムチームである[18]

スクラムチームはプロダクトゴール達成に必要な全ての活動を責務とする(必要な権限とそれを行使する責任を持つ)[19]。すなわち開発において、どのメンバーが何(what)をいつどのように(how)行うかはスクラムチーム自身が決定し自己管理する[20]。価値ある成果物を生み出す(プロダクトゴールを達成する)ことに関して、チームとしてステークホルダーに対する説明責任を負う[21][22]

スクラムチームは適応型プロダクトを開発する。ゆえに適応に必要な速度を担保できるサイズの小ささが必要であり、1チーム10人以下が推奨される[23]

スクラムチームには以下の3つの明確な役割・責任が定義される。

プロダクトオーナー[編集]

プロダクトオーナー(: Product Owner)は製品の総責任者である。 顧客の意思の代表としての役割を担う。 ビジネスの視点(ROI等)においてプロジェクトに問題がないことを保障する役割を持つ。 顧客の要望をプロダクトバックログに優先順位を付けて反映させる。

スクラムマスター[編集]

スクラムマスター(: Scrum Master)はスクラムフレームワークが正しく適用されていることを保証する役割である。権限としては間接的である。主な作業は、チーム内外の組織間調停(ファシリテーション)と外部妨害を対処することとされる。従来のプロジェクトマネージャがこの役割を担うことが多いが、プロジェクトそのものを管理するわけではない。

開発者[編集]

開発者(: Developer)は各スプリントにおいて、利⽤可能なインクリメントの あらゆる側⾯を作成することを確約する役割を担う。開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。

方法論[編集]

プロダクトゴール[編集]

プロダクトゴールはプロダクトの将来の状態である[24][25]。すなわち将来のプロダクト利用が生み出すべき価値である。ゴールは評価可能であり、全員に共有され、一度に1つのみ設定される。

プロダクトゴールはプロダクトの目標である。これによりスクラムチームはプロダクトゴールの実現を目標として計画を立案できる[26]。プロダクトゴールは評価可能である[27]。これによりプロダクトの進捗が検査可能になり、プロダクトが適応できる[28]。プロダクトゴールはチームとステークホルダーに共有される[29]。これによりチームは提供すべき価値を把握して「なぜ(why)これを開発するのか」を理解でき、目的意識を持った自律的な開発が可能になる[30]。プロダクトゴールは一度に1つのみ設定される。これによりチームは単一のゴールへ向け集中できる[31]

例えばタクシーサービスが掲げる「顧客は平均7分でタクシーを捕まえられる」は定量評価可能なユーザー体験であり、プロダクトゴールに相応しい。

プロダクトバックログ[編集]

プロダクトバックログ(: Product Backlog)はプロダクトが目指す姿とそうなるための要素の一覧である。プロダクトバックログはプロダクトゴールプロダクトバックログアイテムからなる[32]

プロダクトバックログアイテム(PBI)はプロダクトゴールを達成する「何か(what)」の定義であり、理想形に必要な要素を示す。PBIはコストと顧客価値が見積もられ優先順位をもつ。プロダクトに対する要求は常に変化する。例えば変化を引き起こす物事としてプロダクトの利用・成長、市場からのフィードバック、ビジネス要求・環境の変化、技術の登場などがある[33][34]。プロダクトに対する要求の変化に対してプロダクトバックログは「適応」する。すなわちプロダクトバックログの項目は要求の変化に応答して変化する。プロダクトバックログを更新していくことで、製品は常に適切で競争力をもち便利な方向へ開発されていく[35]

プロダクトバックログの最終的な決定と責任はプロダクトオーナーにあり尊重される。そこに至るまでのバックログへの関わり方(オーナー主体かチーム取り組みか)はプロジェクト次第である[26]。またPBIがもつべき具体的項目は各プロジェクトごとに定義される(スクラムはあくまでフレームワークである)[32]

プロダクトバックログリファインメント スプリント期間中、チームはプロダクトバックログの健全性を保つための会議を開く。プロダクトバックログの健全性を示す指標として、INVESTが用いられることが多い。

インクリメント[編集]

インクリメント(: Increment)はプロダクトゴールへの一歩となる、具体的な成果物である[36]。すなわちインクリメント(増分)を積み上げていくことで理想形のプロダクトが実現する。インクリメントの原料はPBIである。いわばアイデアであるPBIを開発者が実装することでインクリメントとなる。作業中の途中産物はインクリメントではなく、"完成の定義"を満たした段階でインクリメントとなる[37]。インクリメントはリリース可能である[38]

完成の定義[編集]

完成の定義(: Definition of Done)はPBIの完成品が満たすべき品質基準である。

スプリント[編集]

スプリントはアイデアを価値に変換する、すなわち実際に開発が行われる工程である[39]

スクラムは適応型プロダクトを開発する。つまりプロダクトは短期間で開発・実践投入・学習・適応を繰り返す必要がある。開発工程として計画・開発・日次見直し・レビュー・調整を含んだ一定期間の区切りがスプリント: Sprint)である。スプリントを設定することでプロダクトが目標とする価値へ定期的に適応するように誘導される[40]。素早い適応のためにスプリント長は1ヶ月以下に設定される[41]

スプリント内では、決まった順序は存在しない。必要に応じて、プロダクトバックログの項目を開発し、まとめ、レビューする。また、項目によっては、単にレビューと調整だけで済む場合もある。どのように開発されるかは、そのバックログ項目の内容によるが、プロダクト全体として、インクリメンタル/イテレーティブに開発されることが多い。

スプリントでは検査と適応のために以下の4つのイベント(プロセス)を組み合わせて用いる[42]

  • スプリントプランニング: スプリント期間の最初に行われる。スクラムチームでスプリントバックログを生成する。この過程でチームメンバー間の認識差異がないことを最終確認する。
  • デイリースクラム: スプリント期間中、チームは、毎日スクラム会議を開く。デイリースクラムは、平日の決まった時間に決まった場所で行う。また、15分以内で完了させなければならない。また、スクラムマスターは、必ず出席しなければならず、チーム全員に対して、「前回のスクラム会議以降、何をしたか」「問題はあるか」「次回のスクラム会議までに何をするか」などの質問をする。会話は、これらの質問への応答に限られる。その質疑応答の結果によっては、即座に別の会議を開くこともある。問題があると報告された場合、スクラムマスターは、即座に意思決定する責任を負う。問題が外的要因によるものである場合、スクラムマスターが、その解決の責任を負う。
  • スプリントレビュー: スプリント最終盤にはスプリントレビューが行われる。このプロセスではプロダクトの適応をおこなう。すなわち生み出されたプロダクト/ソリューションが目標とする価値(プロダクトゴール)を実現しているかレビューする。インクリメントを中心にプロダクトが評価され、必要に応じてPBIが追加・変更される。このレビューには顧客・プロダクトオーナー・開発者(場合により営業・マーケター)が参加する。レビュー対象はインクリメントであり、未完で終わったPBIは含めない(ソリューション評価にならないため)[43]
  • スプリントレトロスペクティブ(振り返り): スプリント終了時には振り返りが行われる。このプロセスでは開発工程の適応をおこなう。スプリントで発生した問題とその改善策などを検討し、必要に応じてプロセス改善のPBIを追加する。

スプリントではPBIがインクリメントへ実装される。インクリメントは完成の定義を満たしリリース可能な状態にある。ゆえにスプリントの途中、スプリントレビューより前の段階でデプロイされうる[44]。デプロイ判定(受け入れテスト)は"完成の定義"でなされるべきであり、スプリントレビューが障害物となって適応を遅くする事態を招いてはいけない[45]

スプリントバックログ[編集]

スプリントバックログはスプリントの計画である[46]。このスプリントで実現したい成果(スプリントゴール)、そのために必要なPBI、PBIを生成する手順計画からなる[47]。スプリントバックログはデイリースクラムで進捗を検査可能な程度の詳細度が必要である[48]。スプリントプランニングで生成され、状況の変化に応じて適応する[49]

スプリントゴール[編集]

スプリントゴールはスプリントがプロダクト改良を通じて提供する価値の目標である[50][51]。スプリントの目的はスプリントゴールそのものである[52]。作られるプロダクト(what)やプロダクト開発手順(how)のみでなく、生み出したい成果すなわち価値(why)に注目するためにスプリントゴールは設定される[53]。ゴールを明示することで手順に大きな自由度が与えられる[54](c.f. ミッション・コマンド)。状況の変化により設定されたスプリントゴールがもはや役に立たなくなった場合、そのスプリントは中止される[55]

組み合わせ技法[編集]

スクラムは工程の枠組み・フレームワークである。すなわちスクラムの上に具体的なプロセスを配置し完成形のシステムとなる。ゆえに様々な技法・プロセス・パターンをスクラムとともに採用できる[56]。以下が技法の例である。

  1. テスト駆動開発
  2. 受け入れテスト駆動開発英語版
  3. リファクタリング
  4. 継続的インテグレーション
  5. ユーザーストーリー: 顧客要望の対話的分析、プロダクトゴールスプリントゴールの表現

開発工程というブラックボックスを管理可能にする手法がある。結果を分析することで、プロジェクトマネージャは何らかの意思決定を行う。例えば、

  • バックログ項目数によりプロジェクトの規模を見積もる。
  • 実装が完了したバックログ数からプロジェクトの進捗状況を見積もる。
  • リスクの定量化によってプロジェクトの複雑度を見積もる。

スクラムの制御はメタデータモデルで表される。

ベロシティは前回スプリントで達成したプロダクトバックログの相対見積り合計である。

プロダクトゴール設計[編集]

スクラムはプロダクトゴール達成を唯一の目的とし、優れたソリューション/プロダクトの開発を可能にする。しかしその前提として、プロダクトゴールすなわち提供する価値の質はすべてを左右する。価値のないプロダクトゴール(無価値な価値)を達成する完璧なプロダクトが完成しても、それは価値を生み出さない[57]。そのため良いプロダクトゴールを設計する様々な技法がスクラムフレームワークと共に採用されうる。

プロダクトゴールはしばしばプロダクトのビジョン: Vision)から演繹される。プロダクトのビジョンは企業が掲げる理想像である。プロダクトは徐々に改善されながらビジョンへ向かうため、いくつもの状態を経ることになる。プロダクトゴールはその1つ1つの状態に対応する[58]

提供すべき価値が不確かな段階ではプロダクトゴール自体を探索する必要がある(c.f. 商品開発)。その場合、適応的な価値探索をおこなう。プロトタイピングを通してMVPを作成し価値を探索する。リーンスタートアップはそれを実現する方法論の1つである。プロダクトマネジメントは価値探索から開発までを含んだマネジメントである。

プロダクトゴールが不確かな場合、プロダクトゴールを設定すること自体が意味を持つ。なぜならプロダクトゴールのもつ特性(長期目標・単一・可測・公開)は具体的であり、ステークホルダーとの議論を中身あるものにするからである[59]

プロダクトゴールの最終決定はプロダクトオーナーの責務である。その過程でスクラムチームを巻き込むことは現場の感覚・知恵を取り入れまたチームの更なる自己管理を促進する意味で有意義である。ゴールは達成すべき目標であるが、実際にユーザーが手にするのは開発されたインクリメントの総体たるプロダクトである。

参考文献[編集]

  • 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

関連項目[編集]

脚注・出典[編集]

  1. ^ "スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。" scrum guide 2020 JP
  2. ^ "スクラムとは次の環境を促進するため ... 1. ... 問題に対応するための作業をプロダクトバックログに並べる。 2. スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。 3. スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。 4. 繰り返す。 スクラムはシンプルである。" scrum guide 2020 JP
  3. ^ "プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド.
  4. ^ "スクラムとは、複雑な問題に対応する適応型のソリューションを通じて … 軽量級フレームワークである。" scrum guide 2020 JP
  5. ^ "スクラムとは ... 価値を⽣み出すための軽量級フレームワークである。" Ken Schwaber & Jeff Sutherland (2020). スクラムガイド.
  6. ^ 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
  7. ^ "スクラムフレー ムワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている。... スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。" scrum guide 2020 JP
  8. ^ 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日閲覧。. 
  9. ^ a b 伊藤真美 (2013年2月1日). “「実践知リーダーシップとアジャイル/スクラム」-野中郁次郎氏が国内最大のスクラムイベントで講演”. EnterpriseZine(翔泳社). 2017年8月24日閲覧。
  10. ^ a b c スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法 (1/2)”. ITmedia (2011年4月13日). 2017年8月24日閲覧。
  11. ^ Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum. SCRUM GUIDES 2020-08-16閲覧
  12. ^ "スクラムが誕⽣したソフトウェアプロダクト開発の領域を超えて、本質的に複雑な作業を必要とするさまざまなドメインでスクラムが採⽤されている。" scrum guide 2020 JP
  13. ^ 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
  14. ^ Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. SCRUM GUIDES 2017
  15. ^ "これは、潜在的に望ましくない変化や問題を検知するためである。" scrum guide 2020 JP
  16. ^ "検査によって適応が可能になる。適応のない検査は意味がないとされる。" scrum guide 2020 JP
  17. ^ "スクラムの基本単位は、スクラムチームという⼩さなチームである。" scrum guide 2020 JP
  18. ^ "⼀度にひとつの⽬的(プロダクトゴール)に集中している専⾨家が集まった単位である。... スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。" scrum guide 2020 JP
  19. ^ "The Scrum Team is responsible for all product-related activities" scrum guide 2020
  20. ^ "⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。... 2020 年版ではスクラムチームの⾃⼰管理に重点を置き、「誰が」「どのように」「何の」作業をするかを選択できる" scrum guide 2020 JP
  21. ^ 例えば完成したプロダクトが売れなかった場合、そうなった経緯を社長へ正しく報告する責任がある。チームの失敗はチームとして責任を負う。
  22. ^ "The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint." scrum guide 2020
  23. ^ "スクラムチームは、敏捷性を維持するための⼗分な⼩ささ ... があり、通常は 10 ⼈以下である。"
  24. ^ "プロダクトゴールは、プロダクトの将来の状態を表している。" scrum guide 2020 JP
  25. ^ "The Product Goal describes a future state of the product" scrum guide 2020
  26. ^ a b "プロダクトゴールは、スクラムチームの⻑期的な⽬標である。... プロダクトを全体的なプロダクトゴールに近づける" scrum guide 2020, JP
  27. ^ "優れたプロダクトゴールは、達成に努めるものであり、測定可能であり" Ben Linders, Ken Schwaber, Jeff Sutherland. (2020). スクラムガイド 2020の変更点: Ken Schwaber氏とJeff Sutherland氏とのQ&A. InfoQ.
  28. ^ "スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。… 各作成物には、透明性と集中を⾼める情報を提供する「確約(コミットメント)」が含まれている。これにより進捗を測定できる。・プロダクトバックログのためのプロダクトゴール … プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり" scrum guide 2020 JP
  29. ^ "優れたプロダクトゴールは…スクラムチームとそのステークホルダに可視化されます。" Ben Linders, Ken Schwaber, Jeff Sutherland. (2020). スクラムガイド 2020の変更点: Ken Schwaber氏とJeff Sutherland氏とのQ&A. InfoQ.
  30. ^ "プロダクトゴールは、プロダクトバックログのコンテキストを提供します。これは、プロダクトバックログが存在する「なぜ (Why)」と、スクラムチームが作業を行っているなぜ (Why) と考えることができます。… なぜチームにバックログを与えているのかについてのビジョンがないプロダクトオーナに大きな問題があると言いました。これは、チームにとって重要な意欲を削ぐものです。" Ben Linders, Ken Schwaber, Jeff Sutherland. (2020). スクラムガイド 2020の変更点: Ken Schwaber氏とJeff Sutherland氏とのQ&A. InfoQ.
  31. ^ "スクラムチームは ... ⼀度にひとつの⽬的(プロダクトゴール)に集中している" scrum guide 2020 JP
  32. ^ a b "プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か(what)」を定義するものである。" scrum guide 2020, JP
  33. ^ 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
  34. ^ Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog. SCRUM GUIDES 2017
  35. ^ 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
  36. ^ "An Increment is a concrete stepping stone toward the Product Goal." scrum guide 2020
  37. ^ "プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。... 完成の定義を満たさない限り、作業をインクリメントの⼀部と⾒なすことはできない。" scrum guide 2020 JP
  38. ^ "スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。 ... プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。" scrum guide 2020 JP
  39. ^ "スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わる。" scrum guide 2020 JP
  40. ^ "スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まる。" scrum guide 2020 JP
  41. ^ "スプリントは 1 か⽉以内の決まった⻑さとする。" scrum guide 2020 JP
  42. ^ "スクラムでは、検査と適応のための 4 つの正式なイベントを組み合わせている。それらを包含するイベントは「スプリント」と呼ばれる。" scrum guide 2020 JP
  43. ^ "プロダクトバックログアイテムが完成の定義を満たしていない場 合 ... スプリントレビューで提⽰することもできない。" scrum guide 2020 JP
  44. ^ "スプリ ント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。" scrum guide 2020 JP
  45. ^ "スプリントレビューのことを価値をリリースするための関⾨と⾒なすべきではない。" scrum guide 2020 JP
  46. ^ "スプリントの計画(スプリントバックログ)" scrum guide 2020 JP
  47. ^ "スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。" scrum guide 2020 JP
  48. ^ "スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。 " scrum guide 2020 JP
  49. ^ "スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。... 作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。" scrum guide 2020 JP
  50. ^ "プロダクトの価値と有⽤性を今回のスプリントでどのように⾼める ... そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。" scrum guide 2020 JP
  51. ^ "スプリントゴール(なぜ)" scrum guide 2020 JP
  52. ^ "スプリントゴールはスプリントの唯⼀の⽬的である。" scrum guide 2020 JP
  53. ^ "これまでのスプリントプランニングのトピックである「What」と「How」に加えて、スクラム ガイド 2020 年版では、3 つ⽬のトピック「Why」に重点を置いた。これはスプリントゴールで ⾔及されている。" scrum guide 2020 JP
  54. ^ "スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。" scrum guide 2020 JP
  55. ^ "スプリントゴールがもはや役に⽴たなくなった場合、スプリントは中⽌されることになるだろう。" scrum guide 2020 JP
  56. ^ "スクラムフレームワークの中で、さまざまなプロセス、技法、⼿法を使⽤できる。スクラムは既存のプラクティスを包み込む。... スクラムを利⽤していると、本⽂書で説明しているスクラムフレームワークと適合するようなパターン、プロセス、インサイトを発⾒・適⽤・考案することもあるだろう。" scrum guide 2020 JP
  57. ^ "誤解を恐れずに言えば、アジャイルでは「正しく」ソフトウェアを作っても、それがリーン・スタートアップが目指す「正しい」ソフトウェアにならないことが起こり得るということになります。" 新規事業のイノベーションを加速するリーン・スタートアップ適用とアジャイル開発. PROVISION No.87, 2015.
  58. ^ "いくつものプロダクトゴールを積み上げていくことで、プロダクトビジョンに到達する、という考えです。" Jeff Sutherland & Scrum Inc. Japan. (2021). スクラムガイド2020解説ビデオ オンライン上映会 開催レポート.
  59. ^ "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.

外部リンク[編集]