スクラムというフレームワークに則ってやらないと
Railsを使って規約を無視して書いてRails使えないと言うのと同じだと
スクラムマスターよりアドバイスいただいたので
おのおのスクラムガイドについて考えて欲しい

なお、スクラムガイドの著作権をきちんと読んでいないので
問題があったら即座に削除します。
スクラムガイドの翻訳をした角征典さん、著者のKen SchwaberとJeff Sutherlandに感謝
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

スクラムガイドの目的

スクラムは、複雑なプロダクトを開発・提供・保守するためのフレームワークである。本ガイドでは、
スクラムの定義を説明する。スクラムの定義には、スクラムの役割・イベント・作成物と、それらをまと
めるルールが含まれる。スクラムは、Ken Schwaber と Jeff Sutherland が開発したものであり、スクラ
ムガイドはこの 2 人が執筆・提供する。両者は共にスクラムガイドを支援している。
スクラムの定義
スクラム（名詞）：複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価
値の高いプロダクトを生産的かつ創造的に届けるためのものである。
スクラムとは、以下のようなものである。
• 軽量
• 理解が容易
• 習得は困難
スクラムは、1990 年代初頭から複雑なプロダクトの作業管理に使用されてきたプロセスフレームワ
ークである。プロダクトを構築するプロセス、技法、決定的な方法論などではない。さまざまなプロ
セスや技法を取り入れることのできるフレームワークである。スクラムは、これまでのプロダクト管理
や仕事のテクニックの相対的な有効性を明確にして、プロダクト・チーム・作業環境の継続的な改
善を可能にする。
スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。
それぞれに目的があり、スクラムの成功や利用に欠かせない。
スクラムのルールは、役割・イベント・作成物をまとめ、それらの関係性や相互作用を統括するもの
である。スクラムのルールについては、本稿全体で説明する。
スクラムフレームワークを使用する具体的な方法にはさまざまなものがあり、それらについては本
稿では触れない。

軽量

覚えることが少ないから軽量と聞いたけど最近は微妙だと個人としては感じているよ

理解が容易

覚える用語は多くて、スクラムマスターにとっては理解はとても大変、チーム、POに対して理解できる言葉で伝えるのが大事なんだと教わった。このスクラムガイドすら読まないでスクラム開発している例はたくさんあるよ。

習得は困難

スクラムマスター認定試験でもスクラムの型を教えてくれるだけと伺った
常に応用なので大変だよ

複雑なプロダクトの作業管理に使用されてきたプロセスフレームワークである。プロダクトを構築するプロセス、技法、決定的な方法論などではない

複雑なのは仕事なら当たり前だよね。フレームワークと定義していることが大事

スクラムの用途

当初、スクラムはプロダクトの開発と管理のために開発された。1990 年代初頭から使用され、今で
は以下のように世界中で広く利用されている。
1. 有望な市場・技術・プロダクトの研究および特定
2. プロダクトや追加機能の開発
3. プロダクトや追加機能のリリース（1 日に何度もリリースされる）
4. プロダクトが使用するクラウド（オンライン、セキュア、オンデマンド）やその他運用環境の開発と保守
5. プロダクトの保守や刷新
スクラムは、ソフトウェア、ハードウェア、組込みソフトウェア、機能同士を接続するネットワーク、自
動運転車などの開発から、学校、政府、マーケティング、組織運営マネジメントに至るまで、個人
や社会が日常的に使用するあらゆるものに使用されている。
技術・市場・環境の複雑化やそれらの相互作用は急速に高まっており、スクラムがその対応に有
効であることは日々証明されている。
スクラムは反復的で漸進的な知識移転において特に有効であることが示されている。今では、プ
ロダクト、サービス、所属する組織の管理に広く利用されている。
スクラムの本質は、少人数制のチームである。個々のチームは非常に柔軟で適応力に優れている。
こうした強みは、単一のチームであっても、複数あるいは多数のチームであっても、数千人の成果
やプロダクトを開発・リリース・運用・保守するネットワーク型のチームであっても有効である。チー
ムは協力や情報交換をしながら、洗練された開発アーキテクチャやターゲットとするリリース環境を
整えていく。
スクラムガイドで「開発」や「開発する」といった言葉が登場するとき、それは上記のような複雑な作
業を意味している。

スクラムは反復的で漸進的な知識移転において特に有効

言葉が少し難しい
漸進的・・・物事を徐々に進めていくさま
知識移転・・・学習方法の1つ。送り手の頭の中にある知識を受け手の頭の中に再構築する
スクラムの中でよく出てくるペアプロ、モブプロは知識移転のためだとわかる

