はじめに
この記事は クラウドワークス Advent Calendar 2021 3日目の記事です。
久しぶりのQiita投稿ですので、お手柔らかにお願いします。
この記事をご覧になる前に、クラウドワークス エンジニアブログにある
「チームに「スクラム」を導入したお話」
をぜひご覧ください！
上記の内容の中でも特に「スクラムマスター」にフォーカスした内容になります。
背景
先日クラウドワークス エンジニアブログに投稿させてもらいましましたが、クラウドテックの開発チームでは、
- 多くのタスクが属人化されている
- ちゃんとスクラムが出来ていない
- そもそもちゃんと理解しているわけじゃない
- 現状POへの負荷が高いと感じている
- チームのパフォーマンスを測定出来てない
などの課題解決に取り組むため、半年前ぐらいからスクラムでの開発を導入しました。
導入にあたって、チームには**「スクラムマスター」を担っているメンバーが居なかったという課題があり、これを解消すべく未経験ながらスクラムマスターに挑戦**することになりました。
スクラムでの開発をする上で、スクラムマスターはとても重要なポジションになりますし、このスクラムマスターが機能しないと**「スクラムチームが成り立たなくなる」**ほどの重役になります。
これを未経験ながら行うことになったのですが、その際に「何を準備」して、実践で「何を意識」しているのかを、書いていこうと思います。
認定スクラムマスター を取得されてる人から見たら、誤っている部分もあると思いますが、温かく見守って頂ければと思います。
準備・インプット編
スクラムでの開発を行う上で、所属チームでは1ヶ月程度の準備期間がありました。
この期間に何を準備してきたのかをまとめてみます。
「スクラム」について叩き込む
まず「スクラム」についてを自分に叩き込むことをしました。
スクラムマスターはチーム内で**「一番スクラムについて詳しくあるべき」**と考えました。
とは言え、スクラムの経験もさほど無いですし、そこまで深く知っているわけではなかったのですが、短期間でインプットする必要がありました。
そんな中で取り敢えず以下の物を読んでインプットしていきました。
スクラムガイド（ 2020年版 / 2017年版 ）
まずは「スクラム」について知らないといけないのでこれを読みました。
基本的には 2020年版 を読んでいるのですが、過去のスクラムガイドとの違いは何なのかを確認するために 2017年版 の内容も読んだりしました。
チーム内でも2020年版スクラムガイドで読書会を行いましたので、チームとしての共通認識は2020年版の内容で揃えています。
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
スクラムガイドと並行して読んだのがこちら。
スクラムガイドはチーム全体の共通認識として使いましたが、スクラムガイドを読むだけでは「どう実践すればいいの？」という部分がわかりませんでした。
この書籍では物語仕立てで「どんな風に実践していくのか」が書かれていたので、実際チームで行っている内容は、この書籍をベースとしてやっているところが多いです。
もちろん実践を通して改善を入れているので、今は全く一緒というわけではないですが、右も左も分からない最初はとても助かりました。
SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ
上記2つは「スクラム」について勉強するために読みましたが、更にスクラムマスターについても知る必要があるため、こちらの書籍を読みました。
スクラムガイドやSCRUM BOOT CAMP THE BOOKでもスクラムマスターに関しての記載はありますが、よりスクラムマスターにフォーカスしている書籍なので、私自身の行動のベースとして使っている書籍になります。
スクラムマスターはよく「縁の下の力持ち」と言われますが、何をして、どんな姿勢でいればいいのかはとても難しいです。
自分自身が、この書籍に書かれていることをちゃんと実践出来ているかは分からないですが、漠然と「何をすべきか」を捉えるのに重宝しています。
また、スクラムマスターのことを調べていると必ず「サーバントリーダーシップ」に行き着くので、追加で「サーバントであれ - 奉仕して導く、リーダーの生き方」も合わせて読んでます。
ビジネスサイドへの「スクラム」の共有
チームがどのように変化するのかのデンタツに合わせて、「スクラム」についても勉強会という形式で共有しました。
主目的はもちろん「スクラムについてを理解してもらう事」になるのですが、同時に「自身にインプットした内容を伝えること」での理解度向上にも繋がりました。
誰かに伝えること、特にビジネスサイドに理解してもらうのは難易度が高いものでもあります。
インプットした内容を自分の言葉にして伝えることで、自身の理解度向上にも繋がるし、チームとビジネスサイドの円滑なやり取りにも繋がりました。
ドキュメントを残す
実践するにあたって、取り敢えずなんでもドキュメントに残すようにしました。
会議の目的やルール・Backlogの管理方法・スプリント運用 etc...
ついでにスクラムに直接関係しないが、チーム関するアレコレをとにかくまとめてドキュメント化しました。
ドキュメントがあることで、自分だけでなくチームメンバーも実施している内容を確認・振り返りが出来るようになりますし、新しいチームメンバーが加入した時にも重宝しました。
実践編
次に、実践している中で自分なりに意識している内容をまとめてみようと思います。
常にメンバーの同意を取る
ミーティングの見直しだったり、Issueの管理方法だったり色々変更をしましたが、この時に重要視したのが**「常にメンバーの同意を取る」ということでした。
言い換えれば「スクラムマスターが決定をしない」**ということを常に意識しました。
もちろん「こういうやり方だと良さそう」を考えて、チームと話し合うことはします。
ただ、「自分で考えたものを、共有なく実施する」というのは行わないということを意識しました。
あくまで、運用を実施していくのはスクラムマスター以外のメンバーになっていきます。
なので、他のチームメンバーが知らない・納得していないという状態は望ましくないので、これを出来る限り排除できるように、チームが動きやすいように徹するということを念頭に置いてました。
とはいえ、難しい部分もたくさんあるので、100％出来ているかというとそうではなく、まだまだこれからだと思っています。
コードを書かないようにする
**「スクラムマスターはPOでも開発者でもない」**ので、もちろんコードは書かないようにしました…
とは言いつつも、実際はスクラム外で管理している物に関しては少しだけやっていたりしました。
言い訳っぽくはなりますが、スクラムで管理しているものに関しては、もともと関わりが薄いというのもあり、コードを書くことはなかったです。
実際にスクラム外のものでもコードを書く時間を設けてしまうと、スクラムマスターとしてチームの課題に当たる時間が減ってしまいました。
これによって、改善やチームの円滑化が出来なくなってしまうのは本末転倒です。
ある種身を持ってそれを気がつけたので、現状は書くこと無く（あったとしても別案を考える）スクラムマスターを行えているかなぁと思っています。
まとめ
未経験から半年ほどスクラムマスターをやってきて、少しはスクラムマスターとしての経験を積むことが出来ました。
とは言え、**「正しくスクラムマスターが出来ているか？」と言われると「全然まだまだ出来ていないよね」**と自覚しているので、これからもチームと一緒に勉強をして、経験を積んでいくことになります。
さて、明日は @shinichinomura さんになりますので、皆様要チェックですよ！