ソフトウェア・リポジトリ・マイニング～Web2.0をソフトウェア工学に応用する

第35回　SEA関西プロセス分科会の「フォールト・プローンネス・フィルタリング - テキストマイニングを用いた不具合検出の試み - 」を聞いた感想をメモ。
＃走り書きなので後でロジカルにまとめる。

【1】ソフトウェア・リポジトリ・マイニングによってメトリクス採取を試みる

フォールト・プローン・モジュールとは、不具合を含みそうなソフトウェアモジュール。
この分野は古くから研究されているらしい。

ソフトウェア工学の素晴らしい結果としては、信頼度曲線(バグ収束曲線)などがある。
こういう数学的に美しい結果を探したいらしい。

従来からの研究手法はモデルありき。
つまり、モデルを証明するために、たくさんの現場データを集めて、メトリクスを採取して検証する。
しかし、弱点は、従来はデータそのものの信頼性が低かった。

近年の手法はデータは自力で収集する時が多い。
特に、オープンソースの生データを使う。
例えば、Eclipse、MozillaのCVS、Bugzilla、メーリングリスト等の生データをマイニングして、新しい知見を得るのが最近の動向である、と。

しかし、マイニングは研究でない！という意見もあるらしい。
理由は、モデルと現場の双方向の行き来による検証が研究である。現場の生データありきは研究ではない、と。

水野先生は、オープンソースプロジェクトEclipseのBTSやCVSログから、メトリクスを採取するアルリズムを研究しているらしい。
つまり、EclipseのCVS、Bugzilla、メーリングリストなどのバグ情報が入ったリポジトリ４Gを解析した。
CVSコミットログで「issue #123 is fixed」があれば、fixedという単語からバグが解消されたと判断できる。
ここで、自然言語の解析アルゴリズムが使える。

この発想を使って精度の高い検出アルゴリズムを作ったと言う。

この発想であるソフトウェア・リポジトリ・マイニングこそ、Web2.0機能の真骨頂と言っていい。
情報生物学も同様の発想。
つまり、BTSでたまったチケット集計結果を、色んな観点で解析して、プロジェクトのリスクをいち早く感知したい。
生データはDBに既にあるのだから、これらを色んな観点で解析して、有用な知見を探したい。
データマイニングこそWeb2.0で最重要な機能なのだ。

小売系Webシステムでよく使われる手法は、レコメンドエンジン、pageRankなどのアルゴリズムによって、貯めたトランザクションデータからある種の傾向を吸い取り、マーケティングへ生かす。

最近は生データがオープンソースプロジェクトで公開されているから、誰でもソフトウェア工学の研究ができるのだから。

【2】ソフトウェア工学とはそもそも何なのか？

コンピュータ・サイエンスとはそもそも数学のように演繹的であるべきだと思う。
プログラムは、Yes/Noのどちらかしかないし、真偽ははっきりしている。

しかし、ソフトウェア工学は、社会科学のように帰納的手法が多い。
具体的には、現場の作業ログ、アンケートを採取して、統計的に何らかの傾向を探る。
しかし、生データそのものの信頼性が低ければ、結論の信頼性も落ちる。

一番の問題は、個人の作業や意思という独自性が集計結果からは消えてしまって、顔の見えない現場に役立たないモデルしか作れないのではないか？

ソフトウェア工学の研究は、ひたすら、作業ログを収集して集計して、常識のようなメトリクスを作るだけ。
何が面白いのか？

しかし、プロジェクトリーダーになって、ソフトウェア工学の重要性を初めて認識した。
ソフトウェア工学をプロジェクトのリスク管理に使いたいのだ。

講演の最後に、「When do changes induces fixes? (on Friday)」という論文をもらった。
論文の内容は「EclipseやMozillaプロジェクトでは、BTSログから、金曜日が最もバグ発生の頻度が高い」という結果を発表している。
まさにマイニングの成果。

この論文の似たような経験はある。
オープンソースで、statSVNというSubversionの全コミットログから、LOCなどのメトリクスを集計して出力するツールがある。

このstatSVNのレポートを見ると、デスマーチプロジェクトでは、金曜や土曜に最もSubversionコミット回数もソース変更行が多い。
　
これは、休日出勤で作業の遅れをカバーしようとすることを意味する。
週5日でできなければ、休日出勤すればいいや、という行動が出てしまうのだろう。

正常プロジェクトでは、Subversionコミット回数の山が水曜に来る。
そもそも土日や18時以降のSubversionコミットもない。

プロジェクトリーダーは、statSVNで開発者の生産性を常に見ながら、リスク管理に使える。
作業の遅れを早期に発見できれば、インタビューしたり、リスケしたり、アサインそのものを変える時もあるだろう。

BTSはプロジェクトの状態をリアルタイムに最新表示する最も効率よい仕組み。
同様に、チケット駆動開発でもBTSやSubversionにたまったログから、そのプロジェクト特有の傾向を洗い出してリスク管理にいち早く使いたいのだ。

プロジェクトリーダーはBTSを上手に使って、プロジェクト管理を効率化すべきだ。