プログラマの思索

「リーン開発の現場」「リーン開発の本質」「リーンソフトウエア開発」を読み直すと、リーン開発で最も重要なメトリクスはWIP(仕掛り制限)ではなく、サイクルタイムであるような気がした。
ラフなメモ書き。

【1】「リーン開発の現場」を読み直すと、XPやScrumには出てこなかったメトリクスとして、サイクルタイムが出てくる。

「リーン開発の現場」では、サイクルタイムとは、１機能の開発にかかった日数(週数)。
かんばん上の計測方法としては、「次の10機能」ステージから「受入テスト準備OK」ステージへ到着するまでの時間である。

サイクルタイムは何故重要なのか？
サイクルタイムは、顧客の要求が受付された後、本番リリースまでにどれくらいの時間がかかるか、を意味する。
サイクルタイムが短いほど、顧客の要求が製品に反映されるリードタイムが短くなるから、よりスピーディに注文を受け付けることが可能になる。
一時期のDellのPC組立事業と同じだ。

しかし、サイクルタイムを短くするのは現実的にはかなり難しい。
実際にサイクルタイムを計測してみると、その内訳の殆どは作業待ち時間で消費されている。
つまり、「ムダ」がたくさん含まれている場合が多い。

「リーン開発の現場」では、プロセスサイクル効率でムダがどれくらい存在するのかをメトリクスで示している。

プロセスサイクル効率＝作業日数/経過日数

「リーン開発の現場」によると、たいていの企業ではプロセスサイクル効率は10～20％くらいだという。
つまり、サイクルタイムが20日(1ヶ月)だとしたら、実作業時間はわずか2～4日であり、残りの16～18日は作業待ち時間として在庫として積まれている事実を意味している。
作業待ちが16日以上もあるのならば、何故すぐにリリースしないのか、という指摘をしているわけだ。

製品が作業待ちとして80～90％も倉庫で眠っているとしたら、倉庫に保管している間、電気水道代もかかるし、その期間に市場が値崩れしてしまう危険もあるからだ。

【2】「リーンソフトウエア開発」P.33において、バリューストリームマップで分析したサイクルタイムの例が載っている。

(1)伝統的なウォーターフォール型開発の場合、
要求抽出→プロジェクト承認→要求収集→顧客の承認→分析→設計→設計レビュー→コーディング→テスト→導入
の作業が発生し、下記の内訳となる。

作業時間(実績工数)＝21.6週
作業待ち時間＝35週
↓
サイクルタイム＝作業時間＋作業待ち時間＝56.6週
↓
プロセスサイクル効率＝21.6/56.6＝38.2％

(2)アジャイル開発の場合は、
要求抽出→プロジェクト承認→仮設→1イテレーション→2イテレーション→3イテレーション
の作業が発生し、下記の内訳となる。

作業時間(実績工数)＝14.1週
作業待ち時間＝2.8週
↓
サイクルタイム＝作業時間＋作業待ち時間＝16.9週
↓
プロセスサイクル効率＝14.1/16.9＝83.4％

上記のサイクルプロセス効率を比較すると、WF型開発では、サイクルタイムのうち実作業して顧客に価値を提供している割合はわずか38％しかないのに対し、アジャイル開発では、サイクルタイムの実に80％以上を顧客に実際に価値を提供している作業に費やしている。
つまり、アジャイル開発の方が作業にムダが少ないことを指摘しているわけだ。

但し、「リーン開発の現場」では普通の企業のプロセスサイクル効率は10～20％しかないと書かれているから、もしそれが本当だとしたら、上記のWF型開発のメトリクスよりも更に悪いために、本当に意味ある作業に殆ど費やしていないことを示しているのだろう。

【3】チケット駆動開発で、サイクルタイム、プロセスサイクル効率はどのように実装されるか？
回答は下記だ。

チケットの属性には、開始日、終了日、実績工数が必ず入力されているとする。

(1)サイクルタイム＝チケットの平均完了日数(チケットの開始日から終了日までの経過日数)

(2)プロセスサイクル効率＝チケットの実績工数の合計/チケットの完了日数

各チケットでサイクルタイムは上記で計算できるので、アジャイル開発では、各イテレーションの全てのチケットのサイクルタイムを計算できるから、1イテレーションの平均サイクルタイムを出力できる。
そこから、イテレーション単位にプロセスサイクル効率を計算できる。

【4】上記の定義を見ると、チケットのサイクルタイムはMantisの平均完了日数とまさに同一だ。

Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索

つまり、チケットが起票されてCloseされるまでの経過日数が平均完了日数であり、サイクルタイムとなる。
更に、障害チケットのサイクルタイムは平均修復時間(MTTR)そのものになる。

