導入に成功するための運用ルールについて
２０１４年１１月１５日
松谷 秀久（@mattani)

チーム内の役割分担はどうすればいい？
古いチケットがいっぱいたまってしまう・・・
Excelの課題表と同じじゃないの？
どうカスタマイズすればいいんだろう？
運用のコツがわからないなぁ・・・
ワークフローってどう使うの？

自己紹介
アンチパターンについて
Redmine導入のアンチパターン
◦ チケットライフサイクルと運用ルール
◦ Redmineの世界と現実の課題をどう結び付けるか
まとめ

ハンドルネーム
＠mattani
所属
NTTコムウェア（株）
Redmine歴
◦ 約２年、自チームのタスク管理で使用
◦ お客様に課題管理システムとして提案 他
連携させているツール
◦ Subversion
◦ Jenkins
◦ Rsync
Redmine以外で使ったことのあるITS
◦ Mantis、Trac

アンチパターンとは、問題に対する不適切な解決
策を類型化したものです。
Redmineは非常に柔軟性の高いツールなので、
うまく使うためにはすこしコツが必要です。
私の経験から、Redmineを使っていて感じた
アンチパターンとその対処法をご紹介します。
状況によっては異なるご意見もあるとおもいます。
この後のオープンディスカッションで発言してい
ただけると幸いです。

チケットのライフサイクルは、簡単化すると以下
のようになります。
◦ このライフサイクルを停滞させないようにするため、
あらかじめ運用ルールを決めておく必要があります。
チケット発行
活動中
完了（終了したチケット）

《チケット発行担当者の固定化》
アンチ
パターン
症例
1. 導入当初によく見られる。
2. よく知っている施策推進者に、チケットの発行までやってもらおうとする初心者（担
当者）が多発する。
対処法
（おすすめルール）
1. チケットは、各担当者が気づいたときに発行するものとする。
2. 重複したときは後から消せばよいので、共有すべきタスクはどんどんチケットを発行
推奨する。（忘れるよりマシ）
3. 不要になったチケットは作業管理者が「破棄」にする。
補足
1. 推進者がチケットを発行することにより、施策の推進が進んでいるような錯覚をする
場合がありますが、逆効果です。
2. 初心者向けの運用マニュアルを作成するのもよいでしょう。
3. 早期に、自律的にredmineをつかえる担当者を増やすのが、施策定着の早道です。

《担当者の固定化》
アンチ
パターン
症例
1. Excelで課題を管理してきた人によく見られる。
（Excelでは担当者を書き換えると、検討経緯がわからなくなるため）
2. 課題を提案した人が最初の担当者にアサインされる傾向にある。
（最初に言ったものが損をする？パターンに陥る。）
3. 重症化すると、課題があっても見て見ぬフリをするようになる。
対処法
（おすすめルール）
1. 別の人に作業を委任したい場合、依頼事項を書いて、その人に担当者を変更する。
2. 必要に応じて作業管理者が担当者をアサインしなおしてもよい。
補足
1. Redmineではチケットの変更の履歴が残るので、今アクションしなければならない人を
担当者にするのがおすすめです。
2. 関連症状として、《承認者不在》（次ページ）も参照してください。
3. 「担当者固定」パターン（ｂｙ＠akipiiさん）も参照してください。

《承認者不在》
アンチ
パターン
症例
1. 担当者はタスクが終わって、内容はコメントに記述したが、それをだれがいつ承認す
るのかわからない。
2. 一方、担当者が勝手に「完了」ステータスにされると、個人メモによるタスク管理と
同じになってしまう。
対処法
（おすすめルール）
1. 担当者は、タスクが終わったら、必ず担当者を作業管理者に変更し、ステータスを
「レビュー待ち」に変更する。
2. 作業管理者は、レビュー待ちのチケットが回ってきたら、内容を確認し、OKであれば
OKの根拠を書いて、ステータスを「完了」にする。NGであれば、何がNGか書いて、
ステータスを「差し戻し」にする。
補足
1. 別名《ポテンヒット》 担当者と承認者、両方が手を出さずにころがってしまい、
本来実施すべきアクションが遅れます。声、出していきましょう！
2. チケットに書くだけでなく、お互いに声かけあうと、コミュニケーションがスムーズ
になります。

