第二回品川RedmineLT資料です。

1. Redmineチケットによる
プロジェクト火消し戦略!!
2012/1/21 高倉利明 @ TrinityT

2. はじめに
● ２００８年からRedmineで様々なプロジェクト管理を行ってきた。
● 中には凄く忙しい案件、危機一髪な案件もあり。
→こういうケースでのチケット運用の肝が見えてきている
→自分の経験を一回フィードバックしておきたい
注：あくまでもテンパる前に何とかするのが
プロジェクト管理の理想です！

3. ケーススタディ
● 状況(よくありがちなケース)
● どう対処するべきか？

4. 状況 (よくありがちなケース)：その１
● 終了済みバグ、タスクがRedmineに大量に山積みされている
● 優先度や期日が有名無実化
● チケットの粒度があいまい (一週間かかるものまである)
● なぜかExcelやGoogleドキュメントが併用して使われている。
※ある時点でのチケット一覧をCSVで出力。
顧客から言われて作ってしまったケースが多い。

5. 状況 (よくありがちなケース)：その２
● 次から次へとタスクやバグが追加される
→ 終わりが見えないので各担当者のモチベーションも低下
● 大量のチケットの担当者が同じ人になっている
→使命感のため(案件に最初から参加していた自分がやらな
きゃ。。。)
● みんな終電帰り
→自分のタスクが終わっても帰れる雰囲気じゃない
● しかしリリース日は変えられない
→既にプレスリリースしてしまった等。SI案件だと顕著

6. どう対処するべきか？
大事なのは２点
● トリアージ
● 効率化

7. トリアージ
本全体からたった一言だけ覚えるとすれば、それはトリ
アージである。 [ エドワード・ヨードン「デスマーチ」 ]
● 限られた人的資源で納期を順守するために、作業に
優先／非優先の順位をつけなければならない。これ
がシステム開発におけるトリアージである。
[@IT 情報マネジメント用語事典より]
● 「スコープ(機能)」「予算(人員)」「時間」「品質」 を調整

8. トリアージ
● プロジェクトがテンパると、無駄な作業を増やそうとす
る力が働く。 → 突っぱねるための代替案が必要
○ 一日ごとの作業状況報告書をExcelで提出しろ
○ 毎日一時間進捗報告会議
○ ...etc
● 不必要なコミュニケーションコストを最大限削る
→本当に必要な作業と コミュニケーションに注力
● メンバーのモチベーションUP

9. 戦略1：チケット整理
● チケットの初期化
● 優先度＆未担当カスタムクエリ

10. チケットの初期化
step1:チケットの棚卸し＋全てのタスクのチケット化
● チケットの集約＆棚卸し (1日潰してでも徹底して実施)
○ 他のツール管理タスクも全てRedmineに一本化
○ 最小チケット発行の目安は5分以上かかる作業
● 重いタスクやバグは分割
○ 目安は1日で終わる単位に
○ 親子チケットは便利だが運用コスト＋メンバーのリテラシがそ
れなりに必要。無理ならやめた方が良い
○ 特にバグは親子チケットを使わない方が良い
→バグ原因によって親子関係が変わる可能性が高い

11. チケットの初期化
step2:担当者「<社名> 未担当」を作成して設定
● 複数社が関わるSIでは、担当者を空欄にするとどの会社がボー
ルを持っているか不明になる
● 全てのチケットを最初に一回未担当にする。
→ チケットを抱えこんでしまった人は気づかないが、
ほとんどのタスクは代わりに出来る人がいる

12. チケットの初期化
step3:優先度、開始日、期限日の設定
● この時点では判断が難しいが、設定しないよりは遙かに良い。あ
る程度アバウトに。
● 開始日は以外と重要
○ 現時点で必要ない作業に取りかからない
○ タスクを終わらせるための開始の目安
● 「優先度：低のチケットは無視する可能性大」
ということを関係者に伝えておく。

13. 優先度＆未担当カスタムクエリ
[優先度別＋未担当]のカスタムクエリを三つ作成

14. 戦略2：チケット運用
● チケット管理者を立てる
● チケット運用フローの簡略化

15. チケット管理者を立てる
● チケット管理全般を担当する
○ 優先度、開始日、期日等の調整
○ 特別なタスクの担当者割り振り
○ その他雑用 ＝ 煩わしい作業を一手に引き受ける
● 理想は専用担当者
○ 切羽詰まった案件ではチケット管理が最重要になるので、
重いバグ修正やタスクを兼務しない方が良い

16. チケット運用フローの簡略化
各担当者が以下の簡略化フローで回す。
1. 前述した三つのカスタムクエリのチケットから「優先度が高い
順」「自分が対応できる」ものを担当者：自分担当にする。
併せて期限日を現実的な再設定する。
2. タスクを潰す
3. 作業完了後、担当者：チケット管理者にして終了
○ 完了時コメントはテンプレ化 (バグ原因＆修正方法)
○ この後はチケット管理者が対応
■ チケットステータス変更
■ 担当者割り振り(顧客、バグ報告者)...etc

17. 戦略の効果
● 「トリアージ」の観点
● 「効率化」の観点

18. 「トリアージ」の観点
● 「優先度順で処理される」システム
→チケットを切る際の手間や、重要タスクの伝達漏れが減少
● 残っているタスクの見える化
→顧客との期限日までに作らない機能や修正しないバグの交渉
がしやすくなる

19. 「効率化」の観点
● カスタムクエリでプロジェクトの進捗状況把握が容易になる
→進捗報告等の手間が省ける。
● 各担当者が自発的にタスクを選ぶ
○ 人から言われたタスクより遙かにモチベーションが高い
○ 担当者のレベルに応じて作業を割り振る手間が省ける
○ 一時的なヘルプ要員などにタスクを割り振りやすい
● 期限日を担当者自身が決める
○ 進捗遅れの発生が減少
○ 少なからず自分でスケジュールを組める
→モチベーションアップ（頑張って今日は早く帰るぞ！）

20. さいごに
何よりも大事なのは
モチベーション！

21. ご静聴
ありがとう
ございました！