The Scrum Guide

Size: px

Start display at page:

Download "The Scrum Guide"

るるみなかきむら
4 years ago
Views:

1 スクラムガイドスクラム公式ガイド : ゲームのルール 2017 年 11 月 Developed and sustained by Scrum creators: Ken Schwaber and Jeff Sutherland 日本語版 Japanese

2 目次スクラムガイドの目的... 3 スクラムの定義... 3 スクラムの用途... 3 スクラムの理論... 4 スクラムの価値基準... 5 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム... 6 スクラムマスター... 7 スクラムイベント... 8 スプリント... 8 スプリントプランニング... 9 デイリースクラムスプリントレビュースプリントレトロスペクティブスクラムの作成物プロダクトバックログスプリントバックログインクリメント作成物の透明性完成(Done) の定義最後に謝辞人々歴史翻訳スクラムガイド 2016 年版と 2017 年版の変更点 Page 2

3 スクラムガイドの目的スクラムは複雑なプロダクトを開発提供保守するためのフレームワークである本ガイドではスクラムの定義を説明するスクラムの定義にはスクラムの役割イベント作成物とそれらをまとめるルールが含まれるスクラムは Ken Schwaber と Jeff Sutherland が開発したものでありスクラムガイドはこの 2 人が執筆提供する両者は共にスクラムガイドを支援しているスクラムの定義スクラム ( 名詞 ): 複雑で変化の激しい問題に対応するためのフレームワークであり可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものであるスクラムとは以下のようなものである軽量理解が容易習得は困難スクラムは 1990 年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワークであるプロダクトを構築するプロセス技法決定的な方法論などではないさまざまなプロセスや技法を取り入れることのできるフレームワークであるスクラムはこれまでのプロダクト管理や仕事のテクニックの相対的な有効性を明確にしてプロダクトチーム作業環境の継続的な改善を可能にするスクラムフレームワークはスクラムチームとその役割イベント作成物ルールで構成されているそれぞれに目的がありスクラムの成功や利用に欠かせないスクラムのルールは役割イベント作成物をまとめそれらの関係性や相互作用を統括するものであるスクラムのルールについては本稿全体で説明するスクラムフレームワークを使用する具体的な方法にはさまざまなものがありそれらについては本稿では触れないスクラムの用途当初スクラムはプロダクトの開発と管理のために開発された 1990 年代初頭から使用され今では以下のように世界中で広く利用されている 1. 有望な市場技術プロダクトの研究および特定 2. プロダクトや追加機能の開発 3. プロダクトや追加機能のリリース (1 日に何度もリリースされる ) 4. プロダクトが使用するクラウド ( オンラインセキュアオンデマンド ) やその他運用環境の開発と保守 5. プロダクトの保守や刷新 Page 3

4 スクラムはソフトウェアハードウェア組込みソフトウェア機能同士を接続するネットワーク自動運転車などの開発から学校政府マーケティング組織運営マネジメントに至るまで個人や社会が日常的に使用するあらゆるものに使用されている技術市場環境の複雑化やそれらの相互作用は急速に高まっておりスクラムがその対応に有効であることは日々証明されているスクラムは反復的で漸進的な知識移転において特に有効であることが示されている今ではプロダクトサービス所属する組織の管理に広く利用されているスクラムの本質は少人数制のチームである個々のチームは非常に柔軟で適応力に優れているこうした強みは単一のチームであっても複数あるいは多数のチームであっても数千人の成果やプロダクトを開発リリース運用保守するネットワーク型のチームであっても有効であるチームは協力や情報交換をしながら洗練された開発アーキテクチャやターゲットとするリリース環境を整えていくスクラムガイドで開発や開発するといった言葉が登場するときそれは上記のような複雑な作業を意味しているスクラムの理論スクラムは経験的プロセス制御の理論 ( 経験主義 ) を基本にしている経験主義とは実際の経験と既知に基づく判断によって知識が獲得できるというものであるスクラムでは反復的かつ漸進的な手法を用いて予測可能性の最適化とリスクの管理を行う経験的プロセス制御の実現は透明性検査適応の 3 本柱に支えられている透明性経験的プロセスで重要なのは結果責任を持つ者に対して見える化されていることである透明性とはこうしたことが標準化され見ている人が共通理解を持つことである例 : プロセスの用語を参加者全員で共有している作業する人とそのインクリメントを検査する人が完成の定義を共有している検査スクラムのユーザーはスクラムの作成物やスプリントゴールの進捗を頻繁に検査し好ましくない変化を検知するただし頻繁にやりすぎて作業の妨げになってはいけないスキルの高い検査担当者が念入りに行えば検査は最大の効果をもたらす適応プロセスの不備が許容値を超え成果となるプロダクトを受け入れられないと検査担当者が判断した場合はプロセスやその構成要素を調整する必要がある調整はできるだけ早く行いこれ以上の逸脱を防がなければいけない Page 4

