BTSをBusiness Intelligenceとして使う

チケット駆動開発の戦略part3として、BTSをソフトウェア開発のBusiness Intelligenceとして使うアイデアをメモ。
#走り書きなので後でまとめる。

元ネタは、下記の記事。

Mantisのバグ情報から信頼度成長曲線作成ツール

SRATS取り扱い説明書

【1】Web2.0の重要機能「足跡」をプロジェクト管理に応用できないか？

ソフトウェアメトリクスの測定には、大きな障害がある。
それは、メンバーがプロジェクトに関する様々なデータを「入力する手間」が発生することだ。
ソフトウエア開発プロジェクトはただでさえ忙しいから、入力するデータの質は落ちやすい。

だから大手SIや銀行では、上からの命令で15分おきに生産性を入力させるような運用もしている。
つまり、彼らは従業員の実績をリアルタイムに管理したがっている。
でも、ソフトウェア技術者である僕らは奴隷じゃない。
トイレに行く時間まで管理されたくない。

Web2.0システムは、作業ログを自動収集して、色んな観点から統計結果を見せる機能がふんだんにある。
つまり、緩やかに作業ログを収集する仕組みが洗練されている。
しかもRSSなど、収集したログを集計した最新情報を自動配信する機能さえある。

この機能は、小売系WebシステムやMixiなどのSNSでは当たり前の機能だ。
データマイニングをマーケティングの一手法として使う。

例えば、レコメンドエンジンとは、eコマースサイトでよく見られる「これも一緒にいかがですか？」と関連商品を表示する機能を実現したものと言える。

特に、Amazonの最大の特徴は強力なレコメンデーション機能にあると言ってよい。

例えば、Amazonのレコメンデーション機能は協調フィルタという有名なアルゴリズムが使われている。

PVや画面遷移の履歴は簡単に採取できる。
例えば、PVや画面遷移の履歴、購入履歴から、購入画面や注文画面へ誘導するする設計を取ることもできる。
これを使って、購入履歴から売れ筋の商品をリンクさせる機能も追加できる。
この機能は、商品購入時に関連商品を表示させて、商品のレビュー履歴から関連商品をお勧めさせたいのだ。

Googleの検索エンジンのアルゴリズムpageRankも同様の発想だ。
つまり、どのHPが一番検索されて有用か？を検索履歴から集計して最新情報を常に反映させる。
これによって、商品を検索した時、特定のHPに誘導することさえできる。

mixiのようなSNSの足跡機能も同様。
特定の人へのアクセスログから、友人関係の距離を計算できる。
ここから、「スモールワールド」「世界中の任意の人とは6人の人間関係を経由すれば必ずアクセスできる」などのような社会科学の研究にもつながる。

しかも、これらの機能は、Google、Amazonのように、マッシュアップのおかげで多様なWebサービスが誰でも簡単に作れる。

この機能を更に進化させた概念がいわゆるBI(Business Intelligence)だ。

IT用語辞典では、BIは下記で説明されている。

業務システムに蓄積される企業内の膨大なデータを、分析・加工して、企業の意思決定に活用しようとする手法。
ERPパッケージやCRMソフトなどからもたらされるデータの分析を専門家に依存せず、経営者や社員が必要な情報を自在に分析し、経営計画や企業戦略などに活用することを目指す。

この機能は、マーケティングを生かした商品開発、ビジネス上の経営判断に使える。
この機能をプロジェクト管理にも使えないだろうか？

【2】BTSのチケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にする。

ソフトウェアメトリクスを採取する話では、いつも「計測できないものは制御できない」というケルビン卿の話が良く出る。
つまり、ソフトウェア工学とは、ソフトウェア開発プロセスの定量化が目的の一つなのだ、と。

ソフトウェア・リポジトリ・マイニングは、ソフトウェア開発履歴からのお宝発掘。
　　SVNコミットログ
　　BTSチケット履歴
　　ビルド履歴
　　メーリングリスト
から、プロジェクトの状態、ソースの状態、作業の状態をリアルタイムに見える化する。

管理者がやりたいことは、BTSのチケット集計結果にソフトウェア工学の知識を応用して、プロジェクトのリスクをいち早く感知したいこと。
Redmine/Tracのようなプロジェクト管理機能を持つBTSは、プロジェクトのセンサー。

プロジェクトリーダーは、リアルタイムに出力されるBTSのソフトウェア・リポジトリ・マイニング機能を使いこなせれば、プロジェクトをモニタリングしながら、リスクを即座に察知できるはず。

チケット集計結果から、信頼度曲線を出力できれば、後どれくらいの工数で品質が歩溜まりに達するか分かる。
garyoさんのRubyプログラムを使うと、Mantisの出力CSVから、信頼度曲線を作ることができる。

更に、SRATSというフリーの信頼性評価ツールにチケット集計結果を食わせると、下記を出力できる。
　
2-1.Total: 対象とするソフトウェアに潜在する総フォールト数

2-2.FFProb: 現時点で対象とするソフトウェアにフォールトが存在する確率

2-3.MTBF: 次のフォールトが発見されるまでの時間

2-4.Be X Life: 次のフォールトが発見される確率が０．９となる時間
（その時間までに１つ以上のフォールトが発見される確率が９割）

情報処理試験で習ったMTBFの概念は、ハードウェア障害だけでなくソフトウェアの障害まで当てはめることができる。

この数値をプロジェクト終了後にメンバーと一緒にKPTを行えば、何が問題だったのか、次のプロジェクトでは何を試せばいいか、メンバー自身を自然にプロセス改善に誘導できる。

BTSを有効活用すれば、プロジェクトをこなすたびにメンバーを成長させるきっかけにできるはずだ。