Redmine導入、運用を失敗しないための設定のポイント

プロダクトのタスク管理にRedmine を10年ほど使い、他の部署にもRedmine の導入推進をしている。

その中で見えてきたRedmine 導入時に陥りがちな設定ミスと、中長期で使う場合に避けたほうがよい設定がある。それらを避け、Redmine 運用に失敗しないためのポイントを記載する。

今回は設定編。

運用編はこちら

運用を失敗しないためのポイント(設定編)

カスタムフィールドは最低限にする

典型的なアンチパターンとして、管理や分析用のカスタムフィールドが大量に登録され、チケット画面がカスタムフィールドで埋まっている状態がある。

こうなると入力する側としては、チケット作成のたびに多数の項目を埋める必要があり、チケット作成自体がされにくくなる。また更新するときも情報量が多くて気が滅入るので更新の頻度も下がる。こうなるとまずRedmine が定着しない。

まず重要なことはRedmine 使ってもらい定着させることだ。管理や分析に必要なカスタムフィールドは最小限にする。そういった項目はエクスポートしてからExcel などで追加し、管理、分析する方法もある。

あくまでRedmine は開発者、作業者ためのツールでFlyweight であるべきと考える。

モジュールは最低限にする

最初に導入したときは色々な機能を表示したくなる。しかし多く表示すればするほどRedmine に難しい印象を持たれて定着しづらくなるし、せっかくの情報が分散してしまうモジュールもある。なのでモジュールは最低限にしたほうがいい。

特に不要だと思うのは文書とフォーラム。

文書はファイル機能で代替できる。なおファイル機能の利用にも注意が必要だ。ファイルからチケットに飛べないので、どのタスクで発生したファイルなのか分かりづらくなるためだ。固定の設定ファイル等だけを登録するよう指導が必要だ。

フォーラムは議論がチケットに紐付かないので、ノウハウと作業が分散してしまう。あとから経緯を追いづらくなるため、議論の内容はチケットに残したほうがいい。

プラグインは最低限にする

色々と有用なプラグインはあるがRedmine のメジャーバージョンアップで動作しなくなることが割と多い。

Redmine のバージョンアップでは、レスポンスの向上や良い新機能も多くリリースされるため、できる限り最新を利用したほうがよい。

プラグインに引っ張られてRedmine をバージョンアップできないのは本末転倒のため、プラグインは最低限にする。

チケットのカテゴリは使わない

カテゴリは各プロジェクトに標準で用意されていて分類分けするのに便利な機能だが、他のプロジェクトに使い回せない。

あとからカテゴリをカスタムフィールドに置換するのは結構な手間がかかる。始めから他のプロジェクトに使い回せるカスタムフィールドを使う。

最初に親プロジェクトを作ってサブプロジェクトで運用する

長期間1つのプロジェクトで運用していると、検索するときにそれなりに重くなる。また検索時に情報が大量にヒットしてしまい、目的の情報が探しにくくなる。

 
最初に親プロジェクトを作り、サブプロジェクトで運用開始するとよい。その後のサブプロジェクト追加は大きめの機能追加や、イベントの単位で作成する。そのほうが後から情報を検索しやすい。

また、1プロジェクトでRedmine を運用すると過去のチケットを整理するタイミングがなくなるケースが多い。サブプロジェクトで切っておくと、そのサブプロジェクト終了時にチケットを見直すタイミングができるので、そのときに整理できる。

何よりチケットをすべてクローズしてサブプロジェクトを終了させるのには達成感がある。