スクラムを自分のチームの文脈に落とし込む
この記事は、NAVITIME JAPAN Advent Calendar 2021の 6日目の記事です。
こんにちは、かっしかしです。ナビタイムジャパンで、トラックカーナビのアプリ開発を担当しています。この記事では、トラックカーナビ開発チームのスクラムへの取り組みについて紹介します。
チームにスクラムを導入する
皆さんも「スクラムをどうやって自分のチームに取り入れるか？」というテーマを一度は考えたことがあるかもしれません。私もスクラムがやりたいと考え、試行錯誤をしてきました。しかし、他のチームの例をそのまま真似してもうまくいかない事が多かったです。スクラムが良さそうなのはわかるけど、現実にはどうやって始めればいいのだろうという疑問がありました。
試行錯誤の中でわかったのは、最初からスクラムをきっちりやるのではなく、価値観を少しずつ浸透させるのが大切だということです。
そして最近生まれたのが運営奉行という役割です。運営奉行はスクラムでいえば、スクラムマスターのような立ち位置です。チームの運営を改善していく中で、スクラムマスターをそのまま導入せず、自分たちに必要な役割として運営奉行を作り出しました。運営奉行については後ほど詳しく説明します。
自分のチームの文脈にスクラムを落とし込むことで、無理なくチームをよい方向に進めることができました。
スクラムをやってみたい！からの挫折
チームにスクラムを入れようと動き始めたのは数年前のことでした。しかし、まず何をやればいいのかがあやふやでした。ふりかえりを開催してもなかなか全員は集まりませんでした。スプリントを導入しようとしても、「何のためにスプリントがあるのか」「今までの開発スタイルから変えるためのコストが高そう」といった意見にうまく答えられず頓挫してしまいました。結果、勢いで取り組んだスクラム導入はうまくいきませんでした。
なぜうまくいかないのか？
チームのメンバーはそれぞれが技術力を持って、主体的に行動することができていました。そして開発チーム自身は、チームがうまく回っていて成果も出ていると認識していたので、大きく変わる必要性を感じづらい状況でした。
一方で、私がチームにジョインしたとき、高い能力を持つチームについて行くのが大変だったという課題を個人的に感じていました。もがきながら成長をすることで、「なんとかついていけるようになったけど、これを繰り返していくのはどうなんだろう」という気持ちがあり、スクラムに興味が湧いたという経緯がありました。
チームの何かを変える必要はあるのだが、どこをどうすればいいのかがわからないという状況でした。
改善策
そこでスクラムを全て行うのではなく、ふりかえりを継続することにフォーカスしました。ふりかえりは時間を短く30分で終わらせるようにして、時間がないから参加できないという人を巻き込みやすくしました。短い時間を有効活用できるように、ファシリテーションの方法をブラッシュアップさせていきました。また、チーム運営を一緒に考える仲間を作ることで、うまくいかないときにも心強い状況ができました。
ふりかえりが浸透していくうちに「チームで現在の状況を観察して、改善策を試す」という流れが定着していきました。
スクラムを意識しないチーム
継続して改善サイクルを回していくなかで、チームにスクラムの価値観が浸透していきました。結果として、スクラムを意識しないけれども、スクラムの活動に近いものを行うようになりました。スクラムの価値観を取り入れて自分たちの文脈に落とし込むことで、主体的な改善がしやすくなりました。スクラムの一般的な概念に囚われずに、自分たちはどうしたいかを考えて実践しやすい環境になりました。
スクラムマスターを運営奉行と呼ぶ
今年度に入り、開発チームの運営を担当する役割を私とPM(プロジェクトマネージャー)の２人で始めました。この役割は、スクラムマスターに相当する立ち位置だと思います。その後の活動の中で、自身を運営奉行と名乗るようになりました。役割としては、チームの現状を分析して、定期イベントのやり方の調整をメインに行なっています。スクラムを自分たちの文脈に落とし込んだ結果、運営奉行が生まれました。
開発チームの方針を、「個々がアイディアを出し、それぞれで動けるようにしよう」というものにしました。そこでアイディアを発表し意見を集める場を作ろうと考え、生まれたのが「大名会合」です。大名会合では、個々のメンバーが大名となって、アイディアの提案やディスカッションを行います。これにより、個々の考えから、チームで合意形成するまでの流れをスムーズにすることができました。
そして、大名会合という名前から運営チームを運営奉行と呼ぶようになりました。
運営奉行のよいところ
これまで、ふりかえりの実施は私を含めたメンバーによって、ボトムアップの形で発案をして試行錯誤してきました。その中で、「開発チームの方向性はこれでいいのかな？」「PMと認識齟齬がないかな？」と悩むことがありました。運営奉行では、最初からPMを巻き込んでいるので、その悩みがなくなり効率よく意思決定を行うことができるようになりました。また、PMならではの情報網があり、チームを客観的に分析することもしやすいです。結果として、本質的な問題にも取り組みやすい状況になりました。
運営奉行にて、ふりかえりのふりかえりを実施しているのも良い点だと思っています。これはふりかえりの内容を分析して、どんなふりかえりだったか、どうやったらよりよくなりそうかを考える場です。チームの中から客観的に、チームを見つめ直す機会は日頃仕事をしていると持ちづらいと思います。ふりかえりで立ち止まって考えたことを、さらに客観的に分析することで、開発チームの状況を分析し効果的な改善を行いやすくなっています。
運営奉行が開催する定期イベント
開発チームの定期イベントとしては下記を実施しています。それぞれを紹介します。
大名会合
進捗管理会
昼会
ふりかえり
Qのふりかえり
大名会合
運営奉行という名前のきっかけにもなった大名会合は、プロダクトバックログ作成のイメージが近いと思います。私のチームには、プロダクトオーナーを置いていないので、メンバー全員でその役割を担っています。各メンバーは大名として、新機能やグロースの施策の提案、改善案などやりたいことを持ってきます。また、大名会合を開催するにあたってスプレッドシートに記載をしてもらいます。アイディアがあるけど人を集めるのは大変という壁を除くために、記載をするだけで気軽に会合を開催できるようにしました。大名会合という機会を作ることで、個々のアイディアの発信とディスカッションが行いやすくなりました。また、ディスカッションを通して、各個人のサービスに対するスタンスの理解も深まっていると感じています。
独自のものなので具体的な流れを紹介します。
🧑🏻💻 個人：やりたいアイディアを練る。大名会合のアイディア用のテンプレートページがあるので、そこにアイディアの目的や方法などを記載
🧑🏻💻 個人：アイディアのページのリンクをスプレッドシートに記載
📩 通知：大名会合の曜日にスプレッドシートに記載があれば会合を開催
🎎 会合：アイディアの発表を行い、質疑応答をする
🎎 会合：5段階評価で投票を行い、アイディアに対する自身のやりたい度合いを意思表示する
🎎 会合：評価をもとにディスカッションを行い、最終的に開発チームとしての今後の取り組み方の合意をつくる
進捗管理会
進捗管理会はプランニングに近いです。字面だけ見ると怖そうなイメージですが、良い名前が出せなかったのでこのようになっています。内容は、ビジネス面でのスケジュールの要求と、開発状況のすり合わせを行う場です。スプリントを採用していないので、明確なタイムボックスは設定していません。会の流れとしては、長期的なスケジュールを確認して、ビジネス面でのリリース時期の要求を考慮しながら、開発スケジュールを組み立てます。その後、短期的な直近のリリーススケジュールの認識を揃え、具体的にいつ何がリリースされるのかを確認します。
最後に、「1週間後の私」というコーナーがあり、昼会のタスク共有ではわかりづらい個々の1週間の予定を共有しています。狙いは、先の予定を見える化することで、チームの余力を確認したり、タスクの受け渡しができそうな人を確認できるようにすることです。
その他
昼会はデイリースクラムです。個々のタスクや困っていることの共有とプロジェクト全体のやっていることの見える化をします。またKPIとして設定している数値を確認して、現在の目標達成状況のチェックをします。
ふりかえりは２週間に一回の開催です。１０人以上のメンバーがいるチームなので一人あたりの発言量を増やすため、チーム分けをしています。それぞれのチームでふりかえりを行い、最後にチーム間で深堀りした内容を共有しています。
Qのふりかえりは3ヶ月に一回の開催です。通常のふりかえりでは行いづらい長期的な目線でのふりかえりを行います。
これらのイベントは、必要なものを足したり減らしたりさせていった結果、この形に落ち着きました。運営奉行の2人でふりかえりのふりかえりを行ったり、進捗会後のふりかえりを行い、現在のチームを分析して必要なアクションを考え、定期イベントの実施方法を見直しています。
よかったこと
運営奉行をやってきた今年度、チームの中であった印象的な出来事を紹介します。
新しい技術領域にチャレンジする人が、大型改善アイテムの開発に詰まってしまったことがありました。その際に、それぞれのメンバーが個々のタスクの調整をして、困っている人をフォローする動きができました。日頃からのタスク状況の共有や、全体スケジュールの理解を通じて、困ったときにヘルプがしやすい環境にできたのだと思います。
Qのふりかえりを通して、長期的な視野での取り組みを考えられました。今年は開発チームに新卒入社のメンバーが入りました。しかし、リモートワークの環境での新人さんをどのようにサポートしていくか？については知見がありませんでした。この部分に関して、Qのふりかえりで次に新しい人が入ってきたらどうするかを話し合うことができました。
そして、支え合うチームになった
よかったことで紹介した事例のように、開発チームはお互いを支え合うチームに変わっていきました。個人の能力で成果を出すのではなく、チーム一丸となって成果が出せるようになりました。これからもどんどんチャレンジして、変化していけるそんなチームです。
スクラムはどうやって始めたらいいのだろう？と悩みながら、試行錯誤をしてきました。必要だと感じたことに取り組み、自分たちの文脈に落とし込んできた結果、私が理想としたチームの形に近づいてきたことを実感しています。