3年使ったRedmineの使い方について共有したい10のこと

前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。

1. Redmineのオブジェクト構造を理解した方がいい

Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。

プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ

注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考えるとよいです。

2. プロジェクト名は「プロジェクト」か「組織」がいい

プロジェクトには期限がないため、例えば、「○○チームのタスク管理」といったものを作ることができます。しかしながら、普通に「○○プロジェクト Phase1」「○○プロジェクト 2010 1Q」という名前をつけてもいいと思います。両者を比べてみるとどうなるでしょうか？

• 期限なしのプロジェクト名をつけると・・・
  • ○ チケットが集約されるので管理がしやすい
  • × 徐々にチケットが増えると検索が重くなってしまう
• 期限ありのプロジェクト名をつけると・・・
  • ○ そのプロジェクトの情報のみを集約できる（情報制度UP・検索速度UP）
  • × プロジェクトをアーカイブ化したときに検索できなくなってしまう
  • × 分け方に注意しないと細かいプロジェクトがたくさんできてしまう

などなど。一長一短であることがわかりました。

私の経験では、プロジェクトを分けすぎて失敗し、「○○チーム2010」のような組織＋年としてみて、年をまたぐチケットで困った経験があるので、シンプルに「○○チーム」という閉じないプロジェクトを作って運用しています。チケットの増加による検索遅延を防ぐために、「過去の思ひ出」というプロジェクトを作り、定期的にチケットを移動しています。

自分の会社がプロジェクトベースの管理をされている場合は、プロジェクト名をつけたほうがフィットするでしょうし、サービス開発のようなインクリメンタルな開発の場合は、組織名やサービス名で作るとよりアジャイルを意識する形になります。

3. バージョンは「ストーリー」か「期間」で考えたほうがいい

バージョンには期限を設定できます。バージョンは、アジャイルでいう「イテレーション」「スプリント」として使うことが出来ます。また、Redmineの本家のページのように「1.2.0」といったプロダクトのバージョン番号を使うことも出来ます。

また、バージョンをストーリーとして扱うことも出来ます。パーキングロットチャートプラグインを使って、バージョンをストーリーカードのように表示することができるので、バージョンにはストーリー名をつけ、顧客との調整でパーキングロットチャートを使っているという話も聞いたことがあります。

私は、当初「Sprint 1」などにしていたのですが、途中で「次は１２だっけ？あれ、今１２か？」と混乱してしまったので、「2010/01/01～2010/01/14」といったスプリントの期限をバージョン名にしています。

4. 親チケットと子チケットは使わない

ごめんなさい。これに関するノウハウは持っていません。

実際に使ってはみたのですが、メンバーが使い方を理解するのに時間がかかりそうだったので、シンプルに「使わない」選択をしました。当面は「チケットを作って閉じていく」という最低限のルールから始めるといいと思います。

5.入力項目数は少ないほうがいい

プルダウンから選択する項目については、定期的にレポートを使って絞り込みたい情報が無い限りは、選択肢を少なくすることで、初期の教育コストを抑えることができます。チケットを作るときの入力は少ないほうが楽です。

はじめは細かく設定できるようにしたいと思いますが、それをした場合にメンバーがついてきませんでした。また、いざカテゴリを作ってみたものの、結局何にも使わない・・・ということもありました。バグ表として使う場合などはたくさんの項目があって然るべきだと思いますが、通常の作業の場合は、できるだけシンプルにすることがポイントだと思います。

カテゴリは、削除時に「○○カテゴリに再設定する」といったことができるので、たくさん作ってみてあとでマージでもいいかと思います。

6. バージョンにあわせてタイムボックスを利用したほうがいい

私のチームでは、タスクボードを見ながら朝礼、2週間のスプリントでスプリントの終わりの日にふりかえりと個別にスプリント計画を立てています。タスクボードは@kawagutiさんに教えていただいたハレパネを使って作りました。

チケットはほとんどを私がつくり、スプリント計画時にアサインを行います。スプリント内でチケットが終わればいいので、開始日と期日はほとんど使っていないです。そして、スプリント計画時に、「どれぐらいの見積りでどれぐらいかかった？」と質問し、見積もりは予定工数、実績は備考欄（カスタムフィールド）に記載して、次の計画を見積もっています。

ステータスについては、「新規」「アサイン（仕掛りかどうかを判定するため）」「終わり」の3種類の状態のみとし、進捗については、0％か100％しか認めていません。仕掛りチケットは仕掛りチケットでしかないので、あくまでシンプルにしています。

スプリントをまたいだ作業が発生すると、チケットの扱いに困ると思います。昔は、スプリントの終了時にその時点での予実を入力し一旦チケットをクローズしていました。しかし、ベロシティの計測を行うようになって、終っていないチケットは終わるまで次のスプリントに移動するとい う形になりました。

