プログラマーズ雑記帳

Redmine はバグ管理、プロジェクト管理のシステムです。
これらの用途に使用するためには、チケットを使います。

トラッカー

チケットはバグ報告、機能追加のタスクのどちらにも使用します。 このチケットの種類を決めるのが、トラッカーでデフォルトでは以下の 3 種類です。

トラッカー	用途
バグ	不具合報告
機能	機能追加
サポート	不具合修正、機能追加のどちらでもない作業

ほとんどの場合、開発作業はバグまたは機能にわけることができると思います。 ただ、テスト環境の準備といった直接には開発に関係のない作業が必要なときもあります。 こういうときにはトラッカーをサポートにしたチケットにします。

これで足りないなというときは Redmine では新しくトラッカーを追加することもできます。 また、チケットの種類を細分化したいというときは、 カテゴリを使用します。
トラッカーの追加はシステム管理者のみが可能で、システム全体に対してトラッカーを追加するのに対して、 カテゴリはプロジェクトの [設定] ページで追加できます。
デフォルト以外のものが欲しくなったとき、トラッカーを追加するかカテゴリで分けるかというのは難しいところですが、次回説明するワークフローを変えたい場合にはトラッカーの追加となります。
いろいろとトラッカーを追加したいと思われることは多いと思いますが、 やりすぎると混乱のもとになります。この 3 つでも結構十分なので、使いなれてくるまではこのままで、やってみるのがいいかなと思います。

バージョン

チケットはバージョンに関連づけることが出来ます。
バージョンは通常 1.0.0 、 1.5.3.42 のような型式ですが、まだ明確にきまっていない場合は "初期開発" や "Linux 移植" といった内容を表す名前でもかまいません。後から名前を変更することも出来ます。

[ロードマップ]ページでバージョンに関連づけられたチケットの一覧と バージョン全体での進捗をみることができます。
このバージョンが完了した時、 このロードマップがちょうどリリースノートのようになるようにチケットを作るのが、基本的な使い方ではないかと思います。


このため、バージョンの使い方で一つ注意点があります。
バグ報告で対象バージョンを指定する場合、 対象バージョンはバグの発生したバージョンではなく、 バグを修正するバージョンを指定することです。
バグをどのバージョンで修正するかは開発側が決めるものなので、 もし自分が開発者ではない状況でバグ報告を出す場合、 チケット作成時に対象バージョンは指定しないようにしてください。

バージョンの作成

新しいバージョンはプロジェクトの [設定] ページから作成します。

ステータスは作成時には [進行中] のままにしておきます。
バージョンをリリースするなどして完了した時に [完了] にします。 [ロック中] は保留のような状態になります。

• バージョンのロックと終了 | Redmine.JP Blog

Wiki ページはバージョンにもっと詳しい説明をつけたい場合にページ名を書いておきます。 ページの内容がロードマップの説明に追加されます。
ページは後で修正できますし、まだ存在していないページの名前でも構いません。

共有は前回あげた Foo システムの例のようにプロジェクトが複数のサブプロジェクトを持つ場合などで使用します。共有しておけばサブプロジェクトのチケットも同一のバージョンに関連づけれれるようになります。
共有範囲は細かく選択できますが、共有するようなバージョンは親のプロジェクトで作成することが多いので、 [すべてのプロジェクト] 以外はどれを選んでもあまりかわりません。

• バージョンの継承 | Redmine.JP Blog

バージョンの追加

チケット編集時にも + のボタンを押すことによって、新しいバージョンを追加することができます。

細かい設定はできませんが、チケットを編集する時に気づいて、 [設定] ページに戻って作ってから、 再度、チケットを編集するという手間が省けて便利です。
後から変更もできますし、バージョンを作成するときにそんなに細かい設定が必要ないことが多いので、 バージョンは結構こちらで作成することの方が多いです。

ただし、バージョンがひとつもないとバージョンの項目自体が出てこなくなり、 チケット編集画面でのバージョンの作成はできません。

---

Redmine の基本的な使い方であるバグ管理システムとしての使用法を説明します。

ワークフロー

Redmine を使用するためにはワークフローを理解する必要があります。 ワークフローというのはチケットのステータスの変化の流れで、トラッカーとロールによって変わってきます。

ただし、デフォルトの設定ではバグ、機能、サポートの 3 つのトラッカーで同じフローとなっています。

