KAKEHASHI Tech Blog

カケハシのEngineer Teamによるブログです。

スクラムマスターはスクラムマスターを育成する

はじめに

私はカケハシでエンジニアリングマネージャーをしている伊豆本です。約5年スクラムマスターを経験しています。 カケハシにはスクラムマスターが複数いるので、この記事で記載するのはあくまで私の持論です。

スクラムマスターでよくある課題感

自身がスクラムマスターをしている中で見聞きしたり経験した課題感には以下のようなケースがありました。

  • スクラムイベントに遅れて参加する
  • 参加者が集まらずスクラムイベントを開始して良いかわからない
  • スクラムイベントに無断で欠席
  • スクラムイベントがあると休みづらい
  • スクラムイベントが予定していたタイムボックスに終わらない
  • プロダクトバックログの完了の定義がない
  • 外部要因でスクラムバックログが進捗しない
  • プロダクトオーナーが差し込みタスクを追加する頻度が多い
  • スクラムはミーティング多いとメンバーから声が上がる
  • 開発系のバックログは大体できたのでステータスをレビュー、doneに変更する
  • バックログの見積もりより工数が多くかかっている
  • ミーティングの日程調整・進行はスクラムマスターがやる
  • スクラムチームで他のメンバーがスクラム改善に乗り気ではない・反対する
  • そもそもスクラムを理解できていない
  • プロダクトバックログが優先順位に並び替えられていない
  • やりたいことが多くロードマップが詰まっている

記載しているのは一例ですがいっぱいありますよね。いっぱいあって当然だと思います。寧ろいっぱいある方がスクラムマスターの存在意義があります。

スクラムマスターが自身のスクラムチームでスクラムマスターを育成する

これはチームメンバーに次代のスクラムマスターを任せる人材を育成したいという意図ではないです。
メンバーの希望があったり社内の状況次第ではスクラムマスターの役割をお任せしても良いと思います。

そもそもスクラムマスターでよくある課題感はなぜ発生するのか?

スクラムチームのメンバーがスクラムを体系的に学習して理解していないことが大きな要因だと考えています。エンジニアは自分たちの興味のある技術ややらなければいけない業務・スキルアップのために尽力しています。プロダクトオーナーは多くのステークホルダーとの折衝や施策の仮説検証・立案・要件定義に勤しんでいます。なので、メンバーは忙しく、スクラムは自分たちが使用しているアジャイルフレームワークにもかかわらず、体系だったスクラムの学習への優先順位は低く正しく認識されていないことが多くあります。

知らないのであれば、スクラムマスターが期待している振る舞いを求めるのは難しいです。
スクラムマスターはチームにスクラムを理解してもらい、実践してもらうことに責務があります。一方メンバーからスクラムへのアドバイスをスクラムマスターに求められるのは困った時でたまにどうすれば良いか聞かれる形になります。それはそれで間違ってはいないのですが、メンバーが困っていることに対してアドバイスするだけで、メンバーが困っていないことに対しては意識が薄く、あまり浸透はしません。場合によっては、面倒臭いがゆえにスクラムマスターにやってほしいというような、アシスタントのような扱いをされることもあります。

ではどうすれば良いの?

メンバーに正しいスクラムの理論を理解してもらいましょう。
スクラムを理解しているメンバーがスクラムの理論に反していることをスクラムマスターに依頼したり、推奨していない振る舞いをすることは減ります。心理的安全性を下げる要因になっているようにも捉えられるかもしれませんが、そうでもないです。わからなければわからない、自分はこう考えているのですがスクラムマスターはどのように感じますか?と聞ける環境を作るのと、聞かれると言うことはスクラムマスターとして頼られていると思ってください。

スクラムマスターとして頼られるためには、適切なタイミングで正しい発言・議論を促進する発言・タイムボックスを守る状況を作るなど、スクラムマスターとしてあるべき姿の振る舞いをするのが大事です。

スクラムを理解してもらうためにはどうすべきか?

一番最初にしてもらうことはスクラムガイドを読んでもらうことです。 一時間あれば読めます。
各自読んでくれない場合でも大丈夫です。メンバーを集めてスクラムマスターがティーチングしましょう。
それすらもNGなメンバーがいるのであれば、スクラムチームから外すことも検討しましょう。チームで採択しているスクラムというフレームワークのインプットができないメンバーはスクラムチームにいても妨害にしかなりません。

一方スクラムガイドはガイドであって抽象度が高く、具体的なプラクティスが記載されていません。そこで参考になるのが SCRUM BOOT CAMP THE BOOK です。この本は漫画要素も多く文章も簡単なので、人にもよりますが4時間程度あれば読めると思います。
私たちのチームではSCRUM BOOT CAMP THE BOOKを使い輪読会を実施しました。各々担当範囲を決めてまとめ・進行役をローテーションして進めましたが、1回30分を6回開催することで終わりました。

勉強会ごとに進む範囲について、SCRUM BOOT CAMP THE BOOKで記載されている内容について私たちのチームで実現できていない項目を全員でチケットに起票し、私たちがスクラムとしてできていないことをスクラム改善ボードとして作成しました。また、起票されたチケットに対し、優先度や私たちのチームで実現すべきなのかどうか議論することで私たちのチームが実現したいスクラム像を形成しました。

この画像は輪読会で作成したスクラム改善ボードになります。
左側から各担当範囲毎に起票されたチケットがリスト化されており、右側には私たちが改善に着手したいチケットをTODOリストとして管理しています。
画像が見づらいと思いますので進行中のチケットや完了したチケットの一部を紹介します。

  • ベロシティ | 安定している?
  • デイリースクラム(朝会)| 15分で行い、延長はしていないか
  • PMM,PdMメンバーがいない時に、standupを始めるか迷う。
  • 全員揃っていなけど | デイリースクラムの開始に全員が揃うようなルールを作る?
  • スプリントプランニング | プロダクトオーナーがスプリントの目的を明らかにする
  • スプリントレビュー | フィードバックを得られるようになっているか
  • バックログ | 達成してほしい順に並べているか
  • 全員参加のイベント3つ。休むべきではない?
  • など

自分たちで課題提起をし自分のチームで実現できていないことや目指すべき形を議論することで、スクラムや改善すべきことをチームメンバーが理解し、あるべき姿を認識してくれます。認識してくれることで今後も課題提起を行ったり、行動に移してくれるメンバーも出てきます。

まとめ

役割としてスクラムマスターを担うかどうかは別の話ですが、スクラムを学習してもらうことで、自分たちのチームで改善すべきことやスクラムを理解しているので、スクラムにおけるティーチングやコーチングなどスクラムマスターを担う準備ができていると思います。