Redmine 運用について書いてみるシリーズ 2/3。今回は職場の Redmine を運用するためのルールと諸設定をまとめる。守秘義務に抵触しそうな内容を避けるため、ぼかして書いているところもあるが主旨には影響していないはず。

システム管理者

システム管理者とは Redmine のユーザー管理画面においてシステム管理者が有効になっている状態を指す。プロジェクトの管理者とは別なので注意すること。この権限を持つユーザーは Redmine のあらゆる設定を変更できる。

Redmine を運用するにあたり、少なくとも 1 名 (1 ユーザー) は必要になる。

任命するのであれば Redmine のインフラと機能の両面に通じているユーザーであることが望ましい。とはいえ Redmine の動作環境は Ruby だけでなく Passenger や HTTP サーバー、DBMS も絡み複雑。もしこれらの知識に不安を感じるなら My Redmine のようなホスティング サービスを利用するのもありだろう。

インフラも担当するなら Redmine 本家のロードマップや Redmine.JP Blog あたりを巡回して最新動向をおさえておく。最近のバージョンではあまり破壊的な変更はないものの UI 変更はインパクト大きいので、更新前に利用者へ通知するぐらいの配慮はほしい。

システム管理者が 1 名だと運用に関する知見が属人化して代替をたてるのが難しくなる。負担も大きくなるため、複数のシステム管理者を確保しておきたい。現職の場合、

• メイン 1 名
• サブ 2 名

という体制にしている。メインが私でインフラも担当、サブはユーザーやプロジェクト追加など設定面の管理だけ実施という感じ。

インフラについては将来 Ansible で構築できるようにして DB や files だけ引き継ぐとか、そういう管理を考えている。現在はこのあたりの情報を Redmine の Wiki にまとめており、それを読みながらであればサブでも実行可能ではある。

認証

Redmine 管理画面の認証は以下のように設定している。

Redmine を業務管理に利用するのであれば、認証を可能な限り厳しくしてアカウント操作もシステム管理者のみに許可することが望ましい。管理と依頼窓口を一元化することで不測のトラブルを防止できる。

OSS プロジェクトなら不特定多数のユーザーを募ることになるだろうから、パスワードの文字数を長くするぐらいで他は標準設定のままでもよさそう。例えば Redmine 公式はユーザーによるアカウント登録を許可しており、テーマ作者自身が Theme List を更新できる。私も登録しており、このページを編集することがある。

メール通知

Redmine 上で自身の関係するチケットやウォッチ対象が更新されたとき、メールで通知する機能がある。詳しくはメール通知 - Redmine用語解説を参照こと。

地味ながら非常に重要な機能なので必ず有効にしている。Redmine はチケットや Wiki をコンテンツとする一種の CMS と見なせる。CMS を浸透させるためには、そこに関心事があることを積極的に通知することが重要。コンテンツ更新を把握するため同期的に張り付くなんて、いまどきありえない。非同期に更新通知がきて好みのタイミングで反応するのがあるべき姿ではないか。

メール通知対象とする動作は大量にあるけれど、標準設定であるチケットの追加と更新だけ有効にしている。他の操作で通知するのは過剰だ。例外としてニュース機能を利用していならその性質上、メール通知したほうがよさそう。

プラグインとテーマ

プラグインは一切、使用していない。理由は以下。

• インストールが面倒
  • 基本は手動で wget、unzip、rake コマンド実行
  • 公式リポジトリはなく、基本的に野良プラグイン
  • gem に絡む不具合でインストールできないケースも何度か遭遇
  • Ruby、Rails、DBMS の知識がないとエラーを理解できない
  • 時にはプラグインのコードに手を入れることになる
• 著名なものでも更新が滞りがち
  • 最新の Redmine に追従できていない
  • 導入済みで migrate なら動作するが新規インストールには失敗する、とかあって怖い
