初めに
スクラムガイド２０２０年版に記載された本文を引用し、1年の経験をもとにどのような意味であるのか考えをまとめていきます
今回は第１弾としてスクラムの定義及びスクラムの理論についてまとめです
スクラムの定義
スクラムの定義 本文考察
スクラムフレームワークは意図的に不完全なもの
スクラムガイドはあくまでガイドであって、あえて完全に作られていません。
それは、チームや組織が考えるいい感じの働き方はそれぞれ異なるためだと考えます。
このぼんやりとした「いい感じの働き方」を誰かが決めたものではなく各チームや組織で考えて欲しい、経験していく中でより良くしてほしいという経験主義に基づいているからです。
事実、自身のチームでは毎日のレトロスペクティブの中で、プロセスやイベントについて、ポジティブに改善し、やってみてよかったらワーキングアグリーメントに追加し、文化にする。ダメそうだったらもとに戻すということを繰り返すことで少しずつ理想のチームに近づいている感覚があります。
改善をすることも価値があることだと思うのですが、チームの個人個人が「いい感じとは何か」を考える、改善を出すために話し合う土壌がアジャイルソフトウェア開発宣言における対話に価値をおくことなのではと感じています。
アジャイルソフトウェア開発宣言
スクラムは既存のプラクティスを包み込む
スクラムは既存の管理手法をオーバーラップすることができると記載されています。
今まで実践していた手法にスクラムの手法を取り込むことにより、
透明性、検査、適応することができ、改善していくことができます。
これは個人的な考えですが、スクラムの有識者（アジャイルコーチ）がいる場合は、一度に全てのスクラムの要素を取り込むのではなく、部分ごとに取り入れていくこともありなのではないかと感じています。
なぜなら、スクラムは透明性、検査をすることで問題点を炙り出してしまうため、全てを一度に適用すると、問題が噴出し、うまくいかないと感じ、手が止まってしまうからです。
スクラムの有識者（アジャイルコーチ）がいる場合については、チームに上手な失敗をさせることで問題点に気付かせ、改善を促すプロセスをスムーズにとることができるため、全ての要素をではなく、少しずつイベントの意味や目的を知りながら、チームで改善し、結果的にスクラムになっているのが良いと考えます。
逆に、チーム全員がスクラムの理解に乏しい場合はスクラムのルールを全て取り込まないとなんでうまくいかないのか全くわからなくなってしまうため、まずはスクラムガイド通りルールを守って進める必要があります。
スクラムの理論
スクラムの定義 本文考察
スクラムは「経験主義」と「リーン思考」に基づいている
経験主義とは、物事を実践する中で得られた知見をもとに改善を進めるということです。
もともと、スクラムは最初から完全に理解して取り組むフレームワークではなく、チーム、組織が実践していく中で作り出していくものです。
経験主義は既存のプロセスを、よかった部分はどこか、うまく行かなかった部分はどこかを振り返りの中で、少しづつ改善していくということです。そのためチーム全員で以下のことを意識し振り返りを実施すること重要です。
- チームでよかった点をワーキングアグリーメントにしチームの文化とすること
- チームで統一した課題認識をもち、改善に向かうこと
- お互いの価値観や人となりを理解すること
リーン思考とは、無駄を省き、早く顧客に提供することでフィードバックを得て、不確実性をできる限り取り除くことです。
ユーザが、求めている物、事は頭の中で描くことはできず、実際のフィードバック（ユーザの振る舞い）を取り込むことで確信を持ってプロダクトの方向性を決めることが重要です。
事実、頻繁にフィードバックを得られたプロダクトでは明確なスプリントゴールを設定でき、顧客が何を考えているか、どう思っているかをチームが共有しているため、技術視点ではなく顧客体験に注力しやすい環境になります。
イテレーティブ（反復的）でインクリメンタル（漸進的）なアプローチを採用している
スクラムではスプリントという期間で反復処理を繰り返し、そのスプリントの中でインクリメント（リリース可能な成果物）を作成していくということです。
スプリントという短い期間で区切ることで判断回数を増加させ、未来の変化や課題について検討する時間を組織、チームに与えることが目的だと考えます。
透明性
透明性 本文考察
作業を実行する人とその作業を受け取る人に見える必要がある
スクラムでは以下の作成物、コミットメント（確約）をチームが認識し、
チームの誰が検査しても同一の判断ができる状態を透明性が高いとしています。
| 作成物 | コミットメント（確約） | |
|---|---|---|
| 1 | プロダクトバックログアイテム | プロダクトバックログのためのプロダクトゴール |
| 2 | スプリントバックログアイテム | スプリントバックログのためのスプリントゴール |
| 3 | インクリメント | インクリメントのための完成の定義 |
各作成物が重要な意思決定の判断材料となるため、透明性が担保できない場合、意思決定を誤るリスクが高くなります。
検査
検査 本文考察
これは、潜在的に望ましくない変化や問題を検知するためである
潜在的に望ましくない問題とは、プロダクトゴール及びスプリントゴールが誤っていることだと考えます。
正しいゴールを設定出来ていない場合、どれだけチームが良い状態であったとしても、良い結果がでることはないです。
例えば、「ユーザの獲得 100人/週」というようなゴールを設定した場合、チームは営業、広告宣伝などに注力し、プロダクトに目を向けることはなくなるのではないでしょうか。極端な例なので理解しやすいですが、ゴールの設定の検知はチームでプロダクトのあるべき姿を共有できていない状況（ワンマンチーム）だと発生しやすく、検知が難しい問題です。
潜在的に望ましくない変化とは、プロダクトゴール及びスプリントゴールに対して、誤った方向に進むことだと考えます。
正しいゴールを設定しているが、チームがそのゴールに向かっていなければ、良い結果がでることはないです。
例えば、ステークホルダーからメンバーへ直接の割り込み作業を命じられ、ゴール達成必要な作業に着手できない場合、誤った方向に進むことになります。
組織として、スクラムの理解や権限の委譲ができていない場合に発生しやすく、検知はできるものの組織文化を変えていくために多くの時間がかかる問題です。
スクラムでは、検査を支援するために、5つのイベントでリズムを提供している
スクラムでは5つのイベントが毎スプリント内で実施され、各イベントは毎スプリントで下記例のように同一タイミングで実施するよう規定されています。
同一のタイミングでイベントが実施されることで改善の効果が測りやすい、バックログに集中できるなどの効果を得ることができます。
１週間スプリントの例
| イベント名 | 実施タイミング |
|:-:|:-:|:-:|
| スプリント | 月曜日〜金曜日 |
| スプリントプランニング | 月曜日 9:30 |
| デイリースクラム | 毎日 10:00 |
| スクラムレビュー | 木曜日 16:00 |
| スプリントレトロスペクティブ | 金曜日 10:00 |
スクラムのイベントは、変化を引き起こすように設計されている。
スクラムのイベントは、短い周期でプランニング・レビュー・レトロスペクティブ繰り返すため、計画通りゴールに到達したのか判断が容易に作られています。
そのため、ゴールに対して、達成した部分、達成できなかった部分をチームで振り返りやすい環境が整うことで、改善（変化）を引き起こしやすくなるよう設計されています。
適応
適応 本文考察
プロセスのいずれかの側面が許容範囲を逸脱していたり、成果となるプロダクトが受け入れられなかったりしたとき
プロセスのいずれかの側面が許容範囲を逸脱するとはコミットメント(確約)を満たすことができないことだと考えます。
例えば、スプリントゴールが達成できないとわかったタイミングでチーム全員が集まり、どのようにプロセス、行動を変化させるかを検討します。
この達成できないとわかったタイミングが重要であり問題が発覚したタイミングで適応、変化することがチームに求められます。
また、スクラムでは問題が発覚することは良いことです。
なぜなら、問題を検知するための透明性や検査が正常に働いているからです。
この問題が怒ることは良いことであるということがチームに浸透しないと、問題を隠蔽することやなかったことにすることが透明性を下げ、検査をすり抜けてしまい、潜在的に望ましくない変化につながると考えます。
関係者に権限が与えられていないときや、自己管理されていないときは、適応が難しくなる
権限が与えられていないときは、チームが改善を実施できない状態になります。
また、スプリントレビューで発言したステークホルダの発言が重視されてしまいプロダクトゴールがぶれてしまうためリスクの増加を招くことになります。
自己管理されていないときは、チームで定義した改善を実践できないため適応が難しくなります。
こちらについてはチームのメンバー内でスプリントレトロスペクティブを実施できれば少しずつではあるが改善はされていくと考えられますが、各イベントに出席できないことや感情的になりすぎチームのメンバーへの尊敬を欠いた行動をすることは心理的安全性が確保されず大きな阻害要員となります。
スクラムにおける自己管理
確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、勇気（Courage）
終わりに
いかがだったでしょうか。
今回、記載に当たって悩んだ部分をチームのメンバーに相談させていただくことで自分の今の考えをまとめることができました。
チームの皆様に本当に感謝しています。
まだまだ、スクラムガイドの序盤なのですが見づらくなってきたため、以降は第２弾の記事でまとめていきたいと思います。
拝読ありがとうございました。