カンバンのWIP制限：上限の決め方と見直し方

進行中のカードが十五枚もあるのに、ほとんど完了していないカンバンボード。そこに足りないのは活動量ではなく、何に着手しないかという判断です。WIP制限は、その判断を明確にします。合意した作業量に達したら、新しい仕事を引き受ける前に、進行中の仕事を終わらせるか、停滞を解消する方法を探します。

上限の数を選ぶだけでは十分ではありません。何を数えるか、上限に達したらどう行動するか、どのような観察結果をもとに制限を変更するかも決める必要があります。

WIP制限とは

WIP制限とは、定義したワークフロー全体、またはその一部で、着手済みかつ未完了の作業項目数に設ける、合意済みの制約です。カンバンガイドは、WIPをどのように制御するかを定義し、例外を明示するよう求めています。数値による上限は一般的な実現方法ですが、ガイドが全チーム共通の数を定めているわけではありません。

「レビュー」の上限が三件なら、チームの数え方に従い、その列に置けるのは三件です。レビュー担当者一人あたり三件という意味ではなく、三件の難易度が同じという意味でもありません。ボードを設計中なら、まずカンバンボードの作成ガイドを参考にワークフローを定めてください。

数え始める前に、着手と完了の境界を決めます。編集チームでは、依頼された段階はWIPに含めず、執筆開始から公開承認までを含めることがあります。サービスチームでは、最初に手を付けた時点ではなく、依頼を受け付けた時点を着手とする場合もあります。

実際の仕事の流れから初期上限を決める

他チームの上限をそのまま使ったり、人数に根拠のない係数を掛けたりしないでください。現在のボードを見て、何件が進行中か、どこで待っているか、誰が先に進められるか、どの仕事を分担できるかを確認します。週に一度、午後だけレビューする専門家がいる場合と、専任のレビューチームがいる場合では、制約が異なります。

AtlassianのWIPに関する解説では、チームが仕事の流れを学びながら制限を設定・調整するものとしています。初期上限は試してみるための運用上の合意であり、常に枠を埋めるための目標ではありません。

すでに対応能力を超える作業が進んでいるなら、超過分を終えるまで、一時的に新規着手を止めます。数をよく見せるためだけに未完了カードをバックログへ戻すと、情報が失われます。本当に中止した、または実施の約束を取り下げたのであれば、その判断を明確に残してください。

例：記事制作チームのWIP制限

執筆者、デザイナー、ほかの業務も担当するレビュー担当者からなる、架空のチームを考えます。カードは記事内の個別タスクではなく、公開可能な記事一本を表します。現在の負荷を確認したうえで、次の初期ルールを選びました。数値は例であり、推奨の初期設定ではありません。

火曜日、レビューには二本の記事があり、デザインでもう一本が仕上がりました。デザイナーは、上限の対象外となる「レビュー待ち」列を勝手に追加して、そこへ移してはいけません。チームで修正を手伝う、レビューの時間を設ける、本当に次工程へ進める状態かを再確認する、といった対応ができます。待ち時間は見えるままにします。

工程ごとの上限だけでは、全体の負荷は分かりません。このチームでは、引き受けてから公開するまでの記事をすべて数え、システム全体での滞留も確認します。

ブロックされた作業も数える

着手済みで未完了なら、ブロックされていてもWIPです。記事が顧客の承認を待っている場合は、現在の工程に残し、ブロックの印と次の対応を明示します。別の保留場所へ移すと、各列は順調に見える一方で、増え続ける待ち行列を隠してしまいます。

この例では、ブロックされた記事を、工程の上限にも進行中の総数にも含めます。各カードに、不足しているもの、それを入手できる人、次に確認する時期を記します。工程の上限について例外を合意することはできますが、完了するか明示的に中止するまで、総WIPには含まれます。

担当者がボトルネックを直接手伝えない場合もあります。それでも、不足情報の準備、受け入れ条件の明確化、習熟中の人との共同作業、繰り返し起きる遅延原因への対処はできるかもしれません。WIP制限は、必要な知識や資格がない仕事を行うよう求めるものではありません。

緊急作業は例外として明示する

緊急案件が来ても、処理能力が増えるわけではありません。修正をすぐ公開する必要があるなら、どの進行中作業を待たせるのか、誰が例外を認めたのかを示します。専用レーンを設けても、緊急案件を負荷の集計から外さないでください。

有用な例外ルールには、誰が緊急と判断できるか、どの状況が該当するか、同時に何件まで扱えるかが含まれます。「重要な関係者に頼まれた」では曖昧です。記事制作チームなら、公開済みの記述に重大な誤りがある場合は該当しても、新しい記事を少し早く出したいという希望は該当しないかもしれません。

例外が頻発するなら、個別の出来事ではなく傾向として見直します。ほぼすべてが上限を迂回するなら、受け入れルールが不適切か、両立しない約束を引き受けているか、「緊急」という言葉が意味を失っています。

忙しさではなくフローのデータで見直す

カンバンガイドでは、WIP、スループット、作業項目の経過時間、サイクルタイムを区別します。平たく言えば、着手済みの量、一定期間の完了数、未完了の仕事が着手後どれだけ経過しているか、完了した仕事にどれだけ時間がかかったかです。比較するときは、着手と完了の定義をそろえます。

レビューの上限を下げた結果、執筆者が毎回同じ承認を数日間待っていると分かったとします。上限を上げても、列が長くなるだけで承認は早まりません。慎重な確認が必要な記述を早めにレビューする、代わりに承認できる人を決める、といった変更のほうが有望です。

十分な期間を取り、似た作業同士を比較し、人員や項目の大きさの変化も記録します。落ち着いた一週間だけで最適な上限は判断できません。可能なら一度に一つのルールを変え、理由を残し、品質を損なわずに古い作業が完了していくかを見ます。依頼の流入が減っただけなら、進行中件数の減少を成功とは言えません。

ボード上にルールを表示する

Boardmixを開き、記事制作チームのボードを「執筆」「デザイン」「レビュー」「公開待ち」に分けます。列の見出しには、合意した上限の3、2、2、2を記入します。一記事につき一枚のカードを使い、ブロックされた仕事は待ちが発生している工程に残します。火曜日の確認では、レビューの二枚のうち一枚が先へ進むまで、三本目の記事をデザインに置いておきます。レビュー担当者と次の対応を記したメモを加えます。カードを動かしたら、記入した件数も一緒に更新します。これらのラベルはチームの運用ルールを表すものです。

ワークフロー自体が合っていないなら、カンバンボードの事例で別の構成を比較してください。上限を話し合う際は、「次を始める前に、どの未完了の仕事を完了へ近づけられるか」という実務上の問いを中心に据えます。