WIP 制限によってワークフローに「フロー」を取り戻す

進行中の作業 (WIP) の制限によって進捗が妨げられることはありません。むしろ、その逆です。

Dan Radigan Dan Radigan
Browse topics

WIP 制限とは?

アジャイル開発では、進行中の作業 (WIP) 制限で各ワークフローステータスの作業量上限を設定します。同時進行できる作業量を制限することで、チームのワークフローで非効率な部分を特定しやすくなります。また、状況が切迫する前に、チームのデリバリーパイプラインのボトルネックがはっきりと見えてくるようになります。

WIP 制限はなぜ重要なのか?

この質問を聞いて「詳しく話して!」と思ってもらえればうれしいです。

WIP の量を制限することにより、スループットが向上し、チームの作業をより小さなタスクセットに集中させて、「ほぼ完了」状態の作業の量を減らすことができます。基本的には、WIP 制限は「完了」を重視する考えを奨励しています。さらに重要なのは、WIP 制限がブロッカーやボトルネックを可視化することです。既存のどの作業がボトルネックになっているかをはっきり表示するものがあれば、チームは流れを止めている課題の対応に集まり、それを理解し、実装し、解決できます。流れを止めているものが取り除かれると、チーム全体の作業が再び流れ始めます。こうした利点を生かせば、顧客に価値のインクリメントをより迅速に提供できます。結果として WIP 制限はアジャイル開発の貴重なツールとなります。

開発の途中で、こう考えがちです。「そうだ。この課題はひと休みして、もう 1 つの課題に取りかかろう」と。2 つの課題をオープンすると、2 つの異なる事柄の間でコンテキストを切り替えたり、チームの仲間と作業を受け渡ししたりすることになります。1 つの課題から別の課題への切り替えは簡単にはできません。それには時間がかかり、集中力が低下します。ほとんどの場合、1 つの課題を開始し、完了しないまま、新しい課題を始めるより、はじめの課題の作業を継続した方がよいのです。言い換えれば、WIP 制限は開発者自身がフローを妨げるのを阻止しているわけです。

最後に、WIP 制限は慢性的な待機状態や過負荷になっている部分を指摘します。これによって、チームは作業を行っている特定の部分だけではなく、プロセス全体の中で効率が悪い部分を知ることができます。

プロからのヒント:

WIP 制限を初めて導入したチームは、落ち着かない感じがするものです。最初のいくつかのイテレーションでは、話し合いに時間をかけてください。いつ、なぜ WIP 制限に達したかを理解しましょう。まずあれこれと調整したくなる気持ちを抑えてください。制限超過が恒常的になった場合は、WIP 制限が厳しすぎるか、またはチームのプロセスが非効率であるか、そのどちらかを示しています。

アジャイル チームで WIP 制限を使用する

WIP の価値に納得できたところで、具体的な話に入りましょう。

新しいワークフローを展開する際は、ステータスごとの WIP 制限値をチームで決めてください。いくつかのスプリントについて、ステータスごとの作業項目数の平均を測定した後で、WIP 制限を設定することをお勧めします。下に示すのは、一般的なソフトウェア開発チームが使用する WIP 制限付きのアジャイルボードの例です。

WIP 制限|アトラシアンアジャイルコーチ

上の例では WIP 制限がコードレビューに設定されています。コードレビューの列で制限を超えているため、背景色が赤くなっています。

課題が完了に達すると実行する仕事はないため、この段階で WIP 制限の必要がなくなります。上のボードでは、「開発前」はストーリーがプロダクト所有者とチームによって入念に吟味されたことを意味します。作業項目に取りかかる際に、開発チームは作業を「開発準備」から「進行中」に移動します。開発チームの各メンバーがフルに活用された状態となるよう、「開発準備」ステータスに十分な作業を保持することが、ベストプラクティスとして重要です。「開発準備」状態に過不足のない程度のストーリーだけ保持することにより、プロダクト所有者は要件を詰める段階で先行しすぎていることがなく、プログラムは変更に対応しやすくなります。

