はじめに

認定スクラムマスター(CSM)研修を受講したのでその学びのアウトプットしつつ、スクラムガイドの内容を整理しようと思います。（ひとまず初版は文章だらけです。量が多くなるので適宜更新かけようと思います）

ここで書かないこと

スクラムガイドに書かれていることの写経になるような内容は必要な物以外、割愛する

ここで書くこと

研修を受けて私自身が理解したこと、認識したこと
スクラムガイドに記載されている内容を更に深掘りするような話（スクラムは各チームが考えることを重視しているので、あくまで私自身の深堀りによる話）

前提

スクラムはアジャイルマニフェストにかかれている価値感や原則を踏まえたフレームワークである。そのため、事前にアジャイルソフトウェア開発宣言を読んでおくことを推奨します。

また本記事はスクラムガイド2020に沿って記述していくので合わせて事前にまたは横において読んでおくことで理解度があがると思います。

受講した研修の概要

スクラムの定義

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。

これ以上でもこれ以下でもない。シンプルにこういうこと。しかし曖昧なのでもう少し掘り下げる。

スクラムの理論

透明性

プロダクト、作成物、プロセス、ゴール、完成の定義、人、状況、問題点など、全てのチームに関わる物事を常に細かく共有する
こっそり何かをするのはNG
透明性が約束されている環境下でなければ、判断を間違い、リスクを増やし、良い仕事はできない

検査

透明性を踏まえ、頻繁に作成物や進捗を検査し、期待する結果との差やゴールに向けた状態との差を明らかにする
プロセスや人に対しても頻繁に検査をする

適応

透明性、検査を踏まえて、できるだけ早く調整や変更をおこなう
一気に大量に変更してはいけない
少しずつ、最も効果的なものから調整、変更する

スクラムの価値基準

確約

ゴールの達成とお互いのサポートに全員が全力を尽くす
自分の役割だけとか、自分のタスクだけという考えはご法度
スプリントゴールを達成するために助け合い、教え合い、協力する

集中

全員がスプリントの作業やスプリントゴールに集中する
兼務は集中できない
集中できない状態はすぐさま改善を回す

公開

すべての仕事とそれらを遂行する上での課題を公開することに合意する
隠し玉禁止
クイックレスポンスできない（概ね5~10分以内で消せない）ものは即PBIに積む or チームにエスカレーション

尊敬

お互いを能力ある独立した個人として尊敬し、一緒に働く人たちから尊敬される
お互いをリスペクトしてそれぞれの強みを活かす、任せる
リスペクトされるよう、日々自己研鑽し、成長する

勇気

正しいことをする勇気を持って、困難な問題に取り組む
変化を許容し、よくなると思うことには挑戦する
失敗を恐れず、チャレンジする

スクラムチーム

プロダクトオーナー 、開発者、スクラムマスター をあわせてスクラムチームと呼ぶ

スクラムチームのサイズは10人程度までがよい
プロダクトオーナーとスクラムマスターはそれぞれ1人
サブチームや階層(プロダクトオーナーが上、開発者が下とか)はなし（※サブチームみたいなのがあるスクラムはLarge Scale Scrumというらしい）
スクラムチームは自己管理する(いつ、何を、どうやって、誰がやるかは自分たちで決める。指示されない。)
マネージャーや管理者はいない（チーム内にいるべきではない）
タスクが誰かにアサインされることはない / 誰かに進捗を管理されることもない（自己管理）
プロダクトに関して必要となり得るすべての活動に責任を持つ(良いも悪いも連帯責任)
スクラムチーム全体で、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ

開発者

プロダクトのHOWの中心で、実際にプロダクトを作る人たち

「プログラマー」だけを意図しているのではない
作業の規模を見積もる(これができるのはスクラムでは開発者のみで、 実行責任 がある)
全員揃えばプロダクトを作れる能力が揃う( 機能横断的 )
- 外部依存による待ち時間の削減と高速な繰り返し
- コミュニケーションとコラボレーションの醸成
- 役割分担より顧客や価値に注力できる

プロダクトオーナー

プロダクトのWHATとWHYの中心

プロダクトゴール達成とプロダクトの価値の最大化に 説明責任 を持つ
プロダクトに1人必要で、複数人や委員会ではない
- 意思決定の遅延、権限分散による不整合や価値の低下を防ぐ
効果的なプロダクトバックログの管理に 説明責任 を持つ(作業は委任できる)
- プロダクトバックログアイテムの作成
- プロダクトバックログアイテムの並び順
- プロダクトバックログアイテムが完成しているか判断
ステークホルダーマネジメント

スクラムマスター

スクラムガイドで定義されたスクラムの確立とスクラムチームの有効性に責任を持つ

