プロジェクト管理ツールとしてRedmineを導入してみたけど、いつのまにか未完了チケットが数百個溜まったまま放置されていたり、発行されたチケットの進捗が別途Excelで管理されていたり、気づいたらまとも利用されなくなっちゃってることってありませんか？
ここ２年くらい、いくつかRedmineでプロジェクトを運用してきて、特に上記のように若干崩壊しちゃってるチケット管理を立て直す場合に、こういう風にするとうまくいくんじゃないか……という知見が溜まってきた気がするので書き残しておこうと思います。チームの規模は大体３〜８名程度で、非エンジニア(デザイナー、企画者)などもRedmineのメンバーに含まれる環境でした。使っていたRedmineのバージョンは2.x系です。
基本原則
チケット管理において、以下を意識する。
- シンプル
- 意味のわからない表現を無くす
- メンバーそれぞれが次に何をするべきかわかる
逆に、チケット管理が上手くいっていない場合は上記ができていない。
シンプルにする
Redmineはプラグインの無いデフォルト状態でも非常に機能が豊富。しかし、これらすべての機能が本当に必要な場合は多くない。できるだけシンプルにすることで、チーム内での使い方のブレが発生しにくくする。
不要なモジュールの無効化
チームがRedmineの運用に慣れていない場合は、思い切って以下のモジュール以外を無効にする。
モジュールの有効化、無効化は、プロジェクトの設定から行える。
その他のモジュールは、必要になったら随時有効化していけばいいが、有効化する前に以下の懸念を考慮したほうがいい。
時間トラッキングは、開発者に余計な入力の手間をかける割に情報の信憑性が低く、価値のある情報になりづらい(コミットメッセージで自動化したとしても、通常、実装時間だけが作業に要した時間とはならない)。
以下のモジュールは他のツールと機能が被り、情報の分散化を招きやすい。
| モジュール名 | その他のツール |
|---|---|
| ニュース | 議事録、Wiki、メーリングリスト |
| フォーラム | メーリングリスト、チャット |
| ファイル | ファイルサーバー |
| 文書 | ファイル、Wiki、ファイルサーバーの設計書など |
ガントチャートやカレンダーは一見便利そうに見えるが、チケット毎に開始日、期日を設定する必要があるため、全体を俯瞰したスケジュール管理がしづらい。期日の管理はロードマップに集約したほうが修正がかけやすい。
不要なチケットフィールドの無効化
デフォルトで用意されている、開始日、期日、予定工数、進捗率は不要。トラッカーの設定で無効化する。
意味のわからない表現を無くす
Redmineのデフォルトデータで用意されているトラッカー、ステータス、優先度などの表現は、人によって解釈に違いが出ることがある。場合によっては、意味がわかりやすいようにデフォルト状態から設定を変更したほうがいい。
トラッカー
Redmineのデフォルトデータで作成されるトラッカーであれば以下のように使い分けのルールを決める。
| トラッカー | 用途 |
|---|---|
| 機能 | 機能追加、仕様変更 |
| バグ | テスト中、リリース後に発生した不具合 |
| サポート | プログラム変更をともなわない作業依頼(データ調査など) |
ルールがない状態でチケット運用を開始すると、下記のようなチケットが発生することがある。
- 「〜の動作確認」
- 「〜不具合の原因調査」
- 「〜さんにメールを出す」
Redmineはコミュニケーションツールであって、個人のメモ帳ではない。こういうチケット発行を許していると、Redmineは他人が勝手に本人にしか意味がわからないメモを書き込んでくるメモ帳以下のアプリになってしまう。ミーティングでこんな会話を聞いたことがあったら要注意。
チームリーダー「この『〜動作確認」てチケットなんですか？」
メンバー「あ、それは僕の個人的なタスクです」
この手のチケットは情報のノイズになり、結果的にチーム全体に無駄な時間をとらせることになる。これを防ぐため、チケットの発行は「作業」単位でなく、「機能要求」と「インシデント(出来事)」単位で行うようにする。
場合によっては、機能になる手前の「要望」のようなトラッカーも作っておくと良いかもしれない。また、「タスク」のような抽象的なトラッカーは、作業的なチケットを誘発するので作らないほうがいい*1。
ステータス
Redmineがデフォルトで用意しているステータスは、使い分けの基準が微妙に不明確(「解決」と「終了」など)なので、意味のわかるステータスのみ残す。ステータスの変更条件を決めておくことも重要。最低限「誰が」「どんな時に」ステータスを変えるのかがチームで共有されていること。ステータスの変更ルールが無いと、まだ責任者が確認してないのに勝手にチケットがクローズされていたりして、チケット管理が崩壊していく。
実際のプロジェクトでは以下のようにステータスを定義していた。
| ステータス名 | 説明 |
|---|---|
| 新規 | 初期状態 |
| 進行中 | 実装担当者が設定され、作業が開始している状態。実装担当者自身がこのステータスに変更する。 |
| フィードバック | 作業担当者による作業が完了し、確認者が確認している状態。担当者に確認者を設定し、実装担当者がこのステータスに変更する。 |
| リリース可能 | リリースまでに必要な作業がすべて完了し、リリースを待つだけの状態。確認がOKだった場合に、確認担当者がこのステータスに変更する |
| 終了 | 本番環境にリリースされた状態。リリース実施者がこのステータスに変更する。 |
「フィードバック」と「終了」の間に、「リリース可能」というステータスを追加している。このように、ステータスはRedmineのデフォルトをそのまま使うのではなく、チームの実態にあったものを定義していったほうが良い。
また、Redmineのワークフロー機能を駆使すれば、ロールごとに変更可能なステータスを制限できる。ルールが守られない場合はこのような対応を検討する必要もあるかもしれない。
優先度
Redmineのデフォルトデータで用意されているチケットステータスは、以下の通り(バージョン2.6.1時点)。
- 低め
- 通常
- 高め
- 急いで
- 今すぐ
これらは、重要度と緊急度という２つの概念が一つのフィールドに混在しているため混乱を招きやすい。例えば、「高め」と「急いで」のどちらを優先するかが人によって異なったりする。なので、下記のように変更する。
- 低め
- 通常
- 高め
- とても高め
- 最優先
チケットステータス名の変更は、[管理] > [列挙項目] から行える。
また、チケットの優先度を決めるのは誰かを明確にしておくことが重要。多くの場合、企画者やプロジェクトマネージャーがこれにあたると思う。
メンバーそれぞれが次に何をするべきかわかるようにする
チケットの一覧を見ただけで次着手すべきチケットがわかれば、メンバーは自発的に行動できるようになる。これを実現するため不要なチケットの除去と情報の可視化を行う。
実質無効なチケットはすべて削除
まず、1年以上更新が放置されているようなチケットがあればすべて削除(もしくは「却下」ステータスに変更)する。もしかしたら重要なチケットがあるのでは……と思うかもしれないが、それが本当に重要なことなら再度チームの課題としてチケット化されるはず。
チケットに優先度を設定する
優先度を決定する権限がある人(企画者やプロジェクトマネージャー)と対面で話しながら、すべてのチケットに優先度を設定していく。もしチケットが大量にありすぎて、一つ一つ優先度設定するのがきつい場合、以下のようにチケットをグルーピングして進める。
- 機能名や画面名などでカテゴリ*2を作成
- カテゴリ毎の優先度をきめる
- すべてのチケットをカテゴリに割り振る。
- カテゴリの優先度に合わせてチケットの優先度を設定
ロードマップ(対象バージョン)を作成する
チケットの優先度が決まったら、次にそれを「いつ」完了するかを決める。リリース予定日が迫っているプロジェクトであれば最低限、「リリース日までに」、「リリース日以降」の２つのロードマップがあれば十分。
ロードマップはプロジェクトの[設定] > [バージョン]から作成できる。
カスタムクエリで担当者を明確にする
次に担当作業を可視化するカスタムクエリを作る。メンバー毎に以下のようなクエリを作り、誰が何を担当しているのかがすぐにわかるようにしておく。
他にも以下のようなクエリを作っておくとプロジェクトの状態を把握しやすい。
- 担当者なしのチケットの一覧
- 最近１週間で新規追加されたチケットの一覧
ここまでくればあとは、直近のロードマップのチケットに担当者を割り当て、ルール通り運用していくだけになるはず。
おわりに
Redmineは機能が豊富にあるように見えますが、ある程度割り切って目的と機能を絞って使ったほうが活きるのではないでしょうか。Redmineは本質的にはイシュートラッカーで、標準機能だけではプロジェクト管理の機能は弱い、というのが今まで使ってみた感想です。Redemineのガントチャートなどを頑張ってメンテするより、ExcelやMicrosoft Projectなど他の製品と併用するか、Backlogsプラグインなどの追加を検討したほうが効率的だと思います。