Google Chartを使ったプロジェクトの可視化
Tagged:  •    •  
はじめに

ASCADEでは以前から成果物の量を取得して査定のデータに使用したりしています。
基本的に全ての成果物はプロジェクトごとのリポジトリで管理されているので、データの収集もスクリプトを用いて収集します。誰がある期間内にどの程度の成果物を作成したかは基本的には自動でわかるわけです。
ただ、数値を取得すること自体は簡単なのですが、数値の羅列がたくさんあっても、「状況」はわかりにくくて、可視化したいと思いつつ放置していました。

ところが最近、Google Chart APIが公開され、見てみると使い方も簡単そうなので可視化に取り組んでみることにしました。

やってみたこと

色々とやりたいことはあるのですが、まずは以下の2つに取り組んでみることにしました。

1. 作業負荷状況と変化
基本的には成果物を大量に作成しているのは作業負荷が高いときです。
個々のメンバーの作業負荷状況と一定期間内での変化をグラフ化してみます。
2. 成果物の合計と変化
作業内容は最終成果物に残るとは限りません。レビューなどの結果、不要と判断され削除されたりもします。
最終成果物の量がどのように変化していったかと、それに占める各作業者の割合をグラフ化してみます。

なお、成果物はソースコードに限定し、その量はステップ数で表せるものとします。これで、プロジェクトの作業状況や効率がある程度可視化できるのではないかと思います。

実際の作業は、以前から社内で使用しているCVSリポジトリ用の数値取得スクリプトを元に修正し、Google Chart URL の生成は pythonで新たに書いてみました。(というかPythonの習得のためにこれをやったようなものなのですが)

ちなみにASCADEでは構成管理の主流は Mercurial になりつつあります。今回は、過去の(CVSでおこなわれた)プロジェクトのデータを見てみたかったので、CVSをターゲットとしてみました。

1. 作業負荷状況と変化

各自の作業量は、CVSのログを解析することでわかります。
コードの削除についてはグラフ化対象としません。新規追加の場合はログには直接記録されないので、r1.1のステップ数を取得します。

作成したスクリプトは複数のファイル群で構成されています。以下に全体の構成と各スクリプトの動作概要を示します。
なお、動作確認は Linux でおこないました。

スクリプト群の構成
  # HTML作成用メインスクリプト
  genWorkloadChart.sh config-file unit start-date end-date
    標準出力にHTMLを書き出す

  # TSV作成用メインスクリプト
  genWorkload.sh config-file unit start-date [end-date]
    config-fileに記載された内容にしたがってCVSからデータ
    を取得し、標準出力にTSVデータを書き出す

  # CVSログからTSVデータを生成するスクリプト
  analyzeModifyData.awk module-name range-start range-end
    標準入力からCVSのログデータを読み込み、指定された
    range期間における作業状況を標準出力にTSVデータと
    して書き出す

  # Google Chart URL生成用スクリプト
  genWorkloadChart.py unit start-date [end-date]
    標準入力からTSVデータを読み込み、標準出力に Google
    Chart用のURLを書き出す

  # データ取得用設定サンプル(CVSで対象とするターゲット等)
  config.sample.rc
各スクリプトの概要

スクリプトはtar+gzip形式でまとめましたので、興味がある方はダウンロードしてください。動作の詳細はソースを見てください。(つぎはぎなので見づらいとは思いますけど)

まず、あるプロジェクトにおける負荷状況を月毎にグラフ化してみます。

注: 掲載にあたって生成したURLの一部を修正してありますが、基本的な部分はそのままです

$ /bin/sh genWorkloadChart.sh ./config.sample.rc \
      1month 2005-09-01 2006-05-31
WORKLOAD SUMMARY 2007/12/26
1ヵ月毎の負荷状況

もっと詳細に見たい場合は、1週間単位でグラフ化することもできます。

$ /bin/sh genWorkloadChart.sh ./config.sample.rc \
      7days 2005-10-01 2005-12-02
WORKLOAD SUMMARY 2007/12/26
1週間毎の負荷状況

現在のスクリプトではx軸(時間)が9個ほどあると、もっとも収まりの良いグラフが作成されます。自動調整は可能ですが、その辺りはさぼっています。

年間のグラフを見ると、tarouを中心として前半に集中して作業がおこなわれていることがわかります。特に10,11月に基本的な部分の作り込みがおこなわれているようです。また、05/11/19の週は大量にコードを登録していることがわかります。ichiroはメンテナンスのために参加した人で、後半に少しだけ作業しています。

2. 成果物の合計と変化

今度は CVS annotateコマンドを使用して、ある時点での最終成果物と各作業者の割合をカウントします。
annotateで取得したデータが元になっていますので、途中でどんなに大量に作成していてもレビューなどで不要と判断され削除されると、最終成果物は0となります。
なので、頑張って作業して大量に成果物を作成していても最終的な成果物への貢献度は(単純な量だけだと)低いということがありえます。

これもスクリプトをまとめましたので、興味のある方はダウンロードしてください。基本的な構成は負荷状況測定用のスクリプトと同じなので、ファイル構成は省略します。

先ほどと同じプロジェクトにおける変化を月毎にグラフ化してみます。

$ /bin/sh genArtifactsChart.sh ./config.sample.rc \
      1month 2005-09-01 2006-05-31
ARTIFACTS SUMMARY 2007/12/27
1ヵ月毎の成果の合計

基本的には負荷状況に応じて成果量も増えているのがわかります。全体の進捗を確認する場合は、この方が見やすいかもしれません。

ちなみに、よくよく数字を見ると、作業負荷で出てくる数字の合計よりも、このグラフでの最終成果物量の方が少なくなっています。これは、前述しましたようにレビューや仕様変更などの結果、削除された分です。このプロジェクトでは2割近くがそのようなコードでした。

まとめ

グラフとして可視化することで、単なる数値の表よりも変化がわかりやすくなりました。やはり、プロジェクトの状況をモニタリングする際はこのようなグラフが有ると無いとでは大きく違います。
データの生成に時間がかかるのが難点ですが、スクリプトの最適化(無駄な処理が結構あるはずです)や、定期的に短い期間の差分を追加していくようにすれば問題とならないでしょう。

機会があれば、Mercurial対応やTrac等のプロジェクトポータルへの組み込みを公開したいと思います。

補足

実際にこのスクリプトを使ったグラフを元にしてプロジェクトの状況を確認する際は、以下のことに注意してください。

  • CVSには幾つかの弱点がありますが、ファイルの移動を追跡できないという致命的な問題があります。
    ディレクトリ構成の変更でファイルを移動すると、最終成果物の量は変化しませんが、(移動後のファイルが新規扱いとなるので)作業負荷の数値に影響があります。やはり、もっとまともな構成管理ツールを使うべきでしょう。
  • 外部からリポジトリへソースを取り込む際は、アカウント名に気をつけるべきです。
    取り込み用のアカウントで作業をおこなわないと、本当に書いたものか、単にコピーしただけなのかがわからなくなります。
  • 全体を見るだけでなく、システムを構成する個々のパッケージ毎の傾向も見てみるべきです。
    特定のパッケージで、作業負荷は高いのに最終成果物の量は増えないといった状況が見られることがあります。このようなパッケージは要注意です。