Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破する記事のリンク

「プロジェクト間チケットコピー機能の改造で縦割り組織のサイロ化打破？」の記事がすごく参考になるのでメモ。

【参考】
Redmineを1000人規模で使っていたら…: プロジェクト間チケットコピー機能の改造で縦割り組織のサイロ化打破？

(引用開始)
Redmine上のプロジェクトの粒度とも関連するが、複数のプロジェクト間で情報共有しなければならないケースで、必須となるのがチケットのコピー機能だ。

ソフトウエア開発では（いや、ソフト開発に限らないかもしれないが）、顧客への「製品・サービス」や「展開品・派生品」を管理するグループ（縦軸）と、機能・コンポーネント等の単位で開発を行うグループ（横軸）で構成される、いわゆるマトリックス体制を採ることが多いと思う。
多製品・サービスになればなるほど、開発部隊は開発対象をプラットフォーム化・共通化し、製品やサービスに展開することで開発効率を上げるためだ。このような組織で、プロジェクト管理ツールを使うとなると、ツール上の「プロジェクト」の粒度をよく考える必要が出てくる。

縦軸や横軸を形成するグループが複数存在し、各々が役割分担している場合、それぞれプロジェクトを分ける方が良いだろう。なぜなら、Redmineの場合、プロジェクトが分かれても、プロジェクト間でチケットのコピーを極簡単に行える（後には、Versionのプロジェクト間共有も可能となった）からだ。

そして、それだからこそ、プロジェクト間の依頼事項はチケットのコピーによって行うこととなる。チケットのコピーは、重複を生むと考えられがちだが、それはちょっと違う。
グループ間でコピーされたチケットは、そもそものチケットのゴール（CLOSE条件）が違うからだ。
横軸はバグ修正や機能の実装が完了すれば、そのチケットはCLOSEする。縦軸はそれらの案件を顧客にリリースすることでCLOSEすることになる。
平行開発する派生品があれば、派生品毎にそれぞれCLOSEすべきタイミングがが異なることもザラだ。
CLOSEするタイミングが異なる案件を一つのチケットで管理しようとする方が、かえって無理というものだ。
自分の組織では、各グループの独立性が高く、（というかグループ間の見えない壁みたいなモノで、）いわゆるサイロ化現象を起こしていた。
だからこそ、一つのチケットが複数のグループで各々の責任範囲を持つとき、コピーすることで案件を分割するこの考え方が、非常にしっくりきたようだ。（またこの運用が、組織的なRedmine利用の原動力ともなった。）
もっとも、複数のグループを一つの「プロジェクト」で全て包含し、その中で「Version」（マイルストーン）を複数立てて管理することも可能であろうが、これでは各々のグループの独立性が高いほど（マトリックス開発の役割分担がはっきりしていればいるほど）、運用は困難になるだろう。
(引用終了)

いわゆる製品やシステムの派生開発では、本流(trunk/master)の障害修正は、傍流(branch/顧客ごとにカスタマイズしたbranch)でも障害修正する必要がある。
たとえば、OSやApacheのセキュリティパッチ、OracleやMySQL、Rubyなどのミドルウェアのパッチなどがある。
しかし、発端となったインシデントPJの障害チケットと、それらの派生システムへ内容コピーの障害チケットは、単純なコピーではない。
傍流の派生システムのリリース日も違うし、進捗も違うから、それぞれの派生システムでチケット管理したい。

上記の記事では、プロジェクト間でチケットをコピーする機能をこのような派生開発の作業管理に適用することで、トレーサビリティや各製品ごとの進捗管理がやりやすくなる、と主張されている。
その内容はとても同意する。

また、Redmineのプロジェクト間チケットコピー機能で縦割り組織のサイロ化を打破できるのでは、という示唆も興味深い。
派生製品の開発体制は、システム・製品単位のProductのグループ、機能や顧客ごとにカスタマイズした派生製品ごとの機能グループの2つの軸になる。
つまり、マトリクス型の組織体制になる。

一般の組織論の知見では、マトリクス型組織は運用したくなる場面が多いが、運用が非常に難しい。
ツーボス制になるために指揮命令系統が複雑になりがちだし、複数の組織に属するがゆえに自由に行動できる権限の範囲があいまになりやすい。
結局、従来の縦割り組織の開発スタイルのまま、突入して、コミュニケーション不足が発生して、潜在バグが多数残ったりして、リリース後に大きな障害を招いたりする。

根本的な解決方法はないけれど、Redmineの複数プロジェクト機能を用いて、マトリクス型組織を擬似的に当てはめることで、縦割り組織に属するメンバーが一つのRedmineプロジェクトに属することになり、チームとしての一体感が湧きやすくなる利点はある。
たとえば、SEチーム、製造チーム、テストチームのような縦割り組織があったとしても、一つのRedmineプロジェクトにSE・PG・テスターが割り当てられれば、一つのチームとして、各チケットをペア作業のように連携するようになっていく。
この「チームとしての一体感」という雰囲気の醸成が重要なのだ。

但し、Redmineのコピー機能はかゆいところに手が届いていないので、改造したらしい。
詳細は、記事を読んで下さい。

(引用開始)
ただ、Redmineのコピーの機能で、上記いの運用を行おうとしたとき、何かかゆいところに手が届かない感じがした。

・チケット登録権限のないプロジェクトへもチケットをコピーできてしまう。
・プロジェクト間でチケットをコピーしたことが、その時点で判らない。
・コピーしたら、各々のチケットの進捗が判るよう、チケット関連付けをするルールにしたものの、ちょっと面倒。忘れることもしばしば。
・状況によっては、チケットに付随するウォッチャーもコピー先へ反映させたいことも多い。

これらを改善すべく、以下の改造を施した。

＜プロジェクト間チケットコピー・移動の運用ルール＞
・チケットを取りに行くPull型がお勧め。
関連するプロジェクトのチケットを参照し、他のプロジェクトで自分のプロジェクトに関するチケットが発生したら、自分のプロジェクトへコピーするという原則。
プロジェクト間の最初の伝達は定例会議や口頭（生のコミュニケーションも大事）、チケットのウォッチャー指定など様々。

・コピー・移動先のプロジェクトで、チケット登録することができ、チケットをアサインすることのできる立場の人なら、Push型でも良いが、そうでない場合無視されるチケットが出たりしかねない。
（そういう意味でチケットをPushできる人を運用上決める必要性が出たり、余計なアクションが増えてしまうので、しっくりこなかった。）
(引用終了)

上記の記事が指摘していることを考えると、機能別組織であるソフトウェア会社でマトリクス型組織を導入したい場合、Redmineが有効ではないか、という意見を示唆しているかもしれない。

但し、大規模な組織の多様な業務にRedmineのチケット管理を導入したい場合、第10回redmine.tokyo勉強会で議論されたように、たくさんの課題はある。
大規模な組織と多様な業務にRedmineが耐えるために、必要な機能と必要な運用ルールは何であるか、今一度考えてみたい。

第10回redmine.tokyoの感想～Redmineユーザはメトリクスがお好き #redmineT: プログラマの思索