5 スクラムでは検査と適応のための 4 つの公式なイベントを規定している詳しくはスクラムイベントの節で説明するスプリントプランニングデイリースクラムスプリントレビュースプリントレトロスペクティブスクラムの価値基準スクラムチームが確約 (commitment) 勇気 (courage) 集中 (focus) 公開 (openness) 尊敬 (respect) の価値基準を取り入れそれらを実践するときスクラムの柱 ( 透明性検査適応 ) は現実のものとなりあらゆる人に対する信頼が築かれるスクラムチームのメンバーはスクラムの役割イベント作成物に触れて仕事を進めるなかでこれらの価値基準を学習探索するスクラムを活用するにはこれらの 5 つの価値基準を上手に実践しなければいけない個人はスクラムチームのゴールの達成を確約しなければいけないスクラムチームのメンバーは正しいことをする勇気を持ち困難な問題に取り組まなければいけない全員がスプリントの作業とスクラムチームのゴールに集中しなければいけないスクラムチームとステークホルダーはすべての仕事とそれらを遂行する上での課題を公開することに合意しなければいけないスクラムチームのメンバーはお互いを能力のある独立した個人として尊敬しなければいけないスクラムチームスクラムチームはプロダクトオーナー開発チームスクラムマスターで構成されるスクラムチームは自己組織化されており機能横断的である自己組織化チームは作業を成し遂げるための最善の策をチーム外からの指示ではなく自分たちで選択する機能横断的チームはチーム以外に頼らずに作業を成し遂げる能力を持っているスクラムにおけるチームのモデルは柔軟性創造性生産性を最適化するように設計されているスクラムチームは前述した用途や複雑な仕事において非常に高い効果を自ら証明しているスクラムチームはプロダクトを反復的漸進的に届けるこれはフィードバックの機会を最大化するためである完成したプロダクトを漸進的に届けることで動作するプロダクトで役に立つ可能性のあるバージョンを常に利用可能にするプロダクトオーナープロダクトオーナーは開発チームから生み出されるプロダクトの価値の最大化に責任を持つ組織スクラムチーム個人によってその方法はさまざまであるプロダクトオーナーはプロダクトバックログの管理に責任を持つ 1 人の人間であるプロダクトバックログの管理には以下のようなものがあるプロダクトバックログアイテムを明確に表現するゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える開発チームが行う作業の価値を最適化する Page 5

6 プロダクトバックログを全員に見える化透明化明確化しスクラムチームが次に行う作業を示す必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう上記の作業はプロダクトオーナーが行う場合もあれば開発チームが行う場合もあるいずれの場合も最終的な責任はプロダクトオーナーが持つプロダクトオーナーは 1 人の人間であり委員会ではない委員会の要求をプロダクトバックログに反映することもあるだろうがプロダクトバックログアイテムの優先順位の変更についてはプロダクトオーナーと相談しなければいけないプロダクトオーナーをうまく機能させるには組織全体でプロダクトオーナーの決定を尊重しなければいけないプロダクトオーナーの決定はプロダクトバックログの内容や並び順という形で見える化されている異なる要求の作業を開発チームに強制することは誰にもできない開発チーム開発チームは各スプリントの終了時にリリース判断可能な完成したプロダクトインクリメントを届けることのできる専門家で構成されている完成したインクリメントはスプリントレビューに必要であるインクリメントを作成できるのは開発チームのメンバーだけである開発チームは自分たちの作業を構成管理するために組織から体制と権限を与えられているその相乗効果によって開発チーム全体の効率と効果が最適化される開発チームには以下のような特徴がある自己組織化されているプロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は誰も ( スクラムマスターでさえも ) 教えてくれない機能横断的であるインクリメントを作成するスキルをチームとしてすべて備えているある人にしかできない作業があったとしてもスクラムにおける開発チームのメンバーに肩書きはないテスティングアーキテクチャ運用ビジネス分析のような専門領域であってもスクラムは開発チームのサブチームを認めていない開発チームのメンバーに専門能力や専門分野があったとしても最終的な責任は開発チーム全体が持つ開発チームの規模開発チームに最適な人数は小回りが利く程度に少なく 1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である開発チームのメンバーが 3 人未満の場合は相互作用が少なく生産性の向上につながらないまた開発チームの規模が小さいとスキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もあるメンバーが 9 人を超えた場合は調整の機会が多くなってしまうまたチームの規模が大きいと経験的プロセスが複雑になり有益ではなくなるスプリントバックログの作業に携わらないのであればプロダクトオーナーとスクラムマスターはこの人数に含まない Page 6

