ぷろまねさん

グローバルコンサルティング会社でシステム開発・運用保守（アプリ方面）のプロジェクトマネジャーをしています。2014年PMP取得。アジャイル開発などの開発手法、Redmineなどの開発ツールを話題の中心に書いてます。

チケット管理を超えて：『Redmineによるタスクマネジメント実践技法』を読んで

Redmine ソフトウェア開発ツール 書評 プロジェクト管理

今週チームメンバにRedmineを開発サーバに立ち上げてもらい、「とりあえずみんな使い方よく分かんないから適当にいじってみようね」という感じになったので、俄然やる気を出して土日で本書読んでしまった。

Redmineの環境構築方法や、具体的なカスタマイズ方法（設定、プラグイン導入・開発）についてはほとんど触れられていない。それらは別の書籍に譲ることで、本書ではTiDD（チケット駆動開発）の手法をどうRedmineで実現するかを伝えている。これは実際の構築はメンバにお任せで、どう管理するかを模索したい僕には良かった。管理者はこの本を読むのが正解。

タスクも（子）チケットと捉える

これまでも「チケットを作業の単位」にしてきた。むしろ運用保守のプロジェクトであれば通常そうなのではないだろうか？（チケットと呼ぶか否かは別にして）
しかしそのチケットは「インシデント」単位でしかない。ここで言うインシデントは問合せ、障害、作業依頼等をすべて包括した1つの「やっつけなきゃいけない事案」のこと。

インシデントに対しては、ユーザとのコミュニケーションや実際の設計・開発、それにリリース作業等多くの「タスク」がひも付いている。この管理の仕方は次の2種類だろう。

1. WBS的に一括管理

チケット管理システムの作業ログや別途Excelでタスクに分割して管理する。そのためには中央集権的に管理しなければならず、管理工数が非常にかかる。それに対してチケット管理とほぼ分離してしまうので、管理のために利用しづらい。
今の僕のチームの管理状態がこれ。

2. 各メンバにおまかせ

事案の入口と出口（＝起票とクローズ）だけをトラックする。1.のように「細々管理してらんねぇ」となったらこうなる。こうなったら当然管理なんて出来たもんじゃない。
以前の炎上していたプロジェクトの管理状態がこれ。

これに対してRedmineでは親チケットに子チケットを紐付けることが出来る。親チケットをインシデント（XPで言えばストーリカード）単位で起票し、各種タスクを子チケットとして紐付けるわけだ。

タスク単位での可視化

これだけで前述の1.と情報量はほとんど変わらないのだが、これがRedmineのキモになる。

タスク単位でのステータス、進捗率、工数、開始・終了日付がデータ化されるわけだから、分析することが出来る。これが作業ログとしてベタ書きされていたりしたら分析出来ないし、Excelにかかれていたら不可能ではないものの大変。

これまでインシデント単位（もしくはもっと大きな単位）でしか管理出来ていなかったものがタスク単位での管理が可能になる。これは単なる情報の細分化だけの意味以上のものを持っているはず。タスクは小さなインシデント、というわけではなく、異なった性質を持つものだから、これが可視化されるのだから。（具体的なメリットは導入成功したところでまとめてみよう。）

他開発ツールとの連携

個人的には上記がRedmineの最大の利点と見ているが、もう1つ挙げるとしたら本書でも多くのページを割いて解説しているSubversionやHudson（現Jenkins）等との連携だろう。

各ツールを単独で使うよりも連携させることでマニュアル作業が減り開発者・管理者ともに工数削減になるとともに、ここでもデータの有用性が各ツール個別の単純合計以上に増加する。

とりあえずRedmine単独の導入で終わらせてはいけない、と固く誓った。

あとは実践

想像していたやりたいことはRedmineで出来そうだ、そして他ツールも入れればそれ以上のことが出来そうだ、というところに確信が持てたという意味で非常に良い本だった。

あとは実際に導入してみてこの本＋αのプラクティスを経験してみて、というところ。

 

 

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

 

 

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法