プログラマの思索

ヘンリック著「リーン開発の現場」において、サイクルタイムという重要なメトリクスが出てくる。
理解できていることをラフなメモ書き。
間違っていたら後で直す。

【参考】
数学トレーニング講座

待ち行列（１）

- サルでもわかる待ち行列

リトルの法則 - Wikipedia

リトルの法則 - Elegant Cat Wiki

待ち行列の計算

【1】待ち行列理論は情報処理技術者試験でも良く出てくる。

その中でリトルの法則は、リトルの法則 - Wikipediaの通り。

【リトルの法則】L_q=λW_q

L_q：待ち行列内に滞在している平均客数
λ：平均到着率
W_q：待ち行列内の平均待ち時間(つまり、客が待ち行列に到着して最後尾に並びはじめてから、サービスを受け始めるまでの時間)

リトルの法則の使い道は、リトルの法則 - Elegant Cat Wikiに書かれている。

「1時間に20人のお客さんが来て，平均30分間滞在していたら，店の中には1時間あたり平均10人のお客さんがいる」

「例えば，日本の人口流動では、日本人の平均寿命はだいたい80年、日本の総人口は1億2千万人くらいとすれば、年間あたり150万人が出入り(出生・死亡)している」

「例えば，大学への入学者数では、学生数1万人，平均4年滞在だと，年間2,500人ほど入ってくる計算になる」

リトルの法則を使えば、病院や人気のレストランや遊園地のアトラクション、ATMの待ち時間を簡単に計算できる。

リトルの法則の注意点としては、以下の通り。

・系が安定していて割り込みがないのが前提
・対象がどのような確率分布であってもこの振る舞いをする
　(つまり、M/M/1モデルだけでなく、サービス窓口が2個以上でも同じ)
・客が待ち行列に到着する割合(平均到着率：λ)は待ち行列を出る割合、サービスが完了する割合(サービス利用率：μ)が同じと想定する

【2】サイクルタイム、Velocity

「リーン開発の現場」によれば、かんばん上で採取するメトリクスとして、Velocityとサイクルタイムを計測している。
Velocityは、1週間に開発した機能の数。
具体的には、1週間で受入テスト準備OKフェーズに移動された機能カードの数。
Scrumでも出てくるおなじみのメトリクス。

サイクルタイムは、1機能の開発にかかった時間。
具体的には、開始日(次の10機能フェーズから開発中フェーズに移動された日)から終了日(システムテスト中フェーズから受入テスト準備OKフェーズへ移動された日)までの時間。

Velocityもサイクルタイムも、かんばん上では計算しやすい。
Veclocityは1週間後に、受入テスト準備OKに入ったカードを数えればよい。
サイクルタイムは、カードごとに、開始日と終了日の差を計算すればよい。

では、なぜ、Veclocityとサイクルタイムが重要なのか？
Veclocityは開発チームの生産能力そのものに相当する。
値が大きいほど、開発チームは数多くの機能を開発完了できることを意味している。
実際は、プロジェクトが安定すると、Velocityの値も増えていくが緩やかに一定の値で安定するときが多い。

「リーン開発の現場」では、Velocityの計算ではストーリーポイントを使わない。
その理由が12.2節「ストーリーポイントを使わない理由」に書かれている。
僕の理解では、機能カードの粒度が一定ならば、機能カードをポイント付けする必要がない、とヘンリックは決めているようだ。

サイクルタイムは、機能が開発完了するまでの開発時間を意味している。
値が小さいほど、開発時間が短いので、頻繁にリリースできることを意味している。
「リーン開発の現場」では、サイクルタイムは、実際の作業日数よりも5～10倍に長くなるらしい。
つまり、サイクルタイムには、作業待ち時間がかなりの割合を占めていて、リリースできるまでに相当な時間と労力を費やしているわけだ。

「リーン開発の現場」では、サイクルタイムを機能ごとの管理図でグラフ化し、ある機能が開発完了するまでの時間を予測するのに使っているようだ。

