こんにちは。Webディレクターのともぞうです。
今回はチケット運用のオレオレ心得について書いていきます。
前提として
チケット運用にはプロジェクト管理ツールの代名詞Redmineを使用しています。Redmineってなんだ？ って人は過去にいい記事があったので参照してみてください。
プロジェクト管理ツール「Redmine（レッドマイン）」とは？特徴をまとめてみた
たま
- 本稿で用いる単語についての補足
- チケット・・・Redmineは1タスクの単位をチケットと呼称します。
起票・・・チケットの登録を起票と呼称します。
No Ticket, No Work
これ、1番といえるくらいに大事だと考えています。
起票されていないのに作業を進めるのはご法度です。
実際に作業をしていてもチケットがないと、何もしていないのと同義というくらい厳しく考えています。起票されないまま作業をすると誰が何をしているのか？ が全くわからなくなってしまいリスクにもなります。
仕事していますよアピールにもなるので、極力チケットを立てていきましょう。
チケットはログである
これは2番目くらいに大事だと思っています。
タスク管理の側面が強く出すぎるので忘れがちですが、チケットは資産になります。サイト制作をおこなううえで、だいたいの作業は再現性が高いです。過去のチケットを見ることでリスクヘッジにもなりますし、学びを得ることもできます。
また、案件を引き継いだときに、なぜこの機能が実装されたのかなど歴史を紐解く手助けにもなります。背景を知ったうえで作業できるほうが色々と捗りまし、改修方法が明確になります。
余談ですが、初めてWeb業界に入ったとき先輩がすぐにいなくなってしまい、プロジェクト管理ツールのログが先生っていう感じでした。なのでログは大事です。
ログという一面もあるので極力ふざけたコメントはチケットにしないようにします。ふざける場所はチャットです。
結論を明示する
何をどうしてほしいのかをしっかりと記載することを心がけます。どうなればこのチケットは閉じることができるのか？ というのを記載する感じです。
バグチケットでこの記載は特に必要です。ここの表示が崩れています！ や仕様通りではないです！ みたいな報告だけのチケットだと作業者は何をすればいいのかがわかりません。
なので、期待値という項目を設け、そこにどう直してほしいのかを記載します。バグチケットの起票のお作法については下記の記事がありますので参照してみてください。
エンジニアに分かりやすくバグを報告するバグレポートの書き方
Jack
担当の変更は忘れずおこなう
担当が変更されないとステータスが不明瞭になってしまいます。
作業が完了し確認依頼するときに、担当を変えずに伝えるだけだと、誰に担当を振ったらいいかわからないとなります。
そういうときは、とりあえずディレクターに振るなどして、最適な担当にボールを渡せるようにします。
また、担当を変えたときはチャットでもお知らせしてあげると優しいです。担当が変わっていることに気づいてもらえず、後続タスクが遅れたりするのはもったいないですよね。
ステータスは正しくセットする
「ステータス」は文字通り、タスクがいまどういった状態なのかを指します。
この「ステータス」が正しくセットされていないとチケットを一覧表示したときに、何がどうなっているのかが不明瞭でプロジェクトがどこまで進んでいるのかがわからなくなります。
なので、作業が完了したならステータスを完了にするなり、解決にするなり最新かつ正しいものにセットします。
ちなみに弊社のRedmineには下記の7つのステータスが存在します。
- 新規
- 進行中
- 解決
- 差戻し
- 終了
- 却下
- 無効
できればステータスごとに「どういう状態なのか」の定義があると、チケット一覧でステータスをみたときに一目瞭然なので便利です（たとえば「解決」ステータスは、「作業は完了し、決定者の確認待ちになっている」と定義しています）。
定義ができると、誰がどのステータスでチケットを保有すべきかがわかるようになります。たとえばデザイン確認担当者が差戻しステータスのチケットにアサインされていると、状態としておかしい、ということが一目でわかります。
クリティカルパスを意識する
クリティカルパスは、「重大な経路」という意味です。Web制作においては、チケットAの完了が遅れるとチケットBもあわせて遅れるということが起こりえますが、こういったチケットどうしの重大なつながりのことをクリティカルパスと呼びます。クリティカルパスを意識しておくと、工期がどこまで遅れても大丈夫なものなのかが明確になります。
弊社のRedmineだと先行・後続チケットをセットでき、ガントチャートで見ると視覚的にどういった関係性があるかがわかります。
関連チケットを明記する
作業している間に「あれ？ これも必要じゃね？」みたいに派生した作業はチケット同士を関連づけます。こうすることで、なぜチケットが起票されたかもわかりやすくなります。
クリティカルパスを意識するに似ていますが、微妙に用途が異なります。前後関係問わず関連性があれば付与していきます。
さいごに
チケット運用の効果を感じられると、チケットなしでは仕事ができない体になります。
チケットの魅力は
①ログになること
②何かを記憶しておく必要が減ること
の2つなのかなと思っています。
起票されていれば、いざとなったときにチケットを振り返ればいいですし、作業途中のものでも進捗をコメントしておけば、セーブポイントからはじめる感じで再着手できます。
これからチケット運用をはじめる方や、悩んでいる方の一助になれば幸いです。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
