Redmineの情報のサイロ化を解決したい問題

「Redmineの情報のサイロ化を解決したい」問題がGoogleGroupにアップされていた。
その議論が興味深かったのでメモ。

【元ネタ】
情報のサイロ化を解決したい - Google グループ

nanego/redmine_multiprojects_issue

【1】問題

(引用開始)
Redmine便利に使っていますが、困っているのが情報のサイロ化です。
他PJに情報(チケット)を横展開する場合、コピーすることになると思いますが、どうもかゆいところに手が届かい感じがしています。
横展開するPJが1つか2つなら手作業でコピーできなくもありませんが、3を超えると忘れ（サボ）られがちです。

1つのチケットを一度に複数のPJへコピーする方法（プラグイン）、または情報のサイロ化を防ぐ手段、ツール、運用方法とあればご教授頂きたいです。
(引用終了)

問題の発端としては、あるチケットが他の複数のRedmineプロジェクトにも影響があることが判明したので、横展開したいことがある。
例えば、ある顧客向けのパッケージ製品でバグ修正や機能改善した時、他の顧客向けの製品にも影響があるね、と分かる時もある。
あるいは、あるモジュールの修正が後続の外部システムに影響があるので、情報を連携したい時もある。

問題の前提としては、少人数のチームではなく、複数チームで複数のシステムを開発・運用していて、相互に密接に関連する場合があるだろう。

個人的には、課題管理のチケットで上記のような問題が発生しやすいだろうと思う。
なぜなら、課題の重要度や緊急度を判定するときには、リソース・スケジュール・スコープなどへのインパクト(影響度)を把握する必要があり、その時に、影響するプロジェクトを指定したい場合があるからだ。

【2】技術的課題

nanego/redmine_multiprojects_issueを使うと、一つのチケットを複数のプロジェクトに所属させる機能を実現できる。
使い道としては、チケットに対し、影響するRedmineプロジェクトを選択すればいいだろう。

しかし、実際の運用では下記のように、迷ってしまう場合が出てくる。

(引用開始)
(redmine_multiprojects_issueプラグインの)運用としては以下のようになるかと思いますが、少し使い難いと思った点があります。

例）
1．Project Aで問題が見つかる
　　→チケットを発行
2．類似プラットホームのProject B にも影響するので、問題を横展開する
　　→チケットをProject Bにも所属させる
3．Project Aで問題は解決した、Project B では未対策
　　→このタイミングではチケットをクローズ出来ない
　　　Project A上でこのチケットは残ったままになる
4．Project Bでも問題解決した
　　→このタイミングでチケットをクローズする

難点としてはクローズするタイミングが全てのPJで同じになってしまう点だと思いました。

上の例だと、3のところでProject A上では問題は解決しているのでクローズさせたいところですが、
Project Bに対しては解決出来ていないのでこのチケットをクローズ出来ません。
プロジェクトの進行によっては3と4の間に期間が大きく空いてしまう場合もあると思います。
情報を横展開した後は、各PJ毎に任意のタイミングでクローズさせる必要があると考えております。
(引用終了)

つまり、影響するプロジェクトでCloseできなければ、チケットのステータスをCloseにできない問題がある。
チケットの作業状況がチケット一覧から見えにくい短所がある。

したがって、チケット管理で進捗状況をリアルタイムに見える化したいのに、redmine_multiprojects_issueプラグインを使うと、ステータスから進捗度合いを把握するのが難しくなる。

【3】解決策の提案

一つの解決策としては、下記の提案のように、プロジェクトごとに終了ステータスを記録するカスタムフィールドを作る方法もある。

(引用開始)
参考になるかどうか判りませんが、私の所では、プロジェクト毎に終了ステータスが記録できるカスタムフィールドを作り、
それぞれ記録しています。 全て終わったら Redmine のステータスが 「終了」 になります。

前提としては 「同じ案件なら同一チケットに集約したい」、「プロジェクト数はそんなに多くない」 という条件があります。
この条件にマッチすれば、ひょっとしたら参考になるかもしれません。

この話は 解決アプローチが何通りかありそうで、興味深い内容だと思いました。
(引用終了)

しかし、このやり方では、Redmineプロジェクトが増えるたびにカスタムフィールドが増殖してしまうリスクもある。

【4】僕の考えでは、影響するRedmineプロジェクトごとに、チケットをコピー(複製)する機能を使い、各プロジェクトごとにチケットを作り、元のチケットを関連チケットで関連付ける運用が良いと思う。

他のRedmineプロジェクトに影響すると分かっても、各プロジェクトごとに、その意味合いは異なる。
あるプロジェクトでは重大な課題になる場合もあれば、他プロジェクトでは後回しにしてよい課題の場合もある。
チケットは各プロジェクトごとに記録していく方が良い。

関連チケットにしておけば、チケットの関連チケット欄にステータスも表示されるから、他チケットの対処状況も把握可能だ。
わざわざredmine_multiprojects_issueプラグインで運用を複雑化させる必要もないと思う。

つまり、「1個のチケットで一つの情報の記録を集約させていく」「Redmineプロジェクトで案件や製品を分割し過ぎない」運用ルールで進めた方が良いと思う。

色んな現場を見てみると、WBSライクに親子チケットで分割し過ぎたり、Redmineプロジェクトを分割し過ぎて階層化しない「サイロ型プロジェクト」のようなアンチパターンをよく見かけるからだ。
Redmineはチケットやプロジェクトの機能の柔軟性が高いので、チケットやRedmineプロジェクトを分割し過ぎてしまいがち。
すると、逆に、情報がたくさんのチケットやRedmineプロジェクトに散在されてしまうので、履歴を追いにくくなる。

むしろ、「情報はチケットに集約する」「チケットは製品に従う」「Redmineプロジェクトは製品単位に作る」ような運用ルールに従う方が、その後の運用保守で使いやすくなるだろうと思う。
この辺りのプラクティスやアンチパターンも集めてみたいと思った。