詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）

最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。

今回は、Shibuya.trac第12回勉強会～チケット管理システム大決戦　第二弾～で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。

Redmineのプロジェクト画面

上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジュールがあります。しかし、

パーキングロットチャート
チケット一覧
たまに活動

を使う以外は、まったく使わなくなりました。当初は自分で作ったバーンダウンチャートなども使っていたのですが、私のチーム作業の性質上合わない部分があったため、今は使っていません。

余談ですが、A-Teamという名前は、「特攻野郎A-Team」のように、問題をあっという間に解決するチームにしたかったので、A-Teamという名前をつけました。よく、「A-TeamのAはどういう意味？」と聞かれるのですが、「アジャイルのAだ」とか「アーキテクトのAだ」とか「ありがとうのAだ」とか、適当なことをいうようにしています。チームを持つなら名前は重要です。

バックログの管理はExcel
バックログはExcelで管理しており、これをベースに「とあるリリース日」に対して、どこまで実装可能かを説明するようにしています。あとでも説明しますが、チームのベロシティは測定できているので、あとは上からどこまで作業を積めるかだけ考えればいいようになります。

Excelの場合、優先度を変更したときのログなどが残しにくいので、いずれは、ビジネスサイドや開発を問わず、すべてのやりとりがRedmineで管理され、それぞれのタスクの関連や状況がリアルタイムで共有できるようにしたいと思っています。

タスクボードとチェックポイントの活用

現在は、大きなタスクボードを作り、タスク状況を貼り出すようにしています。今はポスト・イットとRedmineチケットの二重管理になっており、開発者は開発に集中すべきだと思うので、その管理はすべて私がやるようにしています。最近は同期がめんどくさくなってきたので、別の方法がないかと考えているところです。

タスクボードで「常に見える」状況なのですが、それ以外に、以下のような作業チェックポイントをつくっています。

毎朝の朝礼
週1回のふりかえりや情報共有、課題検討MTGを1時間

MTGをできるだけ減らすために、進捗報告会などは一切していません。週次のMTGも情報共有や課題検討に時間をかけるようにしています。私にとっては、進捗の確認は朝礼で十分であり、週報のようなレポートよりも、フェイス・トゥ・フェイスのほうが質が高いと思っています。それほど重要な朝礼なのですが、朝礼に来ないアホ社会人（エンジニアに多い）がいたり、電車遅延で全員揃わないケースがあるので、やる時間は考える必要があります。

「朝礼でわかりやすく簡潔に報告できること」「時間をまもること」は、チームのメンバーに一番最初に覚えてもらう仕事でもあります。

チケットには予想と実績を考えてもらうための入力を作る

スプリントの終わりの日には、チームでふりかえりを行います。その後、本来は、スプリントレビューとスプリント計画をチームで実施したいのですが、作業の性質もあってそれはせず、個別にタスクを相談しながらチケット化しています。

導入当初は、Redmineのチケット一覧を見ながら、私とペアでで予想と実績（備考欄）を入力します。できれば、先に予想を書いて欲しいのですが、そこまで厳密にしなくてもいいやーということでこうしています。予想をあとで考えるのは変な感じですが、「2日だとおもってたけど、3日ぐらいだった」とかで、相対的なコストや作業状況がわかります。

そして、次のスプリントのタスクを整理し、優先順位と作業のサイズ確認を行います。さらに、「どうやったら終わりとするか」を決め、チケットの概要にそれを記述するようにしています。

メンバーには、チケットにコメントを残すようにうながしています。コメントは、毎日入力するわけではなく、「仕様が変わったとき」とか「予定が変わったとき」「問題が起こったとき」など、イベントごとに残せばOKとしています。日記みたいな感じです。

パーキングロットチャートでスプリント状況を見える化

私のチーム作業マネジメントはこの画面を中心に行います。チームでは「イテレーション」よりも「スプリント」のほうがかっこいいので、「スプリント」と呼ぶようにしています。

パーキングロットチャートによって、それぞれのスプリントの健康状態をチェックできます。赤いスプリントは次のスプリントに入れておらず、オレンジだとピンチを表します。シンプルでぱっと見て分かるので、個人的にとても気に入っています。

