Redmineを運用している規模について

[K]

現在、Redmine（Bitnami）を少人数の1チームで利用しているのですが、

将来的には他のチームも含めて、徐々に拡大して大人数が利用することを想定しております。

ただ、現在のRedmineの1サーバにそのままプロジェクトやメンバーをどんどん追加してよいか不安があります。

チケットが急速に蓄積されていき、大人数の同時アクセスとか性能面は大丈夫かなあとか、

Redmineをバージョンアップする時には全停止しなきゃいけなかったり、

障害が起きた際に全社的に影響がでてしまうなどといった懸念があります。

そこで、考えているのは・・・

元々の案A）1つのRedmineサーバにそのまま他のチームのメンバー＆プロジェクトを追加していく。

代わりの案B）複数のRedmineサーバを立てて、組織の部署ごとに利用する。1つの部署の中の複数チームが1つのRedmineを共有利用する。

案Bの場合は、何かトラブった際には局所的になるし、

バージョンアップやプラグイン適用もそれぞれに必要分だけ適用するで済むので安心なのですが、

部署間でチケットを共有できないなぁとか、兼務で横断的に活動しているメンバーはどうしようとか、

結局、それぞれメリット・デメリットがあるような気がするところで、今に至ります。

そこで、ちょっとアンケートっぽい質問で恐縮なんですが、

他の皆さんはどのくらいの規模感で運用しているのでしょうか。

いろんな事例を知りたいので（利用者100人以上などの大規模な事例はとくに知りたいのですが）、

お手数おかけしますが、何卒、ご協力のほどよろしくお願い致します。

ちなみに私の場合は下記となります。

１）使っているRedmine（本体版、Bitnami版、MyRedmineなど）

　→Bitnamiのver3.2です。

２）Redmineのサーバ数

　→1台です。

３）利用ユーザの規模数

　→1チームで5人が使っています。　※ちなみに将来的には10チーム以上、100人以上を見込んでいます。

４）CIツールや構成管理ツールなどの連携

　→JenkinsとSubversionを使っています。2つともRedmineと同じサーバにのせて連携しています。

５）どんな用途で使っていますか？

　→運用：インシデント管理・問題管理のためのチケット利用

　→開発：変更管理のためのチケット（変更の背景や改修内容を明記したチケット）

６）上記の構成でRedmineを運用するに当たって良かったこと

　→利用者が少ないので、積極的にバージョンアップやプラグイン適用がしやすかったことです。

７）上記の構成でRedmineを運用するに当たって困ったこと

　→一度、サーバが壊れたことがあり、復旧まで2日ほどまったく使用できなくなったことです。（復旧後にまとめてチケット更新しましたが）

以上、特に結論のない質問で恐れ入りますが、何卒、よろしくお願いします。

[K]

昨日、Redmineの勉強会があったんですね。

知らなかったので、タイミング的に惜しいことをしてしまいました。（反省）

http://redmine.tokyo/projects/shinared/wiki/%E7%AC%AC10%E5%9B%9E%E5%8B%89%E5%BC%B7%E4%BC%9A

闇Redmineというのか、各部署や各チームで

Redmine インスタンスを、こっそり運用しているらしいことが分かったので、

やっぱりそれが大多数なのでしょうかね。

[あきぴー]

redmine.tokyoスタッフのあきぴーです。

昨日の第10回東京Redmine勉強会の参加申込者144人分のアンケート結果は

下記で公開されていますので、ご参考下さい。

Redmine.tokyo 10 questionnaire // Speaker Deck https://speakerdeck.com/naitoh/redmine-dot-tokyo-10-questionnaire

Kさんが考えているように、当初は一つのチームで運用し始めたRedmineに、隣のチーム、隣の部署

が相乗りして、そして会社全体の部署と多様な業務へと発展していくケースが多いように思います。

すると、小規模プロジェクトで有効であったチケット駆動開発の運用ルールが多様な業務、多様な組織に

展開しにくくなる事例が多いように最近感じてます。

ですが、セキュリティポリシーや内部統制上、業務ごとに複数のRedmineインスタンスを作らざるをえない場合が

あるので、解決方法があるか分かりません。

この辺りも、皆さんの経験談を、東京や大阪のRedmine勉強会、このメーリングリストで議論したいです。

次回の東京Redmine勉強会は11月になると思いますので、TwitterやWikiをチェックしてもらえればと思います。

2016年5月15日日曜日 19時22分58秒 UTC+9 K:

[松谷秀久]

同じくRedmine.tokyoスタッフの松谷です。

Redmineは簡単にインスタンスを立てられるので、まずは小さな単位から初めて、より大きな単位の組織へ拡大していくのがよいかとおもいますが、
より大きな組織について１つのインスタンスで運用していくためには、性能とか移行だけでなく、運用の効率化という課題に直面することになるとおもいます。

