スクラムチームと自由研究
この記事は、NAVITIME JAPAN Advent Calendar 2020の 1日目の記事です。
はじめに
こんにちは、「メタルは全てを解決する」です。ナビタイムジャパンで経路探索の研究開発に従事しています。
私が所属する研究開発チームはスクラムを取り入れて日々の研究開発を行っています。年明けに開催されるRSGT2021では、チームが辿ってきた実験と成長の道のりについて話す予定です。もしRSGTに参加される方はぜひこちらもチェックしてください。
今回のnoteでは、スクラムチームが悩むことになる「休日を挟むスプリントをどう過ごすか」、とりわけ「冬休みという長期休暇期間をどう過ごすか」という課題に対して「スプリントを止める」「止めた期間で自由研究を実施する」という方法で向き合った話をします。
休日という不確実性
みなさん、休日は好きですか？きっと、多くの人は「もちろん！」と首を縦に振るのではないでしょうか。しかし、スプリントという固定されたタイムボックスを基準として反復的に開発を行う場合、「休日」の存在は少々厄介なものとなります。ベロシティからの着地点の予測が難しくなるからです。
弊社では9-10月に夏季休暇を取るエンジニアが多い傾向にあります。また、9月はいわゆる「シルバーウィーク」と言われる連休が存在しています。私のチームは「この時期にはベロシティがぶれやすい」という課題を抱えています。
上図: 2020年後半のベロシティグラフ。灰色がコミットメント、緑が実績
スクラムガイド日本語版(2020年版)を見ても、スプリント中に休日がある場合はどうするとかメンバーが休むときはどうするとかそういったことは書いてありません。自分たちで考え、判断し、学んでいく必要があります。
現時点での私たちのチームにおける最適解は、「スプリントプランニング時にベロシティ+休日+休暇予定を勘案し完成可能なストーリーポイント数を見積もる」です。ざっくり着地点を定めてから、対話を通して着地点を決めています。これで、すこしづつブレが解消されてきました。
ただ、1~2日の休みならともかく、年末年始のような長期間にわたる休暇が横たわる場合、ベロシティ予測は困難を極めます。そういった状況への対処方法として2年前にとったのが、「スプリントを止める」という方法でした。
スプリントを止めてみる
「スプリントの中止」ー。2017年版のスクラムガイドには、スプリントの中止の項目に下記のような一文が書かれています（※2020/11/19に公開された2020年版からは、該当の記述は削除されました）。
スプリントを中止すると、新しいスプリントのスプリントプランニングのために全員が再度集まる必要があり、リソースを消費してしまう。また、スプリントの中止がチームのトラウマになってしまうこともある。とはいえ、スプリントの中止はめったに発生しない。
確かに、ただ「スプリントを止める」と言ってしまうと対外的にもチーム的にもネガティブな印象を持ってしまいます。ですが、このときは「うまくいっていないから止める」という理由からの中止ではありませんでした。年末年始期間の「ベロシティ予測を立てづらい」という状況への対処、そしてもう一つの目的がありました。それが「自由研究」です。
自由研究
我々のチームでは、普段はチーム単位で優先順位をつけ、スプリントバックログを選定し、開発を進めています。「自由研究」という懐かしい響きは、その「チーム」という制約から解き放たれ、日々やってみたいけどやれていないことに取り組むという意図を込めて名付けました。自由研究期間のルールは下記のように設定しました。
・個人単位で、日々やってみたいと思っていること/気になっていることに取り組む
・緊急度の高いタスク（インシデント対応など）が発生しない限りは自由研究に集中する
こういったことをやるにはいくつか狙いがありました。
・個人単位で課題発見力/解決力を磨く
・チーム単位では優先順位が上がらなかったストーリーの敗者復活戦
・本気でやりたいと思っていることへ取り組めることによるモチベーション向上
さて、実際に「自由研究」に取り組んでみてどうだったのでしょうか。
やってよかった自由研究
自由研究をやってみてよかったことは、それはもうたくさんありました。まとめると以下のとおりです。
・メンバーのモチベーションが高かった
・それぞれの興味関心が改めて浮き彫りになった
・思っていた以上に具体的な「成果」が生み出された
ひとつひとつ解説していきます。
メンバーのモチベーションが高かった
日頃から課題に感じていることに対して取り組むわけだから、モチベーションは高くなるだろうと想定していました。これは想定通りで、「割り込みがあるから進まない」「なかなか手が進まない」ということがあまりなく、年明けの「成果発表会」で多くの研究が何らかの結果を伴う発表まで漕ぎつけていました。
副作用として、自由研究に没頭するあまり残業をしてしまう傾向が見られました。ここはなかなか難しい問題ですね。
それぞれの興味関心が改めて浮き彫りになった
今回、自由研究を実施したのは経路探索の研究開発を行っているチームでした。それぞれが選択したテーマは千差万別で、「経路をもっとよくする」「ツールの使い勝手をよくする」「扱いづらい箇所をリファクタリングする」など多岐にわたっていました。また、テーマ選定の際に「課題意識」だけではなく「自身の能力開発」という観点から普段触れていない技術にあえて飛び込んでいくケースもありました。
チームがお互いを知るには、ドラッカー風エクササイズのような手法や日頃の雑談、1on1といったプロセスが有効ですが、この自由研究期間に表出した「それぞれが解決したいと思っている課題」はお互いの人となりを何よりも雄弁に語っていました。
実際、それまであまり開発環境の整備などには興味がないと思っていたメンバーが目覚ましい改善を生み出してくれたり、自分の技術力に自信が持てなかったメンバーが一歩踏み出し成果を出すことで自信を持つきっかけになったりと、予期せぬ、そしてうれしい発見や学びがありました。
思っていた以上に具体的な「成果」が生み出された
日々、開発を進めていく中ではどうしても「足し算」の発想で物を考えてしまいがちです。少なくとも私はそうです。なので、メンバーが自由研究で「今やっていることをやめる」ことでプロダクト品質が高まる成果を持ってきたことには驚きましたし、「そうか、今やることを止めることで上がる品質もあるのか。それもひとつの開発だな」という学びになりました。
また、いくつかの研究成果はその後の開発効率を大きく向上させるような目覚ましい成果につながりました。
環境構築改善：リードタイムを半日→1時間にまで短縮
リグレッション環境のクラウド+コンテナ化：可用性向上、実行時間を90%弱削減
普段からこういった改善を当たり前のように行える、というのがベストですが、日頃はどうしても価値創出に比重を置いてしまう自分たちのチームには、「自由研究」という期間を通してこういった改善への投資がなされたというのは価値あるものでした。
（そして、企業の中で「自由研究」というものが認められるためには、しっかりと成果につなげていくことは必須要件でもあると思います）
浮き彫りになる課題
当初心配していた、「スプリントの中止」による負のインパクトはほとんどありませんでした（※なお、2020年のスクラムガイドでは、スプリントが中止されるタイミングについては「スプリントゴールがもはや役に立たなくなった場合」とされており、そもそも負の影響については記述されていません）。
むしろ、自由研究期間中に普段は漸進的に行われるプロセス改善が一気にすすんだこともあり、再開以降のスプリントはそれまで以上にバリューを生み出しやすいものになっていました。
そして、自由研究を通して自分たちのチームの課題がつまびらかになりました。上記でも少しふれましたが、本来ならば日々の開発の中で行うべき開発環境の改善が後手に回っているという現実に直面したのです。「自由研究でやりたいこと」は、裏を返せば「普段はやりたいけどできていないこと」です。そして、この自由研究で得られた気づきから、いまは当たり前に改善も行えているよ…と言えればかっこいいのですが、ここが後手に回りやすい状況はまだある、というのが正直なところです。（自由研究自体の課題ではなくチームの課題であり、ここは継続的に改善していきたいです）
そして実験は続く
実は、上記の「自由研究」での成功体験を味わったあと、私はチームから離脱しました。そして今年、当時とはまた違うチームで「自由研究」を実施しようと目論んでいます。その成果については、また別の機会に紹介したいなと考えています。
まとめ
「年末年始、スプリントどうしよう…」というところから、半ば苦し紛れに始まった「自由研究」。実際にやってみると、そこにはいくつものメリットがありました。
・日頃向き合っているチーム単位の優先順位から離れ、一人ひとりが課題を見つけ、解決に向けて動く
・普段は気づけていなかった課題を解決することでチーム全体が前進する
・チームに内在していた課題に気づくことができる
また、私個人としては「プロダクトオーナーがなんでもかんでも判断するより、メンバーと対話し時にはメンバーに判断をゆだねたハイブリッドなオーナーシップを持つほうがよりよいものづくりにつながる」という学びが得られました。
年末年始のスプリントの過ごし方に悩んでいるスクラムチーム、チームに新しい視点を入れてみたいと目論んでいるチームは、ぜひ一度「自由研究」を試してみてください。