Redmineの大規模化の壁

昨日、meeting/17 - Shibuya.trac第12回勉強会～チケット管理システム大決戦　第二弾～Shibuya.trac Wiki - SourceForge.JPが開かれた。
UStreamで観戦して、とても面白かったです。
スタッフの皆さん、お疲れ様でした。

実際の議論を聞いて参考になったとともに、Redmine派の自分としては、@daipresentsさんの話がもっと聞きたかったな、と思っている。
今の僕の興味は、一プロジェクトでITSを使ってプロジェクト管理することよりも、1個の事業部、1つの会社全体へRedmineのようなITSを導入して運用して、ソフトウェア開発の基幹業務システムにしてしまいたいという思いに移っているから。

僕もRedmineを4年間使ってみて、一プロジェクトの事例はたくさん経験したし、ボトムアップで成功例を作ることで他チームへ影響させることができることも知った。
けれど、数十人、数百人のメンバーで数十個以上のプロジェクトが並行して動いている場合、Redmine1個でどこまでプロジェクト管理を代用できるのか、はまだ手探り。
だから、@daipresentsさんが楽天で1000人規模でRedmineを運用してぶつかった壁について、もっと知りたいと思っている。

Redmineを大規模化するために、今考えていることをメモ。

【元ネタ】
meeting/17 - Shibuya.trac第12回勉強会～チケット管理システム大決戦　第二弾～Shibuya.trac Wiki - SourceForge.JP

[資料公開]チケット管理システム大決戦 第二弾 #shibutra | Ryuzee.com

かおるんダイアリー　2011年06月30日

3年使ったRedmineの使い方について共有したい10のこと | 世界 - @daipresents

Redmineが1000人のエンジニアに使われるまでのこと | 世界 - @daipresents

Shibuya.trac第12回勉強会でチケット管理システム大決戦第2弾が開かれるようです #tidd: プログラマの思索

【1】Redmineを一プロジェクトの数人のタスク管理だけでなく、数十人、数百人、数千人の規模まで拡張したい目的は2つある。
1つは、ITSによって事業部や会社全体の開発プロセスを標準化できること。
もう一つは、ITSをプロセス改善の道具に出来ること。

前者は、ITSの機能で開発プロセスを実装することによって、全チームのプロジェクト管理にツールによる制限という規律を自然に導入出来ること。
つまり、ITSをプロセス標準化の道具として使うこと。
プロセスを標準化できれば、新米の現場リーダーも初期設定の標準プロセスをそのまま使ってチーム運営できるし、どのチームのプロジェクト管理も同じならば、要員の流動化も図りやすい。

従来のCMMI、PMBOK、WF型開発のように、開発プロセスを標準化しようとすると、大量のドキュメントと融通のきかない承認フローによって、開発の速度が鈍くなる。
しかも、せっかく標準化したとしても、これだけインターネットで情報がアッという間に普及する時代では、すぐに陳腐化してしまいがち。
プロセスの内容をバージョンアップするだけでかなりの苦労がかかる。

後者は、ITSに蓄積された障害やタスク、リリース作業の履歴から、データマイニングによる傾向分析によって、意味あるメトリクスを抽出して、予防対策や是正対策を取れるような仕掛けをもたらすこと。
つまり、ITSを中核として、チームが自律的に学習する組織へ変えること。
チームが自己組織化することによって、自ら問題を解決していく組織へ変えることができる。

プロセス改善していくには、今どんな問題が目の前にあり、どのように解決するのかという方針を自ら決めて、実際に対策を評価するというPDCAサイクルが必要。
CMMIは今までのソフトウェア開発のベストプラクティスを分類してレベル分けした点が素晴らしいけれど、やることが多すぎてプロセス改善まで手が回らない。
又、普通のプロジェクトでは、障害の履歴を残して、後から分析出来る仕組みがないから、そもそも改善していく仕掛けすら無い。

【2】Redmineを大人数で使う場合、WebサーバーやSCMリポジトリに問題が出てくる。
1個のプロジェクトで5人しかメンバーがいないなら、SVNリポジトリへリモートでアクセスして、Webrickで起動していても問題ない。

しかし、数十個以上のプロジェクトが並列に動いている場合、Webrickではアクセスがもたついて使いづらい。
Unix上にRedmineがあるならば、Passengerが一番安全。
Apacheの負荷分散やスケールアップのノウハウは枯れているので、安心できる。
僕の経験では、Webrick＜Mongrel＜Thin＜Passengerの順で高速で安全なように思える。

