2.7 待ち行列理論

概要と動機

待ち行列理論は、待ち行列の数学的研究です。ソフトウェアエンジニアリング指標についての本にとって奇妙な取り合わせのように聞こえますが、提供パイプラインのどれほど多くが実際には待ち行列であるかに気づくまでのことです。レビュー担当者を待つプルリクエスト、CIランナーを待つコミット、拾い上げられるのを待つチケット、応答を待つ顧客サポートのメッセージです。トピック2.4はすでにフロー負荷とフロータイムを紹介し、バリューストリームを過負荷にすると提供が急激に遅くなることを示しました。そしてトピック2.5とトピック2.6は、ほとんどの提供時間が作業時間ではなく待ち時間であることを示しました。待ち行列理論は、それがすべて単に観察されたパターンではなく、なぜ真実なのかを説明する根底にある数学です。

唯一最も有用な結果はリトルの法則であり、オペレーションズリサーチの研究者ジョン・リトルによって1961年に証明された定理です。安定したシステムにおけるアイテムの平均数は、アイテムが到着する平均の速さに、各アイテムがシステムに留まる平均時間を掛けたものに等しいというものです。トピック2.4はすでにこの結果をFlow Framework自身の呼び名のもとで使いました。フロー負荷は到着率にフロータイムを掛けたものに等しい、というものです。本書のより広い語彙では、これは仕掛かり作業(トピック2.5)が新しい仕事の到着率にサイクルタイム(トピック2.6)を掛けたものに等しい、とも読めます。これは経験則でもなければ、いくつかの研究で観察された相関でもありません。それは、待ち行列が何を処理しているか、次に何に取り組むかをどう決めているかにかかわらず、どんな安定した待ち行列にも成り立つ証明です。

大規模なチームにとって、その普遍性こそが要点です。リトルの法則は、待ち行列がカンバンボードであれ、メッセージブローカーであれ、共有CIパイプラインであれ、同じように機能する健全性チェックを与えてくれます。もしあなたの測定された仕掛かり作業、到着率、サイクルタイムがおおよそこの等式を満たさないなら、三つの数字のどれかが間違っています。たいていは「進行中」や「到着した」としてカウントされるものについての一貫性のない定義のせいです。企業や政府の組織は、共有コードレビュープール、共有テスト環境、共有承認委員会のような、そうした待ち行列を同時に数十運営しており、リトルの法則は、悪い指標の定義が悪い人員配置やプロセスの決定を駆動する前にそれを捉えるための、入手可能な最も安い道具です。

重要な原則

リトルの法則はヒューリスティックではなく証明である。 仕掛かり作業は、どんな安定した待ち行列についても、到着率にサイクルタイムを掛けたものに等しく、これはあなたの提供指標が内部的に一貫しているかどうかの迅速なチェックです。
使用率は待ち時間と線形には比例しない。 共有資源が完全な使用率に近づくにつれて、待ち行列の遅延は、緩やかにではなく急激に増加します。95%忙しい状態で動いている資源は、80%で動いているものよりも、単に「少し悪い」のではなく、何倍も長く待たされていることがよくあります。
待ち行列の平均はその最悪のケースを隠す。 平均待ち時間だけを報告することは、容量近くでの長く苦しい裾を隠します。これはまさに、平均の代わりにパーセンタイルを使うことについてトピック1.6が警告することです。
待ち行列がどう定義されるかは、他のどんな指標とも同じくらい簡単に操作されうる。 何かが「到着した」「進行中」「対応済み」としてカウントされるかどうかは選択であり、仕事に実際に何が起きているかを変えることなく、ダッシュボードをより良く見せるように調整できます。
パイプラインは通常、待ち行列の待ち行列である。 提供パイプラインはいくつかの段階を連鎖させており、他がどれだけ速く動いているかにかかわらず、最も遅い段階が連鎖全体のペースを決めます。

推奨事項

自分の数字を信頼する前にリトルの法則で確認する

