これまでWeb・DTP制作／システム開発の両方で日常的にRedmineを使用してきた中で生まれたプラクティスをまとめます。

「いやそれは違う」という箇所もあるかもしれないので、もし指摘があればコメントをお願いします!

基本方針

情報の集約度を高める
ガチガチの設定を沢山定義するのではなく、シンプルな設定で柔軟に運用する

アクセス解析を入れる

チケットが増えてくるとRedmineは重くなります。この重さを改善するために色々な施策が必要になるタイミングがいつかやってきますが、サーバの応答速度などのデータがないと改善策がどれくらいの効果だったのかが分かりません。

ほかにも色々な測定ができるので、とりあえず入れておいて困ることはないでしょう。Google Analyticsの導入はプラグインで簡単に可能です。

チャットサービスとの連携を考える

Redmineの欠点の1つは、チャットなどでのリアルタイムな通知手段がないことです。今時メールの通知だけではちょっとやっていけない辛みがあります。Redmineと他サービスの連携には、APIを外部に公開してZapierなどのマッシュアップサービスを経由させるか、直接外部のチャットへ投稿を投げるプラグインの導入が選べます。超便利なので是非導入してみてください!

チャットが便利だと、有益な情報がチャットに集約されてしまうのでRedmineの情報集約性が低下してしまいます。情報の集約はあくあでもRedmineが主役で、チャットでは通知だけを読むという運用ができると理想的です。別の記事でSlackやChatworkへ連携できるプラグインを紹介しています。

その際、ユーザー名にSlackやChatworkでメンションとなる文言をセットしておくと、チャット投稿時に自動でメンションが飛ぶのでさらに便利です（その代わり自分自身の投稿でも通知されてしまいますが)。

積極的にテーマを切り替える

案件ごとに複数のRedmine環境を立ち上げる場合、標準の外観だと今自分がどのRedmineにログインしているのかぱっと見で分からない為、投稿先を間違える危険があります。

環境ごとにテーマを着り替え、自分がどの環境にアクセスしているのかが直感的に把握できるようにセッティングするべきです。

なお、おすすめのRedmineテーマについては「僕がredmineに入れてる便利なプラグインとデザインの格好良いテーマ」へまとめています。

使い道のはっきりしないモジュールは使わない

「文書」「フォーラム」「ファイル」といった機能は、チケットやWikiの機能と上手く使い分けができず情報の分散する原因になりがちです。他のモジュールでも代替可能なので、余程の理由がなければOFFにした方が良いでしょう。

添付ファイルはWikiやチケットやニュースにアップロードし、「ファイル」モジュールは使用しない
- チケットやWikiに比べ「ファイル」モジュールは検索性が低く、ファイルが増えてくると割とカオス
- 階層化したプロジェクトの「ファイル」に大量のファイルが分散するととても探しにくい
ドキュメントはWikiに直接記載し「文書」機能は使用しない
- 「文書」はエクセルやワードの資料に簡単な説明を添えてアップロードすることを意図した機能
- テキスト情報はWikiへ直接記入を基本とし、必要があれば添付ファイルでアップロード
容量が無駄になりそうな物は、ファイルパスだけチケットやWikiに書き、実体はファイルサーバへ
議論は関連性の高いチケットの中で行い「フォーラム」は使用しない

プロジェクトを階層化する場合、恒久的な情報は親プロジェクトのWikiにまとめる

開発プロジェクトをフェーズごとに切ったり、雑誌の◯◯号のように定期的に発生する単位でプロジェクトを切ると、有益な情報が子プロジェクトのWikiに溜まっていきやすくなりがち。

しかし、いずれ子プロジェクトは古いものから閉じられていくと考えると、始めから親プロジェクトに情報を集約していった方が情報管理がしやすくなります。いっそ親プロジェクトにだけWikiモジュールを有効化するのも良いかもしれません。

トラッカーを安易に増やさず、代わりにカテゴリを多用する

あるトラッカーを使ったチケットがどこかに残り続けている限り、そのトラッカーは削除することができません。

案件に特化したトラッカーやワークフローが増える程名前付けも難しくなり、整理したくても削除できなくてものすごくモヤモヤします。

また、得てしてRedmineユーザーは管理者ほどチケットのステータスに興味がないので、案件ごとに細かいトラッカーやワークフローを作っても多分無駄です…。

トラッカーはせいぜい5種類以内に収め、トラッカーの細かい分類には「カテゴリ」を使うのがおすすめです。

