チームで1週間ガチでフィーチャー開発のみに全集中したって話

こんにちは！SmartHRで基本機能を開発しているプロダクトエンジニアのnukosukeです。

世の中にはゴールデンウィークと呼ばれるものがあります。家族や友達とお出かけしたり、はたまたお家でゆっくりすることもあるでしょう。

ゴールデンウィーク

一方でスペシャルウィークというのはご存知でしょうか？え？知らない？それもそのはず、SmartHR内の造語です（笑）。

この記事では私たちのチームでスペシャルウィークという取り組みをしたので今回はその紹介です！

※スクラム用語が多めなのでご承知ください。

スペシャルウィークとは？

1週間、フィーチャー開発のみに全集中するというのがスペシャルウィークです。

SmartHRではスクラムで日々開発しており、フィーチャー（機能）開発を１週間スプリントで日々開発をしています。

が、すべての時間をフィーチャー開発に当てているわけではありません。メンバーはチーム外のプロジェクトの作業もあり、色々なことを日々やってます。

このチーム外での取り組みを一切行わずに、フィーチャー開発に全集中するのがスペシャルウィークです。

テスト勉強

なぜスペシャルウィークを始めたのか？

チームで取り組んでいるフィーチャー開発の進捗が当初の予想より遅れている状況でした。

リリース日も近づいていく中、どうすれば山積みのタスクを消化していくのか。

そのような状況で、社内の風の噂で「スペシャルウィーク」なるものを知り、チームでやってみようとなりました。

スペシャルウィークの事前にやったこと

準備運動

スペシャルウィークを発動する前にはいくつか準備が必要でした。例をあげます。

メンバーが普段何に時間使ってるかの認識合わせとチーム外のプロジェクト関係者との調整

フィーチャー開発以外にどういったことで時間を要しているかレトロスペクティブでメンバー同士で認識合わせをしました。

特にチーム外のプロジェクトの作業に予定外の時間消費をしていることがわかったので、チーム外のプロジェクトの作業やミーティングなどは各々のメンバーで調整してもらい、よりフィーチャー開発に時間を費やせるようにしました。

スクラムイベントの調整

SmartHRは1週間スプリントですが、可能な限り作業に集中するためのスクラムの戦略を考えたいところです。調整の具体例としては次のようなものがあげられます。

スペシャルウィーク中にプロダクトバックログリファインメントをしないようにあらかじめバックログをリファインメントしておく。
スペシャルウィークで定型的なタスクを消化できるようにバックログの優先順位を調整する。

スペシャルウィークの期間中にやったこと

ジョギング

期間中にやったこととしては主に２つです。

チーム外のプロジェクトの作業やミーティングはスキップ

「メンバーが普段何に時間使ってるかの認識合わせとチーム外のプロジェクト関係者との調整」でもお話しましたが、フィーチャー開発に集中するため、事前に調整していた通りチーム外のプロジェクトの作業やミーティングはスキップしました。

一部スクラムイベントのスキップ

毎週決まったスクラムイベントがありますが、いくつかスキップして作業の時間に当てました。例えば、「スクラムイベントの調整」でもお話しましたが、プロダクトバックログリファインメントは事前にバックログをリファインメントしておくことで、スペシャルウィークは実施しませんでした。

もちろん、何がなんでもスキップしたわけではありません。例えば次のようなイベントは続けました。

相談や進捗確認をするための、同期的にコミュニケーションを取るデイリースクラム
夕方にSlackに進捗状況や所感を書き込むような、非同期でコミュニケーションを取る夕会
スペシャルウィークの振り返りをするためのレトロスペクティブ

スペシャルウィークの結果

結論から言うと普段の2倍の開発をこなすことができました。

SmartHRではプロダクトバックログに対してストーリーポイントで作業の大きさを見積もっていますが、スペシャルウィーク中は13ポイント分を消化できました。

直前4スプリントの実績が1スプリントあたり大体6.5ptだったので、2倍の作業をこなせたことになります。

その他の数値においても顕著な効果が出ていました。

例えばサイクルタイム（コミットからマージまで）の平均時間は、スペシャルウィークの前月では127時間でしたが、スペシャルウィーク後は15.9時間になりました。つまり、約8倍サイクルタイムが短縮されたことになります。

弊社ではこのようなサイクルタイムを改善する取り組みを紹介している記事があるので、ぜひそちらもご参考ください！

スペシャルウィークの気づき

チームで振り返ったスペシャルウィークを気づきを共有します。

不確実性の低さが実施の条件

いつでもスペシャルウィークを実施できるわけではありません。スペシャルウィークでこなす作業は、やるべきことが決まっている不確実性の低いものに限られそうです。

フィーチャー開発の初期では「どのような仕様にしようか」といった具合に不確実な部分が多いです。一方でフィーチャー開発の後期になってくると仕様策定などの不確実性の高い作業は少なくなり、「あとはやるだけ」のような作業も多くなります。今回の経験ではまさしくフィーチャー開発の後期で「あとはやるだけ」のような作業も多かったです。

今回のスペシャルウィークではこのような不確実性の低いタスクが多かったからこそ、黙々と作業に集中して多くの作業量をこなせたのではないかと思います。

逆に言えば、不確実性の低いタスクが積んである状況でのみスペシャルウィークは発動できるということで乱発は難しそうです。

事前準備が大切

「よし、明日からスペシャルウィークやるぞ！」というノリでシュッと始めることは難しそうです。

スペシャルウィークの事前にやったことでもお話しましたが、チーム外の活動やスクラムイベントの調整が色々と必要です。

事前に「いつのスプリントからスペシャルウィークを実施するか」をチームメンバーで認識をあわせ、準備期間を設けた上で実施したほうが良さそうです。

痛みもある

一見して「スペシャルウィーク、めっちゃええやん！」と思うかもしれませんが、もちろん１週間フィーチャー開発のみに集中するということは他プロジェクトの作業ができないということでもあります。

その他、私たちのチームではちょうど新しいメンバーが入りましたが、いつもよりオンボーディングが手薄になるになることもありました。具体的には、私たちのチームではクロス1on1という、各メンバーと新しく入ったメンバー同士で1on1をしますが、その実施がスペシャルウィークの翌週に後ろ倒しになってしまいました。