7 スクラムマスタースクラムマスターはスクラムガイドで定義されたスクラムの促進と支援に責任を持つスクラムマスターはスクラムの理論プラクティスルール価値基準を全員に理解してもらえるように支援することでその責任を果たすスクラムマスターはスクラムチームのサーバントリーダーである ( 訳注 : メンバーが成果を上げるために支援や奉仕をするリーダーのこと ) スクラムマスターはスクラムチームとやり取りをするときに役に立つこと / 立たないことをスクラムチームの外部の人たちに理解してもらうスクラムマスターはこうしたやり取りに変化をもたらすことでスクラムチームの作る価値を最大化するスクラムマスターはプロダクトオーナーを支援するスクラムマスターはさまざまな形でプロダクトオーナーを支援するスクラムチームの全員がゴールスコーププロダクトのドメインを可能な限り理解できるようにする効果的なプロダクトバックログの管理方法を探す明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう経験主義におけるプロダクトプランニングについて理解する価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握してもらうアジャイルを理解実践している必要に応じてスクラムイベントをファシリテートするスクラムマスターは開発チームを支援するスクラムマスターはさまざまな形で開発チームを支援する自己組織化機能横断的な開発チームをコーチする開発チームが価値の高いプロダクトを作れるように支援する開発チームの進捗を妨げるものを排除する必要に応じてスクラムイベントをファシリテートするスクラムがまだ完全に適用理解されていない組織環境で開発チームをコーチするスクラムマスターは組織を支援するスクラムマスターはさまざまな形で組織を支援する組織へのスクラムの導入を指導コーチする組織へのスクラムの導入方法を計画するスクラムや経験的プロダクト開発を社員やステークホルダーに理解実施してもらうスクラムチームの生産性を高めるような変化を促す他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める Page 7

8 スクラムイベントスクラムで規定されたイベントは規則性を作り出しスクラムで定義されていないミーティングの必要性を最小化するすべてのイベントは時間に上限のあるタイムボックス化されたイベントであるスプリントを開始するとその期間は固定され増減することはできないスプリント以外のイベントについては目的が達成されたときに終了することもあるこれはプロセスでムダなことをせずに必要な分だけ時間を使うためであるスプリント以外のスクラムイベントは何かを検査適応するための公式な機会である ( スプリントはその他のイベントの入れ物である ) これらのイベントは非常に重要な透明性と検査の両方が実現できるように設計されているこれらのイベントがなければ透明性は低下し検査適応の多くの機会を失うスプリントスクラムの中心はスプリントであるこれは完成した利用可能なリリース判断可能なプロダクトインクリメントを作るための 1 か月以下のタイムボックスである開発中はスプリントの長さは常に一定であるスプリントが終了するとすぐに新しいスプリントが開始されるスプリントはスプリントプランニングデイリースクラム開発作業スプリントレビュースプリントレトロスペクティブで構成されるスプリントではスプリントゴールに悪影響を及ぼすような変更を加えない品質目標を下げない学習が進むにつれてスコープが明確化されプロダクトオーナーと開発チームの交渉が必要になる可能性があるスプリントは 1 か月以内のプロジェクトと考えることができるプロジェクトと同様にスプリントは何かを成し遂げるために使うものであるスプリントには開発対象のゴール開発のための設計や柔軟な計画実際の作業成果となるプロダクトインクリメントが含まれるスプリントの期間は 1 か月以内に制限されているスプリントが長すぎると開発対象の定義が変更されたり複雑になったりリスクが増大したりする可能性があるゴールに対する進捗を少なくとも 1 か月ごとに検査適応することで予測可能性が高まるのであるまたリスクも 1 か月分のコストに収まるようになるスプリントの中止スプリントはタイムボックスの終了前に中止できるスプリントを中止する権限があるのはプロダクトオーナーだけであるこのときにステークホルダー開発チームスクラムマスターの意見を参考にすることもできるスプリントゴールが古くなった場合はスプリントを中止することになるだろう会社の方向性や市場技術の状況が変化するとスプリントゴールは古くなってしまう状況を考慮して意味がなくなったと思えばスプリントを中止すべきであるただしスプリントの期間は短いので中止したからといって影響があることはほとんどない Page 8

