プログラマの思索

JAXAのRedmine事例報告にあるRedmineモデルを自分なりに理解して書いてみた。
Redmineは綺麗なレイヤ構造になっていると感じた。
ラフなメモ書き。

【参考】
JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒント

JAXAのスーパーコンピュータ活用課でRedmineを使ったチケット管理システムの経験論文: プログラマの思索

JAXAのRedmine運用事例の分析～「ロール設定のORルール」と「カスタムフィールド設定のANDルール」: プログラマの思索

【1】JAXA Repository / AIREX: CODA: JSS2の運用・ユーザ支援を支えるチケット管理システム: Redmineの事例と利用のヒントの「Figure 8　Redmine の主な定義の構造」を引用して、RedmineのアーキテクチャをVer3.3の機能「Tracker role-based permissions」も含めて描いてみた。

Redmineは、幾つかのレイヤに機能を配置するように分割設計されているのがよく分かる。
※CC Atributionライセンスでダウンロード可能とした。

【2】Redmineのレイヤは大きくは2つ(論理層・物理層)、細かく分けると6層に分割できると思う。

物理層は、利用者がRedmineプロジェクトでチケット管理するレイヤ。
論理層は、Redmineシステム管理者が、チケット管理で使われるワークフローやロール、権限制御を行うレイヤ。

【2-1】物理層は、ユーザ層・ロール割当層・PJ定義層に分かれる。
幾つかのポイントがある。

一つ目は、PJメンバーにユーザを割り当てる時に、ロールをアサインするが、その時に「ロールのOR設定ルール」を使うと良い。
つまり、PJメンバーがチケット管理で操作できる権限の範囲はロールで決まるので、複数のロールを組合せることで詳細かつ、MECEに制御できる。
例えば、業務ごとに必要なロールに分割しておき、それら複数のロールを組み合わせて、チケット管理の操作権限の範囲を決めるようにすれば、Redmineのアクセス権限をより厳格に運用できるだろう。
また、新たな権限を登録する場合、ORルールのおかげで修正範囲が共通箇所になるように設定しておけば、保守作業も効率化できる。

二つ目は、PJで使われるチケットのカスタムフィールドは、「カスタムフィールドのAND設定ルール」を用いると良い。
つまり、PJで使われるトラッカーのCFは、PJごとにOn/Offを設定することで、CFの使用可否を制御できる。
例えば、同じトラッカーでも、PJごとに表示されるチケット属性の個数が異なるように設定できる。
この運用ルールを使えば、一つのトラッカーで、複数のカスタムフィールドの表示・非表示を組合せられるので、トラッカーの数を減らすことができる。

Redmineで運用するチームが増えて、業務の種類も増えると、どうしてもトラッカーが増大しがちだが、「カスタムフィールドのAND設定ルール」を用いることで、トラッカーの数に制限をかけることができるだろう。

3つ目は、モジュールや使用トラッカーをPJごとに割当できること。
不使用のモジュールやトラッカーはOFFにして、操作を簡素化できる。
特に、文書やフォーラムの機能を使わないならば、OFFにして、少しでも操作を簡単にした方が運用しやすい。

【2-2】論理層は、チケット定義層・ロール定義層・モジュール定義層に分かれる。

【2-2-1】チケット定義層は、ステータス・ワークフロー・トラッカー・標準フィールド、カスタムフィールドの属性とその関係が設定される。
このレイヤが明確に分離されていて、汎用的に作られている点がRedmineの最大の特徴だろうと思う。
だからこそ、事務処理・問合せ・資産管理などの多様な業務にRedmineを適用できるわけだ。

【2-2-2】ロール定義層は、ロール毎にモジュールやプラグインの権限の制御が設定される。
Ver3.3では、「Tracker role-based permissions」の機能が実現されたので、「ロールと権限」画面の下部に、ロール単位かつトラッカー単位にチケットの参照・登録・編集・削除・コメント追加の権限を細かく設定できるようになった。
この機能は、非常に面白いし、Redmineの運用方法のバリエーションを増やしてくれるだろうと思う。

例えば、事務処理ワークフローでは、Redmineに属するユーザ全員が参照できて、かつ、チケットの新規登録による申請はできるようにしたい。
しかし、その後の承認フローは事務処理PJに属するメンバーだけで回して、チケットを精査するような運用にしたい。
その場合、「Tracker role-based permissions」を使えば、「非メンバー」ロールのユーザは「チケット参照・登録・コメント追加」の権限だけ付与し、それ以外の権限は付与しない運用も考えられる。

あるいは、完了した障害チケットや問合せチケットは、コメント追記のみ権限を許可する、と言った運用も考えられるだろう。

