はじめに

こんにちは。開発者とスクラムマスター(以下、SM)をしている金丸です。
サイボウズのGaroonという製品の開発チームに所属しています。

サイボウズではSMのことを社内外問わず、より多くの人に知ってもらう啓蒙活動の一環として、サイボウズのSM達によるリレーブログ企画を開催しています。

blog.cybozu.io

チームでスクラムを始めて約1年経ち、良い機会と感じましたので、このリレーブログに参戦させていただきます。

今回は、いち開発者がどうやってSMを始めたのか、そして自身の所属するチームにどうやってスクラムを定着させていったのか、自らの経験をベースにお話させていただこうと思います。駆け出しではありますが、SMが何を行っているかのご理解に役立ちましたら幸いです。

スクラムがチームに定着するまでの流れ

スクラムチームの始まり

まずはじめに、私のチームの紹介をします。
私のチームは、名前をYukimiチームと言い、弊社のGaroonという製品のセキュリティにまつわる部分の開発・保守作業を主に行っております。

より詳しい業務内容については、以下の記事をお読みください。 blog.cybozu.io

さて、このYukimiチームですが、約1年前はスクラムで動いておりませんでした。どうしてスクラムを採用することになったのでしょうか。

キッカケとしては、日々業務をこなす中でチームのタスク管理に問題が生じていた、という背景があります。

タスク管理に対する問題を解決するためにスクラムを導入

この当時、チームのタスク管理の問題として、大きく分けて以下の4つの問題がありました。

チーム外から舞い込んだタスクの優先順位付けをできる人(役割)がいない
タスクの粒度が大きすぎてタスク完了の見通しが立たない
今、誰が、どのタスクを持っているのか把握しづらい
タスクやプロジェクトが計画通り進んだかふりかえりしづらい

これらに対する解決策の一つとして浮かんだのが、スクラムのフレームワークを導入することでした。

タスクを管理する役割としてプロダクトオーナー(以下、PO)を用意し、プロダクトバックログ、スプリントバックログを活用しながらタスクを取り扱うことでこれらの問題が解決できると期待したのです。

スクラムチームになるために行ったこと

幸いなことに、私のチームメンバーは皆変化に寛容で、「失敗だと思ったらやめましょう」というマインドがあったため、なにはともあれスクラムをスタートすることになりました。スクラムをやると決めてからは、かなり素早く物事が進みました。

弊社には経験豊富なシニアスクラムマスター(以下、シニアSM)も在籍しておりますし、スクラムを行っている別チームもあります。そのため、望めばスクラムについてなんでも聞くことができる環境があります。
あとは、チームメンバーにスクラムをやる気持ちがあり、SM、POを決めてしまいさえすればスクラムを始めることができたわけです。

運良くSMやPO経験があり、セキュリティの知識がある人がこのタイミングでたまたま転職してきました、なんてことはなかったので、初心者ながら、私がSM、もう一人のチームメンバーがPOを務める形でスクラムチームが生まれました。ちなみに、私は冒頭でお伝えした通り、SMと開発者を兼任しているのですが、これはあまりオススメはできません(理由は後述します)。

スクラムマスターの一歩を踏み出すために行ったこと

特にスクラムチーム結成直後は、チームがスクラムとして動くことに専念するため、自分の開発者としての立ち回りを少なくし、SMとしての立ち回りを多くこなしていくことにしました。そしてそのSMとして立ち回るためには、なによりまず知識が必要でした。そこで、シニアSMの方々の記事やアドバイスを参考にしつつ、本や動画で知識をつけることから始めました。

以下は特に参考にした書籍です。

SCRUM BOOT CAMP THE BOOK【増補改訂版】
- スクラムを動かす上で大事なことはなんだっけ？を意識しながらスクラムが学べます
スクラムガイド(2020)
- 理解するのは難しいですが、スクラムを進めてふと読み返してみる度に新しい気づきが得られます
SCRUMMASTER THE BOOK
- スクラムマスターとしての責務を強く認識できる本です
- おまけの「10分でスクラム」はスクラムガイドの理解を容易にしてくれます

スクラムチームを動かす前準備

前述の方法で知識を付けながら、スクラムを実践していきました。

スクラムのフレームワークに則りスクラムイベントを準備しました。
そして、それらのイベントを何故行うのかを解釈し、チームでスクラムを動かすためのマニュアルを作り、チームメンバーに共有しました。

