Redmine導入、運用に失敗する運用のアンチパターン

これまでRedmine の導入推進をしてきて、導入失敗しているプロジェクトにいくつかの共通項があったので、アンチパターンとしてまとめる。

Redmine 運用のアンチパターン

荒れ地

何も決めずにRedmine を使い始めて失敗した残骸。乱立したプロジェクト、カスタムフィールド、更新されないチケットたち。

最低限、チケットのトラッカーとステータスを決めて、定期の運用にRedmine をどう組み込むか決めてから始めよう。

溶岩流

大量の入力項目と必須項目。チケットを開くとカスタムフィールドで画面が埋まっている。

担当者にチケットの更新どころか作ることすらためらわせる。Excel台帳の列をそのままカスタムフィールドにしたときにありがち。

項目を1つにまとめられないか、そもそも必要か？を検討してからカスタムフィールドにしよう。管理項目はCSV エクスポート後に別で付与することも検討する。

神トラッカー

タスクやToDoなどなんでもありなトラッカー名。

トラッカーで分類ができないので、溶岩流になりやすい。Redmine を使い始めるときにまず作業の分類はどんなものがあるかを考えてから、それをトラッカー名にすることを検討する。

ワープ

途中経過を記載しないチケット。ステータスの開始、終了だけが残っている。

ノウハウが全く残らないので、Redmine を使うメリットが感じられなくなる。作業の途中経過がノウハウ、資産になるのでコメントを記載しよう。

アンデット

終わらないチケットたち。

メモや備忘録のような完了基準がないチケットを作ると発生する。チケットが残り続けるので、残タスクの量が分かりづらくなったり、チケット一覧が大量に見えるので精神的負担になっていく。

そういったチケットは作らず、作業チケットの中にコメントで記載するようにする。

肥満児

1チケットに延々と記載が続く。担当者のモチベーションがガリガリ削られていく。

作業がどこまで進んだのか、また後から振り返って見たときに何が問題だったのか、どう解決したのか分かりづらくなる。

最初からある程度の作業で分けて子チケットにする。途中で長くなった場合は子チケットを作成する。

迷路

カスタムフィールドのわかりにくい選択肢。担当者によって選択がまちまちになるので、分析などをする際に集計してから手で直すことになる。

選択肢は担当者が一目見て迷わない名称にする。どうしても複雑な場合は、wiki にフローチャートを書く。

不可視

Redmine に登録されないタスク。

一部の作業が別台帳や別システムで管理されていると発生する。担当者からは更新対象が増え、手間が増えたように受け取られる。

情報の集約がRedmine を使う利点の一つなので、タスクはRedmine に集約しよう。

まとめ

Redmine を導入したけれど上手く行っていなかったり、あまりメリットを感じられなかったり作業者からの評判が悪い場合は、上記のアンチパターンに陥っていないか確認してみてほしい。

その他、Redmine 運用のポイントについては以下も参照。