また、「リーン開発の現場」によれば、機能の開発規模とサイクルタイムに相関関係はないらしい。
つまり、機能の大きさがサイクルタイムに影響を及ぼしていないとヘンリックは結論付けている。

【3】サイクルタイムの計算方法

「リーン開発の現場」の12章プロセスメトリクスP.88-89で、サイクルタイムの計算を以下で計算している。

・開発中の機能(仕掛り中(WIP)の機能)
　＝L_q(待ち行列内の平均カード数)
　＝30機能

・1週間で開発できる機能(Velocity)
　＝λ(平均到着率)
　＝5機能/週

⇒サイクルタイム(1機能あたりの平均待ち時間)
　＝W_q(待ち行列内の平均待ち時間)
　＝30/5＝6週間

※注意：
「リーン開発の現場」P.88を読むと、下記の仮定があるように思える。
・Vecocityは5機能/週で安定していた。
・WIP制限(仕掛かり制限)は、30機能で上限値を決めていた。
　かんばんの写真を見ると、開発チームは3チームあり、チームごとのWIP制限は10機能で決めていた。
　⇒3チーム全体のWIP制限は、3 * 10＝30機能になる。

かんばんのメトリクスで面白いのは、仕掛かり中の機能カード数とVelocityを計測できれば、リトルの法則によってサイクルタイムの理論値を計算できることだ。

ヘンリックは、サイクルタイムを平均6週間から2週間に改善したいと考えていた。
すると、選択肢としては、二つある。

一つは、Velocityを増やすこと。
もう一つは、WIP制限を減らすこと。

Velocityを5⇒10機能/週へいきなり増やすのは、現実的に無理。
むしろ、WIP制限を減らす方が即効性がある。
作業中の機能カードの数を減らすだけだから、簡単だ。

WIP制限を30⇒15機能へ減らすと、サイクルタイムは下記で計算できる。

・開発中の機能(仕掛り中(WIP)の機能)
　＝L_q(待ち行列内の平均カード数)
　＝15機能

・1週間で開発できる機能(Velocity)
　＝λ(平均到着率)
　＝5機能/週

⇒サイクルタイム(1機能あたりの平均待ち時間)
　＝W_q(待ち行列内の平均待ち時間)
　＝15/5＝3週間

※注意：
「リーン開発の現場」P.89を読むと、下記の仮定があるように思える。
・1チームごとのWIP制限(仕掛かり制限)は、10⇒5機能で上限値を決めた。
　⇒3チーム全体のWIP制限は、3 * 5＝15機能になる。

よって、サイクルタイムが6⇒3週間に半分減らせたので、当初の目標の1/3へ減らすのは無理だったが、十分な削減だったとヘンリックは結論付けている。

【4】サイクルタイムにリトルの法則を適用する意味

サイクルタイムの計算方法で面白いのは、かんばん上で流れる仕掛中のカード枚数の上限値(WIP制限)が待ち行列内の客数(L_q)に相当することと、Veclocityが待ち行列システムの平均到着率に相当することだ。

前者は、何を意味しているのか？
どの開発チームもメンバーが手持ち無沙汰にならないように、メンバーにタスクを1個以上アサインするが、かんばん上で作業できる機能カードは、WIP制限という上限値があるので、その上限値いっぱいまで作業するのが前提になっているように思える。
つまり、かんばん上の機能カードは常時、WIP制限という上限値までいっぱいに貼られている場合が多い。

すると、かんばん上で開発中～システムテスト中の機能カードは、あたかも待ち行列と見なすことができる。
待ち行列にたまっている客数、つまり、機能カード数はWIP制限という上限値になっているわけだ。

後者は何を意味しているのか？
リトルの法則の前提条件としては、待ち行列への平均到着率(λ)やサービス利用率(μ)が同じと想定している。

かんばん上の仕掛中の機能カードがWIP制限という上限値いっぱいまで貼られていたとすれば、かんばんは機能カードで満杯状態だ。
すると、この前提条件を満たす状況では、開発中フェーズに機能カードに入れるタイミングは、システムテスト中フェーズから受入テスト準備OKフェーズへ機能カードを出すタイミングと同じになる。

