はじめに
はじめまして。開発第2チームでスクラムマスターをしている3.141です。
数か月前にスクラムマスターになり、いざ「良いスクラムを作っていくぞ！」と意気込むも、現実はそう甘くはなく「このスクラムで本当に良いのだろうか？」と思うような手探り状態でスクラムを回していく日々に悶々としていました。
真のスクラムマスター（？）になるべく、今一度スクラムについて調べたりしていく上で「もっとこうすればよかったのでは？」とか「考え方が違っていたかも？」と思うことがあったため、ひよっこスクラムマスターなりにスクラムイベントについて、はまりがちポイントと、見直しポイントを自分のスクラムマスターとして、そして開発チームとしていた頃経験を元にまとめてみました。
現在スクラム開発をしている方も、これからスクラム開発をする方も、ひとつの意見としてみていただければ幸いです。
目次
スクラムとは何か
スクラムの定義については以下の通りです。
スクラムは複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。
引用 ： スクラムガイド スクラムの定義
スクラムでは変化の激しい問題に対応すべく過去の経験に基づき、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行うことを重要視してます。
正直なところ「スクラムとは？」という内容に関しては、説明すればいくらでも深く話せる内容ですので、今回の記事では省略します。（スクラムについて詳しい内容が知りたい場合、こちらの内容が参考になりますので是非ご覧ください。）
参考
■スクラムガイド
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
■ スクラム入門
http://www.goodagile.com/scrumprimer/scrumprimer_jp.pdf
■認定スクラムマスターの俺が正しいスクラムの理論をまとめてみた
https://qiita.com/gold-kou/items/90ba982a14ca79d843c9
今回は初心に戻りスクラムガイドをベースに、各スクラムイベントについて 、はまりがちポイントと、見直しポイントについて考えていきたいと思います。
スプリントプランニング
スプリントプランニングでは、スプリントの作業を計画するものですが、計画するにあたり以下の2つの質問について考える必要があります。
1. スプリントの成果であるインクリメントで何を届けることができるか？
引用 ： スクラムガイド スプリントプランニング
2. インクリメントを届けるために必要な作業をどのように成し遂げるか？
はまりがちポイント
スプリントゴールが抽象的すぎて何を作ればいいかわからない
1について、開発チームは開発できそうな機能を予測し、プロダクトオーナーはスプリントで達成すべき目的と、完成すればスプリントゴールを達成できそうなプロダクトバックログアイテムについて検討する必要があります。お互いにスプリントプランニングでやるべきことは決まっているのに、どちらとも抽象的に決めておりスプリントが開始した時点で仕様について検討しなおす……ということはありませんか。
開発チーム側は「プロダクトオーナーの言う、スプリントのゴールがイマイチわからない」といい、プロダクトオーナーは「バックログにアイテムを記入したものの、結局インクリメントが出ていない」という結果となります。不平不満からスクラムチーム間でのバトルが勃発したら正直なところ目も当てられません。
作業タスクについて有識者のみで話がすすめられてしまう
2について、必要な作業タスクを洗い出す段階で、有識者の方が話始めると「それが正しい」と考えてしまいつい発言をしなくなってしまいます。
この点について「そのほかに良い案があるが、有識者が言うのであれば間違いないだろう」と考えてしまった開発チームの人がいれば、スクラムとしては大きな問題となります。
まず、前提条件で開発チームには上下関係というものは存在しないです。無論、プロジェクトに携わる期間が長ければ長いほど仕様に詳しいなど差は出るかもしれませんが、その差を埋め、技術的な差を開発チーム内で極力なくしていくのがスクラムの開発チームというものです。
このような意識でスクラムを回していくと、自分の発言に自信がなくなり発言しなくなるということになりかねません。そして、最終的には「有識者が考えるからいいか」というスクラムの開発チームメンバーとしては最も良くない動きをしてしまうことになりかねません。（スクラムは常に問題点に関して改善するフレームワークである以上、思考することを放棄した時点で開発チームのメンバーとしてはいけないと考えています）
ここで、スプリントのゴールを明確にし、作業タスクについて開発チームで納得のいく形で話し合いをするにはどうすればいいか？について今一度見直してみようと思います。
見直しポイント
当事者意識を常に持ちスプリントプランニングに挑む
上記2つのはまりがちポイントに共通すること。それは「当事者意識を持っていない」という一言に尽きるかと思います。スクラムでは「自己組織化」というワードをよく見かけると思います。簡単に説明するならば、「作業を成し遂げるための最善の策を、自らが選択して決める」というもです。開発チームメンバ全員が「自己組織化」されていれば正直なところこのような話題を大々的に言わずともはまりがちポイントなどではまることはないかと思います。しかし、自己組織化というものはある程度訓練が必要でありそう簡単に習得できるものではないという認識です。では、どうすればいいかと考えた際に、まずは「自ら発言をする（自らが自分の意見を選択して決める）」というスモールスタートから始めてみるのはどうだろうか？と考えます。
「最善の策」についてはスクラムや開発内容について徐々に精度をあげることができればよいです。とりあえず、「他人任せ」な部分をやめて「当事者意識を持つ」ことをして、常に相手の発言や成果物に対して「もっと良くできるのでは？」と考えてることが必要であると思います。
デイリースクラム
デイリースクラムで話す主な内容は以下の通りとなります。
1. 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
引用 ： スクラムガイド デイリースクラム
2. 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
3. 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
はまりがちポイント
とりあえず進捗報告だけしがち
本当に「とりあえず進捗報告」だけ。『本日はxxの作業をしていました。』というもの。タスクが1日で完了しているというのであれば特に問題はないかと思います。但し、作業量が多かったりした場合、話は変わってくると考えてます。 『本日はxxの作業をしていました。』 と言われても、「どれくらいあと残っているのか」が客観的にみてわかりづらいし、それだけでは3にかかわってくる「問題」について気が付きにくいです。
現在、形骸化した「とりあえず進捗報告」していませんか？その場合、別のポイントで引っかかってきます。
問題について「特にありません」って言ってしまいがち
1, 2以上に、3が最もデイリースクラムの中で 難しいと考えてます。そしてこの「ゴールを達成するのを邪魔しかねない問題」は、なかなか出ないことが多いです。実際に何か問題がないか？と聞かれても「特にありません」と言ってしまいがちです。
開発最終日や前日に「実は問題があって……。」と本人から言われることもあれば、本人も気が付かず、周りが根掘り葉掘り聞いた結果「それ、問題ですね。」ということはあり得る話かと思います。
ここで、問題が先送りにならないようにするにはどうすればいいか？について今一度見直してみようと思います。
見直しポイント
自分の作業の透明性が担保されているかを確認する
スクラム開発における「透明性」とはとても重要な状態であるということはスクラムガイドを確認する上で再三出てくる話かと思われます。デイリースクラムを進行していく上で、自分の作業が不透明な状態が最も問題である可能性があります。現在自分が持っているタスクで想定よりも時間がかかっている場所がないか？仕様が曖昧で進んでいない箇所がないか？を自問自答する必要があるかと考えています。
問題がある人のことが客観的に見えているかを確認する
3にある「開発チームや私」という表現がある以上、「自分の問題を言わない人が良くない」と決めつけるのもチームとしては正しい動きではないと考えています。 意外と自分では気が付かないけれど、客観的に見て「それ、問題では？」ということはあるかと思います。問題を見つける習慣をつけることで、自分の問題にも気が付くようになるのではと考えるため、意識してメンバ全員が「問題がないか？」を考える必要があるかと思います。
言いづらい雰囲気がないか
問題があるときに言いづらいと感じるのは大いにあることであり、それを排除するのがスクラムにおいて重要な要素であると考えています。（過去に参画したスクラムで、進捗悪いと「はぁ？」みたいに圧迫してくる方がいらっしゃいました。そのような行いは絶対にしてはなりません。）
開発チームメンバー、スクラムマスター全員が問題に対して対策を考えられるような雰囲気を作る必要があるかと考えています。
スプリントレビュー
スプリントレビューを行うにあたり、以下のルールに従い実施いたします。
1. 参加者は、スクラムチームとプロダクトオーナーが招待した重要なステークホルダーである。
引用 ： スクラムガイド スプリントレビュー
2. プロダクトオーナーは、プロダクトバックログアイテムの「完成」したものと「完成」していないものについて説明する。
3. 開発チームは、スプリントでうまくいったこと、直面した問題点、それをどのように解決したかを
議論する。
4. 開発チームは、「完成」したものをデモして、インクリメントに対する質問に答える。「完成」の定
義にプロダクト機能のリリースが含まれていれば、それらを表示してレビューしてもらう。
5. プロダクトオーナーは、現在のプロダクトバックログの状況を説明する。（必要であれば）現在
の進捗から、可能性のある目標とデリバリーの日程を予測する。
6. グループ全体で次に何をするべきかを議論し、次のスプリントプランニングに価値のあるイン
プットを提供できるようにする。
7. 市場やプロダクトの利用状況によって、次に行うべき最も価値の高いことが変更される可能性
をレビューする。
8. 次にリリースするプロダクトの機能や性能のスケジュール・予算・可能性・市場をレビューする。
はまりがちポイント
完成したものに対して重きをおきがち
上記の内容を見て、「スプリントレビューでもっとも重要視していることはどれ？」という質問をした場合、高確率で「完成したもののデモ（この場合4にあたる）」という回答が多そうな気がします。
無論、デモが動くことが開発メンバーからしてみれば何よりも大事な要素になるかと思いますが、実際のスプリントレビューの目的はインクリメントの検査（完成したもののデモ）に加え必要であればプロダクトバックログの適応を行うものとされています。
この 「必要であればプロダクトバックログの適応を行うもの」 というのがかなり蔑ろにされがちです。
（過去に行ったスクラムでも、プロダクトバックログの適応をしていたか？と言われると「NO」な気がします。）
見直しポイント
現在のスプリント以上に未来のスプリントについて考えてみる
こちらについては、今あるはまりがちポイントを見直しましょう！というお話になるかと思います。
現在のスプリント（デモの完了）も大切ですが、プロダクトバックログをスプリント時に見直し、次のスプリントで何ができるかを参加者全員で話し合うということができているかを確認してみましょう。スプリントレビューではプロダクトオーナー、スクラムマスター、開発チーム、そしてスプリントレビューをする上で必要な参加者も集まります。このイベントでデモの説明を済ませ、問題ないことの確認で早々とスプリントレビューを終えるのは非常にもったいないかと考えます。無論、スプリントレビューのタイムボックスを超えるような話し合いはしてはなりません。それでも、ここで参加者全員で議論することで、次のスプリントで価値のあるインプットを提供できるようになると考えています。
スプリントレトロスペクティブ
スプリントレトロスペクティブおいての目的は以下の通りとなります。
1. 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
引用 ： スクラムガイド スプリントレトロスペクティブ
2. うまくいった項目や今後の改善が必要な項目を特定・整理する。
3. スクラムチームの作業の改善実施計画を作成する。
はまりがちポイント
問題や改善策が出てこない
スプリントレトロスペクティブにて「KPT(Keep Problem Try)」を利用する場合が多くあります。これについて、人により書くポイントが偏ったりすることがあると個人的には考えています。例えば「Problemが多い」であったり「Keepが多い」であったり。細かなことに気が付くことができるという点はとても良いと考えていますが、「ある一定の項目が一つも出ていない」というのは問題であると考えています。
その中でも「問題点や今後の改善ポイント(KPTでいうPやT)が一つも出てない」というのが最も問題かと考個人的には思います。
この問題や改善策が出てこないということは、スクラムとしては成り立っていないと言い切ってもよいかと思います。スクラムガイドの中で「透明性」と「検査」と「適応」の3本柱で成り立つという話はスクラムを実施する上ではご承知の通りかと考えられますが、この「検査」「適応」について考えるのがスプリントレトロスペクティブだからです。
「何も意見が出てこない」つまり 「改善する理由や余地がない」ということになり、スクラムとして崩壊していると考えられます。
問題や対策を出すだけで終わる（改善実施計画ができていない）
問題や対策に対して各メンバー内で話し合うことはできた。そしてそのスプリントが終わる …… という本当に終わるだけのようなレトロスペクティブもあります。
レトロスペクティブでもっとも重要なのは「作業プロセスの改善や「完了」の定義の調整」です。
対策に対して実施計画などを立てず「とりあえず暫定的に対応する」というのも一つの案ではあります。無論、「暫定的な対応をして、再び問題になるようであれば考え直す」ということもよいかもしれませんが、それは「とりあえず暫定対応」で問題の本質を考えているのではなく、ただ先延ばしにしているだけとなります。
ここで、問題点や改善策を出しかつ、改善策を実施するようにメンバー全員で対応するにはどうすればよいか？について今一度見直してみようと思います。
見直しポイント
常にスクラムを良いものにしようとする目標を全員で持つ
問題点や改善点が出ない深層心理として「今のままでよい」という現状維持の気持ちがどこかにあるからだと考えています。また、「言ったところで変わらないだろう」というところも、問題点や改善案が出なくなる理由の一つかと思います。（実際問題、現状の仕事量や質等に不平不満がある場合、いくらでも問題点は出てくると個人的には考えています。）常にスクラムを良いものにしようと考えていけば必然的に問題と改善策は出ると思いますので、「今のスクラムを良いものにするには？」という気持ちを常に持ち、スプリント内での自分の行動やチームの行動を見ていくことができればと考えてます。
まとめ
最後まで記事を読んでいただき、誠にありがとうございました。
本記事はあくまでひよっこスクラムマスターが作成した記事ですので、情報として不足している点は多々あるかと思います。
それでもなお、引き続きスクラムを回していく上で、問題を解決してすすめていくことができればなと考えています。（この考えがまさに『スクラム』であると思うので！）
今回の記事をきっかけに、世のスクラムマスター（またスクラム開発をしている方）で困っている人の役に立てることを信じて……！
