Redmineインスタンスを分割したい状況の考察

@nekosanzさんから、Redmineインスタンスを分割したいつぶやきがあって、色々考えさせられたのでメモ。 論理的でないラフなメモ書き。

【参考】 かるね@nekosanzさんはTwitterを使っています: 「Redmineの今後について、やはり複数に分ける方向に進んだほうが幸せかも。なやましー」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@yassan168 そんな感じです。お客さんによって規模と契約が極端に違うせいか、同じ部門でも求められる成果や粒度が違います。大企業向けのチームはロールや作業時間、カスタムフィールドに対する要望も多くなってます。サーバーのEOSLの兼ね合いもあるので、方針決めを楽しんでます。」 / Twitter

りょうま@Redmine大阪LTするよさんはTwitterを使っています: 「@nekosanz1 @netazone @yassan168 多分、利用者同士は各Redmineの中で話するので困らないと思いますが、nekosanzが「どのインスタンスの？」と聞く手間が増えますね。」 / Twitter

akipiiさんはTwitterを使っています: 「@kam1nchu @netazone @nekosanz1 @yassan168 組織とRedmine の間がどれだけ密結合なのか、という基準になると思います。一人のユーザーが複数のRedmine インスタンスに関わるような組織、つまり組織とRedmine が疎結合ならば、運用は煩雑になるでしょうね。」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@yassan168 @akipii @kam1nchu @netazone 複数あるとめんどい部分もありますね。ただ、それなりの組織の活用レベルを上げる（密な状態になっていく）と特定のビジネスに合わせて特化してくような感じです。トラッカーやカスタムフィールド、作業時間、インターフェイスとか。今の環境見直しだけでも出来そうですが、他への影響を考慮してます」 / Twitter

neta＠ 8/31(土) Redmine 大阪で会いましょうさんはTwitterを使っています: 「@nekosanz1 @yassan168 @akipii @kam1nchu 1人 1 Redmine と正しくスコープ設計ができるならいいと思います。私は失敗した。顧客共有用 Redmine が開発から保守フェーズに入った際に社内用分離→内緒話を不適切な方に書く事故多発。 ワークフローやロール数は増えるかもしれないけど、分割しないと解決できないケースはなんだろう？外部共有？」 / Twitter

黄巻紙さんはTwitterを使っています: 「@netazone @nekosanz1 @yassan168 @akipii 「分割しないと解決できない」とはちょっと違いますが、例えば「特定の部署ではものすごく欲しいけど、ほかの部署では不要なプラグイン」を入れたとして、そのプラグインが原因でバージョンが上げられなくて迷惑するみたいなケースは想像してました。実際の運用経験からのものではないですが…」 / Twitter

かるね@nekosanzさんはTwitterを使っています: 「@kam1nchu @netazone @yassan168 @akipii まさしくそんな感じです。かなり特殊な事例ですが、特定対象（うちだと顧客）において、1番でかくて複雑な運用を大人数で回してるプロジェクト群を「根本見直し」するケースですね。トラッカーやロール、時間管理、プラグイン、諸々変えるのですが、他の部門には関係ないですし、既存運用もあるので。」 / Twitter

akipiiさんはTwitterを使っています: 「@kam1nchu @netazone @nekosanz1 @yassan168 なるほど、Redmine に対して、部署ごとに要求が違うのに真因があるわけですね。単一の標準Redmine では、多種多様な社内のニーズに耐えきれなくなる事例。面白いですね。」 / Twitter

やっさん??さんはTwitterを使っています: 「@akipii @kam1nchu @netazone @nekosanz1 Redmineというか無償なOSSあるある問題な気がします。管理者コストを代償にフレキシブル＆ニッチオブニッチに対応し、それらの影響でVer.UP出来ないとか、運用が複雑になってしまって、構築した人しか扱えないものになってしまうとか、割とアンチパターンに成り易いので注意がいるパターンです??」 / Twitter

やっさん??さんはTwitterを使っています: 「@akipii @kam1nchu @netazone @nekosanz1 とは言え、何でもかんでも断るのも、良い関係性保てないし、そもそも改善出来ないので、改善の本質を考えたり、とてもバランス感覚が必要なところじゃないかなぁと思います。」 / Twitter

neta＠ 8/31(土) Redmine 大阪で会いましょうさんはTwitterを使っています: 「@yassan168 @akipii @kam1nchu @nekosanz1 以前はノリでプラグイン入れてたけど、全社利用になったので「安定、信頼、長期利用」に方針転換した。 バランス大事なのほんとにそう。ウチは幸にもヘビーな要望がないので、コミュニティの知恵を借りることで結構なんとかなってる感謝。 Redmine 管理者レベルが上がると思って楽しんでます(まだ)」 / Twitter

akipiiさんはTwitterを使っています: 「@netazone @yassan168 @kam1nchu @nekosanz1 みんなの意見が参考になります。Redmine はカスタマイズしやすい特徴があるが、組織が大規模になり、高品質な運用が求められてくると、安易なカスタマイズが仇になるわけか。組織構造よりも組織文化とRedmine の間の課題かもしれない。」 / Twitter