スプリントのほとんどは「05/11-05/24」のように作り、期間が決められているプロジェクト系の作業は、2週間ごとに「○○Sprint1」や「○○対応」という命名規則を使っています。どちらかというと、バージョンは「作業の大枠」を表すほうが良くて、「○○対応」「○○改善」のように名前をつければ、完了したバージョンを表示するだけで、「我々の成果は何か？」が明確に見えるようになり、「進んでいる感」がでて、チームのモチベーションも上がります。

思いついたアイデアはBacklogというバージョンにチケットを残し、毎年12月は作業を完全に止めて「今年もありがとう！棚卸＆改善月間」として、アイデアの消化だけを行う期間を設けています。

チームスピードの計測

Redmineでアジャイルチームのスピードやパワーを見える化するでも説明させていただいたのですが、スプリントごとのベロシティをExcelでグラフ化することにより、スプリントごとのトレンドを計測しています。ベロシティは「そのスプリントでチームが達成した作業の合計日」と定義し、100％完了したタスクのみカウントされます。

仕掛りタスク（作業途中のタスク）は次のスプリントに持っていくかどうかを確認し、あまりにも終わらないタスクは「やる必要がない」と判断して、これまでのコストはカウントされません。よって、「終わらせないと成果につながらない」ことになるので、メンバーは「完了の定義」を意識せざるをえません。

RedmineからダウンロードしたCSVからExcelガントチャートを作る

マネージャ層の視点はチームの視点とは異なるため、ガントチャートのように「おおまかな」進捗を確認したいため、RedmineからダウンロードしてきたCVSを貼りつけるだけで、ガントチャート表記するExcelを作りました。しかし、はじめは喜ばれるものなのですが、全然使われないので、何か言われたらこれをみせるぐらいの気持ちでやっています。

チームも変化していく

「Redmineをただ単に使いたい」のであれば、バグ管理や問い合わせ管理といった「外部が要因となる作業」だとやりやすいはずです。個人用TODOにRedmineを使う人もいますが、Redmineはそういうツールじゃない気がしています。

現在の私のチームは、プランニングポーカーをやってみたり、見積と計画づくりゲームををワークショップ形式でやってみたり、ツールだけではない様々なTryをするようになってきました。また、スプリントでリズムもうまれ、改善のサイクルも生まれてきました。

こうなってくると、チームのプロセスは、よりアジャイル開発へと向かっていくようになりました。

ツールへの依存は変化していく

パーキングロットチャートによって、達成したことを見える化して報告したり、チームの状況をチケット単位でロギングしたり、なれるまではチームも大変です。

当初は規律が強くあったチームも、それがやがて空気のようになり、現在は協働作業の場としてRedmineが存在する形になってきました。メンバーがログを残すことで、引継ぎコストが下がったり、困ったときにチケットを検索することで、過去の経緯や、ナレッジを調べることが可能になります。

Redmineは、メンバーの経験データベースになっていきます。

まとめ

はじめに、私は「リーダー」というものを仕事にすることが多く、ほとんどの場合が、1からのチームづくりです。どのチームもそうなのですが、外部要因を除いた場合、

タスクがなかなか終わらない
タスクの優先順位が決まっていない
レポートラインを作りきれていない

といった課題が多く、いつもこれらの解決案を考えることから初めている気がします。

アジャイル開発はもちろんなのですが、Redmineのようなツールでもこのあたりを意識した開発プロセスを作ることができます。

タスクの長期化問題を、スプリントのふりかえりや、チケットの運用でフォロー
相談して決めた優先順位がつけられたチケット
朝礼やRedmineのレポートビューを組み合わせることによるレポートラインを平準化

Redmineの場合、こういう枠組みが実装されているので、よりサポートしてくれるように思います。
よく「どうやったらRedmineを使ってもらえるか」や「Redmineを使いこなす秘訣はなにか」と聞かれるのですが、はじめの一歩に必要なのは、運用や導入する側の「ビジョン」や「コンセプト」だと思います。

私のコンセプトは「チームの作業の流れを整理し、成果を見える化する」でした。

ツールは開発チームを支えてくれますが、そのかわりに、ツールも導入者の力を必要としています。「このツールで何を実現したいのか？」をまず整理し、それぞれの現場で理想とする開発プロセスを探検する勇気が必要だと思います。勇気や想像力により、価値のある規律や、価値を体験できる流れを作り出さなければなりません。

ちょうど今、「プレゼンテーションZen」を読んでいるのですが、そこにこんな言葉が書いてありました。