HCL Accelerate は、バリュー・ストリーム・チェーンとそのボトルネックを可視化して、生産性を高めるソフトウェアです。その解説記事 Bottlenecks in the Value Stream の翻訳版です。
バリューストリームにおけるボトルネック
2020年7月29日
著者: Matthew Steele / Data Scientist
さて、バリュー・ストリーム管理システムがすべてセットアップされたとしましょう。あなたはモニター画面を通して、アイデアの創造から、それが組織から価値を提供する瞬間までを追跡しています。つまり、バリュー・ストリーム・メトリクスを監視しているのです。なんと素晴らしいことでしょう!
では、次は何をしますか?次は、バリューストリームのボトルネックを見つけてください。この記事では、バリュー・ストリームのボトルネックについて考察し、ボトルネックがバリュー・ストリームから効率性を奪う前に、HCL Accelerate を使用して、ボトルネックの出現を検出して緩和する方法を説明します。
なぜボトルネックを追跡するのか
バリューストリーム管理の取り組みから利益を得る最善の方法の1つは、バリューストリームのワークフローのボトルネックを見つけることです。 ボトルネックは、整備されたソフトウェア開発マシンから効率を奪います。バリューストリームのボトルネックを特定して修正することで、プロセスやワークフローの不調や非効率を、多額のコストが発生する前に回避または排除することができます。幸いなことに、HCL Accelerate のようなバリューストリーム管理ツールは、ボトルネックを発見するために必要なデータと、ボトルネックの効率性を損なう結果を回避するためのインテリジェントなモニタリング機能の両方を提供します。
ボトルネックとは
少し形式的な話をしましょう。ボトルネックとは、システムのグローバルなスループットを制限するローカルスループットの制限です。言い換えれば、バリューストリームは、バリューストリームの中で最も制約を受けている部分よりも、与えられた時間内に多くの作業を処理することができません。均一なワークロード(すべてのワークアイテムが同じで、等間隔でシステムに入る)を持つシステムの場合、期待されるスループット(ローカルまたはグローバル)は、期待される処理時間(1 単位のワークを処理するのにかかる時間)に対する処理能力(何個のアイテムを並列に処理できるか)の比にすぎません。このような均一なシステムでは、ボトルネックを見つけるのは簡単です。
キャパシティと予想される処理時間を知ることは、非一様なワークロードでも重要ですが、ボトルネックを見つけるのは実世界のワークロードでは困難です。 ソフトウェア開発のバリューストリーム内のすべての作業が同じように作成されるわけではありません。作業項目によって完了までに必要な作業量が異なり、作業項目には相互に関連した依存関係があり、それらがバリューストリームをどのようにナビゲートするかを決定します。 これらの考慮事項はすべて、キャパシティ/処理時間の分析から明らかになる以上に、一時的なボトルネックを発生させる可能性があります。現実のボトルネックは複雑ですが、幸いなことに、適切なデータがあれば、バリューストリームのボトルネックを発見し、修正し、最終的に防ぐことができます。
ボトルネックを見つけるには
ソフトウェア開発の多くの取り組みと同様に、バリューストリームのボトルネックを発見するための取り組みは、基本的なことを見落とさないように、簡単なことから始めるべきです。バリューストリームのどのプロセスでも、常にリソースが不足していないか?バリューストリームのプロセスの中には、バリューストリームのリードタイムに比べて処理時間が長いものがありませんか?この答えをすでに知っていて、キャパシティと予想される処理時間のボトルネックを積極的に緩和するための手順を持っているかもしれません。もしそうでない場合は、データを入手して、これらのシステム的なボトルネックがバリューストリームを遅らせていないかどうかを確認してください。バリュー・ストリームの各プロセスの段階内時間は?各ステージの平均負荷はどれくらいで、それらの負荷に対応するためにどのようなリソースが使われていますか?幸いなことに、HCL Accelerateは、これらの質問に答えるためのデータだけでなく、容量/処理時間のボトルネックを可視化するためのツールへの自動監視とアラートも提供します。
単純なキャパシティ/処理時間のボトルネックを超えて、プラクティスの方法論によってもたらされるボトルネックに遭遇します。私たちは、グローバルなバリューストリーム効率への影響を考慮せずに、特定のタスクのローカル効率を最大化するために開発手法を選択することがよくあります。例えば、トランザクションのオーバーヘッドとコンテキストの切り替えコストを削減するための一般的なプラクティスの1つは、特定の付加価値の高い作業をバッチで処理することです。バッチ処理は、それが採用されている付加価値作業全体の効率を高めることができますが、下流への継続的な流れを阻害することで、バリューストリームの全体的な効率を低下させる可能性もあります。バッチングプロセスの下流のステージでは、使用率不足と過剰供給が交互に発生し、最適な効率で作業する能力が大幅に低下する可能性があります。なぜなら、ボトルネックは局所的に最適化された付加価値プロセスによって発生する可能性があるため、ボトルネックを発生させているステージのバリュー・ストリーム・メトリクスを見ると、すべてが素晴らしいものに見えるからです。けれども、各ステージのフローパターンと、そのパターンが下流プロセスにどのような影響を与えているかに注目する必要があります。時系列スループットの頻繁なスパイクや谷は、実践方法論によって導入されたボトルネックの主要な指標となります。HCL Accelerate は、すべてのバリューストリームのグローバルおよびローカルのスループットを追跡し、実践方法論がバリューストリームにボトルネックが発生している場合には、ユーザーにアラートを提供します。
次に検討するボトルネックのタイプは、ソフトウェア開発のバリューストリームの特徴的なボトルネックである、不均一な作業負荷のボトルネックです。ソフトウェアでは、すべての作業が同じように作成されるわけではありません。同じウィジェットを製造しているわけではなく、複雑で創造的な作業に従事しているのです。ソフトウェアの仕事には、仕事の複雑さ、開発リソースの要件、価値の流れへの流入に固有の不均一性があります。つまり、バリューストリームのキャパシティと処理時間が完璧にバランスが取れていて、すべての実践方法論がグローバルにもローカルにも最適化されていたとしても、ボトルネックが発生する可能性があり、また発生する可能性があるということです。システムを通る不均一な流れは、個々のステージで定期的にキューを発生させたり、他のステージの作業アイテムを枯渇させたりして、バリュー・ストリームのスループットを低下させます。幸いなことに、バリューストリームのステージ負荷とスループットのボトルネックを注意深く監視することで、不均一なワークロードによって発生するボトルネックを、バリューストリームに大きなコストが発生する前に検出し、緩和することができます。さらに HCL Accelerate は、何を監視すべきかを既に知っており、不均一なワークロードのボトルネックが発生し始めると、ユーザーを検出して警告することができます。
ボトルネックを修正するには
バリューストリームでボトルネックがどのようにしてどこで発生するかを知ることは、ボトルネック緩和の最も困難な部分です。ボトルネックが発見されず、バリューストリームの効率性を奪ってしまうことがあっては、ボトルネックは問題となりません。バリュー・ストリームとワークフローのメトリクスを手動で検査する日常的かつ体系的な方法、または HCL Accelerate が提供するような自動化されたモニターとアラート・システムのいずれかが、ボトルネックの脅威と戦うための最良の前線の武器となります。Once you’ve found the bottlenecks, you’ll likely find the tools for mitigating them are already in your software development toolkit. (訳不明瞭)。
処理時間が長いために、バリューストリームのステージがボトルネックになっていないか?プロセスを自動化または合理化できる部分があるかどうかを確認してください。
1つのステージでのバッチ処理が下流の流れを阻害していませんか?より小さく、より頻繁なバッチを検討するか、またはバッチングをすべて廃止することを検討します。
不均一な作業負荷がバリューストリームに大混乱をもたらしていませんか?チームのスキルセットに柔軟性を持たせることで、コストが発生する前にリソースを再配分してキューをクリアできるようにしましょう。
HCL Accelerate を持っているとがわかります。どこで、なぜ、いつボトルネックが発生するのかを。それを知ることで、効果的な効率性節約の緩和を実践することができます。HCL Accelerate の検出およびアラートシステムがボトルネックを発見することで、お客様のチームは、効率的で効果的な価値の流れの中でソフトウェアを開発することができるようになります。