【感想と考察】 【１】会社標準の単一Redmineインスタンスから複数のインスタンスを立ち上げたい時、どんな考え方が判断基準になるだろうか？

僕は、組織とRedmineの間でどれだけ密結合になっているか、という基準で区別できるだろう、と考えている。

たとえば、組織とRedmineが疎結合の場合、Redmineインスタンスは所属部署に関係しないので、一人のユーザは複数のRedmineにログインする運用になる。 よって、ユーザは各Redmineのログインパスワードを別途記憶せざるを得ないし、Redmineに書き込んでいる時に自分が今どのRedmineインスタンスにいるのか、逐一存在確認する状況が発生してしまう。 特に、システムごとにRedmineが乱立していると、作業日報や障害・問い合わせの記録をする時に、複数のRedmineチケットに記入する時の入り口の判断にパワーを取られるのが、あまり楽しいものではない。

一方、組織とRedmineが密結合の場合、Redmineインスタンスは所属部署に強く関係づけられているので、一人のユーザは所属部署が持つ単一Redmineだけの運用になる。 ユーザの作業全ては単一Redmineのチケットに起票するだけなので、ブラウザでどのRedmineだっけ？と考える手間は全く無い。 たぶん、ユーザにとっては入り口が楽な分、運用も定着しやすいだろう。

【２】では、Redmineと組織の関係にはどんなパターンがあるのか？

たぶん２種類ある。 組織を単一Redmineインスタンスに標準化するパターンと、組織ごとに複数のRedmineインスタンスが混在するパターン。

前者では、単一RedmineのRedmineプロジェクトに組織構造の情報が埋め込まれているはずだ。 しかし、Redmineの設定は標準化されているので、部署単位の文化はあまり埋め込まれていないだろう。

ただし、組織とRedmineの関係は密結合になっている。 Redmineで実現された標準プロセスに埋め込まれたワークフローや諸々の運用ルールに、組織に属する全ての人達が規定されられているはずだ。 何となく窮屈な気もする。

後者では、Redmineインスタンスごとに組織（部署）が対応付けられているはずだ。 よって、Redmineには組織の情報だけでなく、部署単位の組織文化がふんだんに埋め込まれているだろう。 たとえば、ワークフローやカスタムフィールドに、業務やシステムの特徴がもろに出ていたり、部署の管理職が欲しがる情報がカスタマイズして埋め込まれているだろう。

ただし、組織とRedmineの関係は疎結合になっている。 一人のユーザは、こちらのRedmineに入ればその組織文化を受け入れ、あちらのRedmineに入れば別の組織文化を受け入れる。 たとえば、ある組織のレビュープロセスが普通と思っていても、別の組織のレビュープロセスが違っていれば、Redmineのワークフローは大きく異なっているはずだ。 おそらく、新規加入した委託契約の開発者は、乱立したRedmineごとの開発プロセスの違いで混乱してしまうのでは、という気がする。

だから、複数のRedmineの集計ビューを一つのRedmineで見たい、という要望も発生しがちだ。 特に、PMOのように複数の組織やPJを横断する情報が欲しい場合、複数のRedmineのビューを手軽に見たくなる。

複数Redmineの内容を一つのRedmineに集約して見る方法: プログラマの思索

【３】とはいえ、会社標準の単一のRedmineインスタンスで運用を始めて全社に展開していくと、ユーザから細かな改善要望が結構出てくる。 Redmineの良さは、カスタマイズのしやすさなので、割と簡単に要求を受け入れて、その会社特有の業務に使いやすくできる。 しかし、カスタマイズしすぎると、Redmine本体が複雑になってしまい、ユーザの多様なニーズに添えなくなる時がある。

つまり、単一の標準Redmineでは窮屈すぎて、組織内にある多種多様なニーズを実現できなくなる臨界点が現れるわけだ。

上記の議論の通り、Redmineのカスタマイズのしやすさが、逆にRedmineの普及や浸透に制限をかけてしまう場合がある。 そう言えば、Jenkinsでも同様な話があった気がする。 例えば、Jenkinsでデプロイ作業やデプロイのパイプラインをどんどん作り込んでいくと、どんどん複雑になってしまい、Jenkins職人と言われる属人化した人しか触れなくなる、みたいな。 たぶん、Redmineでも、Redmine職人しか会社のRedmineをカスタマイズできない、と言った症状が出てくるかもしれない。

では、単一Redmineが複数のRedmineに分離したくなる臨界点とは、どんな条件があるのだろうか？ その臨界点では、組織とRedmineの間に、どんな緊張関係が出てくるのだろうか？

実際、単一Redmineでは使いにくい、という不満が大きければ、その不満を発する組織と単一Redmineには大きなコンフリクトが発生しているからだ。

たぶん、いろんな状況や理由があると思うので、色々聞いてみたい。