チケット駆動でソフトウェア開発のメトリクス分析を行うアイデア

チケット駆動開発でソフトウェア開発のメトリクス分析を行うアイデアをメモ。
以下はラフなメモ書き。
アイデアをラフに書いているだけなので、ロジカルではない。

【参考】
Cumulative Flow Diagram(CFD)：タスク全体の推移を「見える化」する - THE HIRO Says

完了率：本当に完了・リリースできた機能を「見える化」する - THE HIRO Says

割込率：作業の割り込みを「見える化」する - THE HIRO Says

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

現場実践主義としてのリーン開発とアジャイル from Rakuten, Inc

【1】問題意識

Redmineでソフトウェア開発に関する作業管理を運用すると、チケットで見える化されるが、何か物足りない点がある。
RedmineにチケットやSVNリポジトリの情報が溜まっているのだから、それらデータを分析して、目の前のプロジェクト、目の前の開発チームに何が足りないのか、何が悪いのか、を探りたい。
しかし、今のRedmineでは、チケットというデータは溜まっているが、どんなメトリクスが役立つのか、どんな分析方法が役立つのか、が分からない。

その問題点は、二つあると思う。
一つは、ソフトウェア開発のメトリクスに必要な作業情報をそもそも収集するのが難しい、あるいはコストがかかり過ぎること。
もう一つは、メトリクスや分析手法などの理論の前提と、実際のソフトウェア開発の制約条件が一致しているとは限らないこと。

ソフトウェア工学の歴史が短いと言っても、既に40年近くの蓄積があり、CMMIやPMBOK、アジャイル開発などではそれなりの情報があると思う。
しかし、実際の現場で使われているとは言いがたい。
その理由は、ソフトウェア開発が汎用機、クラサバ、Web、モバイル、クラウドなどへどんどん変化していくために、それら開発のデータを収集したとしても、理論が前提とする制約条件に合致しない状況が多いのではないか？

CMMIは理論としては良いことは言っているにも関わらず、なかなか現場で身に付かないのは、現場の制約条件に合わせて落としこむ部分が難しいのだろうと想像する。

そんなことを考えると、Redmineに溜まったチケットデータがあったとしても、それを上手く使う方法や、分析の前提条件をきちんと整理しなければ、使いものにならない。
本当は、ソフトウェア・リポジトリ・マイニングのように、せっかく溜まったRedmineチケットを有効活用したいのに、メトリクスや分析手法、その効果がきちんと整理されていないように思う。

【2】損益計算書・貸借対照表から経営分析する手法の事例

チケット駆動開発でソフトウェア開発のメトリクス分析を行うアイデアとしては、損益計算書・貸借対照表から経営分析する手法に似たようなものになるのではないか、と思う。

例えば、経営分析では、企業が四半期ごとに提出する損益計算書・貸借対照表を元に、各種の経営分析のメトリクス(経緯指標：KPI)は既に知られている。

経営分析指標

決算書の読み方・財務分析のしかた

総資本利益率（ROA）が経営分析指標の重要な数値で、ROA＝売上高利益率/総資本回転率になる【どもども遠田幹雄BLOG】

経営分析では、収益性・安全性・生産性・返済性などの観点の指標があり、この企業は本当に儲かっているのか、将来も安全なのか、効率的な経営がされているのか、投資したお金や借金の利息をきちんと返してくれるのか、を見る。

銀行や株主、投資会社は、企業のPL・BSを元に、各種の経営指標を計算し、自分たちの投資に対して十分な利益(リターン)が出ているか、を調べる。
中小企業診断士のような経営コンサルタントは、もし、利益が低ければ、どの指標が悪いのか、を洗い出し、どこを改善すべきか、を診断してくるだろう。

すなわち、経営指標は、飛行機の操縦室にある数多くの計測器と同じであり、飛行機が安定飛行できているか、どこに異常が発生しているか、を検知するために存在する。
同様の発想をソフトウェア開発のメトリクス分析にも適用できないか？

【3】チケット駆動のメトリクス分析の観点

例えば、経営指標と同じような観点でソフトウェア開発を考える場合、収益性・安全性・生産性の観点を応用できないか？
経営指標は下記の観点がある。

収益性・・・投資した資本に対し、どれだけの収益が出ているか？
安全性・・・借金を返す能力はあるか？
生産性・・・労働者1人当りの生産性は高いか？

経営指標の観点をソフトウェア開発に適用した場合、下記のイメージになるだろうか。