つまり、ロール定義層で、ロール毎にRedmineのチケット操作、モジュール操作の権限を細かく設定することで、現場の業務フローにより近づけることも可能だろう。

【2-2-3】モジュール定義層では、プラグイン情報やチケットトラッキングなどの設定が行える。
チケットトラッキングは、より詳細な設定ができるようになっている。

・異なるプロジェクトのチケット間で関連の設定を許可
・異なるプロジェクトのチケット間の親子関係を許可
・チケットをコピーしたときに関連を設定

上記の設定は、特に製品の並行開発、派生開発、事務処理ワークフローの申請チケット複製で威力を発揮するだろう。
派生元のチケットを元に、関連するシステムの作業を親子チケットにしたり、関連チケットにしたり、複製したりすることが可能になる。
また、事務処理ワークフローでは、過去に使った完了チケットを複製したい時が多いが、「チケットをコピーしたときに関連を設定」が「都度選択」に選択しておけば、不必要な時は「重複する」関連を付けない運用もできる。

・親チケットの値の算出方法

「親チケットの値の算出方法」の設定では「子チケットから算出」にすれば、「WBS100%ルール」を当てはめられるし、「子チケットから独立」を選んでおけば、「WBS100%ルール」が適用されない。
特にWF型開発でWBSを詳細化して、かなり深い階層で作った場合に、「WBS100%ルール」を当てはめたくない時に使える。
「親チケットの値の算出方法」の設定を「子チケットから算出」にしておくと、親チケットに記入した当初の予定情報が、子チケットを登録したタイミングで消えてしまうリスクを無くすことができるからだ。

・進捗率の算出方法

「チケットのフィールドを使用」ではなく「チケットのステータスに連動」へ設定しておけば、「90％進捗シンドローム」「停滞したチケット」にはまることなく、明確な進捗管理ができるようになる。

【2-3】このように見ると、利用者はプロジェクト定義層の機能を主に使うが、その設定情報の保守は、論理層で行われている。
その論理層はシステム管理者が、業務に応じてRedmineのパラメータを色んなバリエーションで設定しているわけだ。

おそらく今まで適用しにくかった業務にも、Redmineを当てはめることができる可能性が出てくるだろう。

【3】Redmineの初期設定は、ERPのパラメータ設定に似ている。
この設定方法を上手く使えば、多様な業務のワークフローを実現できる。

すると、業務ごとに、Redmineの設定を保存できないか？という思いが出てくる。
例えば、設定情報をXMLで出力し、後でインポート可能にしたいのだ。
つまり、事務処理、問合せ、資産管理などの業務ごとにPJ初期設定情報を保存し、Redmineインスタンスごとにインポートすることができれば、業務ごとのRedmineテンプレートを配布する事もできるだろう。

実際、ワークフロー管理のパッケージ製品などでは、ワークフロー単位に初期設定情報を出力したりインポートする機能が普通は付いている。
設定情報はXMLであり、複雑な機能はJarなどのコンポーネントを登録することもできたりする。
その機能があるおかげで、データ移行やシステム移行がすごく楽になる。

同様に、Redmineでも、業務ごとにPJ設定情報をXMLで出力したり、インポートできれば、データ移行が楽になるかもしれない。

【4】このようにRedmineはきれいにレイヤ化されているメリットは何か？
機能が明確にレイヤ化されていることで、機能追加やカスタマイズがやりやすくなるメリットがある。

Redmineは誕生して10年経ったが、機能拡張が漸進的に行うことができた理由の一つは、機能を明確にレイヤ化された設計が当初からなされていたことではないだろうか。
そして、そのような設計思想を、JAXA担当者の方のモデルを見て初めて知ったことを思うと、JPLは、そんな設計思想を最初から持っていたのだろうと推測する。

@sakaba37さんにそんなことを話してみたら、JPLはヨーロッパ人なので、アメリカ人よりも、ソフトウェアアーキテクチャに対して美的意識が強いのでしょう、と聞いた。
なるほど、そうなのかな、と思ったりする。

実際、JPLは自動テストコードのカバレッジにすごくこだわっているから、ソフトウェアの品質にも美的意識が強いのだろうと推測する。

Redmine build status
Redmine code coverage

JPLに一度、Redmineの設計思想を聞いてみたい気がする。

【追記】
的確な意見があったのでリンクしておく。

yojikさんのツイート: "ここで言われてる論理層、物理層という言葉、アナリシスパターンにおける知識レベル、操作レベルですな。 (パターンが忘れ去られることによって用語の統一が失われる問題) / “JAXAのRedmineモデル～Redmineはレイヤ構造…” https://t.co/hMhFCnp2WF"