Tbpgr Blog

Employee Experience Engineer tbpgr(てぃーびー) のブログ

リーンソフトウェア開発 | リトルの法則

概要

リトルの法則

詳細

リーンソフトウェア開発では顧客満足を高めるために素早く開発を行う必要がある。
そこでリトルの法則を利用して、開発を改善する。

リトルの法則とは待ち行列理論において
・長時間平均化した顧客数L
・長時間平均化した到着率λ
・長時間平均化した顧客が系に費やす時間 W
とした場合、

L= λW

という法則ある。

これをシステム開発に置き換えるならば
平均要件量 = 要件の到着率 × 要件の消化に費やす時間

1ヶ月に20件の要件が発生し、チームは1件あたりの開発に1週間(=5営業日)かかるとします。
この場合、20 × 5 = 100(日)が平均要件量となります。

そこで、以下の様な対応をします。
・作業を平準化させる
・要件を絞る=>本当に重要な機能のみを要件リストに追加する
・1定期間に受け付ける要件の数を抑える
・各要件のサイズを最小化する
・プル型スケジューリング
※開発者が自ら自分の許容範囲内のタスクを選択する。早く終われば残りの作業リストから
新たななタスクを選択しても良い。

上記の対応により例えば
・要件は月10件のみ受け付けるようにする
・各要件のサイズを以前の1/2にする
などをした場合、最初の例は以下のように変わります。

1ヶ月に10件の要件が発生し、チームは1件あたりの開発に2.5営業日かかる。
この場合、10 × 2.5 = 25(日)が平均要件量となります。
これで、各要求から実現への時間や全体としての待ち時間が短縮され
顧客の要望は素早く実現されるようになります。

補足

Googleの20%ルールは、開発者の余裕を持ちつつ開発者のモチベーションを高めているため
この理論にそっている。各開発者は20%ルールの時間を持っているが、いざスケジュールに余裕がなくなれば
80%の本業のリスク削減に利用することが出来る。
待ち行列が増えることは、単純な平均要件量以上の負荷を産む。
開発者への負荷、管理コスト、コンテキストスイッチの増加による作業効率の低下等々。
・よくある悪週間=>少しでも手が開いている開発者がいたらどんどん作業を詰め込む。
複数作業、複数コンテキストによる作業効率低下。その人物が各種作業のキーパーソンだった場合は
他作業へのクリティカルパスの目詰りをも産む。
若干余力がある程度の方が全体の作業が滞り無く進む。

課題

・プロジェクトマネージャーが顧客に上記の内容を理解していただくための
交渉力が必要となる。
組織として上層部にこの考えを認めてもらい、承認を貰う必要がある。
=>実績を作るしかないか?

雑記

・現状の私の職場は、高負荷ではなく作業量も抑えられているため
この件は満たされている。
・L= λWを変形してW = L / λとした場合、待ち時間の計算に活用出来る。
自分の前に並んでいた人数 = 50人
自分の後に並んた人数 = 1分間で10人
待ち時間 = 50 / 10 = 5 × 1分 = 5分