はじめに
こんにちは！
Mediiでバックエンドエンジニアを担当している中島です。
私たちのチームでは最近、スクラムチームの構成メンバーが増加したことを背景に、ある問題に直面していました。
それは「開発のリードタイムが長引き、不安定になっている」ことです。
下のグラフは、当時の私たちの状況を示すDevOps分析ダッシュボードの一部です。
ご覧の通り、変更のリードタイムは100時間を超えることが常態化しつつあり、時には120時間に達することもありました。
この状況ではせっかく開発メンバーが増えたにも関わらず、作業の完了見込みが立てづらくなり
その結果、他チームから依頼された機能改修のリリースが遅れ、やむなく運用でのカバーをお願いする、といった弊害も発生し始めていました。
この問題を打開するために、私たちは「WIP制限」という、一見すると原始的にも思えるルールを導入しました。
この記事では、このWIP制限がもたらした予想以上の改善効果について、ご紹介したいと思います。
私たちが抱えていた課題
WIP制限を導入する前、私たちのチームは以下のような課題を抱えていました。
- 長いリードタイム: ストーリーに着手してからリリースされるまで平均100時間以上かかっていた。
- 頻繁なコンテキストスイッチ: 作業の途中でレビュー依頼が来て、また別の作業を少しする…という形で頻繁に思考の切り替えが発生し、開発者の集中力が削がれていた。
- 隠れたボトルネック: 誰がどの工程で詰まっているのかが分かりにくかった。
特にリードタイムのグラフが示す通り、じわじわと悪化していた状況は5月中旬にピークを迎え、120時間という数値を記録します。
この事態を前に、私たちは根本的なプロセスの見直しを迫られました。
導入した施策：WIP制限
そこで私たちが試したのが「WIP (Work In Progress) 制限」です。
※導入の背景にはFindy Team+サポート担当者様からのご助言もありました。この場を借りて感謝申し上げます。
WIP制限とは、「チーム全体で同時に進行してよい作業（タスク）の数に上限を設ける」という、リーンやカンバンの考え方に基づくプラクティスです。
例えば、「進行中」のステータスにあるタスクは3つまで、といったルールを設けます。新しいタスクに着手したければ、まず今あるタスクのどれか一つを完了させなければなりません。
私たちは、「同時に着手できるストーリーは各担当者2件まで」という具体的なルールを設け、5月19日週のスプリントから適用を開始しました。
↓当時のSlack。今思えば、かなり「お試し」感覚でのスタートでした。
変更のリードタイムが劇的に短縮！ (120h → 60h)
そんな半信半疑な雰囲気で始まったWIP制限の厳格化ですが、結果はすぐにグラフ上の数字として現れました。
- 導入前: 90h 〜 120h を不安定に推移
- 導入後: 劇的に減少し、現在は 40h 〜 60h で安定
ピーク時から比較すると、リードタイムが約1/2に短縮されました。これは、開発プロセスが安定し、チーム全体の予測可能性が格段に向上したことを意味します。
開発中の体感としても、「スプリント後半、次は何をしよう…？」「QA待ちのタスクが溜まりすぎているかも…どこから手伝おう…？」といった迷いの時間が明らかに減ったという実感があります。
なぜWIP制限は機能したのか？
今回の結果は、少し恣意的に見えてしまうほどでした。なぜWIP制限がこれほどまでに機能し、リードタイム半減にまで至ったのか。この記事を書くにあたり、その要因を改めて整理してみました。
1. 1つのタスクへ、より深く集中できるようになった: 開発者目線で目の前のタスクに集中でき、課題になっていたコンテキストスイッチのコストが削減された。
2. ボトルネックの顕在化: WIPの上限に達すると、新しい仕事に着手できなくなるため、「どこが詰まっているのか？」を探し、協力して解消するようになった。
3. チームワークの促進: 上記の過程で、手が空いたメンバーが他のメンバーのタスク完了を自然に手伝う「スイミング（群がり）」が発生しやすくなった。「次はこれがQAに来ると思うので、今のうちに見ておきますね」のような会話が増え、チームワークがより機能するようになりました。
こうしてみると、当初の課題に対してWIP制限が的確に作用したのだと、今になって納得できます。
また、目に見える結果が出始めたことで、チームがより積極的にこの取り組みを推進するようになったことも、成功の大きな要因だと思います。
特にチームのデザイナーが、毎朝のデイリースクラムで確認するスプリントボードにWIP状況のグラフを組み込んでくれたことは、意識の定着に大きく貢献しました。
↓NotionでWIP状況を可視化したグラフ
色でWIP制限の状況がわかるだけでなく、ストーリーを分割したタスク数も表示されるため、担当者ごとの負荷がより明確になり、チームの状況把握がさらに容易になりました。
まとめと今後の展望
半信半疑で始めた「担当者一人につき2件まで」というWIP制限でしたが、課題となっていた開発リードタイムは120hから60hへと半減し、劇的な改善の兆しが見えています。
この成功は、単にルールを導入したからというだけでなく、データによって効果が可視化され、それを見たチームメンバーが自発的に改善を重ねてくれたことが大きな要因だと感じています。
このように、チームみんなで業務改善に取り組めるMediiの雰囲気がとても良いなと個人的に感じており、その一例として今回この記事を書かせていただきました。
次のステップとしては、チームみんなでDevOps「Elite」水準（リードタイム平均24時間以下）を達成することを目指しています。
まだまだ改善できることはたくさんあるはずなので、
今回のWIP制限のように、またメンバーと協力しながら、より良い開発の形を探っていきたいです。
この開発基盤がさらに強固なものになれば、安定したペースで既存サービスの改善を続けながら、新サービス『Medii Q』といった新しいプロダクト開発にも、もっと力を注げるようになります。
私自身もプロダクトチームの一員として、一つひとつの開発に丁寧に向き合い、その積み重ねによって、Mediiが掲げる「誰も取り残さない医療を」というミッションの実現に、少しでも貢献できればと思っています。
最後まで読んでいただきありがとうございました！もし同じような課題を持つチームがいらっしゃれば、この記事が何かのヒントになれば幸いです。
Discussion