プログラマの思索

東京Redmine勉強会のLTで、複数のRedmineインスタンスからデータ収集してAgile開発する利用事例があった。
もう一度見ながら、ラフなメモ書き。

【1】RedmineはOSSで無料であり、インストール手順はネット上に公開されているので、誰もがすぐに運用できる。

すると、最初は自分たちのチームだけで使っていたら、各案件、各チームごとに社内でRedmineインスタンスが乱立してしまう。
このような状況は、野良Redmineと呼ばれていた。

あるいは、社内標準で設置されたRedmineは、各案件の特徴にあった運用ルールやプロセスに準じておらず、使いづらいために、こっそり自分たちのRedmineを使い始めた、という話もよく聞く。
このような状況は、闇Redmineと呼ばれていた。

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

最近よく聞くRedmineのFAQ～Excel添付のチケットから野良Redmineまで: プログラマの思索

Redmineを運用している規模について - Google グループ

第11回東京Redmine勉強会の感想～Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

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

そのように、多数の複数Redmineインスタンスが乱立している状況では、各チーム・各案件の進捗状況を横串で把握しにくい問題が出てくる。
そこで、複数Redmineインスタンスの進捗状況を横串で把握できる仕組みが必要になってくる。

あるいは、組織の統廃合などで、複数Redmineインスタンスを一つに集約したい要望が出てくる。

【2】このような要望や問題を考えると、その課題はいくつかあげられる。

【2-1】一つは、複数Redmineインスタンスの情報を一括集計する方法は何か。

複数Redmineインスタンスを現状運用しながら、全体進捗を一括集計したい場合、RedmineのREST APIを使う方法があげられるだろう。

上記のLT資料は以下の通り。

(引用開始・多少編集)
【問題意識】
受託開発案件のRedmine利用率、なんと100%
1 プロジェクト、1 Redmineのパターン
それぞれの顧客から自分のRedmineを使いたいね

【やりたいこと】
やりたいことは 複数のRedmineでAgile開発を楽にしたい
● 一目で、それぞれのプロジェクトの進捗状況が知りたい
● Agileスプリントの作成・編集を行いたい
● スプリントごとの進捗を Burndown chart式で見たい
● スプリントごとのタスク進捗をカンバン式で見たい
● Velocityを測りたい
● 見積のないタスクをすぐに特定したい

一目で、それぞれの プロジェクトの進捗状況が 知りたい！！！

【解決方法】
救世主：Redmine API できることは結構ありそう
● プロジェクト、バージョン、タスクなどの操作
● タスクの更新履歴が取れる！
● 複数のRedmineサーバから集計できそう！
(引用終了)

この仕組みを自分たちで作って「Redmine Tracker」と名付けたらしい。
まだ未公開のようだが、OSSで公開してくれるとすごく嬉しい。

Agile開発に特化しているので、WF型開発案件やその他の種類の案件では使いにくいかもしれないが、ニーズはとても多いのではないかと思う。

【3-2】もう一つは、複数Redmineインスタンスを1個のRedmineにサーバー統合する方法はあるか。

複数のRedmineインスタンスをサーバー統合する方法は、一筋縄ではいかない。
利用事例としては、下記の発表資料がある。

QA #247: 複数のRedmineサーバを統合したい - Unofficial Redmine Cooking - redmine.tokyo

乱立してるRedmineを一つにまとめる話 agileware-jp/douhashi-slides

他システム(Notes)からRedmineへの移行（第３回品川Redmine勉強会）

NGK2012BでRedmineとRedmineを統合した話について発表してきた | Dabits

いずれも相当苦労している。
理由は、RedmineのIDはDBシーケンスなのでID変換用の中間テーブルが必要であることや、データ移行用のツールを別途開発する必要があることだろう。

たとえば、アジャイルウェアの堂端さんの事例では、17個のRedmineインスタンスを1個のRedmineに統合して、チケット数9万以上、プロジェクトは1千個以上に膨れ上がったらしいので、恐れ入る。

【4】1個のRedmineに集約するメリットは、チケット入力の運用ルールさえ徹底できれば、1個のRedmineのデータから、社内の全PJの進捗や品質の情報を集計できることだ。

実際、Redmineには複数プロジェクト機能や親子チケット、柔軟なワークフロー設定などがあるので、案件がWF型開発でもアジャイル開発でも実費請求の保守案件であっても、1個のRedmineインスタンス内で、別々のプロジェクト設定やワークフロー設定で区別して管理できる。

つまり、PMOや品質保証部から見れば、多種多様な案件があったとしても、Redmineという一つの箱を見れば、進捗や品質も一元管理できるのは最大の効果だ。
すわなち、Redmineの柔軟性が、多種多様なプロセスを全て飲み込んでくれるわけだ。

チケット駆動でソフトウェア開発のメトリクス分析を行うアイデア: プログラマの思索

第13回RxTStudy勉強会の感想 #RxTStudy: プログラマの思索

【5】一方、複数のRedmineインスタンスでの大規模な利用事例としては、気象庁のRedmine利用事例があげられるだろう。
資料を読むと、インフラ構成も公開されているので、インフラ関係者は必見だろう。

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

また、各Redmineインスタンスで運用ルールが異なっている点も興味深い。
そのような運用の背景には、各部署の権限が強く、組織文化も大きく異なるので、あえて1個のRedmineではなく、複数のRedmineの方が運用しやすい、という判断があったのではないか、と想像する。

【6】複数のRedmineインスタンスで運用している場合、Redmineインスタンスごとに運用ルールが異なるので、第三者の観点で見ると、社内で数多くのチームがバラバラに動いているように見える。
ゆえに、それぞれのチームの文化がRedmineと一体化しているので、1個のRedmineに統合するのはとてもハードルが高いだろうと想像する。

なぜなら、「アーキテクチャは組織に従う」「プロセスは組織に従う」という発想と同様に、「Redmineは組織に従う」「Redmineはプロセスに従う」経験則が見られるからだ。
よって、「標準の唯一のRedmineに全案件のプロセスを従わせる」というやり方は、大企業になるほど難しいかもしれない。

Redmineは戦略に従う。そして、Redmineは組織に従う～システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

【7】一方、各チームがアジャイルに開発したいならば、チームごとにRedmineインスタンスを提供して、自分たちの開発に合わせたプロセスへどんどんカスタマイズした方が良い、という考え方もできる。
つまり、運用されているRedmineはチームの組織文化や慣習を表しているので、あえて全社統一のプロセスに標準化するよりも、変化の激しい状況に対応できるように、チームごとに動けるようにするわけだ。

すなわち、逆コンウェイの法則「アーキテクチャに合うような組織を作る」という発想のように、あえてスクラムチームまたはアジャイルチームのような機動的なチームに細分化し、そのチームの文化やプロセスに合ったRedmineへカスタマイズする戦法もありうるはずだ。

「Redmineに組み込んだプロセスに合うチームを作る」という観点で、あえて野良Redmineを作り出す手法もあるだろう。

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

逆コンウェイ戦略のメモ～望ましいアーキテクチャを促進するためにチームと組織構造を進化させる: プログラマの思索

今後も色々考えてみる。