« Redmineと連携する構成管理リポジトリの作成を自動化する方法 | トップページ | キャッシュフロー計算書はエクセルで簡単に作れる »

2016/03/31

JAXAのRedmine運用事例の分析~「ロール設定のORルール」と「カスタムフィールド設定のANDルール」

JAXAのRedmine運用事例の経験論文をじっくり読み直した。
特に、「ロール設定のORルール」と「カスタムフィールド設定のANDルール」の箇所が参考になったのでメモ。

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

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

【1】Redmineはとても柔軟なチケット管理システムなので、ソフトウェア開発のタスク管理以外にも、システム保守などの雑多な作業管理や、日々の事務作業にも適用可能だ。
すると、それぞれの業務の特徴を把握した後、Redmineにどのような設定を行えば、業務の要件を満たすのか、という業務要件とRedmineの機能のフィットギャップ分析が必要になってくる。

この作業はいわゆるERPのパラメータ設定と同じである。
つまり、ERPと言うパッケージ製品の中身、特にDB設定と機能の詳細を知らないと、適当にパラメータ設定してしまい、実際の業務では使い物にならない、と言われてしまう。
普通は、ERPコンサルタントと呼ばれる人が高い単価で仕事している作業になるだろう。

【2】Redmineでは、システム管理者がブラウザ上で自由にパラメータを設定できる。
【2-1】もっとも重要なパラメータは、トラッカー毎のワークフロー設定だろう。
ワークフローを定めて、チケットのステータス遷移がスムーズに流れなければ、業務として扱いづらい。

【2-2】次に重要なパラメータは、ロールとカスタムフィールドの設定だろう。
ロール毎に、Redmineの機能を絞込できるので基本は、組織の職位とロールを対応付ければいい。

しかし、正式な職位(部長、課長、係長)とは違って、その部署内のローカルな職位も必要だったりする。
例えば、工場では、数多くの班があって班長が品質管理やQC活動を推進していたりする。
あるいは、地方の営業所では、部長がおらず、稟議を回すには現地の人で回したいために、一部の業務だけ稟議決裁できる特別な権限を付与していたりする。

つまり、組織の職位とロールは必ずしも1対1に対応しないし、Redmineのロールはむしろ、もっと膨れ上がる可能性が高い。
JAXAの報告書のように、トラッカー * ロールの分だけワークフローの種類が増えるので、Redmineがどんどん複雑になってしまう。
これはRedmineに原因があるのではなく、業務に対するRedmineのパラメータ設定に問題がある。

【2-3】また、管理者の観点では、カスタムフィールドをチケットに増やしたがる。
なぜなら、チケット集計結果にカスタムフィールド単位のメトリクスを出力して、品質管理や稼働分析などに使いたいからだ。

チケット入力の運用ルールさえ徹底できれば、リアルタイムにチケット集計することで、いろんな観点で最新のメトリクスを採取できるメリットがある。
Redmineはガントチャート以外にもたくさんのビューがあるし、Excel出力すれば、好きなだけExcelマクロでグラフ化したりできる。

しかし、カスタムフィールドを増やすと、JAXAの報告書にあるように、カスタムフィールドが1個だけ違ったとしても、トラッカーを新規登録していくと、トラッカーが増大してしまう欠点がある。
これも、Redmineに原因があるのではなく、業務に対するRedmineのパラメータ設定に問題がある。

【3】JAXAが指摘している「ロール設定のORルール」と「カスタムフィールド設定のANDルール」は、上記の問題対するパラメータ設定の解決方法になる。

【3-1】「ロール設定のORルール」とは、プロジェクト設定>メンバーの画面で、ユーザ1人に対し、Redmineのロールを複数個対応させるルールだ。
例えば、リーダーのAさんは管理者と開発者、開発者のBさんは開発者ロールのように割り当てる。
すると、Aさんは管理者ロールとして完了ステータスに更新可能だが、Bさんは開発者ロールだけなので完了ステータスに更新できない。

確かに、Redmineのプロジェクト設定>メンバー画面では「管理者,開発者」のように表示される場合があるが、それは「ロール設定のORルール」を意味しているわけだ。

この運用ルールに基いて、JAXAの報告書では例えば、「一般」「承認者」「保守」というロールを作り、ユーザがプロジェクトごとに異なるロールを選択できるようにしている。
つまり、ワークフローのステータスをグループ化して、ステータスをグループ化した各グループ単位にロールを割り当てることで、ロールによる機能制限が可能になる。

普通はステータスやロールはそんなにコロコロ変わるわけではない。
業務や組織は頻繁に大きく変わるわけではないから。
だから、上記のように最初にきちんとパラメータ設定すれば、業務にフィットした運用が可能になるだろう。

