Redmineは帳票ワークフローシステムであるというアイデア

@sakaba37さんから「Redmineは帳票ワークフローシステムである」という指摘を受けて、自分が持っていた疑問がかなりストンと落ちたので、メモ。
ラフなメモ書き。

【参考】
Redmineは帳票ワークフローシステム？: ソフトウェアさかば

【1】Redmineによるチケット駆動開発を研究して、それを広めたいと思っている僕にとって、Redmineに関する根本的疑問が二つある。

一つは、Redmineのチケットとは、そもそも何なのか？
もう一つは、なぜ、日本のSIや製造業のシステム子会社や情報システム部門で、Redmineの導入に興味を持ったり、運用しようとする事例が多いのか？

【2】Redmineのチケットが面白い点は、色んな業務に適用しやすい特徴があることだ。
元来、チケットは障害管理票だった。それがBTSになる。
そして、チケットは課題管理票でもある。それはITSになる。

【2-1】「Redmineによるタスクマネジメント実践技法」で書いた内容は、チケットはXPのタスクカードであり、作業指示書であるというアイデアから派生されるメリットや可能性をひたすら書いたこと。
アジャイル開発なら、チケットはタスクカードやストーリーカードに相当する。

【2-2】WF型開発なら、チケットはWBSになるだろう。
Redmineのチケットが親子チケットの構造を持ち、さらに無制限の階層構造を持つ特徴から、チケットをそのままWBSにマッピングできるからだ。

他の例では、ヘルプデスク管理やシステム保守サポートなら、チケットはインシデントまたはQA票になる。
あるいは、PC資産管理に使うなら、チケットはPC資産管理票になるだろう。

Redmineを見積書や経費などの簡単な申請承認フローで使うならば、チケットは申請書に相当する。

【2-3】以上の例のように、「～票」「～カード」「～書」のたぐいのものは全て、Redmineのチケットに置き換えることができる。
つまり、下記のイメージだ。

チケット→対応するシステム
.----
1)障害管理票→障害管理システム(BTS)
2)課題管理票→課題管理システム(ITS)
3)タスクカード→アジャイル開発のタスクボード
4)WBS(作業指示書)→WF型開発の作業管理
5)インシデント票→ヘルプデスク管理、製品保守サポート
6)資産管理票→PC資産管理
7)申請書→事務処理の申請承認ワークフローシステム

【3】なぜ、Redmineのチケットはこれほど多様な場面に適用できるのか？
その理由は、Redmineには柔軟なワークフロー管理機能があること、ガントチャートのような強力なチケット集計機能がデフォルトであること、チケットやプロジェクトが無制限の階層構造を持つこと、バージョン管理と連携してトレーサビリティを実現できる、という特徴があるからだろう。

@sakaba37さんによれば「Redmineは帳票ワークフローシステムである」。
その意味は、たぶん、帳票はほとんどRedmineチケットにマッピングでき、帳票のステータス制御はRedmineのワークフロー管理で実現できることだ。

実際、帳票の各項目はカスタムフィールドを使えばいい。
帳票の種類ごとに、トラッカーを対応付けて、ワークフロー管理すればいい。

つまり、簡易なワークフローであれば、Redmineでほぼ実現できてしまうのだ。
但し、「簡易なワークフロー」という意味は、「ある申請書は5万円未満は課長決裁、5万円以上は部長決裁」などのような複雑な分岐を実現するワークフローではないこと。

Redmineは事務処理の申請承認ワークフローに使えるか？: プログラマの思索

すなわち、Redmineのチケットは帳票そのものであり、Redmineは帳票ワークフローシステムとして使われるべき対象。

すると、Redmineチケットは、フローなのか、ストックなのか、という議論も出てくる。

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

【4】Redmineに至るまでの歴史を辿ってみると、日本人は帳票が大好きな組織文化があるのではないか、という仮説がある。

例えば、「Redmineによるタスクマネジメント実践技法」にも記載しているが、80年代頃から日立では、ソフトウェア開発の作業をB票・P票・C票という帳票で制御していたらしい。

swtest.jp/wiki/tools - PukiWiki

それらは、障害管理票(B票)、仕様変更管理票(C票)、プログラム変更票(P票)に対応する。
彼らは、紙ベースで障害管理・変更管理・構成管理のプロセスを標準化し、運用していたのだ。