• プラグインに不具合が発生すると Redmine 全体がクラッシュすることがある
  • 業務で発生したら大損害
  • テーマ開発してるとき特定プラグインで表示がおかしくなるという issue が報告されたのでインストールしてみた時に遭遇
  • gem とか rake 絡みで問題が発生すると影響範囲が本体に及ぶことを知った
  • Redmine の設計的な問題だと思う
  • gem 未使用または静的に包含することを強制するとか、本体と隔絶した設計にしたほうがよいのではなかろうか

要するにエコシステムがうまく回っていない。インストールに一発で成功して動作するとガッツ ポーズを取ってしまうぐらい事故に見舞われたので、もうお腹いっぱいである。WordPress がいかによく出来ているかを実感する。

優れたプラグインもあるため、このあたりの問題に Redmine として対策されたなら改めて導入を検討したい。

一方、テーマは CSS と JavaScript だけで構成されており、それ自体で完結しているため問題には遭遇しにくい。少なくとも Redmine がクラッシュすることはないはず。そのため過去には A1、現在は自身で開発している minimalflat2 を採用している。

さきほど WordPress を引き合いに出したが、あちらはテーマが HTML の DOM 構造まで操作するので問題が起きやすい。逆にプラグインは基本的に WordPress 本体の提供する API のみを使用するようになっている。共通してどちらも PECL は使用せず、動作環境は配布されるイメージだけで完結している。

Redmine もこのようにすれば公式リポジトリからの自動インストールなどをサポートしやすくなるだろう。プラグイン開発でも本体 API だけ追従できれば互換の問題も起きにくくなるのになぁ、と思う。

プロジェクト分類と階層化

複数の案件を同時に管理する場合、その単位でプロジェクトを用意したくなる。

少ない案件を何年も回すなら単純にプロジェクトを追加してゆくだけでよい。数が増えてきたら見通しをよくするためルール化された階層化を推奨する。

現職は扱う案件が受託と自社に大別されるので、これをベースに階層化している。

.
├── 受託
│   ├── 企業 A
│   │   ├── 案件 A
│   │   ├── 案件 B
│   │   └── 案件 C
│   ├── 企業 B
│   │   ├── 案件 A
│   │   └── 案件 B
│   └── 企業 C
│       ├── 案件 A
│       └── 案件 B
└── 自社
    ├── 部署 A
    ├── 部署 B
    └── 社員個人
        ├── 社員 A
        └── 社員 B

顧客から請け負う案件は受託に分類。その下へ顧客となる企業名、案件名というように階層化してゆく。顧客があまりにも多いとか類似案件が大量にある場合は、それをあらわす系へまとめてもよい。例えばひとつのパッケージ製品があり、ほとんどの案件で作業が似通っているなら、

• 受託直下にパッケージ製品のプロジェクトを用意
• そのプロジェクトの子プロジェクト、またはロードマップで案件を管理

という感じにする。

社内向けの作業などは自社に分類。配下は事業や部署単位で階層化する。特別なプロジェクトとして社員個人を提供。この配下に社員単位で個別のプロジェクトを用意する。

ここはいわゆる砂場。クライアントや部署とは隔絶された安全圏だから社員の裁量で自由に利用可能。Redmine を導入するにあたり、いきなり実案件でチケットや Wiki を書いてもらうより個人プロジェクトで練習する機会を与えて苦手意識を克服させるのが狙い。

現職だと個人的なブックマークや Tips 集として利用されることが多い。チケットはあまり活用されていないが Wiki でメモを取る需要はそれなりにあるようで、管理者として活動を眺めているとけっこう積極的に更新されている。

Redmine 管理用プロジェクト

Redmine のシステム管理用プロジェクトがあると便利だ。前述の階層構造であらわすと自社の直下にRedmine 管理といった名前で用意する。

新規にプロジェクトやユーザーを追加したい場合、このプロジェクトのチケットで依頼してシステム管理者が対応する。確か Redmine 標準設定だとプロジェクト管理者のロール設定でプロジェクトやサブ プロジェクトの追加が有効になっているのだが、これは明示的に無効化する。

このようにすることでプロジェクトを追加する窓口はシステム管理者に一元化される。

