チケット駆動におけるメトリクス集計方法~「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」資料から分かるもの
「メトリクスによる「見える化」のススメ: エッセンシャル・リーン」の資料が良かったので、リンクしておく。
【参考】
XP祭り2014で、メトリクスについてLTしてきました - THE HIRO Says
Agile2014に参加してみて分かった昨今の世界のアジャイル事情 - THE HIRO Says
上記の資料で気になる内容は、アジャイル開発で有用なメトリクスを提示している点だ。
これらメトリクスを読むと、こんな疑問が湧いてくる。
これらのメトリクスはどんな場面で有効なのか?
そして、チケット駆動開発に置き換えると、これらのメトリクスはどのような集計方法で実装されるべき仕様なのか?
以下の4つのメトリクスを考えてみた。
【1】Cumulative Flow Diagram (CFD)
いわゆる累積フロー図。
「リーン開発の現場」の第12章にも紹介されている。
仕組みとしては、ステータス毎にタスクカードを集計した枚数を、時系列に並べた図になる。
累積フロー図の発端は、かんばんのメトリクスでよく出てくる「製造業の追番管理」そのものだ。
製造業では、第1工程→第2工程→・・・の順に製品が作られる場合、工程ごとにかんばんの枚数を集計し、時系列に並べる。
その図から、どこにボトルネックが発生しているか、が分かるのが利点。
実際、どこかの工程でカンバンの枚数が多ければ、その工程で何かの事情で、無駄な在庫が溜まっていると推測される。
「リーン開発の現場」の感想part6~累積フロー図は生産管理の流動曲線管理または追番管理である: プログラマの思索
「受注生産に徹すれば利益はついてくる」の感想~ERP普及が上流工程の軽視を助長している: プログラマの思索
しかし、「リーン開発の現場」では、累積フロー図は良いと色んな人が言っているが、実際に使い物にはまだなっていない、というコメントもある。
たとえば、ソフトウェア開発の現場では、仕掛りチケットが溜まった状況が一気に消化された場合、あとで聞いてみると、定期的にチケットの棚卸しをしているに過ぎない時もある。
つまり、棚卸しするまで、仕掛りチケットがずっとたまり続けており、その状況を誰も気にしていない。
そして、ある一定の時期になれば、溜まった仕掛りチケットを消化する運用になっていて、そんな状況では余り意味が無いかもしれない。
【2】スループット
ある一定期間で、どれだけのチケットが終了しているのか?
ScrumのVelocityに相当するだろう。
Scrumなら4週間のスプリントで、終了したチケットの枚数を数えれば、それがVelocityになる。
TOCのスループットの概念に似ている。
XPの「持続可能な開発プロセス」というプラクティスに従えば、Velocityは変動すべきものではなく、安定すべきもの。
つまり、Velocityが急激に増えたり、減ったりするような性質にしない方がいい。
開発チームが安定して出荷可能な製品をリリースできるような仕組みを作るべきだろう。
【3】サイクル・タイム
チケットが次のフェーズに移動するのに、 どれだけ時間がかかっているのか?
この資料のサイクルタイムは、次ステータスへ遷移するまでのステータス間の作業時間で定義される。
つまり、かんばんのボードで区切られたステージ(ステータス)を横切る時に、どれだけの作業時間がかかったのか、を示す。
サイクルタイムが短いほど、スムーズに各工程で作業が流れていることになる。
また、各工程(各ステータス)のサイクルタイムの変動量が小さいほど、安定して作業していることになる。
普通は、プログラム実装や設計書作成の作業はスムーズに進んでも、コードレビューや設計レビューで長時間待たされて、フィードバックを受けて再修正するうちに、どんどん時間だけ浪費してしまう時も多い。
サイクルタイムが長いという事実は、作業時間そのものが長くて作業の効率が悪いか、または、作業は終わっているのに次の工程の作業のキューに溜まって待ち時間が発生しているか、のどちらかだ。
多くの場合、無駄な待ち時間が長い時の方が多い。
特に、レビューアが少なければ、レビューがボトルネックになりやすい。
なお、「リーン開発の現場」のサイクルタイムの定義は「ある機能が「次の10機能」ステージから「受入テスト準備OK」ステージに到着する時間」としているので、ちょっと違う。
「リーン開発の現場」のサイクルタイムの定義は、この資料のリードタイムの意味に近い。
「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索
チケット駆動開発におけるサイクルタイムの計測方法~リーン開発で最も重要なメトリクス: プログラマの思索
また関連して、プロセスサイクル効率というメトリクスも計算してみると良い。
作業時間よりも待ち時間が多いかどうかという指標として有効だからだ。
「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索
【4】リード・タイム
チケットが開始してから終了するまで、どれだけ時間がかかっているのか?
チケットの平均完了日数に相当する。
古くからある障害管理ツールMantisでは、平均完了日数というメトリクスが最初から表示されている。
平均完了日数は、ユーザから見れば、システム改善要望の待ち時間と同等である。
つまり、改善要望のチケットを起票したら、平均完了日数の日数はかかるだろう、と見ておかないといけない。
すると、平均完了日数が長いシステムほど、顧客満足度は低くなるだろう。
アジャイル開発であれば、リードタイム(平均完了日数)は基本はイテレーションの期間よりも短くなるのが前提。
イテレーション計画で立てたタスクカードは、イテレーション終了時には全て完了しているはずだから。
逆に言えば、イテレーションの期間に収まり切らないようなチケットがあれば、イテレーション終了時にはリリースすべき機能の残作業が残っていて、リリースできなかったことを意味するだろう。
【5】以上をまとめると、チケット駆動開発では、上記のメトリクスは下記で置き換えられる。
Cumulative Flow Diagram (CFD)
→累積フロー図と同等。
→ステータスごとに集計したチケット枚数を時系列に並べたグラフ。
スループット
→Velocityと同等。
→各スプリントの完了チケットの平均枚数。
サイクルタイム
→チケットをステータスごとに集計した時の平均作業時間。
リードタイム
→チケットの平均完了日数。
チケット駆動開発で考えれば、上記のメトリクスの仕様はすぐに分かるし、Redmine上ですぐに実装できるだろう。
そして、それらメトリクスを使うことで、プロジェクト管理に役立てることもできるだろう。
他にも役立つメトリクスはないのか?
その他のメトリクスはどんな場面で役立つのか?
いろんな課題が出てくるだろう。
| 固定リンク
「Redmine」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 「RedmineのUbuntu+Docker構築への移行」の感想 #redmineT(2024.11.24)
- 第27回redmine.tokyo勉強会の感想 #redmineT(2024.11.10)
- Redmineのバージョン設定でプロジェクトの設定方法が違う(2024.06.23)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
「チケット駆動開発」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- 第26回redmine.tokyo勉強会の感想~多様性はコミュニティが成功する重要な要因の一つ #redmineT(2024.06.15)
- チケットはデータでとプロセスの二面性を持つ #redmine(2023.12.24)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「Agile」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーにおける4チームのインタラクションをUMLで整理してみた(2025.01.12)
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント