数千人が利用する楽天Redmineの過去と未来 #47redmine

第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。

数千人が利用するRedmine

来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。

はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。

自分のグループで使ってみようという提案もしましたが、なぜか当時のマネージャが嫌がり断念。その後、ユーザー数はゆっくり増えてユーザ数64人に。当時だとエンジニア全体の10％に満たない開発者数です。

そんな中、プラグインを作っていろいろいじるようになり、チームの進捗を見える化し、チームを応援するため、Roadmapsプラグイン、All Time Teamプラグインを作りました。

その結果、Redmineの活用に成功しました。状況が一目でわかるようになり、見る側も自分がどういった状況なのかを理解できるようになりました。「チームでRedmineを使う」という方針にもつながりました。これらの成果は、徐々に周りへと広がり、徐々にユーザが拡大していきます。

ユーザが300人ぐらいを超え、チームメンバーもRedmineに慣れてくると、問い合わせ業務をRedmineに完全移行しました。外部とのやり取りを整理したかったという理由からだったのですが、問い合わせの傾向などをRedmineのレポートで出し、時間がかかっている部分を洗い出したり、過去の問い合わせをトラッキング＆検索することで、業務改善に大きく役立ちました。

このころからアジャイルプラクティスを本格的にRedmineに適用するようになります。

Version Burndown Chartプラグインはその1つです。Redmineのプロジェクトに対するバーンダウンチャートプラグインは見つけたのですが、バージョン単位のものがなかったので作成しました。しかし、入力が多く、バーンダウンせず最後にどーんと下がるチャートばかりだったので利用しなくなりました。

次に生まれたのがパーキングロットチャートプラグインです。私が作ったプラグインの中でも、これがもっとも多く使われているように感じています。バージョンを工夫することで、ビジネスサイドとのやりとりに使うこともでき、完了したバージョンが積み上がっていくため、達成感を感じることができます。

アジャイル開発の要素を取り入れたプラグインを入れてから、様々な情報の見える化が進みました。プラグインに興味をもつユーザが現れ、Redmineが周囲へも浸透していきました。なによりもチームのタスク管理能力が上がったように思います。

当時はバージョンアップごとに機能が増え、それにあわせてバージョンをがんがん上げていました。その影響か、ユーザはやがて1000人を超えます。頻繁なバージョンアップのために環境を改善し、できるかぎり自動化して対応しました。

1000人を超えたため、リアルサーバ＋Passengerへと切り替えました。

一番大きな問題として、RedmineのSVN連携で、SVN側に負荷が集中してダウンしたことがありました。たしかRedmineのコードに書かれていたタイムアウトが長く（たしか3分）、コネクションが積み重なってしまい、負荷へとつながっていました。

SVNだけでなく、JenkinsやReviewBoardなどもSVNに連携するため、SVN側をマスタ・スレーブにするなどの対応が必要になります。SVNにはスケールするための仕組みがあるので、それらの機能をうまく活用して、連携するシステム全体の増強を考える必要があることを学びました。

また、重い検索処理がRedmine全体を止めることがあったため、全体の検索機能は使えなくなりました。私の作った「All Time Teamプラグイン」もユーザが増えるとそうなる現象が発生しました。

コーチングの仕事の影響で、チームはタスクボードを活用するようになり、現在は、問い合わせ作業のみRedmineで運用しています。タスクボードの手軽さはあなどれません。

上のタスクボードでは、Doingのスペースを付箋２枚分しかとらないようにして、作業が誰かに偏らないように並行作業を制限しています。あとは写真をとってふりかえりなどで活用し、消化したタスクの傾向だけトラッキングしています。

私のチームはRedmineからはじめたて使いこなせるようになってきたので、タスクボードの手軽さは魅力ですが、張り出せない制限があったりするケースもあるはずなので、どっちがいいかというより、チームはどちらが好きか？で選べばいいと思います。

また、私のチームが使わなくなった理由として、Redmineで取っておきたい情報（問い合わせの履歴や外部とのやり取り）はRedmineを使う。開発に関する情報は、Subversionのコミットログや、リリースノート、簡単なマニュアルを書いたWikiがあれば十分だったため、ログが残らなくてもタスクボードで十分だったのです。

そして、最初は数人で始まったRedmineの現在へと進みます。

2011年秋ごろのデータです。ユーザは4000人を超え、2500ものプロジェクトが作成されています。

誰でもすぐ使えるようになったためユーザは急増。ただ、使いこなせているかどうかまではわかりません。私の感覚では、30％ぐらいのひとしか使いこなせていない気がしています。ここまでくると、開発の基幹システムと言えます。

ここまで大規模になった楽天のRedmine。たどった道のりを振り返ると、私のコンテキストからはいろいろな問題点も見えるようになりました。

まずは、簡単に使えてしまうという問題。簡単に使えるがゆえに、必要以上に使おうとする人が出てくるため、目的と手段の勘違いが発生し、非効率になってしまうことがあります。

次に、ルールの程度の問題。厳しいルールを始めに決めてしまい、ルールを守れない人が悪・・・という状況がチームを苦しめる場合もあります。大量の更新メールが開発者を襲い、「メール見ろよ」とかの衝突も生まれてました。

最後に、ユーザが増えたことで最適化が難しくなる問題。先に述べたような「全体検索停止」「負荷予測ができないためREST API停止」といった制限が生まれ、もともとあった柔軟性は徐々になくなり、「それなら独自で環境をつくろう」といった動きにつながります。Pluginが大量にインストールされ、大量のタブができてしまうこともあります。

ただ、それでもいいところはいっぱいあるため、どういった使い方をしていきたいのか？というビジョンを運営者側で持つ重要性が高まります。利用開始時のサポートや使い方のレクチャーも考えていく必要があります。ビジョンを達成できないのであれば、「ツールを使わない」という選択も必要になってきます。

楽天のRedmineの未来については、恐らく、私のチームがやっているように、やりとりのログが重要になる問い合わせなどで使われることが主流になっていく気がします。

環境面では、オープンソースソフトウェアで構成することも十分可能ですが、運用に○人コストを掛けるのであれば、ホスティングサービスのほうが安い場合もありえます。もしくは、クラウドサービスを使うことで個別最適化が進み、各自で独立した環境を作るケースが増えてくるかもしれません。

大人数で使う場合は、柔軟性ももちろんですが、「問い合わせならこういう使い方」「開発ならこういう使い方」というプロジェクトごとのテンプレートを作り、OSイメージを配る形で運用したほうが、開発者のためになりそうです。

最後に、どんなツールよりも対話するほうがコミュニケーションを取ることができます。アジャイルマニフェストにも「個人との対話」と書かれていますが、最近ではツールの進化が激しいので、プロセスやツールも軽視できない時代になってきたのではないかと思うようになりました。

私のチームでは、Redmine以外にもいろいろなツールを導入し、使い、捨ててきました。しかし、根本となる「ツールの使い方」「ツールを使う理由」への理解を深める事で、どんなツールに変化しても、対応できる柔軟性がチームに生まれました。ツールではなくチームが柔軟性を持ったのです。

最適なツールを最適に使いこなすことができれば、開発はより楽しくなります。Redmineはとてもいいツールだと思いますが、Goodなツールではなく、Excellentなツールへと育てるのが、導入や運用する側の仕事になってくるのではないでしょうか。

もし、今のRedmineがExcellentではなかったり、そうならないのであれば、ツールを再考する時期かもしれません。なぜなら、ツールを使い続けることが目的ではないからです。