KIDSNA キズナコネクト開発チームにおけるスクラム運用のご紹介
こんにちは。エンジニアの太田原です。
本記事では私の所属する保育園向け業務支援サービス「KIDSNA キズナコネクト」の開発チームにおけるスクラム運用についてと、レトロスペクティブから実施したカイゼンをご紹介します。
どんなふうにスクラム運用しているか？
昨年の7月からスクラムの知識が豊富な方がディレクターとしてjoinし、よりスクラムをガッツリとやっていこうという流れになりました。
現在、スプリントは1週間に設定し、各スクラムイベントは以下のように運営しています。
デイリースクラム
頻度：毎日15分
参加者：スクラムチームのみ（エンジニア、デザイナー、ディレクター）
プロダクトバックログリファインメント
プロダクトバックログの優先順位付けを行っています。
各プロダクトバックログアイテムは、「{ Who }が{ Action } できるようにする。なぜなら{ Problem }という課題があり、これができるようになることで、{ Benefit }からである」という形式になっており、各項目を穴埋めしていくことでユーザーストーリーが明確になるようになっています。
優先順位付けの際には
- 狩野モデルを用いて分類した品質
- 営業、CSからみた優先度
から計算したポイントにより並び替えを行っています。
頻度：隔週1時間
参加者：テックリード、デザイナー、ディレクター、管掌役員、CS（代表者1名）、営業（代表者1名）
スプリントプランニング
次のスプリントでやることの選定、仕様確認、ストーリーポイントの付与や、プロダクトバックログの確認を行います。
特に仕様の決定は議論の結果を議事録に残すことを意識しています。実際にみんなでコードを見て、大まかな設計をしたりする場合もあります。これにより手戻りを減らすことができています。
頻度：毎週2時間
参加者：スクラムチームのみ（エンジニア、デザイナー、ディレクター）
スプリントレビュー
スプリントの成果物（エンジニアなら開発した機能、デザイナーなら出来上がったデザインデータ）を共有し、レビューしてもらう場です。
営業さんには保育士経験者もおり、現場目線でのFBをいただくことができています。
頻度：毎週1時間
参加者：エンジニア全員、ディレクター、デザイナー、管掌役員、CS（代表者1名）、営業リーダー
スプリントレトロスペクティブ
KPTを用いたふりかえりをしています。
Google Jamboardというホワイトボードツールにみんなで書いていきます。
実際のホワイトボード画面はこのような感じです！
頻度：毎週1時間
参加者：スクラムチームのみ（エンジニア、デザイナー、ディレクター）
レトロスペクティブから、こんなカイゼンをしました！
実際にレトロスペクティブで上がり、カイゼンできたことをご紹介します。
（雰囲気が伝わるよう、KPTの「Problem」の赤い付箋をそのまま貼っています。）
リモートワークでのコミュニケーション問題解決
緊急事態宣言化でフルリモートになり、上記のようなコミュニケーションの課題が出てきました。
これに対しTryとして以下を行いました。
- スクラムチームに限定した雑談チャンネルを作成し、コミュニケーション活性化
- レビューのやりとりや相談は、すぐに通話（Google Meetや、Slackの通話機能を使っています）を繋ぎ口頭で行う文化づくり。全体に共有したい相談事については、デイリースクラムをしているGoogle Meetの通話ルームをデフォルトにしてしまい、迷わなくする
スクラムイベント自体のふりかえりを実施する
スクラムイベントを実施していく上で課題も発生していましたが、なかなか腰を据えて振り返る機会がありませんでした。そのため、スクラムイベント全体のふりかえりを実施し、以下をTryとして実行しました。
- プランニングが長くなりがちだったので、時間配分や優先順位を見直す
- デイリースクラムに対してもアジェンダを作り、それを守って行う
- スプリントレビューはファシリテータが決まっていなくて会議が本題から逸れたり、時間オーバーすることが多かった。そのため、ファシリテータをローテーションしたり、事前に発表順を決めて時間を効率的に使えるようにする。
知識の属人化・新人のキャッチアップ困難問題
ドキュメントが不足しており、仕様やドメイン知識が属人化してしまっていたり、新しく入った方向けの体系的な資料がなくキャッチアップに時間がかかるという問題がありました。
そこで、Tryとして以下を実施しました。
- 隔週でドキュメントを書く時間を1h確保する。この時間はカイゼンタイムのような位置づけになってきており、ドキュメントに限らず開発効率カイゼン（自動化など）も行う。
- 開発チーム向けの「まるわかりシート」を作成する。内容は環境構築、ドメイン知識、チーム開発の進め方、用語集、システム構成など。
レビューをする上での問題
- レビューが特定の人に集中していて負荷が高い・知識の属人化が発生していた
- リモートではレビューのコミュニケーションが難しく、時間がかかりがち
といった問題がありました。Tryとして、以下を実施しました。
- レビュワーを分散させる。メンバーがレビューする場合は、二段階制（メンバーがチェック→テックリードがチェック）にする。テックリードだけがレビューしている状況が改善された。
- モブプロならぬ、モブレビュー（レビューの作業を配信する）を実施する。参加メンバーがレビュワーのチェックポイントを学べる、ドメイン知識や仕様の共有にもなり良かった。
- レビュータイミングでSlack通話をつなぎ会話する。実装意図などが伝えやすく、スムーズになった。ペアプロ的にその場で直してしまうのも効率的だった。
まとめ
最近ではスクラムの運用がかなりしっかり仕組み化されてきており、スクラムチームは自己組織化されたチームとしてそれぞれのメンバーが課題を挙げ、打ち手をみんなで議論し、実行していくサイクルを回せています。
余談ですが、Problemに着目するだけでなく、Keepにも目を向けるフレームワークを活用していくのもいいかもね、という話になったりもしています。
ここまで読んで頂きありがとうございました！
We are hiring!
株式会社ネクストビートビートでは
「人口減少社会において必要とされるインターネット事業を創造し、ニッポンを元気にする。」
を理念に掲げ一緒に働く仲間を募集しております！
