Redmineチケット一覧のフィルタ「対象バージョン」のリストが大量表示されて使いにくい問題点

redmine-users-jaメーリングリストで、「Redmineチケット一覧のフィルタ「対象バージョン」のリストから終了したバージョンを表示させない方法」に関するスレッドが面白かったのでメモ。

【参考】
チケット一覧のフィルタ「対象バージョン」のリストから終了したバージョンを表示させない方法 - Google グループ

【1】チケット駆動開発では、対象バージョンがマイルストーン・イテレーション・リリースバージョンに相当するように運用するために、対象バージョンは非常に重要な機能であり、対象バージョンをたくさん作る。
しかし、Redmineチケット一覧で、対象バージョンをフィルタリングする時、進行中のバージョンだけでなく、終了したバージョンも表示されるため、リストに大量表示されて選択しづらいという問題がある。
スレッドでも下記のような意見がある。

(引用開始)
よくチケット一覧を、「対象バージョン」でフィルタして使用しているのですが、
対象バージョンの選択リストに、終了したバージョンが多数表示され、
目的の現行バージョンの選択が、結構大変になってきました。
(引用終了)

(引用開始)
これ、徳永さんや本家チケットに上がってる動機も、クローズしたバージョンが多すぎて
リストの選択肢がすごいことになるんですよね。
知り合いの会社も、毎月10個ぐらいバージョン作成した運用されているので、
3年運用するとなると、300個以上リストが出てくるんだなと。。
(引用終了)

また、Closeしたバージョンは非表示にする機能も使い勝手が悪い。
なぜなら、古いバージョンのチケットを探したい利用シーンもあるからだ。

(引用開始)
ただ、終了したチケットを表示させないことについては反対意見もあります。
確かに私も古いバージョンでフィルタすることもありますので納得できる意見です。
(引用終了)

【2】上記の問題点に対し、松谷さんから、下記の運用で回避できないか、という提案がなされている。

(引用開始)
運用対処として考えらえるのは、カスタムクエリの利用です。
よく使うクエリであればカスタムクエリを登録すれば、フィルタで対象バージョンを何度も選択しなくても必要なクエリができますので、
終了したバージョンのカスタムクエリは消す、という運用にすれば、迷わないとおもうのですがいかがでしょうか。
(引用終了)

(引用開始)
もし、何百というバージョンがフィルタに出てくるのを避けたいのであれば、
ある程度まとまった単位でプロジェクトを分けるという案があるかとおもいます。
(引用終了)

綺麗な運用は、Redmineプロジェクトで最初から分割しておく、という手があるだろう。
しかし、当初はそんなに使われると思っていなかったのに、大量にチケットが発行され続けて、後からRedmineプロジェクトに分割したいが、運用が混乱するのでできない、という状況もありうる。
上記のような運用で暫定的にカバーするしか無いだろう。

また、前田剛さん、川端さんから、Redmineの機能改善として下記のような意見が出ている。

(引用開始)
賛成派・反対派の両方を満足させる解決策の一つとして提案されているのが、ドロップダウンリストボックスをバージョンのステータスごとにグループ化して表示する方法です。
(引用終了)

Feature #10412: Target version filter shoud not show closed versions - Redmine

(引用開始)
システム管理のカスタムフィールド設定画面のように「フィルタとして使用」チェックボックスをバージョンの設定画面に作るのもどうなんでしょうかね？
(引用終了)

本来は、Redmineの機能の一部として、フィルタリングする時にバージョンのリストの中身を事前にステータスごとにソートしておいたり、「フィルタとして使用」チェックボックスをバージョン設定画面に用意しておくべきなのだろうと思う。
個人的には、「フィルタとして使用」チェックボックスをバージョン設定画面に用意しておく、という案は良いアイデアだと思う。

【3】いずれの意見ももっともだと思うが、最近感じることがある。

最近、たとえば50個以上の案件で100人以上のユーザがRedmineを使っている例のように、Redmineを大規模運用している場合、Redmineプロジェクトと対象バージョンの使い分けと運用が非常に難しくなっていると感じている。
案件の特徴、チームの特徴、業務の特徴に応じて、Redmineプロジェクトや対象バージョンの意味合いが変わるので、ベストな運用ルールを現場ごとに編み出すのが難しいのだ。

たとえば、一括請負の受託案件以外にも、準委任契約のシステム保守案件もあれば、日々の事務的な処理の案件もあるし、顧客からのサポートデスクの管理もあり、メンバーも、バリバリのIT技術者もいれば、事務員やオペレータ、デザイナーの人もいる。
また、チケットが数百万件以上になったり、チケットの階層構造が深くなったり、プロジェクトの階層構造が深くなったり、対象バージョンが数百件以上になったりする。
そんな場合、小規模プロジェクトで編み出された運用ルールがそのままでは拡張できない。
僕が当初やり始めたアジャイル型チケット駆動開発の運用ルールは、大規模運用の環境ではそのままでは拡張しにくいのだ。

つまり、案件の多様性、業務の多様性をRedmineの機能で吸収する時に、大規模運用の観点からRedmineはまだまだ改良の余地があるのかもしれない。
逆に言えば、Redmineは先進的なプロジェクト管理の実験ツールであるからこそ、このような問題点が具体化されてきたのだ。
従来の古いツールでは見えてこなかった課題が、色んな業務にRedmineを適用することで、具現化されて、Redmineがより進歩するキッカケになるわけだ。

今後も、大規模運用におけるRedmineの機能拡張の課題は考えていく。

【追記】
前田剛さんから下記のフォローがあったのでメモ。

MAEDA, Goさんのツイート: "@akipii バージョンの一覧が長くなる問題はプロジェクトの設定画面のバージョンタブにもあって、この画面ではステータスごとに表示を絞り込む機能を提案中です。 https://t.co/HnA2tKR3Me"

次期バージョン3.4で解決されるらしい。
最近は、こういう細かなユーザインターフェイスの改善が次々にリリースされるので、ユーザにとってはとてもありがたい。
RedmineのVerUpに追随すれば、自然に使い勝手も上がるのだ。

2016年8月のRedmineの機能改善に期待できること: プログラマの思索

2016年7月のRedmine開発状況 | Redmine.JP Blog

2016年8月のRedmine開発状況 | Redmine.JP Blog