LeSSの原理原則：待ち行列理論 と組織構造
Craig Larmanの研修を受けて、LeSSの原理原則のうちの１つである、「待ち行列理論」がとてつもなく大切なものだったと気づき、LeSSの以下のページを日本語化しました。現時点では反映されていませんが、数日後には日本語で見れるはずです。
上記ページの要約になります。
待ち行列理論の視点から、なぜ従来の開発が遅くなりがちなのか、そしてどのように改善できるのかを説明しています。特に、大規模開発においては「大きなバッチ」「高いリソース利用率」「可視化されていない待ち行列」がサイクルタイムを長引かせる主な要因となることを解説しています。
主要なポイント
待ち行列の非線形な影響
大きなバッチ（例：「1つの」巨大な要件）は、実は複数の小さな要件の集まり（隠れたバッチ）であり、待ち行列を増やし、サイクルタイムを非線形に悪化させる。
直感的には「10倍の作業なら10倍の時間がかかる」と思いがちだが、実際にはさらに遅くなる。
高い稼働率の罠
リソースを100%活用しようとすると、待ち行列が発生し、かえってスループットが低下する。
60%程度の負荷からサイクルタイムが急増し始める。
待ち行列を「見抜く目」の重要性
開発では物理的な在庫と異なり、待ち行列が見えにくい（例：未完了の仕様書、テスト待ちのコード、未統合の開発成果）。
可視化（Visual Management）を活用し、隠れた待ち行列を認識し、削減する。
サイクルタイム短縮の間接的なメリット
「湖と岩」のメタファー：サイクルタイムやバッチサイズを小さくすると、隠れていた問題（岩）が顕在化し、改善のきっかけになる。
LeSSでの待ち行列管理
プランA（理想）：システムそのものを変え、待ち行列を根本的に排除する（例：フィーチャーチーム、ATDD、継続的デプロイ）。
プランB（妥協策）：待ち行列を制限し、バッチサイズを小さくし、優先順位を明確にする（例：WIP制限、定期的なバックログリファインメント）。
結論
LeSSでは、単に待ち行列を管理するのではなく、そもそも待ち行列を発生させない組織設計を目指すべき。待ち行列を適切に扱うことで、サイクルタイムを短縮し、開発のフローを改善できる。
プロダクトバックログ自体がそもそも待ち行列を発生させるものである、という示唆はそのとおりだと思いました。最低限の待ち行列は必要になります。