「進行中」ステータスでは、現在開発中の作業が一覧として表示されます。この場合の WIP 制限の目標は、全員に作業があり、誰もマルチタスクになっていないようにすることです。上のボードでは、「進行中」項目の制限数は 4 であり、現在その状態には項目が 3 つあります。このことから、チームにはもう 1 つ作業をする余力があることがわかります。ベストプラクティスとして、WIP 制限の最大値をチームメンバーの数より少なく設定するチームもあります。余裕の範囲内でアジャイルの作業をうまく進めるアイデアです。開発者の 1 人が項目を 1 つ終了したが、チームは既に WIP 制限に達している場合、急いでコードレビューをいくつか済ませるか、または別の開発者にペアプログラミングに入ってもらう時だということがわかります。

「コードレビュー」ステータスは、ストーリーのコードはすべて書かれているが、コードベースにマージする前にレビューする必要があることを示しています。適切な時にコードレビューを行うのはベストプラクティスであり、品質を確立し、新しいイノベーションが市場に送り出すのを早め、未完成のブランチを減らすことによってマージしやすくなり、エンジニアリングチーム全体に知識を広めます。次のいくつかの理由から、この状態の項目には緊急に対応する必要があります。

  • チームのメンバーが新しいコードにとりかかっている間に、コードが陳腐化しないため
  • 開発者が元のコードを書くことで得たコンテキストを失わないため
  • フィーチャーをリリース用のメインブランチにマージできる状態にするため

WIP 制限によって、未レビューのコードが山積みにならないよう保証されます。

上のアジャイルボードでは、チームが抱えるコードレビューが多すぎるため、列の色がそれを示す赤に変わっていることにご注意ください。

注意すべきアンチパターン:
  • チームが今後 WIP 制限に達することがないように、制限を必要に応じて引き上げている。(「債務上限」ですね、何か他にいい表現は?)
  • 皆が膨大な「バックグラウンド業務」を抱え、仕事のない時間がなくなってしまう。
  • チームメンバーは、ボトルネックに対処せず、何もせずに仕事が入って来るのを待っている。
  • エンジニアリング方式やチームプロセスの改善よりも、いつまでも続くボトルネックにスタッフの時間を投入することが優先されている。

WIP 制限を使用するアジャイルチームがめざす 4 つの目標

どの新しいアクティビティでも同じように、はじめは WIP 制限に落ち着かない感じがするかもしれません。この場合のゴールは中期的にチームを最適化することであり、短期的に落ち着かないのは実際はよいことです。WIP 制限によって、チームはプロセスの間に痛みを感じます。数週間 WIP 制限を使用した後、必要に応じて調整をします。チームが継続的に制限に達しているために WIP 制限を上げたくなる気持ちを抑えてください。この機会をとらえて、作業能力を向上させます。理想的には、チームを教育し、各メンバーに新しいスキルを身につけさせるか、または開発プロセスのいずれかの側面を効率化します。

目標 1: 個々のタスクの大きさに一貫性を持たせる。要件やユーザーストーリーを分割する際に、個々のタスクを 16 時間未満に維持することが重要です。そうすることで、チームが自信を持って見積もりを行う能力が向上し、ボトルネックを防ぐことにつながります。パイプラインを詰まらせる大きな作業項目ほど、チームの作業を遅らせ、WIP 制限を悪化させるものはありません。

プロからのヒント:

進行中の作業制限がチームで機能している場合、課題のサイクルタイムは低下します。サイクルタイムは課題を完了するのにかかる時間の量です。詳細については、アジャイルの指標に関するページを参照してください。

目標 2: チームのスキルに合わせて WIP 制限をマッピングする。上の例では、チームのメンバーは同程度のスキルを持っていると想定しています。チームに専門家がいる場合、専門家が関与すると、進行中の作業制限値が変わってきます。専門家の作業向けに特化したステータスを作成してください。そのステータスにボトルネックが生じた場合、その機会を利用して、専門家のスキルを活用して能力を高めるよう他のチームメンバーを教育し、チーム全体のフローを向上させます。

目標 3: 待機状態を減らす。仕事のないチームメンバーを、上流または下流のチームメンバーの手伝いをするように促します。彼らはチーム全体の生産性に貢献し、その過程で学ぶことがあります。

目標 4: 持続可能なエンジニアリング文化を保護する。進行中の作業制限があるからと言って、特定のステータスで過負荷にならないように、開発者が作業を大急ぎで片付ける必要はありません。開発者は確固としたアジャイルエンジニアリング業務をサポートし、製品の品質とコードベースの健全性を維持する義務があります。

次の記事
Kanban vs Scrum