アジャイル開発では、サイクルタイムを短くすることに注力する。
その意味は下記にも書いたけれども、MTTRを極力短くすることによって、信頼度を高く保つことにある。
そのやり方は、WF型開発が極力故障を起こさないような方針に対し、アジャイル開発はたとえ障害がたくさん発生してもMTTR(サイクルタイム)を短くすることで、信頼度を同じ程度に保てるはずだ、という主張になっている。

アジャイル開発と品質管理の関係: プログラマの思索

アジャイル開発が問題点をすり替えた品質特性～機能性と信頼性: プログラマの思索

【5】上記の定義を見ると、チケットのプロセスサイクル効率は、簡単に出力できる。

チケットが完了したタイミングで、実績工数と完了日数は確定される。
つまり、チケットを完了ステータスへ更新するタイミングで、リアルタイムにチケットのプロセスサイクル効率を計算すれば良い。

【6】チケット駆動開発において、サイクルタイムやプロセスサイクル効率というメトリクスは、どんな分析結果を提供し、どんな課題が発生するのか？

「リーン開発の本質」P.129にタスクリストの話が載っている。
あるマネージャは、プロジェクトのタスクリストに750個のタスクがあり、それらに優先順位を定期的につけているという。
メアリーは、その要求を1ヶ月に平均していくつ完成できるか、聞いた。
マネージャは、平均して、毎月9つは完了すると答えた。(つまり、Velocityは9個/月)
すると、750個/9(個/月)＝約7年分の作業がタスクリストに積まれていることになる。

その意味は、新しい顧客の要求がたった今到着したとしたら、タスクリストという作業待ち行列(キュー)の順序を変更できない場合、7年後にならなければリリースされないことを意味している。
メアリーは、絶対に終われないなら、そんなに大量のタスクリストに意味があるのか、と問うている。

この寓話は非常に重要な指摘事項だ。
チケット駆動開発を運用すると、チケットはどんどん溜まっていく。
チケット駆動開発では、忘れたくない作業や顧客の要望で重要度は高くない要望もチケット化する時が多いからだ。

だから、100枚や300枚のチケットが残として残るのは普通だ。
すると、残チケットの重みでタスクの進捗は落ちていきやすい。

例えば、300枚の残チケットがあるならば、Velocityが5枚/週としても、60週＝約1.1年分のタスクが積まれていることになる。

以前Mantisを運用していた時、Mantinsのメトリクス画面において、チケットの平均完了日数は100～300日という値はザラに表示されていた。
その場合ならば、もっとひどくなるだろう。

それゆえ、チケット駆動開発では、棚卸しという場で、全チケットを精査し、イテレーション(リリースバージョン)単位にチケットを振り分けして、制御可能な作業量へ調整する。
棚卸しはできれば毎日、少なくとも週1回は行わなければ、チケットの精度が落ちてしまう。

また、Pivotal Trackerのように、Iceboxという要望の貯蔵庫を別途作る運用もある。

Pivotal Trackerとredmineの違い: プログラマの思索

例えば、忘れたくない作業や顧客の要望で重要度は高くない要望のように、今すぐ着手する必要はないチケットは、Iceboxに一旦保管しておき、棚卸しのタイミングで必要なチケットをBacklogに引っ張り出し、イテレーションに割り当てる。
Iceboxという特別なイテレーション(Redmineの対象バージョン)に保管しておけば、サイクルタイムの計算外として運用することも可能になる。

その意味では、チケットの棚卸しというプラクティスで、サイクルタイムが長くなりやすい罠を防ごうとしている。
だが、棚卸しだけでは対策は不十分だ。

「リーン開発の現場」に出てくる因果関係図、「リーン開発の本質」に出てくるバリューストリームマップ、TPSのなぜなぜ分析のようなツールを使って、サイクルタイムにムダな作業がないか、なぜ作業待ちというムダが発生するのか、を徹底的に原因追求する必要があるだろうと思う。

【7】XP→Scrum→リーンというアジャイル開発の進化の歴史を辿ると、XPが見出した暗黙的なメトリクスが具現化された過程のように思える。

XPが提唱した週40時間労働、持続可能な開発ペースという概念は、ScrumがVelocity(スプリント単位の平均開発速度)で具現化された。

XPが提唱した小規模リリース、イテレーション単位の頻繁なリリースの背後には、サイクルタイム(要望受付からリリースまでのリードタイム)を短くするという手法が隠されている。
そのメトリクスはリーン開発では、サイクルタイム、プロセスサイクル効率で具現化された。

チケット駆動開発上でサイクルタイムやプロセスサイクル効率を実装した場合、どんな効果が生まれるのかをさらに考えてみたい。