皆様明けましておめでとうございます🐉
先日友人から誘われて、クリスマスイブに開催された有馬記念をやることにしました。
初めての競馬で賭け方もあまり分からなかったのですが、2万勝てました💰
これがビギナーズラックというやつですかね？
これで調子に乗らないよう、適度に競馬を楽しんでいこうと思います🐎
はじめに
弊社では、昨年の6月からスクラム開発を取り入れました。
以前もスクラム開発を行っていたものの、今ほど厳格に行っていませんでした。
そこで今回はスクラム開発を本格的に導入して、チームでどういった課題があったか、課題に対してどう向き合ってかを書いていきたいと思います！
（弊社では開発チームは3チームに分かれています。今回紹介する話は、僕が所属してるチームでの話になります。）
以前までの開発スタイル
以前まではチームリーダーがPMと相談し、メンバーにタスクを振るという運用でしたが（少なくとも自分が所属してたチームではそうでした。）
スクラム開発が本格的に導入されてからは、リーダー制度が廃止されメンバーが要件を仕様に落とし込み、開発をするように変わりました。
以前まではスプリントのほとんどをリーダーから振られた開発タスクに注力していましたが、スクラム開発が初まってからは、各メンバーの主体性が求められるようになったのと、より抽象度の高い課題を取り扱うようになりました。
スクラムイベント
スクラムとはアジャイル開発のフレームワークの一つです。
以下の画像のように、1スプリント（弊社では1週間）を通して各スクラムイベントをこなし、開発を進めていきます。
（この記事ではスクラムの紹介をメインで取り扱ってないので、気になる方はスクラムガイドをご確認ください！）
以下で弊社で行なってる主要なスクラムイベントについて簡単に紹介します。
リファインメント
各チームが扱うプロダクトバックログアイテム(PBI)をプロダクトオーナー（PO）と相談して決める時間になります。
POというバックログの管理を行う人をBiz側から立てて、バックログにPBIを作成してもらいます。
POはPBIを優先度順に並べ、ユーザーストーリーとACを記載します。
リファインメントの時間に開発メンバーとPOで話し合い、どのチームがバックログのPBIを扱うか決めます。
扱うPBIが決まったらチームメンバーでPBIにストーリーポイントをつけていきます。
また弊社ではメンバーがPBIを作成することも可能で、メンバーから起案があればSlackチャンネルでPOと相談し、バックログにPBIを積んでもらいます。
プランニング
チーム内で1スプリントで積むPBIを決めるのと、チームが取り扱うPBIを開発ができる粒度（Jiraのチケットが切れる状態）まで落とし込む時間です。
僕が所属してるチームの構成はフロントメンバー3人、バックエンドメンバー4人とスクラムマスター1人になります。
職能関係なく、基本的に全員でチケットに落とし込んでいきます。
プランニングを全員で行うことで、メンバーの扱うPBIの仕様の解像度が上がっているので、誰かが休んだ時に代わりに他の人がタスクを巻き取ることができるようになったり、チームが何をやってるかが以前より明確になったと思います。
レトロスペクティブ
1スプリントの終わりに今スプリントの振り返りと来スプリントに向けてTryを決めます。
各チーム振り返りの方法は異なると思いますが、僕達のチームはFigJamを使って振り返りをしています。
課題
以前までの開発体制と、弊社で行っているスクラム開発をざっと説明しましたが、いざやってみるとうまくいかないことだらけでした🥲
時間内に終わらないスクラムイベント、意見が出づらい雰囲気
スクラムを始めた当初はリファインメントと、プランニングが時間内に終わらずとても長引きました。
思いつく主な要因は以下の通りです。
- 会議中に無言の時間が多い
- メンバーがファシリ慣れしておらず会議がスムーズに進まない
長引く原因として、誰かが問いかけても無言になってしまうという事が多かったというのがあると思います。
初めた当初は誰かが「〇〇ってこういうとですか？」と言う問いかけをしても、全員がシーンとなるみたいなことはザラにありました。
無言になってしまう理由として、チームメンバーとの関係値や、分からないことを分からないという勇気を持てなかったなどがあったと思います。（僕はそうでした）
そして空気は地獄でした😇
チームで工夫したこと
会議で意見が出づらい、長引くなどの課題がある中、どうやってチーム内のコミュニケーションを円滑にしていったかを紹介していきたいと思います。
スクラムイベントの内容を全てテンプレ化する
FigJamに全てのスクラムイベントのテンプレを用意するようにしました。
以前までは各イベントのテンプレを用意していなかったので、会議の進行がファシリをする人に依存する形になっていましたが、テンプレを作ることで、各イベントで何を確認すべきか明確になり、誰がファシリをスムーズに進行できるようになりました！
レトロでの振り返りの仕方をお気持ちから始めるKPTに変更
意見を発散してくださいって言われると、意味のあることを書かないとと焦って、意見を出し辛くなる時ありませんか？？
僕自身がそうで、今スプリントでTryにつながるような、クリティカルな意見を出さないと・・と焦って意見を出すことにハードルを感じてました。
そこで振り返りで意見を発散するときに、今スプリントであった仕事に関係ないこと（ゲーム買いました、競馬で勝ちましたなど）や、思ったことや感想も気軽に呟けるようにしました。
意見を出すハードルを下げたことで、付箋の数が増え、KeepやProblemの発散からTryを決めやすくなりました！
また、読み上げるときにアイスブレイクも兼ねていてとても良かったです。
心理的安全性を高めるの記事を読んで、意見を共有し合う
ミーティングの時間にシーンとなることが多く、考えてることを発言できないというのは心理的安全性が高くないのでは？という意見から、以下の記事を読んでみんなで意見を発散し合うというのをやりました。
チームとして心理的安全性に課題があると感じ、それに対しメンバーが発散し合えたことで、安全性が高い状態を目指すんだ！！という意識付けができるようになれたと思います。
ワーキングアグリーメントを決める
これも心理的安全性を高めることに繋がってると思いますが、チーム内で暗黙的になっているものをルール化しました。
僕たちのチームでは、ルールとマインド二つのセクションを設けて、チームでの約束事を決めました。
レトロの時間に、来スプリント注力したいワーキングアグリーメントを決めたり、追加したいワーキングアグリーメントをみんなで決めています。
個人的にはマインド面でのワーキングアグリーメントを決めれてのがとても良かったなと思っていて、チームの共通認識を持てたことで、よりチーム内のコミュニケーションが活発になったと思います。
感想
昨年の6月にスクラムが本格的に導入され、会議中意見が出づらい何度も静かになる事もありましたが、今ではあの頃が懐かしいよねと言えるぐらい、心理的安全性が高いチームになれたと思います！
課題と向き合い、意見を言い合えるチームだからこそ改善していったと思います。
これはレトロででた意見ですが、今Qはチーム内でドラッカー風エクササイズをやってよりチームメンバーのことを理解し合おうと思っています！
チーム内で意見が出づらい、心理的安全性が低いと感じてる方がいらっしゃったら参考になれば嬉しいです！
全然関係ないんですけど、スクラムの価値基準って少年ジャンプの友情・努力・勝利みたいでカッコイイ（小並感）
最後に
では最後に宣伝です！
スペースマーケットでは、一緒にサービスを成長させていく仲間を探しています。
とりあえずどんなことをしているのか聞いてみたいという方も大歓迎です！
ご興味ありましたら是非ご覧ください！
スペースを簡単に貸し借りできるサービス「スペースマーケット」のエンジニアによる公式ブログです。 弊社採用技術スタックはこちら -> whatweuse.dev/company/spacemarket
Discussion