ぷろまねさん

グローバルコンサルティング会社でシステム開発・運用保守(アプリ方面)のプロジェクトマネジャーをしています。2014年PMP取得。アジャイル開発などの開発手法、Redmineなどの開発ツールを話題の中心に書いてます。

Redmineカスタマイズ事例:チケットの作成単位

プロジェクトに続いてチケットの作成単位について。

もともと僕のチームで行っている運用保守業務ではチケット管理システムとして自作ツールで以下を管理していた。

  1. ユーザからの問合せ
  2. ユーザからの作業依頼
  3. ユーザ以外(顧客IT部門、自社内)からの問合せ、作業依頼
  4. 定常作業(月末締め対応や監視で検知した問題の対応)
  5. 障害の対応(バグ等)
  6. 仕様変更対応
  7. 自主的なシステム改善

つまり、(管理作業などを除き)チームで行うほとんどの作業はチケットとして起票されている、基本的なTiDDなルールには元々従えていたわけだ。(属人化していない運用保守プロジェクトであれば基本的に上記のようになっているのではないかと思われるので、運用保守業務はTiDDとの相性は悪くないと思っている。)

一方、上記の単位(案件と呼んでおく)毎にチケットは起票されているたが、各案件には通常複数のタスクが紐づく。障害対応であれば、設計書の修正、プログラム改修、テスト、レビュー、移送、初回稼働確認等というように。これらのサブタスクの管理は管理ツールの1テキストフィールドにベタ書きしていくというルールにしていた。そのため、以下3つの課題が存在していた。

  • 「何をやる必要があるか」を毎回1から記載するため、作業に抜け漏れがないかが分かりにくく、属人化しやすい(初回稼働を忘れる、など)
  • 各案件の顛末(どういう理由で何が決定され、何が実施されたか)が長文を読み解かなければ理解出来ず、振り返りに時間がかかる
  • 各サブタスクの詳細まで可視化されていない(誰が担当で、いつ完了予定か等)

作業の流れに即したワークフローを設定

まず1点目の課題に対してはワークフローが役立っている。障害対応、仕様変更対応といった案件のカテゴリ毎にワークフローを設定し、必ずすべきことをワークフロー上に乗せた。例えば、チケットをクローズするのは特定のユーザのみに限定しておき、実作業者ユーザはクローズ依頼申請する際に障害対応であれば初回稼働確認を行った結果をRedmineに記載しなければそのステータスに遷移出来ない、など。

どのようなワークフロー設定にしたかの詳細はまた別の機会に説明したい。

顛末を記載するフィールドを用意しておく

次に2点目の課題に対しては、「結局そのチケットで何を行ったか」を記載するフィールドを用意し、先に説明したワークフローと合わせて作業者に記載させるようにした。

Redmineには更新時に注記を記載していく機能があるので、対応の途中段階では注記に随時状況をアップデートしていくことになるが、対応完了時に上記を記載するルールとしている。注記が長くなってくると結局何をしたかが曖昧になってしまうので、サマリ情報を保持させておき、今後の振り返りに役立てたいという意図。

サブタスクは子チケットとして起票する

そして3番目が「チケット作成単位」という意味でこれまで使用してきたツールと大きく変更した点。Redmineにはチケット間に親子関係を設定することが可能なため、サブタスクも子チケットとしてどんどん起票するように促している。起票の粒度に厳密な定義は設定しないが、基本的に以下の粒度になるまで分解している。

  • 担当者を1名に限定出来る
  • 予定工数が2~16時間(2人日)程度

親チケットには紐づく子チケットが最小限の情報とともに一覧化されるため、毎日のステータス確認はその一覧を見ながら状況の概観を確認、気になるサブタスクの状況を子チケットを表示して確認、という流れで回している。親チケット画面の子チケット一覧は情報は少ないところがネックだが、ここはプラグインでなるかも知れない。

しかし、正直なところRedmineの親子関係設定については課題も多い。少なくともデフォルトでは子チケットから親チケットを設定するには番号を指定しなければならず、もう少し直感的な紐付け方も欲しいところ。また、「関係するチケット」が紐付いているチケットに対して親チケットを新規設定しようとするとエラーになる、おそらくバグも存在しているようだ。

 

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

 

 

Redmine超入門(日経BP Next ICT選書)

Redmine超入門(日経BP Next ICT選書)