Redmineカスタマイズ事例：プロジェクト作成単位
Redmine運用が開始出来たので、カスタマイズや運用の事例をまとめておく。まずは「プロジェクト（およびサブプロジェクト）をどういった単位で作成したか？」について。
今回は以下2点のルールとした。
- 運用チーム主体ごとにプロジェクトを作成する
- 大規模な仕様変更の場合はサブプロジェクトを作成する
運用チーム主体ごとにプロジェクトを作成する
ものの本や記事を見ていると、アプリケーション単位でプロジェクトを作成するのが常道っぽい。当初このルールに従って3つのプロジェクトの作成しようと考えていた。（アプリケーションA, B, Cとしよう。）
しかしアプリケーションBは（SAPのERPパッケージなのだが）ユーザに画面を開放しておらず他システムとデータインターフェースに使用する中間システムとして機能している。そのため、このアプリケーション単独で問合せ等が発生することはなく、案件管理はこれまでもアプリケーションAのメンバ（僕を含め）が主体となって実施しており、Bのメンバは実作業者のみで構成していた。
そのため、アプリケーションAとBをプロジェクトとして分けてしまうと進捗確認時にはAプロジェクト、Bプロジェクトの双方を見なければならないため非効率的になってしまう。ということでアプリケーションAとBは同じプロジェクトとした。*1
一方アプリケーションCはアプリケーションの特殊性ゆえ自社メンバではなく外部ベンダが主体となり、僕が進捗管理、品質担保、および顧客との調整を行うのみ（実作業は外部メンバに一任）となっている。そのため、AとBに比べて独立性が高いので別プロジェクトとした。
という風に、「誰が運用の主体になるのか」によってプロジェクトを分割してみたが、今のところ上手くいっている。基幹システム系であれば多くないと思うが、それ以外のシステム領域（税金計算、品質管理など）であれば小粒のシステムが乱立しているという状況もしばしばあると思われるので、そのようなときに愚直にシステムごとにプロジェクトを作成する必要は必ずしもないだろう。
大規模な仕様変更の場合はサブプロジェクトを作成する
上記のようにプロジェクトはいったん2つに絞ったが、大規模な仕様変更が発生した場合はその主体プロジェクト下にサブプロジェクトを作成することとした。サブプロジェクトを作成するか否かの定義は敢えて明確に定義していないが、工数、プログラム本数、担当人員数などで適宜判断することとしている。特にメインで実改修を行う人員が複数になるのであればサブプロジェクトを設けてよいかと思う。
サブプロジェクトを作成することによる利点は以下2点だろう。
- サブプロジェクトのチケット情報を排除して統計情報、一覧を取得しやすい
- サブプロジェクト単独での統計情報を取得しやすい'
特に2点目の意味で、完成率やEVM情報を簡単に取得出来るというのは開発管理としては大きな利点になる。
一方で、デメリットとしては、サブプロジェクト自体はチケットとしてカウントされないため、上記のようにサブプロジェクトのチケット情報を排除して統計情報を取得するとサブプロジェクトにした案件分の情報が欠如してしまい、不正確な情報になってしまうという問題がある。この点はちょっと面倒なのだが、親プロジェクトに別途サブプロジェクトの案件に相当する案件をチケットとしても起票しておき、ステータス項目のみそのチケットで管理するということにしている。そうすればサブプロジェクトの情報は無視して報告しても統計情報として問題ないサマリが手に入る。
*1:別フィールドでアプリケーションAとBを区別する情報を持たせてもいいと思うが、今のところは用意していない。
