Slack（スラック）

タイムボックス化されたイテレーションにおける一般的なアプローチは、関係するスタッフの稼働率を最大化するために、各イテレーションにできるだけ多くのユーザーストーリーを割り当てることです。スラックとは、ストーリーに割り当てられていない時間を意図的に残し、その時間 unplanned work（計画外作業）に充てるポリシーです。これは非効率的に見えるかもしれませんが、通常、チームの生産性を大幅に向上させます。

計画にスラックを導入する良い方法は、計画に内在する不確実性に対処するために使用することです。イテレーションあたり平均20個のストーリーを完了するチームは、毎回正確にその数を完了するわけではありません。代わりに、15から22までのような範囲が見られます。このような状況では、チームは一貫して達成可能な最低数（15）で計画を立て、追加の時間をスラックとして扱うことができます。

このアプローチの利点の1つは、ストーリー完了のばらつきが軽減されることです。20個のストーリー割り当ての最後の5個を今回のイテレーションで完了できるかどうかを心配するのではなく、高い確度で15個を完了できると期待できます。計画と調整においては、高い確度はスループットの最大化を試みることよりも価値がある場合が多いです。

スラックは怠惰につながると懸念する人がよくいますが、そのスラック時間を生産的に活用する方法はたくさんあります。最も明白なのは、追加のストーリーにコミットメントされていないボーナスとして取り組むことです。これは、低いコミットメント率の予測可能性には影響しませんが、可能な限り多くのことを成し遂げることができます。

しかし、より多くのストーリーを実行することが、常に最も生産的なことであるとは限りません。ほとんどのチームは、作業環境の要因によって速度が低下しています。ビルドプロセスの非効率性、コードベースの不要な部分、生産性ツールに慣れていないことなどがあるかもしれません（ほとんどの人はIDEに undiscovered gems（隠れた宝石）をたくさん持っています）。スラック時間をこれらに費やすことで、将来のインタラクションの生産性を向上させ、大きな違いを生むことができます。実際、チームが直面する最も一般的な生産性の問題は、これらの impediments（障害）が悪化するのを許してしまう、 congested schedule（過密なスケジュール）が原因です。

スラックのもう1つの良い使い方は、顧客とのコラボレーションを強化する活動です。真の生産性に対する最大の impediment（障害）は、顧客とユーザーの仕事をどのように改善するのが最善かを本当に理解していない開発チームであることがよくあります。ユーザーの仕事を半日 shadowing（観察）するだけでも、ユーザーについて詳しく学ぶことで、機能の価値を大幅に高めることができます。

スラックは、緊急の要求に対応するチームの能力を向上させます。多くの場合、チームは協力する必要があります。たとえば、別のチームの機能のためにAPIを拡張するなどです。スラックがないと、そのような作業は計画にスケジュールする必要があり、遅延と他のチームのサイクルタイムが増加します。小さなタスクはスラックで処理でき、わずかな儀式で迅速に完了できます。高い稼働率はレイテンシを増加させることを忘れないでください。

ここではタイムボックス化されたイテレーションの観点からスラックについて説明しましたが、継続的フローにも重要です。ここでの smell（兆候）は、継続的フローチームが常に忙しい場合です。これはスラックが不足していることを示しており、要求への対応が遅くなり、作業環境のケアができなくなります。

スラックは重要であり、しばしば過小評価されていますが、メインディッシュではなく調味料です。すべてがスラックのスケジュールは、可視性と長期計画を諦めることになります。しかし、それなしで実行するのは、オイル交換を怠るようなものです。