チケットはデータでとプロセスの二面性を持つ #redmine

Redmineのチケットとは一体何だろうか？

Redmineのチケット駆動開発の面白さは、最初は課題チケットでしかなかったのに、いつの間にか作業チケットに変わった、というように、チケットにストックとフローの二重性を持たせて、チケットに複数の意味を持たせている点にあると思う。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

その他にも、Redmineでは、課題チケットという一つのインシデントという情報（データ）として意味を持たせていたのに、課題を解決する対策の作業手順（プロセス）もチケットとして登録される、というケースがよくある。

つまり、チケットは、ナレッジとして蓄積されるデータのケースと、作業手順として進捗管理されてステータス管理されるプロセスのケースの2つの性質を持つ。

たとえば、課題、障害、問い合わせのようなインシデントは、都度発生したタイミングでチケット登録される。
それらチケットには、当初のインシデントの内容だけでなく、調査結果や作業ログ、解決策や再発防止策も記録される。
最終的には、解決策や再発防止策は、ナレッジとして蓄積される。

チケット管理システムが持つ検索機能によって、それらナレッジはいつでも取り出すことができる。
つまり、チケット管理システムはナレッジデータベースの側面も持つ。

一方、作業チケットは、何らかの目的に対していくつかの作業手順に分解されてチケット登録される。
一般には、親子チケットで管理されるだろう。
作業チケットは作業手順の一部であるから、作業の順序が重要になる。
チケット管理システムでは、作業の順序はガントチャートのような進捗管理機能として実現されているだろう。

つまり、チケット管理システムは、作業手順というプロセスを管理する仕組みが必要なので、必然的にチケットの先行後続関係を表現したり、クリティカルパスを表現したり、作業チケットのステータスを管理する機能が必要になる。
一般にチケット管理システムでは、進捗管理機能はチケット集計機能の一部として実現されるので、今までに知られているプロジェクト管理システムとして普遍化されるだろう。

そんなことを考えると、チケット管理システムでは、チケットはデータであったりプロセスだったりするし、ストック型プロセスで使われるときもあればフロー型プロセスで使われるときもある。

そういう二面性をあえてチケットに持たせることで、より柔軟にプロジェクト管理しやすくする仕組みを持たせているわけだ。