ソフトウエア開発や継続的改善を管理するシンプルで効率的な方法として、カンバンにますます関心が集まっています。しかし、カンバンとはどのように動作するのでしょう。カンバンはシステムを明らかにし、要求を見える形で追跡できるのか。作業中のタスクを制限し、タスクの切り替え労力を削減できるのか。頻繁なフィードバックによって、マネージャにサイクル時間やスループットのようなシンプルな物差しを提供するか。この記事では、待ち行列理論とリトルの法則1を使って、カンバンを深く掘り下げます。また、ケーススタディを通じて、カンバンを実践した時にマネージャが直面する3つの問題とその解決策を説明します。これによって、カンバンの基本的な概念と示唆に富んだアイディアを明らかにできるでしょう。
ソフトウエア開発におけるリトルの法則
リトルの法則(John Little氏の名前に由来する)はカンバンが依拠するアイディアのひとつです。ソフトウエア開発の世界では、次のような式で表現されます。
WIP = Th * CT
WIP (Work In Process)は、開発中のシステムの完了していないアイテム(バグ、ユーザストーリー、変更要求)です。
Th (Throughput)は、単位時間当たりのチームのアウトプットです。
CT (Cycle Time)は、アイテムを完了させるのにチームが必要とする平均時間です。
リトルの法則の力学はすばらしいものです。ソフトウエア開発の複雑な状態を説明し、解決策をもたらしてくれます。次のケーススタディを分析するために、Diagrams of Effects2を活用します。この図は、非線形のシステムやふたつ以上の効果や影響がシステムの振る舞いに影響を与える場合を分析するのに優れた効果を発揮します。
ケース1: チームのスループットを増大する
Adamはふたりの開発者とひとりのテスターで構成するチームのコーチで、企業の幅広い製品のメンテナンスに責任を持っています。この企業は2013年に製品のマーケティングに投資を行い、なんとか顧客を2倍に増やしました。今、Adamのチームの受けるサポートリクエストは増大しています。しかし、CEOはチームのサイズを大きくするつもりはありません。
この場合、増大する顧客のリクエストに答えるには、チームはスループットを増やさなければなりません。リトルの法則によれば(Th = WIP / CT)、スループットを増加させるには、サイクル時間を削減するか、WIPを増やすかのどちらかです。チームはサイクルタイムを減らせません。キャパシティが固定だからです。したがって、WIPを増やすのが簡単な解決策です。
ここで問題です。WIPを増やせば、本当にスループットが向上するのでしょうか。答えは、Noです。大きなWIPは、スループットを増やしますが、一定の上限までで、その後は、次のグラフの通り、低下してしまいます。
図 1. スループットとWIPの関係
次のグラフで説明するように、WIPの増加はチームが仕事を最適化するように刺激し、最大のスループットに達するまで、デリバリプロセス(黄色い領域)での無駄を削減します。その後、WIPが増えても更なる改善は見込めません。反対に、スループットを低下させます。ストレスとタスクのスイッチング(赤い領域)が原因です。
図 2. チームはWIPが増えるに従い、対応していく。
赤い領域では、チームは外的要因に圧倒されており、生産性の低下を生み出す内部の問題を経験します。次のDiagrams of Effectsでは、赤い領域でのチームの力学を分析しています。
図 3. チームの能力を超えるWIPがチームの生産性とスループットを低下させる。
この図はチームの能力を超えたWIPの増加の影響を示しています。顧客とのやり取りを増やし、タスクのスイッチを増やし、ストレスを増やします。ストレスの下で働くこととタスクのスイッチを行うことによって、バグが増加し、生産性が低下し、スループットが低下します。
この決定の影響をつかむに、次の図ではこの影響が強化される様子をモデルにしています。増えるWIPが生産性を低下させ、それによって、要求が積み上がり、さらにWIPが増加するのです。このサイクルはループしており、スループットも低下し続けます。
図 4. チームの能力を超えるWIPがふたつの強化ループを生む。この力学では、開発チームが壊れるまでWIPは増え続ける。
注記: ふたつの連続するネガティブな影響がポジティブな影響になってしまう。
要約すれば、能力が固定で、スループットを増加させたいなら、チームのサイズとWIPの両方を大きくさせなければならないということです。これができないのなら、残された選択肢はひとつだけ。サイクル時間を短くすることです。無駄を見つけ、削減することです。
ケース2: サイクル時間を安定化させる
Ismailは開発マネージャで、Service Level Agreement (SLA)で定義された時間制限内に顧客からの変更要求を実現することにコミットしています。Ismailと彼のチームが受け取る顧客要求の量は変動します。いつもより多い場合は、SLAを超えるサイクル時間になってしまいます。逆にまったく能力を消費しない場合もあります。次の図はサイクル時間がインプット量に応じて増える様子を表しています。
図 5. 高いインプット量が大きなサイクル時間を生む。また、低いインプット量は小さなサイクル時間を生む。
リトルの法則の示唆によれば、サイクル時間はWIPと比例し、スループットと反比例します。従って、Ismailはこのふたつのパラメータを安定させれば、サイクルタイムも安定するはずです。
ふたつのパラメータを安定させるには、IsmailはWIPとチームの能力(チームメンバの数や顧客の要求に専念するチームの時間の割合)の両方を制御して、インプットの量に対処する必要があります。このふたつはサイクル時間に2重に影響を与えます。WIPを増やせば、サイクル時間が笛、チームの能力を増やせばサイクル時間が減ります。つまり、双方の効果が相殺されるのです。
図 6 マネージャがWIPとチームの能力を増やす/減らすとサイクル時間が安定し、チームのパフォーマンスが最適化される。
つまり、要約すれば、チームが変動するインプットの量を経験しているのなら、ふたつのポラメータを制御する必要があるということです。ふたつのパラメータを制御することで、チームはサイクル時間を安定させ、チームの力を最大化できます。
ケース3 – 手早く片付けすぎない!
仕事を手早く片付ける(カンバンボードの優先レーンを使う)のは、繰り返し作成しなければならないトラブルの報告書、問題含みのサービス要求に対処するには良い方法かもしれません。多くの場合、特別な問題から解放され、声の大きな顧客の不平に対処するためにルールなしで手早く片付けるのは魅力的です。
しかし、そのようなやり方はチームの時間と労力を奪います。開発は遅くなり、サイクル時間の平均値は増加します。リトルの法則によれば、これによってチームのスループットも低減します。
図 7. リトルの法則の通り、WIPが変わらなければ、サイクル時間が増えれば、スループットは小さくなる。
実際には、サイクル時間とスループットの線形の関係が次のように変わります。
図 8. スループットが劇的に下がる。要因は、サイクル時間の増加と、スループットとサイクル時間の関係を定義するグラフの移動。
より極端な例では、チームは優先レーンのタスクへスイッチし、要求が来たらすぐ対応し、今まで手がけていたタスクをほったらかしにします。簡単に文脈を切り替えてしまうこともスループットに悪影響を及ぼします。次の図はこの影響を示しています。
図 9. 手早く片付けようとしたアイテムは現在対応中のアイテムのサイクル時間を引き上げ、スループットに悪い影響を与える。
このケースを要約すれば、優先レーンの罠に気をつけろ、ということです。チーム全体の生産性に悪い影響を与えるからです。さらにサイクル時間も低下します。小さな緊急事態に対しては有効かもしれませんが、意図しない悪影響を呼び込んでしまう可能性が高いです。
結論
上述した3つのケースを通じて、カンバンの動作について、待ち行列理論を使って説明しました。カンバンはとてもシンプルでとても効率的なマネジメントツールです。マネージャとして、または、チームリーダーとして、制御するべきパラメータはいくつかあります。WIP 、チームの能力です。また、サイクル時間やスループットのような簡単に計測し、頻繁にフィードバックできるプロセスメトリクスもあります。カンバンを使う場合の基本的な問題をまとめると次の3つになります。
- チームの能力を明らかにし、能力を上回る量のタスクを追加して、チームを圧倒しないようにする。WIPとスループットの関係をプロットすると、どの程度のWIPにチームが耐えられるのかの指標にできるだろう。
- 開発プロセスを安定させるために一つ以上のパラメータを制御する。ふたつ目のケースのように、WIPとチームの能力を制御することで、安定したサイクル時間になる。
- 優先レーンの罠に気をつける。この罠はプロセス違反のためのバックドアだ。注意しないとチームの生産性が崩れる。
1リトルの法則:
Massachusetts Institute of Technologyから出版された書籍では、John Little氏はこの法則を説明し、理論と実践の橋渡しをしている。この説明は、わかりやすく、かつ、リトルの法則の確信に迫っている。
この書籍で説明されている問題のひとつはリトルの法則のオリジナルの公式(到着率を公式のパラメータとする)と製造システムへの適用(到着率をスループットに置き換える)の違いだ。次のような説明をしている。
リトルの法則は次のように定義している。
L = λ W
L = 待ち行列内にあるアイテムの平均数
λ = 新しいアイテムのシステムへの到着率
W = システム内のアイテムの平均待ち時間
John Littleによればこの法則は強靭であり、包括的であり、次の中核的な条件を満たすどのような待ち行列にも適用できる。すなわち、"[行列が空のときに]動きだし、行列が空になったときに止まる有限の観察枠を持っている"(p.88)
お気づきの通り、この公式はこの記事で説明したものとは違う。実際、オリジナルのリトルの法則とソフトウエア開発の文脈(WIP = Th*CT)でのリトルの法則にはふたつの基本的な違いがある。オリジナルの法則はインプットと到着率について説明している。一方、ソフトウエア開発の現場でのリトルの法則ではアウトプット率とスループットについて説明している。Littleが説明するふたつ目の違いは、条件についてだ。つまり、システムはアイテムが0の状態で始まり、0の状態で終わる。しかし、ソフトウエアの世界では要求が0の状態のシステムはほとんどない。
これらの違いを解決するため、Littleが示しているのは、この法則に微妙な条件を付け加えることだ。すなわち、システムにアイテムが追加されず、アイテムは消滅しないし、終了もしない、という条件だ。Littleはこれを“フローの維持”(p. 93)と読んでいる。この条件をシステムに適用すれば、インプット率とアウトプット率が同じであること、それゆえ、ラムダ(λ)とスループット(th)を関連付けることができる。
ふたつ目の条件(システムはアイテムが0のときに開始、終了する)については、Littleによれば、この法則は“少なくとも近似的には、十分な時間間隔を選択できれば、適用することができる”(p. 93)
Diagrams of Effectsが初めて紹介されたのは、Gerald Weinberg氏のQuality Software Managementシリーズ。この図は非線形な振る舞いをするシステムの力学を理解するのにとても役に立つ。ソフトウエア開発チームはそのような複雑なシステムによく似ている。
Diagrams of EffectsはCausal Loop Diagrams (CLD)に似ているが、表記が微妙に違い、また、システム内での人間の介入をモデル化するにはDiagrams of Effectsのほうが優れている。この図のはノードと矢印 で構成されている。各ノードは計測できる量に対応している。各矢印は矢印の元になっているノードが先になっているノードに与えた効果(ポジティブであれネガティブであれ)に対応する。書き方はこちらを参照。
著者について
Amr Noaman Abdel-Hamidはアジャイルコーチであり、トレーナー。エジプトと中東でアジャイルとリーン思考を広めることをライブビジョンにしている。Agile Academyを設立し、チームや組織が最大限のポテンシャルでソフトウエアを提供できるように支援している。エジプトのLean & Agile Networkの設立メンバのひとりであり、エジプトのGoAgileプログラムの発案者。このプログラムはエジプト政府がスポンサーのアジャイルを広めるための運動だ。それ以降、400人以上を指導し、多くのチームをコーチした。また、いくつかの産業報告書の著述なども行っている。ブログTales of Agile Software Developmentでは自身の考えを共有している。メール、Linked-in、ツイッター@amrnoamanでコンタクトが取れる。