JAXAでは、メリットを下記のようにまとめている。

(引用開始)
このように,ロール設定の OR ルールを利用することでロールと権限及びワークフローの保守負担を削減できる.
CODA では,導入当初は Figure 3 のような定義をしていたが,システムの利用範囲が広がるにつれてロールやワークフローの保守が複雑になってきたため,運用開始から約 1 年経過したところで Figure 4 に示したロール設定の OR ルールを利用する方法に変更した.
(引用終了)

【3-2】「カスタムフィールド設定のANDルール」とは、1個のトラッカーに対し、全ての業務をカバーするようなカスタムフィールドを全て追加しておき、プロジェクトごとにトラッカーのカスタムフィールドを選択するルールだ。

例えば、「全般」トラッカーは標準フィールド以外に、「影響度」「支援SW種別」「問合せ先」「ISO9001項番」というカスタムフィールドを追加したとする。
その後、プロジェクトAの「全般」トラッカーでは、プロジェクト設定>概要>カスタムフィールド画面で、「影響度」「問合せ先」だけを選択し、「支援SW種別」」「ISO9001項番」というカスタムフィールドはチェックしない。
すると、プロジェクトAでは、「全般」チケットの「影響度」「問合せ先」は入力できるが、「支援SW種別」」「ISO9001項番」は表示されないから入力できない。

つまり、管理画面のトラッカーは、全てのカスタムフィールドを包含するように設定し、各プロジェクト設定画面で必要なカスタムフィールドだけ選択して、不要なカスタムフィールドはOFFにすれば、トラッカーの種類を増やす必要がなくなる。
JAXAはそのような運用をしているらしい。

JAXAでは、メリットを下記のようにまとめている。

(引用開始)
この機能を利用すると,1 個のトラッカーで,業務のフローは同じだが業務ごとに管理すべき内容(フィールド)が異なるケースに対応できる.これは,保守が容易になる以外に,利用者にとっても以下のような利点がある.
(1) 業務分野への関係があるフィールドのみが表示されるので,画面表示の煩わしさが少なく,業務に集中しやすい.
(2) 利用者が複数の業務分野を担当している場合,プロジェクトが異なっても同じトラッカー(例では「全般」)を利用できるので,トラッカーの選択肢が少なくなり,選択に迷うことが少なくなる.
(引用終了)

さらに、Redmineではカスタムフィールドに、ロールごとに「必須」「読み取り専用」の設定が可能なので、その機能を考慮すると、より業務に即した運用が可能になるだろう。

【3-3】なお、「ロール設定のORルール」と「カスタムフィールド設定のANDルール」は正直複雑な設定方法なので注意が必要だ。
つまり、Redmineを業務に適用する前に、業務に必要なワークフロー(つまりトラッカー)や管理項目(カスタムフィールド)を事前に洗い出し、どのように運用を行うか、という運用設計を十分に検討する必要がある。

例えば、「カスタムフィールド設定のANDルール」では、RedmineプロジェクトごとにカスタムフィールドをON/OFFに選択するので、間違って選択したり忘れないように注意が必要になる。

つまり、業務の複雑さに合わせたRedmineの運用を回すには、Redmineのパラメータ設定ないし運用設計がそれなりに複雑になってしまうというトレードオフの関係が発生するので、注意が必要だ。

【4】JAXAはRedmineの運用ルール「ロール設定のORルール」と「カスタムフィールド設定のANDルール」を試行錯誤しながら見出したわけだ。
Redmineを作ったJPLも、そのような発想でRedmineを設計していたのだろうと推測する。
JPLすごいね。

【追記1】
Redmine本家でも、Redmineの運用事例として「Public sector>Japan Aerospace Exploration Agency (JAXA) 」にリンクが貼られている。
世界に誇れるくらい、日本の良い事例だろうと思う。

WeAreUsingRedmine - Redmine

【追記2】
JAXAのRedmine事例報告を記載した方から、「フィールド設定のANDルールにおいて、ANDルールの対象はカスタムフィールドのみであり、標準フィールド(例:対象バージョン、カテゴリ)は選択できない」内容に、論文を訂正された、という記載がありました。
詳細は、下記の論文を参考ください。

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

|

« Redmineと連携する構成管理リポジトリの作成を自動化する方法 | トップページ | キャッシュフロー計算書はエクセルで簡単に作れる »

Redmine」カテゴリの記事

コメント

コメントを書く



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


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



« Redmineと連携する構成管理リポジトリの作成を自動化する方法 | トップページ | キャッシュフロー計算書はエクセルで簡単に作れる »