DevHRチームのスクラムは、どう回しているのか？

おはようございます。プロダクト本部副本部長の田中（@tan_yuki）です。

以前、私が所属しているDevHRチームの紹介をさせていただきました。

creators-note.chatwork.com

上記ブログでは、DevHRチームの目的、エンジニアと人事がワンチームなチーム構成、スクラムやってるよ、くらいの簡単な紹介をさせていただきました。DevHRという構成が世間一般から見てめずらしいのか、社内外から多くの質問をいただきました。上記記事をきっかけとして、Meetyでの面談もいくつかさせていただきました。

DevHRというチームへの関心の高さを実感しました。

今回、DevHRがスクラムをどう回しているのかといった、より具体的な方法について紹介します。上記ブログの詳細な部分の紹介になります。まだ上記ブログを読んでいない方は、読んだ上で以下を読みすすめることをおすすめします。

読むにあたっての留意事項

これから紹介するスクラムの具体的な方法論については、これをやればうまくいく、というものではありません。DevHRチームでも最初の形から何回かマイナーチェンジを繰り返しこのやり方に落ち着いています。そもそも具体的な方法論全般に言えることとして、そのまま別の組織に当てはまるというのは稀だと考えています。そこからなにか気づきを得て、その気づきを現在の組織に持ち帰る、くらいがベターでしょう。

あくまでも、私達はこうやってますよ、くらいに捉えていただけると嬉しいです。

DevHRでのスクラム

スクラム基本情報

メンバー：6名（2022/04現在）
- PO / ScM それぞれ 1名ずつ
- 人事メンバー：2名
- エンジニアメンバー：4名
スプリント期間：4営業日
- 月曜：スプリントプランニング
- 月曜〜木曜：スプリント期間
- 金曜朝：スプリントレビュー
- 金曜日の日中：空き時間（チームとしてはなにしててもOK）

DevHRで担当しているタスク上、（特に人事の方々の）差し込みタスクが多くなりがちなので、臨機応変に対応できるように1週間スプリントとしています。

開催しているイベント一覧の概要

スプリントプランニング（30分 / 週）
- スプリントゴールの決定
- 1週間でやることの確認
デイリースクラム（15分 ~ 30分 / 日）
- 進捗、困っていることの共有: 15分
- 共有したいこと、相談したいことの議論 + 雑談: 15分
- その日の朝の時間帯に開催
- DevHRチームではよく「朝会」と呼んでいる
バックログリファインメント（30分 / 週）
- ちらかったバックログを整理するイベント
- 完了条件などの説明が不十分なバックログアイテムをReady-Readyな状態（いつでも着手できる状態）にしたり、いらなくなったバックログアイテムを削除したり
- メンバー全員でモブワークしながらバックログアイテムを整理
スプリントレビュー（30分 / 週）
- スプリントのレビュー
- 2回に1度、ステークホルダー（CTO、人事部長）を招待し状況共有
- スプリントの結果の共有
- 採用の進捗状況の共有
- 採用優先順位の合意
わくわく会（30分 / 週 x 2）
- DevHR 独自のイベント
- みんなが集まる時間を強制的に作っている
- モブワークをしたり、勉強の場としてつかったり、いろいろ
- スプリント開始時にこの時間の使い方をメンバー全員で相談する
レトロスペクティブ（30分 / 週）
- スプリントの振り返り
- 振り返りの手法はそのときそのときで決定

DevHR ダッシュボード

DevHR はコミュニケーションのハブとして、miroをよく使用しています。

miro.com

DevHRではmiroに専用のダッシュボードを用意しています。私達はそのダッシュボードをもとによくコミュニケーションをとります。

上記はDevHRダッシュボードの一部で、以下の枠があります。

話したいこと
今週のイベント
年間イベント

各メンバーは、共有したいことや相談したいことがある場合、miro上の「話したいこと」の枠に付箋を書いておきます。この付箋は毎朝のデイリースクラムで確認し、全員で認識を揃えます。

今週のイベントには各自の休みの予定、重要なイベントなど、各メンバーがそれぞれどういう動きをするのか把握するために利用しています。

年間のイベントには、DevHRチームに関わる特に重要なイベントを書いており（例：サマーインターンシップ、大規模カンファレンスの開催、採用イベント、etc）、それらの準備をいつ時頃はじめるのかなどを常に把握できるようにしています。

スプリントプランニングとバックログ管理

バックログ

バックログはJIRA、スプリントバックログはJIRAとmiroを使って管理しています。DevHRのメンバーはタスクが発生するとJIRAのバックログアイテムに積んでいきます。

スプリントプランニング

スプリントプランニングでは、そのスプリント期間で何を達成するのか？を決定します。以下のような流れで決めていきます。

POとメンバーが意見を交わしながら、スプリントゴールをの候補をゆるく決めていく
スプリントゴールに紐づくバックログアイテムを選択していく（これらのバックログアイテムをスプリントバックログアイテムと呼ぶ）
POとメンバーでゴールを明文化、確定する

実際には1と2を交互に繰り返しながら3を目指していく形です。スプリントゴールとそれに紐づくスプリントバックログはmiroにまとめていきます。

サブタスク

スプリントバックログアイテムは細かな粒度のサブタスクに分解していきます。各担当のスプリントバックログアイテムを、必ず1営業日以内で終わるようなサブタスクに分解していきます。

サブタスクには、そのタスクを完了するまでの予定の時間を書いておき、誰が担当するかも書いておきます。みんなで相談しながら（モブワークしながら）進めたいタスクについてはミーティング用のマークを用意し、予定をおさえておきます。「わくわく会の時間を利用しよう」ということもあります。

また、スプリント期間中に完了したことがわかるようにマークをつけるなど、常に情報を最新の状態に保ち、現在のスプリントの状況が可視化できるようにしています。

なぜmiroとJIRAを両方使っているの？

ストックとしてのJIRA、発散としてのmiro、という棲み分けで考えています。

今後の予定しているタスク（バックログアイテム）はJIRAにストックし、スプリントバックログ内のタスクをどう達成していくか？はスプリントプランニング中にみんなで発散させながら考えていきます。

そもそもストックもmiroで統一してもいいのでは？という考えもあります。JIRAとmiro、2つのツールで行き来するので、若干面倒なところもありますが、現時点ではそれほど問題になっていないです。また、miroとJIRAの連携もシームレスな連携ができるのでそこまで困っていない、というのもあるかもしれません。