スクラムマスター認定のための研修を受けてきました。
社内でもスプリントを回して振り返りを行っていますが、本当にこれでいいのかな？ということや スプリントを回す = スクラム ... ではないよな??? といった基本的なこともあやふやだったので 今回、改めて研修を受けることにしました。 一番の収穫としては、エンジニアだけでなく、色々なバックグラウンドを持った方々(アナリスト、マネージャー、すでにスクラムマスターの方)と一緒にスプリントを回しながら、 お互いの疑問や悩みについて共有できたところです。 理想的なスクラムマスター像や、運用にあたり注意したり、検討していく必要のある点などを学んでいけたのがとても面白かったです。 体系的なお話は研修含めいろいろな材料やところで学べると思いますので 自分が研修を受けて、なるほどなと思ったところだけざっくばらんにピックアップしたいと思います。
スクラムはアジャイルのあくまで軽量なフレームワークである
スクラムは簡単に始められるもので、小さく継続的にアウトプットし、すぐフィードバックをもらえるようにする、 というものが原則です。
見える化と心理的安全について
スクラムは「見える化」をとても意識されています。 きちんと動く仕組みを小さくつくっていき、 なるべく早くレビューしてもらうようにする。早く失敗し、切り戻し、切り替えを早くできることが強みなので、 成果はもちろん、困っていることや間違いもすべて表面に現れやすいと言えます。 「組織の課題を隠せなくなる仕組みなので、隠せなくなった課題を地道にひとつづく努力して直していくというのが スクラム・アジャイルの正体です」という講師の言葉が印象的でした。 なので、やはり心理的安全が必要だな...と思いました。 「できそうにない」「これではむずかしい」という状態が明らかになったときに、 「どのようにしたらカイゼンできそうか」と一緒に考えることが必要で、 建設的に考え、特定の人を咎めたり、責任を取らせるものではなく、 「チームで」考える、チームで責任を持つ。もしチームが困っていたら、別のチームや、別の部署もサポートするというのは 自分たちの Value に沿っており、とてもしっくりきました。
それでは個人のパフォーマンスは評価されなくなるのではないか？
MVPを取るのはそれはそれでもちろんすばらしいですが、チームが勝利することに貢献していなければ意味がないということでした。 チームスポーツと一緒ですね。たしかに素晴らしいプレーヤーは あまり自分のことを自慢せずチームが勝つことだけを考えてるというインタビューが多いですね...
スクラムに効率を期待してはいけない
スクラムをやればウォーターフォールより効率がいい ... と思っていました。違いました。 ウォーターフォールの方が、決まったものをスムーズにやっていく方法として効率的で、優れているとのこと。 スクラムは、効率ではなく、成功率(効果)を上げることを重視します。
時間厳守
こちらも当たり前なのかもしれませんがあまりわかっていませんでした。特にミーティングの時間については 小さなチームで集まっても振り返りやブレストに30分以上経過することはよくあったため、 もっと短い時間を測って集中し、その後何が決まったのか、考えた結果をアウトプットする、という訓練はためになりました。 また、時間を守らないとだんだん開始時間自体がゆるくなっていき、どんどん遅れていく事に気づかないため、 常に同じ時間に同じようにミーティングをすることが大事というのもわかりやすかったです。 こちらは社内に戻ってすぐ共有し、全体やチームのミーティング時間はきっちり測るように努めています。 結果意識的に時間内で話をするようになっていき、さらに全体でぱっと見で理解・共有できるよう 見える化の工夫が増えてきており、会議の質が上がっていると感じています。
完成の定義をする
スプリントのゴールを決めること、何をもって完成なのかが見えていない状態ですプリントを なんとなくまわしていても仕方ないということですね。 なので、完成の定義をし、どうなっていればよいか、どこまでできていればいいかをコミットしておくことが大事です。 また進捗についても細かくどのステップまで進んだかを見える化するため、 タスクのワークフローの見直しにもつながってきています。
ざっくり見積る
アジャイルは経験主義であり、未確定要素の高い見積を正確に行うのは難しいので まずは T シャツサイズ(S, M, L)くらいの大きさでバックログを見積もると良いことも参考になりました。 スプリントまで落とし込まずとも、チームのタスクの棚卸しのときにもこのサイズ感はわかりやすく作用するため 直近のスプリントで L サイズのタスクは不可能、もっと完了が簡単にできそうなタスクに 小さく落とし込んでいくこともしやすくなりました。
健康第一
これ、スクラム関係ないようなサブ要素かもしれませんが、はっとしたものでした。 というのも、何でもやる人は(も、誰でも)、その人自体も疲れすぎないように健康でないといけない。 特に本人が過労だと思っていないときが一番危ない。 チームとして大事なのは、顧客の幸せをまず優先しつつ(しつつです)、自分たちの心理的安全と、肉体的な健康を維持することだと思います。 もちろんいろいろな準備をしていても、インシデントが発生してしまったり、 ここは踏ん張って頑張らないと！というシーンはどこかしら発生するものと思います。 そのときに、チームで解決する、誰かに負荷がかかった状態にしない、困っている状態を見逃さない、辛いと声を出す というのが当たり前のようにできる環境作りというのはいつも大事だと思いました。
リリース日ありきのプロジェクトが多いのが現実
こちらは弊社が今まで受諾開発が多かったため疑問に思っていた点でした。 また、お客様の業務都合上、すでに年間のイベントが決まっている場合にも、どのようにするのが良いのかなと思っていたところです。 アジャイルでは締め切り概念については柔軟性を求められるところではありますが リリース日が決まっているプロジェクトはよくあることなので、そういう場合は「スコープの調整をする必要あり」 が回答でした。「なにがなんでもとりあえずこれをいつまでにやれ」っていうのはスコープ調整されてないので そのあたりはスクラムマスターがチームの様子を傾聴しつつ、どこまでできそうか確認し関係者と調整するのが良さそうです。 また、プロダクトオーナーは顧客に有益をもたらすための機能かつ デリバリが早くできるものを先に提供していくという視点でバックログを積むということが大事だということでした。 こちらも単純に優先度だけで決めるものではないのだなということがわかり興味深かったです。
理想的なスクラムマスターとは
こちらは研修2日目に出された課題です。 チームで理想像を模索していきましたが、結果「スクラムを回すためなら何でもやる人」かつ 「何でも相談でき判断の速い超絶人格者」ということになり、その後発表しつつも、 こんな人いるんだろうかという疑問に陥り..、 「でもこれってスーパーヒーローに近いので現実的にはなかなか難しいと思うのです」という他の方の率直な意見に救われました。 完全ではなくとも、小さな心がけでできそうなところはありそうでしたので、 まずはチームの意見をよく聞くこと、チームの様子(進捗だけでなく、忙しさや、困っていることなども)を見える化すること、 楽しくしていること(話しかけやすさ)、時間を守ることからはじめても良いのかもしれません。
それから、権限が強い人がスクラムマスターやるのはあまりおすすめされないということ。 というのも、権限が強い人に対しては上下関係が発生してしまい、チームが自己組織化するのではなくスクラムマスターの御用聞きになってしまうためです。 「スクラムマスターは偉くもないし、技術的にいちばんすぐれている人がなる必要もなく、 チームをよく観察して、チームをエネルギーに満ちた状態にすることが重要なので、 それに向いている人がなればいいと思います」 という言葉もなるほどなと思いました。
ということで、スクラムを学びながら、チームをどのようにサポートできるかという視点を養う貴重な時間を過ごせたので 有意義な研修だったと思います。一緒に学んだメンバーとのオンライン懇親会も楽しみです。 スクラムマスター認定試験も無事合格しました！
https://bcert.me/srszrjkqd
今後も少しずつ環境改善していきたいと思います。