【4-1】このうち、障害管理票(B票)はBTSに自然にマッピングできる。
すなわち、障害管理プロセスに相当する。
僕の考えでは、障害管理こそがソフトウェア開発の基本的なプロセスだろうと思っている。

【4-2】仕様変更管理票(C票)は、変更管理プロセスから生まれるものである。

実際、障害管理やソフトウェア保守をやっていれば、仕様変更は自然に出てくるワークフローなので、障害管理のワークフローにおいて、ステータスの読み替えで運用することで対処できる。
ワークフロー管理の機能が不足していたMantisやTracではよくやっていたことだ。

しかし、「ステータスの読み替え」は、開発チームごとのローカルルールになりやすく、新規参入の開発者は混乱するし、開発プロセスとしても標準化しにくい弱点があった。

【4-3】プログラム変更票(P票)は、プログラムのバージョンアップなどの構成管理に関するたぐいのもの。
構成管理プロセスに相当する。

しかし、構成管理で発生した作業内容と、本来の要件や仕様変更と結びつける作業は手作業でやっていたから、非常に煩雑だった弱点があった。

こういうやり方を帳票やExcelを使って、開発プロセスを標準化した人たちはすごいな、と思う。

【4-4】@sakaba37さんの話を聞いて、理解した流れは下記になる。

そういう状況に対し、MantisやBugzillaがBTSとして表れて、障害管理はWeb化された。
しかし、変更管理はステータスの読み替えという弱点が残り、構成管理とチケットの連携はプラグインによる対応という弱点が残ったままだった。

そして、Tracは、「チケット」という概念に昇華することで、障害管理だけでなく変更管理も一つのタスク管理に含めてしまった。
また、SVNリポジトリブラウザやWikiを内蔵することで、構成管理とその発端となった要件や仕様を連携する機能を編み出した。
しかし、Tracではワークフローをカスタマイズするのが難しい弱点は残ったままだった。

そんな中で、RedmineがMantisやTracよりも優れている点は、Tracの機能をクローンにするだけでなく、ワークフローをWeb上でいくらでも追加編集できるようにして、ガントチャートをデフォルト機能に含めてしまったことだ。
これによって、Redmineは進捗管理できる特徴を持ち、進捗管理のプロセスが入り込んだ。
すると、Redmineはプロジェクト管理全般に適用できるようになる。

つまり、障害管理、変更管理、構成管理をRedmineという一つのツールでカバーできるだけでなく、進捗管理できることから、プロジェクト管理そのものを実現する方向へ発展した。

Redmineのチケットにソフトウェア開発に関するあらゆる情報が集約され、蓄積されることで、スケジュールや品質、コストに関する情報をいくらでもチケット集計すれば、欲しいメトリクスを出力できるのだ。
すなわち、Redmineでプロジェクト管理のQCDをすべて収集し、コントロールできるようになる。

個人的には、Redmineでプロジェクト管理を全て済ませるようにしたいならば、アジャイルウェア(株)が販売しているLycheeEVMやLycheeGanttChartのようなツールの機能が必要になるだろうと思う。

【5】また、日本のソフトウェア開発では、スクラッチ開発も多いが、実際はソフトウェアの改造や保守がかなり多い。
すると、改造作業や保守作業では、トレーサビリティがすごく重視される。

たとえば、なぜこんなソース修正が必要なのか、本来の要件や仕様へ辿って検討する必要がある。
これは、前方追跡に相当するだろう。

あるいは、この要件や仕様に対して、機能は実装されているのか、リリースされたのか、をチェックする必要もある。
あるいは、OSやDBのバージョンアップに対し、この機能はどこまで保証されていて、どこを修正したのか、をチェックする必要もあるだろう。
これは、後方追跡に相当するだろう。

すなわち、元々あるシステムに対し、仕様追加や障害修正などで手を加える場合、変更管理や構成管理のプロセスを整備しなくてはならない動機がある。
つまり、Redmineの特徴の一つである「チケットと構成管理の連携」を使って、トレーサビリティをシステム的に実現する仕掛けを使って解決すればいい。

【6】そんなことを思うと、Redmineは日本人に向いたソフトウェアなのかもしれない。
つまり、日本には帳票文化があり、改造作業の案件が多い状況では、オープンソースでありながら、十分に多機能であるRedmineが適用しやすい場面が多いのだろう。
その仮説を他の事例でも検証してみたいと思う。