ベストプラクティス Redmine

はじめに

ここではRedmineマニュアル的な使い方の話ではなく、
Redmine ( やそれに類するプロジェクト管理ツール ) を利用する上で、

気を付けるとよい点
こういう使い方は止めた方がよい点 (バッドノウハウ)

に関して書いてみます。

※ Redmine Japan で聞いた事とかもまとめています。
※ Redmine 以外のプロジェクト管理ツールを利用する場合にも有効 ( だと思う )。

Redmineとは

もともとはIT開発者向けとして開始されましたが、現在では様々な分野や仕事で利用されている プロジェクト管理ツール です。

プロジェクト管理ツールって何？と聞かれた場合には、
「やるべき事を付箋に書いて、できたらはがす」 事を

ITの力を借りて、
よりシステマチックに

行うものと説明しています ( 私は )。

付箋＝Redmineのチケットなので、

やる事をチケットに書いて、
出来たら消す。

という事になります。

チケットを消す

という事でRedmineを使う目的を1つ上げるとすると

「チケットを ( 書いて ) 消すこと」 になります。

※ ゲーミフィケーション的に「チケットを消すのが快感」になるようできると定着しやすい。

自分のチケットを消す
他メンバーのチケットも消す
記録を残す

併せて、チケット消化のために行ったアクションをきちんと記録する。

消すために

消せないチケットが増えると、モチベーションも上がりませんし、ツールの利用も促進されません。
消しやすいチケットにするために、以下のような事に気を付けましょう。

消しやすい粒度でチケットを切る
あまりに範囲が広い ( 粒度が大きい ) チケットは消せない。
→ 子チケットに分割する ( 数時間～数日単位を目安に消化できる粒度で作る )。
複数のタスクを書かない
記録 ( コメント ) を残す場合でも、どのタスクに対する作業か判りづらくなる。
→ 上と同様ですが、適切な粒度の子チケットに分割する
終了条件が明確になるようなチケットを切る
「運用改善」のようなチケットだと、何が行われたら終了できるか判らない。
→「〇〇を××する」といった実際に行う必要があるアクション、及び、終了条件が判るようなチケットにする。

見える化

記録を残す事で、見える化が可能になります。可視化は重要。
何を可視化したいのか/すべきかはしっかり意識しましょう？ここがぶれると余計な情報が増えたり、可視化したいものが欠落したりします。

ここはプロジェクト次第で、「これ！」というものを提示するのは難しいので、例を示します。

以下、開発プロジェクトの場合の例

やる ( べき ) 事
- チケットに書く ( 粒度に気を付ける )
- 担当を割り振る ( 未決ならばプロジェクト管理者等割り当てを実施する人に )
- 期間を設定する ( 仮の期間でも良い )
- 適切なタイトルを付ける
- 必要十分な説明 ( 概要 ) もきちんと書く
スケジュール
チケットに期間、進捗率を記録する事でガントチャート化
タスクの状況
- 対応内容はきちんとコメントに書く。ステータスや担当者も適宜変更する。

運用する上で気を付ける事

設定はあまり細かく分けない
Redmineを運用する上では、各種設定を細分化したくなります。
しかし、細分化するほど設定・運用・メンテナンスのコストは増えます。可能な限り細分化しない事をお勧めします。
組織構造をそのまま反映するのは基本止める
実際の部署や役職を元に最初にデータを構造化するのは結構ありがちかと思われますが、これをやると大抵失敗するか、管理が辛くなります。

プロジェクト管理ツールはプロジェクト内の組織構造や役職の構造を管理するためのツールではありません。あくまでタスクを捌くためのものです。
目的のために必要最小限で効率のよいトラッカー、ステータス、ロール、プロジェクトを定義する事をお勧めします。
最初はミニマムで始め、必要に応じて変更/改善しましょう。

以下具体的なバッドノウハウ ( 例 ) を記載していきます。

トラッカーを分けすぎない

トラッカーってチケットの区分だから、業務種別毎にトラッカーを分けて作ろう。
→ 「業務/部署ごとに分けて作ろう！」

ってのはありがち。

※ Redmineのトラッカー＝帳票 の意味合い。( 入力項目があって、承認フローがある )。

でも、

トラッカーをたくさん作ったけど、実はワークフローが一緒って事が多い。

入力項目もワークフローも同じならトラッカーは同じものが使える可能性が高い。
設定が多いほど、管理コストやメンテナンスコストが上がる。
後で整理しようとしたときに辛くなる。