できれば、JRuby＋TomcatでRedmineの運用も試してみたい。
@haru_iidaさんがRedmine 1.2.0 をJRuby 1.6.2 + SQLite3で動かす方法を公開されている。

Haru's blog: JRuby で Redmine や ChiliProjectを動かす

JRuby＋TomcatでRedmineの運用を試したい理由は、Tomcatで負荷分散するノウハウは既に枯れているからだ。
RailsよりもJavaのWebアプリケーションサーバーの方が歴史が長く、負荷分散やスケールアップの技術ノウハウは結構あるので、流用できるものは使った方が楽だから。

【3】SVNリポジトリが既に存在していて、巨大な場合、リモートで接続を指定すると、@daipresentsさんの言う通り、Redmineがダウンしてしまう事も経験した。
正直この現象はとても痛い。
構成管理ツールと連携しないITSは、ただのチケット管理システムに過ぎず、No Ticket, No Commitの運用ルールが使えないから、成果物のトレーサビリティを実現できない。
だから、ロードマップがソース修正履歴となり、Excelのリリース管理台帳をRedmineで置き換える手法が使えなくなってしまう。

僕の考えでは、Redmineと同一サーバー上にミラーリポジトリを作って、マスターリポジトリとミラーリポジトリを同期させるのが現実的な解決方法だろうと考えている。
Subversionならsvnsyncで同期させるし、GitやMercurialなら元々分散バージョン管理だから、ブランチを同期させるのはもっと簡単だ。

この辺りは下記のTwitterで色々議論した。
@Kokawa_Takashi さんの指摘にあるように、JenkinsでSCMリポジトリをリアルタイムなバッチ処理のように同期させる手法はとても優れているように思える。

Twitter / @akipii: @kyon_mm @aoi_wakusei 大規模プロジェクトや巨大なSCMリポジトリの場合、同一サーバー上にミラーリポジトリを作らないと実用的でないでしょう。@daipresentsさんの話にもありますが、Redmineがダウンしてしまいます。

Twitter / @akipii: @kyon_mm @Kokawa_Takashi さんの指摘通り、RedmineはリモートSVNでURL指定可能です。小規模プロジェクトならとても便利です。

Twitter / @akipii こちらを参考にしてくださいー。うちではJenkinsで定期的にrubyのタスクを走らせています。 redmine.jp/guide/RedmineR… #shibutra

Twitter / @akipii: @Kokawa_Takashi JenkinsでSCMリポジトリを同期ですか！なるほどね。リアルタイムなバッチ処理みたいな使い方ですね。参考にします。　#shibutra

【4】Redmineを大人数で使う場合、プロジェクト・チケット・バージョンの階層化という特徴はとても相性が良い。

Redmineプロジェクトは、実プロジェクトや組織構造にそのままマッピングしやすい。
事業部や会社の組織は、命令系統が階層構造となっているので、ツリー構造でマッピングできる。
Redmineプロジェクトの階層化は、プロマネには理解しやすいみたいだ。

Redmineプロジェクトを大規模組織に適用する時に難しい点は、どこまでプロセスを標準化できるか、という点だ。
Redmineの管理画面では、カスタムフィールドをトラッカー単位、プロジェクト単位に対応付けることができる。例えば、バグ修正のワークフローではチケットの属性に障害管理報告票の項目を追加すればいいし、課題問合せのワークフローは課題特有の項目をカスタムフィールドに追加してもいい。
それらカスタムフィールドは、選択したプロジェクトのみ反映されるので、チェックボックスでチェックしなければ反映されないから、使わない運用もできる。
また、ステータスは必ずトラッカーに依存する設定のため、課題問合せのワークフローはタスクのワークフローと異なるように管理することもできる。

しかし、各チームの要望を受け入れてカスタムフィールドやステータス、ワークフローを増やしすぎると、組織全体でプロセスを標準化していく方向からずれてしまう。
各チーム独自のローカルルールがはびこると、プロセスの標準化による利点が消えてしまう。
この辺りは、どこまでRedmineでプロセスをカスタマイズしていくか、というさじ加減になる。

【5】チケットの階層化も、MS Projectに慣れたプロマネは理解しやすいみたいだ。
チケットの階層化の利点は、顧客やプロマネが見たいビュー(ストーリーカード)と開発者が管理したいビュー(タスクカード)を分けることにあると思う。

