ブログタイトル、「WIP」を少なくすることで、もっと多く

このエントリは、SmartHR Advent Calendar 2023 シリーズ2の19日目の記事です

こんにちは、SmartHRでプロダクトエンジニアをしているnomusonです。
2023年6月にSmartHRにジョインしてからSmartHRオプション機能「人事評価」のバックエンドエンジニアとして働いています。

SmartHRでは主にスクラムで開発をしています。規模が大きいプロダクトでは Large-Scale Scrum (LeSS) で開発をしています。私の所属する「人事評価」も2チームの LeSS で開発をしています。
今回は、この半年開発してきた中で私のチームであった WIP (Work In Progress) に関するできごとを紹介したいと思います。

WIP とは

WIP (Work In Progress) は、処理中の仕事のことです。実装中の Pull Request のタイトルに WIP と書いたり、執筆中のドキュメントのタイトルや文中に WIP と書いたりして、仕掛り中であることがわかるように使われます。

書籍「The DevOps 逆転だ！究極の継続的デリバリー」では、工場のライン中に溜まる部品の山 (WIP) が、納期遅延、品質問題の根本原因のひとつであるという話が出てきます。

チームで発生した WIP

リリースまで数スプリント要する機能開発をしていたときのことです。
あるスプリントで、計画していた PBI (プロダクトバックログアイテム) が予定よりも早くすべて完了しました。スプリントはあと半日ほど残っていたので、おかわりとしてバックログから PBI をスプリントに追加して取り組むことにしました。しかしながら、おかわりした PBI は半日で終わるサイズではなく、スプリントの終了時に WIP な PBI が残りました。

数スプリント要する機能開発の PBI を、早くデリバリーするためにおかわりして進めることは一見よさそうに思えます。ですが、スプリントレビューでフィードバックがあり優先度の高い追加の PBI が発生したら、緊急で対応が必要な作業が差し込まれたら、WIP な PBI はどう扱えば良いでしょうか。 WIP を後回しにしたとしても、時間が経ったあとでまた着手するときにスムーズに再開できるでしょうか。

WIP をコントロールしたプロセス改善

スプリント終了時に WIP があると、スプリント計画の妨げになります。 WIP を残さないために、PBI をおかわりするときに以下を徹底するようにしました。

PBI を残りのスプリント時間内で完了できるサイズに分割する
スプリントバックログアイテムを作成する
どこまでの内容をスプリント内で完了できるかコミットメントする (プロダクトオーナーに共有する)

WIP を残さないようプロセスを改善して、変化に適応できるようになりました。

待ち行列理論

LeSS の原理原則の1つに「待ち行列理論」があります。

待ち行列理論では、 WIP をなくしていくことがサイクルタイムにとっていかに重要かが説明されています。詳しくは、Less.works の待ち行列理論のページを見てください。

日々の仕事をしていると WIP なタスクがつい発生してしまいます。WIP なタスクが増えてくると、タスクのスイッチングコストが増えて作業効率が下がります。作業効率が下がると、作業完了までの時間が伸びていき、新しい作業の開始ができなくなり、悪循環が渦巻いてきます。
悪循環を断ち切るためには、WIP を少なくします。そうすることで、もっと多く価値を生み出すことができます。