9 スプリントを中止した場合はプロダクトバックログの完成したアイテムをレビューする部分的にリリース判断可能なものについては通常はプロダクトオーナーが受け入れる未完成のプロダクトバックログアイテムは再見積りをしてからプロダクトバックログに戻すそこにかかった作業の価値は急速に低下するため頻繁に再見積りが必要になる ( 訳注 : 作りかけの機能や設計については時間が経つと状況が変わってしまうためその価値が失われてしまうことが多いそうすると最初から見積りをやり直す必要が出てくる ) スプリントを中止すると新しいスプリントのスプリントプランニングのために全員が再度集まる必要がありリソースを消費してしまうまたスプリントの中止がチームのトラウマになってしまうこともあるとはいえスプリントの中止はめったに発生しないスプリントプランニングスプリントの作業はスプリントプランニングで計画するこれはスクラムチームの共同作業であるスプリントが 1 か月の場合スプリントプランニングのタイムボックスは最大で 8 時間であるスプリントの期間が短ければスプリントプランニングの時間も短くすることが多いスクラムマスターは参加者に目的を理解してもらうようにするスクラムマスターはスクラムチームにタイムボックスを守るように伝えるスプリントプランニングでは以下の質問に答えるスプリントの成果であるインクリメントで何を届けることができるか? インクリメントを届けるために必要な作業をどのように成し遂げるか? トピック 1: スプリントで何ができるか? 開発チームはスプリントで開発できそうな機能を予想するプロダクトオーナーはスプリントで達成すべき目的と完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムについて検討するスクラムチームはみんなで協力してスプリントの作業を理解するスプリントプランニングのインプットはプロダクトバックログ最新のプロダクトインクリメント開発チームが予想するキャパシティと過去の実績であるプロダクトバックログから選択するアイテム数については開発チームが責任を持つスプリントで何を達成するかを評価できるのは開発チームだけであるスプリントプランニングではスクラムチームがスプリントゴールを設定するスプリントゴールとはプロダクトバックログを実装することで実現するスプリントの目的であり開発チームがインクリメントを開発する指針となるものであるトピック 2: 選択した作業をどのように成し遂げるか? プロダクトバックログアイテムを選択しスプリントゴールを設定したら開発チームはスプリントでそれらの機能を完成したプロダクトインクリメントにする方法を決める選択したプロダクトバックログアイテムとそれらを届ける計画を合わせてスプリントバックログと呼ぶ開発チームはプロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシステムと作業の設計から着手する作業の規模や工数はバラバラであっても構わないが開発チームが次のスプリントで実現できそうなものを計画する開発チームがスプリントの最初の数日間で行う作業についてはスプリントプランニングで作業に分解する作業の単位は 1 日以下にするこ Page 9

10 とが多い開発チームは自己組織化してスプリントバックログの作業を引き受けるこれはスプリントプランニングだけでなく必要であればスプリントでも行うプロダクトオーナーは選択したプロダクトバックログアイテムの明確化やトレードオフを支援する開発チームの作業が多すぎたり少なすぎたりした場合は選択されたプロダクトバックログアイテムについて開発チームとプロダクトオーナーで話し合うあるいは技術やドメインに詳しい人を招待してアドバイスを求めることもできるスプリントプランニングが終了するまでに開発チームは自己組織化したチームとしてどのようにスプリントゴールを達成しどのように期待されるインクリメントを作成するかをプロダクトオーナーとスクラムマスターに説明できなければいけないスプリントゴールスプリントゴールはスプリントの目的の集合でありプロダクトバックログの実装によって実現するものであるこれは開発チームがインクリメントを構築する理由を知る指針となるスプリントゴールはスプリントプランニングで作成するスプリントゴールを設定することで開発チームがスプリント終了までに実装する機能を柔軟にできる選択したプロダクトバックログアイテムは一貫性のある機能として届けられるそれがスプリントゴールになることもあるスプリントゴールがあれば開発チームは一致団結して作業ができる開発チームが作業するときにはスプリントゴールを念頭に置くスプリントゴールを達成するために機能や技術を実装する開発チームの予想と異なることが判明した場合はプロダクトオーナーと交渉してスプリントバックログのスコープを調整するデイリースクラムデイリースクラムとは開発チームのための 15 分間のタイムボックスのイベントであるスプリントでは毎日デイリースクラムを開催する開発チームは次の 24 時間の作業を計画する前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることでチームのコラボレーションやパフォーマンスを最適化するのであるデイリースクラムは毎日同じ時間場所で開催し複雑にならないようにする開発チームはデイリースクラムを使ってスプリントゴールとスプリントバックログの進捗を検査するデイリースクラムは開発チームがスプリントゴールを達成する可能性を最適化する開発チームは自己組織化チームとしてスプリントゴールを達成しスプリント終了までに期待されるインクリメントを作成できるかを毎日把握しなければいけないデイリースクラムの構成は開発チームが設定するスプリントゴールを目指している限り他のやり方で行なっても構わない質問を使うチームもあれば議論ベースで進めるチームもあるたとえば以下のような例を使用するといいだろう開発チームがスプリントゴールを達成するために私が昨日やったことは何か? 開発チームがスプリントゴールを達成するために私が今日やることは何か? 私や開発チームがスプリントゴールを達成する上で障害となる物を目撃したか? 開発チームやチームメンバーはデイリースクラムの終了直後に集まりスプリントの残作業について詳細な議論適応再計画を行うこともある Page 10