例えば同じ「タスク」というトラッカーでも、カテゴリとして「開発」や「デザイン」を割り付ける事ができるため、グルーピングやフィルタリングに便利です。「カテゴリ」はプロジェクトごとに自由に定義が可能なので、名前付けや管理が簡単になります。

子チケットの作成は避け、代わりに関連チケットやバージョン機能を多用する

子チケットの運用は難易度が高く、おすすめできません。

例えば、元々1つのチケットだったタスクが子チケット化したのに、親チケットにも重複して担当者がアサインされているとしたら、それはどのような状態なのでしょうか?

子と親の担当が同じだったとしても、異なっていたとしても、客観的に誰がどのように責任を持っているのかが分かりにくいです。(個人的に、このような状況では親チケットは担当無しにするべきだと思いますが…)

あるチケットから派生したチケットを単に参照できれば十分なケースがほとんどなので、もっと柔軟に活用できる「関連チケット」を使う方が良いです。

チケット同士の関連づけ | Redmine.JP Blog

また、複数チケットの進捗度をまとめて管理するには「バージョン／ロードマップ」機能を使うのもおすすめです。

ロードマップ — Redmine用語解説

ワークフローが異なるトラッカーでも、初期ステータスを介してトラッカーの変更が可能な設定にしておく

（v3.3や3.2など、最近のバージョンでは発生しなくなりました。）

チケット作成時にトラッカーを間違えてしまい、しかも内容をガッツリ書いてしまうと、トラッカーを変更したくなることは多いです。しかし、チケットのトラッカーを途中から変更した場合、変更後のトラッカーに存在しないステータスが設定されていると、チケットのステータスがロックしてしまう仕様があります。

トラッカー	ステータス
ToDo	新規→進行中→承認待ち→終了
DTP制作	新規→入稿待ち→デザイン中→校正中→校了

1.トラッカー「ToDo」のチケットがステータス「進行中」の時、そのチケットをトラッカー「DTP制作」に変更する
2.すると、そのチケットのステータスは「進行中」の状態でグレーアウトし、ロックされてしまう
3. このチケットはトラッカーを「ToDo」に戻すまで二度とステータスが変更できない

このケースでチケットをトラッカー「DTP制作」に正しく変更するには、両者の間で共通している「新規」と、すべての項目が相互に遷移可能な状態に設定されている必要があります。

トラッカー「ToDo」のチケットのステータスを、一度「新規」にする
トラッカーを「DTP制作」に変更する
変更後、ステータスを任意のもの(「入稿待ち」〜「校了」までのどれか)に変更する

この手順を可能にするには、両方のトラッカーで

すべてのワークフローから「新規」に戻れるようにする
「新規」からすべてのワークフローへ進めるようにする

ことが必要です。

問題が起こってからワークフローを再設定するのは面倒なので、始めから全種のトラッカーで上記の設定を行っておくとスムーズに作業ができるのではないでしょうか。

ワークフローは緻密に設計しない

Redmineのワークフローはかなり自由に設定できるので、例えば承認権限を持っているロール以外は先に進められない、とか、理論的にありえない前のステータスには戻させないようにする…等の管理者心をくすぐるワークフローの設定が可能です。

しかし、緻密に設計したはずのワークフローでも、ほとんどの場合でイレギュラーが起こります。

間違えてステータス進めちゃったから戻したい
承認は口頭で取ったから、とにかくステータスを進めたい
終了したチケットをまた復活させたい

規模の大きい企業であれば話は別かもしれませんが、結局面倒臭くなって全部の「ステータスの移行先」にチェックを入れ直すことになるので、緻密なワークフローは作らない方が良いと思っています。

プロジェクトメンバーへの一斉通知は「ニュース」モジュールを使う

v2.3くらいからのRedmineでは「ニュース」機能をメーリングリストの様に使えます。添付ファイルやWiki記法も使えるので、営業の人に、顧客からもらったファイルを共有してもらったりしています。

尚、添付ファイルの有無が一覧からは分からないので、題名に添付ファイルの有無を付けると後で探しやすいです。

[添付有]最新版の台割を受領

性質上、定期的にアップデートされる、使い捨ての書類の共有に適しているかもしれないです。

※ユーザーの個人設定でメール通知なしになっていると配信されないので注意

担当者欄にグループをアサインしない

職場の雰囲気にもよるかもしれないですが「◯◯チーム」等のグループにアサインされたチケットは放置されやすい気がします。特別なルール付けがないのであればやめた方が良いです。

