デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。
はじめに
上の資料はそのときのものです（Slideshareはこちら）。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入＆運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。
標準化とか全社共通とかいう仕事
私は入社以来、サービス開発を担当しておらず、サービス開発を支える横断的な組織で働いています。現在は、アンオフィシャルですが「特攻野郎A-Team」というチームのリーダを担当しています。「なんでも派手に解決してやるぜ！」というA-Teamの再放送に興奮した世代ですので、そういう名前をつけました。名前は重要です。
横断的な組織では、「標準化」「共有」「協調」といった、もやっとした言葉が仕事のキーワードとなります。具体的には、開発に近いプロセス整備や、ライブラリ開発、社内SNSであるソニックガーデンさんのSKIP導入、開発標準になりつつあるCIサーバHudson、Subversionといったツールの導入、展開、整備をしています。
全然使われない導入初期
下の図は、Redmineを導入した2008年末から2010年末ぐらいまでの利用ユーザ数を表したグラフです。去年末で1300人を超えるエンジニアが一つのRedmineを利用し、5000人を越えるグループの従業員全体利用へと広がろうとしています。
当時、私は数名のチームの一員で、そこはタスク管理がほとんどされておらず、各自がバラバラに活動していました。私はチームや当時のマネージャに、ツールを紹介・提案しましたが「めんどくさそう」「興味がない」「今忙しい」といったよくある反応が返ってきました。当時はトップダウンからのアプローチが期待できず、ボトムアップで進めるしかない状態でした。
開発プロセスの型をツールで構築する
開発では様々なツールが使われます。OSS、ベンダー製品、自社開発、ちょっとしたスクリプトなど。その中に「新しいツール」を導入することはとても難しいことです。一時的な興味はもっていただけても使われるまで発展しません。しかし、横断的な組織にいることで、社内にある共通の課題を知りました。
それは、各チームの課題管理がばらばらでミスコミュニケーションが発生しているという点です。
課題管理方法がばらばらで、伝える方法もツール or メール…と異なり、沢山のチームがある場合、どうなるでしょうか？一緒に仕事をすることになっても、同じ地図をみて仕事ができません。各自が各自の地図を持ち、それぞれが方向を決めて進む。地図にメモを書き、それらのメモを確認するには、それぞれの地図を確認するしかありません。これはとても不便であり、エンジニアは不便を嫌うものです。
私は、この「足りない地図」という部分に、Redmineというツールをはめ込むことを考えました。私は「標準化」を「大体同じ」と解釈しています。Redmineを使って大体同じ管理方法に誘導し、「同じ地図を見る」形に持っていけないかと考えました。
始まりはまず「自分が」動くこと
自分のチームには、様々なチームから依頼が届くため、手始めに、自分に来る作業依頼をRedmineで管理するようになりました。これにより、必然的に相手はRedmineを見るようになります。Redmineを使って快適に作業を処理する姿を、依頼元に伝える効果があったのではないかと思います。
次に情報の共有です。困っているチームの話を聞くと「私のチームの運用方法」や「他部署の事例」を共有しに行くようにしました。さらに、使い方やアイデアを社内SNSに連載形式で掲載したり、Redmineの新機能情報などもどんどん展開しました。合わせて使うときのルールも整備していきました。
そして、自分の所属するチームのプロセス改善に取り組みました。課題管理に苦しんでいたチームは、やがてRedmineを使った作業管理を受けいれてくれるよ うになりました（半ば強引でしたが）。そして、外部との折衝はすべてRedmineで管理されることとなり、さらにRedmineが社内でも認識されるようになります。
型の多様性問題
徐々に広がっていくRedmineですが、コンテキストが異なる場で利用されると、新たな課題が浮かび上がりました。それは、コンテキストが異なることによって発生する型の違いです。利用者は様々な「やりかた」を持っていて、それにあった機能やを要求します。そして、その大半は、あるリーダーは「作業時間」に着目したビューをほしがり、あるリーダーは「ガントチャート」を重視するといった異なるビューでした。
残念ですが、これらの要求すべてに答えてくれるツールはきっと存在しないでしょう。
なにせ、最終的に900を越えるプロジェクトが作成された環境です。私は、ツールの柔軟性を維持したまま拡張性を高めていく方法として、Redmineにプラグインとアジャイルのアイデアを組み込むことを考えました。
プラグインの活躍
一番初めに導入したのが史上最高のチームプラグインです。
自分の新しい上司の「今のチーム状態がもうすこし見えるようにしたい」というリクエストから作成したのがこのプラグインです。作業者の稼働時間とアクティビティを表示しただけのプラグインですが、現場の「今」がわかります。上司も喜び、以後はこれをつかって進捗報告をするようになりました。チーム内に共通の地図ができました。
しかし、これを続けては要望の数だけプラグインができてしまいます。それをなんとかするため、アジャイルのアイデアをRedmineに注入しました。あきぴーさんのブログやRedmineのプラグインサイトで見つけたプラグインを動くように修正し（動かない事が多かった）次々と導入していきました。
余談ですが、プラグインの導入の際は以下の点に注意する必要がありました。
- 日本語表示できること
- データ更新がないこと
日本語化されていない場合は自分で翻訳しました。そして、既存テーブルを更新するようなプラグインではなく、データの読み込みだけで動くプラグインを選ぶことで、「Redmineのバージョンアップで動かない」といったトラブルを防止しました。継続して使えることはツールの重要な要素です。
アジャイル開発に登場するビューは、とても完成されています。なんでも表示できる柔軟なビューも考えたのですが、今あるいいものを活用することを選択しました。さらに、すばらしいアジャイル本であるアジャイルな見積りと計画づくりからさらにアイデアを得たため、バーンダウンを理解するためにバージョンバーンダウンプラグイン、パーキングロットチャートプラグインを作成しました。
Redmineにアジャイルを注入することで、Redmineのロードマップから、チームはイテレーションを意識するようになり、正確なバーンダウンチャートを得るため、正確なスプリントの期間を考える必要がでてきます。さらに、チケットからストーリーへ。ガントチャートからタスクボードへと、ちょっとの示唆で、開発方法がアジャイルのアイデアへと近づいていきます。
ツールもアジャイルに進化する
偶然、ユーザ数が増え始めた頃は、Redmineの開発が盛んでした。よって、たくさんの機能が実装され、短い期間でどんどん改善されていきました。RedmineはRailsでできているため、バージョンアップも簡単にできます。バージョンが上がったら即検証を行い、すぐに導入。これを繰り返し行っていくことで、ツール自体もアジャイルに加速していきます。
機能の変化にとまどうユーザも多かったですが、機能がよりよくなることを説明するだけでユーザはついてきてくれます。ツールがより柔軟になることにより、運用も柔軟になり、version0.9あたりで可能になった「プロジェクト作成権限設定」などによって、さらに運用が軽くなり、Redmineが自走するようになりました。
まとめ
ここまでくると、ユーザ数はうなぎのぼりに増えるようになりました。昨今のアジャイルムーブメントもあり、アジャイルに関する質問も多く来るようになり、アジャイルの社内啓蒙活動にもつながりました。今思えばですが、Redmineを導入するというスプリントに2年かかりましたが、今後数年で会社もアジャイルに変わっていくといいなぁと思っています。
最後に、これらのアイデアをくださった方々に感謝します。特にRedmineへScrumのアイデアを注入 via あきぴーさんからはたくさんのアイデアを頂きました。さらに、Agile Japan 2010で知った「変化を受け入れるアジャイルなプロジェクトマネジメントと現場 <ツール・環境篇>」には衝撃を受けました。標準化に従事するものとして、この発表には深く感銘しました。この記事に書いた「示唆する」という表現も、上記発表の「傾向化」という考え方があってのことだとおもっています。ありがとうございます。
今回は、Redmineの導入部分について説明させていただきました。次は、運用やRedmineのその後、使い方のパターンなどをまとめようと思います。
旅と子育てとアジャイルコーチのブログ「世界」 