チケット駆動におけるメトリクス集計方法～「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」資料から分かるもの

「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」の資料が良かったので、リンクしておく。

メトリクスによる「見える化」のススメ: エッセンシャル・リーン from Hiroyuki Ito

【参考】
XP祭り2014で、メトリクスについてLTしてきました - THE HIRO Says

Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says

上記の資料で気になる内容は、アジャイル開発で有用なメトリクスを提示している点だ。
これらメトリクスを読むと、こんな疑問が湧いてくる。

これらのメトリクスはどんな場面で有効なのか？
そして、チケット駆動開発に置き換えると、これらのメトリクスはどのような集計方法で実装されるべき仕様なのか？

以下の4つのメトリクスを考えてみた。

【１】Cumulative Flow Diagram (CFD)

いわゆる累積フロー図。
「リーン開発の現場」の第12章にも紹介されている。
仕組みとしては、ステータス毎にタスクカードを集計した枚数を、時系列に並べた図になる。

累積フロー図の発端は、かんばんのメトリクスでよく出てくる「製造業の追番管理」そのものだ。
製造業では、第1工程→第2工程→・・・の順に製品が作られる場合、工程ごとにかんばんの枚数を集計し、時系列に並べる。
その図から、どこにボトルネックが発生しているか、が分かるのが利点。
実際、どこかの工程でカンバンの枚数が多ければ、その工程で何かの事情で、無駄な在庫が溜まっていると推測される。

「リーン開発の現場」の感想part6～累積フロー図は生産管理の流動曲線管理または追番管理である: プログラマの思索

「受注生産に徹すれば利益はついてくる」の感想～ERP普及が上流工程の軽視を助長している: プログラマの思索

しかし、「リーン開発の現場」では、累積フロー図は良いと色んな人が言っているが、実際に使い物にはまだなっていない、というコメントもある。
たとえば、ソフトウェア開発の現場では、仕掛りチケットが溜まった状況が一気に消化された場合、あとで聞いてみると、定期的にチケットの棚卸しをしているに過ぎない時もある。
つまり、棚卸しするまで、仕掛りチケットがずっとたまり続けており、その状況を誰も気にしていない。
そして、ある一定の時期になれば、溜まった仕掛りチケットを消化する運用になっていて、そんな状況では余り意味が無いかもしれない。

【２】スループット

ある一定期間で、どれだけのチケットが終了しているのか？

ScrumのVelocityに相当するだろう。
Scrumなら4週間のスプリントで、終了したチケットの枚数を数えれば、それがVelocityになる。
TOCのスループットの概念に似ている。

XPの「持続可能な開発プロセス」というプラクティスに従えば、Velocityは変動すべきものではなく、安定すべきもの。
つまり、Velocityが急激に増えたり、減ったりするような性質にしない方がいい。

開発チームが安定して出荷可能な製品をリリースできるような仕組みを作るべきだろう。

【３】サイクル・タイム

チケットが次のフェーズに移動するのに、 どれだけ時間がかかっているのか？

この資料のサイクルタイムは、次ステータスへ遷移するまでのステータス間の作業時間で定義される。
つまり、かんばんのボードで区切られたステージ(ステータス)を横切る時に、どれだけの作業時間がかかったのか、を示す。

サイクルタイムが短いほど、スムーズに各工程で作業が流れていることになる。
また、各工程(各ステータス)のサイクルタイムの変動量が小さいほど、安定して作業していることになる。

普通は、プログラム実装や設計書作成の作業はスムーズに進んでも、コードレビューや設計レビューで長時間待たされて、フィードバックを受けて再修正するうちに、どんどん時間だけ浪費してしまう時も多い。

サイクルタイムが長いという事実は、作業時間そのものが長くて作業の効率が悪いか、または、作業は終わっているのに次の工程の作業のキューに溜まって待ち時間が発生しているか、のどちらかだ。
多くの場合、無駄な待ち時間が長い時の方が多い。
特に、レビューアが少なければ、レビューがボトルネックになりやすい。

なお、「リーン開発の現場」のサイクルタイムの定義は「ある機能が「次の10機能」ステージから「受入テスト準備OK」ステージに到着する時間」としているので、ちょっと違う。
「リーン開発の現場」のサイクルタイムの定義は、この資料のリードタイムの意味に近い。

「リーン開発の現場」はアジャイルサムライの再来となるかpart3～サイクルタイムとリトルの法則の関係: プログラマの思索

チケット駆動開発におけるサイクルタイムの計測方法～リーン開発で最も重要なメトリクス: プログラマの思索

また関連して、プロセスサイクル効率というメトリクスも計算してみると良い。
作業時間よりも待ち時間が多いかどうかという指標として有効だからだ。

「リーン開発の現場」の感想part4～トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

【４】リード・タイム

チケットが開始してから終了するまで、どれだけ時間がかかっているのか？

チケットの平均完了日数に相当する。
古くからある障害管理ツールMantisでは、平均完了日数というメトリクスが最初から表示されている。

平均完了日数は、ユーザから見れば、システム改善要望の待ち時間と同等である。
つまり、改善要望のチケットを起票したら、平均完了日数の日数はかかるだろう、と見ておかないといけない。
すると、平均完了日数が長いシステムほど、顧客満足度は低くなるだろう。

アジャイル開発であれば、リードタイム(平均完了日数)は基本はイテレーションの期間よりも短くなるのが前提。
イテレーション計画で立てたタスクカードは、イテレーション終了時には全て完了しているはずだから。

逆に言えば、イテレーションの期間に収まり切らないようなチケットがあれば、イテレーション終了時にはリリースすべき機能の残作業が残っていて、リリースできなかったことを意味するだろう。

【５】以上をまとめると、チケット駆動開発では、上記のメトリクスは下記で置き換えられる。

Cumulative Flow Diagram (CFD)
→累積フロー図と同等。
→ステータスごとに集計したチケット枚数を時系列に並べたグラフ。

スループット
→Velocityと同等。
→各スプリントの完了チケットの平均枚数。

サイクルタイム
→チケットをステータスごとに集計した時の平均作業時間。

リードタイム
→チケットの平均完了日数。

チケット駆動開発で考えれば、上記のメトリクスの仕様はすぐに分かるし、Redmine上ですぐに実装できるだろう。
そして、それらメトリクスを使うことで、プロジェクト管理に役立てることもできるだろう。

他にも役立つメトリクスはないのか？
その他のメトリクスはどんな場面で役立つのか？
いろんな課題が出てくるだろう。