プログラマの思索

第2回Lychee Redmineユーザ会で、MSProjectのようなガントチャート運用のようにRedmineを使っている事例の資料があったのでメモ。

Redmineが日本企業に受入れやすい理由の一つは、従来のWF型開発でガチガチのガントチャート管理をチケット管理で実現しやすいためだろう。
なぜなら、親子チケットで階層化すれば、WBSをそのまま実現できるからだ。

しかし、Redmine標準のガントチャートでは、予実管理までの機能はなく、MSProjectに付随しているベースライン管理、リソース管理、PERT図のような機能まではないから、MSProjectをバリバリ使っているプロジェクトリーダーの観点では不満があるだろう。

上記の資料では、Lycheeガントチャートという有償プラグインを導入することで、MSProjectの大半の機能をRedmine上でも同様に利用することで運用しようとしている。

興味深い点は3つある。

一つ目は、 開発プロセス用トラッカーは、測定項目を共通化し4種類に集約していること。
明示されていないけれど、分析、設計、実装、検査の項目と思われる。
一般にプロセスをトラッカーにするのはあまり推奨されていないけれど、小規模チームならば問題ないと思う。
個別PJだけのチケット管理の運用ルールに特化しているから。
つまり、チームの運用に合わせるようにRedmineを当てはめて、タスク管理をスムーズに実行することを目的としているから。

2つ目は、チケットの基本項目や測定項目を全て必須入力とし、工数、検査項目数、NG数などの入力漏れを無くし、 承認待ちステータスを入れて責任者が最終確認して完了する運用を徹底したこと。
たぶん、完了したタスクに対し、設計プロセスで仕様漏れが発生していないか、その使用漏れが後工程まで引きずっているか、というメトリクスも収集し集計したい意図があるのだろう。
特に、組込み製品開発では、後工程の手戻りがあるとコスト増加に大きく響いてしまうから。

また、承認ステータスを入れることで、「いつの間にかタスクが完了していた」という事態をなくせる。
おそらく、必ずプロジェクトリーダーの承認を経てタスクをクローズする運用を徹底することで、当初の計画通りに成果物が作られたのか、という検査をきちんと記録に残すことができ、システム監査で説明できる資料にしたいためだろう。

3つ目は、 ベースライン保存機能で保存したスケジュールのスナップショットと、現在のスケジュールを同時表示 し、スケジュール変更前後を比較可能とし、打ち合わせ時にチケット棚卸しを実施していること。
MSProjectでは、基準計画という機能があり、たとえば顧客都合の仕様追加でリスケが発生したら、リスケ前とリスケ後のスケジュールを別々の保持する機能がある。
この機能を使えば、リスケ後に、顧客に、これだけの工数が追加したので別請求で代金を支払って下さい、と請求できる根拠を示せる。
また、開発者にも、リスケ後にこれだけ工数が追加で発生したと説明できるし、どれだけの実績工数の差異が発生したのか、を追跡できるようになる。

一般に、受託開発案件は一括請負契約が多いので、こういうスコープ変更に伴う追加代金の請求の根拠となる資料はとても重要だから。

上記の資料ではオフショア開発にRedmineを展開していたようなので、資料に書かれていない内容でたくさんの苦労があったのではないか、と勝手に想像する。

こういう資料を読んでいると、日本のSIではPJ管理にすごく苦労しているんだろうな、と感じる。
資料の背後に隠されている泥臭い作業をイメージできてしまうから。

できれば、開発チームのメンバーのフィードバック、開発チームや開発プロセスの効果も聞きたかかったな。

Redmineがそういう作業を全て解決できるか否かは分からない。
でも、そういうPJ管理の問題点が見える化されることで、根本原因は何か、真の解決策は何か、を考えるきっかけになる気はする。
そういう問題点、根本原因を明確にすることで、解決策がメンバーと共有されて、解決されていくと思うから。