はじめに
WIP制限を導入したことでの気づきを書いていきます。
導入理由
当初開発メンバーが２名になり、チームでの開発の体制をスクラム開発の形で回していくことになり、その中で色々と問題が出てきました。
その中でもバグ修正や機能開発のリードタイムが長いという課題があり、調査するといくつか原因があることが分かりました。
- どちらかの進捗が遅れたり、工数に差があったときにレビュー待ちのタスクが溜まる
- かといって自分のタスクを止めてレビューを優先して進めていると自分のタスクが終わらない
これらを解消する手段としてWIP制限を導入することにしました。
導入
メンバーの人数＋１でWIPの上限は３としました。
ただWIPの上限を決めるだけでは上限に達した時点で待ちが発生するだけなので、以下の取り組みを同時にはじめました。
- ペアプロ
- スプリント計画の時間を長く取りチームでタスクの深堀りをする
- タスクの優先順位を明確にする
ペアプロについて、基本は１人で１タスクを担当し、悩んだり詰まったりしたときにヘルプで実施する形をとりました。
運用上発生する差し込みのタスクや、緊急度の高いタスクは制限の対象外として扱っています。
導入後の変化
結論から先に述べると問題になっていたリードタイムを短縮することができました。
- ペアプロを行うことで実装に掛かっていた時間が短縮された
- ペアプロで実装の内容を把握した上でのレビューになるためレビューの時間が短縮された
- イテレーション計画時にチームとしてタスクを深堀りすることでお互いに実装のイメージを共有できているため実装とレビューの時間が短縮された
- チームとして優先順位の高いタスクを終わらせる意識ができた
- 差し込みのタスクが発生したりどちらかが休んだ場合でも、タスクの引き継ぎが可能なので優先度の高いタスクを止めずに進捗させることができる
上記が主な理由です。
また副次的な効果としてペアプロやイテレーション計画での会話が増えたことにより、コミュニケーションをとることのハードルが下がったことで相談や質問をしやすくなりました。
まとめ
WIP制限を実施する上でのメリットとして挙げられるタスクの切り替えが発生しづらいという恩恵は差し込みタスクをWIPの制限外に置いているということもあり、あまり感じることができなかったです。
そのあたりはまた改善していこうと思います。
今回分かったことは、WIP制限をかけること自体が重要なわけではなく制限をかけた上でどのような取り組みを行うのか、チームとしてどのような意識を持つのかが大事だということです。
ここまで読んでいただきありがとうございました。
Discussion