作業が多すぎるうえにそれを行う人が少なすぎる状況において、経験の浅い管理者は処理量の増大を期待し、複数のタスクに取り組むように人を割り当てます。残念なことに、その結果タスクの完了に時間がかかり、チームはその過程で燃え尽きてしまいます。
そうならないためにも、次のことをおすすめします。
- 作業に優先順位を付ける
- 作業する人を制限する
- 少数の優先度の高いタスクを完了することに焦点を当てる
製造業では、仕掛り（WIP）の量を制限する取り組みを長きにわたり続けてきました。工場は大量の在庫を保有しません。代わりに、企業はお客様から製品を受注すると、部品を社内でオンデマンドで製造するか、または必要に応じて上流のサプライヤーから納入を受け、製品をジャスト イン タイムで組み立てます。このプロセスを正しく実施すると、リードタイムの短縮、品質の向上、コストの削減、無駄の削減につながります。
仕掛り制限を実装する方法
ストーリーボードを使用する。テクノロジー業界において、在庫は目に見えません。作業が山積みになった作業場や、作業の進行状況を確認できる組み立てラインはありません。在庫を可視化する簡単な方法は、チームが行っているすべての作業をインデックス カードに書き出し、ボードに貼り付けることです。アジャイル手法では、これはストーリーボードの作成と呼ばれます。
次のサンプル ストーリーボードは、複数の機能（分析、開発、テスト、運用）にまたがっており、単一のプロダクトのすべての作業を示しています。
（出典: 「Kanban for Ops」ボードゲーム、Dominica DeGrandis 2013）
ストーリーボードの一般的な使い方は、カードの作業が行われた日ごとにカードにドットで印を付けることです。チームは、どの作業で進捗が止まっているか、または必要以上に時間がかかっているかを簡単に確認できます。
制限を指定する。ボードの列ごとに、WIP 制限、つまり一度にその列に入れることができるカードの数を指定します。WIP 制限に達すると、その列にはカードを追加できなくなります。カードが次の列に移動するのを待ち、最も優先度の高いカードを前の列から pull しなければなりません。
WIP 制限を設定し、上記の pull ベースプロセスに従うことが、「かんばん」を実現可能にする唯一のアプローチです。
チームの能力に基づいて WIP 制限を決定する。たとえば、開発者のペアが 4 組ある場合、「開発中」列のカードは 4 枚までにします。
制限を厳守する。WIP 制限によってチームがアイドル状態になり、他のタスクが完了するまで待機することがあります。このときに WIP 制限を引き上げないでください。代わりに、プロセスを改善することでこれらの遅延に寄与している要素に対処してください。テスト環境の準備が間に合わない状況が発生した場合、準備を担当するチームにプロセス改善または合理化を手伝う、と提案するのはその一例です。
仕掛り制限に関する一般的な落とし穴
WIP 制限を実施する組織がよく陥る落とし穴には、次のようなものがあります。
- 見えない作業を考慮しない。チームが担当する作業の部分だけでなく、アイデアから顧客までのバリュー ストリーム全体を可視化することが重要です。これを行わないと、本当のボトルネックを把握できなくなり、実際には作業フローにとって大きな制約となっていない問題への対処に終始することになります（これは局所最適とも呼ばれます）。
- WIP 制限の設定値が大きすぎる。過大な WIP 制限を設定しないようにしてください。チームが時間を分けて複数のタスクまたはプロジェクトを処理している場合、それは WIP 制限が大きすぎることを示す明らかな兆候です。
- WIP 制限を緩和する。人がアイドル状態になっているときに WIP 制限を緩和しないでください。代わりに、そのような人はバリュー ストリームの他の部分の支援に回し、他の箇所での制約につながる問題に対処してもらうようにするべきです。
- 段階的な成果に満足して改善を怠る。WIP 制限を簡単に達成できる場合は、それを引き下げます。WIP 制限のポイントは、システムの問題に対処できるようにその問題を明らかにすることです。もう一つ留意すべきことは、視覚表示に表れる、作業段階の列が多すぎないかということです。デリバリー プロセスを簡素化してハンドオフを削減する方法を模索してください。プロセス改善作業は、フローを増やすために重要です。
DevOps Research & Assessment の調査によると、WIP 制限は、特に視覚表示の使用とモニタリングからのフィードバック ループを組み合わせた場合に、ソフトウェア デリバリー パフォーマンスの改善につながります。
仕掛り制限を改善する方法
- 作業を可視化する。これを行う際には、すべての作業を洗い出し、複数のチームや関係者に対してそれらすべてを可視化するようにしてください（詳しくは、視覚表示をご覧ください）。
- チームの作業能力に見合った WIP 制限を設定します。
- 本番環境サポート、会議時間、技術的負担などの活動を考慮します。
- プロセスのいかなる部分においても、タスクに割けるマンパワーを超える WIP を設定しないでください。
- 時間を分けて複数のタスクを処理することを人に求めないでください。
- 特定の作業が完了したら、その作業を表すカードを次の列に移動し、キューで待機している最も優先度の高い作業を pull します。
- すべての作業に優先順位を付けるために、関係者向けの週次の会議を設定します。出席しなければ作業が完了しないことを関係者に周知します。
- フローを増やす取り組みを行う。システムを介して作業のリードタイムを測定します。作業が開始された日付と作業が終了した日付をカードに記録します。この情報から、実行頻度のヒストグラムを作成できます。これは、作業がシステムを通過するのにかかる日数を示します。このデータにより、ばらつきを小さくすることを目標に、平均リードタイムとばらつきを計算できます。ばらつきが大きい場合は、プロジェクトを十分に見通せていないか、チームの外部に大きな制約があることを意味します。また、ばらつきが大きいということは、将来の作業についての見積もりと予測があまり信頼できないことも意味します。
- 作業プロセスを改善する。ハンドオフの削減、タスクの簡素化と自動化、連携を行い、作業を完了する方法を検討します。障害を取り除いて適切な状態になったら、WIP 制限を引き下げて次の障害を明らかにします。理想は、単一のフローです。つまり、最小限の待機時間またはやり直しでアイデアから顧客へのデリバリーへと作業が進む状態です。この理想は達成できないかもしれませんが、継続的な改善のプロセスでの進路を示す「真に重要な目標」となります。
仕掛り制限を測定する方法
WIP 制限は、測定するというよりは設定するものですが、改善方法を探し続けることが重要です。定期的に振り返る際に、次の質問をしてください。
- バリュー ストリーム全体（アイデアから顧客まで）の平均リードタイムとばらつきを知っていますか？
- フローを増やして作業のリードタイムを短縮する方法を探していますか？
- WIP 制限によって、フローの増加を妨げる障害は表面化していますか？
- それらの障害について何か対処していますか？
次のステップ
- DevOps ページで他の記事やリソースへのリンクを確認する。
- DevOps 研究プログラムを調べる。
- DevOps のクイック チェックを確認する。業界におけるご自身の立ち位置を把握できます。