スクラムの理論

スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経
験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸
進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。
透明性
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明
性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
例：
• プロセスの用語を参加者全員で共有している。
• 作業する人とそのインクリメントを検査する人が「完成」の定義を共有している。
検査
スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない
変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査
担当者が念入りに行えば、検査は最大の効果をもたらす。
適応
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断し
た場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以
上の逸脱を防がなければいけない。
は、検査と適応のための 4 つの公式なイベントを規定している。詳しくは、「スクラムイベ
ント」の節で説明する。
• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

スクラムは、経験的プロセス制御の理論（経験主義）を基本

経験主義というのが大事。スクラムの最初はうまく回らなくて当たり前だよ
スクラムを止めたいという前にフレームワークに則っていたのかを確認して欲しいな。

予測可能性の最適化

何で予測ができるか。それは用語(暗黙知)と完成の定義が共有されているから工数が見積もれるんだ

リスクの管理

この場合のリスクは納期ではない。
適応の中で説明されている成果となるプロダクトを検査担当者が受け入れられないことを指すんだ

検査と適応のための 4 つの公式なイベントを規定している

規定(prescribes)だけど必須ではない。最初から4つやらなくていいよ。

スクラムの価値基準

スクラムチームが、確約（commitment）・勇気（courage）・集中（focus）・公開（openness）・尊敬
（respect）の価値基準を取り入れ、それらを実践するとき、スクラムの柱（透明性・検査・適応）は現
実のものとなり、あらゆる人に対する信頼が築かれる。スクラムチームのメンバーは、スクラムの役
割・イベント・作成物に触れて仕事を進めるなかで、これらの価値基準を学習・探索する。
スクラムを活用するには、これらの 5 つの価値基準を上手に実践しなければいけない。個人は、ス
クラムチームのゴールの達成を確約しなければいけない。スクラムチームのメンバーは、正しいこと
をする勇気を持ち、困難な問題に取り組まなければいけない。全員が、スプリントの作業とスクラム
チームのゴールに集中しなければいけない。スクラムチームとステークホルダーは、すべての仕事
とそれらを遂行する上での課題を公開することに合意しなければいけない。スクラムチームのメン
バーは、お互いを能力のある独立した個人として尊敬しなければいけない。

スクラムチームが、確約・勇気・集中・公開・尊敬の価値基準を取り入れ、それらを実践するとき、スクラムの柱（透明性・検査・適応）は現実のものとなり

スクラムチームが出来上がった後でメンバー追加が難しいのがここなんだ
スクラムの柱が確立してしまうと新しく来た人は今ある信頼関係に適応しないといけないんだ
スクラムチームの人員配置は課題になり続けるんじゃないかな。

スクラムチームのメンバーは、スクラムの役割・イベント・作成物に触れて仕事を進めるなかで、これらの価値基準を学習・探索する

確約・勇気・集中・公開・尊敬の価値基準は仕事を進めながら進めていくんだ。

全員が、スプリントの作業とスクラムチームのゴールに集中しなければいけない

現実には差し込みや兼業があってそれにどう対処するかはスクラム運用には必要だけどみんな悩んでいるよ

スクラムチームとステークホルダーは、すべての仕事とそれらを遂行する上での課題を公開することに合意しなければいけない

先に仕事の課題を公開できないと行き詰まることを示唆しているね

スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない

スクラムチーム

スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチー
ムは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための
最善の策を、チーム外からの指示ではなく、自分たちで選択する。機能横断的チームは、チーム
以外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟
性・創造性・生産性を最適化するように設計されている。スクラムチームは、前述した用途や複雑
な仕事において、非常に高い効果を自ら証明している。
スクラムチームは、プロダクトを反復的・漸進的に届ける。これは、フィードバックの機会を最大化
するためである。「完成」したプロダクトを漸進的に届けることで、動作するプロダクトで役に立つ可
能性のあるバージョンを常に利用可能にする。

機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている

現実的にはチーム以外に頼らず仕事というのは複雑なプロダクトでは滅多にない。先に遂行する上での課題としてクリアにする形になるんじゃないかな

動作するプロダクトで役に立つ可能性のあるバージョンを常に利用可能にする

プロダクトや追加機能のリリース（1 日に何度もリリースされる）の部分だね

プロダクトオーナー

プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組
織・スクラムチーム・個人によって、その方法はさまざまである。
プロダクトオーナーは、プロダクトバックログの管理に責任を持つ 1 人の人間である。プロダクトバ
ックログの管理には、以下のようなものがある。
• プロダクトバックログアイテムを明確に表現する。
• ゴールとミッションを達成できるようにプロダクトバックログアイテムを並び替える。
• 開発チームが行う作業の価値を最適化する。
• プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチームが次に行う作業を
示す。
• 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解してもらう。
上記の作業は、プロダクトオーナーが行う場合もあれば、開発チームが行う場合もある。いずれの
場合も、最終的な責任はプロダクトオーナーが持つ。
プロダクトオーナーは 1 人の人間であり、委員会ではない。委員会の要求をプロダクトバックログ
に反映することもあるだろうが、プロダクトバックログアイテムの優先順位の変更については、プロ
ダクトオーナーと相談しなければいけない。
プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなけ
ればいけない。プロダクトオーナーの決定は、プロダクトバックログの内容や並び順という形で見え
る化されている。異なる要求の作業を開発チームに強制することは誰にもできない。

プロダクトオーナー

スクラムの中で実践が難しいうちの一つだよね。
プロダクトオーナーが受託で用意できない、自社開発なのにプロダクトオーナー不在なんてのはよく聞く。
プロダクトオーナーにスクラムをお願いする時はスクラム用語を使わずにお願いしよう
プロダクトオーナーは大体偉い人なので時間確保は難しいし、定例は難しいかもしれない。なんとか時間を作ってもらおう
プロダクトオーナーは大変なので要件を決めてくれ！と言うより、こういう要件とか考えたけどあっている？と積極的に提案するのがよい
どうしても確保できない場合はプロダクトオーナーと一緒に行動し、彼の仕事を見せてもらおう

開発チーム

開発チームは、各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届
けることのできる専門家で構成されている。「完成」したインクリメントは、スプリントレビューに必要
である。インクリメントを作成できるのは、開発チームのメンバーだけである。
開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。
その相乗効果によって、開発チーム全体の効率と効果が最適化される。
開発チームには、以下のような特徴がある。
• 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変え
る方法は、誰も（スクラムマスターでさえも）教えてくれない。
• 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
• ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書
きはない。
• テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開
発チームのサブチームを認めていない。
• 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チー
ム全体が持つ。

開発チームの規模

開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂
げられる程度に多い人数である。開発チームのメンバーが 3 人未満の場合は、相互作用が少なく、
生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース
判断可能なインクリメントを届けられない可能性もある。メンバーが 9 人を超えた場合は、調整の
機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではな
くなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスタ
ーはこの人数に含まない。

最適な人数

この人数はマジックナンバー7±2に由来する、つまり最近の説では4±1でもあるかもしれない

スクラムマスター

スクラムマスターは、スクラムガイドで定義されたスクラムの促進と支援に責任を持つ。スクラムマス
ターは、スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらえるように支援する
ことで、その責任を果たす。
スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるた
めに支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするとき
に役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスタ
ーは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。

スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）

これはつまりスクラムマスターは成果のためにベロシティを計測しなければならないと言うことである
指示型のマネージャーとスクラムマスターは違うよって話。兼任は多いけどね。
マネージャーはスクラムの外である評価、承認に必要。
スクラムマスターとマネージャーが別になるとマネージャーの仕事は減ることになるね。

スクラムマスターはプロダクトオーナーを支援する

スクラムマスターは、さまざまな形でプロダクトオーナーを支援する。
• スクラムチームの全員がゴール、スコープ、プロダクトのドメインを可能な限り理解できるように
する。
• 効果的なプロダクトバックログの管理方法を探す。
• 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
• 経験主義におけるプロダクトプランニングについて理解する。
• 価値を最大化するためのプロダクトバックログの調整方法をプロダクトオーナーに把握しても
らう。
• アジャイルを理解・実践している。
• 必要に応じてスクラムイベントをファシリテートする。

スクラムマスターは開発チームを支援する

スクラムマスターは、さまざまな形で開発チームを支援する。
• 自己組織化・機能横断的な開発チームをコーチする。
• 開発チームが価値の高いプロダクトを作れるように支援する。
• 開発チームの進捗を妨げるものを排除する。
• 必要に応じてスクラムイベントをファシリテートする。
• スクラムがまだ完全に適用・理解されていない組織環境で、開発チームをコーチする。

スクラムマスターは組織を支援する