スクラムマスターは、スクラムチームと、より大きな組織に奉仕する真のリーダー
スクラムの理論とプラクティスをスクラムチームだけでなく組織に理解してもらえるよう支援する
- 支援
- 教育・トレーニング
- コーチング
- タイムボックスを守らせる
- 妨害の排除の働きかけなど

スクラムイベント

スプリント

1か月までの同じ期間に区切って繰り返す。1つの区切りをスプリントと呼ぶ
スプリントは、他のイベントのコンテナ(入れ物)となる
期間の長さが変わってはいけない
スプリントが長いと複雑になり、リスクが高まる可能性がある
スプリントが短いと多くの学習サイクルを繰り返せるようになり、リスクも短い時間に収まる

慣れるまでは1週間以下のサイズでやるのが良い
1日スプリントとかもあり

スプリントプランニング

スプリントのスタート
そのスプリントを計画する
必要なときに必要な分の計画をする(Just in Time)
3つのトピック
1. スプリントゴールを1つ 決める
2. スプリントで実施するPBIをプロダクトバックログから選択する
3. 選択したプロダクトバックログアイテムの完了までの手順や段取りを明確にする

スプリントゴール、選択したプロダクトバックログアイテム、実行計画をあわせて「スプリントバックログ」と呼ぶ

スプリントプランニングで最も重要なのは、スプリントゴール達成のための戦略を考え実行可能な計画にすることだと思っている
誰が何やるレベルで留めず
- なにをいつ仕掛け始めなにをいつまでに完了させるのか
- 役割分担はどうするか（Front、Back、QAとか）
- Obstacle（阻害要因）があった場合にどんなPlanで立て直すのか
- etc

サッカーや野球などスポーツでも試合前のミーティングで、敵を知り適切な戦略のある状態で試合に望む
それと同じイメージで、戦略がなければうまく行かないし、反省もできない

開発（イベントではないが）

開発者全員で仕事をすすめる
- 特定の誰かに特定の責任が付与されるわけではない
完成の定義を守って品質を作り込む
開発者がやり方を決める
- 例えばペア作業やモブ作業の要否は開発者が決める
- リーンの原則に基づき同時の仕掛りを減らすのが一般的

デイリースクラム

スプリントゴールに向けた進捗を毎日検査する

これから1日の作業の実行可能な計画を作成する
必要に応じて今後の作業を調整し、必要ならスプリントバックログを適応させる
毎日、同じ場所で同じ時間に開始
最長15分間で延長なし
開発者のための会議（プロダクトオーナー、スクラムマスターの出席は必須ではない）
デイリースクラム以外でも必要に応じて、頻繁に話し合い、再計画して構わない

日次なのはあくまでも24時間に１回は検査をすべきという考え方から来ているらしいので、デイリースクラム以外に時間を取ることは構わない。
ただしその分開発工数が減ることには注意。

スプリントレビュー

プロダクトオーナーが主催

ステークホルダーを招待し、協力しながら今後の適応を検討するための時間
- スプリントで完成したインクリメントやプロダクトをデモする
  - スプリントレビューまでに完成確認しておく（ぶっつけ本番禁止。というか危険）
- フィードバックを得て、プロダクトバックログを見直す(新しいアイデア、優先すべきこと)
- プロダクトゴールに対する進捗について話し合う
- 現在のプロダクトの状況、今後の予定や見通しを共有する
進捗報告、承認の場ではない

スプリントレビューは進捗報告、承認の場では有りませんが

「アジャイルマニフェスト」の12の原則の「 動くソフトウェアこそが進捗の最も重要な尺度です。 」のとおり、結果的に進捗報告を兼ねることにはなる（主目的ではない）
リリースの判断（OK・NG）はスクラムチームの責任で判断されるべきなので、外部の承認を得る場でもない

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

日本だとふりかえりとも呼ばれることも多い(が正式名称ではない)

