前提

Scrum Inc.認定スクラムマスター研修を受けてきたので、「スクラムの概要・理論・価値基準」と「スクラムの3役割・5イベント・3成果物」について自分なりに整理してみる。
整理した結果、ほぼほぼスクラムガイドの抜粋/言い換えになっている。もしこの記事に出会った人がいたら、ぜひスクラムガイドに立ち戻ってみて、「あーこいつこういうこと言ってたんだ」「いやこいつの解釈はちょっと違うのではないか」など想いを巡らせてほしい。
自分用記事なので、理解が変わるたびに多分何度も編集する。

スクラムとは

デリバリー（価値を届ける）のフレームワーク
経験的プロセスに基づく
- 経験→検査→適応→検査→適応……
- 作業プロセスを透明化する必要がある
  - → 「透明性」「検査」「適応」は、経験的プロセスによる統制の柱
軽量でリーン、アジャイルの視点から成る
- 軽量　→スクラムガイドはたった13ページ。シンプルなルールであることで、自己組織化を促す。
  - 「シンプルで明確な目的と原則は、高度で知的な行動が生まれる」「複雑なルールと規制は単純で愚かな行動を生み出す」
  - スクラムガイドは「ルールブック」、プレイブックはそれぞれのスクラムチームで決めるもの
- リーン　→無駄を省き、問題を取り除くことでより価値を早く届ける
  - 参照：トヨタ生産方式
- アジャイルなマインドセット　→顧客と協調することで、より価値の高いものを届ける
  - 参照：アジャイルマニフェスト、アジャイルソフトウェア開発宣言
スクラム(SCRUM)の価値基準
- OPENNESS（公開）
- RESPECT（尊敬）
- COURAGE（勇気）
- FOCUS（集中）
- COMMITMENT（確約）
  - 参照：スクラムガイドP.5

スクラムの3役割、5イベント、3作成物

スクラムチームの役割

プロダクトオーナー
- プロダクトの「価値」に対する責任を負う　→「WHAT」
  - 顧客に価値を届けることがPOのミッション
  - 品質管理、QCD担保、コスト管理……etc
- 顧客の声を元に、プロダクトビジョンとプロダクトゴールを設定する　→「WHY」「WHAT」
- プロダクトバックログの優先順位を決め、リリース計画を設定する
  - →色々優先順位を決めることがある。意思決定の時間を短くする必要がある
- 関連）OODAループ（観察・情勢判断・意思決定・行動）
スクラムマスター
- 「より良いプロセス」「スクラムチームの継続的な改善」のために奉仕し、スクラムチーム・組織のゴールを達成させる
  - 「スクラムチームと組織に奉仕する真のリーダー」
- 開発者・PO・組織をスクラムプロセスを活用してコーチし、パフォーマンスを向上させる
- 割り込みからスクラムチームを守る
- スクラムチームとステークホルダーに作業を見える化する
開発者
- 「スプリントバックログの完成にコミットする」ことに責任を負う
  - プロダクトバックログアイテム/POが定めた「価値」に対し、どのようの顧客に届けるか　→「HOW」
- スプリントバックログを作成し、スプリントの作業を計画する
- 完成の定義を忠実に守り、品質を作り込む
- 専門家としてお互いに責任を持つ

スクラムチームの要素

機能横断
- 仕事を成し遂げるために必要なすべてのスキルを持っている
自己管理
- 1スプリントでどれだけの仕事ができるか、どのように作業を進めるか……を自分たちで決める
  - ↔︎プロジェクトマネージャーによる管理、プロジェクト計画、WBS
協調的
- 全員で協力してスプリントゴールを達成する
少人数
- 通常10人以下
- メンバが増えるとパフォーマンスが低下する

※スクラムチームは最小単位。スクラムチームの中にサブチームは存在しない。

スクラムの5イベント

以下のイベントが、スプリントの中で行われる。