転んで起きるを繰り返す

そして、スクラムガイドに書かれている最小要素を満たすようにスクラムを動かしてみました。

スクラムは、以下で説明されるように、イテレーティブ(反復的)で、インクリメンタル(漸進的)なアプローチをします。

簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。

プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。

スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。

スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。

繰り返す。

( 引用: スクラムガイド(2020) )

一度スクラムを動かしてみると、何か問題点を見つけて、それを受けて調整して……という上記のインクリメンタルなアプローチが行われることになり、チームが次第に強くなっていきました。

これはまさにスクラムのフレームを利用する強みだと思います。

チームで、スクラムチームを作る

スクラムチームはSMだけで作るものではなく、チームメンバー全員で作るものです。スクラムチーム立ち上げから、チームメンバーにたくさんの意見を出してもらえたおかげで、自分たちだけのスクラムが少しずつ出来上がっていきました。

チームメンバーが意見を出しやすい環境を作るのはSMの仕事ですが、元から透明性が高いチームではあったため、その点についてあまり心配することはありませんでした。とはいえ、チームメンバーの関係性やそれを取り巻く環境は時が経つにつれ変わるものではあるので、自分たちの現在地を確かめるためにも、チームビルディングのような催しを必要に応じ行いました。

また、SMとしてスプリントレトロスペクティブの時に必ず何かしら１つはTRYを提案するように心がけていました。

スクラムを続けるべきかの判断をするための場を設ける

スクラムを始めて2ヶ月経った時点で、私のチームがこのままスクラムチームとして歩むべきか、それとも以前のやり方に戻すべきか、その判断をするためにふりかえりを行いました。
ふりかえり手法は世の中にいくつもあるのですが、以下の記事を参考にさせていただき、適当なふりかえりを見繕い、実施しました。

qiita.com

このときは Story of a Storyというものを実施しました。

大きく、「事実」、「続けたいこと」、「改善すべきこと」、「ネクストアクション」をチーム全員で出し合いました。そしてチームがスクラムを行うことで起きた変化を受け止め、それが今後のチームにも好ましいものかを判断しました。

その上で、私のチームではスクラムを継続するという結論に至りました。

軌道に乗ってからは

チームがスクラムチームとして軌道に乗ってからは、私はSMの立ち回りをほとんど無くし、開発者としての立ち回りをするようになりました。しかし、これは悪い立ち回りでした。

チームにおきている潜在的な問題は、SMとしての思考の時間をとらないとなかなか気づけませんでした。さらに、ようやく問題に気づけても対処法を考える時間が取れなかったため、後回しにしてしまい、この間チームは停滞してしまったように思います。

この悪循環を断ち切るため、チームに「一度、開発者の動きをやめて、SMに専念する」と伝えました。これにより、その時存在していた複数の問題に対する思考の時間が確保でき、1つずつ解決していくことができました。

器用な人であれば、開発者とSMを両立させられるのでしょうが、私にはこの2つの思考の切り替えを上手に行うことはできませんでした。
これが開発者とSMの兼任をオススメできない理由です。

認定スクラムマスターの取得

スクラムマスターを始めて半年ほど経ち、ある意味我流でSMを進めてしまっていたので、意を決して認定スクラムマスターという資格を取得しにいきました。
もっとチームに積極的に介入する方法を知りたかったというのと、試験を乗り越えた人間がSMを行っているという安心感をチームと自分自身に与えたかった、というのが大きな目的でした。

研修内容については割愛しますが、研修を受けたことでスクラムマスターとしての動き方、責務を再認識できましたし、チームでやってみたいTRYも複数見つけることができました。

現在行っている業務

現在はというと、緊急の業務や、ライブラリの更新対応に追われて開発者ロールばかりになってはいるのですが、時折POやチーム全員と協力し、やはり少しずつチームの改善を考えています。
一度チームで認識を合わせたことも、時間が経てば最適なやり方が変わったりするものなので、「今までのやり方」に囚われすぎないことを意識しています。

また、飛び道具的なやり方として、サイボウズのいくつかのチームではColuminityというチーム改善用の外部ツールを導入しており、私のチームもこれを使ってチームの診断と改善を行っています。
診断結果によって、客観的な視点からのチーム改善策を提案してくれるので、この診断結果を利用して、自分たちの主観的なふりかえりからは導けないようなチーム改善が行えます。