入力項目多すぎ

トラッカー = 帳票と言いましたが、
カスタムフィールド追加しまくって何入力すればいいか判らない。
って事にもなりがち。

結局入力してないフィールドがある
形骸化していて、利活用されていないフィールドがある

後々、分析や集計に利用するのでなければ、普通にチケットの説明欄に記載するので十分な事が多い。

入力はしてほしい項目がある ( 分析まではしない ) のであれば、Issue Templates プラグイン使いましょう。
→ トラッカーの乱立も防止できます。

※ 実際に入力項目100個とかあるらしい... 地獄
※ 担当者以外に、対応者とかあるトラッカーあるけど、違いって何？

ステータスは必要最小限に

必要以上に細かくすると判り難い。
→ どのステータスを選べばよいか、プロジェクト参加したばかりの人が把握できるのがよい状態。

業務フロー整理できていますか？
実際の業務では存在するステータスでもシステム上では不要な場合もあります。
必要かどうか微妙なステータスを作成するのは止めましょう。
どうしても必要になった時点で追加すれば済むことです。
担当者が割り振れないステータス本当に必要ですか？
→ チケットが消化されなくなる可能性が高くなります。
同じワークフローに位置するステータスが複数ある ( 部署が違う場合に別で作られている等 ) なら纏めましょう。

※ 実際にステータスが30個とか...あるらしいワークフロー把握/理解できるのか？
※ Redmineでもプラグイン追加によってカンバン利用できますが、ステータス30個のカンバンとかカオス...

ロールも細分化するのは止めよう

いろんな人が見れるのは良くない。ロールで詳細に権限を分けよう。
→ 役職毎とかにロール作ってるとこ見たことある。。。

PMとかPMOとかPLとかRedmineで何ができるロールだっけ？ → 承認者、レビュワー、オブザーバー等役割が明確なロールの方が良い。

※ PM だからこの権限、PL だからこの権限、と役職に合わせてロールを作る必要はありません。

ワークフローは？

ワークフローはロール×トラッカーの数だけある。

多くなると管理が大変。

ワークフローが同じものは、できるだけ同じトラッカーで扱えるようにする。

( 承認不要 ) タスク
顧客承認タスク
上長承認タスク

等のようにワークフローが同じトラッカーはまとめてしまって、部署を跨いだ場合でも同じトラッカーが使えるようにする方が判りやすい。

プロジェクトも不用意に細分化しない

「案件単位でプロジェクト」とかありがちだけど。。。

「バージョン」利用で足りるのであれば、バージョンを活用しましょう。

Redmineではソースコードとの連携も行いやすくなっています。
→ 適切なプラグインを併用する事で Redmineサーバ上で Subversion/Git リポジトリサーバ構成も可能です。
→ 製品/サービスとプロジェクトを一対一で紐づけるのがお勧め。

「〇〇サービス××改善」のようなプロジェクトがある場合には、「〇〇サービス」プロジェクトで、「××改善」バージョンを作成する事で、任意の製品/サービスのロードマップ毎に分割可能になります。

GitLabでのMilestoneも同様です。

組織階層で構造化するのは悪手

ありがちです。

が、複数の部署が連携して行わなければいけないプロジェクトの場合は？

→ おすすめは案件単位
但し、フェーズが分かれる場合には不用意にプロジェクト分割せずに、バージョン利用解決できないか検討しましょう。

バージョンの使い方としてどうよ？

基本、バージョンは期間を区切るものとして使うようにしています。

プロジェクトを期間以外の軸で分割するのに使っている場合もあるようですが、

期間で分割したくなった場合に、適切に分割できなくなるので、その手の要件が絶対に発生しないプロジェクト以外で採用するのは止めましょう。

メンバー追加しすぎ

考えるの面倒だったの？メンバー多すぎだろ？

基本的には、当該プロジェクトに実際に関わる方のみメンバー追加するようにしましょう。

閲覧だけさせたい？ → 公開プロジェクトでよいのであれば、それで足りる。

終わりに

特に運用開始時、トラッカーのステータス、ロールの追加を行う際に、
「項目追加したぞ！うちの会社に併せて構造化されている＆ワークフローも反映されてて完璧。スゲー！」
とか思ってしまう場合もあるかもしれませんが、

単に業務分析や抽象化が出来ていないだけかもしれません。
より少ない設定でうまく回せるような方法を考えましょう。

設定が細かいことと、業務を適切に抽象化できていることは別です。