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

この質問を見ると「詳しく教えてほしい」と思うはずです。

WIP の量を制限することにより、スループットが向上し、チームの作業を少数のタスクに集中させて、「ほぼ完了」状態の作業の量を減らすことができます。基本的には、WIP 制限は「完了」を重視する考えを奨励しています。

さらに重要なのは、WIP 制限がブロッカーやボトルネックを可視化することです。既存のどの作業がボトルネックになっているかはっきり表示するものがあれば、チームは流れを止めている課題の対応に集まり、それを理解し、実装し、解決できます。流れを止めているものが取り除かれると、チーム全体の作業が再び流れ始めます。

こうしたメリットを生かせば、顧客に増加した価値をより迅速に提供できます。結果として WIP 制限はアジャイル開発の貴重なツールとなります。

開発の途中で、こう考えがちです。「そうだ。この課題は一休みして、もう 1 つの課題に取りかかろう」と。2 つの課題をオープンすると、2 つの異なる事柄の間でコンテキストを切り替えたり、チームの仲間と作業をやりとりすることになります。1 つの課題から別の課題への切り替えは簡単にはできません。それには時間がかかり、集中力が低下します。

ほとんどの場合、1 つの課題を開始し、完了しないまま新しい課題を始めるより、初めの課題の作業を継続した方がよいのです。言い換えれば、WIP 制限は開発者自身がフローを妨げるのを阻止しているわけです。

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

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

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

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

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

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

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

• チームのメンバーが新しいコードにとりかかっている間に、コードが陳腐化しないため

• 開発者が元のコードを書くことで得たコンテキストを失わないため

• フィーチャーをリリース用のメインブランチにマージできる状態にするため

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

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

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

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

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

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

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

チームが WIP 制限を実装する準備が整ったら、アトラシアンのカンバン・ボード・テンプレートを使って無料で始めてください。