【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪

次回のRedmine大阪のパネルディスカッションの資料を事前に公開しておきます。
パネルのテーマ「RedmineのFAQとアンチパターン」に関する資料を書いていたら、ページ数が増えてしまったので、事前に公開しておく。

【参考】
Redmine大阪 第16回勉強会 - connpass

【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪 from akipii Oga

Redmineの親子チケットの功罪: プログラマの思索

最近よく聞くRedmineのFAQ～Excel添付のチケットから野良Redmineまで: プログラマの思索

親子チケットを使う上での用途や問題とかを洗い出してくれている。Redmineの現機能上の制約なども書いてあり、参考になる。 - prisira のコメント / はてなブックマーク

【1】Redmineが他のPJ管理ツールと違う点は、OSSでありながら、チケットやPJの階層が無限に作れること、があると思う。
その特徴があるがゆえに、多様な業務でもPJごとに切り替えたり、WBSの粒度に合わせて親子チケットで表現できる。
つまり、多様な業務、大規模な組織でも、Redmineの利用範囲が広がっている。

しかし、特に、親子チケットは落とし穴が多い。
そのアンチパターンや、よく聞かれるFAQを資料にまとめてみた。

【2】Blogでアイデアを書き散らした後で、もう一度見直した点は、「ＷＢＳはプロジェクト組織を規定する」という意見だ。
作業や業務内容を親子チケットで表現したものの、何故かしっくりこない原因には、「ＷＢＳはプロジェクト組織を規定する」という事実が背景にあるような気がする。

ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

実際、Redmineでプロジェクト管理を始めると、WBSはチケットでどのように書けばいいか、という質問がよく来る。
他にも、チケットの粒度やチケットの完了条件、ワークフローの質問もある。
つまり、WBSは工程単位に作るべきなのか、機能単位に作るべきなのか、という質問が根本的と思う。

彼らは、情報処理試験で習った教科書通りに、工程単位にタスク分割して階層化して、WBSをチケット化しようとする。
しかし、実際は、そんなきれいな開発はほとんどない。

経験上、工程単位のタスク分割でチケット駆動を始めると、たいてい上手くいかない。
溢れたタスク、割り込みタスク、仕様確認のQA、突然発生した障害など、WBSでは表現しきれない作業がどんどん現れるからだ。
それらのタスクは、どの工程に入れるべきなのか？
いつも判断に迷う。

たとえば、バージョン＝工程に紐付けても、障害が出るたびにバージョンはReOpenされ、いつになってもCloseできない。
工程単位にPJを作るチームもあって、工程ごとにタスクを分割したい発想が根源にあるけれど、工程単位に作ったPJのチケットは統一的に管理しにくい。
その結果、チケットは乱発され、放置されて、Redmineはゴミ箱になる。

つまり、彼らは「WBSは工程単位に作るべき」という思い込みに囚われすぎていると思う。
もっと柔軟に考えて、実際の現場の運用に合わせて、もっと軽量なプロセスにすべきだと思う。

ＷＢＳはプロジェクト組織を規定する : タイム・コンサルタントの日誌からで指摘していることは、WBSの構造、つまりチケット化されたタスクの構造は、そのチームの組織構造を体現することだ。
機能別組織ならば、工程単位のWBSが向いているだろう。
つまり、縦割り組織だったり、開発工程をベンダーに一括請負契約で丸投げ発注している場合には、向いているかもしれない。
しかし、その後の受入テスト、部門間の調整事項などのタスクや課題が発生したら、その運用では耐えきれないだろう。

また、親チケットの開始日・期日・進捗率・予定工数は子チケットをロールアップさせるべきなのに、親チケットにせっかく入力した予定情報は消して欲しくない、という要望がすごく多い。
結局、親チケットと子チケットはバラバラに運用したい、という現場が多い。
つまり、彼らも綺麗なWF型開発を運用するのは難しい、と知っているのだ。

【3】上記の資料を書きながら思ったことは、あるべきチケット駆動開発をRedmineが完全に実現しきれていないことだ。
Redmineの機能制約があるために、チケット駆動開発のあるべき姿に制限がかけられて、未実現に終わっている。

例えば、ロードマップ画面で、スクラムのバックログのようにチケットの優先順位をドラッグ＆ドロップするパッチが提供されているのに、まだ実現されていないゆえに、Redmineはアジャイル開発のツールとしてまだ不十分だ。
そのパッチの提供者のMarius BALTEANUさんは以下のように書いている。

Feature #22802: Add the posibility to set/change the position of an issue in a version - Redmine

(Google翻訳による引用開始)
ロードマップタブでは、トラッカータイプ（アルファベット順）と作成日付（古いもの）の後に、バージョンで自動的にソート（配置）されます。
あるバージョンの問題の位置を手動で設定したり変更したりすることは可能でしょう。
このようにして、ユーザーはバージョン内の作業の優先順位をつける方法が増えます。
ユースケース：私たちはバージョンをスプリント（時間ベース）として使用し、各バージョンについて、チームが次の期間に実装すべきいくつかの問題を計画します。
この機能を利用できるようにすることで、機能の実装順序も設定できるようになります（バージョンの上位にある問題が最も重要です）。
このメカニズムは、現代のソフトウェア開発（スクラム、かんばんなど）に非常に使用されており、チームで使用するのは簡単ではありませんが、古典的な計画（開始日、期日、後続/先行関係あり）定期的に問題を発行し、優先順位が頻繁に変更されます。
(引用開始)

彼の意見に僕は同意見で、ロードマップ画面はアジャイル開発のバックログ、かんばんのように使うべき画面へ改良すべきと思う。

他に、ロードマップ・カレンダー・文書・ファイル画面のように、Redmineで置き去りにされた機能は、もっと改善すべき余地がたくさんある。

しかし、逆に言えば、Redmineで色々試すうちに、チケット駆動開発のあるべき姿が見えてきた、という経緯もある。
こんなやり方もあるよね、とたくさんの人々が試して、初めて分かったアイデアもある。

つまり、RedmineはWebのプロジェクト管理ツールとして、先進的な人々が試す実験ツールなのだ。
だから、Redmineが機能改善されて、チケット駆動開発のあるべき機能が実現できれば、今まで思いもつかなかった運用方法や効果が出てくるだろう。
すなわち、Redmineにはたくさんの可能性が秘められている。

幸いなことに、Redmineはオープンソースなので、自由にカスタマイズできる。
Redmine本家でも活発に機能改善パッチが提供されて、どんどん改良されている。
今後のRedmineにすごく期待している。