スクラムマスターは、さまざまな形で組織を支援する。
• 組織へのスクラムの導入を指導・コーチする。
• 組織へのスクラムの導入方法を計画する。
• スクラムや経験的プロダクト開発を社員やステークホルダーに理解・実施してもらう。
• スクラムチームの生産性を高めるような変化を促す。
• 他のスクラムマスターと一緒に組織におけるスクラム導入の効果を高める。

スクラムマスターは組織を支援する

できるスクラムマスターはどんどん偉くなっているのを見ていると納得する
しかしスクラムマスター＝マネージャーではない
スクラムマスターが色々管理をし始めたらそれはマネージャーである

スクラムイベント

スクラムで規定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必
要性を最小化する。すべてのイベントは、時間に上限のあるタイムボックス化されたイベントである。
スプリントを開始すると、その期間は固定され、増減することはできない。スプリント以外のイベント
については、目的が達成されたときに終了することもある。これは、プロセスでムダなことをせずに、
必要な分だけ時間を使うためである。
スプリント以外のスクラムイベントは、何かを検査・適応するための公式な機会である（スプリントは
その他のイベントの入れ物である）。これらのイベントは、非常に重要な透明性と検査の両方が実
現できるように設計されている。これらのイベントがなければ、透明性は低下し、検査・適応の多く
の機会を失う。

スプリント

スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダク
トインクリメントを作るための、1 か月以下のタイムボックスである。開発中はスプリントの長さは常に
一定である。スプリントが終了すると、すぐに新しいスプリントが開始される。
スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレト
ロスペクティブで構成される。
スプリントでは、
• スプリントゴールに悪影響を及ぼすような変更を加えない。
• 品質目標を下げない。
• 学習が進むにつれてスコープが明確化され、プロダクトオーナーと開発チームの交渉が必要
になる可能性がある。
スプリントは 1 か月以内のプロジェクトと考えることができる。プロジェクトと同様に、スプリントは何
かを成し遂げるために使うものである。スプリントには、開発対象のゴール、開発のための設計や
柔軟な計画、実際の作業、成果となるプロダクトインクリメントが含まれる。
スプリントの期間は 1 か月以内に制限されている。スプリントが長すぎると、開発対象の定義が変
更されたり、複雑になったり、リスクが増大したりする可能性がある。ゴールに対する進捗を少なくと
も 1 か月ごとに検査・適応することで、予測可能性が高まるのである。また、リスクも 1 か月分のコ
ストに収まるようになる。

スプリントの中止

スプリントはタイムボックスの終了前に中止できる。スプリントを中止する権限があるのは、プロダク
トオーナーだけである。このときに、ステークホルダー・開発チーム・スクラムマスターの意見を参考
にすることもできる。
スプリントゴールが古くなった場合は、スプリントを中止することになるだろう。会社の方向性や市
場・技術の状況が変化すると、スプリントゴールは古くなってしまう。状況を考慮して意味がなくな
ったと思えば、スプリントを中止すべきである。ただし、スプリントの期間は短いので、中止したから
といって影響があることはほとんどない。
スプリントを中止した場合は、プロダクトバックログの「完成」したアイテムをレビューする。部分的に
リリース判断可能なものについては、通常はプロダクトオーナーが受け入れる。未完成のプロダク
トバックログアイテムは、再見積りをしてからプロダクトバックログに戻す。そこにかかった作業の価
値は急速に低下するため、頻繁に再見積りが必要になる（訳注：作りかけの機能や設計について
は、時間が経つと状況が変わってしまうため、その価値が失われてしまうことが多い。そうすると、
最初から見積りをやり直す必要が出てくる）。
スプリントを中止すると、新しいスプリントのスプリントプランニングのために全員が再度集まる必要
があり、リソースを消費してしまう。また、スプリントの中止がチームのトラウマになってしまうこともあ
る。とはいえ、スプリントの中止はめったに発生しない。

スプリントプランニング

スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業である。
スプリントが 1 か月の場合、スプリントプランニングのタイムボックスは最大で 8 時間である。スプリ
ントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。スクラムマスターは、
参加者に目的を理解してもらうようにする。スクラムマスターは、スクラムチームにタイムボックスを
守るように伝える。
スプリントプランニングでは、以下の質問に答える。
• スプリントの成果であるインクリメントで何を届けることができるか？
• インクリメントを届けるために必要な作業をどのように成し遂げるか？

トピック 1：スプリントで何ができるか？