《塩漬けチケット》
アンチ
パターン
症例
1. 長期間放置され、検討もされず、完了もされないチケットがある。
2. 重要なチケットが、塩漬けチケットに埋もれて、アクションが遅れてしまう。
対処法
（おすすめルール）
1. チケット発行時に、必ず「期限」を決めること。当面期限がない場合は、１週間程度
の仮期限を入力しておくこと。
2. 期限が入っていないチケットは、作業しなくてよい。
3. 塩漬けになってしまったチケットは、思い切って「破棄」すること。
補足
1. 「破棄」というステータスを作っておけば、あとで必要になったときに、再度オープ
ンすることができます。
2. 定期的にチームでステータスミーティングを行い、重要なチケットの状況を確認し、
期限を過ぎているものがないか、塩漬けになっているものがないか、レビューをする
とよいです。
3. 「中長期課題」というようなバージョンを作って、期日をすごく長くしておく、とい
う方法もあります。

プロジェクトはどういう単位で作るか
◦ Redmineのプロジェクトの定義
すべてのチケットはいずれかのプロジェクトに含まれる。
一般的に言うプロジェクト、すなわち期限までにある目的を達成
するための業務がRedmineのプロジェクトにほぼ対応。
◦ 現実の仕事では・・・
チームは、期限が来たら解散する、ということはあまりない。
複数のプロジェクトに対し、同時に関わることもある。
◦ このような場合、どのようにRedmineプロジェクトを
作成すべきか？
A1プロジェクト
A2プロジェクト
チームA

《俯瞰できないプロジェクト》
アンチ
パターン
症例
1. 同じチームなのに、複数の個別Redmineプロジェクトに割り当てられている。
2. 相互のプロジェクトが関連づけられていない。
3. チーム全体のタスク割り当て状況が確認できない。
補足
1. チームが異なる場合は、親子関係ではなく、複数のプロジェクトにする。
2. バージョンを割り当てると、ロードマップを表示することができるので便利です。
（次ページ参照）
3. 「サイロ型プロジェクト」パターン（ｂｙ＠akipiiさん）も参照してください。
対処法
（対処法１）親プロジェクト、子プロジェクトの形にする。
⇒A1、A2が特に内容の相関のない業務の場合、この形がおすすめ。
（例：A1＝開発業務、A2＝維持管理業務）
（対処法２）チーム全体＝プロジェクト、A1～A3＝バージョンにする。
⇒A1、A2が同様の業務の場合、この形がおすすめ。
（例：A1＝STEP1開発、STEP2開発）
チームAプロジェクト
A1プロジェクト
A2プロジェクト
チームAプロジェクト
バージョンA1
バージョンA2

プロジェクト－設定ーバージョンー新しいバー
ジョンにバージョンを登録すると
設定－バージョンに登録すると、ロードマップ
タブが表示され、バージョン毎の進捗状況を
確認できるようになる。
（バージョンを１つも登録していないと
ロードマップタブは表示されない）

カテゴリ、バージョンを登録している カテゴリ、バージョンを登録していない
プロジェクトの設定で、バージョン、カテゴリ
の値が登録されている場合のみ、「新しいチ
ケット」画面で、対象バージョン、カテゴリを
選択することができるようになる。

ワークフローってどうつかうの？
◦ Redmineのワークフローとは
ワークフローとは、ユーザーがチケットのステータスをど
のように変更できるのかを、 トラッカー とロールの組み合
わせごとに定義したもの。
◦ どう活用するか
特定のステータス遷移に制約を持たせたい場合に便利
例：開発者は、「作業中」から「完了」「破棄」にはできない。
必ず、管理者の「レビュー待ち」に変更し、
「完了」「破棄」は管理者が行う 等。
全員の動きをコントロールできるような小チームの場合、
ワークフローで制約しなくてもあまり問題ない。

