文系プログラマによるTIPSブログ

文系プログラマ脳の私が開発現場で学んだ事やプログラミングのTIPSをまとめています。

redmineを使ったチケット管理の失敗のさせ方

Redmineを使ったチケット管理をしている方必見!ジワジワとredmineを壊して失敗させていく方法を公開しちゃいます。
f:id:treeapps:20160226022423p:plain

チケット管理のアンチパターンとベストプラクティス - Javaプログラマのはしくれダイアリー

こちらの記事の便乗ですが、私の今までのチケット管理経験から「こうすると失敗するよ」という実例を挙げてみようと思います。私はほぼredmineしか触っていないので、今回はredmineでのお話となります。

※ 冒頭の記事と被る内容も多々有りますが、気にせず列挙していきます。
※ 主にSI業界に関するチケット管理のお話です。
※ 大規模プロジェクトは想定していません。多くても20人以内程度を想定した記事です。

これであなたも無事、失敗できる!

進捗率をユーザの裁量で更新させる

進捗率は人によって設定するさじ加減がバラッバラなので、全くあてになりません。例えば「俺は着手開始の印として進捗率を10%にしてから作業する!」という人もいれば「俺は50%単位でしか更新しない!」「いやいや俺は5%刻みでいくぜ!?」という具合にバラバラです。これは非常に悪しき風習です。

今のredmineには、「チケットのステータスで進捗率を更新する」という機能があるので、是非これを使うべきです。
小技(0.9): チケットのステータスで進捗率を更新する | Redmine.JP Blog

この機能を使う事で、ステータスを選択すると自動的に進捗率が設定でき、ユーザが任意に進捗率を設定できなくなるため、オレオレ進捗管理を避ける事ができます。

対象バージョン「なるはや」

いつまでにリリースしたいか決まっていないが、なるべく速い方がいい、そんな思いから作られた対象バージョン「なるはや」。

お仕事なのだから「速いほうがいいのは当たり前」だし、曖昧な表現を用いてはいけません。人によっては「なるはや=1週間以内くらい?」と考えていたり、「なるはや=今月中」という人もいます。

本当にいつリリースしてもいいのなら「実装待ち」みたいにして、いつのリリースに対応してもいいよ〜、くらいに割り切った方がよいです。

チケットの内容が途中から変わる

仕様に関するチケットなのに、チケット内で仕様が決まると「この仕様で実装お願いします!」等という激励コメントと共に、そのチケットを使いまわしてそのまま開発側に投げてしまうパターン。

途中から実装チケットに早変わりしてしまい、仕様チケットの筈がデザイン崩れ等のデザインに関する内容まで飛び交う事も有り。

横着してチケットの使い回しをすると、重要な情報がどんどん流れてしまうし、「本当に知りたい情報」は一体どのチケットを見たらいいのか解らなくなります。ちゃんと役割ごとにチケット分け、関連のあるチケットを関連付けしておいた方がよいです。

増殖するプロジェクト固有のトラッカー

redmineはサブプロジェクト形式で複数のプロジェクトを1つのredmineに相乗りさせる事ができます。相乗りしているredmineでは必ずと言ってもいいほど、そのプロジェクトでしか使われないトラッカーが作られます。例えば「クライアント確認(XXXプロジェクト用)」といった具合に作られます。

一度でもプロジェクト固有のトラッカーを使ったら最後、「あ、そのプロジェクト専用のトラッカー作っていいんや!!おっしゃ!!」→ 設定画面のトラッカー一覧にプロジェクト固有トラッカーがズラ~・・・・

「本日は打ち合わせありがとうございました」

社外redmineでありがちだと思いますが、チケットに「本日は打ち合わせありがとうございました」等と、チケットの内容と一切関係ないコメントを書いてしまう。気持ちは解るがやめましょう。挙句の果てにはそのチケット内で次のMTGの日程決めのやりとりをベンダー数社でやり始めたりして。

おいおいキミたち。このチケットは仕様確認のチケットでしょうが。何してるの。

対象バージョンの書式がバラバラ

SIの場合はリリースが毎週一回ある等、定期的にスケジューリングされている場合がありますね。その場合、対象バージョンに日付を設定する場合があります。例えば「2016/02/26」のように。しかしですね、日付の書式がバラバラなんですよ。「2016/1/1」と設定する人もいれば、「2016/01/01」とする人もいます。書式は合わせましょうよ。

redmineのソートは文字列ソートである場合が結構あるので、「2016/1/1」と「2016/01/01」ではソート結果がめちゃくちゃになります。「2016-1-1」と「2016/1/1」の違いも同様です。書式は統一した方が後々トラブルが起きにくくなります。

チケットに添付されまくる仕様書

エクセルに走り書いた仕様書や画面仕様書等をチケットに添付するの、やめません?

その資料に更新が必要になった時にいちいちゴミ箱ボタンで既に添付されたファイルを全部手動で削除していって新たに更新版を添付する、それを10回繰り返すの、何とも思わないのかな?

gitやsvnで管理して、コミットされてる場所書くようにしませんかね。

チケットの題名が「仕様調査依頼」

そのチケットの題名見て内容が想像できる人、いないよ?

redmineのチケットは、gitのコミットメッセージ考える時くらい真剣に、要点を抑えて短く書きましょうよ。

お電話で話した内容ですが

「先ほどお電話でお話した件ですが、調査をお願いします。」とだけ書かれたチケット、電話を受けた人しかそのチケットの内容が解りませんよ。

内容を書くのが面倒臭くなったのでしょうか。1週間後にチケットを起票した本人がそのチケットを見た時、どんな内容のチケットなのか答えられますか?