スプリントプランニング
- 作成物：スプリントゴール、スプリントバックログ
- スプリントのゴール設定、キャパシティ策定、スプリントで実行する作業の棚卸しを実施する
  - スプリントのゴール設定：「このスプリントはなぜ価値があるのか？」を検討/設定
  - スプリントのキャパシティ：休暇状況を考慮しつつ、ベロシティを元に策定
  - スプリントで実行する作業の棚卸し：バックログリファインメントによって「準備完了」となったプロダクトバックログアイテムから、本スプリントで着手するものを選定し、スプリントバックログに追加する
デイリースクラム
- 開発者のための15分のイベント。毎日同じ時間・同じ場所で開催する。
  - PO・スクラムマスターは、スプリントバックログアイテムに積極的に取り組んでいる場合は開発者として参加する。そうでない場合は特に発言をしない。
- スプリントバックログを元に、開発者が作業計画を立て、進捗を共有する
  - ※ スプリントプランニングでは、スプリントバックログアイテムに対する作業計画/アサインは実施しない。開発者主体で、デイリースクラムで実施する。
- 必要に応じて、スプリントバックログアイテムの調整・再計画を行う
- スプリントゴール達成のための障害物を洗い出し、取り除くためのプロセス改善に繋げる
スプリントレビュー
- プロダクトのインクリメントをステークホルダーにデモし、プロダクトバックログに適応できるFBを収集する（最優先事項）
  - 共同議論、プロダクトバックログの優先順位変更は2番目の優先事項。
スプリントレトロスペクティブ
- スプリントのプロセスを振り返り、改善する
- 改善タスクは次スプリントバックログの一番上に配置する

また、スプリント内で随時、バックログリファインメントを行う。そのほか、プロダクトビジョン・ゴールを設定するインセプションデッキをスクラムチーム立ち上げタイミングで実施する。

インセプションデッキ
- プロダクトビジョンの設定、プロダクトゴールの設定を行う
バックログリファインメント
- スプリントプランニングにて、スプリントバックログに追加できる「準備完了」のプロダクトアイテムを1~3スプリント分程度用意する。
  - 「準備完了の定義（DoR）」はチームごとに設定する。
    - 例えば、良いバックログアイテムは「INVEST」である
      - Immediatelly：直ちに着手できる（独立して着手できるか？外部要因で進まなくなったりしないか？）
      - Negotiatable：交渉できる（目的は明確でありながら、実現方法に幅があるか？）
      - Valuable：価値がある
      - Estimatable：見積もりできる
      - Sized to fit：適切な大きさである（1スプリントで終わるくらいの適切なサイズか？）
      - Testable：テストできる（明確な受け入れ条件がわかっているか？）
        
        条件1：バックログアイテムに「受け入れ条件(※)」が定義されている
        
        条件2：「完成の定義(※)」がスクラムチーム内で定義されている
        
        →「テストできる」とは、上記条件1,2を満たしているか検査できるか否かということ。
        
        関連：テスト駆動開発
  - プロダクトバックログアイテムを、スプリント内で完成できるサイズに分解し、必要に応じて優先順位を並び替える
  - 各プロダクトバックログアイテムを完成するために必要な労力を見積もる

(※)「受け入れ条件」と「完成の定義」

受け入れ条件
- POが、当該プロダクトバックログアイテムによるインクリメントを受け入れても良いとする条件。機能的な面にフォーカスする。
- 各プロダクトバックログアイテム別に定義される。
  - 受け入れ条件は、通常はPOがドラフトするが、特に技術的なバックログアイテムの場合は開発者が補助する場合が多い。
完成の定義（DoD: Definition of Done）
- 作業の品質基準。プロダクトバックログアイテムが完成してリリースする際の品質マークのようなもの。
- 全プロダクトバックログアイテムに共通して適用される。
  - 部門全体、会社全体に適用できる基準……とみなすこともできる。
- 例）「受け入れテスト完了済み、ドキュメント更新済み、自動テストメンテ済み、デモサーバーに配備済み」

スクラムの3成果物

プロダクトバックログ
- スクラムチームが成し遂げたい仕事（プロダクトバックログアイテム）のリスト
  - プロダクトバックログアイテムは、ビジネス価値の順番に並べられている。
  - 個々のプロダクトバックログアイテムは、機能を提供するための作業レイヤーを全て含むようにする。
    - 例）アーキテクチャ・詳細設計・DBスキーマ・サーバ・クライアント・GUI・テスト……