《縛りすぎワークフロー》
アンチ
パターン
症例
1. 小さなチームなのにワークフローの制約をかけてしまい、ステータス遷移が面倒。
2. ステータスで管理せず、説明欄やカスタムフィールドで状況を管理してしまう。
補足
1. 面倒な制約をかけすぎると、ツールとして浸透しなくなります。
2. 操作がシンプルに考えられるように制約をかけるのがいいとおもいます。
対処法
1. 小チームでは、ワークフローは使わなくてもよい。
（すべてのステータスに自由に変更できるように定義しておく）
2. チームからチームへのチケット渡しを行う場合など、相手側チームのコントロールが
できないのであれば、ワークフローで制約をかける。

ワークフローの例
上：管理者＝どんなステータスへも変更可能
下：報告者＝「破棄」「完了」はできないよ
うに制約している。

チケットはどういうサイズにすればいい？
◦ チケットのサイズ感については、正解はありません。
◦ 私は以下のようにしています。
チーム内で互いに共有したいと思ったら、チケットにする。
あえて定量的な目安でいうなら、半日以上かかる作業は、
チケットにする。
半日以上かからなくても、リポジトリのファイルを修正を
加える場合は、チケットにする。
単なる伝言や、ルーチンワークは、チケットにしない。
大小様々な粒度のチケットができますので、親チケット－
子チケットや関連チケットを使用する。

《細かすぎるチケット》
アンチ
パターン
症例
1. 細かいことまで、すべてをチケットに登録しないと気が済まない。
2. 毎日／毎週のルーチンワークまでチケットに登録して作業している。
3. チケットはあっても、中に細かい説明や作業結果は書いてない。
補足
1. 最低限、発行時に、背景、目的、完了条件くらいは書いておくべき。
2. 発行時に書くべき内容を統一するには、IssueTemplateプラグインがおすすめです。
（ｂｙ @akiko_pusuさん）
対処法
（おすすめルール）
1. チケットを切るなら、概要と説明をちゃんと書く。
これを書かないのなら、チケットにする意味はあまりない。
2. 毎日、毎週のルーチンワークのチケットは切らない。
月次作業などは、あらかじめチケットに登録するとよい。

《超巨大チケット》
アンチ
パターン
症例
1. とても大きな課題を１つのチケットで処理しようとして、どこから手を付ければよい
のかわからない。
2. １つのチケットで、いろいろな修正を行い、チケットが完了できない。
3. どこまでやったら完了かわからない。
4. コメントが長くなり、また、途中で流れが変わったりして全体像がつかみにくい
補足
1. 題名に「○○を改善する」のように、どこまでやれば終わりなのかわからないものは使
用すべきでない。
→「○○を改善して１．０版を制定する」だったらOK。
2. 親子チケットの利用イメージは次ページ参照
対処法
（おすすめルール）
1. チケットの題名は、概要がわかるようにする。
2. 大きな課題をチケットに登録してもよいが、課題を俯瞰して複数の子チケットに分割
して、それぞれの担当者を割り当てる。
3. チケット発行時と状況が変わった場合は、経緯を書いたうえでいったんチケットを完
了にし、別チケットを発行する。このとき、チケットは関連付けておく。

対向システムとのインターフェース調整を、
EシステムとGシステムのインターフェース
調整に分割して子チケットを登録した例
対向システムとの
インターフェース調整
Ｅシステム
インターフェース
Ｇシステム
インターフェース

Redmineは柔軟性が高く、使用するのにはコツが必要ですが、
慣れればとても使いやすい。
ライフサイクルにあわせ、チケットの担当者を変える
◦ Excelの課題管理のように、だれがどこを変えたかわからなくなった
りしない。
現実世界の課題を的確にRedmineに登録。習うより慣れろ。
◦ バージョン、カテゴリ、親子チケット、関連チケット
チームのコミュニケーションが大事。
◦ 定期的なステータスミーティング
◦ チケットアサイン時はリアルで声をかけましょう。