研究開発チームでアジャイル開発を取り入れた話
この記事は、NAVITIME JAPAN Advent Calendar 2021の 19日目の記事です。
こんにちは。デルタです。ナビタイムジャパンで道路規制や渋滞情報などの交通情報提供を担当しています。
今回は交通情報チームで今年4月からアジャイルを取り入れはじめた事例について紹介します。
この記事の想定読者について
アジャイルの基礎知識はあって、これからチームで導入してみたい人を想定しています。
特に研究開発などを行っているチームであれば共通するところも多いかと思います。
アジャイル導入時は似た業務を行っていてアジャイルを取り入れているチームを見学するのが一番わかりやすいと思うのですが、そんなチームは身近にない！という時に参考になればと思い執筆しました。
アジャイルやスクラムに関する用語の解説は記事内で行っていませんので、もしわからない用語があれば適宜調べていただければと思います。
導入したチームはどういうチーム？
人数は6名のチームです。
カーナビ等で経路を調べた際の予想到着時刻の精度を上げる研究開発がメイン業務となっています。
アジャイルを取り入れてからやっていること
主に2週間スプリントのスクラムを中心に取り入れています。
プロダクトオーナーはマネージャー、スクラムマスターは自分が担当しています。どちらも開発との兼任です。
スクラムイベントとしては
スプリントプランニング
朝会（デイリースクラム）
スプリントレビュー
ふりかえり
を行っています。
スプリントプランニング
プロダクトオーナーがこの2週間でやってきてほしいタスクをバックログから持っていきます。ファシリテートもプロダクトオーナーが担当しています。
導入したてのスプリントでは各自の担当のタスクを自分で定義して持ってきていましたが、プロダクトオーナーの役割を明確にし、担当者を固定にしない（チーム全体で担当するという意識をもつ）ためにこの方式に変更しました。
ただし、交通情報チームではプロダクトオーナーは開発者も兼任しておりすべてを把握することが困難なため、他のメンバーも次のスプリントで必要そうなタスクがあれば適宜持ってくるようにしています。
プランニング中はそれぞれのタスクについて「何を満たせば完成となるのか（DoD）」を定義し、それがどれくらいかかるかをプランニングポーカーを行って決定しています。
ここで各自が考えているDoDやストーリーポイントにズレがあれば話合いを行ってすり合わせを行います。
すべてのタスクについてDoDとストーリーポイントが決定したらスプリントを開始します。
交通情報チームでは2時間確保していますが、1時間半程度で終わることが多いです。
開発期間中
デイリースクラムとして朝会を毎日15分行っています。
しばらく動いていないチケットがある場合や、割り込みのストーリーが発生した場合はここで確認して見直しを行います。
また、毎週15分の1on1を行っています。
1on1ではプロダクトオーナーと各メンバーが雑談や業務での困りごとなどを話す時間になっています。
最近は開発手法としてモブプロを取り入れ始めました。
交通情報チームの特性として運用するモジュールが多いため、全員で集まることが難しい場合はペアプロで開発するなど、チームで開発を行うことを重視しています。
スプリントレビュー
各タスクについて担当者が見える形にして成果物を持っていき、プロダクトオーナーと開発者全員で確認します。交通情報チームでは1時間確保しています。
ここではプロダクトオーナーは確認する側として集中するため、スクラムマスターがファシリテーターを担当しています。
ふりかえり
このスプリントで良かったことや改善したいことを話し合い、次のスプリントでやったほうがいいことをアクションにします。スプリントレビューの後に1時間確保して行っています。
ファシリテーターはメンバーで順番に担当を回していて、ファシリテーターになった人がふりかえり手法を決めます。交通情報チームではKPTなどがよく使われます。
導入前不安だったこと
研究開発業務でもスクラムを回せる？
交通情報チームは研究開発業務が多く、先の見通しが立たないことが多いです。例えば、渋滞予測精度を改善するためのAという施策を行う際に、
仮実装を行い施策の効果を調査
→ 効果が見込めそうであれば本実装
→ 効果がなさそうであれば別の施策を検討
など、2週間のスプリント中にやれそうなタスクの中にも分岐が発生してしまいます。
このような場合どうプランニングしていけばいいのかというところは最初かなり迷いました。
現在はプランニング時に「A施策の効果がわかっている」というタスクを作成し、調査後に発生するタスクは「割り込み」として調整することで対応しています。
また、割り込みがある想定でプランニング時の全体のストーリーポイントをあらかじめ余裕のある数値にしておくこともあります。
スプリントによっては調整がうまくいかずベロシティが下がってしまうこともありますが、今のところスクラムが回せなくなるほどの支障にはなっていません。
ミーティング時間の増加
アジャイル開発導入時によく言われることですが、ミーティングの時間が増えて開発する時間が圧迫されるのではという不安がありました。
実際、目に見えるミーティングの時間自体は増えました。
しかし、開発を進める中で都度発生する各自の意識や考えていることのすり合わせなど、カレンダーでは見えないような無駄な時間が減ったように思います。
また、各自が仕事を進めるうえで課題だと感じていることを話せる時間があることで開発時の効率はあがっている実感があります。
正確な測定は難しいですが、個人的には消費する時間以上に効果があるなと感じました。
サービスで確認できるような成果物がない場合でもレビューはできる？
研究開発業務ではアプリ開発やWeb開発のようにサービスの画面で見せられるような成果物がないため、初見の人も含めてみんなで共有ができるようなスプリントレビューが可能なのかが不安な点でした。
結論として、工夫することで可能でした。
サービスの画面はありませんが、グラフや結果の数値を報告するなどで見える形でのレビューは問題なくできました。
導入してよかったこと
透明性の向上
以前は各自の抱えているタスクについて自分の担当外の詳細は把握していないことも多くありました。
現在はプランニングでそのタスクがなぜ行われているのか/どのような作業が必要になるのかを全員が把握する仕組みになっているため、担当以外のタスクへの透明性が上がりました。
結果として、属人化がある程度防がれることでタスクの引継ぎや同様の事象への対応が容易になったり、プルリクレビューがしやすくなるなどのメリットがありました。
一人で迷いながら進めることがなくなった
研究開発業務ではどこまで一つの施策を突き詰めるべきか迷う場面がかなりあります。
例えば、施策について現時点では改善の成果が出ていないものの継続して手を加えればよくなりそうな時、手を加える方向に進むか、全く別の施策に着手するかの選択はかなり悩ましいところです。
以前は悩んでいる人が「他のメンバーに相談する」というアクションを起こすまで一人で抱えてしまうことが多かったのですが、スプリントレビューで定期的に現状の確認を行うことで判断を一人で抱えることが少なくなりました。
担当者以外の視点も入ってくるため、施策の結果を客観的に結果を見て判断するという視点も以前より強化されている気がします。
ヘルプを求める・申し出ることが容易になった
こちらは心理的安全性の向上とタスクの把握が容易になったことで生まれたメリットかなと思います。
そもそも導入前から良いチームで雑談は多かったのですが、ふりかえりなどを通して雑談以外の仕事をする上での本音を共有しやすくなりました。
また、スプリント内での進捗を朝会で確認しているので、誰の手が空いていて誰が大変そうなのかというのが、「お気持ち」ではなく形としてわかるようになりました。
この二点が作用して「今空いてるから手伝います！」「手伝ってほしいです！」という申し出が増えたように思います。
もし導入する時は
もしこの記事を読んでいただいて「スクラム導入してみたい！」と思ったなら、しばらくは思い切ってフルでスクラムをやってみるのがおすすめです。
スクラムイベントはそれぞれが互いに作用しているため、一部だけの導入では効果が出にくいかなと思います。
この記事が皆さんのお役に立てば幸いです。