あなたのチームの測定された平均仕掛かり作業、週あたりの新しいアイテムの平均到着率、そして平均サイクルタイムを取り、仕掛かり作業が到着率にサイクルタイムを掛けたものとおおよそ等しいかを確認してください。そうでないとき、理論が間違っていると想定しないでください。実際の原因を探してください。一貫性なくカウントされた段階の境界、「ブロックされている」が今も進行中としてカウントされている仕事、あるいはサイクルタイムとは異なる窓で測定された到着率などです。この単一のチェックは、ほとんどのチームが他のどんな方法でも見つけられないよりも多くの悪い計測基盤を捉えます。

すべての共有された容量制約のある資源について使用率を直接追跡する

あなたの提供パイプラインが多くのチームにわたって共有する資源、コードレビュープール、CIクラスタ、ステージング環境を特定し、それを限界近くで運用する計画を立てる前に、それぞれが利用可能な容量に対してどれだけ忙しく動いているかを割合として測定してください。ほぼフル容量で動いている共有のレビュー担当者グループは、それを引き起こした控えめな需要の増加よりもはるかに速く成長するレビューキューの待ち時間を生み出します。これはまさに、トピック2.9が最初のレビューまでの時間を先行指標として監視するよう助言する力学です。

到着率、成功率、失敗率、スキップ率を分離する

待ち行列を離れるすべてを単一の「スループット」や「サービス率」の数字に潰すことに抵抗してください。四つのことを別々に追跡してください。仕事がどれだけ速く到着するか、そのうちどれだけが成功して完了するか、どれだけが失敗して手戻りが必要になるか、そしてどれだけが誰かが完了させる前に放棄されるか静かに落とされるかです。スキップ率が静かに上昇したために速く見えるパイプラインは、実際にはより多くを届けているわけではなく、これら四つの割合を別々に追跡することだけが、あなたにそれを示してくれます。

複数段階のパイプラインを待ち行列の待ち行列としてモデル化する

提供パイプライン、あるいはインシデントのライフサイクルや採用パイプラインのような多段階のプロセスを、未分化な「時間」の塊一つとしてではなく、待ち行列の連鎖として扱ってください。全体の到着率は最初の段階によって設定され、全体の完了率は最後の段階によって設定され、パイプラインの総エラー数とスキップ数は各段階のそれの合計です。この枠組みは、たまたま計装が最も簡単な段階ではなく、高い使用率と高い失敗率やスキップ率の最悪の組み合わせを持つ段階、どの段階に投資する価値があるかを即座に教えてくれます。

スループットだけでなく使用率を念頭に置いて人員配置とWIP制限を設定する

あるチームが何人のレビュー担当者やCIランナーを必要とするかを決めるとき、容量を平均到着率に正確に合わせて規模設定しないでください。平均で100%の使用率で動いている待ち行列は、実際の到着が完全に滑らかではなく不均一であるため、実際には事実上無限の待ち時間を持ちます。意図的に余裕を計画し、「私たちのレビュー担当者はほとんど常に忙しい」を、効率的な資源配分の証拠としてではなく、来るべき待ち時間についての警告の兆候として扱ってください。

トレードオフ:長所と短所

アプローチ	長所	短所
正式な待ち行列モデルなし、直感による人員配置	始めるのが速い。チームにとって新しい語彙が不要	フル容量近くで待ち時間がどう爆発的に増えるかを一貫して過小評価する
既存の指標の健全性チェックとしてのリトルの法則	安く、新しいツールが不要、悪い定義を速く捉える	一貫性を確認するだけで、それ自体では原因を診断しない
完全な待ち行列シミュレーション(到着分布、複数のサーバー)	負荷のもとでの待ち時間の振る舞いの最も正確な予測	本物の統計的スキルと、ほとんどのチームが維持できない保守が必要
より深いモデリングなしの共有資源の使用率追跡	単純で行動可能、暴走する待ち時間の唯一最大の原因を捉える	なぜ使用率が高いのか、根底にある原因について何をすべきかについては何も語らない