チケットを「削除」せず、「削除」に相当するワークフローで代用する

一度消してしまったチケットは元に戻せません。手が滑って貴重な情報を削除してしまったり、今いらないと思っても後で実は必要だった……といったことを避けるために、全ロールで「チケットの削除」はできない運用にしてしまいましょう。

代わりに、トラッカーへ「削除」「無効」などの完了扱いとなるワークフローを追加し、ステータスで削除に相当する意味付けをするのがおすすめです。

定期的に古いチケットは強制終了する

更新されていない古い未終了ステータスのチケットは、適当なルールを決めて一括で終了させてしまいましょう。

n日（あなたの会社でこれくらい放置されたらもういいよね、という日付）以上未更新
非終了ステータス
(運用上長期にわたって未更新となる想定のトラッカーは除外する)

上記のようなカスタムクエリを作成し、定期的に掃除しましょう。

プラグインを導入する前によく考える

Redmineには魅力的なプラグインがたくさん揃っていますが、本当にそれを取り入れるべきかどうかは、よく考えてみた方が良いでしょう。バージョンが0.1上がるだけでも、それまで使っていたプラグインがそのまま動くかどうか、今後もバージョンアップが続くかどうかは運次第です。

Redmineのバージョンを今後も上げていきたいか?
もし、プラグインが今後のバージョンアップで使えなくなったらどうするか?

EasyRedmineやRedmineCRMといった商用プラグインであれば、サポート体制は比較的信頼できます。逆に、個人がオープンソースで開発しているようなプラグインに依存するのは、それがどんなに便利でも、リスクを孕んでいることに留意するべきでしょう。私はどんどんインストールしちゃいますけど……。

「アーカイブ」と「終了」を使い分ける

使用しなくなったプロジェクトには、「アーカイブ」か「終了」を選択できます。

「アーカイブ」したプロジェクトは完全に非表示になり、検索対象から外れます
「終了」したプロジェクトは検索対象になり、プロジェクト一覧からも「終了したプロジェクトを表示」チェックボックスを押すと表示されます。編集ができなくなるだけで、Wikiやチケットには引き続きアクセスできます

まずは「終了」し、最終的に不要になってから「アーカイブ」するようにしています。

有益な情報があるチケットは他と区別して終了する

チケットの内容が有意義なものに成長した場合、単に終了ステータスに変更してしまうのは惜しいです。内容をWikiに書き写すのも良いですが、時間がないときは面倒です。

そこで、こういったチケットを保存するための専用の終了ステータスとして「アーカイブ」という名前のワークフローを全てのトラッカーで定義しています(名前は何でも良い)。情報価値の高いものと低いものをフィルタリングすることができるので便利です。

しかし、いずれはそのプロジェクト自体を終了したりアーカイブ入りさせることも出てくるため、有益な終了チケットだけを集めた永久保存用プロジェクトに移動させても良いと思います。

データベースが成長すれば、その永久保存用プロジェクトはとても価値あるものになっていくはずです。

補足・「チケット」のモデルは色々な用途に応用できる

最後は運用ルールではなく補足。

「チケット」モデルは色々な概念に応用できるため、使い道はバグトラッキングやシステム開発の管理に留まりません。

例えば

チケット一覧を台割に見立てることで、台割とページ数を管理しながらDTP制作の進捗管理に応用
1チケットを1つのトピックとして、カテゴリで整理されたナレッジベースを作る
サーバやリポジトリのアドレス・認証情報を記載して共有ブックマークを作る
- (例)参考となるサイトをRedmine上で分類・評価
ステータスを予約や貸し出し状況に見たてて、会議室や備品管理表にする
1チケットを1原稿に見たてて、執筆・校正の管理に使う(差分も取れる)

等といったこともできます。

チケット化すれば、Redmine内で #0000 と記載するだけで簡単にリンクが貼れるため、情報の再利用性が高まります。

何もかもRedmineで管理することが正解かどうかは分かりませんが、変なエクセルの表で管理するくらいならマシかもしれません。

こちらもどうぞ

僕がredmineに入れてる便利なプラグインとデザインの格好良いテーマ
Redmine勉強会Vol.1 なぜ組織にはドキュメンテーションが必要なのか

拙作の勉強会資料です。Redmine以前の問題として、業務を文書ベースで整理することの必要性を説明し、できるだけ多くの人に納得してもらうことを目指した内容になっています。