11 スクラムマスターは開発チームにデイリースクラムを開催してもらうようにするただしデイリースクラムを開催する責任は開発チームにあるスクラムマスターはデイリースクラムを 15 分間のタイムボックスで終わらせるように開発チームに伝えるデイリースクラムは開発チームのためのミーティングであるそれ以外の人たちが参加する場合開発チームの邪魔にならないようにスクラムマスターが配慮するデイリースクラムはコミュニケーションを改善しその他のミーティングを取り除き開発の障害物を特定排除し迅速な意思決定を強調助長して開発チームのプロジェクト知識のレベルを向上させるものであるこれは検査と適応の重要なイベントであるスプリントレビュースプリントレビューとはスプリントの終了時にインクリメントの検査と必要であればプロダクトバックログの適応を行うものであるスプリントレビューではスクラムチームとステークホルダーがスプリントの成果をレビューするスプリントの成果とプロダクトバックログの変更を参考にして価値を最適化するために次に何ができるかを参加者全員で話し合うこれはステータスミーティングではなく略式のミーティングであるインクリメントを提示することでフィードバックや協力を引き出すことを目的とするスプリントが 1 か月の場合スプリントレビューは最大 4 時間であるスプリントの期間が短ければスプリントレビューの時間も短くすることが多いスクラムマスターはスプリントレビューが確実に開催されるようにして参加者には目的を理解してもらうようにするスクラムマスターは関係者全員にタイムボックスを守るように伝えるスプリントレビューには以下の要素が含まれる参加者はスクラムチームとプロダクトオーナーが招待した重要なステークホルダーであるプロダクトオーナーはプロダクトバックログアイテムの完成したものと完成していないものについて説明する開発チームはスプリントでうまくいったこと直面した問題点それをどのように解決したかを議論する開発チームは完成したものをデモしてインクリメントに対する質問に答える完成の定義にプロダクト機能のリリースが含まれていればそれらを表示してレビューしてもらうプロダクトオーナーは現在のプロダクトバックログの状況を説明する ( 必要であれば ) 現在の進捗から可能性のある目標とデリバリーの日程を予測するグループ全体で次に何をするべきかを議論し次のスプリントプランニングに価値のあるインプットを提供できるようにする市場やプロダクトの利用状況によって次に行うべき最も価値の高いことが変更される可能性をレビューする次にリリースするプロダクトの機能や性能のスケジュール予算可能性市場をレビューするスプリントレビューの成果は次のスプリントで使用するプロダクトバックログアイテムが含まれた改訂版のプロダクトバックログである新たな機会に見合うようにプロダクトバックログを全体的に調整することもある Page 11

12 スプリントレトロスペクティブスプリントレトロスペクティブはスクラムチームの検査と次のスプリントの改善計画を作成する機会であるスプリントレトロスペクティブはスプリントレビューが終わって次のスプリントプランニングが始まる前に行うスプリントが 1 か月の場合スプリントレトロスペクティブは最大 3 時間であるスプリントの期間が短ければスプリントレトロスペクティブの時間も短くすることが多いスクラムマスターはこのイベントが確実に開催されるようにするまた参加者に目的を理解してもらうようにするスクラムマスターはこのミーティングがポジティブで生産的になるようにするスクラムマスターは全員にタイムボックスを守るように伝えるスクラムマスターはスクラムのプロセスを説明するためにチームメンバーとして参加するスプリントレトロスペクティブには以下の目的がある人関係プロセスツールの観点から今回のスプリントを検査するうまくいった項目や今後の改善が必要な項目を特定整理するスクラムチームの作業の改善実施計画を作成するスクラムマスターは次のスプリントが効果的で楽しいものになるように開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらうスプリントレトロスペクティブではスクラムチームは作業プロセスの改善や完成の定義の調整によってプロダクトの品質を向上させる方法を計画するただしプロダクトや組織の基準と衝突しないように適切に行うスプリントレトロスペクティブが終わるまでにスクラムチームは次のスプリントで実施する改善策を特定しなければいけないこれらの改善策の実施はスクラムチーム自体の検査に対する適応になる改善はいつでも実施可能だがスプリントレトロスペクティブは検査と適応に集中するための公式な機会であるスクラムの作成物スクラムの作成物は作業や価値を表したものであり透明性や検査適応の機会を提供するものであるスクラムで定義された作成物は全員が共通理解を得るために必要な情報の透明性を最大化するように設計されているプロダクトバックログプロダクトバックログはプロダクトに必要だと把握しているものをすべて順番に並べた一覧であるプロダクトに対する変更要求の唯一の情報源であるプロダクトオーナーはプロダクトバックログの内容可用性並び順に責任を持つプロダクトバックログは決して完成しない構築の初期段階には明確でよく理解できている要求が並べられているその後プロダクトや使用環境に合わせて進化するプロダクトバックログは動的であり適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化するプロダクトが存在する限りプロダクトバックログも存在し続けるのである Page 12