中心にある緊張関係は厳密さと採用です。完全な待ち行列シミュレーションは最も正確な答えを与えますが、ほとんどのエンジニアリングチームはそれを構築し維持することはありません。誰も信頼せず更新しないモデルは、モデルがないよりも悪いものです。リトルの法則と基本的な使用率の追跡は、いくらかの精度を犠牲にしますが、専門的な統計スキルを必要とせず、チームがすでにトピック2.4からトピック2.6のために収集している指標に直接当てはまります。それらの安く採用しやすいチェックを既定とし、完全なシミュレーションは、単一の共有資源(大規模なCIフリート、専門化されたレビュープールなど)が投資を正当化できるほど高くつく稀なケースのためにとっておいてください。

チームで話し合うべき問い

私たちの測定された仕掛かり作業、到着率、サイクルタイムは実際にリトルの法則を満たしているでしょうか。もし満たしていないなら、なぜでしょうか。これは、悪い指標の定義にとって入手可能な唯一最速の診断です。実際の数字を一緒にたどってみて、もし等式がおおよそ成り立たないなら、そのチェックを退けるのではなく、不一致を特定の定義上の矛盾までたどってください。
私たちの提供パイプラインの中で、どの共有資源がフル使用率に近い状態で動いており、私たちはその使用率の数字を実際に知っているでしょうか。ほとんどのチームは「いつも忙しく感じられる」資源を名指しできますが、その使用率を直接測定したことがありません。最も制約の大きい二つか三つの共有資源を特定し、それぞれについて実際の数字を得てください。
私たちは成功、失敗、スキップを単一のスループットの数字に混ぜ合わせているでしょうか。そしてそれらを分けたら何が見えるでしょうか。 単一の「完了したアイテム」の件数は、品質が下がっていたり仕事が静かに放棄されていたりしても上昇することがあります。直近の期間のスループットを三つの別々の数字として再計算し、その分割が混ぜ合わせられた数字が隠していた何を明らかにするかを話し合ってください。
私たちのパイプラインのどこに本当のボトルネック、つまりそれより下流のすべてにとってペースを決める最も遅い段階があるでしょうか。 チームはしばしば、実際に総スループットを制約している段階ではなく、改善が最も簡単な段階に投資します。高い使用率と高い失敗率やスキップ率の最悪の組み合わせを持つ段階を特定してください。
もし私たちが最も制約の大きい共有資源に容量を追加したら、待ち時間は実際に改善するでしょうか、それとも需要が単に拡大してそれを埋めてしまうでしょうか。この問いは、本物の容量不足を需要の問題から切り分けます。そしてその答えは、正しい修正がより多くの人員なのか、WIP制限なのか、あるいは仕事が待ち行列に入る前にどう優先順位づけられるかの変更なのかを変えます。
私たちは、仕事に実際に起きたことを変えることなくダッシュボードをより良く見せる形で、何が「進行中」や「到着した」としてカウントされるかを再定義したことがあるでしょうか。これは、仮説的な懸念として扱うのではなく、昨年からの実例を伴って、正直かつ具体的に問う価値があります。

業種別の視点

スタートアップ。 一握りのエンジニアであれば、ほとんどの待ち行列は、正式な待ち行列分析が過剰であるほど短いものです。役立つ習慣はより小さなものです。一人の人物、しばしば最も上級のエンジニアが、他のすべてがそれを待つ事実上の共有資源になったことに気づき、それを、背後に正式なモデルがなくても名指しする価値のある使用率の問題として扱ってください。

中小企業。 中小企業のチームは、めったに、自分たちの一つか二つの本当に共有された資源、しばしば単一のレビュー担当者や単一のデプロイパイプラインの使用率を追跡すること以上の洗練さを必要とせず、「通常利用可能」が静かに「通常ボトルネック」になる地点に注意を払うだけです。スプレッドシートで十分であり、専用のツールはこの規模では必要ありません。

企業。 共有資源は企業規模で急速に増殖します。中央のプラットフォームチーム、共有のセキュリティレビュー委員会、数十の製品チームにサービスを提供する共有CIフリートです。これらはまさに使用率の追跡がその価値を発揮する資源です。なぜなら、単一の過負荷の共有資源は、それに依存するすべてのチームの提供時間を静かに悪化させることがあり、どの個々のチーム自身の指標も、自分自身のパイプラインの外にある原因を明らかにしないからです。