このワークフローは通常、システム管理者しか確認できません。
Redmine インフォメーション プラグインがインストールされていれば、 [情報] → [ワークフロー] のメニューからワークフローを表示させることが出来ます。 また、システム管理者でも表でしか確認できないので、流れを理解するのはなかなか難しいですが、プラグインではさらにワークフローを図で表示することもできます。
参考書やサイトにもフロー図が載っているものは多いですが、 このプラグインを使えばトラッカーやスタータスを追加したとしても、現在の Redmine の設定でのワークフロー図をみることが出来ます。

以下は、デフォルトでの開発者と報告者のワークフローです。 (管理者はすべてのステータスに変更可能です)

フローの矢印の方向にしか変更は出来ません。 例えば、開発者は [進行中] と [解決] 間はどちらにも変更できますが、 いったん [終了] にすると他のステータスに変更できなくなります。

バグ管理の流れ

バグ管理の流れを例を挙げて、説明したいと思います。
例としてはロールのところであげた Foo システムのように複数人で開発しているプロジェクトを考えます。 ただし、シンプルにするため、サブプロジェクトはないものとします。 サブプロジェクトがある場合はチケットの移動なども行う必要があります。

基本的な流れは次のようになります。

1. バグ報告 [新規]
2. 担当者の割り当て
3. 修正の開始 [進行中]
4. 修正作業
5. 修正の完了 [解決]
6. 修正の確認 [終了]

1. バグ報告

開発者、テスタ等

バグを見つけた人がバグ報告を行います。 バグ報告は報告者のロールやメンバ外のユーザーでも可能です。

バグ報告はトラッカーを [バグ] としてチケットを作成します。

1. 対応プログラムのプロジェクトを開く
2. [新しいチケット] を選択
3. トラッカーを [バグ] に設定(デフォルト)
4. その他の必要項目を記入し、 [作成]

基本的に入力する項目は [題名] と [説明] です。
開発メンバーの場合はその他の担当者などの項目も分かるものは設定しておきます。
逆に [対象バージョン] は修正するバージョンなので、開発メンバーでなければ入力しない方がいいでしょう。

これらの項目は後から編集(チケットの更新)することが出来ます。 ただし、題名や説明などを変更する方法は若干分かりづらいです。

• チケットの登録 | Redmine.JP
• チケットの更新 | Redmine.JP
• チケットの題名・説明を変更する | Redmine.JP

2. 担当者の割り当て

管理者など

チケットを追加された後、プロジェクト管理者は担当者が未定のままの場合は担当者を推測します。
Redmine で チケットの [更新] から担当者に推測した担当者を設定します。 担当者など一項目の変更であれば、チケット一覧の右クリックメニューからでも変更できます。

• Redmine の気がつきにくい機能 | Redmine.JP Blog

この割り当ては管理者でなくてもかまいません。 例えば、バグは大抵 GUI として現れるので、 GUI 担当者が原因箇所を特定して割り振りを行うといった具合です。
ただし、この割り振りを行う人は後の回で説明するメール受信の設定でプロジェクトのすべての変更を受け取る設定にしておく必要があります。

2B. 報告を却下

管理者

バグと思われたものが、環境設定のミスとかだった場合や「バグではなく仕様です」 と言い張る場合(^^;) にはチケットを却下します。
この場合には、ステータスを [却下] に変更します。

[却下] のステータスは開発者や報告者のワークフローには出てきません。 これはバグ報告を [却下] できるのが管理者だけであるためです。

3. 担当者の決定、修正作業の開始

担当者(開発者)

担当者として割り当てられるとその担当者にメールが届きます。 担当者候補は自分の作業かどうかを確認して、修正作業を開始します。

チケットの [更新] から以下の項目を変更します。

• ステータスを [進行中]
• 開始日 を変更
• 期日
• 予定工数
• 対象バージョン

Redmine の昔のバージョンでは [進行中] のステータスは [担当] でした。 そのころにデータベースの作成を行っている場合はステータスは [担当] になっているかも知れません。

実際には、担当が自分でない場合や調査後、 バグでないと判明した場合は管理者に連絡して 2 の状態に戻したり、 予定工数だけ報告して、開始はプロジェクト管理者の Go がでてからという手順を踏むこともあります。

4. 修正作業

担当者

担当者はバグの修正作業中は定期的に以下の項目を設定します。

1. 進捗 %
2. 作業時間の記録
3. 活動

ここでの更新はタスク管理や工数管理に利用している場合で、 単にバグ管理として使うだけであれば、経過の入力をしなくてもかまいません。

5. 修正作業完了の報告

担当者

担当者は修正作業が完了したら、作業が完了したことを Redmine で報告します。
チケットの [更新] からステータスを [解決] に変更します。