13 プロダクトバックログは今後のリリースで実装するプロダクトのフィーチャ機能要求要望修正をすべて一覧にしているプロダクトバックログアイテムには詳細並び順見積り価値の属性があるプロダクトバックログアイテムには完成時にそれを確認するためのテスト記述も含まれていることが多いプロダクトが使用されて価値が増加し市場からフィードバックを得られるとプロダクトバックログは巨大で包括的な一覧になる要求の変更は止まらないプロダクトバックログは生きた作成物であるビジネス要求市場の状態技術の変化などがプロダクトバックログの変化につながる複数のスクラムチームが同じプロダクトの作業をすることがよくあるそうした場合プロダクトの作業は 1 つのプロダクトバックログに記述するまたアイテムを分類するための属性をプロダクトバックログに追加することもあるプロダクトバックログに含まれるアイテムに対して詳細の追加見積り並び替えをすることをプロダクトバックログのリファインメントと呼ぶこれはプロダクトオーナーと開発チームが協力して行う継続的なプロセスであるプロダクトバックログのリファインメントによってアイテムのレビューと改訂が行われるいつどのようにリファインメントをするかはスクラムチームが決定するリファインメントは開発チームの作業の 10% 以下にすることが多いただしプロダクトバックログアイテムはプロダクトオーナーの判断によっていつでも更新できる並び順が上のプロダクトバックログアイテムほど明確で詳細である明確で詳細であれば見積りも正確になる並び順が下のアイテムほど不正確で詳細ではない今後のスプリントで開発チームが従事するプロダクトバックログアイテムはスプリントのタイムボックスで完成できるようにうまく細分化する開発チームが 1 つのスプリントで完成できそうなプロダクトバックログアイテムはスプリントプランニングで選択できる準備完了 (Ready) の状態になったと見なすことができるプロダクトバックログアイテムは上記のリファインメントによって透明性を獲得することが多い開発チームは見積りに対して責任を持つプロダクトオーナーがトレードオフの理解や選択などについて開発チームに影響を及ぼすこともあるが最終的な見積りは実際に作業をする人が行うゴールへの進捗を追跡するいずれかの時点でゴールに対する残作業を合計するプロダクトオーナーは少なくともスプリントレビューにおいてこの残作業の合計を追跡するプロダクトオーナーは前回のスプリントレビュー時点の残作業の合計と比較して希望する期日までにゴールに到達できるかどうかを評価するこの情報はステークホルダー全員に明らかにする進捗の見通しを立てるためにバーンダウンバーンアップ累積フローなどのさまざまなプラクティスが使用されているこれらは有用ではあるが経験主義の重要性を置き換えるものではない複雑な環境下では何が起きるかわからないすでに発生したことだけがこれから先の意思決定に使用できるスプリントバックログスプリントバックログはスプリントで選択したプロダクトバックログアイテムとそれらのアイテムをプロダクトインクリメントにして届けスプリントゴールを達成するための計画を合わせたものであるスプリントバックログは次のインクリメントに含まれる機能とその機能を完成したインクリメントにして届けるために必要な作業について開発チームが予想したものである Page 13

14 スプリントバックログによって開発チームがスプリントゴールを達成するのに必要な作業がすべて見える化されている継続的改善を確実なものとするために前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておくスプリントバックログは十分に詳細であり今後も変更される可能性のある計画であるそれはデイリースクラムで理解できる程度のものである開発チームはスプリントでスプリントバックログを修正するスプリントバックログはスプリントで創発されるこうした創発が発生するのは開発チームが計画を実行するなかでスプリントゴールの達成に必要な作業を学習するからである新しい作業が必要になれば開発チームがスプリントバックログに作業を追加する作業が完了すれば残作業の見積りを更新する計画の要素が不要になれば削除するスプリントでスプリントバックログを変更できるのは開発チームだけであるスプリントバックログには開発チームがスプリントで行う作業がリアルタイムに反映されるスプリントバックログは開発チームのものであるスプリントの進捗を追跡するスプリントのいずれかの時点でスプリントバックログの残作業を合計する開発チームは少なくともデイリースクラムにおいてこの残作業の合計を追跡しスプリントゴールの達成に見通しを立てる開発チームはスプリントで残作業を追跡し自分たちの進捗を管理するインクリメントインクリメントとはこれまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものであるスプリントの終了時には新しいインクリメントが完成していなければいけないつまりインクリメントが動作する状態でありスクラムチームの完成の定義に合っていることを意味するインクリメントは完成していて検査可能なものでありスプリントの終了時の経験主義を支援するものであるインクリメントはビジョンやゴールに向かうステップであるプロダクトオーナーがリリースを決定する / しないにかかわらずインクリメントは常に動作する状態にしておかなければいけない作成物の透明性スクラムは透明性に依存している作成物の状態を把握することで価値の最適化やリスクの制御に関する決定を行う透明性が確保されている限りこうした決定には信頼できる根拠が存在する作成物の透明性が不完全であればこうした決定には不備があり価値は低減しリスクが高まる可能性があるスクラムマスターはプロダクトオーナー開発チームその他の関係者と一緒になって作成物が完全に透明化されているかを理解する不完全な透明性に対処するにはいくつかのプラクティスが存在するスクラムマスターはそのなかから最適なプラクティスを選択してもらえるように支援するスクラムマスターは作成物の検査パターンの察知言説の傾聴期待値と実際値の違いを把握することで不完全な透明性を検知できるスクラムマスターの仕事はスクラムチームや組織と一緒になって作成物の透明性を向上させることであるこの仕事には学習説得変化を伴うことが多い透明性は一夜にしてならず透明性とは長い道のりなのである Page 14