政府。 複数機関・複数ベンダーの提供プログラムは、単一のチームが統制も規模調整もできない共有承認委員会、共有セキュリティ認定プロセス、共有テスト環境を通じて仕事をしばしばルーティングします。これらの共有されたゲートの待ち行列分析、つまり到着率、容量、使用率は、容量を追加するか、ゲートに到達する前に仕事がどうまとめられるかを変えるためのビジネスケースにとって、しばしば入手可能な最も明確な証拠です。

事例

企業。 あるクラウドインフラストラクチャプロバイダの内部プラットフォームチームは、どの個々のチームも自分たちの働き方を変えていないにもかかわらず、共有CIフリートに依存するすべての製品チームにわたって変更のリードタイム(トピック2.10)が忍び寄るように増えていることに気づきました。使用率の分析は、コアとなる時間帯にこのフリートが90%を超えて忙しく動いていることを発見しました。これは、待ち行列理論が待ち時間が緩やかにではなく急激に増加すると予測する地点をはるかに超えています。このプラットフォームチームはCIの容量を追加し、単一のチームの活動のバーストが待ち行列を独占できないように、公平な配分のスケジューリング方針を導入しました。中央値のCI待ち時間は1か月以内に半分以上減少し、ボトルネックがずっと共有された見えない待ち行列だったという証拠となりました。

政府。 ある国家許認可機関のデジタルサービスチームは、申請処理を2年間「週あたりクローズされたケース」という単一のスループットの数字として追跡しており、その数字は安定して見えました。その数字を、承認されたケース、却下されたケース、そして長い遅延の後に申請者によって放棄されたケースに分割した、より詳しい分析は、同じ期間に承認が横ばいのままだった一方で、放棄率がほぼ3倍になっていたことを発見しました。ケースワーカーの待ち行列に適用されたリトルの法則は、仕掛かり作業がチームの述べられた平均処理時間が示唆するよりもはるかに成長していたことを示し、これは、「待機中」としてカウントされていないステータスの中でケースが静かに積み上がっていたことを意味していました。この機関は、すべての未解決のケースを正直にカウントするようにケース追跡の定義を再構築し、使用率を85%未満に保つよう規模調整されたケースワーカーの容量を追加し、現在はそれをスループットの数字と並んで常設の運用目標として追跡しています。

ビジネスケース:動機、ROI、総所有コスト

基本的な待ち行列分析を適用することからの見返りは、「パイプラインが遅く感じられる」を、実際の原因を見逃す「もっと速く働け」という漠然とした圧力ではなく、具体的で擁護可能な決定(この共有資源に余裕を追加する、この混ぜ合わせられた指標をその本物の構成要素に分割する)に変えることです。上記のクラウドインフラストラクチャの例、個々のチームの行動への変更ではなく容量とスケジューリングの修正から待ち時間を半分にしたことは、この分析が確実に生み出すパターンです。修正は、見えないボトルネックの周りで下流のすべてのチームにもっと速く動くよう求めるよりも、ほぼ常に安く済みます。

採用の総コストは本当に低いものです。リトルの法則と使用率の追跡は、トピック2.4からトピック2.6がすでに収集を求めている到着率、仕掛かり作業、サイクルタイム以上の新しいツールを必要としません。投資はほとんどが分析の規律です。数字を互いに照らし合わせて確認し、共有資源の使用率が組織の次の説明のつかないリードタイムの悪化になる前に定期的にレビューすることです。

アンチパターンと落とし穴

