Redmineのチケット管理はフロー型とストック型で運用方法が異なる

Redmineのチケット管理は、フロー型とストック型で運用方法がどのように違うのか、考えてみた。
ロジカルでない、ラフなメモ書き。

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

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索

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

【1】フロー型のチケットは、チケット集計機能で見える化したい気持ちがその背景にある。
プロジェクトリーダーの場合、メンバーに個別に進捗状況を問い合わせるのではなく、Redmineを通じてリアルタイムに状況を把握したい。
だから、メンバーが自身の最新状況をチケット入力してくれれば、彼らの作業にプロジェクトリーダーが介入する必要はない。

チケット属性があれば、色んな見せ方がある。
たとえば、ガントチャート、ロードマップ、カレンダー、サマリーなど。
つまり、フロー型のチケットでは、チケット全てを集計して、進捗や品質、コスト状況、障害、課題などの状況をリアルタイムに把握したい。
そうすることで、プロジェクトリーダーは、今どの部分でプロジェクトの進捗が遅滞しているのか、どこにボトルネックがあるのか、をいち早く察知して、対処したいのだ。

つまり、フロー型チケットでは、ステータス、トラッカー、開始日・終了日、予定・実績工数、カテゴリ、バージョンなどの属性項目が重要だ。
それらの属性を用いて、進捗・品質・コストなどの色んな観点で見える化したいから。

最終的には、プロジェクトリーダーは、顧客や上司に対する進捗報告は、Redmineのチケット集計機能で代用したい欲望があるはずだ。

チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索

【2】一方、ストック型のチケットは、入力のしやすさが大事。
チケットの属性項目よりも、チケットの説明欄が重要だ。
Issueテンプレートプラグインはまさにそう。
チケットの説明欄をテンプレート化することで、たくさんの情報を書き込んでいく。

すると、蓄積したチケットを後から検索して、必要な時に取り出したくなる。
過去の障害や問い合わせはどうだったっけ？
なぜ、こんな複雑なパッチを書いたのか、その意図は何か？

つまり、全文検索機能も大事。
蓄積したデータをいつでも取り出せるようにする。
これは、全文検索プラグインで解決できる。

すなわち、ストック型チケットでは、チケットの説明欄への入力と、その情報を強力に検索できる機能が必須だ。
おそらく、サポートデスクやシステム運用保守チームでは、日々の進捗管理も重要だが、作業記録を残してナレッジを蓄積していくことが大事だろう。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

第17回Redmine大阪の感想 #redmineosaka: プログラマの思索

Redmineの全文検索プラグインでついに類似チケット機能が実装された: プログラマの思索

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

【3】では、フロー型とストック型の運用スタイルは、Redmineではどの機能に対応付けられて、どのように運用されているのだろうか？

実はRedmine は、ストック型の機能が多い。
チケット以外にも、文書、ファイル、Wiki、フォーラムなど。
しかし、Wiki以外は、これら機能はあまり使われてないように思える。

チケット管理がフロー型の場合、Redmineのストック型の機能を別に使ってる場合が多い。
たとえば、ソース管理、Wikiとか。

たとえば、作業の構成管理はチケット、成果物の構成管理はソース管理で行うとうまくいく。
ISO9001のシステム監査をはたから見ていると、余計にそう感じる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

たとえば、チケットの代わりに、Wikiがストックのイメージ。
Wikiに書かれるものは、たとえば、新規メンバーが加入した時に必要な環境構築、設計情報、技術情報のポータル情報とか、案件で定期的に実施されるふりかえり（KPT）の内容、顧客打合せや内部打合せの議事録、など。

あるいは、過去の障害や課題などのチケットから蒸留した情報をWikiに書く時が多い。
すなわち、システム開発やシステム保守で得られたナレッジをWikiにまとめて、メンバーは誰でも共有できるようにしたい。
そういう運用が自然に回れば、自分たちでシステム開発を改善していく雰囲気が醸し出されるはず。

一方、議事録をチケットにするのはストック型の運用だ。
だから、議事録をWikiにする人は、チケットをフロー型で運用している。

議事録の運用に優劣があるのではなく、チケットをフロー型で意識しているのか、ストック型で意識しているのか、で使う機能が違うだけだ。

【5】まとめると、フロー型はチケット集計機能によるプロジェクトの見える化を重視し、ストック型はチケットの入力や全文検索の機能を重視する。

現状のRedmineの機能を見ると、チケット集計機能は機能改善がすごく多い。
たとえば、ガントチャート、ロードマップ、サマリ、チケット一覧などの画面は、UIや機能も含めて、頻繁にパッチが当てられている。

【5-1】最近のRedmine本家のチケットで気になる機能改善は、カレンダーのUIをHorizontalだけでなく、Vertical list layoutでも表示できるようにしたい、という内容だ。

Feature #33682: Calendar UI proposal (Vertical list layout) - Redmine

#33682の添付画像を表示。

カレンダー画面は正直あまり使われていなくて残念に思っていた。
上記のVertical list layoutが実現できると、縦列は日付、横列はユーザごと・トラッカーごとで表示できる可能性がある。
そうすれば、かんばんに近い感じのUIになって、別の使い道が生まれるだろうと期待している。

あるいは、縦列に日付、横列に時間帯を付ければ、GoogleCalendarの代わりにもなる。
特に、システム保守チームでは、1日でこなすべきチケットを、ガントチャート画面ではなくカレンダー画面で見たいはず。
そういう使い方がしたい要望があれば、カレンダー画面をもっと改善できるはず。

一方、ストック型の機能はあまり機能改善が見られないように思える。
たとえば、Wiki、文書、ファイル、フォーラムなどの機能は、あまり進歩がない。

【5-2】個人的には、RedmineのWikiは仕様書になるように、もっと機能が欲しい。
たとえば、Wiki のサイトマップを自動生成して欲しい。
あるいは、WordなどのOfficeで書くUIの機能をもっとWikiに実装して欲しい。
つまり、WikiはWordやExcelの代わりに書けるもの、という運用を根付かせたい。

以前、Jiraの人に聞いたら、JiraではExcel設計書などの構成管理は考えていない、それら仕様書はConfluenceというWikiで代用できるはずだと考えているから、と聞いたことがあった。
つまり、Jiraでは、設計書はExcelで書いて、Gitで構成管理するのではなく、Wikiに直接書いてしまい、Wikiの履歴管理機能で蓄積できるはず、という設計思想らしい。
同様に、Redmineでもその設計思想は実現できるはずだ。

そうすれば、Redmineをプロジェクト管理ツールとして採用したシステム開発案件では、ExcelやWordなどのOfficeを全て排除できるはず。
ソースコードはGitで管理して、Remdineと構成管理ツール連携をすればいい。
設計書だけでなく、議事録や進捗報告の類も、全てWikiにしてしまうことで、全文検索プラグインでいつでも欲しい情報を取り出せるようになる。
納品物として必要ならば、一括PDFで出力してしまえばいいだけだ。

【5-3】文書機能もまだまだ可能性があるはず。
DMSFプラグインがRedmine本体の文書管理機能を乗っ取ってしまった感じだが、本家の機能ももっと改善したい。

【5-4】そんなことを思うと、Redmineにあるフロー型の機能やストック型の機能はどんなものがあるのか、それら機能に欠点があるならばどんな改善をすればいいのか、を考えたい。
つまり、Redmineの本来のあるべきフロー型やストック型の機能は何なのか、をもっともっと妄想しながら考えてみたい。