普通は、サービス利用率(サービス処理率)がVelocityに相当するように思えるけれども、上記の前提条件があるから、平均到着率と見なせるのだろう。

つまり、機能カードが開発完了しなければ、次の新しい機能カードが開発中フェーズのかんばんに入れることはできないから、Pullシステムに似ているように思える。
かんばんでは、後工程の作業が終わらなければ、前工程でいくら作業して成果物を後工程へ送り続けても、WIP制限によって、前工程で成果物を作れない仕組みになっているわけだ。

【5】WIP制限(仕掛り制限)を制御する理由

【5-1】WIP制限が重要な理由は、「リーン開発の現場」ではいくつか書かれている。

一つは、過剰なマルチタスクを避けるために、後続プロセスに負荷をかけすぎないようにするため。(P.75)
WIP(仕掛中)とは、開発中・システムテスト準備OK・システムテスト中の3つのフェーズに貼られているカードを指す。
開発中のカードは開発チーム、システムテスト中のカードはテストチームの役割分担になっている。

開発チームは開発中のカードだけに専念してどんどん機能を実装すればいいが、じきにシステムテスト準備OKにカードがたくさん溜まってくる。
テストチームは頑張って、システムテスト中へ機能カードを移してテストするだろうが、普通はテストの方が時間がかかるから、システムテスト中がボトルネックになってくる。

でも、1チームのWIP制限が10枚と決まっていれば、システムテスト準備OK・システムテスト中のカードが10枚あって、開発中のカードが0枚であったとしても、開発チームは次の新しい機能カードに着手することはできない。
機能カードをどんどん開発して、システムテスト準備OKへ移しても、テストがボトルネックなので、無駄な在庫をどんどん増やしていることになるからだ。

つまり、開発チームは手持ち無沙汰だが、テストチームは忙しすぎて次の作業に手が回らないことを意味している。
だから、この状況では、開発チームはテストチームの支援に集中すべきだ、とヘンリックは言っている。

もう一つは、メトリクスの一貫性を保つため。(P.78)
ヘンリックは故意に、機能カードのみWIP制限という上限値を付けており、技術課題やバグ修正にはWIP制限はつけていない。
WIP制限があるからこそ、待ち行列の客数(L_q)がほぼ一定になるし、平均到着率(λ)も平均化しやすい。
リトルの法則が使えることを意味しているのだろう。

【5-2】「リーン開発の現場」では、WIP制限を減らす手法に力点を置いているが、その手法がいつも有効とは限らない。
WIPを減らしすぎると、メンバーが手持ち無沙汰となり、暇になって遊んでしまう。(P.89)
更に、遊んでしまう人が増えて一部の人だけが忙しい状態になれば、Velocityが小さくなってしまい、悪影響を及ぼす副作用もありうる。

だから、「リーン開発の現場」では、WIP制限がいっぱいの理由で手持ち無沙汰となったメンバーには、技術課題に取り組んでもらうことを「奨励している」らしい。(P.78)
技術課題を解決すると、後続プロセスの中にあるボトルネックが解消する場合があるからだ。(P.76)
実際、テスト自動化、ビルド自動化、テストデータの作成、テスト環境の構築などに取り組めば、テスト作業のボトルネックが解決されるだろう。

そのために、「今週の質問」というカードを貼り付けておき、やることのないメンバーには、「今週の質問」にある「今日すべきことは何か？」に従って優先順位の高い作業に取り掛かるように仕向ける。
つまり、WIP制限によって、メンバーは、いつもと違う作業を時々やってもらうようになる。(P.79)

「WIP制限の本質は、何かを始めるよりも、今の作業に集中して終わらせることだ！」(P.79)とヘンリックが主張しているのは、上記のような理由があるのだろう。

