Amazon Web Services ブログ
仕掛かり (WIP) を減らして速く届ける
本記事は 2025 年 3 月 4 日 に公開された「Deliver Faster by Limiting Work in Progress」を翻訳したものです。
ソフトウェア開発チームは、ビジネスや顧客が期待するタイムラインで機能を届けることに苦労してきました。最近の BCG の調査では、回答者の社内ソフトウェア開発プロジェクトのうち 3 分の 1 以上に遅延が発生していました。デリバリーの遅れは ROI を先送りし、関係者の不満につながります。
ソフトウェアデリバリーを加速するうえで組織が直面する課題は数多くありますが、影響が大きく、比較的シンプルに解決できる課題が 1 つあります。同時に手をつける仕事が多すぎる、という問題です。
マルチタスクの罠
あるチームに 6 週間規模のプロジェクトが 3 つあるとします。
- プロジェクト A: 顧客向けモバイルアプリの更新
- プロジェクト B: 重要なセキュリティ強化
- プロジェクト C: パートナー連携用の新しい API
チームがプロジェクト間でコンテキストスイッチを繰り返すと、作業は停滞します。絶え間ない会議と異なるステークホルダーの期待管理に追われる——そんな経験は誰にでもあるでしょう。結局、3 つのプロジェクトはほぼ同じ時期に完了します。
- プロジェクト A: 16 週間
- プロジェクト B: 17 週間
- プロジェクト C: 18 週間
影響は深刻です。モバイルアプリはピークシーズンを大きく過ぎてからのリリースになり、セキュリティ更新の遅れはステークホルダーを不安にさせ、API の遅延はパートナーのオンボーディング機会を逃します。
一方、チームが 1 つのプロジェクトを完了させてから次に進めば、モバイルアプリをわずか 6 週間で届けられます。セキュリティ更新は 12 週目、API は 18 週目に完成。全体の作業量は同じ 18 週間ですが、コンテキストスイッチする場合と比べて顧客へのアップデートは 10 週間早くなります。セキュリティの修正も 5 週間前倒しでき、プロセス全体の効率も上がります。
シンプルな解決策: 仕掛かり制限 (WIP リミット)
仕掛かり制限 (WIP リミット) とは、チームが同時に手をつけるアイテムの数を制限するやり方です。WIP リミットを導入すれば、市場投入までの時間を短縮できます。
Siemens Health Systems の開発チームが WIP リミットを導入したところ、デリバリーのサイクルタイムは 71 日から 43 日へ、42% 短縮されました。リソースの追加も残業の増加もなし。同じチームが同じ量の仕事をこなしながら、顧客への価値提供を約 1 か月早めたのです。品質面でも改善があり、初回テスト合格率は 75% から 95% に上昇。同時に抱えるアイテムを減らすだけで、デリバリーは速くなり、成果の質も上がります。
システム内の平均アイテム数に関するリトルの法則は、WIP が増えるとデリバリー時間も増えることを数学的に示しています。
各変数の意味は以下のとおりです。
- L = システム内の平均アイテム数 (WIP)
- λ = 単位時間あたりの平均完了数 (スループット)
- W = アイテムがシステム内に留まる平均時間 (サイクルタイム)
仕掛かりが 10 アイテム (L) で、週 2 件完了 (λ) の場合、各アイテムの所要時間は 5 週間 (W) です。
WIP を 20 アイテムに倍増させると、完了ペースが同じでもデリバリー時間は 10 週間に倍増します。
デリバリーを速くするには、スループットを上げる (リソースの追加が必要) か、WIP を減らす (集中力が必要) かの 2 択です。WIP リミットの導入に大きな投資や複雑な変革は不要で、最もコスト効率の高い改善手法の 1 つです。
WIP リミットは制約 (ボトルネック) に効かせる
WIP リミットはボトルネックに適用してこそ最大の効果を発揮します。制約理論 (Theory of Constraints) によれば、プロセス全体のスループットは最も遅いステップで決まります。
バリューストリームマッピングを使えば、制約を特定できます。構想から本番までの開発プロセス全体を可視化し、作業が滞留してボトルネックが生じている箇所を明確にする手法です。たとえば、テスト待ちのコードの山や、デプロイ承認待ちの機能が見つかるかもしれません。ボトルネックがデリバリー全体の速度を決めています。
ボトルネックとなるステージに WIP リミットを設定すると、システム全体を調整する「プル」効果が生まれます。ボトルネックのステージが WIP リミットに達すると、上流のステージはそれ以上作業を押し出せなくなるため自然にペースが落ちます。作業が制約箇所に積み上がるのを防ぎ、システム全体の WIP が減少。下流のステージも、ボトルネックを通過する速度に合わせて処理が進みます。
典型的な開発プロセスでは、テストがボトルネックです。WIP リミットがなければ、10 件が開発中、6 件がコードレビュー待ち、8 件がテストで詰まり、3 件がデプロイ待ち——合計 27 件が仕掛かり状態になることもあります。テストの WIP リミットを 4 件に設定すると波及効果が生まれ、コードレビューも 4 件以上は送り出せなくなるため、開発もより少ない機能に集中します。結果として、開発 4 件、レビュー 4 件、テスト 4 件、デプロイ 2 件の合計 14 件に減少。週 3 件の完了ペースが同じなら、サイクルタイムは 9 週間から 5 週間弱へ、ほぼ半減します。
はじめの 12 週間: WIP リミット導入ガイド
WIP リミットの導入は、まずパイロットチームを選ぶところから。変化を受け入れる姿勢があり、現在の作業量に苦戦しているチームが最適なパートナーです。チームとステークホルダーを集め、構想から本番デプロイまでの各ステップをバリューストリームマップに落とし込みましょう。作業が溜まりやすいステージに注目してください。WIP リミットの効果が最も大きい箇所です。
ボトルネックを見つけたら、現在のワークロードの 70〜80% を目安に初期の WIP リミットを設定します。急激な変化でデリバリーを止めず、程よい緊張感を生む水準です。先ほどの開発プロセスの例なら、テストの初期リミットは 6 件に設定します。
パイロットチームのサイクルタイムを 4 週間計測します。各作業アイテムが完了するまでの日数を数え、月あたりの完了件数 (スループット) を記録。開発やテストなど各ステップの所要時間を計り、チームが慣れてきたらボトルネックの WIP リミットを引き下げます。
最初の 4 週間が経過したら、リミットを 10〜20% 削減します。この幅なら進捗と実用性のバランスが取れます。厳しすぎるリミットは抵抗を生み、緩すぎると行動変容につながりません。チームの状況に合わせて調整してください。10 人の開発チームなら、同時作業 8 件でスタートし、完了ペースが安定するにつれて 6 件に引き下げるイメージです。
同じ指標を 8〜12 週間計測し続け、変化を確認します。仕掛かりが減れば各アイテムの完了は速くなりますが、月あたりの完了件数は変わりません。週 3 件完了のチームなら、図 2 のような結果が見えてきます。
図 2. 8 週間にわたる WIP リミットの効果
WIP リミットに達したチームメンバーは、新しいタスクを始める代わりに、進行中の作業を支援しましょう。バグ修正、コード改善、ツール更新、ナレッジ共有などが対象です。個人の体感としては作業が遅くなったように見えるかもしれませんが、チーム全体では完了が速まり、デリバリーが加速します。
パイロットから組織全体へ
パイロットが成功したら、WIP リミットを組織全体に展開します。まずはパイロットチームと日常的に連携しているチームから始めましょう。日々の協働を通じて既にメリットを実感しているチームです。類似の課題を抱え、同様の要件で作業しているため、導入がスムーズに進みます。
WIP リミットは段階的にスケールさせます。チームはストーリーレベルで作業しますが、大きなイニシアチブは複数チームにまたがることがあります。そうした上位レベルにも WIP リミットを適用してください。部門リーダーはアクティブなイニシアチブの数を制限すべきです。チームが WIP リミットのもとで安定してデリバリーできるようになれば、リーダーはポートフォリオレベルでも WIP リミットを活用するようになります。
WIP リミットをデリバリープロセス全体に広げましょう。初期構想から本番デプロイまでの流れをマッピングしてみると、コードを書く前からプロセスが始まっていることに気づく組織は少なくありません。各ステージに WIP リミットを適用すれば、デリバリープロセス全体の流れを円滑に保てます。
着手を止めて、完了させよう
WIP リミットは今日のソフトウェアデリバリーを速くするだけではありません。将来の課題にも対応できる組織をつくります。WIP リミットでデリバリーを速めた組織は、規模が拡大してもそのスピードを維持できます。
開発チームには、もっと速く届ける力が既にあります。WIP リミットで引き出しましょう。