Redmine を運用しているとシステム管理者の関与していないところで無尽蔵にプロジェクトが作成されて見通しが悪くなりやすい。階層構造にルールを設けてもたやすく破壊される可能性がある。こうした事態を防ぐため、システム管理者だけがプロジェクトを増減可能にしておく。

プロジェクトやユーザー追加をチケット化は手続きを可視化するための施策。依頼方法を別立てするより Redmine 内で管理するほうがわかりやすい。例えばプロジェクト作成依頼ではチケット作成フォームの入力内容は

という感じ。プロジェクト追加に必要な情報は Wiki にテンプレートを用意して、それを埋めてもらう。Textile のテーブル記法は慣れないと難しいから単純なプレーンテキストを書き換えるようにした。

「ZZZZ」案件を管理するプロジェクト作成を依頼します。

顧客名 : YYYY 
案件名 : ZZZZ
管理者 : A、B
開発者 : C、D、E 

顧客名、案件名は前述のプロジェクト階層に対応。はじめての顧客なら、その階層から作成する。企業内で案件を管理する番号などがあれば、それを追加してもよい。このような管理には企業文化が反映されるものだ。

プロジェクトの初期メンバーは管理者と開発者に列挙されたユーザーにしておく。以降、メンバーを増減する場合はプロジェクト管理者が実施。時間トラッキングなどプロジェクトに必要なモジュール設定なども同様。基本は分割統治である。

プロジェクトを作成したら、その URL をコメントしつつチケットのステータスを解決に変更。担当者を依頼者に設定して内容を確認してもうらう。問題なければ依頼者はステータスを終了にする。なにか設定に過不足があればフィードバックしてから、このやりとりを繰り返す。

プロジェクト管理者が変更できる設定なら、誤りがあってもそちらで対応してもらったほうがよい。そのためプロジェクト追加の依頼者をメンバー設定でプロジェクト管理者にしておくと作業がスムーズに進む。

プロジェクト追加

プロジェクト追加にあたり以下を考慮している。

• プロジェクト名
  • 階層によって異なる
  • 企業名であればフルネーム
  • 案件系ならば実際の製品名をなるべく正確に
  • コードネームを割り当てる文化があるなら、それを採用してもよい
• プロジェクト識別子
  • プロジェクト階層を意識した命名にする
  • 例えば CLIENT-COMPANY_NAME-PRODUCT_NAME
  • 階層の区切り文字はハイフン、各ユニット内の区切りはアンダースコアにしている
  • CSS の命名ルールである BEM みたいな感じ
  • Gitolite などで自前リポジトリをプロジェクトに関連付ける場合、その名前にも流用する
  • 企業名については公式サイトのドメイン名を利用してもよい
  • 英語に訳しにくいとか、長過ぎる場合はドメイン名を参考にすることが多い
• メンバー
  • プロジェクトは基本、メンバーにのみ公開する
  • 外部企業と Redmine 上でやりとりする場合は守秘義務も絡むので公開範囲はなるべく小さくする
  • 社員全員に公開するものでもプロジェクトを公開せずメンバー追加で対応する
  • 非メンバーや匿名ユーザーを追加しないように注意すること
• ロール
  • Redmine 標準のロールである管理者、開発者、報告者をそのまま利用
  • プロジェクトに関する設定は管理者に任せる
  • 実務者は開発者にする
  • グラフィック デザインや資料作成も実務なので開発者ロールになる
  • 案件の成果物を検証する、進捗などを閲覧するなど補助的なユーザーは報告者にする

プロジェクトで使用するモジュール (各種機能) などは管理者へ委ねる。基本は分割統治だがシステム管理者としては**プロジェクトが公開されていないか？**だけ注意すること。

これはプロジェクト設定の情報タブにある公開というチェックボックスで切り替えられるのだが、その権限はロール設定でも無効にできない。そのため定期的に Redmine 管理画面のプロジェクト一覧で公開がチェックされていないことを確認したほうがよい。