チケットのステータスには [解決] と次項の [終了] の 2 つがあり、紛らわしいですが、 チケットは [解決] のステータスでは終了したものとして扱われません。 [解決] は言い換えると 確認待ち の状態です。

6. バグの修正確認

チケット作成者(バグ報告者)など


[終了] または [却下] ステータスのみ、チケットがクローズしたとみなされます。 修正内容を確認して [解決] を [終了] にする必要があります。

チケットを [終了] にする人はいくつか方針があると思います。

• 開発者が行う([解決] ではなく、直接 [終了] にします)
• プロジェクトリーダー(管理者)が行う
• チケット作成者が行う

私としては、バグ報告者と修正担当者が違う場合には対象となるバグに対して認識が違っている可能性があるので、基本的にバグ報告者が確認して [終了] にするのがいいのではないかと思います。

ただし、そうした場合、デフォルトの設定ではプロジェクトメンバーではない人(Non member)がチケットを作成すると、ステータスを変更することは出来ません。 そのため、 Redmine の管理ページから Non member に [チケット作成時の追加の遷移] として以下の遷移を追加します。

• [解決] から [終了]
• [解決] から [フィードバック]

流れの例ではバグ報告者がチケットを [終了] にするようにしています。
チケットの作成者は作成したチケットの変更に対して自動的にメールを受け取るようなっているので、 チケットが [解決] に変更された通知も受け取っています。

6B. フィードバック(差し戻し)

チケット作成者(バグ報告者)など

[フィードバック] の用語も分かりづらいですが、差し戻しの意味になります。
担当者が [解決] にした後、 修正対象や結果がバグ報告者が思っていたのと違うということになった場合に チケットのステータスを [フィードバック] に変更します。

[フィードバック] になったものは、担当者の修正作業に戻り、3. から再度修正を行うことになります。

終了時に進行率を 100% にする

チケットの [終了] 時には進行率を 100% にする必要があります。 これをしていないとロードマップでバージョンの進捗がきれいに表示されません。
ただ、意外とこれを忘れたりして、進捗率を直すだけでメールが飛んで悪いなと思ったりします。

こんなときには Issue Extensions プラグインです。 チケットを終了にした時に、進行率も自動で 100% にしてくれるようにできます。
このプラグインは他にも関連するチケットを指定しやすくするなど、 あると便利だなというチケット関連の機能を提供してくれます。

---

今度は Redmine のバグ管理ではなく、タスク管理、工数管理としての使用法について記述します。

チケットはバグだけでなく、機能というトラッカーがあります。 これを使うことによって、バグ管理だけでなく、 プロジェクト開発全体を管理するプロジェクト管理システムとして Redmine を使用することが出来ます。
ただし、バグ管理とタスク管理はきちんと切り分けられるものでもないので、 タスクや工数管理の視点からみたポイントぐらいに考えてください。

作業フェーズごとのチケット作成

プロジェクト(タスク)管理システムとしての利用を考えた場合、 新規作成やメジャーバージョンアップなど多くの機能を一度にするときには、 機能別にチケットを作成するよりも、設計、実装、テスト といった作業フェーズごとに分けたいことがあります。
こういった場合、作業フェーズごとにチケットを作成しても問題ありません。
フェーズごとに分けたチケットを関連付けるためには、次のような方法があります。

• バージョンで関連づける
• 親チケットを作成し、子チケットとして分ける
• チケットの関連付けの機能を使う

どれが一番いいともいえないので、使いやすいものを選んで使用してください。

タスク管理

機能追加としてチケットを利用する場合、 チケットの作成者が開発者自身であったり、仕様を決める人であったりするだけで、 基本的な流れはバグ管理システムのときと同じです。

ただし、タスク管理、進捗管理として利用する場合は、 開始日、期日等の日程と進捗率を入力することが重要になってきます。 これらを入力することにより ガントチャート 、 カレンダー などから作業の進捗、予定を確認することができます。

ガントチャート

ガントチャートを表示するにはプロジェクトメニューの [ガントチャート] のタブを選択します。 このガントチャートではサブプロジェクトのチケットの進捗もあわせて表示されます。

Better Gantt Chart をインストールしていると関連付けされたチケットで矢印も表示してくれるようになります。

工数管理

工数管理として利用する場合には 予定工数 と 作業時間の記録 を付ける必要があります。
活動 はフェーズごとに 機能追加やバグ修正にどれだけの時間がかかったかという情報を残すために使用します。

工数管理のプラグインとしては以下のようなものがあります。

プラグイン	説明
Work Time	工数入力を簡単にする
Time Tracker	ストップウォッチのような感じで工数を記録できる
Advanced Roadmap	工数情報つきでロードマップを表示する

---