はじめに
こんにちは!
ourlyでバックエンドエンジニアをしております @naoto_911 です。
この記事は開発生産性 Advent Calendar 2024の24日の記事です。
ourlyでは開発生産性の向上について取り組んでおり、Four Keysや開発生産性の可視化ツールとしてFindy Team+(以後Team+と記載いたします)を導入しています。
今回プロダクトチームの3Q（2024年10〜12月）サイクルタイム目標として設定した「commitからmergeまで平均34時間」に対して、15.7時間と大幅に目標達成することができました!
その要因として効果のあったWIP制限について共有いたします。
※画像は2024/12/23時点のものとなります。
この記事の主張
3Q当初の課題感について
2Q成果と3Q課題について
ourlyでは、2Q終了時点でサイクルタイム=42時間という結果で着地しました。
2Q内で振り返りの精度を上げたこと(詳細はこちらに記載)で、次にボトルネックとなっている箇所が、「review~apporve」のプロセスであり、その最たる原因が「自身のPRを出した後に、レビュー待ち時間がもったいなくて、後続の実装を初めてしまう。そのまま集中してしまって、前者のPRのレビュー修正への着手が遅れる」という問題でした。
つまり、一時的に発生する相手側のフロー効率の悪さ(レビューをすぐ見てくれない)ことにより、自身のリソース効率を上げようとしてしまい(後続実装をスタート)、その結果、自身がフロー効率を悪くする原因となってしまう(後続実装に集中してしまい先行PR修正への着手が遅れる) ということです。
この原因については、これまでに何度もチーム内の振り返り時に、話はしており、徐々にサイクルタイムは下がっていました。しかし、大幅な改善ができておらず、マインド面の変革によるサイクルタイムの変化には短期的なインパクトが生まれにく、限界があると私は判断しました。
以上より我々は以下のようにプロセス目標値を設定し、その施策としてWIP制限を導入することにしました。
| Cycle | commit~open | open~review | review~approve | approve~merge | |
|---|---|---|---|---|---|
| 現状 | 43h | 17h | 9h | 15h | 2h |
| 目標 | 34h | 13h | 8h | 11h | 2h |
| 差分 | -9h | -4h | -1h | -4h | 0h |
WIP制限の狙いについて
WIP制限について
WIP制限(Work in progress制限)とは、一般的に 「同時並行で行える作業の上限をチームに設定することで、リソース効率を下げ、フロー効率を高める」 ための施策だと私は解釈しています。
そのため、この仕組みを普通に適用すると、「チーム内で同時にオープンできるPRはn件まで」というルールができあがります。
しかし、私はこの方法では、レビュー負荷が一時的に高い人がずっとレビューだけをやってしまう状態(負のスパイラル)が発生すると考えました。また、実装スピードに差があるチームの場合も同様に、実装スピードが早いメンバーがチーム内のWIP上限の過半数を使ってしまうと考えました。そして、我々のチームでこの現象が充分に起こりうると判断しました。
ourlyにおけるWIP制限のルールについて
以上の経緯よりourlyにおけるWIP制限ルールは 「一人1PR以上の同時作業を禁止する」 というルールにしました。
また、同時作業の定義ですが、以下の作業はWIP制限中でも作業を許可する運用にしました。
- 調査タスク(後続PRの不確実性を下げる目的で部分的に調査を行う作業)
- 設計タスク(後続PRの設計や実装方針となるドキュメントをUMLなどを用いて作成する作業)
- 第二領域タスク(メンバーが各自で持つ機能開発以外の作業)
このルールを適用し、運用をスタートしたところ、見事にレビュータイムが下がっていくことをTeam+上でも確認することができました。
当初の狙い通り、後続の実装ができないのでレビュー修正への着手が速くなったり、そもそもレビュアーが早くレビューをしてくれないと自身の作業ができなくなるので今まで以上にレビュアーへのレビュー以来の催促や、レビュー負荷低減のためのコラボレーションが増えていきました。
また、チーム内の振り返りで繰り返しWIP制限による排反がないか? を定性的に問い続けたものの、特に排反がなく、とても効果的な施策として作用していることがわかりました。
発生した問題
数値のhackが起きてしまった
しかし、事態は急変します。
ある日のSP振り返りの場で、WIP制限の排反を聞いたところ以下のような発言はでてきました。
「正直WIP中にやっている他の作業で後続実装が大幅に進んでおりそれがサイクルタイムに計上されていないので後ろめたさを感じている」
その後、ヒアリングにより、WIP制限中に以下のような作業をしていることがわかりました。
- 実装が完了しPR作成する
- レビュー待ち時間の間に、後続実装の調査を開始
- 調査の過程で後続実装が実質本実装と同じように進んでしまう
- しかし、WIP制限ルールがあるのでブランチは仮で作成している
- 先行PRが完了したら、調査で作業した後続PRをソースコードごとコピーする
- そのため調査中の時間に作業した分が本実装として0時間となり計上されない
- 結果的に、サイクルタイムの「commit~open」の時間が実態よりも低くなる
何が問題だったのか?
この問題の原因が主に2つあるのでそれぞれについて記載します。
①目的意識が時間と共に希薄化すること
私がチームへ施策を発信した時には、施策の目的が理解されていたと感じています。
一方で、時間経過とともに薄れていき、目の前のルールや手段が先行してしまっていたことが原因だと感じています。
そして、そのためにも推進者は、目的の情報発信を継続して続ける必要があるということです。
仮に、一度発信した内容が完全に伝わってその時は理解できていたが、時間経過とともに記憶から薄れていき、手段が先行してしまう可能性があります。そのためにも、繰り返し継続的に情報を発信し続けることが必要であると改めて学びました。
②排反確認を拾う仕組みの質が低かった
今回の問題はWIP制限による排反を継続的に確認し続けたことで気づくことができました。
一方で、確認のフォーマットを改善したらもっと早くこの問題に気づけていたかもしれません。
定性的な意見を適切に拾い上げる上では問いのフォーマットが重要です。
この部分にはまだまだ伸び代があるので今後も改善していきます。
3Qの結果
定量
最後にTeam+の画面上でWIP制限の効果を確認します。
WIP制限の狙いは、リソース効率に制限をかけることで、「review~approve」のフロー効率を高めてレビュータイムを短くすることでした。
下図は、「review~approve」の実績のみに絞ってサイクルタイムの遷移を確認したものです。
狙い通り徐々にサイクルタイムが下がっており、最終的に12月には、2.5時間にまで削減することができました。
一時は数値のhackも発生してしまいましたが、狙いの部分であったレビュータイムには継続して効果的に作用していることをTeam+上でも確認しました。
(数値のhackによって一時的に、「commit~open」の時間が短縮された部分が一部あったと推測されますが、「review~approve」にはこの影響は出ない*正確には出るが、レビュータイムが長くなる形で作用するのでもっと短縮できると示唆されます)
定性
定量的にWIP制限が効果的に作用したことは確認できました。
一方で、他に効果があったことはなかったのか? や、定量的な数値がよくなることでどのような嬉しさがあったのか? も把握したくなりました。
そこで、定性的なアンケートも実施しました。
アンケート結果に記載された内容を要約してまとめたもの
スコアが良くなった要因はなんだと思いますか？
やはりWIP制限によって生まれた効果にポジティブな意見が圧倒的に多いです。
また、チーム内で開発のプロセスを変更した部分(先に不確実性の高い設計/実装方針を進める、FEのタスク分解粒度の向上)も作用していることがわかります。
どのような変化や嬉しい効果がありましたか？
3Qを通して「成長実感」や「開発者体験向上」を感じることができたメンバーが多いようです。
特に、WIP制限によって、レビュアーとしてだけではなく、実装者としてレビュアーへの配慮をより意識することになり、その結果工夫した中で自身の「成長実感」を感じたメンバーが多いことがわかりました。
最後に
いかがでしたでしょうか?
今回はWIP制限によって大幅に成果が出たことと、その最に注意するべき観点である目的の継続的な共有が大事であるということをシェアさせていただきました。
前提として、ourlyでは、昨年度から1年間Team+を運用して行く中で、レビュー優先のカルチャーとマインドがチーム内に築けていたこともWIP制限が効果を発揮した要因の一つではあると考えています。一方で、カルチャーやマインドだけでは大幅な改善が短期的に見込めないのも事実としてあると思います。
前提の部分が築き上げられたチームで一気に改革を起こしたいチームの皆さんに、ぜひとも参考にしていただければ幸いです。
Discussion