なお、Redmine 管理画面の設定からプロジェクトを選び、デフォルトで新しいプロジェクトは公開にするのチェックを外すことで、プロジェクト追加時の初期値を非公開にできる。

ロードマップ (バージョン)

ロードマップは期限を持つ工程に名前をつけて管理するための機能。画面によってロードマップやバージョンなど呼称がバラバラなので注意する。というか混乱するのでいい加減、どちらかへ統一してほしいものだ。

ロードマップを利用する場合、ソフトウェア開発なら Semantic Versioning に従って v1.0.0 のようにバージョン番号で命名するとわかりやすい。v1.0.0 未満の新規プロジェクトであれば

1. Alpha
2. Beta
3. RC (Release Candidate)
4. RTM (Release To Manufacturing), GM (Gold Master)

のようにしてもよい。ソフトウェア開発以外でも何らかの工程管理を実施しているならば、それらに名前を付けていると思われるから流用するとよいだろう。

ロードマップを設定してチケットを関連付けると、それらを集計してロードマップ全体の進捗率を表示してくれる。例えば Redmine v3.3.1 をみると 2016/7/27 時点の進捗率は 64% になる。

時間トラッキングや期限を設定すれば予想工数と実作業時間や残り日数も教えてくれる。これはプロジェクト リーダーやマネージャーが現状をざっくり把握するのに有用。そのため更新や運用フェーズのないプロジェクトでもロードマップは設定しておいたほうがよい。

チケット管理

チケット作成において粒度はなるべく小さくすることを推奨している。プロジェクトやロードマップに比べて個人差が出やすいので、 iki にガイドラインやサンプルを掲載しつつ、地道にアドバイスして慣れてもらう必要あり。

Redmine 標準のトラッカー、ステータス、優先順位は細か過ぎる。なので必要なもの以外は削除して簡素化するのも有効だ。チケット分類のためにトラッカーやステータスを増やしたがるユーザーもいる。例えばトラッカーに「設計」、「資料作成」、「顧客折衝」、ステータスに「検証」、「顧客待ち」など。

こうしたものはカテゴリで解決することを提案する。ある状態を定義できれば十分というケースが大半だろうし、それはプロジェクト固有の事情であったりするからカテゴリで十分なはず。トラッカーとステータスは全プロジェクトに影響するため、ひとたび設定すると廃止が難しい。そのためよほど汎用なものでない限り避けたほうがよい。汎用の判断基準としては業界で標準的な概念とか業態で必須の工程だろうか。

入門Redmineに呉服屋の受発注を Redmine で管理する例が掲載されているけど、こうした業界であればその用語でトラッカーやステータスを定義してもよさそうだ。

時間管理

Redmine のチケットはそのまま利用しても便利だが、時間管理を組み合わせると更によい。プロジェクト設定のモジュールで時間管理を有効することで利用を開始できる。実際に運用する場合、以下のようになる。

1. チケット作成時に予定工数を入力
2. チケットで管理している作業が進行する
3. チケット編集画面を開く
4. 時間を記録欄に作業時間と活動内容を入力
5. 覚書などがあれば注記欄に記述

作業時間を入力する都度、チケット全体の作業時間に累積されてゆく。この情報は実際の作業時間と見なせるため予想工数との乖離をみて見積もり精度の目安にするとか、管理職への日報の代りにするなどの用途に使える。

ロードマップ画面には全チケットの総計として予定工数と作業時間が表示される。この情報は進捗率とあわせてプロジェクトの状況を大まかに把握するため役立つ。進捗率は問題ないが、予定工数を作業時間が超え始めたならば、危険の兆候と判断してよいだろう。

時間管理の単位について。この設定は基本的に時間単位で入力するのだが小数点も設定可能。そのため私は以下の基準を設けている。

• 30 分 = 0.5 時間
• 半日 = 4 時間
• 1 日 = 8 時間

最小を 30 分として 1 日を標準労働時間である 8 時間で換算。半日はその 1/2、数日かかる作業なら 8 の倍数にする。予定工数を 1.5 日 = 12 時間とか細かく設定しだすとキリなく厳密さを求めたくなるため 1 日を超えるものは日単位でざっくり決定。逆に作業時間はベンチマークとして重要なので可能な限り細かく設定しておく。