小規模な運用をする分には、トラッカーやステータスの種類など自由に小規模な単位の好きなように設定することができるので、
そのようにして始めるのが普通だとおもいます。しかしながら、大規模な組織で運用するためには、それぞれの小組織の言い分を聞いていろいろな設定を行うと、
Redmineに設定が可能ではあるのですが、多様になりすぎて収集がつかず、運用が大変になるのです。
そのような状況では小規模で運用していたよりも運用が大変になり、「大規模な運用は結局割に合わない、小規模で運用したほうがまし」
ということになってしまうのです。
そうなってしまうと、結局、「Redmineだめじゃん」みたいな感じになり、上位への説明が難しくなります。

それをうまく運用するためには、Redmineの機能に頼るだけではなくて、運用ルールや運用者のポリシーを決めて
きちんと統制しながら運用することが不可欠になります。
例えば、以下のように運用ルールを決めて運用されているような事例を見たことがあります。
　・プラグインは入れない
　・ワークフロー、ステータスのパターンを決め、どの小組織もそれに従ってもらう　など
全社運用などの成功事例では、Redmineでできることを理解したうえで、しっかりと主体性をもった統制を行っている場合が多いようです。

まずは、小規模でもRedmineを運用し、社内に仲間を増やしておくことで、実際に運用ルールを決める際も検討しやすくなるとおもいます。
また、勉強会等に参加し、参加者同士で意見交換されるのもよいとおもいます。

p.s.
次回の勉強会については、このGoogle Groupで告知してもいいかもしれないですね＞あきぴーさん

[あきぴー]

こんばんは、あきぴーです。

KさんとTwitterでやり取りした内容がとても重要と思い、Togetterにまとめました。

Redmineの運用が大規模化していく上での課題～@Will_meaningさんとのやり取り - Togetterまとめ 

http://togetter.com/li/976269

日本のソフトウェア開発の文脈では、教科書にのらないような全く違う観点の問題が出てくるのかな、と思います。

2016年5月15日日曜日 19時22分58秒 UTC+9 K:

[松谷秀久]

あきぴーさん

松谷です。

Togetter まとめを興味深く読ませていただきました。
私も海外ではJIRAが多いのに日本ではRedmineがずいぶん普及していることについては疑問におもっておりました。

Kさんの記述によるとプルリクが使えるのが１つ明らかな違いということなんですね。
たしかに、それにより、ビジネスアジリティに多少の影響を与えているかもしれません。

私の考えでは、プルリクを行うか否かについてというスタイルの差はあるかもしれませんが、単独のプロジェクトを管理するのであれば、
JIRAであっても、Redmineであっても、開発管理としては問題なく運用できるような気がしています。

Redmineの課題点としては複数の大規模化・多様化したプロジェクトを、どうやってマネジメントしていくべきか、ということです。
Redmineは、複数プロジェクトを扱うことは可能なのですが、レポーティングが弱く、
複数プロジェクトを横断的にチェックするPMO(Project Management Office)的な対応は、少なくとも現在は困難だとおもいます。
ワークフローを意識的に統一するなどの統制をしないと、複数のプロジェクトをより効率化するといったところには至らない
というのも１つの切り口と思います。
海外では、ITSの発展の歴史から、そういうPMO的な要素をマネジメントすることが可能なJIRAが発展してきたといえるのかもしれません。
一方で、日本では、未だエクセルでガントチャートを書いているプロジェクトも多い気がしています。
プロジェクトの大小にかかわらず、１つのプロジェクトだけを見るのであれば、ITSを使ったほうが、整然と管理できるのは当然だとおもうのですが、
従来のやりかたを良しとする日本的な考え方が、幅を利かしているいるような気がしています。
そんななかで、Redmineは、導入が簡単、OSSなので無料、自前での工夫が容易というところで、自分で工夫するのが大好きな日本人の心を
つかんでいるのかもしれません。

今回の考察にあたり、以下のWeb記事を参考にしました。
https://www.ricksoft.jp/document/blog/view-blog-post.action?pageId=58982417

今後も、エクセルよりはよくなるということでRedmineは根強く使われていくでしょう。
ただ、こう考えてみるとJIRAは、複数の多様なプロジェクトをマネジメントするという点から、一歩先を行っているような気がしてなりません。
この記事では、JIRAのアドバンテージについて書かれているのですが、現在もRedmineを使っているという@bohnenさん、@FireBlade96さんから
情報を得たとされています。こういった方も、できれば勉強会にお呼びしたいですね。

Kさん、このような考察をするきっかけをいただきありがとうございました。
まとまりはありませんが、今後もこういうテーマについては、深く追求していきたいです。

2016年5月17日火曜日 22時38分16秒 UTC+9 あきぴー:

[松谷秀久]

自己レスです。

PMOを支援する機能としてどういう機能をJiraが持っているか、よくわからなくなってきました。
実際のところ、検索してみても、それほどアドバンテージのある機能は見当たらないですね。

もしご存じの方がいらっしゃいましたら、情報いただけますと幸いです。

[川端光義]

アジャイルウェアの川端です。

弊社著書で恐縮ですが、様々なRedmine利用事例を載せた

「Redmine実践ガイド」があります。

http://www.amazon.co.jp/dp/488337968X

書籍の中で特に大きい事例が島津製作所さんでの300人超えと

