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を実現してしまえばいい訳だ。
この辺りも色々考えてみる。

Ruby初心者が間違いそうなこと

Ruby初心者が間違いそうなことの記事に共感したのでメモ。
適当なラフなメモ書き。

【参考】
Ruby初心者が失敗しがち/間違えがちなこと5選 | Workship MAGAZINE(ワークシップマガジン)

1. 範囲演算子の範囲を読み違えがち
=> 範囲演算子「..」「...」は異なる。点一つで意味は全く違う。

2. 引数にProcをそのまま渡しがち
=> Procをブロック引数として渡すために、&演算子を使う。
　　さらに、シンボルで渡す方が簡略化できる。
　　injectが良い例。
　　＆演算子を使う部分はPerlに似ている。

3. Array#mapのブロック引数で、途中結果を返却するためにreturnを書きがち
=> mapやselectなど、ブロック引数を受けとるタイプのメソッドを使用する際、「ブロックの途中で得られた値」を「そのブロックで得られた最終結果」として返却したい場合では、「return」ではなく「next」を使う。
結構間違える。

4. 正規表現のマッチ結果を思うように取得できない
=> （）でグループ化した正規表現に対し、組込変数$1,$2...に、マッチング結果が格納される。
　Perlと同じ。Javaとは異なる。Javaの方が面倒。

5. privateなクラスメソッドを定義しようとしてpublicにしがち
=>
　privateの考え方はJavaやC#と全く異なるので、最初は混同してた。

JavaやC#の常識が通用しないRubyのprivateメソッド - give IT a try

[Ruby] privateメソッドの本質とそれを理解するメリット - Qiita

Javaならば、親クラスのprivateメソッドは子クラスでは呼び出せない。
しかし、Rubyでは「privateメソッドはサブクラスからも呼び出せる」考え方が最初は分かってなかった。
「privateメソッドは呼び出す際にレシーバを指定できない」「子クラスでは、親クラスのメソッドをレシーバ無しで呼び出せる」ことを組み合わせれば良い、という記事を読んでようやく理解できた。

6. スコープゲートが厳しい
=> Rubyのスコープゲートは厳しい。
　Rubyは、class、module、defのスコープゲートは乗り越えられない。

ローカル変数をスコープ内側へ - 【旧】PerlerのRuby日記->はてなブログに移行しました

　Perlは、myを付けなければ、ローカル変数はメソッド内でも使える。
　Javaならば、クラス内ではprivateな変数はどのメソッドでも使える。
　この点をよく間違えていた。

　一方、Rubyでは、ブロックならスコープゲートを越えられる。
　たとえば、define_method do～end、Class.new do～endのような書き方でスコープゲートを回避する。
　つまり、フラットスコープ。

AWSクラウドデザインパターンの感想～RDP（Redmine Design Pattarn）の構想

「AWSクラウドデザインパターン」を読み直した。
以下、AWS初心者によるラフなメモ書き。

【参考】
AWS-CloudDesignPattern

【１】「AWSクラウドデザインパターン」本を買ったのは、2013年のデブサミの時だった。
玉川さんにサインを書いてもらった。
「Work hard, Have fun, Make history!」と。

あの頃はまだCDP（クラウドデザインパターン）理解しきれてなかった。
AWSに触れて、ようやくCDPの威力を理解することはできた。
ただし、CDPに記載されたAWSサービスは2012年頃の内容なので、Lambdaなどが含まれていないから、そういう最新のサービスで置き換えられる部分はいくつかある。

振り返ると、2010年代前半にCDP本が出たからこそ、AWSが日本に普及し始めたのだと思う。
CDPは、システムのアーキテクチャ設計、インフラ設計において、AWSのサービスや機能をどの場面で適用するとどんな効果が得られるのか、を明確に示唆してくれる。
クラウドによる設計や実装を試行錯誤していた頃に、CDPを用いることで、より良いクラウドによるアーキテクチャ設計が実現可能になったためだ。
また、アーキテクト同士で、クラウドによるアーキテクチャ設計について、共通の言葉を使って議論できるようになった。
そういうメリットがCDPにはあった。

CDPの形式はGOFのデザインパターンに似ている。
CDPの形式はもっとシンプルだ。
解決したい課題、クラウドでの解決、AWSによる実装、利点、注意点、その他の関連パターン、という項目で必要最低限に絞り込まれている。
CDPというカタログを読んでいくと、どのユースケースでは、どんなパターンを用いるとどんな利点があるのか、クラウドでの解決方針に沿ってAWSはどんなサービスや機能を提供してくれているのか、が理解しやすくなる。
実際に、オンプレのインフラ構築や運用で苦しんできた経験のある人ほど、AWSによる実装方法で、なるほど、と気づく場面が多いはずだ。

イントロの部分もすごく惹かれた。
AWS普及に心血を注ぐ3人が、ある居酒屋にて、クラウドを語る上で共通言語となるデザインパンターンのようなものが必要である、という議論が白熱し、その場で40種類以上のクラウドデザインパターン（CDP）の種をノートに書き出した、とある。
この文に触れて、クラウドの導入でつまずいているプロジェクトがあって苦労したり、オンプレの設計思想に囚われすぎてAWSの良さを活用しきれていない場面で歯ぎしりしたりしたのではないか、と勝手に想像した。
そういう経験を元に、CDPが生み出されたのだろう。

【２】そんなことを考えているうちに、Redmineデザインパターン（RDP）みたいなものが作れないだろうか、と想像したりした。
Redmineの導入・運用も既に10年以上の蓄積があり、必要な運用ノウハウはネット上にたくさん語られているし、運用で必要なロール（組織上の役割）もいくつか語られている。
しかし、そういうノウハウはバラバラに散らばっているに過ぎない。
それらを一つの体系として、暗黙知となっているものを形式知化することには意義があるはず。
なぜなら、まだ困っている人も多いだろうし、経験者が議論する時の共通言語はまだ暗黙知になっている部分が多いからだ。

僕も以前、チケット駆動開発のパターン集みたいなものを編み出そうと考えていた。
そのパターンの根底は、アジャイル開発にチケット駆動開発を適用するにはどんな考え方が必要なのか、があった。
でも、それから5年以上たち、今は情報システム部門の人達が一般ユーザに使ってもらう運用基盤に変化したので、異なるパターン集が必要になっていると思う。

今僕のアイデアとしては、パターンに4つほどのレイヤで階層化して詳細化できないか、と考えている。
イメージは、ユースケース層＞マネジメント・ロール層＞アプリ・機能層＞ソース・実装層。
たとえば、ユースケース層では、課題管理・ソフトウェア開発・サポートデスクなどの実際の利用シーンでカテゴライズする。
マネジメント・ロール層では、Redmine職人・Redmineエバンジェリスト・Redmine警察のようなロール、PMxTMマトリクスのような組織への導入方法。
アプリ・機能層では、Redmineの各機能のベストプラクティス。たとえば、チケットのワークフロー、JAXAが生み出したカスタムフィールドやプロジェクトのOR・AND条件など。
ソース・実装層では、ViewCustomizeプラグインによる課題解決、プラグインやカスタマイズによる課題解決など。

このようにパターンをレイヤ化して区別することで、パターンの粒度を区別できること、初心者や経験者が会話できる共通言語を提供できること、というメリットがあると思う。
僕が以前考えていたパターンはアジャイル開発への適用に特化しすぎていたので、2020年現在の実情に合わせたデザインパターンを作れたらいいなあ、と考えた。