« なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine | トップページ | 製造業アジャイルの事例リンク »

2026/07/08

Redmineのバージョンはなぜ使われないのか?

Redmineのバージョンはなぜ使われないのだろうか。
その事例を実際に見かけたのでメモ。

【参考】
チケット駆動開発の戦略: プログラマの思索

RedMineでチケット駆動開発!: プログラマの思索

【1】Redmineで一番重要な機能はバージョンだと思う。
バージョンがスプリントであり、イテレーションであり、マイルストーンであり、リリースバージョンになる。
バージョン単位にタスクをグルーピングし、小規模リリースする戦略がアジャイル開発だと考える。

よって、バージョンという機能はアジャイル開発と密接に関係する。
バージョンを使うことで、たとえば、LycheeRedmineでは、カンバンやバックログが使えるようになる。
つまり、1つのバージョンを特定すれば、カンバンになる。
複数のバージョン単位にカンバンを広げれば、バックログになる。

すなわち、カンバンやバックログのような機能を使うには、Redmineのバージョンを使う必要があるし、バージョンを使わざるを得ない。

【2】たとえば、Excelのタスク管理が混乱していて、何をすべきか分からないチームがいる。
PMOである僕は、彼らチームにRedmineを提供し、チケット駆動開発の運用ルールと運用ノウハウを伝える。
すると、若いメンバーほど、すぐにチケット管理に慣れて、タスクの消化が進んでチームが加速する。
彼らはすごく楽しそうにやる。

僕はさらに、リーダーである彼にカスタムクエリ設定、LycheeRedmineのガントチャートの操作方法を教える。
彼はカスタムクエリはSQLですね、と即座に理解し、PMOの僕が作ったクエリよりも、自分のチームなら彼が考えたクエリの方が便利だとクエリを追加する。
そして、実際に彼が作ったクエリを毎日の朝会で使って、昨日の実績、今日やること、をすぐに見える化した。
デイリースクラムが自然に身について、チームに一体感が生まれ、さらにチームが加速する。

しかし、PMOである僕が「バージョン」を設定するように説明しても、彼は納得しない。
チケットの期日から対象バージョンの期日が決まるから、機能が重複しているのでは?と彼は指摘する。

彼がカスタマイズし始めて運用を始めたRedmineでは、チケット一覧とガントチャートだけでタスク管理が回る。
ロードマップ、カンバン、バックログは使っていない。
そんな機能はなくても回るよ、と言いたげだ。

【3】では、なぜ、Redmineのバージョンは使われないのか?
理由は、バージョンを設定する人は、メンバーではなく、プロジェクトリーダー層であり、メンバーの自主性に任せて決定すべき機能ではないからだ。

バージョンはPJ設定画面でしか登録できないし、1個のプロジェクトで全てのチケットに横断して使われる。
さらに大規模PJになれば、ツリー構造のPJに対し、バージョンがPJ横断で設定される。

つまり、バージョンは、1つの案件に対し横断的に設定されて、統制をかける。
バージョンはスプリントであるから、大規模PJであれば、全ての子PJにて、基本は同じスプリントが強制設定されて、同期させることになる。
これがいわゆるアジャイルリリーストレインになる。

しかし、アジャイルリリーストレインとなるバージョンを設定できる人は、メンバーでもないし、サブチームのリーダーでもない。
1つの案件を担当するプロマネ、あるいは、プロマネの代理者でもあるPMOが担当すべきだ。
プロマネやPMOこそが、1つの案件のプロジェクトマネジメントをコントロールし責任を持つからだ。

だから、サブチームのさらにサブリーダーである彼にとって、バージョンは自分にとって身近なものではなかったのだろう。

【4】バージョンを使わない弊害は何か?

バージョンを使わないと、チケットがどんどん増えた時に収集がつかなくなる。
どのチケットを最優先にやるべきか、チケットの期日でしか優先順位の基準がない。
だから、毎日、1日分のタスクをどうやってこなすべきか、という観点しか身につかない。
1か月、数カ月レベルで案件を長く見る立場で、どのような戦略でタスクをこなしていくか、という考え方が出てこない。

スプリントという一定期間でチケットをグルーピングすれば、スプリントの中で、期日以外の優先順位付けを考えることができるようになる。
作業の優先順位は、期日だけではないからだ。
プロダクトバックログのように、1列に並べたチケットのスタックに対し、上から順に取り出せばいい。
それが唯一の優先順位であり、期日とは限らない。

【5】改めて、Redmineのバージョンは重要な機能だと思う。
今後も色々試していく。


|

« なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine | トップページ | 製造業アジャイルの事例リンク »

「Redmine」カテゴリの記事

コメント

いくつか考えが思い浮かびました。
・期日に応じたバージョンを自動的にセットしてくれればうれしいかも
・LycheeRedmineがうまく割り当てて処理してくれても良いかも
・概念的にバージョンはプロパティでなく、継承(親子)かも

投稿: さかば | 2026/07/09 15:58

いいえ、そんな意図ではないです。
Redmineのバージョン、つまりScrumスプリントは、タスクの期日とは異なる基準で定められます。
Redmineのバージョンは、チームメンバーが決めるべき判断レベルではなく、案件リーダーやPMOが検討し管理すべき機能である点が重要と考えます。
結論は、Redmineのバージョンは、期日に紐づく適当な機能ではなく、Scrumのスプリントのように、案件のリリース戦略の観点から決めるべき機能であって、メンバーの作業レベルから決めるべき機能ではない、点です。

投稿: あきぴー | 2026/07/12 13:12

バージョンというのはリリースされるプロダクトのバージョンですよね。
あるタスクの期限とは開始日に工数を加えたものではなく、あるバージョンのリリースに含めるなら、リリースからビルドなどの期間を引いた時期になるはずです。なので、期限からバージョンは決めることができます。
スプリントは期間を示すので、開始日と工数(および担当者が作業に何%割り当て可能か)で割り当てられるものですね。
あるバージョンをリリースするというチケットを作り、チケットを起票するときはいずれかのリリースチケットの子チケットとすればわかりやすいと思います。

投稿: さかば | 2026/07/12 14:30

さかばさん、違いますね。
チケットの期日からスプリントを自動的に決める処理は所詮プログラムで実装できます。
しかし、アジャイル開発の理念はそんな観点ではないはずです。
スプリントの概念は、チケットの期日から決めるのではなく、リリース戦略の観点から、どのチケットが重要であるか、どのチケットを優先してリリースすべきか、という戦略的基準から出てくるはずです。
プロダクトオーナーは、スクラムチームのデベロっーパーが見積もりしたチケットの見積もり工数から、プロダクトバックログを作るわけではないです。
プロダクトオーナーはどの機能が必要なのか、ビジネス戦略からチケットを取捨選択して決めるはずです。
たとえ見積もり工数が大きすぎるチケットであっても、さらに分割して段階リリースするなど、色んな手段を用いてプロダクトバックログに落として、スプリントに割り当てるなど考えるはずです。
この話の前提としては、スプリントがないまま、開発者は自分たちがチケットを作成して工数見積や期日を決めるが、優先度やリリース順序を考慮せず、タスク管理しているだけの状態です。
開発者が作ったチケットの期日をPMOが改めて更新し直して、リリース戦略に基づいてチケットの優先順位を決めて、チケットを取捨選択し、スプリントに合わせてチケットの期日を更新する運用に最終的になるだろうと思ってます。

投稿: あきぴー | 2026/07/25 15:27

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« なぜCCPMは挫折する?経営者の理想と現場の挫折をLycheeRedmineが解決する #redmine | トップページ | 製造業アジャイルの事例リンク »