はじめに

恥ずかしながら初めてQiitaに投稿します。皆さんの貴重な時間をありがとうございます。

職場で去年の暮れからスクラムを取り入れることになりました。
最初は全然ピンとこず、何それ美味しいのレベルだった私が今年の春からスクラムマスターに挑戦することになって、さぁ大変。
湧き出た疑問、失敗したこと、改善したことなどを書いていきます。

もしスクラム導入したてで悩んでいる人、スクラムで進めるってどういう感じ？という人に読んで頂ければと思います。

スクラムイベントにがっつり時間取られて作業時間がないんですけど

↓ スクラムガイド 2020 にあるイベント毎の時間の目安一覧

イベント	1週間	2週間	3週間	1ヵ月
スプリントプランニング	2h	4h	6h	8h
デイリースクラム	1.25h	2.5h	3.75h	5h
スプリントレビュー	1h	2h	3h	4h
レトロスペクティブ	1h	2h	3h	4h

こう見ると大したことないように見えます。
1日8h作業可能な場合はそこまで圧迫されないかも。弊社では8hの中でコア業務以外の活動があり、1日の作業時間が5hほどになってしまうため厳しいと感じることがあります。

Sprintの期間を延ばしたら解決する？

どうしてもまとまった作業時間が欲しくて「Sprintの期間を延ばせばいいんじゃない？」と期間を延ばしたこともありました。
でも結果、Sprintの期間を延ばしても、成果物の量が多くなるためスプリントレビューにかかる時間も増え、期待していたような効果は得られませんでした。
上の一覧からわかるように期間を延ばしても比例してイベントに必要な時間は増えるんですから変わらないですよね。
よかったこと…Sprint前半の気持ちが穏やかになることくらいでしょうか。

期間を延ばしても結局終盤にキツキツになる。原因は期間ではない。

私の少ない経験上、期間を延ばしても気が楽になるだけで結局終盤にバタつくことが多かったです。
（デイリーできちんとタスクを検査していたら防げたのかもしれません…）
プランニングの際に、Sprint期間中どの程度の作業時間が取れるのかを把握した上で、対応するPBIを選択する、という改善案に至りました。

エッセンシャルスクラムには以下のようにあります。

チームが今のスプリント期間で仕事を完了できないということは、スプリントの期間を長くする理由にはならない。（中略）
それはスクラムチームが機能不全になりかかっている兆候であり、改善する機会なのだ。決してスプリントの期間を長くするための理由にしてはならない。

PBI見積もりってしんどい

プランニング前にPBIを開発者で見積もるのですが、注意しないと楽しくないポーカーになります。

見積もりの手法で代表的なものは以下ですが、主にストーリーポイントで進めています。
・ストーリーポイント
　PBIの大きさを計測する指標となる架空の単位（時間でも日でもない）
　基準となる１つのPBIを設定し、そのPBIの見積もりの相対でポイントをつける

・理想日
　PBIを完成させるために必要な作業日数（人日）で見積もる
　理想日＝なんの妨げもなくその作業にのみ集中したとしての見積もり

ストーリーポイントで進める際、プランニングポーカーをしているのですが、
まず見積もりの尺度を決めて、開発者同士で認識を合わせておく必要があります。

↓この表のように、どの数字がどのくらいの大きさなのかを決めます。

値	1	2	3	5	8	13	20	40	100
尺度	軽微	小さい	普通(小)	普通(中)	普通(大)	大きい(小)	大きい(中)	大きい(大)	すっっごく大きい

基準となるPBIを決めて、開発者同士で尺度に基づいて見積もる

一番見積もりやすい小さいPBIを選んで、開発者同士名前の通りポーカーのように値を出し合って、合意に達するまで繰り返します。
そのPBIの見積もりを基準として、他のPBIを相対的に見積もります。同じく合意に達するまで繰り返します。
お互いの見積もりが大きくずれていた場合、どうしてそう見積もったのかを話し合い、PBIについての理解を深める狙いがあります。

ただこれ、数が多いとだれる。議論を避けて数字を合わせるようになり、ただの数字合わせみたいになっちゃいます。
最初の尺度まで見失っちゃうことも。。。
今スクラムマスターとして参画しているPJでも私が陥りがちです。

目的を都度確認。大事なのは数字ではなくそこに至る議論

数字を合わせることが目的ではなく、その数字を導き出すまでの議論が大切だということをチームで共有することが必要だと思います。
PBIの内容について掘り下げて話し合ううちに見えていなかった課題や検討すべき項目が明らかになったりします。
それをチームで行うことによって仕様の共有にもなり、見積もりの説得力も増します。

見積もりを出し難そうにしていたら、PBIの内容がまだ荒くて見積もるのが難しいのかもしれないので、PBIの中身を精査する必要があります。

イベントの制限時間に踊らされ、本来の目的を見失いがちなので注意します。（書いてて辛くなってきました）

レトロスペクティブ（ふりかえり）で何も出てこないのはどうして？

いつもKPT法でレトロスペクティブを行っています。
Sprintを「Keep（継続すること）」「Problem（課題）」「Try（解決策）」それぞれの観点でふりかえります。

目的はチームで起きていることを分析したり、仕事のやり方をふりかえったり、問題がある場合には改善して次のSprintへつなげることです。

困ったのはなかなか踏み込んだ意見がでない、いつも決まった人しか発言しない、拭えないやらされている感などなどです。