共有資源の容量を平均到着率に正確に合わせて規模設定する。 需要がほんの少しでも不均一になるたびに、高い使用率と暴走する待ち時間を保証します。
平均待ち時間だけを報告し、パーセンタイルを一度も報告しない。 その中で待っている人々にとって最も重要な長い裾を隠します。
成功、失敗、スキップを単一のスループットの数字に混ぜ合わせる。 本トピックの中心にある操作のベクトルです。プレッシャーのもとにあるチームは、スキップ率、つまり放棄されたチケット、静かに落とされたリクエスト、失敗としてカウントされることのない仕事を静かに上昇させることで、スループットを健全に見せることができます。ガードレールは、本書のあらゆるメトリクスについてトピック1.2が求めるのと同じ規律で、到着率、成功率、失敗率、スキップ率を四つの別々の見える数字として追跡することです。そうすれば、上昇するスキップ率が横ばいのスループットのグラフの背後に隠れることができません。
「私たちの人々はいつも忙しい」を褒め言葉として扱う。 それは高い使用率の症状であり、長く予測不可能な待ち時間の主な原因です。
「進行中」を再定義して仕掛かり作業を静かに縮小させる。 完了にかかる時間を変えることなく、仕事を「ブロックされている」「保留中」のようなカウントされない状態へと移動させ、本来それを捉えていたはずのリトルの法則のチェックを壊します。
待ち行列モデルは一度構築すれば保守が不要だと想定する。 到着のパターンと容量は絶えず変化し、古びたモデルは自信を持って間違った予測を生み出します。

成熟度モデル

レベル1、開始: どの待ち行列も明示的には測定されておらず、待ち時間は「物事が遅く感じられる」という逸話として議論されます。
レベル2、発展: 到着率、仕掛かり作業、サイクルタイムは少なくとも一つのパイプラインについて追跡されていますが、リトルの法則や共有資源の使用率と照らし合わせて確認されたことはありません。
レベル3、標準化: リトルの法則は提供パイプラインを横断した日常的な一貫性チェックであり、使用率は最も重要な共有資源について明示的に追跡されています。
レベル4、管理: 成功率、失敗率、スキップ率はすべての重要な待ち行列について別々に追跡され、容量の決定は平均需要だけでなく使用率の目標を使います。
レベル5、最適化: 組織は主要なパイプラインを待ち行列の待ち行列としてモデル化し、本当のボトルネックを体系的に特定し、待ち行列分析のために行われた具体的な容量やプロセスの変更を、それによって測定された待ち時間の改善とともに指し示すことができます。

議論のためのアイデア

私たちの提供パイプラインの一つを選び、その数字が今日リトルの法則を満たしているかを確認してみてください。
私たちの組織でほとんどの人が「いつも忙しい」と同意するであろう単一の共有資源を名指しし、その実際の使用率の数字を見つけてください。
もし前四半期のスループットのグラフを成功率、失敗率、スキップ率に分割したら、どう見えるでしょうか。
もし今年、正確に一つの共有資源に容量を追加しなければならないなら、どれで、それを正当化する証拠は何でしょうか。

主な要点

リトルの法則、つまり仕掛かり作業は到着率にサイクルタイムを掛けたものに等しいという法則は、ヒューリスティックではなく証明であり、あなたの提供指標が内部的に一貫しているかどうかについて入手可能な最も安いチェックです。
使用率がフル容量に近づくにつれて、待ち時間は緩やかにではなく急激に増加します。 「いつも忙しい」を褒め言葉ではなく警告の兆候として扱ってください。
到着率、成功率、失敗率、スキップ率を別々に追跡してください。それらを単一のスループットの数字に混ぜ合わせることが、本トピックの中心的な操作のベクトルです。
多段階のパイプラインを待ち行列の待ち行列としてモデル化し、改善が最も簡単な段階ではなく、高い使用率と高い失敗率やスキップ率の最悪の組み合わせを持つ段階に投資してください。
ほとんどのチームが維持できない完全な待ち行列シミュレーションよりも、安く採用しやすいチェック、リトルの法則と使用率の追跡を優先してください。

参考文献とさらなる読書

Little, John D. C. “A Proof for the Queuing Formula: L = λW.” Operations Research, 1961。
Kleinrock, Leonard. Queueing Systems, Volume 1: Theory. Wiley-Interscience, 1975。
Wescott, Bob. The Every Computer Performance Book: How to Avoid and Solve Performance Problems on the Computer Systems You Work With. CreateSpace Independent Publishing Platform, 2013。
Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009。
Vacanti, Daniel S. Actionable Agile Metrics for Predictability. Actionable Agile Press, 2015。