Redmineのステータスに説明機能が欲しい要望の背景

Redmineのステータスに説明機能が欲しい要望のやり取りがあったのでメモ。

【参考】
Feature #2568: Description for issue statuses - Redmine

akipiiさんはTwitterを使っています 「なるほど。トラッカーの説明機能はあるが、ステータスも説明欄が必要な利用シーンが聞きたい。RT @minazou67: Redmineの運用が上手くいくかどうかはトラッカーとステータスとワークフローの設定次第と言っても過言ではない。そしてステータスにはコメント欄が欲しい…」 / Twitter

齋藤さんはTwitterを使っています 「@akipii @minazou67 私もステータスのコメント欄に一票。独自に作ることが多く、人によって定義が違ってブレますから。もちろん、wikiに書けば良いという話もありますが、初心者に解りやすいのは、コメントかなと。 #redmine」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii プロジェクト毎に独自のトラッカーを作成するシーンが多くて、進捗率の値の関係で同じ様なステータスが複数あったりするので。トラッカー単位でグルーピングされたステータスを作成できれば良いのですが、そうすると管理画面とDBが複雑になってしまうので。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii 1人の管理者が上手くコントロールすれば良いのですが、専任の管理者を置くのは無理なので複数のPMがトラッカーやステータスを管理している状態だとどうしても乱雑になってしまいます。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii なのでステータスが20個とかできてしまい、一覧には進捗率で並ぶので何がなにやら分からない状況に。。説明欄があれば、このトラッカーで使っていてこの状態の場合はこのステータスと分かるのでありがたいです。」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@saito0119 @akipii Redmineを分ければええやんと言われればそれまでなのですが、プロジェクト単位で立てるのは管理コストが厳しいのです。。saasを使えば楽ですが、使えないプロジェクトも多いのと、数が増えすぎると横断的に把握し難いというデメリットもあるので悩ましいです。」 / Twitter

u6k_yu1さんはTwitterを使っています 「@akipii @minazou67 わかる。作業がどういう状態になったらそのステータスに変更するのか、というのが認識統一しづらかったりする。「作業中」が、事前調査段階なのか、課題で詰まってるのか、手を動かすだけなのか、みたいな。」 / Twitter

akipiiさんはTwitterを使っています 「@u6k_yu1 @minazou67 なるほど、Redmine のステータスは、トラッカーごとに意味が異なると。同音異義語みたいですね。すると、トラッカーごとにステータスの説明機能が必要？」 / Twitter

みなぞう@脱OL系エンジニアさんはTwitterを使っています 「@akipii @u6k_yu1 そこは難しいですね。そこまでするならトラッカー毎にステータスを管理するのが素直だと思うのですが、そこまですると既存からの変更が大き過ぎるのでNGかと。なので単純にステータスに説明欄があれば個人的には満足です。」 / Twitter

akipiiさんはTwitterを使っています 「@minazou67 @u6k_yu1 さっそく @g_maeda さんが本家チケットを掘り返してくれてます。 Feature #2568: Description for issue statuses - Redmine https://t.co/B6aglS4ZMY」 / Twitter

【1】Redmineのステータスに説明機能が欲しい要望の背景としては、各部門ごとにRedmineのトラッカーやステータスに独自の意味を付与して運用しているので、メンバーに説明するために欲しいらしい。
トラッカーやステータスは単一のインスタンスであっても、各部門ごとに独自の意味を持って運用している。
すなわち、トラッカーやステータスは同音異義語のような振る舞いを持っているらしい。

こういう背景が発生した要因も何となく理解できる。
日本企業では、現場の権限が強いので、自分たち独自の共通言語を発展させてきた場合が多い。
すると、各現場では、単一のワークフローであっても、自分たち流に読み替えて運用することで、自分たちの現場の文化に合わせようとする。

特に大企業の場合、事業部門はプロフィットセンターなので声も権限も大きい。
したがって、事業部門ごとに組織文化も育まれてくるので、業務フローの同音異義語も発生しやすくなるのだろう。

ただし、ワークフローごとにステータスの説明機能を付ける事までは不要で、単にステータスの説明だけで十分とのことだった。

【2】他方、トラッカーの説明機能は、Ver4.1で実装された。

Redmine 4.1 新機能紹介 (2/3) | Redmine.JP Blog

Feature #442: Add a description for trackers - Redmine

つまり、独自のトラッカー名称で運用している場合、この説明機能があれば、新規加入したメンバーや派遣社員も理解しやすくなるだろう。

同様に、ステータス機能も本家チケットに10年以上前からあがっているので、実現できるといいだろうと思う。

Feature #2568: Description for issue statuses - Redmine

【3】こういう話を聞くと、Redmineは会社で単一の標準Redmineで運用するのがベストではなく、Redmineインスタンスを各部門にVMで配布して自由に使ってもらうという運用もベターではないか、という気持ちになってくる。
特に、大企業ほど各事業部門ごとに組織文化も業務フローも大きく異るので、単一Redmineで開発プロセスや業務フローを標準化するのは所詮無理があるからだ。

一方、デメリットは、RedmineインスタンスのVMを沢山ばらまいた場合、複数のRedmineインスタンスのVerUp作業が非常に煩雑になる点だ。
しかし、このデメリットも、AWSのコンテナサービスやマネージドサービスを上手に使いこなせれば、解決できるだろうと考えている。
実際、ファーエンドテクノロジーでは、RedmineホスティングサービスをAWS上でRedmineの複数インスタンスを提供している訳だが、そういう問題点は既に解決されている。
つまり、似たような発想で、複数個のRedmineインスタンスのVerUp作業をコンテナ化＆自動化することで解決できるだろう、と思っている。

AWS上でクラウドネイティブで再構築した「My Redmine Gen.2」リリース！ - ファーエンドテクノロジー株式会社

Redmineのホスティングサービスをクラウドネイティブで再構築 | RubyWorld Conference 2019

つまり、複数個のRedmineのインフラ構築そのものも、Infrastructure as Codeを実現してしまえばいい訳だ。
この辺りも色々考えてみる。