Redmine3分クッキング
設定変更を乗り切る工夫 事例

2017/5/13
redmine.tokyo 第12回 勉強会 LT#3
国立研究開発法人 宇宙航空研究開発機構
スーパーコンピュータ活用課
木元一広

1

自己紹介
Redmine利用歴
2013/12- (約3年 (若干ブランクあり))
CODAの運用・保守・拡張 他
スーパーコンピュータ
活用課の活動を記録・管理

JAXA 研究報告

JAXA-RR-15-003 「CODA: JSS2の運用・ユーザ支援を支えるチケット管理システ
ム: Redmineの事例と利用のヒント」
https://repository.exst.jaxa.jp/dspace/handle/a-is/557146
英訳もあります“CODA: Ticket Management System toSupport JSS2 Operation and Assistance toUsers: Redmine Implementation and Hintsof Its Usage”
https://repository.exst.jaxa.jp/dspace/handle/a-is/574705?locale=en2

本日のお題変更したいフィールド以外は過去の状態を維持して(できるだけ触らずに)更新するには?
課題とその対処法

Redmineの設定変更は、GUIで簡単に行える!
でも、既存チケットのデータの値の保守などをスムーズに行うには、これだ
けでは足りない・・・

今日は実際に経験した内容と、その背景にあるRedmineの構造もちょっとだけ触れて、ご紹介します。

実際よりもややシンプルなシナリオで再現してご紹介します。
資料中の画面コピーは、説明用に作ったもので、CODAではありません。
Redmine V.3.1.1 で作りました。

CODAの変遷
当初のとてもシンプルなチケットから、徐々に組織運営の管理・改善のツールとして強化 ・・・

時期

2016/夏2014/夏期日(必須)

ベンダーS/W(オプション)

QMS文書
(必須)

溜まっていく過去のチケット

修正追加

ISO-9001 文書
期日(オプション)

ベンダーS/W(オプション)[運07a]ユーザ要望票[運15a]改善提案管理票[運15b]不適合管理票
その他 ...

S/W障害の分類を意図

2014/4(当初)

期日(オプション)

01-Operating System
02-File System Software
03-管理・監視S/W
その他 ...

4

組織運営の管理・改善のツールとしてさらに強化 ・・・

ここで、課題が発生
廃止2017/3

期日(必須)

ベンダーS/W(オプション)

作業分野

追加

(必須)

QMS文書
(必須)

時期

2016/夏2014/夏2014/4(当初)

期日(必須)

期日(オプション)

期日(オプション)

溜まっていく過去のチケット

作業対象を記録⇒見える化
01-運営
02-QMS活動
ベンダーS/W
QMS文書:(オプション)(必須)
11-JSS-ID申請
12-事業コード申請
ISO-9001 文書:[運07a]ユーザ要望票
21-ユーザプログラム[運15a]改善提案管理票
22-ISVアプリケーション [運15b]不適合管理票
ベンダーS/W:
その他 ...
(オプション)z1-Operating System
S/W障害の分類を意図
z2-File System Softwarez3-管理・監視S/W
01-Operating System02-File System Software その他 ...
03-管理・監視S/W
その他 ...

5

過去チケットの「ベンダーS/W」の値を「作業分野」に引き継
ぎたい

新旧チケットを通しで検索できるように廃止

2017/3

期日(必須)ベンダーS/W(オプション)

作業分野

追加

(必須)

QMS文書
(必須)

2014/夏2014/4(当初)

期日(必須)

期日(オプション)期日(オプション)検索

時期

2016/夏

01-運営
02-QMS活動
ベンダーS/W
QMS文書:(オプション)(必須)
11-JSS-ID申請
12-事業コード申請
ISO-9001 文書:[運07a]ユーザ要望票
21-ユーザプログラム[運15a]改善提案管理票
22-ISVアプリケーション [運15b]不適合管理票
ベンダーS/W:
その他 ...
(オプション)z1-Operating System
S/W障害の分類を意図
z2-File System Softwarez3-管理・監視S/W
01-Operating System
02-File System Software その他 ...
03-管理・監視S/W
その他 ...

溜まっていく過去のチケット

作業対象を記録⇒見える化6

過去チケットの「ベンダーS/W」の値を「作業分野」に引き継ぎたい

新旧チケットを通しで検索できるように読み取り専用にし、暫く保存

2017/3

2014/4(当初)(オプション)

作業分野
(必須)

QMS文書
(必須)

作業対象を記録
過去チケットには、「期日」や「QMS文書フィールド」に値⇒見える化が入っていないものがある。 01-運営
02-QMS活動
期日過去、必須でなかったり、そのフィールドが存在しなベンダーS/W
QMS文書
:
(必須)
(オプション)(必須)
かったときのチケット。
11-JSS-ID申請
12-事業コード申請
ISO-9001 文書「作業分野」に値をセットしようとすると、これらの値も:[運07a]ユーザ要望票
セットしなくてはいけない。 21-ユーザプログラム[運15a]改善提案管理票
22-ISVアプリケーション[運15b]不適合管理票
期日いい加減な値はセットしたくない。
ベンダーS/W:
その他 ...
(オプション)(オプション)「ベンダーS/W」は一定期間(3か月ほど)読み取り専用にして
z1-Operating System
S/W障害の分類を意図
z2-File System Software
保存しておきたい。

