Mantisのチケット集計機能にある最大放置日数と平均完了日数
Mantisには要約(summary_page.php)というWebページがチケット集計機能に相当する。
そこに表示されている「最大放置日数」「平均完了日数」についてメモ。
【元ネタ】
MantisBT Git - mantisbt.git/blob - lang/strings_japanese.txt
Mantisの要約ページは、Redmineのサマリ画面のように、優先度・開発者・起票者などの観点でチケット数を集計表示してくれる。
その中で興味を引いたメトリクスは、「最大放置日数」「平均完了日数」。
【1】最大放置日数は、チケットが起票されてから未完了のまま放置されている期間を表示している。
RedmineやTracでチケット駆動開発を実践してみると、チケットが放置される時は多い。
例えば、チケットに起票された課題を解決するには、顧客や上司の同意が必要だったり、回答を得て課題が解決したと思っても見直してみたら、実は別の不明点が出てきたりする時がある。
あるいは、結合テスト工程でバグがたくさん出て、チケットが乱発されてしまい、チケットの棚卸しが出来ていない時もあるだろう。
ダメなプロジェクトリーダーほど、チケットの棚卸し、つまりチケットの優先順位付けを判断出来ていない。
最大放置日数が長いチケットがたくさんあるほど、チケット管理がうまく機能されていない状況を意味する。
せっかくプロジェクト管理をチケット管理に置き換えたとしても、次々に起票されるチケットが解決されなければ、プロジェクトは停滞していることと同じ。
チケット駆動開発では、チケットは単なるタスクや障害だけでなく、設計上の課題や実装リスクも起票されるので、それらのチケットを管理することはリスク管理につながる。
次々に起票されるチケットはプロジェクトのリスクとして見える化されたわけだから、プロジェクトリーダーはそれらチケットに対して、あらゆる手を使って解決しなければならない責任を負っている。
特にバグが発見されて、そのチケットの難易度がたとえ簡単であったとしても、放置されている期間が長いほど、残存バグの解決コストは大きくなる。
残存バグの解決コストは、難易度×最大放置日数だからだ。
たとえ簡単なバグであっても、発見されずに放置されれば、リリース後の改修コストは非常に高くつく。
【2】平均完了日数は、チケットが起票されてから完了するまでの平均日数を表示している。
例えば、バグが発見されてから、開発者が修正して、テスターが検証して解決するまでの期間に相当する。
平均完了日数はまさに、ソフトウェアのMTTR(平均修復時間)を表している。
チケット駆動開発の場合、イテレーション単位にAgileに開発していくから、平均完了日数がイテレーション期間よりも短くなるように調整しなければ、そもそもリリースできないだろう。
Scrumなら4週間、XPなら2~4週間のサイクルで小刻みにリリースする開発スタイルを実践したいならば、平均完了日数はその期間以下に抑える必要がある。
普通のチケットは1人日以下で終わる時が多いだろうが、テストやレビューで検証NGとなって差し戻しになったり、設計上の課題を質問して回答を得ても精査したら整合性があっていなかったので再質問する時もあるだろう。
又、プロジェクトの運営上、放置すると意思決定したチケットもあるだろう。
そうすれば、結局、平均完了日数は、例えば5日とか10日などのように長くなる。
逆に言えば、チケットの平均完了日数よりも短いイテレーションでAgileに開発することは不可能。
つまり、開発チームが実現できるイテレーションの長さには平均完了日数という制約がある。
リーンソフトウェア開発を運用したいなら、毎日リリースするわけだから、平均完了日数が1日以下にならなければ、そもそも実現できないだろう。
ここで、アジャイル開発と品質管理の関係: プログラマの思索にも書いたように、「アジャイル開発はMTTRを重視している」意見もあるらしい。
リファクタリング、テスト自動化、継続的インテグレーション等のプラクティスは、保守性という品質を高めてソースを修正しやすくすることを目指している。つまり、バグ修正工数と言うMTTRを短くすることにも注力していることにつながる。
平均完了日数が長いシステムは、経験的に品質が悪いように思う。
簡単に直せるバグに必要以上に時間をかけてしまうわけだから、作業効率が悪くなっているのだろう。
例えば、たくさんのバグが発見されてチケットが乱発されてしまって、チームが混乱してしまい、作業効率が悪くなっている状況があげられるだろう。
個人的には、Redmineでも「最大放置日数」「平均完了日数」をプロジェクト単位、イテレーション単位に集計表示してくれると面白いだろうと思う。
チケットの「最大放置日数」「平均完了日数」はシステムの品質とプロジェクトの生産性を映し出す鏡だからだ。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- 「System of Systems(SoS)の統合テストは不可能だ」という言説を聞いた(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- 脱PDCA!DXを加速する超高速戦略「KillChain」(2026.08.10)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
「チケット駆動開発」カテゴリの記事
- 人の成果物は品質基準に不足しすぎるが、AIの成果物は品質基準を超過しすぎる(2026.08.16)
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- Redmineのブロッキング機能はどこで使うのか?~FF関係で使うべきだ!(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- 製造業でアジャイルが定着しない理由~スプリント不在とチケット二重管理の壁 #Redmine(2026.07.18)
「Agile」カテゴリの記事
- チケット駆動でAIを制御する仕組みのアイデア(2026.08.13)
- アジャイル開発を強化するキルチェーン進化の歴史~VUCA時代におけるモノづくりの新アーキテクチャ(2026.08.11)
- 脱PDCA!DXを加速する超高速戦略「KillChain」(2026.08.10)
- AIエージェントのハルシネーションは「チケット駆動」で防ぐ~次世代アジャイル開発の実践論(2026.08.04)
- AIが設計も思考も代替する時代ではエンジニアはモデルを理解するだけの存在なのか?(2026.07.25)


コメント