プログラマの思索

@akahane92さんのSQIP2014発表資料「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がついに公開された。
Redmineを、SIerのソフトウェア保守のうち、内部統制に適用した事例になる。

【元ネタ】
本会議2日目 9/12 | ソフトウェア品質シンポジウム 2014

本会議2日目　9/12 講演テーマ・講演者紹介　【経験論文】 「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証
赤羽根　州晴　氏 | ソフトウェア品質シンポジウム 2014

赤羽根　州晴　氏　発表資料「「効率・品質・統制」の共通課題に着目した現場主導によるITS導入の効果検証」

赤羽根　州晴　氏　 経験論文「「効率・品質・統制」の共通課題に着目した現場主導によるITS導入の効果検証」

【1】@akahane92さんの論文のストーリーは以下で理解している。

SIのソフトウェア保守において、内部統制の諸問題として、実際は完全性、追跡性、効率や品質などの問題がある。
そこで、RedmineというITSを適用することを着目し、さらにチケット駆動開発の運用ルールを適用してみた。
その結果、チケット完了率が高くなった、チケットの完了所要日数が短くなった、さらに重大な障害件数の減少などの効果が得られた。

【2】上記の論文で興味深い点はいくつかある。
最も興味深いのは、Redmineの運用から得られた定量データだ。

個人的に興味深い点は、ITS運営の定量的メトリクスとして、「チケット完了率，チケットスループット（完了所要日数の平均と分布），添付ファイル指数，説明欄文字数（平均），チケット密度」があげられている点だ。

チケット累積枚数：約12万枚
チケット発行数：約3千枚/月
チケット完了率：93％

この数字を見ると、1日約150枚のチケットが起票されているから、かなりの頻度だ。
これほど大量のチケットが登録されると、チケットが放置されやすいリスクがある。
しかし、チケット完了率が93％という数値を見ると、発行したチケットは最終的には9割以上は完了ステータスでCloseされている。
これはすごい。

僕の経験では、現場ごとに違うけれども、チケットは放置されやすい。
チケット管理が上手くないチームは、1年以上も放置されたチケットがあり、誰もその内容が分からなくなり、手を付けられなくなる。

【3】では、チケットが完了されるまでに、どれだけの所要日数がかかっているのか？

2週間以内に発行チケットが完了：全体の50％
3ヶ月以内に発行チケットが完了：全体の80％
チケットの平均完了所要日数：44日

この数字を見ると、発行されたチケットの半分は2週間で消化されているから、かなり作業効率が良いと思われる。
「チケットの平均完了所要日数」は、リードタイムそのもの。
つまり、チケットの発行日から完了日に至るまでの経過日数の平均。
リードタイムが長い場合、チケットが放置されている状況を示す。
上記の定量データでは、平均完了所要日数は44日だが、中身にはばらつきがある。

僕の経験では、ソフトウェア保守ではなくソフトウェア開発になるが、4人で1ヶ月50枚というVelocityの案件があった。
その案件は作業効率も良く、チームの雰囲気も良かった。
たぶん、赤羽根さんの現場も、チケットのやり取りのおかげで、かなり活発に作業されているのだろう。

ここで重要なメトリクスとして、「チケットスループット」(作業効率)が出てくる。
「チケットスループット」という概念は、リーンソフトウェア開発に出てくる「サイクルタイム」と似てる気がする。
TOCっぽい。
すごくインスピレーションを感じる。

【4】Redmineが今後発展する方向のアイデア: プログラマの思索にも書いたけれど、チケット駆動開発から得られるメトリクスの知見を一度整理したい。
ソフトウェア工学の歴史では、メトリクスの研究は1970年代から信頼度成長曲線など、たくさんのメトリクスが発見され、調査されてきた。
しかし、実際の現場ではほとんど知られていないし、使われてもいない。

その理由は、メトリクスが得られても現場では効果が余り得られないというメトリクスの罠もあるが、メトリクスの収集コストが高かったこともあるのではないか？
Redmineではチケットにデータが集約されるから、好きなだけメトリクスを出力することができる。

Redmineから得られるメトリクスにはどんな種類があり、どの場面で効果的なのか？
その内容を整理してみたい。