7. 題名、説明はプログラムする気持ちで記述する

題名は題名だけ見て内容が想像できるように書きます。メソッド名を考えるときに似ていますね。

説明についても、「何をしてどうなったら終わりか？」を書きます。定型作業の場合は、フォーマットを入れることで内容が明確になることもありますので、Redmineの概要ページなどに以下のリンクを作ってみるといいかもしれません。

http://demo.redmine.org/projects/pamu/issues/new?issue%5Bsubject%5D=This%20is%20subject&issue%5Bdescription%5D=This%20is%20description

これをクリックすることで、新規チケットに文字列をデフォルト入力できます。URLエンコードツールなどを使って雛形を作っておくことで入力が楽になります。

8. Redmine導入に失敗するパターンは決まっている

Redmineを導入して失敗しているケースは以下のようなものがあげられます。

• はじめから完全な入力を求めルールを重視しすぎる、メンバーがついてこない”自己満足リーダーケース”
• 最低限の規律をつくらずに、プロジェクトごと放置される”結局みんなメモ帳でタスク管理に戻るのねケース”
• 高性能のツールさえ使えばうまくいくと考えて導入しはじめた”夢と希望にあふれるだけのケース”
• 「うちは独自だから」といって個別に立てたのに使わない”私はあなたと違うのよケース”

リリースするものに価値を加えるのももちろんですが、ツールはまず使うメンバーを喜ばせる必要があります。

2013/03/14 追記：Redmineのようなツール導入で悩むなら以下の記事もどうぞ。

https://daipresents.wordpress.com/2013/redmine-anti-pattern/

9. 考えておきたいインフラのこと

Redmineを利用するユーザが500人を超えてくると、連携するシステムのことも考慮する必要性が出てきます。たとえば、Subversionのようなソース管理システム。500人のユーザがリポジトリブラウザを開くと、恐ろしいリクエストがSubversionを襲います。ユーザの増強と共に、こういった周りにあるシステムも増強する必要性がでてくるとおもいます。

よって、「OSSだから安く導入できる」というのは大間違いだと思いました。少人数での運営ではコストは少ないでしょう。しかし、利用者が増えることで、Redmineは業務システムに変化します。使う側には無料であっても、運営するコストは徐々に大きくなってしまうこともあるので、規模が大きくなる場合は、予算などをしっかり確保するか、JIRAのような有償ツール（できればホスティング）を検討することをオススメします。

私は、次、また1000人規模の組織に導入することになったら、JIRAを提案すると思います。アクセス権限や、レビュー、ソース検索など、トータルのソリューションがJIRAにはあるからです。

追記: JIRAをしばらく使ってみましたが、アトラシアン製品は高機能すぎて使いにくく、大規模で使うにはパフォーマンスが悪すぎました。落ちる、重い、使いにくいの三重苦…。

10. Redmineでコミュニケーションを取り過ぎない

Redmineでプロセスが出来上がると、チームはRedmine中心に作業をこなしていくでしょう。リーダーが、上手にチケット管理したり、ワークフローを使って権限を調整することもできますが、あるときに、メンバーがチケット作成し、他のメンバーに勝手にアサインした結果、そのチケットが放置されていた事件が発生しました。

このように「言った、言わん」の話をするのは不毛です。確かに、毎日チェックすれば気がつくかもしれませんが、一言声をかけるだけですむ問題です。私のチームでは、何かを誰かに頼むときは、私を通す。もしくは、互いに声を掛け合うことをルールとしています。

最後に

ふりかえりとして、Redmineから学んだことを数回に分けてまとめてみました。

Redmineを導入したときは3人のチームでしたが、1ヶ月後には「チケットに切っておきました」とか「チケットを確認します」とかいう声が聞こえてくるようになり、10名ほどの人数になっても、効率よくタスク管理ができるようになりました。

最近の私のチームでは、タスクボードをベースに使い、Redmineはチケットのロギングのみで使うようになってきました。プロセスが整理されてくると、必要最低限の利用となり、チームがツールに頼らない形になっていくことがわかってきました。今はRedmineのインフラ運用から離れてしまいましたが、これからも次世代のプロセス改善方法を考えていこうと思っています。

私は不精な人間なので、作業を便利にしてくれるツールが大好きです。彼らは開発をさらに楽しくしてくれます。そういうツールを開発する方々に感謝したいと思います。もちろん、Redmineにも。あなたのチームが、ツールを駆使し、より価値の高いソフトウェアがリリースされていくことを期待しています。

最後に、アジャイルソフトウェア開発宣言にある私の好きな言葉をみなさんに贈ります。

プロセスやツールよりも、個人と対話を価値とする。