- 誰でも、いつでも、どんなものでもプロダクトバックログに追加できる。
- プロダクトバックログの優先順序は、プロダクトオーナーのみ最終決定権を持つ。
- ここでは粒度が大きくても良い。（＝「エピック」のままで良い）
- 確約：プロダクトゴール
スプリントバックログ
- 「準備完了」のプロダクトバックログアイテムから、当該スプリントで実施するプロダクトバックログアイテムをリストアップし、優先順位別に並び替えたもの。
  - 「より少ない労力で、より大きなビジネス価値を与えられる」もの順に並び替える
- 確約：スプリントゴール
プロダクトインクリメント
- 確約：完成の定義
- プロダクトに追加される一部。プロダクトゴール達成に向けた足掛かり。完成の定義を満たす全てのバックログアイテムの総和。価値があり、検査可能なもの。
  - 各インクリメントは、以前の全インクリメントに追加された状態でテストされる。
  - 動作可能な状態でなければならない。

蛇足：研修後の感想

※筆者は開発者。チームはスクラム開発ではないが、ウォーターフォールとも言い難い体制。

一番大事だと思ったのは「自己組織化」と「透明性」、「開発者として担保すべき責任領域の明確化」。

今のチームはスクラム開発ではないが、開発者の裁量100%みたいな節があると感じている。
個々の開発メンバーが、それぞれのタスクの意味を考えた上で、自ら「何（WHAT）をどのように実現するのか（How）」を検討しなければならない。このHowが開示されていないと、チームとして進捗を確認しリスクを回避することができない……。

一方で、実現した成果物（インクリメント）が完了しているとみなすには、チームで「完成の定義（Definition of Done）」を定めている必要がある。
（多分この辺が弱い‥‥）

開発者は「受け入れ条件（＝仕様面の完了条件）」と「完成の定義（＝品質面の完了条件）」を担保する必要がある。そして本当に価値があり確実に動作するインクリメントを継続的にデリバリーし、顧客価値にコミットしていく必要がある。
（だからCICDおよびDevOpsはアジャイル開発の文面で語られていたのか……と今更初めて理解）

スクラムとは「デリバリー（価値を届ける）のフレームワーク」。
スクラム開発を実践していない身としても、顧客に確かな価値を届けるためには、上記のようなスクラム開発における個々の役割と価値基準、各イベント/作成物で満たさなければいけない基準をおろそかにしてはいけないと感じた。

蛇足：研修中のQA

Q1. ベロシティについて：メンバが体調不良などで作業時間が削れてしまった場合、どのようにベロシティを計測すべき？
A. 一時的な離脱であれば、ベロシティの補正をする。（当該メンバの作業可能人日を元に、当該スプリントの「キャパシティ」を算出。実ベロシティに掛け合わせ、補正ベロシティを算出）
中長期的な離脱であれば、ベロシティの補正はせず、残りメンバの作業量を全量として算出する。

Q2. ベロシティ以外に、スクラムチームのパフォーマンスを測る指標はないか？
ベンダーと発注元がスクラムチームを組んだ場合、POを発注元が、スクラムマスターと開発者をベンダーが担うことが度々ある。まだベンダーと発注元で信頼関係が築けていないケースにおいて特に、POが「ベロシティが低い。生産性が低いのではないか」などと指摘することがあると聞く。

A. そもそもベロシティは「生産性のメトリクス」ではなく、主に「プランニングのメトリクス」。スプリントプランニング時にチームがこなせるポイント数を見積もるためのもの。
副次的効果として、ベロシティの推移からチームの生産性の傾向（上がり調子/停滞気味）を知ることはできるが、絶対指標として「低い」「高い」と分析することはできない。
例示ケースにおいては、スクラムチーム全体としての姿勢に根本課題があるので、チーム全体でスクラムの原則を学び、実践する必要があるか。

指標としては、「Four Keys」が有効かもしれない。
ソフトウェア開発チームのパフォーマンスを測る4つの指標……「デプロイ頻度」「変更のリードタイム」「変更失敗率」「デプロイ失敗時の復元までの時間」のこと。