期日(オプション)

溜まっていく過去のチケット

2014/夏(必須)

ベンダーS/W

検索時期2016/夏期日

追加

z3-管理・監視S/W
01-Operating System
02-File System Software その他 ...
03-管理・監視S/W
その他 ...

7普通にやると、当然、 怒られます できません ⇒ どうしよう?!

8Redmine の構造を思い出してみる

フィールドの「必須」指定はワークフローでもできる。
ロール毎に使い分けできる !

カスタムフィールド「必須」属性
簡単
設定間違いが起きにくい
細かな設定使い分けはできない
標準フィールドでは指定できない

ワークフローでのフィールドの振る舞い設定
複雑・・・ ワークフロー毎(ロールxトラッカー)設定が必要
設定間違いが起きる可能性がある
細かな設定使い分けができる ⇒ ロール毎に使い分けできる
標準フィールドではここでの指定だけ(1) ロール定義層

ロール

論理的な定義-

名前権限(2) チケット定義層カスタムフィールド
ワークフロー

ステータス
--

名前
属性
- 初期値(y/n)- 終了 (y/n)

トラッカー

チケットの動きを決定する
ロールとステータスの定義をトラッカーに組み込む- ロール毎のステータス遷移- ロール毎のフィールド操作権限- 読み取り専用・必須-

物理的な実体の定義

名前概要 等 モジュール- このプロジェクトで使用するRedmineの機能- チケットトラッキング、Wiki, フォーラムなど(3) プロジェクト
定義層(4) ロール割り当て層

木元, “JAXA-RR-15-003”, 2015 を元に作成

名前形式(リストから選択等)
値(選択肢、長さなど)
属性(必須・複数選択可など)

標準フィールド
担当者
開始日
期日 など

このプロジェクトで使用するトラッカー
チケットのカテゴリ-

このプロジェクトで実際に使用するカスタムフィールド

プロジェクト毎に独自の選択肢を定義できる唯一のフィールド

メンバー

ロール
ユーザー

(5) 利用者定義層

名前標準フィールド
使用する可能性のあるカスタムフィールド

--プロジェクト
-

なんだか、できそう!?

-

名前
ログイン名
- メールアドレス等

ロールグループ-

名前ユーザーのリスト

ロール割り当てグループやユーザに複数のロールを割り当てられる⇒ ロール毎の権限オンを組み合わせて活用

9

カスタムフィールド定義の「必須」指定をオフ代わりに、ワークフローで設定
10

ワークフローの設定を使い分けるためのロールを追加
過去チケットの値の保守専用ロール「必須欄保守」

~
~

~
~

11

普段の(通常の)ロールでは「必須」指定をワークフローで設定「必須欄保守」ロールだけは、期日・QMS文書は制限なし

12

やってみると・・・メンテする人に「必須欄保守」ロールを割り当てれば変更OK。
期日はブランクのまま無変更。

作業分野に値をセットできた。
移行

QMS文書はブランクのまま無変更。

13

リスト画面からの一括操作で大量のチケット更新が楽々完了!

実際は、選択肢毎に何枚・何十枚をまとめて実施しました

終了後は、「必須欄保守」ロールを削除。
または他と同じにして抜け穴を塞ぐ14

注意とヒント

実は、「必須欄保守」のワークフローで制限なしに設定すれば、誰にも「必須欄保守」ロールを割り当てなくても、 Redmine管理者は更新OKになります。
Redmine管理者は、誰かができる可能性のあることは、できる。

ワークフローでの「必須」設定は、設定漏れなどの危険性もあります。
日頃のロールやトラッカーの整理整頓・把握が重要です。
カスタムフィールドでの「必須」の方が確実です。

感想

よくできてるなぁ > Redmine

設定の構造や、定義の適用範囲などに納得感がある。

15

謝辞
ご清聴ありがとうございました
そして、皆様にお礼申し上げます
CODAを利用している利用者各位、Redmineが好きで(?) 公私で活用している皆様、Redmineのイベントなどに参加される皆様、Redmineについて書籍・イベント・ブログなどで情報発信している皆様、Redmineのエコシステムに携わっている皆様、Redmineの開発・改善・機能拡張、プラグインに参画されている皆様、それ以外にも、挙げきれない、いろいろな皆様、ありがとうございます
今後も盛り上げていきましょう !!
16おまけ: ロール設定でこんなこともできますロール » 権限レポートで、こうするとキャロルには文書タブが見えるマークには見えない機能の確認や、運用開始前に一部メンバーだけでデータを整備する、などに利用できます17