【5-3】ここで、WIP制限のように、機能カードの上限値を設定する箇所は、仕掛中(WIP)の機能カード以外にもあるのに注意したい。
「次の10機能」フェーズは、開発チームが取り掛かるプロダクトバックログに相当するが、カード枚数は10枚に制限されている。
そのおかげで、開発チームはどれに取り掛かればよいか、すぐに判断できる。

また、バグの登録枚数を30枚に制限している。(P.54)
ヘンリックによれば、バグがトップ30に入るかどうかの議論が必要なバグだけに集中したいから。
バグ一覧が無制限に満杯の場合、長時間の退屈な変更管理ミーティングが必要になり、時間の無駄だから、と彼は言っている。
バグがブロッカーならば、すぐに修正すれば言いし、トップ30に入らないバグに対処するよりも、機能カードに着手する方が優先度が高いから。

この箇所は、チケット駆動開発の弱点を補っている部分のように思える。
チケット駆動開発では、どうしてもチケットは乱発されやすい。
すると、チケット一覧からチケットを棚卸ししたくても、変更管理ミーティング内で精査できない時が多くなる。
バグのトップ30のように既に上限値があれば、チケットを捨てても構わない。
バグの一覧はいつも最新化されているならば、棚卸しのコストはかなり減る利点がある。

【5-4】WIP制限をうまく使うテクニックは、TOCの話を連想させる。
TOCでは、ボトルネックとなる工程がシステム全体のスループットを決定づけるから、ボトルネックの生産能力を上げるべきだと言っている。
これは、テスト工程がボトルネックだからこそ、前工程である開発中フェーズの機能カードを頑張っても在庫を無駄に増やすだけで、テスト工程に注力すべきという話につながるだろう。

また、TOCでは、生産の揺らぎ(変動)を安定させることにも言及している。
これは、Velocityが平均到着率とみなせた場合、Velocityを安定化することで、スループットを安定化できることを意味していると思う。

また、メンバーが技術課題を解決するとボトルネックが解消される話は、TOCにおけるボトルネック改善プロセスに似ているように思える。
ボトルネックを探して解決して、惰性にならないように、別のボトルネックを探して注力していくプロセスと同じだから。

【6】「リーン開発の現場」を読むと、単にかんばん上で機能カードを作業しているだけではなく、とても細やかなノウハウが詰め込まれているのが分かる。

Redmineによるチケット駆動開発を経験していれば、チケット一覧をかんばん、チケットを機能カードに対応付けて、作業するだけに思えるかもしれない。
でも、「リーン開発の現場」では、かんばんを単なる作業用のタスクボードではなく、WIP制限という仕掛中のカード数に上限値を設けて、テストチームの作業負荷が高くならないようにして、メンバーがプロジェクト内で自発的に動くような仕組みが織り込まれている。

「リーン開発の現場」の写真にあるかんばんを見ると、フェーズがたくさんあるだけでなく、かんばんの枠外にあるメモがたくさん貼り付けられている。
そのメモは「今日の質問」「次の5つの技術課題」など、WIP制限によって暇なメンバーが手持ち無沙汰にならないように、普段とは違った作業をしてもらうような雰囲気が仕組まれている。

そんな部分を読み取ると、「リーン開発の現場」のかんばんによるプロジェクト管理は、ヘンリック独自のノウハウがたくさん詰め込まれているのが良く分かる。

但し、「リーン開発の現場」を読んで、新たに以下の疑問も持っている。
色々考えてみたいと思う。

(1)サイクルタイムを最小値とするには、WIP制限(仕掛制限)をどれくらい減らせばいいのか、という手法はあるか？
　WIP制限を小さくしすぎると、逆にサイクルタイムは長くなるのではないか？

(2)メンバーの稼働率と、サイクルタイムに関係性はあるか？
　直感的には、稼働率が低すぎるとメンバーは暇すぎるのでVelocityが落ち、サイクルタイムもさほど短くならない。
　稼働率が高すぎると、メンバーの作業負荷が高いため、Velocityは低くなり、サイクルタイムは急激に長くなると思われる。
　最も頃合の良い稼働率を計算するための手法はあるか？