開発バリューストリームマッピングのベストプラクティス

何かを変更できないと言う人がいた場合は、その前提に異議を唱えてください。

ステップを定義する際は、深くしすぎないようにし、また浅すぎないようにもしてください。まずは、エンドツーエンドのハイレベルなバリューストリームから始め、タスクを規模の大きい順に分解してください。ステップの規模があまりにも小さくなり、マッピングにかかる労力と改善から得られる潜在的な価値とを比較して妥当でなくなった時点で、タスクの分解を止めてください。

参加者にとって最適なツールを選択してください。同じスペースで共同作業している場合は、ホワイトボードと付箋を使用できます。参加者がリモートで参加している場合は、オンラインホワイトボード、Microsoft Visio、Microsoft Excel などのデジタルツールの方が望ましいかもしれません。

変更の結果を評価し、さらなる改善の機会を探してください。開発バリューストリームマッピングは一度限りの活動ではありません。これは、新たな制約を特定し、アクションの有効性を評価するための継続的改善サイクルの一部です。

単に都合が良いという理由だけで制約を選ばないでください。優先順位を付けるにはデータを使用してください。制約理論とは、ごく少数の制約があらゆるシステムの制限原因であるとするマネジメント哲学です。チームが簡単に修正できる項目が多数あるとしても、システムを制限しているごく少数の項目に集中することで、最大の価値が得られます。