Redmineのバージョン機能に別の意味を与える改善に関するアイデア～バージョン機能はリズムという恩恵を利用者にもたらす

Redmineのバージョン機能に別の意味を与える改善チケットが起票されていた。
以下、ラフなメモ書き。

【参考】
機能＃17907：バージョンに別の意味を与える - Redmine

（Google翻訳開始）
Redmineはプロジェクト管理に適しています。しかし、実際のソフトウェア開発だけでなく、だから、バージョンはソフトウェア開発プロジェクトではあまり意味がありません。

私の提案：バージョンがバージョンかマイルストーン、ターゲット、フェーズ、ステージなどであるかどうかをユーザーに選択させる。

実現は非常に簡単です。'バージョン'のタイプを指定する別のフィールドを追加するだけです。ユーザーがドロップダウンで選択する必要のあるバージョンを作成する場合は、そのタイプを選択します。理想的には、いくつかのアイコンを追加して、ロードマップなどのバージョンタイプを視覚化することができます。

さらなる開発では、バージョンタイプを構成可能にすることができます。しかし、これは私の場合はそれほど重要ではありません。私は人がバージョンを使うのが好きではないことに気付くだけです。これがちょうど別の名前を持つことができるのであれば、はるかに明確になります。
（翻訳終了）

【１】僕にとって、Trac、Mantis、Jiraなどの他のITSの運用では分からず、Redmineを運用して初めて理解できた機能が「バージョン」だった。
つまり、Redmineの「バージョン」をXPのイテレーション、Scrumのスプリントとして扱う事で、タイムボックス的なアジャイル開発プロセスを簡単にRedmine上で実装できる。

脱Excel！ Redmineでアジャイル開発を楽々管理 (1/5)：エンジニアがお薦めする 現場で使えるツール10選（3） - ＠IT

しかし、この事実に気づいて運用して以来、１０年も経つと、もっと色々考えたくなる。

【２】上記の改善チケットでは、「バージョン」の名称をユーザが選択できる機能を追加することを提案している。
理由は、ソフトウェア開発以外の場面で、タイムボックス的なプロセスを実現したいからだ。

僕自身は、ソフトウェア開発では、バージョンとマイルストーンは一致させる運用で良いと思う。
開発チームは、本番リリースの運用サイクルを起点とし、本番リリースのサイクルを自分たちの開発リズムとして捉えれば良い。
なぜなら、ソフトウェアにとって本番リリースすることが、顧客にビジネス上の価値をもたらし、開発チームに売上をもたらすので、本番リリースのタイミングを「バージョン」として名付けて、その開発リズムを大切にすることが重要だからだ。

むしろそれ以外の、たとえば、上司への月次の定期報告のようなマイルストーンは不要だと思っている。
本番リリースに直結しない報告タイミングなど、タイムボックスとして無意味だからだ。

【３】一方、ソフトウェア開発以外の利用シーンでは、バージョンという言葉が適合しにくい場面があるのは確かだ。

たとえば、「入門Redmine」に掲載されている事例として、毎年の農業の作業履歴をチケットとして記録し、四季や月ごとにバージョンを設定している事例があった。
すなわち、農業の「タイムボックス」は四季や月が相当するわけだ。
同様に、その他の業務でも、「タイムボックス」を表す名称として、マイルストーン、フェーズ、ステージなどの言葉の方がしっくり来る時もあるだろう。
そうであれば、ja.ymlで「バージョン」に該当する文言は、各業務のタイムボックスを表す名称に一括置換した方が、ユーザフレンドリーになるだろう。

【４】僕は、Redmineのようなチケット管理システムでは、「バージョン」という機能は単なるチケットを分類する機能ではなく、チケットにタグ付けする機能でもない、と思う。

チケット管理システムの「バージョン」は、利用者にチケット運用の「リズム」という恩恵をもたらす。
そのリズムがあるからこそ、チケット運用はスムーズに流れるし、そのリズムが心地よいと感じる。
そのリズムが生まれる背後には、タイムボックスという概念が隠れているからだ。

チケット駆動開発のモチーフ: プログラマの思索

TiDD：チケット駆動開発: ソフトウェアさかば

[TiDD] 出版裏話１：没になった原稿 - なぜ「チケット駆動開発」と呼ぶのか -: ソフトウェアさかば

（引用開始）
実際、あきぴーさんとSPESの論文を書く際には「チケット駆動開発」以外の名前を検討するべく提案しました。

しかし、あきぴーさんの答えは明確で「チケット駆動開発」は譲れないとのこと。当時は、しぶしぶながら承諾しましたが、この理由は、のちに私がチケット駆動開発を実践してみて、ようやく分かたのでした。それは

　　チケットがプロジェクトをテンポ良く推進してくれる

ということです。本の中では「リズム」と言う表現をしていますが、チケット駆動開発を実践していると、

　朝：チケット一覧を見て、作業計画を立てる
　昼：チケットの作業を順にこなしていく
　夕：チケットの進捗を登録する(完了チケットのクローズ)

という、開発パターンに体がなじんで、プロジェクトがリズミカルに進んでいきます。これは、体験してみないと分からない感覚でした(もし、チケット駆動開発を実践しているのに感じられないなら、備忘録のような細かなチケットをもっと発行してみてください)。

この「リズム」を感じる個人のプロセスは、チケット駆動開発のアジリティとも関係する大切なものです。ぜひ、チケット駆動開発を実践して体験してみてください。
（引用終了）

一方、そういうリズムが感じられないチケット管理システムは、単なる強制ツールに過ぎない。
タイムボックスという概念のないRedmineは、運用していてもたぶん楽しくないだろう。

上記の改善チケットが生まれる背後には、Redmineの利用シーンがソフトウェア開発以外にも広がっている事実が世界中で発生していることを示唆していると思う。
ソフトウェア開発以外で、そういうリズムが感じられるRedmineの利用事例も集めてみたいと思う。