フューチャーアーキテクトさんでの1000人での利用事例ですね。

宜しければご参考にされてください。

2016年5月15日日曜日 0時43分55秒 UTC+9 K:

[あきぴー]

JiraとRedmineの比較結果について、Jira側の人から記事が掲載されてます。

画面キャプチャの比較は分かりやすいです。

JIRA Software(+Atlassianツール) vs Redmineについて - 製品とサービスのブログ - サポートドキュメント 

https://www.ricksoft.jp/document/blog/view-blog-post.action?pageId=181961014

チケット管理の運用が大規模になっていくと、ツールの違いや機能の違いだけでなく、組織体制に見合った運用ルールや

その標準化活動の方が重要になってきます。

たぶん、RedmineでもJiraでも、同じくらいの苦労があるでしょう。

その辺りの知見をまとめてみたいと思います。

2016年5月18日水曜日 23時55分11秒 UTC+9 松谷秀久:

[K]

みなさま、さまざまなご意見をありがとうございます。

まだまだどんどんいろいろな見解や議論を知りたいので、

TOPIC自体はまだ継続されてほしいのですが、ひとまず感謝を申し上げます。ありがとうございます。

私自身、あれからいろいろ考えてみた結果、複数インスタンスが好ましいのかなと、今は思っています。

※フューチャーアーキテクトさんの事例（70インスタンス）とまではいかなくても。。

1インスタンスでカバーする場合、

　・ワークフロー、ステータスのパターンを決め、どの小組織もそれに従ってもらう　など

こういう制約は確かにつきもので、それ故に入力項目が多くなり、更新する人が少なくなり、

Redmine内の情報の量も鮮度も弱くなってしまうことは、避けられないのかもなぁと。

私自身、【結局、「Redmineだめじゃん」】って言われるのを避けたくて、

いろんなプラグインを入れて、こういう使い方できますよと宣伝しながら

各プロジェクト単位でいろんなモジュール選択できる＝いろんな使い方ができるように環境を整えてきましたが、

結局、自分の所属するチーム以外に文化として根付かせるのに失敗しております。

で、ふとRedmineを使い始めてからの挫折の流れを自分の経験から追って考えてみたのですが、、、

--------------------------------------------------

①Redmineが使える環境を準備するのが大変だった。

→Bitnami Redmineで簡単にインスタンスはたてられるようになった。

　→でも、デフォルトのままでは組織や業務にマッチしていないので、、、

　↓↓↓

②Redmineのプラグイン導入で苦戦した。

→基本的には手順は同じなので、慣れれば大丈夫だけれど、

　たまにプラグイン同士が競合したりすると、自分でパッチを当てたりしていた。（諦めたこともあります）

　→でも、めちゃくちゃ便利そうなプラグインが現在のバージョンに対応していないことがわかり、、、

　↓↓↓

③Redmineのバージョンアップで苦戦した。

→データ損失が恐怖なので、バックアップとリカバリの手順を、他のサーバで完全再現できるまで念入りに確認しました。

　その環境上でプラグインの依存関係の確認もして、バージョンアップしました。

　→さあ、これだけ充実したRedmine、ぜひ他の人にも使ってもらいたい、、、

　↓↓↓

④他チームへの展開で失敗した。

→Redmineやプラグインの動きは、私のチームは①〜③までの経験で見識を広げることができたけれども、

　他の人からすると、いきなり選択肢が多すぎて、それらを取捨選択して活用する道筋が見えませんでした。

　→すると、どうしてもそのチームの既存プロセスをRedmineに当てはめる傾向になりがちで、

　　Redmineに変えた意味ってあったんだっけ？って思われてしまいました。（最終ログイン日時が止まっているという・・・涙）

--------------------------------------------------

自分のチームと比較した時に何が違ったかというと、

Redmineがデフォルトの状態からバージョンアップやプラグイン導入などで改良されるにつれて、

チーム内のRedmine成熟度もあがり、利用プロセスも改良されていったことのように思います。

下記の動画でも話されていますが、私もRedmineはメンテナンス負荷が高いと思います。

　▼redmine tokyo第9回勉強会08 LT2 Redmineトラブルシューティング事例@solysombra73

　　https://www.youtube.com/watch?v=Z0zXdTvCMCo&feature=youtu.be

それ故に、うまく動いているRedmineについ相乗りしたくなりがちですが、

1つのインスタンスそのものがチームの文化や慣習のようなものと考えれば、飛び込んでカルチャーショック受けるよりも、

デフォルトの状態からそれぞれのチームでRedmineのインスタンスを立てて、

チームと一緒に文化を成熟していくのがシンプルに上手くいくのかなぁと今は考えております。

そして組織や文化の問題を除けば、②や③のポイントでつまづきにくいような

新鮮な情報やサポート、こういう場のQAがこの先もっと潤えばいいなぁと思います。（「Redmine実践ガイド」はその1つですね）

※　Togetterの件も、引き続き、Redmine⇔JIRAで何か知見を得られたら、またこちらにも書き込みたいと思います。