開発チームは、スプリントで開発できそうな機能を予想する。プロダクトオーナーは、スプリントで達
成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムにつ
いて検討する。スクラムチームはみんなで協力して、スプリントの作業を理解する。
スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チ
ームが予想するキャパシティと過去の実績である。プロダクトバックログから選択するアイテム数に
ついては、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チーム
だけである。
スプリントプランニングでは、スクラムチームがスプリントゴールを設定する。スプリントゴールとは、
プロダクトバックログを実装することで実現するスプリントの目的であり、開発チームがインクリメント
を開発する指針となるものである。

トピック 2：選択した作業をどのように成し遂げるか？

プロダクトバックログアイテムを選択し、スプリントゴールを設定したら、開発チームはスプリントでそ
れらの機能を「完成」したプロダクトインクリメントにする方法を決める。選択したプロダクトバックログ
アイテムとそれらを届ける計画を合わせて、スプリントバックログと呼ぶ。
開発チームは、プロダクトバックログを動作するプロダクトインクリメントに変えるために必要なシス
テムと作業の設計から着手する。作業の規模や工数はバラバラであっても構わないが、開発チー
ムが次のスプリントで実現できそうなものを計画する。開発チームがスプリントの最初の数日間で
行う作業については、スプリントプランニングで作業に分解する。作業の単位は 1 日以下にするこ
とが多い。開発チームは自己組織化して、スプリントバックログの作業を引き受ける。これはスプリ
ントプランニングだけでなく、必要であればスプリントでも行う。
プロダクトオーナーは、選択したプロダクトバックログアイテムの明確化やトレードオフを支援する。
開発チームの作業が多すぎたり少なすぎたりした場合は、選択されたプロダクトバックログアイテム
について、開発チームとプロダクトオーナーで話し合う。あるいは、技術やドメインに詳しい人を招
待してアドバイスを求めることもできる。
スプリントプランニングが終了するまでに、開発チームは自己組織化したチームとして、どのように
スプリントゴールを達成し、どのように期待されるインクリメントを作成するかをプロダクトオーナーと
スクラムマスターに説明できなければいけない。

スプリントゴール

スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するも
のである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールは
スプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終
了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機
能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チ
ームは一致団結して作業ができる。
開発チームが作業するときには、スプリントゴールを念頭に置く。スプリントゴールを達成するため
に、機能や技術を実装する。開発チームの予想と異なることが判明した場合は、プロダクトオーナ
ーと交渉してスプリントバックログのスコープを調整する。

スプリントゴール

読む限りスクラムチームとPOのゴールが一致しているかを見る場所

デイリースクラム

デイリースクラムとは、開発チームのための 15 分間のタイムボックスのイベントである。スプリントで
は、毎日デイリースクラムを開催する。開発チームは、次の 24 時間の作業を計画する。前回のデ
イリースクラムから行なった作業の検査と今後のスプリント作業の予想をすることで、チームのコラ
ボレーションやパフォーマンスを最適化するのである。デイリースクラムは毎日、同じ時間・場所で
開催し、複雑にならないようにする。
開発チームはデイリースクラムを使って、スプリントゴールとスプリントバックログの進捗を検査する。
デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する。開発チーム
は、自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメ
ントを作成できるかを毎日把握しなければいけない。
デイリースクラムの構成は、開発チームが設定する。スプリントゴールを目指している限り、他のや
り方で行なっても構わない。質問を使うチームもあれば、議論ベースで進めるチームもある。たとえ
ば、以下のような例を使用するといいだろう。
• 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
• 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
開発チームやチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残作業につい
て、詳細な議論・適応・再計画を行うこともある。
スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにする。ただし、デイリース
クラムを開催する責任は開発チームにある。スクラムマスターは、デイリースクラムを 15 分間のタイ
ムボックスで終わらせるように開発チームに伝える。
デイリースクラムは開発チームのためのミーティングである。それ以外の人たちが参加する場合、
開発チームの邪魔にならないようにスクラムマスターが配慮する。
デイリースクラムは、コミュニケーションを改善し、その他のミーティングを取り除き、開発の障害物
を特定・排除し、迅速な意思決定を強調・助長して、開発チームのプロジェクト知識のレベルを向
上させるものである。これは、検査と適応の重要なイベントである。

デイリースクラム

書かれている例を6名以上だと時間が厳しいこともある
まず障害になりそうなものを報告してもらうのを最優先でも構わないのかな。
前日何をして当日何をするかはデイリースクラム前にまとめさせる

デイリースクラムは毎日、同じ時間・場所で開催

スクラムチームによってはなかなか厳しいこともあるができるずらしてでも行う

スプリントレビュー

スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバック
ログの適応を行うものである。スプリントレビューでは、スクラムチームとステークホルダーがスプリン
トの成果をレビューする。スプリントの成果とプロダクトバックログの変更を参考にして、価値を最適
化するために次に何ができるかを参加者全員で話し合う。これはステータスミーティングではなく、
略式のミーティングである。インクリメントを提示することで、フィードバックや協力を引き出すことを
目的とする。
スプリントが 1 か月の場合、スプリントレビューは最大 4 時間である。スプリントの期間が短ければ、
スプリントレビューの時間も短くすることが多い。スクラムマスターはスプリントレビューが確実に開
催されるようにして、参加者には目的を理解してもらうようにする。スクラムマスターは関係者全員
にタイムボックスを守るように伝える。
スプリントレビューには、以下の要素が含まれる。
• 参加者は、スクラムチームとプロダクトオーナーが招待した重要なステークホルダーである。
• プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないも
のについて説明する。
• 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを
議論する。
• 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定
義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
• プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在
の進捗から、可能性のある目標とデリバリーの日程を予測する。
• グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるイン
プットを提供できるようにする。
• 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性
をレビューする。
• 次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。
スプリントレビューの成果は、次のスプリントで使用するプロダクトバックログアイテムが含まれた改
訂版のプロダクトバックログである。新たな機会に見合うように、プロダクトバックログを全体的に調
整することもある。

スプリントレトロスペクティブ

スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会
である。
スプリントレトロスペクティブは、スプリントレビューが終わって、次のスプリントプランニングが始まる
前に行う。スプリントが 1 か月の場合、スプリントレトロスペクティブは最大 3 時間である。スプリント
の期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。スクラムマスターは、
このイベントが確実に開催されるようにする。また、参加者に目的を理解してもらうようにする。
スクラムマスターは、このミーティングがポジティブで生産的になるようにする。スクラムマスターは、
全員にタイムボックスを守るように伝える。スクラムマスターは、スクラムのプロセスを説明するため
に、チームメンバーとして参加する。
スプリントレトロスペクティブには、以下の目的がある。
• 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
• うまくいった項目や今後の改善が必要な項目を特定・整理する。
• スクラムチームの作業の改善実施計画を作成する。
スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロ
セスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。スプリントレトロスペク
ティブでは、スクラムチームは作業プロセスの改善や「完成」の定義の調整によって、プロダクトの
品質を向上させる方法を計画する。ただし、プロダクトや組織の基準と衝突しないように適切に行
う。
スプリントレトロスペクティブが終わるまでに、スクラムチームは次のスプリントで実施する改善策を
特定しなければいけない。これらの改善策の実施は、スクラムチーム自体の検査に対する適応に
なる。改善はいつでも実施可能だが、スプリントレトロスペクティブは検査と適応に集中するための
公式な機会である。

スプリントレトロスペクティブ

振り返り手法を用いて振り返ること
KPTはPに注力しすぎるのでポジティブになりにくいとされる
YWTや最近はFun! Done! Learn!がもてはやされていると思われる

スクラムの作成物

スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するもの
である。スクラムで定義された作成物は、全員が共通理解を得るために必要な情報の透明性を最
大化するように設計されている。

プロダクトバックログ