Redmineに対するプロマネの要望の殆どは、ガントチャートや課題一覧などビューの見せ方が多い。
彼らは、顧客視点から眺めた一機能の進捗や課題について管理したいのであり、開発者レベルの細かなタスクの進捗や仕様上の質問は正直興味ない。

一つの解決方法としては、RedmineのBacklogsプラグインのように、親チケットをストーリーカード、子チケットをタスクカードで階層化することで、ビューの見せ方を意図的に変えることができると思う。

あるいは、Redmineの対象バージョンをストーリーカード、対象バージョンに紐づくチケットをタスクカードと見なしてもいい。
つまり、本番リリース日までに実装する機能をリリース予定バージョンと見なすわけだ。
この手法は、@daipresentsさんのパーキングロットチャート・プラグインを使えば、バージョン1個の進捗が顧客にとって価値ある機能の進捗に相当するので、非常に分かりやすい。

Redmineが1000人のエンジニアに使われるまでのこと | 世界 - @daipresents

又、Redmine1.2.0から導入されたプライベートチケットを使って、開発者個人のToDoチケットはプライベートチケットにして、工数集計から外すという運用も可能だ。
つまり、工数集計すべきチケットと工数集計から外すチケットをプライベートチケットによって分別するという新しい手法もある。

Redmineはチケットの属性とチケット集計の機能の関連がとてもうまく作られているので、色々試してみる価値があると思う。

【6】Redmineで大規模Agileを実践する時に重要な手法は、アジャイルリリーストレインの実装だ。
複数チームのリリースを制御したい場合、アジャイルリリーストレインを適用することで、全チームのリリースを同期させるようにする。
Redmineでは、バージョンを継承することが可能で、親プロジェクトのバージョンを子プロジェクトへ強制的に反映させることができるから、アジャイルリリーストレインを実現することができる。

アジャイル開発のスケールアップはアジャイルリリーストレインが鍵を握る: プログラマの思索

Redmine 0.9 新機能紹介(2): バージョンの継承 | Redmine.JP Blog

アジャイルリリーストレインが重要な理由は、複数チームのリリース計画作りの一手法であるからだ。
複数チームのリリースの同期はアジャイルリリーストレインを使えばいいし、組込み製品の開発のようにハードウェアチームとソフトウェアチームが内部リリースを繰り返しながら最後にリリースを同期させるようなイテレーションの入れ子関係のような手法もある。
大規模組織におけるリリース計画作りは、色んなバリエーションが必要だ。

しかし、Redmineの残念な点は、子プロジェクトへ継承したバージョンは、子プロジェクトのバージョンと見なされないために、子プロジェクトのチケット一覧に表示されず、親プロジェクトのチケット一覧にしか表示されない。
アジャイルリリーストレインを運用したい場合、子プロジェクトへ継承したバージョンは、子プロジェクトのバージョンでもあり、子プロジェクトのチケット一覧やガントチャートでもフィルタリングできるようにしたい。
何故なら、子プロジェクトへ継承したバージョンに紐づくチケットは、子プロジェクトのタスクなので、子プロジェクトで管理したいからだ。
チケット一覧やガントチャートのSQLのうち、バージョンの取得条件をちょっと修正するだけでアジャイルリリーストレインを実現できると思うのだが、誰か直してくれないのかな？

【追記】
RedmineのVer1.1.xでは上記の症状が発生するが、Ver1.2.xではバグが直っているようだ。
実際、親プロジェクトのバージョンを子プロジェクトが継承した場合、子プロジェクトのチケットで継承したバージョンをセットすると、親プロジェクトでも子プロジェクトでも、ガントチャートやチケット一覧に子プロジェクトのチケットが表示される。
つまり、Redmineの最新バージョンでは、アジャイルリリーストレインの実装は可能だ！

【7】Redmineを大規模組織、全チーム、全プロジェクトへ適用することで、色んな利点が出てくるし、運用してみて色んな発見があって面白い。
RedmineのようなITSがあれば、プロジェクト管理の問題をツールの一機能という問題に置き換えて、プログラミングでマネジメントの問題を解決していく方向に変える。

プロジェクト管理の経験が少なくても、Rubyでプログラミングできる技術さえあれば、シミュレーションして自分だけのノウハウを貯めることも可能。
色々試してみたい。