低カロリーにスクラムマスターを始める方法

こんにちは、freeeで人事労務freeeを開発している id:gn-spawn です。 『シン・エヴァンゲリオン劇場版𝄇』面白かったですね。 パンフレットには制作スタッフのインタビューが記載されていて、感動した作品を作っている側の仕事術が読めるのはとても貴重で奮い立たせられました。

それはそうと最近スクラムマスターになったので、プロセスの改善を行った話を書いていきます。

スクラムマスターを引き継ぎという形で始めた

freeeでは多くのチームがアジャイル開発のプロセスを使ってプロダクトの開発を行っています。 私の所属するチームも1週間でスプリントを区切ったアジャイル開発を採用しています。 他の会社や組織では専任のスクラムマスターがいる場合もありますが、弊チームではスクラムマスターはエンジニアと兼任で行っています。

私のチームでは以下のような流れで開発を進めています。

小さいリリースと検証・改善を繰り返す
小さいリリースと検証・改善を繰り返す

スクラムを実施するにあたってチームでやっていることは以下のとおりです。

  • 毎朝のデイリーミーティング
  • スプリントレビュー
  • レトロスペクティブ
  • プランニング

なぜスクラムマスターになったのか

マネージャーとの1on1の中で

  • スクラムマスターのマネージャーが非常に忙しそうなので、自分が一部でも引き継げる部分はないか
  • プロセスの改善が好きなのでそういった領域で引き継ぎたい

という話をしていると、「スクラムマスターをやってみないか」と提案されました。 今までもスクラムでの開発経験はあるものの、自分でオーナーシップを持って運用したことはありませんでした。 色々な人とコミュニケーションを取るのが好き、少しでもマネージャーから委譲できればというモチベーションで挑戦してみました。

引き継ぐにあたってやったこと

まずはデイリーミーティングのファシリテーションから引き継ぎました。 前述のモチベーションから徐々に引き継いでいく方法を取りました。私がスクラムのオーナーに慣れていないというのも理由の一つです。

やり方を知らなかった私は、前スクラムマスターのやり方をそのまま行いました。

実際に感じた問題

全ての引き継ぎを行ったところ、思ったよりも時間が取られることが分かりました。 エンジニアとスクラムマスターが兼任なので、準備に時間が取られて思うように実装の時間が取られたりしてしまいました。

これは単に私が不慣れな部分があるのですが、実装の時間が取れないのはチームメンバーへの負担も増えますし、リリースしたい機能の開発も遅れてしまいます。

特に時間がかかっているのは

  • バックログの整理
  • バーンダウンの更新

の2点です。「スクラムマスター」のロールをやる以上はチームメンバーが迷わないように完璧な準備が必要だと思いこんでいました。

他チームを見て改善していく

まず問題の改善を行う場合に、スパッと「ここが今のやり方だとマズいよね」と分かれば一番なのですが知識や経験が無いとなかなか難しい部分です。 そこで先ずは他のチームのスクラムイベントを見学してみることにしました。

今は感染症対策もあり、ほとんどのエンジニアチームがオンラインでミーティングをしているので気軽に見に行けるのは助かりました。 その中から自分たちのチームにフィットするやり方を見つけて、取り入れていくことで改善しています。

実施したアクション

他チームのスクラムイベントを見学して、以下のことを実施しました。

  • バックログを整理しない
    • プランニングで整理もメンバーと一緒に行う
  • 準備の委譲
    • メンバーのスプリントごとに出した成果を自分で書いてもらう
    • バーンダウンもとりあえず準備してツッコミがあればその場で直す

スクラムマスターとしてちゃんと準備をしなくては。と思っていたせいで準備に時間がかかっていました。 しかし、メンバーを信頼して完璧に準備をすることをやめてみました。 その結果、精神的負担が減って漫然とした多忙さを感じることがなくなり、プロセスの改善にフォーカスできるようになりました。

得られた結果

スクラムイベントの最後に、感想や改善案を書けるアンケートを置いています。レトロスペクティブでそういうのはやれば良いのでは?とも思いましたが、 レトロスペクティブでは開発に関することにフォーカスを当てています。 私へのアンケートとして匿名も可能な形で書いてもらうことで、フィードバックを受けやすい形にしています。

プロセスの改善にフォーカスできるようになったおかげで、チームとしてより良いやり方を試行錯誤ながら追求しています。

まとめ

スクラムマスターに挑戦して一番のメリットは、プロジェクトの全体像を意識してオーナーシップを持てるようになったことです。 ユーザーに素早く価値を届けるにはどうしたら良いか?というのは、「頑張ってコードを書く」という単純なものではないと思っています。 職種に関わらず、プロダクトに関わる人全員を巻き込んで進めていくのはエンジニアだけで進めたときに見えないものが見えるので非常に面白いです。