社内redmineと社外redmineのテーマが同じ

ぼーっとしてる時、うっかり社内redmineと間違えて社外redmineのチケットを更新しちゃいますよ。注意しててもいつか誰かがやっちゃいます。しかもそんな時に限って「鈴木の糞野郎(クライアントの担当者の名前)がふざけた事ぬかしてたあの件ですが、ちょっとアイツの仕様じゃ全く駄目なんで、一旦整理した方がいいよwwww」みたいな事を書いてしまったりして、それがクライアントに見られたり。

社内redmineと社外redmineは、ぱっと見で違いが解るように、色がかなり異なるテーマを適用した方が事故が減ります。

既に退場した人のユーザが沢山残っている

チケットの担当者のコンボボックスをクリックすると、退職者や今プロジェクトに参画していない人の名前がズラ~っと並んでしまい、目的の人を選択するのに時間がかかってしまう。これはマジで時間が勿体無いので、極力今関わっている人のみになるようメンテした方がいいです。

例えば「鈴木一郎」さんと「鈴木二郎」さんがいた場合、二郎さんの方は既に退職しているのに、一郎さんと二郎さんの区別がまだ付いていない新規参画者が、退職している二郎さんにチケットを回してしまうなんて事故が起きる事もあります。

ステータス「保留」

気持ちは凄く解る。途中まで進んでたのに、別の優先タスクが発生してしまって一時中断したチケット。保留したいですね。しかしその保留チケットは放置されずっと残り続けるゾンビチケットになる可能性を秘めています。

redmineはゾンビチケットが残りやすいので、思い切って一旦そのチケットを終了してしまうのも手です。保留を残し続けると、「このゾンビチケット群、どっかのタイミングで棚卸しないと、そろそろやばいよね〜」←そんなタイミングは来ない場合が多い

「単体テスト」と「単体試験」

呼び方が違うだけで内容が同じトラッカーが複数作られてしまうとさあ大変。気づいた時には既に両方使っているプロジェクトもあったりして、統合する訳にいかなくなってしまう。終いには「UT」や「単体test」なんてでてきたりして。

wikiにある「チケットの更新フロー」

超細かい更新フロー、超細かい進捗率の更新基準、wikiにまとめないといけない程のフローになってしまった時点で、その運用フローは破綻しています。そのまま運用しても失敗するか、「煩雑過ぎるから今日から簡略化したフローに変えます!あ、でも設定変えてしまうと他のプロジェクトに影響してしまうので設定はそのままにします!◯◯のステータスは無視して下さい!」みたいな事が始まります。

フローなんて見なくても解るくらいシンプルで、ワークフローで次の行動をできる限り制限して、プロジェクトに新規参入した人でもすぐ運用できるようにすべきです。

何故か私はこのチケットが終了できないんですよね

ワークフローを適当に設定するのをやめなさい

乱立するredmine

「あのredmine、相乗りしてるプロジェクトが無茶苦茶な数のプロジェクト固有のトラッカーとステータス作りやがるので、別途新規redmine立てました!」←別のプロジェクトが同じ事を繰り返す ← 無限ループって怖い

他にも「あのredmineバージョン低いんだよね。でもバージョンアップ作業ができる人もないし、別途redmine立てるか」等のケースもあります。こうして徐々に乱立していくとredmineに派閥みたいなものができあがり、「あのredmineに相乗りしてる奴らはできるグループだ。急いであっちに引っ越すぞ!」みたいな頭の悪い事をしだす人がいたりします。

雑感

いかがでしたでしょうか。多分こんなような事は皆やっちゃってるんじゃないでしょうか。

色々なプロジェクトを見てきて、チケット管理が成功しているのは、やはり選択肢が非常にシンプルで少ない、ワークフローを上手く使って行動を制限できているプロジェクトの成功率が高いように思えました。

特に、トラッカーはマジでシンプルで選択肢が少ない方が上手く行きやすいように思えました。要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト・受け入れテスト・・・・みたいに細かくしたい気持ちはよく解るのですが、それ、間違いなく失敗します。皆そんな綺麗に運用できません。設計チケットで実装のコメント合戦を始めるし、単体テストチケットで仕様調整の話を始めます。細かすぎです。目茶苦茶少ないくらいが丁度いいです。

進捗率に関しては、私は全く要らない機能だと思っています。例えば調査系のチケットの場合、調査を完了したら進捗率はいくつなの?等と困ってしまったり、進捗率が0%のまま最後まで進んでチケットを終了するときに仕方なく100%にするようなチケットも結構あります。「ここで進捗率を更新しないといけない」みたいなルールを設けても、細かすぎて覚えきれないし、誰も守りません。他にも「実装着手したら進捗率を5%に更新してから実装して下さい」等もアホ臭いです。そのスケジュール管理、おかしいと思いませんかね?もっといい方法探したほうがいいのでは?と思ってます。今だったらgitのコミット頻度とか見れば、本当に実装が進んでそうなのか等が解ったりしますよね。作業者の自己申告制みたいな管理はやめて、機械的に管理できる仕組みを模索した方がいいと思います。


redmineのチケット管理は徐々に色々増殖して破綻していく傾向があるので、「どれだけできる事を減らせるか」「どれだけ行動を制限できるか」の2点にかかっているかと思います。プログラマはどうしても細かく分類して、あらゆるものを無駄に管理したがり、最後は収集がつかなくなって放置されるものが増える傾向があるので、どれだけシンプルにできるかが成功するための鍵になる、と私は考えています。