脱Excel！ Redmineでアジャイル開発を楽々管理：エンジニアがお薦めする現場で使えるツール10選（3）（1/5 ページ）

ITエンジニアの業務効率を改善するために、現役エンジニアが実際の現場で利用している便利ツールを、10回にわたり紹介します。

» 2009年04月14日 00時00分公開

[あきぴー，＠IT]

Redmineの概要

　Redmineは、Ruby on Railsで作られたプロジェクト管理機能を持つバグ管理システム（BTS：Bug Tracking System）である（図1）。

図1　RedmineのTOP画面（※クリックで拡大。以下すべて）

　ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。

　バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。

　Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。

▼Ruby 1.9 - 概要 - Ruby Issue Tracking System

Redmine運用前の問題点

　筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。

1．Excelでのタスク管理の限界

　従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。

　プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが、チームの人数が多いと、ガントチャートへ最新の作業状態を反映するだけでも管理が大変になる。ほとんどのプロジェクトでは、Excelのガントチャートでしか開発者の作業状態を追跡できないため、プロジェクトのリスクを早期に見つけ出すのが難しい。特に、昨今、開発が短納期・大規模化するにつれて、タスク管理が非常にやりにくくなっている。

2．アジャイル開発のプロジェクト管理は運用のハードルが高い

　昨今の開発プロセスの傾向として、従来のウォーターフォール型開発のアンチテーゼとして、XP（eXtreme Programming）を代表とするアジャイル開発が生まれ、その特徴は一部で広く知られてきた。

　しかし、アジャイル開発はイテレーション計画が頻繁に変更されるため、リアルタイムなタスク管理が難しい。

　また、アジャイル開発では、頻繁なリリースに対応するための機能追加やバグ修正、あるいはリファクタリングによるソース修正が発生するため、ソース修正に対するタスク管理が重要になるが、それらを一元管理して追跡できる環境をそろえるのは難しい。実際、アジャイル開発を運用するハードルは高く、現場では普及しているとはとてもいえない。

　そこで、プロジェクト管理機能を持つバグ管理システムであるRedmineを使ってアジャイル開発を実践してみよう。きっとプロジェクト管理がExcelでの管理よりも楽になるはずだ。

　本記事では、Redmineのインストールやカスタマイズ方法は説明しない。チケット駆動開発の簡単な説明、Redmineでチケット駆動開発を実践しアジャイルに開発する運用方法について述べる。

Redmineのインストール

　インストールは下記を参照しよう（本記事では、Ver.0.8.0の機能で解説する）。

▼Redmine.JP インストール

Redmineの特徴

　Redmineは、Ruby on Rails で作られたプロジェクト管理機能を持つバグ管理システム。GPLで配布されている（2009年4月現在、最新版は0.8.3）。

　Redmineには大きな特徴が4つある（参考：Redmine - Overview）。

ガントチャートがデフォルト表示
チケットでさまざまなタスクを一元管理できる
ワークフロー管理が使いやすい
バージョン管理（Subversionなど）とチケットを連携できる

　バグ管理システム（BTS）は昔から障害管理に使われていたが、このワークフローがとてもスムーズなため、障害だけでなくソフトウェア開発の一般タスクへ汎用化しようという発想が生まれた。

　そこから、チケット管理やガントチャート生成、バージョン管理との連携機能などプロジェクト管理機能を持つバグ管理システムとして、TracやRedmineが現れた。

　そして、TracやRedmineを課題管理システム（ITS）として運用するアジャイル開発手法が最近注目されている。

　この開発プロセスは一部でチケット駆動開発と呼ばれ、アジャイル開発の一プロセスへフレームワーク化できないか、現在筆者が試しているところだ。

チケット駆動開発の運用サイクル

　チケット駆動開発は、Tracのチケット管理をプロジェクト管理として使おうという発想から生まれた。

　筆者は、Redmine上でチケット駆動開発を下記のように、アジャイル開発の一プロセスとして運用しようと試みている（参考：「チケット駆動開発 … ITpro Challenge のライトニングトーク (4) ―― まちゅダイアリー」）

　まず、チケットを障害だけでなく要望にも使う。つまり、チケットをXPのタスクカードのように、ソフトウェア開発に必要な作業指示書（または課題）として扱う。

　チケットの粒度はプロジェクトによって違うだろうが、筆者は「1つの成果物を1人が1週間以内に作る作業」としている。

　つまり、チケットを担当者1人のその週の作業まで細分化する。

　次に、それらチケットはRedmineでいう「バージョン」の単位でグループ化する。このバージョンは、システム開発のマイルストーンであり、リリースするバージョンでもある。XPならばイテレーションに相当する。

　これらバージョンを2～4週間のサイクルでリリースし、アジャイルで開発していく。

　開発中のチケットは、ロードマップやガントチャートやカレンダーといったRedmineのプロジェクト管理機能のおかげで、リアルタイムに可視化できる。

　リリースしたバージョンは、Redmineのチケット集計結果機能で、進ちょくや品質に関する結果（メトリクス）を得られる。管理者は、これらの結果をプロジェクト運営における意思決定の材料として扱うことができる。

　さらに、リリースしたモジュールをユーザーが使ってみて、障害の報告や改善の要望が開発チームに寄せられるだろう。それらの内容を開発チームは吟味して、どのバージョンに障害修正や機能改善を反映していくか、イテレーション計画、あるいはもっとスパンの長いリリース計画を作る。図2は、チケット駆動開発の概念イメージ。