ROBOT PAYMENT Engineers Blog

株式会社ROBOT PAYMENTのテックブログです

専任でスクラムマスターを一年間やってみて - 前編 -

f:id:hiy0ki-rp:20210226135442j:plain

こんにちは!

テクノロジーソリューション統括室開発推進チームの伊代田です。

 

今回は曲がりなりにも専任でスクラムマスターをやらせてもらって1年がたったのでざっくりとふりかえりをしてみたいと思います。

スクラムマスター観点のふりかえりになります。

スクラムやスクラムマスターに興味のある方の参考になれば嬉しいです。

 

 

なぜスクラムを導入しようと思ったか

当時私がいたチームで、2019年の夏頃からスクラムを導入する企画をし、2019年9月頃からはじめました。

私は当初開発メンバーと兼任でスクラムマスターをやっていました(今思うとよくやってたと思う。でかめの開発もしてたし。)。

そして2020年の1月頃から専任でスクラムマスターを行うようになりました。

 

スクラム導入当時の雰囲気や課題感は以下にまとまってますので、当時のチームの課題や考えていたことはここでは省略をしますが、私はとにかく現状を変えたい、と思って企画や勉強をしていました。

現状が悪いわけではなかったのですが、将来のプロダクト、チームを考えたときに今のやり方では対応できないのではという不安が強かったからです。

tech.robotpayment.co.jp

 

そもそもなぜスクラムマスターをやろうと思ったか

それまで私は将来のキャリアとして、Webエンジニアとしてのスペシャリストを目指していました。さらに細かく言えば、自分のパフォーマンスを最大化することで提供する価値の最大化を目指していました。もちろんチームや組織での成果へコミットをしていましたが、まず個人の力に注目していた形です。

ただある時、自分のキャリアをふりかえった際に、プログラミングのことは先人の知恵やコミュニティを活用しているにも関わらず、チームでの開発の手法やフローについては現場での習わしや特定の個人の経験に依存していることに気がつきました。


私は当時もアジャイルやスクラムという単語は知っていましたが、それを学んで実践するよりも、現場で実施されていたフローを先輩から学び、独自にチームで工夫をして改善しながら開発を進めていました。さらに言えば、よくアジャイルと対比されるウォーターフォールもちゃんと学んで実践したことはなく、伝聞や記事などから得た断片的な情報をもとに雰囲気で距離をおいていました。
なぜかこの分野については自身の経験が選定基準、判断基準の大半を占めていました。

ふりかえったときにそれらがすべて駄目だったとは思っていませんが、プログラミングと同じように、チームでプロダクトを開発するということに対して巨人の肩に乗ることで今がどう変わるのか気になるようになりました。

こんな感じですこしずつキャリアを積む中で、チームでもっと成果を出すためには、ということを考える時間が増えていきました。

そして、現場での課題やきっかけもあり、スクラムマスターに挑戦をすることにしました。

 

チームで実際にやってみたこととそのふりかえり

ここからはチームで実際にやってみたことを時系列に沿ってざっくり紹介していきます。 

これら以外にも細かい課題や試行錯誤はあるのですが、大きな転換期をベースに紹介します。

とりあえず全員でスクラム(2019年9月- 2019年11月頃)

当時のチームでとりあえず全員でスクラムチームを組んでやってみました。

詳細は前述の記事の通りですが、どういう方針でどういったことをやるかというのをざっくりPOと私で詰めてそれをチームに提案しました。

「反対されるかな」と不安だった部分もありましたが、すんなりと受け入れてもらい、「とりあえずやってみよう」となったのでチームには感謝しかありません。

その際は、8人程度で私(SM兼開発メンバー)、PO、開発チーム(webエンジニア、SRE)という編成でした。

勉強しながらとりあえず走り出し、細かく試行錯誤しながらあれこれやりました。

既存の枠組みへの配慮をしつつも、結構大きく開発の流れを変更したうえに、自分も開発メンバーとしてごりごり実装やら運用やらしていたのでとにかく忙しかった記憶があります。

スクラムマスターとしての研鑽や支援も片手間になり、枠組みを保つのに精一杯という感じで今思うと正直スクラムマスターとしてはあまり動けていなかったです。

メンバーと開発をすすめる上でのコミュニケーションを取ることはできていましたが、スクラムマスターとしてでは不十分だったと思います。

一例として、なんのためにそのイベントをやるのか、どうやってやっていくべきかなどについて十分に説明ができていませんでした。

よかったところ

・とりあえず始めることができた

・メンバーが協力的だった

・POとコミュニケーションをよく取れていた

改善ポイント

・スクラムチームと深くコミュニケーションを取れていなかった

・スクラムマスターとしての役割をあまり果たせていなかった

 

f:id:hiy0ki-rp:20210226144547j:plain

当時のかんばんやふりかえりの様子(わざとぼかしています)。当時はTrelloを使ってかんばんをやっていました。今は別のツールを使っています。

SREを別チームとして分離(2019年11月-2019年12月頃)

当時あった大きな課題として、ソフトウェアエンジニアとSREでタスクが分離されていたために、日々の作業やふりかえり、プランニングでチームの一体感がでないというのがありました。

チームで開発をしたかったのに、個人単位でタスクや計画の確認をしていたり、特定の人しか手を出せないタスクが多くなったりしていました。

今ふりかえるとプロダクトバックログの定義や単位の見直しをするのが筋だったように思いますが、当時はいろいろな人と話をして、そもそものミッションが違うという点を大きな理由にSREチームをスクラムチームから分離しました。

ただし、コミュニケーションを密に行えるようにデイリースクラムには参加してもらったりするなど、メンバーと工夫をして進めました。

反省点もありますが、良い判断だったと思っています。特に色々検討した上でいろんな人とした決断だったので、前に進むことができたのが良かったです。

この頃にはスプリントごとのふりかえりも定着し、改善活動が回っていたように思います。

私個人としては、この頃からプロダクトや開発、それに対するスクラムとは、など今まで悩まなかったことに悩むようになりました。

よかったところ

・どうすべきかをチームで考えて前に進めた

・スクラムが定着してきた

・ふりかえりが当たり前になってきた

・自分がスクラムマスターになることで今まで悩まなかったところで悩むようになってきた。

改善ポイント

・まだ兼任で色々片手間になり忙しい

・自分のやってることに自信がもてなかった

ここまでのまとめ

こんな感じで最初は勢いで始めてみたものの、色々な壁にぶつかり、失敗も多くしていました。

それでもチームメンバーに助けられプロジェクトを進め、改善を続けていました(もちろん今も)。

なにより色々変えたことで、今まで見えなかった問題が見えるようになったり、考えるようになったのはとてもポジティブなことだと思います。

 

ここまでで結構な分量になってしまったため、続きは後編でお送りします。

 

後編は、

・さらなるチーム分割編

・ついに専任スクラムマスターへ

・いろいろチューニング期

・CSM取得(おまけ)

・組織全体へのアプローチ編

をお送りします(次で終わるかな。。)。

 

最後まで読んでいただき、ありがとうございました!

 

We are hiring!!

絶賛仲間募集中です。