NECの友人に誘われてRedmineの運用に関する勉強会に参加しました。ツールにとどまらず、タスク管理についていろいろ議論できて面白かったです。いただいた質問に対する回答はこんな感じ。
使った資料
チケットの種類や粒度について
分ければ分けるほど複雑になります。だから、できるだけわけないのがポイントだと思います。分ける場合は、そのコストにみあった意味づけが必要です。それがないと、利用者からみれば不便なルールになってしまいます。
ワークフロー
ワークフローは使ったことないです。JIRAを試しに使うときに設定を考えましたが、これも使えば複雑になりますし、「リーダーがチェックする」みたいなフローになると、リーダーの負担が増えて流れが遅くなるので、使わない運用（例えば、口頭やメッセでリアルタイムに依頼するとか）にしました。
おすすめは、「かんばん」を使ったチケットの状態管理です。『リーン開発の現場』のように、かんばんはワークフローにもなり、圧倒的に現場が理解できるツールです。
RedmineでもJIRAでもそうですが、ワークフローが快適に動いているところ見たことないです。大抵はどこかがボトルネックになって、「～さんが見ないとOKできない」みたいな属人化や不透明な権威が生まれてます。
チケット発行や完了
はじめの段階では、作ると仕事はリーダーの仕事でした。リーダーが週次のF2F MTGで確認したり更新したりします。これを何回かやっていくと、自分でやれるようになってきますし、「チケット見ればいっか」という状態になります。閉じる作業は、お願いしてやってもらいます。閉じるの気持ちいいですから。
定型作業は、フォーマットがあると便利です。項目を分けるときは、上にも書きましたが意味づけをすること。
ロールによる権限管理
管理上、Redmine自体の管理者とそれ以外にわける必要はありますが、それ以外の権限設定はしたことがないです。変更履歴は嫌でも残るので、細かく分ける必要性よりも、更新が頻繁に行いやすいことを目指すほうが、開発にとって有意だとおもいます。
大人数のリクエストをさばく
最初はRedmineの良さをわかってもらえなかったので、余っているサーバで運用でしたが、利用者の増加にあわせてスケールアップや台数追加をしています。ただ、社内で１０００人で使うぐらいなら、MySQLをデフォルト設定で使っていても、さくさく動いて困らなかったです。
リポジトリ連携など、他の連携は？
リポジトリ連携は便利なんですけど、チケット管理とリポジトリビューアは目指す方向が違うので別が良いと思います。レビューチケットとかはタスクと一緒に見えるとうれしそうですが、僕の場合は、ReviewBoardなど専用ツールに移行しました。
ツールの機能比較をしていると、多機能だと選択肢が増えて便利に感じますが、「～もできる」は大抵ベストではなくて、「まぁ、ちょっと便利」レベルにしかならないと思います。もちはもち屋。
プラグインの追加やRedmine自体のアップデート
画面に告知枠を出したり、メンバーにメールで伝えて、業務時間内（昼食時とか）にやりました。文句をいう人はひとりもいませんでしたね。基本的に、別環境にDBのデータごと新しい環境を作ってテスト。よさげだったら本番反映という流れです。
プラグインに関しては、Redmine本体がプラグインに引きずられてしまうので、既存のテーブルを拡張するものはできるだけいれないほうがいいです。本体のアップデートは、リリースノートを見てタイミングを見て導入していけば良いと思います。Railsなので簡単にアップデートできます。
プロジェクトごとの環境構築
タスク管理であれば、基本ひとつのRedmineで十分だと思います。実際は、全体のバグ管理など、複数立てられてしまいましたが、「分けたほうが便利か？」をよく考えたほうがいいです。管理コスト倍増、使い分けの面倒さが起きて残念になりました。
分けようとする人は、自分たちの環境を作りたくて分けたがるので、全体最適かどうかは別の視点で確認が必要です。
どのような「成果」が見える化したか
チケットの大きさや工数など、いろいろ試したくなりますが、使っていくうちにチケットの粒度がそろってくる傾向があるので、各ステータスのチケット数をカウントするだけで、現場の流れがよくわかってきます。そこからベロシティ使ってみたり、いろいろできるはずです。
成果が見えるようになると、メンバーのモチベーションが上がります。成果が上がるともっと良くする方法を考えるようになり、成果が落ちると対策を考えるようになります。
ポイントは、見えるだけにしないこと。数字は数字でしかないので、それを見てどうするかが重要です。行動あってこその見える化。
KPIの設定
僕の場合は、開発の時間と運用の時間がメインKPIでした。もともと、運用が８０％超えている現場だったので、これを何とかしないと本来やるべきことができません。これはとても現場のフラストレーションになるので、なんとかする必要がありました。
データ集計や共有は、リーダーの仕事です。多少、工数入力やステータスのアップデートをお願いすることはありますが、基本は現場は作業に集中すべきなので、（ここでは）リーダーがやる形になっています。データは定期的に開催していたふりかえり（週次から隔週）で、自分なりの分析を添えて共有。課題に対する回答は現場に責任をもってやってもらうようにファシリテーションします。
プラグインを使ってリアルタイムにKPIを・・・もはじめはやっていましたが、そう大きく動くKPIでもなかったので、途中でやめました。
プラグイン
パーキングロットチャートがベストでした。
https://daipresents.wordpress.com/2010/redmine_parking_lot_chart_plugin/
問題のあったプラグインはたくさんありましたが（笑）、DBアクセスが重すぎて、他のユーザの操作まで止まってしまったりするものは使えなかったです。少人数だといいんですけどね。
プラグインの開発は、簡単にできるので、本当にちょっとしたものからやるといいと思います。個人的にいいなーと思ったのは、Redmineにバナー表示できる「redmine_banner」ですね。ちょっとしたお知らせを効果的にできて、現場のアイデアが反映されたプラグインってステキ。
現場運用導入で苦労したこと
プロモーションは、メールでの共有や、Redmineのトップ画面にメッセージを載せたりしたぐらいで、あんまり力を入れてません。「使いたい人が使えば」ぐらいの感覚でやったほうが気楽ですし、本当に良いツールなら勝手に使われます。
苦労を思い出すと・・・。使われすぎたときに「やばいな」と思ったところでしょうか。ルールは作りたくなかったですが、使われるようになるにつれて、一部が全体への影響にならないように、ルールが必要になりました。ただ、ルールは大切なものを守るためにあるべきなので、ただの制約になったらおしまいです。
まとめ
Redmineの記事を書いていると、管理者の方からいろいろ相談を受けます。自分が運用していた時からだいぶ時間が経ちましたが、ひとつだけ言えるのは、ビジョンのないツール導入は失敗します。失敗とは
- 「チケット見ればわかるでしょ」といった不毛なやり取りが生まれたり
- 更新がまちまちでオンラインツールを使うメリットがなかったり
- 「フォーマットが違うからやりなおし」とかルールが制約になってしまったり
世の中の８０％の現場は、Excelで十分なんじゃないかって思うんですよね。でも、それでもRedmineのようなツールを使うってことは、解決したい何かがあるわけで、その道筋を語れない、描けないのであれば、ツールに使われておしまいなのでしょう。
それを避けるために管理者がやれることは、
- 現状のタスク管理の課題定義をして、
- その解決策としてツール導入を説明でき、
- 使い方をユーザに継続的に伝えていく
ことぐらいでしょう。僕の場合は、使い方を伝える時間をとらなかった（自分たちが使えればよかったので、使いたい人は自分で考えてくれという立場をとった）ので、ツールに振り回された現場をたくさん生み出してしまったのだろうと思います。ごめんね（はーと）。
これができないと、Redmine使おうが、JIRA使おうが、何使おうがハッピーにならないんじゃないかと。
旅と子育てとアジャイルコーチのブログ「世界」 
[…] ようにファシリテーションします。 ちょっとしたお知らせを効果的にできて、現場のアイデアが反映されたプラグインってステキ。 [紹介元] Redmineやチケット管理ツールの運用まとめ […]
いいねいいね