プロダクトバックログは、プロダクトに必要だと把握しているものをすべて順番に並べた一覧である。
プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログ
の内容・可用性・並び順に責任を持つ。
プロダクトバックログは決して完成しない。構築の初期段階には、明確でよく理解できている要求
が並べられている。その後、プロダクトや使用環境に合わせて進化する。プロダクトバックログは動
的であり、適切で競争力のある有用なプロダクトに必要なものを求めて絶えず変化する。プロダク
トが存在する限り、プロダクトバックログも存在し続けるのである。
プロダクトバックログは、今後のリリースで実装するプロダクトのフィーチャ・機能・要求・要望・修正
をすべて一覧にしている。プロダクトバックログアイテムには、詳細・並び順・見積り・価値の属性が
ある。プロダクトバックログアイテムには、「完成」時にそれを確認するためのテスト記述も含まれて
いることが多い。
プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、プロダクトバックログ
は巨大で包括的な一覧になる。要求の変更は止まらない。プロダクトバックログは生きた作成物で
ある。ビジネス要求、市場の状態、技術の変化などが、プロダクトバックログの変化につながる。
複数のスクラムチームが同じプロダクトの作業をすることがよくある。そうした場合、プロダクトの作
業は 1 つのプロダクトバックログに記述する。また、アイテムを分類するための属性をプロダクトバ
ックログに追加することもある。
プロダクトバックログに含まれるアイテムに対して、詳細の追加、見積り、並び替えをすることを、プ
ロダクトバックログのリファインメントと呼ぶ。これはプロダクトオーナーと開発チームが協力して行う
継続的なプロセスである。プロダクトバックログのリファインメントによって、アイテムのレビューと改
訂が行われる。いつどのようにリファインメントをするかは、スクラムチームが決定する。リファインメ
ントは、開発チームの作業の 10%以下にすることが多い。ただし、プロダクトバックログアイテムは
プロダクトオーナーの判断によって、いつでも更新できる。
並び順が上のプロダクトバックログアイテムほど明確で詳細である。明確で詳細であれば、見積り
も正確になる。並び順が下のアイテムほど不正確で詳細ではない。今後のスプリントで開発チーム
が従事するプロダクトバックログアイテムは、スプリントのタイムボックスで「完成」できるようにうまく
細分化する。開発チームが 1 つのスプリントで「完成」できそうなプロダクトバックログアイテムは、ス
プリントプランニングで選択できる「準備完了（Ready）」の状態になったと見なすことができる。プロ
ダクトバックログアイテムは、上記のリファインメントによって透明性を獲得することが多い。
開発チームは見積りに対して責任を持つ。プロダクトオーナーがトレードオフの理解や選択などに
ついて開発チームに影響を及ぼすこともあるが、最終的な見積りは実際に作業をする人が行う。

プロダクトバックログのリファインメント

スプリントバックログとプロダクトバックログは別れているようで別れていない？
スプリントバックログをストーリーで書くのであれば恐らく一緒になる。
プロダクトバックログは見積りができている必要がある
見積もりをするにはテスト記述(受け入れ条件)がなければならない
そのためテスト記述も含まれていることが多いという記載になっている
並び順が上のプロダクトバックログは明確で詳細なためそのままスプリントバックログになり得る

見積りに対して責任を持つ

見積もりが多すぎることも往々にしてある
これは経験不足か心理的安全性が低すぎるから起きやすいのではないか
自分のチームの心理的安全性がいかほどか計測してみよう。
経験主義による見積もりなので経験がなければ見積もりに責任を持てないこともある
そこはまず取りかかってみてどれくらい時間がかかりそうか見てみるというやり方がスクラムの思想にあうのでよく使われるようである

人によって見積もりが違う

スキルによって見積もりが違うのは避けられないことである
そのために知識移転が冒頭で書かれているのだと思われる
スクラムでペアプロを行うことは見積もりの安定にも役立つのではないか

ゴールへの進捗を追跡する

いずれかの時点で、ゴールに対する残作業を合計する。プロダクトオーナーは、少なくともスプリン
トレビューにおいて、この残作業の合計を追跡する。プロダクトオーナーは、前回のスプリントレビ
ュー時点の残作業の合計と比較して、希望する期日までにゴールに到達できるかどうかを評価す
る。この情報はステークホルダー全員に明らかにする。
進捗の見通しを立てるために、バーンダウン、バーンアップ、累積フローなどのさまざまなプラクテ
ィスが使用されている。これらは有用ではあるが、経験主義の重要性を置き換えるものではない。
複雑な環境下では、何が起きるかわからない。すでに発生したことだけが、これから先の意思決定
に使用できる。

スプリントバックログ

スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプ
ロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。ス
プリントバックログは、次のインクリメントに含まれる機能と、その機能を「完成」したインクリメントにし
て届けるために必要な作業について、開発チームが予想したものである。
スプリントバックログによって、開発チームがスプリントゴールを達成するのに必要な作業がすべて
見える化されている。継続的改善を確実なものとするために、前回のレトロスペクティブで特定した
優先順位の高いプロセスの改善策を少なくとも 1 つは含めておく。
スプリントバックログは十分に詳細であり、今後も変更される可能性のある計画である。それはデイ
リースクラムで理解できる程度のものである。開発チームは、スプリントでスプリントバックログを修
正する。スプリントバックログはスプリントで創発される。こうした創発が発生するのは、開発チーム
が計画を実行するなかで、スプリントゴールの達成に必要な作業を学習するからである。
新しい作業が必要になれば、開発チームがスプリントバックログに作業を追加する。作業が完了す
れば、残作業の見積りを更新する。計画の要素が不要になれば削除する。スプリントでスプリント
バックログを変更できるのは開発チームだけである。スプリントバックログには、開発チームがスプリ
ントで行う作業がリアルタイムに反映される。スプリントバックログは開発チームのものである。

