チケット管理システムを使い倒す運用の実装

チケット管理システムと言えばredmineとかそういった課題やタスクをチケットに入れて状態を管理する仕組みである。チケット管理システムを導入しているほとんどの現場ではタスク管理で使っているのではないだろうか。

それで失敗するケースも多いようだ。チケット管理システムでググると『チケット管理システム　失敗』などが上がってくる。使い続けるほど強い動機を持っていなかったか、導入だけ決めて現場に丸投げしたのだろう、などと思うが現実はどうなのだろうか。

チームメンバが同じ場所にいて、過去の経緯を辿りやすくい環境を用意しているかあまり過去の経緯には縛られないならホワイトボードと付箋紙こそ最強だ。誰にも隠さず、フォルダの奥底でたどり着けないような情報は一つもない。タスクは言語化され、張り出される。担当もわかるし、進捗も滞留していれば朝会ですぐに気づく。

それでもチケット管理システムにいれておきたいこともある。

以前のプロジェクトの立て直しで、物理カンバンとチケット管理システムの導入し、結果的にコストをかけてまでチケット管理システムを入れておいてよかったケースがあった。

• チケット管理システムに登録する情報の種類
  プロジェクトで発生する情報全て。
  
  
• 物理カンバンとチケット管理システムの用法
  物理カンバンにはタスクのチケットと片隅に全体のプロジェクトのスケジュールを貼っておく。スケジュールを貼っておくのは①チームメンバが今どこにいるか時間軸を確かめられるため②次のマイルストーンをメンバが自分で意識するため
  
  チケット管理システムにはプロジェクトで発生する情報、アウトプットの情報全てを入れる。タスク、製品の問い合わせ、仕様の検討、設計関連ドキュメント、試験エビデンスのリンク、システム環境情報、プロジェクトメンバの付与した権限、チームのwiki（掲示板）など全て。
  
  
• 運用の原則
  チケット管理システムには漏らさず全て入れる。全てを入れておくことで、メンバの追加があっても情報を入手するスタートを揃えられる。これは情報が偏らず、効果は絶大。
  プロジェクト参加のタイミングで情報較差を招くことは避けられないがチケット管理システムにwikiを用意しておくことで自走できる環境を『日頃からチケットを登録する』ことで整えることができている。まさに、勝手にできている状態を作れる。
  
  
• 効果
  得てしてテストフェーズに入ってから、要件定義や基本設計などの工程で決めた仕様まで遡る問い合わせが必ず数件発生する。これはどのプロジェクトでも起きる。
  そのとき、記憶でメールを探したり、フォルダの議事録を探して見つからないとか辿り着けないとかそういった事態が起きない。製品の問い合わせも残っているので、根拠もいつでも提示できる。
  もし、UATなどでそれが起き、仕様決定のエビデンスを根拠に説明できなかったらどうなるかを想像しよう。恐ろしくて目も当てられないはずだ。例えチケット管理システムに情報を登録するために派遣を1名採用したとしても十分ペイできるどころじゃない。御釣りが戻ってくるくらいだ。

こういったプロジェクトでなければ物理カンバンと付箋紙で十分である。

業務デザインの発想法 ~「仕組み」と「仕掛け」で最高のオペレーションを創る