Redmine 運用について 2/3 – 運用ルールと諸設定

2016年7月28日 0 開発

Redmine 運用について書いてみるシリーズ 2/3。

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

シリーズまとめ
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 コンテンツのアクセスはログイン必須とする。
自動ログイン 無効 手動ログインを必須化。いまどきの Web ブラウザならセッション維持機能が標準搭載されているだろうから、実用上の問題もないと判断。
ユーザーによるアカウント登録 無効 登録はシステム管理者が担当する。「手動で〜」にしてもよいが結局は内容を精査して許可することになるため、設定もシステム管理者に一任したほうがよい。
ユーザーによるアカウント削除を許可 無効 勝手に削除されては困るので無効。そもそもユーザー無効化は削除よりロックのほうが好ましい。
パスワードの最低必要文字数 4 旧 Redmine からのアカウント継承により標準のままとなっているが、近いうちに 32 文字へ変更する予定。複雑度を設定できないのが残念。職場では KeePassX によるアカウント管理を推進しているため、このツールでランダム生成された複雑度の高いパスワード設定を義務付けたい。
パスワードの有効期限 無効 期限による定期変更を強制するよりも、パスワードを長く複雑にするほうがよい。パスワードの定期的変更に関する徳丸の意見まとめ – 徳丸浩のtumblrの見解に賛同。
パスワードの再発行 有効 パスワードの管理はユーザー個人に委ねているため、紛失からの復旧手段も提供する必要がある。そのため有効にしておく。
追加メールアドレス数の上限 5 標準のまま。こんなに要るだろうか。自社でドメインを取っているなら、それに紐づくひとつで十分かもしれない。
OpenIDによるログインと登録 無効 システム管理者のみ登録、という運用なのでこの機能を提供する必要はない。

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 を引き合いに出したが、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% になる。

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

チケット管理

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

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 の認証を必須としていれば、ユーザーが関わることはない
    • ユーザーが戻ってきた時はロックを解除するだけで済む
  • プロジェクト
  • チケット
    • 絶対に削除しない
    • Redmine のチケット番号はシステム全体で連番となるため、存在しない欠番が発生すると管理的にややこしい
    • 間違えて作成したものなら内容を編集して再利用する
    • または単純にステータスを却下終了にするだけでもよい
    • 私は誤りも記録されるべきと考えている
    • 誤りよりもそれを直さないことが問題であり、記録しないと顧みる機会も失われる

まとめ

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

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


REPLY

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です