スプリントバックログ

スプリントバックログをストーリーで書くかタスクで書くかは以前聞いたら半々だったこともあり
やりやすい方にすればいいということになる
ストーリーで書く場合はプロダクトバックログからそのまま転用できる

スプリントの進捗を追跡する

スプリントのいずれかの時点で、スプリントバックログの残作業を合計する。開発チームは、少なく
ともデイリースクラムにおいて、この残作業の合計を追跡し、スプリントゴールの達成に見通しを立
てる。開発チームはスプリントで残作業を追跡し、自分たちの進捗を管理する。

インクリメント

インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックロ
グアイテムを合わせたものである。スプリントの終了時には、新しいインクリメントが「完成」していな
ければいけない。つまり、インクリメントが動作する状態であり、スクラムチームの「完成」の定義に
合っていることを意味する。インクリメントは、完成していて、検査可能なものであり、スプリントの終
了時の経験主義を支援するものである。インクリメントは、ビジョンやゴールに向かうステップである。
プロダクトオーナーがリリースを決定する／しないにかかわらず、インクリメントは常に動作する状
態にしておかなければいけない。

インクリメントは常に動作する状態にしておかなければいけない

スクラムにおいてTDDが重要視される理由の1つかな
テストがなければ1日に何回もリリースして動く状態を担保するのは難しい
完璧なテストなんてないとCIのSaaSの人も言っていたし
TDDがあっても目視による確認はすべきだと思うけどリリース頻度考えると辛いな

作成物の透明性

スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御
に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。
作成物の透明性が不完全であれば、こうした決定には不備があり、価値は低減し、リスクが高まる
可能性がある。
スクラムマスターは、プロダクトオーナー、開発チーム、その他の関係者と一緒になって、作成物
が完全に透明化されているかを理解する。不完全な透明性に対処するには、いくつかのプラクテ
ィスが存在する。スクラムマスターは、そのなかから最適なプラクティスを選択してもらえるように支
援する。スクラムマスターは、作成物の検査、パターンの察知、言説の傾聴、期待値と実際値の違
いを把握することで、不完全な透明性を検知できる。
スクラムマスターの仕事は、スクラムチームや組織と一緒になって、作成物の透明性を向上させる
ことである。この仕事には、学習・説得・変化を伴うことが多い。透明性は一夜にしてならず。透明
性とは長い道のりなのである。

不完全な透明性に対処するには、いくつかのプラクティスが存在する

検知の仕方は書いてあるけど対処については書かれていない？

「完成（Done）」の定義

プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味
を理解しておかなければいけない。スクラムチームによってその意味は大きく異なるかもしれない
が、作業の完了についてメンバーが共通の理解を持ち、透明性を確保しなければいけない。これ
は、スクラムチームの『「完成」の定義』と呼ばれ、プロダクトインクリメントの作業が完了したかどうか
の評価に使われる。
この定義は、開発チームがスプリントプランニングでプロダクトバックログアイテムをいくつ選択する
かの指針にもなる。各スプリントの目的は、そのときの「完成」の定義に合ったリリース判断可能な
機能のインクリメントを届けることである。
開発チームは、スプリントごとにプロダクトインクリメントを届ける。インクリメントは実際に利用可能な
ものであり、プロダクトオーナーがすぐにリリースすることもできる。インクリメントの「完成」の定義に
関して、開発組織の慣例・標準・ガイドラインが存在する場合は、スクラムチームは最低でもそれを
守らなければいけない。
インクリメントの「完成」の定義が開発組織に存在しない場合は、スクラムチームの開発チームはプ
ロダクトに適した「完成」を定義しなければいけない。複数のスクラムチームがシステムやプロダクト
のリリース作業をする場合は、すべてのスクラムチームの開発チームが共通の「完成」の定義を使
用しなければいけない。
インクリメントは、それまでのインクリメントに追加されたものであり、すべてが正常に動くように十分
にテストされたものである。
スクラムチームが成熟していくと、「完成」の定義にさらに厳しい品質条件を追加することもある。新
しい定義を作り、それを使用していくと、以前に「完成」したインクリメントにも手を加えなければい
けないことが明らかになる可能性がある。あらゆるプロダクトやシステムは「完成」の定義を備えるべ
きである。それがあらゆる作業の完了基準となる。

完成

世界中で広く利用使われているから定義されていないのかな。
プログラムの世界ならリリースでいいようだけど。
リリース後のバグ修正とか負荷対策は見積もれないし。
まさかのプロダクトバックログアイテムより先に定義しろとある