3年使ったRedmineの使い方について共有したい10のこと

orcmid via flickr

前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。

1. Redmineのオブジェクト構造を理解した方がいい

Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。

プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ

注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考えるとよいです。

2. プロジェクト名は「プロジェクト」か「組織」がいい

プロジェクトには期限がないため、例えば、「○○チームのタスク管理」といったものを作ることができます。しかしながら、普通に「○○プロジェクト Phase1」「○○プロジェクト 2010 1Q」という名前をつけてもいいと思います。両者を比べてみるとどうなるでしょうか？

期限なしのプロジェクト名をつけると・・・
- ○ チケットが集約されるので管理がしやすい
- × 徐々にチケットが増えると検索が重くなってしまう
期限ありのプロジェクト名をつけると・・・
- ○ そのプロジェクトの情報のみを集約できる（情報制度UP・検索速度UP）
- × プロジェクトをアーカイブ化したときに検索できなくなってしまう
- × 分け方に注意しないと細かいプロジェクトがたくさんできてしまう

などなど。一長一短であることがわかりました。

私の経験では、プロジェクトを分けすぎて失敗し、「○○チーム2010」のような組織＋年としてみて、年をまたぐチケットで困った経験があるので、シンプルに「○○チーム」という閉じないプロジェクトを作って運用しています。チケットの増加による検索遅延を防ぐために、「過去の思ひ出」というプロジェクトを作り、定期的にチケットを移動しています。

自分の会社がプロジェクトベースの管理をされている場合は、プロジェクト名をつけたほうがフィットするでしょうし、サービス開発のようなインクリメンタルな開発の場合は、組織名やサービス名で作るとよりアジャイルを意識する形になります。