チーム内のコミュニケーションは取れてる？

もう耳タコなほど聞く言葉ですが、「心理的安全性」です。
何を言っても受け入れられる場所でないと、怖くてなかなか本音を言えないと思います。
スクラムイベントは多いと10人くらい人がいますし、そこで自身が抱えている悩みを話すのは勇気がいります。
冗談を言うにしてもすべったら嫌だな、とか躊躇してしまうかも…

普段できていないことは、スクラムイベントのような場所ではまずできないと思います。

今年からほとんどのメンバーがテレワークとなり、すれ違いざまの雑談や、会話でのコミュニケーションが減っていてより難しくなっている気がします。
もちろん会話でのコミュニケーションがすべてではありませんが、チームでの開発をしているのでお互いのことに興味、敬意を持って歩み寄ることが大切だと考えます。

空気づくりしてる？

はい。これは私の課題です。
うぇーい、何言っても平気☆な空気を作りたい！

ふりかえりでは楽しいことばかりではなく、チームにとって障害になっていることを明らかにする面もあるため、その内容によっては葬式みたいな雰囲気になります。
何も出てこなくて沈黙。どうしましょな雰囲気も。
その雰囲気に飲み込まれたが最後、当たり障りのないのっぺらとしたふりかえりになってしまい、効果が見られない結果に終わります。

エッセンシャルスクラムには以下のようにあります。

報復を恐れずに自分の意見を言えるような、安全性を感じてもらわなければならない。そのためにもルールを設定すべきである。（中略）
レトロスペクティブは問題解決の場ではない。レトロスペクティブは責任の所在を明らかにしたり、個人の振る舞いを非難したりする場ではなく、スクラムチームのプロセスを改善する場である。雰囲気づくりをするときには、非難のない環境を作るためのルールであることを明らかにしておく。

目的は伝えていてもルールの設定はしていなかったので、今後の課題です。

PJに関係ないことでも上げてもらう

PJに関係なく、「見つけたお店がおいしかった」「猫がなついた」など何でもいいから上げてもらうというのはやってみたいです。
発言のハードルを下げる狙いで。
これも事前のルール決め（ルールと言うと堅苦しいけど）が必要ですね。急にやりだしたら引き潮のようにみんなが遠くに行ってしまいそうです。

デイリー、ちゃんと他の人の報告に興味持ってる？

**『デイリー形骸化問題』**あると思います。
私も何度も感じたことがあります。

毎日セットされる１５分MTG。
日々淡々と進み、終わってみて「ん？他の人何やるって言ってたっけ？？」みたいな。

デイリーの目的は、**「スプリントゴールに向けて順調に進んでいるかのチェック、もしも障害となっていることがあるなら再計画をすること」**です。

デイリーで話すことは以下の３つなのですが、自分の進捗報告をして終わり、という内容だと目的にかなわずただの進捗報告会になってしまいます。

・前回のデイリー後に自分がしたこと
・次回のデイリーまでに自分がすること
・進捗の妨げとなる問題があるか（または共有事項）

報告内容を工夫する＋他のメンバーの報告に質問する

「昨日は○○をやりました。今日は引き続き○○、終わったら△△をやります。
　困っていることは特にありません。」
これだと、進んでいるのか遅れているのかがわかりにくいです。
報告を工夫するとしたら、
「昨日完了予定だった○○ですが、～～で時間がかかり、完了出来ませんでした。
　～～の作業は昨日クリアしたので、○○は今日の午前中には完了予定です。
　終わり次第△△に着手します。△△は予定通り明日中に完了予定です。
　困っていることは特にありません。」
のようにそのタスクの進捗が進んでいるのか遅れているのか、またその進捗が他のタスクに影響するかどうかまで報告の中に入れることで他のメンバーも作業の状況がつかみやすくなると思います。

また、他のメンバーの進捗についても関心を持って、問いかけができるように気を付けるとよいと思います。
「そのタスク、昨日も同じ報告だったけど、なにか問題が起きてる？」
「昨日残業していたけど、なにかあった？タスクを分解したほうがいいかな？」
「そのタスク早く終わりそうですね。その後は何をしますか？」
「進捗が遅れているのでスプリントゴールを変更する必要があるのでは？」
など、報告を鵜呑みにするのではなく、突っ込んで問いかけることで本人も気付いていなかったチームの障害になることが見つかるかもしれません。

とは言え発言しづらい

デイリーもファシリテーターがいるため、なかなか口を挟みにくいと思います。
毎日同じトーンで淡々と進んでいるとなおさらです。

ファシリテーターが気を付けるのは、「まず自分が問いかけてみる」ことです。
ファシリテーターが開発者の場合は、状況が把握しやすいので問いかけもしやすいかも。
問題を指摘するだけではなく、純粋に「作業量多くないですか？」など問いかけをするとよいと思います。
ファシリテーターが開発者以外の場合は報告した本人へだけでなくチームメンバ全員に「この進捗でスプリントゴールに間に合いそうですか？」など、開発者全員に問いかけてみるとよいと思います。

さいごに

ここまで読んでくださりありがとうございました！
書いているうちに自分の考えも整理出来ました。アウトプットするって大切ですね。

まだまだ粗だらけのスクラムマスターですが、しっかりチームのためPJのために働けるよう精進します。
来年の目標は楽しいスクラム体験！！（タイトルは願望です）