個人、相互作用、プロセス、ツール、完成の定義などの観点で今回のスプリントを検査する
うまくいったこと、今後の改善点を整理する
パフォーマンスを改善する上で最も効果がありそうな変更を明らかにし、なるべく早く着手する
- 次のスプリントのスプリントバックログに含めてもよい
- 一度にたくさんのことを変更しようとしない
チーム全員が参加することで幅広い視点で考え、アクションを確実に実行できるようになる
具体的なやり方はスクラムでは定義していない(以下は私のチームで実践したことあるもの）
- KPT
- タイムライン
- Fun Done Learn
- etc

プロダクトバックログリファインメント（スクラムイベントとしては定義はされていないが通常は必要）

スプリント中に次以降のスプリントのためにプロダクトバックログの手入れ(リファインメント)をする活動を行う
- 具体化・詳細化、分割、見積り、並び替え.....
着手可能(Ready)なプロダクトバックログをスプリント開始前までに準備しないとスプリントがうまく回らない
- ただしプロダクトオーナーは未着手のプロダクトバックログアイテムを変更できるし並び順を変えられる
チームの共通理解を形成する
いつ実施するかはチームで決める
- イベント化するか毎日実施するかなど

リファインの基準を決めて基準を満たしたものをReadyにしたりすることもある
- PBIが用意されている
- PBIの価値が明確である
- 心配ごとが無い（解消されている）※進めてみないとわからないことは当然あるが進めなくても明らかな心配ごと
- 疑問点や決定すべき事項が無い（解消している、決まっている）
- 開発者全員が何を作ればいいかわかっている
- 受け入れ条件が決まっていて、明確である
- 他のアイテムとの依存関係が明確である
- サイズが見積もられている
- 非機能要件が明確である
- etc
全員が何を作るか、何をすればいいか、最悪一人でやるとなってもやれるくらい理解できていることが結構重要な基準かも

スクラムの作成物

プロダクトバックログ

プロダクトゴール、プロダクトバックログアイテムをあわせてプロダクトバックログという。

プロダクトゴール

プロダクトの将来の状態を示す
スクラムチームの長期的な目標になる
- 目標は変わることがある（目標を達成した場合 or 目標を破棄した場合）
達成できたかどうかを評価できる必要がある（具体性がある）
計測可能で持続可能な結果やアウトカム
プロダクトのビジョンを実現する上で達成しなければならない小さな目標
特定の期間で完成させて次のゴールにすすむ
SMART(持続可能、計測可能、達成可能、現実的、有期)の5つの要素を持つものになる

ゴールを決める前に「誰にどんな価値を提供するのか、その結果どうなって欲しいのか」の方向性を定める
最初に誰かが一人で仕上げられるならスクラムである必要はないかも

プロダクトバックログアイテム

プロダクトバックログアイテムはプロダクトゴールを達成するために「何（WHAT）をするか」を定義するもの
スクラムでスプリントを開始するにはプロダクトバックログが必要
- プロダクトバックログはプロダクトゴールとプロダクトバックログアイテムで構成されます
- スプリント開始前にプロダクトバックログを作り、以降定常的にお手入れします
スクラムではプロダクトバックログのフォーマットや体裁については明言していませんが、以下は満たす必要があります
- 1列に並んでいる（同じ順番とかはない）
- 上位の項目は見積もられている

プロダクトバックログアイテムにはユーザーストーリーが使われることが多い
※ユーザーストーリーはスクラム用語ではない

並び順は「作る順番」であり「優先度」とか「重要度」ではない

新しいプロダクトバックログアイテムの見つけ方は以下のようなものがある
- スプリントレビュー
- サポートセンターへのリクエスト
- カスタマーサクセスへのリクエスト
- ペルソナの見直し
- ユーザーインタビュー、ユーザー行動モデリング
- メトリクス分析
- ログ解析
- etc

常にアンテナを高く張り「ユーザーはどんな価値を求めているのか」「どうなったら嬉しいのか」を観察し続け、考え続けるべきである。

スプリントバックログ

スプリントゴール

そのスプリントの目的や達成したいことを簡単にまとめたもので、スプリントに1つ

スプリントゴールの達成こそがスプリントで目指すべきことで、スプリント中はスプリントゴールは不変
ステークホルダーが理解できるものでなければいけない
スプリントゴールがあることによるメリット
- 集中しやすくなる
- フィードバックを得やすくなる
- プロダクトバックログアイテムの並べ替えがしやすくなる
- 進捗を確認する際に着目する内容が明確になる
- ステークホルダーとのコミュニケーションがやりやすくなる

スプリントゴールは、そのスプリントの最大にして唯一の目標であるため、スクラムチーム全員がその目標を達成するために全力を出します
進め方や役割分担などをチームで考え全員が貢献する必要があります
基本的にはゴールに関係ないことだけをする人は発生しません

インクリメント

開発者は毎スプリントでインクリメントを作成する

インクリメントとは、これまでのスプリントでの成果と今スプリントで完成したプロダクトバックログアイテムをあわせたものを指す
利用可能なものでなければいけない(複数スプリントで1つのインクリメントを作ることはない)
実際にリリースするかどうかは別の判断(保守開発のプロダクトであれば先にリリースすることもある)
必要な品質(完成の定義)を満たす必要がある

完成の定義

何をもってプロダクトバックログアイテムが「完成」となるかの基準のこと
- これを満たさない場合はプロダクトバックログに残り続ける
全てのプロダクトバックログアイテムで共通である
組織に基準があればそれを採用する
組織に基準がなければスクラムチームで決める
- チームで決めている場合はリファインメントで見直すことは可能
プロダクトバックログアイテムごとに異なる基準が必要な場合は「受け入れ条件」を使う（こともある）※受け入れ条件はスクラム用語ではない

スクラムマスター研修を受けて、スクラムガイドを読み解いている