JAXAのRedmine運用に隠れている運用ルール

JAXAのRedmineモデル、JAXAのRedmine運用ルールを読み直しながら、考えたことをメモ。

【参考】
JAXAのRedmineモデル～Redmineはレイヤ構造になっている: プログラマの思索

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

【1】JAXAのRedmineモデルでは、Redmineの機能は、利用者の物理層とシステム管理者の論理層に分かれていて、細かく分ければ6層になると思う。
それぞれのレイヤの依存関係を紐解いた後、JAXAのRedmine運用ルール「ロールのORルール」「CFのANDルール」が編み出された。

その運用ルールを実施するには、幾つかの前提となる運用ルール、またはRedmineの設定があるのではないか、と考えている。
下記の3つの目的で、隠れている運用ルールを洗い出してみた。

(1)目的：WFの保守負担を減らす
・WFと権限の分離ルール
・ロール単位のWF分割ルール
・ロールのORルール

(2)目的：トラッカーを増やさずに流用する
・CFのANDルール
・業務単位のPJ分割ルール

(3)目的：PJメンバーにロール割当の負担を減らす
・グループ割当ルール

【2】JAXAの運用ルールでは、WFの保守負担を減らすために、あえてロールを増やす。
その場合、あるロールはワークフロー設定だけで権限のチェック無し、他のルールは権限のチェックはあるがワークフローのステータス遷移は無し、と分ける。
これが「WFと権限の分離ルール」。
たとえば、JAXA資料では、「文書係」「管理係」は文書登録やPJ設定の権限は持つが、ワークフロー設定はない。
一方、「承認係」はワークフロー設定はあるが、権限のチェックはない。

さらに、ワークフロー設定ありのロールでは、ステータス遷移の前半と後半を分離して、それぞれのロールを割り当てる。
これが「ロール単位のWF分割ルール」。
たとえば、JAXA資料では、「レギュラー」は「承認前」ステータスまで、「承認係」は「完了」ステータスに更新できる権限を持つ。

これらの前提があって初めて、「ロールのORルール」が意味を持つ。
つまり、複数のロールを組合せることで、プロジェクトリーダーのロール、開発者のロール、リーダーではないがPJ設定を保守できる権限を持つサブリーダー、のようなロールを分けることができる。

このようにあえてロールを増やすように、複雑にワークフロー設定や権限の設定を行う理由は、ワークフロー設定や権限設定の保守の影響範囲を狭めるためだ。
業務が変わったり、増えたりした時に、一部のロールのチェックを付けたり変更するだけで良いようにするためだ。

さらに、PJメンバーにロール割当の負担を減らすために、ユーザグループの単位でロールを一括アサインする。
そうすれば、数多くのユーザのロールを逐一編集する手間もなくなる。

利用シーンとしては、「管理者」「開発者」だけのロールでは不十分で、組織構造に応じた複雑なロールが多い場合、上記のような運用が必要になるだろう。
つまり、組織構造の複雑さが影響している。

【3】トラッカーを増やさないために、JAXAの運用ルール「CFのANDルール」を適用すると、最終的には、１プロジェクトに１個のトラッカーだけを配置するような運用になると思う。

実際、JAXA資料では、「レギュラー」トラッカー１個だけで、複数のカスタムフィールドの組み合わせをPJごとに行い、各PJで業務をチケット管理する。
すなわち、あるPJは是正処置、あるPJは問合せ管理、あるPJは作業支援のように、数多くのPJに分割される。
おそらく、それらのサブPJは、PJの階層化によってまとめられているのだろう。
これが「業務単位のPJ分割ルール」になると思う。

つまり、Redmineトップ画面の右上のPJメニュープルダウンが、トラッカーグループのような機能を持ち、自分の担当業務が階層化されたメニューとなる運用になるはず。
この運用によって、利用者は、各PJを選択するだけで、どの業務にどのトラッカーのチケットをアサインするか、ということを考えなくても良い。

この運用方法は、トラッカーのカスタムフィールドが微妙に違うが、ワークフローは全て同じ業務に対し、プロジェクトごとに業務を割り当てて、業務専用のプロジェクトとしてチケット管理する。
メリットは、トラッカーを増やさなくてよいこと、そして、PJ名が業務名なので区別しやすいことだろう。
デメリットは、PJが数多く作られてしまうことがあろうが、組織や業務の階層化をPJの階層化に当てはめれば、たぶん問題は解消されるだろう。

【4】以上のような運用ルールを考えると、Redmineに対し、多様な業務を複雑な組織階層で対応したい時、上記のような隠れた運用ルールと設定方法が必要になると思う。
したがって、このような複雑な設定を準備するには、事前に、現状の組織構造と業務内容を把握したうえで、Redmineの機能とフィットギャップ分析する作業が必要になるだろう。
その作業はERPの事前パラメータ設定作業と同じような内容になるだろう。

すると、業務ごとにRedmineの設定を登録したい場合、Redmine設定情報をXMLなどのような形式で保存できる仕組みが欲しくなる。
つまり、ロール・権限・ワークフローなどのRedmineの論理層だけの設定情報をXMLで保存しておき、新たなRedmineインスタンスを立ち上げる時は、そのXMLを読み込むだけで、すぐに業務のチケット管理が運用できるようにしたいのだ。

実際、汎用ワークフロー管理システムのパッケージ製品では、ワークフロー設定や組織情報はXMLやCSVなどの形式でインポート・エクスポートできる仕組みがあり、データ移行やバックアップで使われるような機能として提供されている時が多い。
Redmineもそのような機能があれば、たとえば、サポートデスク業務、勤怠管理の業務、課題管理の業務などのように、業務ごとのRedmine設定情報がXMLで提供され、そのXMLを読み込むだけで、すぐにRedmineで業務の運用が開始できるはずだ。

RedmineにはREST APIが既にあるので、論理層の設定情報をXMLやJSONで保持することは可能だし、その設定情報をGitHubで公開すれば、数多くのユーザにもメリットがあるだろう。

Redmineをソフトウェア開発の作業支援だけでなく、汎用的なワークフロー業務システムとして使うためにはどんな機能が必要なのか、改めて考えてみたい。