Web2.0時代のプロジェクト管理

「Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド」を読んでインスピレーションを得たこと、下記のBlogで得たヒントを書く。

【元ネタ】

Trac入門というより、新しい時代のプロジェクト管理入門　Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド

Web2.0時代のバグ管理ツールを作る

【1】Excelによるプロジェクト管理は、紙を使った前近代の管理とBTSを使うWeb2.0時代の管理の過渡期の手法

本番リリース後にお客から障害発生が通知されたら、その履歴をきちんと管理するために、バグ管理するだろう。

そういう管理すらないプロジェクトでは、障害の事象や、その修正状況を共有するインフラが無い。
「今問題となっている障害は、障害管理番号XXX番のことですよ！」と一言言えば済むのに、一意に降られた番号が無ければ、最初から逐一説明しないといけない。

つまり、バグ管理IDを一意に採番することで、問題事象をメンバーと共有できる。
バグ管理IDがなければ、哲学の認識論争から始まる。

だから、以前なら、Excelの別シートでバグ管理IDを手動で採番し、決められたフォーマットに書いていた。
今のBTSは、バグ管理IDの採番はチケットを新規に起票する時に自動処理してくれる。

【2】BTSを使う利点の一つは、強力なデータマイニング

BTSがExcelよりも強力なツールとなる利点は、信頼度成長曲線のようなソフトウェアメトリクスを生成できることだ。
プロジェクトリーダーは、これらのソフトウェアメトリクスをビジネスインテリジェンス(BI)、つまり、プロジェクト運営の意思決定の一手段として使いたい。

しかし、実際の運用では、ソフトウェアメトリクスは評判があまりよくない。
よくよく聞いてみると、バッドノウハウがすごく多い。

下記の記事にその理由が書かれている。

Web2.0時代のバグ管理ツールを作る（第3回）
バグ成長曲線をどこまで信じればよいのか

バグ修正の時間が経つにつれて、バグ収束曲線のような右肩下がりに寝るようなグラフに実際はなかなかならない。
突然の仕様変更やトラブル対応に追われたり、進捗が均一でないなどの理由があるだろう。

だから、テスト担当者は、バグ収束曲線の理想形に合わせるようなテストケースを作ったり、テストの順番を考慮に入れたりするらしい。
でも、これらはバッドノウハウに過ぎないと思う。
おそらく使い方が間違っているように思う。

昨今の小売系のシステムでは、データマイニング機能は普通の機能だ。
コンビニのPOS、Amazonの関連商品を表示するレコメンドエンジン、iTunesのお勧め曲の表示などの実例が示すように、データマイニングは販売の強力な機能だ。

そこからヒントは得られないだろうか？

【3】BTSを変更管理、インシデント管理、要件管理にも適用する

BTSは元々、バグ管理、つまりITILで言う問題管理が対象だった。
しかし、最近は課題管理システム(Issue Tracking System)としてBTSを運用する流れが主流になりつつある。
つまり、チケットをバグ管理票だけでなく、ソフトウェア開発の日々のタスクとして管理・運用することだ。
その筆頭がTracであり、Redmine。

最近は特に、問題管理だけでなく、変更管理もBTSで運用することが普通だろう。
変更管理は、RFC(変更要求)が発生して初めて稼動する業務フロー。
つまり、仕様変更や新しい機能の開発だ。
Redmineなら、Patch、Featureというトラッカーに相当するチケットだ。

変更管理の状態遷移図を描いてみると、問題管理のそれと殆ど同じか、全く同じだ。
だから、BTSを拡張するのは簡単。

だが、インシデント管理や要件管理は、問題管理の業務フローにはそのままでは乗せにくい。
だから、BTSを工夫する必要がある。

Redmineならどのように工夫するか？

Redmineには、プロジェクト単位でフォーラムやWikiの機能がある。
だから、顧客からの些細な要望や単純な問合せは、フォーラムでチャットのように受け取り、そこから重大と判断したインシデントはチケットにRFCとして登録するやり方がある。

あるいは、インシデント管理用のトラッカーを作り、新たな業務フローを作る。
Redmineは、ステータス・トラッカー・ロールをいくらでも追加できるので、インシデント管理特有のフローをカスタマイズしてしまえばよいだろう。

要件管理では、チケットの階層化が重要だ。
この話は八朔さんから教わった。
一つの要件管理IDから、複数の仕様に分かれて、そこから更に実装タスクが発生する。
つまりチケットの階層が3層構造になっている。

Redmineでは、チケットのリンク機能が充実している。
「関連する」「重複する」「先行する」「ブロックする」の4種類があるので、使い分ければよいと思う。

【4】難点は、今運用しているプロジェクトの業務フローをBTSへ乗せることができるか？

でも実際のプロジェクトの全ての業務をBTS上に乗せるのは難しいだろうと思う。
問題管理、変更管理は簡単に乗せれるけれど、実際のプロジェクトでは様々な雑用が発生する。
それら雑用はどんなフローで書けるのか？

結局の所、我々SIerに従事する開発者は、ソフトウェア開発の業務フロー分析ができていないだけなのだ。
お客様のビジネスの業務分析はするのに、自分たちの会社、自分たちのプロジェクトの業務フローを明確化していないだけ。

そして、我々SIerでは、同じ会社なのに、プロジェクトごとに業務フローが大きく異なることも多いだろう。
そんなレベルでは、プロジェクト管理という言葉すらも定義できていないだろう。

まずは、自分たちのソフトウェア開発の業務を分析し、フローを洗い出すことが先決なのかもしれない。