15 完成 (Done) の定義プロダクトバックログアイテムやインクリメントの完成を決めるときには全員がその完成の意味を理解しておかなければいけないスクラムチームによってその意味は大きく異なるかもしれないが作業の完了についてメンバーが共通の理解を持ち透明性を確保しなければいけないこれはスクラムチームの完成の定義と呼ばれプロダクトインクリメントの作業が完了したかどうかの評価に使われるこの定義は開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択するかの指針にもなる各スプリントの目的はそのときの完成の定義に合ったリリース判断可能な機能のインクリメントを届けることである開発チームはスプリントごとにプロダクトインクリメントを届けるインクリメントは実際に利用可能なものでありプロダクトオーナーがすぐにリリースすることもできるインクリメントの完成の定義に関して開発組織の慣例標準ガイドラインが存在する場合はスクラムチームは最低でもそれを守らなければいけないインクリメントの完成の定義が開発組織に存在しない場合はスクラムチームの開発チームはプロダクトに適した完成を定義しなければいけない複数のスクラムチームがシステムやプロダクトのリリース作業をする場合はすべてのスクラムチームの開発チームが共通の完成の定義を使用しなければいけないインクリメントはそれまでのインクリメントに追加されたものでありすべてが正常に動くように十分にテストされたものであるスクラムチームが成熟していくと完成の定義にさらに厳しい品質条件を追加することもある新しい定義を作りそれを使用していくと以前に完成したインクリメントにも手を加えなければいけないことが明らかになる可能性があるあらゆるプロダクトやシステムは完成の定義を備えるべきであるそれがあらゆる作業の完了基準となる最後にスクラムは無料であり本ガイドで提供されるものであるスクラムの役割イベント作成物ルールは不変であるスクラムの一部だけを導入することも可能だがそれはスクラムとは言えないすべてをまとめたものがスクラムでありその他の技法方法論プラクティスのコンテナとして機能する謝辞人々スクラムに貢献してくれた非常に多くの人たちのなかでも最初に貢献してくれた人物の名前を挙げたいまず Jeff Sutherland と一緒に働いた Jeff McKenna と John Scumniotales それから Ken Schwaber と一緒に働いた Mike Smith と Chris Martin と同僚たち翌年からはその他にも多くの人たちが貢献してくれた彼らの助けがなければスクラムは今日のように洗練されていなかっただろう Page 15

16 歴史 Ken Schwaber と Jeff Sutherland が 1995 年からスクラムに取り組み 1995 年の OOPSLA カンファレンスにおいてスクラムを共同発表したこの発表は Ken と Jeff が過去数年間で学んだことを文書化したものでありはじめて公開された正式なスクラムの定義であるスクラムの歴史は別のところで説明されている最初の試行錯誤の場である Individual, Inc. Newspage Fidelity Investments IDX( 現 GE Medical) に感謝したいスクラムガイドは Jeff Sutherland と Ken Schwaber が 20 年以上かけて開発進化保守してきたスクラムを文書化したものであるその他の情報源ではスクラムフレームワークを補完するパターンプロセスインサイトなどが提供されているこれらは生産性価値創造性結果に対する満足を高める可能性がある翻訳本ガイドは Ken Schwaber と Jeff Sutherland による英語バージョンを日本語に翻訳したものである日本語訳は角征典が担当した最新版の翻訳は守田憲司さん高江洲睦さん永瀬美穂さん栗秋宏徳さん川口恭伸さん角谷信太郎さん木村卓央さん原田騎郎さん吉羽龍太郎さんにご協力いただいた以前の版ではむらはしけんいちさんいろさんたなべすなおさんにもご協力いただいた翻訳に関する連絡先 : 角征典 (kdmsnr@gmail.com) スクラムガイド 2016 年版と 2017 年版の変更点 1. スクラムの用途のセクションを追加した当初スクラムはプロダクトの開発と管理のために開発された 1990 年代初頭から使用され今では以下のように世界中で広く利用されている 1. 有望な市場技術プロダクトの研究および特定 2. プロダクトや追加機能の開発 3. プロダクトや追加機能のリリース (1 日に何度もリリースされる ) 4. プロダクトが使用するクラウド ( オンラインセキュアオンデマンド ) やその他運用環境の開発と保守 5. プロダクトの保守や刷新スクラムはソフトウェアハードウェア組込みソフトウェア機能同士を接続するネットワーク自動運転車などの開発から学校政府マーケティング組織運営マネジメントに至るまで個人や社会が日常的に使用するあらゆるものに使用されている技術市場環境の複雑化やそれらの相互作用は急速に高まっておりスクラムがその対応に有効であることは日々証明されているスクラムは反復的で漸進的な知識移転において特に有効であることが示されている今ではプロダクトサービス所属する組織の管理に広く利用されている Page 16