収益性・・・投下した工数に対し、どれだけのアウトプットを作り出し、リリースできたか？
安全性・・・潜在バク、リファクタリングすべきソース、古くなったアーキテクチャを改善する能力はあるか？
生産性・・・労働者一人当たりの生産性は高いか？

従来のソフトウェア開発のメトリクスの場合、安全性と生産性の観点はすごく多い。
信頼度成長曲線、バグ密度、テスト密度などの品質、EVMなどのコスト管理のメトリクスは既に知られている。
しかし、収益性という観点が不足していないか？
確実にリリースできているか、リリースしたソフトウェアが売上に貢献しているか、という観点では弱いのではないか？

その弱点を補充するかのように、最近のアジャイル開発では、収益性という観点で、各種のメトリクスが提唱されているように思える。
メトリクスによる「見える化」のススメ: エッセンシャル・リーンでは、CFD、スループット、サイクルタイム、リードタイムが、アジャイル界隈では人気のあるメトリクスだ、と言っている。
チケット駆動のメトリクスとして有効である例としては、Velocity、サイクルタイム、リードタイム、チケット完了率(スループット)が挙げられるだろう。

収益性という観点では、Velocityやチケット完了率、生産性という観点ではサイクルタイム、リードタイムが挙げられるかもしれない。
でも、個人的にはこれだけでは不十分。
もっと色んなメトリクスが欲しいし、それらのメトリクスをどの場面で、どのように使うと効果的なのか、が知りたいのだ。

【4】チケット駆動のメトリクス分析による効果とは

チケット駆動のメトリクス分析による効果として、不十分かもしれないが、SQIP2014で@akahane92さんが発表された経験論文が参考になると思う。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

この経験論文が優れていると思う点は、Redmineを内部統制で運用するツールとして用いることで、Redmineチケットの精度や品質がかなり良いという前提があること。
また、品質の良いRedmineチケットから、「チケット完了率，チケットスループット（完了所要日数の平均と分布），添付ファイル指数，説明欄文字数（平均），チケット密度」という定量的メトリクスを抽出できたこと。
さらに、それらメトリクスの動きから、各プロジェクト・各開発チームの作業効率や投資対効果がよく分かってくることだろう。

本当は、Redmineを使って、上記のような定量分析をもっと緻密に、理論化したいのだ。

【5】Redmineによるチケット駆動のメトリクス分析の可能性

先に、従来のメトリクス分析の問題点を2つ挙げた。

１・ソフトウェア開発のメトリクスに必要な作業情報を収集・集計するのが難しい。
２・メトリクスや分析手法などの理論の前提と、実際のソフトウェア開発の制約条件が一致させるのが難しい

僕の直観としては、この2つは、Redmineという柔軟なチケット管理ツールを用いることで解決できるだろうと思う。
1番目の収集・集計のコスト高の問題は、Redmineというチケット管理ツールのおかげで、チケット入力の運用ルールさえ徹底できれば解決できる。
チケット集計は、Redmineの一機能に置き換えできる。

2番目の、メトリクス分析の理論的前提と実際の現場の乖離の問題は、例えば、WF型開発の案件もアジャイル開発の案件も、同時に一つのRedmineで別々に管理でき、かつ、一つのRedmineで横串で集約・集計できることで解決できる。
実際、Redmineの複数プロジェクト機能、柔軟なワークフロー管理やカスタムフィールドの割り当てを使えばいいだろう。

すなわち、Redmineの機能がそれぞれの現場の開発プロセスや運用ルールを吸収できれば、それぞれの現場の特異性はなくせる。
理論的な観点では、Redmineという一つの箱にあるデータを見れば良い、という状況に置き換えられるはずだ。

つまり、柔軟なチケット管理ツールを用いることで、従来のソフトウェア工学にあるメトリクス分析の問題点は解決できるだろう。
また、本来のソフトウェア工学がやりたかった「メトリクスによるソフトウェア開発プロセスの分析」をチケット管理ツールを用いることで、注力できるはずだ。

このアイデアを元に、経営指標のような分析のアイデアを付け加えれば、Redmine上で色んなメトリクス分析を試せるのではないか、と思う。
さらに、現在のアジャイル開発が色んなメトリクス(KPI)を提案しているアイデアを流用すれば、アジャイル開発をRedmineで補強できるのではないか、と思ったりする。
つまり、Redmineをアジャイル開発の作業管理ツールだけでなく、アジャイル開発を支援するメトリクス収集ツールとして用いるわけだ。

このアイデアを実際に色々試してみたいと思う。