記録の更新は作業でキリのよいタイミングにしている。進捗率と一緒に更新することが多い。なるべく注記も一緒に書いておくと後で振り返るのに便利だ。私は作業の考察などを結構マメに書いている。Twitter へつぶやく程度の気持ちでガンガン書くのがよい。

Redmine の検索は Wiki だけでなくチケットも対象になる。よってある機能や業務に関連づいたメモ書きというのは後に有用な資料となることが多い。私はこれに幾度となく助けられた。

リポジトリとの関連付け

職場の Redmine は Git リポジトリと関連付けている。設定についてはさくらのVPS を改めて使いはじめる 10 – Git、Gitolite、GitHub で書いたとおり。GitHub でプライベート リポジトリを運用するか迷ったが、

• 既に Redmine で業務タスクを管理していた
• Redmine と GitHub issue の使い分けで迷いそう
• GitHub なら issue もこちらで管理したほうがよい
• そうなると業務と開発のタスク管理が分散して運用しにくい
• 業務タスクも GitHub に移行する場合、Redmine の過去資産と分断されて管理しにくい

という理由により Gitolite を採用した。Redmine と共に Git (Gitolite) リポジトリ管理も私が担当。リポジトリの追加頻度は高くないためなんとか回せている。しかし hook 周りの設定とか Redmine との関連付けが面倒。なのでこの辺を Shell Script か小さな Web サービスで自動化したいと考えている。

Redmine と連携される際にひとつ、大きな問題が。Redmine のチケット番号はシステム全体で連番となる。そのためプロジェクト単位でリポジトリを作成しても、コミット時のコメントに書くチケット番号を 1 から開始できない。

そのため GitHub へリポジトリと issue を 移行したい場合、コミット ログを書き換えてチケット番号を整理するなどの面倒な作業が必要。やろうとは思わないが、このチケット番号の仕様は Redmine における Vendor Lock-In 問題のひとつと認識している。

削除について

ユーザー、プロジェクト、チケットの削除は原則禁止。削除を実行するとこれらを参照している部分に影響するため、削除を求められた場合は以下のように対応している。

• ユーザー
  • Redmine 管理画面のユーザーでロックを指定
  • これでログイン不能になる
  • Redmine の認証を必須としていれば、ユーザーが関わることはない
  • ユーザーが戻ってきた時はロックを解除するだけで済む
• プロジェクト
  • 間違えて作成したもの以外、削除しない
  • プロジェクト追加がシステム管理者のみに許可されているなら通常は遭遇しないケース
  • 既にプロジェクト管理が崩壊しているならありえる、そういう環境を引き継いだとか
  • どうしても削除したい場合はチケットと Wiki ページを別プロジェクトに移行してから実施する
  • 不可視にするだけなら当面使用しないプロジェクトを非表示にする — Redmine.JP で解説されているようにアーカイブ化すればよい
  • 可視状態で読み取り専用にするなら Redmine 2.1新機能紹介: プロジェクトの「終了」機能 | Redmine.JP Blog を利用するとよい
• チケット
  • 絶対に削除しない
  • Redmine のチケット番号はシステム全体で連番となるため、存在しない欠番が発生すると管理的にややこしい
  • 間違えて作成したものなら内容を編集して再利用する
  • または単純にステータスを却下や終了にするだけでもよい
  • 私は誤りも記録されるべきと考えている
  • 誤りよりもそれを直さないことが問題、誤りは記録することで初めて顧みる機会を得られる

まとめ

記事を書くにあたり職場の Wiki に掲載したルールを見なおしたのだが、判断基準も添えて書いているうちによくない部分が可視化されて棚卸しにつながった。特に認証設定は緩かったので本記事のとおり厳し目に変更している。これだけでも書いた価値があった。

次回は職場に Redmine を普及させるための施策と課題について書く予定。数日、間が開くかもしれない。