17 スクラムの本質は少人数制のチームである個々のチームは非常に柔軟で適応力に優れているこうした強みは単一のチームであっても複数あるいは多数のチームであっても数千人の成果やプロダクトを開発リリース運用保守するネットワーク型のチームであっても有効であるチームは協力や情報交換をしながら洗練された開発アーキテクチャやターゲットとするリリース環境を整えていくスクラムガイドで開発や開発するといった言葉が登場するときそれは上記のような複雑な作業を意味している 2. スクラムマスターのセクションの表現を変更し役割を明確化したスクラムマスターはスクラムガイドで定義されたスクラムの促進と支援に責任を持つそのためにスクラムマスターはスクラムの理論プラクティスルール価値基準を全員に理解してもらえるように支援するスクラムマスターはスクラムチームのサーバントリーダーである ( 訳注 : メンバーが成果を上げるために支援や奉仕をするリーダーのこと ) スクラムマスターはスクラムチームとやり取りをするときに役に立つこと / 立たないことをスクラムチームの外部の人たちに理解してもらうスクラムマスターはこうしたやり取りに変化をもたらすことでスクラムチームの作る価値を最大化する 3. スクラムマスターはプロダクトオーナーを支援するのセクションに以下を追加したスクラムチームの全員がゴールスコーププロダクトのドメインを可能な限り理解できるようにする 4. デイリースクラムのセクションの最初の段落を以下のように変更したデイリースクラムとは開発チームのための 15 分間のタイムボックスのイベントであるスプリントでは毎日デイリースクラムを開催する開発チームは次の 24 時間の作業を計画する前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることでチームのコラボレーションやパフォーマンスを最適化するのであるデイリースクラムは毎日同じ時間場所で開催し複雑にならないようにする 5. デイリースクラムのセクションを変更してデイリースクラムのゴールを明確化したデイリースクラムの構成は開発チームが設定するスプリントゴールを目指している限り他のやり方で行なっても構わない質問を使うチームもあれば議論ベースで進めるチームもあるたとえば以下のような例を使用するといいだろう開発チームがスプリントゴールを達成するために私が昨日やったことは何か? 開発チームがスプリントゴールを達成するために私が今日やることは何か? 私や開発チームがスプリントゴールを達成する上で障害となる物を目撃したか? 6. タイムボックスについて明確化した最大という言葉を追加してイベントを時間どおりに行なう必要があるのかという疑問を解消し許容される最大の時間であることを明確にした 7. スプリントバックログのセクションに以下を追加した継続的改善を確実なものとするために前回のレトロスペクティブで特定した優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく Page 17

18 8. インクリメントのセクションが明確になるように以下を追加したインクリメントは完成していて検査可能なものでありスプリントの終了時の経験主義を支援するものであるインクリメントはビジョンやゴールに向かうステップである Page 18

目次スクラムガイドの目的... 3 スクラムの定義... 3 スクラムの理論... 3 スクラムの価値基準... 4 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム... 5 スクラムマスター... 6 スクラムイベント... 7 スプリント... 7 スプリントプランニング.

目次スクラムガイドの目的... 3 スクラムの定義... 3 スクラムの理論... 3 スクラムの価値基準... 4 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム... 5 スクラムマスター... 6 スクラムイベント... 7 スプリント... 7 スプリントプランニング. スクラムガイドスクラム完全ガイド : ゲームのルール 2016 年 7 月 Developed and sustained by Ken Schwaber and Jeff Sutherland 目次スクラムガイドの目的... 3 スクラムの定義... 3 スクラムの理論... 3 スクラムの価値基準... 4 スクラムチーム... 5 プロダクトオーナー... 5 開発チーム... 5 スクラムマスター...