Redmine 運用について 3/3 – 普及の施策と課題

2016年7月29日 0 開発

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

最終回は Redmine に馴染みないユーザー、例えば工程管理やバグ表を Excel で運用していたとか、そういう管理職や社員に対して Redmine を普及させるための施策や課題などを書く。

これまでの内容と重複する部分もあるが、本記事ではルールよりも事例や留意したことに重きを置く。

シリーズまとめ
Redmine 運用について

現状分析

前職はソフトハウスであり、一部に Trac による TDD を経験していたプロジェクトもあったので Redmine 導入はスムーズに行われた。TDD に親しみのない社員も BTS として利用しはじめて、Excel ベースのバグ表を置き換えながら慣れていった。

一方、現職は私が移籍する前に Redmine を導入していたものの、数名が実験的に利用しているような状況で、業務は主に上長の手による Excel シートで管理されていた。

シートには部署に属する社員と担当業務がずらっと並んでいる。2 週間ごとにおこなわれる定例で聞いた話を紙にメモ、その後に自席に戻ってそれを Excel に反映させるのだという。

これを Redmine 管理へ置き換えることを提案することにした。まずは現状分析するために二ヶ月ほど定例に参加してみた。定例の規模は 7 人で 1 時間、参加した回数は 5 回ぐらい。その中で気になった点をまとめる

  • 同じ課題が何度も繰り返されている
    • あの問題どうなりました、確認中です、ではまた次回に、という感じ
    • 手元のメモで数をカウントしたら 3 回のものもある
  • 進捗報告は基本的に作業の開始と終了のみ
    • 〜に着手しました、終了しました
    • 中間報告は率ではなく問題の有無となる
    • 期限までに終了すれば経緯を問わない
    • 担当者が問題と感じたものだけが問題として扱われる
    • 良くいえば裁量主義、悪くいえば放置放任
  • 議事録がない
    • 定例の記録は各人のメモに委ねられている
    • 業務管理 Excel シートは一種の議事録ともいえる
  • 2 〜 3 人で細かな業務の議論が突発的にはじまる
    • それで大丈夫ですか?あれはどうなっています?という感じで開始
    • 細かくメモを取るタイプだと報告から問題に気づき、それを指摘することが多い
    • 議論の記録が保証されないためか、この場で結論せねば、という雰囲気
    • これが数回あると、定例が 2 時間に及ぶこともある
    • 議論に関係ない社員は終了を待ち続けるか、雑談をはじめる
    • 私は眠気が抑えきれず、船を漕いでいる

業務管理はもとより定例にも多くの問題がある。これをもとに Redmine で対策する方法を考える。

部署単位の業務管理

定例で私の番が回ってきたとき、現状分析で気になった点を発表した。そのうえで、これらの問題が既に導入されている Redmine で解決可能なことを説明。口頭のみでスライドなどは用意しなかったが、当時を思い出しながら問題と対策をまとめる。

  • 同じ課題が何度も繰り返されている
    • 課題を Redmine のチケットとして管理する
    • チケットには課題の内容、担当、期日、対応状況を設定できる
    • 個人のメモや記憶に頼らず、常に確認可能
    • チケットならば任意のタイミングで着手できる
    • 定例を待たずとも議論可能
  • 進捗報告は基本的に作業の開始と終了のみ
    • 途中経過も重要
    • 作業の見積もりと実際にかかった時間は計測されているべき
    • そうしないと効率化できない
    • 定例の合間となる 2 週間、質問するまで手が空いていることもわからない
    • チケットで期日、作業時間、進捗率を設定することでリアルタイムに現状報告される
    • 定例を待たずとも把握可能
    • 作業が発生したら定例の場でチケット化する
    • 理想はチケット一覧を眺めながら数値で現状確認すること
  • 議事録がない
    • 議事録ドリブンを提案
    • テキストで残して全員が読めることの重要性を説明
    • 定例の前に Redmine Wiki に議題を書き、読んできてもらう
    • 定例では Wiki の内容をテキスト エディタでプレビュー表示
    • 当時は Sublime Text + timonwong/OmniMarkupPreviewer
    • 現在は Atom + textile-preview を利用
    • 議題に対する発言や決定事項をエディタで編集
    • メモしてほしいことがあれば発言する、というルールを提示
    • 定例が終了したときには議事録が完成、Wiki に反映して共有できている
  • 2 〜 3 人で細かな業務の議論が突発的にはじまる
    • 議事録ドリブンにより大きな問題は議題として登録済み
    • 小〜中規模の問題はなるべく当事者間で議論、できればチケットで
    • テキストでやりとりしないと、理解の齟齬が起きやすいことを説明
    • 口頭では相手の発言を精査引用するのが難しい、博覧強記を求められる
    • すべてを把握するより必要な情報がある場所を管理するほうが簡単

こんな感じの話をした。私は既に自身の業務に関係する社員と Redmine でやりとりしていたので、そのチケットを見せたりもした。

結果、まずは部署内の業務管理で Redmine を活用してみようということになった。上長の Excel シート管理はその後もしばらくは続いていたようだが、ここ 1 年ぐらい見ていないので移行できたのだろう。

対策のうち議事録ドリブンは採用、業務のチケット化については少しずつ浸透している。オフィスを歩いているときに見える PC の画面で、チケット編集している様子をみることが増えた。

全社的な展開

現職の企業は社員数 20 名ほどの小さな会社である。そのため、全社的な展開といっても大企業の 1 部署程度なのだが、横展開の手法という意味では規模に関係なく汎用性がある話といえるかもしれない。

個人、部署レベルでは Redmine による業務単位を取り入れたので、これを全社へ展開することにした。管理職には前述の提案を繰り返すことで賛同を得られたのだが、具体的な運用がピンと来ないとのことで、勉強会を希望された。

勉強会を開催するにあたり、実運用しているプロジェクトをサンプルとした。私はソフトウェア開発を担当しているのだが、この業務は目的のはっきりしたチケットが多いため、サンプルにふさわしい。

ある機能の開発着手、進捗更新、解決報告して検証、終了という流れを見せた。またそれをソフトウェア開発とな異なる業務、たしか書類作成だったかに当てはめて、同じように進捗管理する手順を説明。

概ね納得していただけたようで、全社的に積極利用する運びとなった。社員に対する説明は Wiki
に掲載した運用ルールやチャット、必要ならば個別に対応する。既に Redmine が導入済みということもあり、基本操作については特に解説しない。

かわりに

を購入して会社の本棚へ公開した。

私はこれの第 2 版を持っているが、基本機能だけでなく呉服屋の管理事例など運用面の話も面白く、かなりオススメの書籍である。Redmine の更新ペースには追従できていないが、激変というほどでもないので入門には十分だと思う。

管理職の説明会には質問も多く挙げられた。それらの内、特筆すべきものをまとめる。

プロジェクトはどういう単位で作成すればよい?

この話は前回を参照のこと。

現在の〜という業務をチケット化するとしたら?

  • 実際にチケットを作成しながら説明
  • バージョンや親チケットなどは慣れないと分かりにくいので割愛
  • トラッカーで業務の大まなか分類を指定
    • ソフトウェア開発でなくても「実務 = 機能」、「問題への取り組み = バグ」、「顧客対応 = サポート」のように分類可能
  • 題名に業務内容を指定
    • 〜業務とするより、その業務で達成したいことや成果物で考えるとチケット化しやすい
    • 〜する、〜を作成する、など
  • 説明に業務の背景や補足情報を記述
  • ステータス新規進行中終了だけで管理する
    • 慣れたら解決フィードバックも利用して終了を判断するタイミングを設ける
  • 優先度は慣れるまで設定しなくてよい
  • 担当者は業務を依頼する社員を指定
    • チケット上で対話する場合は、その内容をコメントしたうえで担当者を相手に変更
    • 相手が返答したら相手が自分に担当を戻す
    • これで対話が成立
  • 開始日はチケットに着手した日を指定
    • 業務の見積もりに関わる、管理職として非常に重要な設定
    • デフォルトはチケット作成日
    • すぐに着手しないなら空欄にするとよい
  • 期日は業務の締め切りとなる日を指定
    • 業務の見積もりに関わる、管理職として非常に重要な設定
    • デフォルトは空欄
    • これを設定するなら開始日も厳密に指定すること
    • 開始日と期日を指定することで正確なガントチャートを表示できる
  • 予定工数は時間単位で指定
    • 業務の見積もりに関わる、管理職として非常に重要な設定
    • 1 日 = 8、半日 = 4、1 時間 = 1、30 分 = 0.5 ぐらいの単位で入力
    • ざっくりでよい
    • あわせて時間管理を有効にし、実作業の時間も記録すると効率化や見積もり精度の向上に役立つ
  • 進捗率
    • 業務の現状把握に関わる、管理職として非常に重要な設定
    • 0 からはじめて 10% 単位で更新
    • ステータスを解決終了にするときは 100% にする

業務の資料はなるべく Wiki に書くべきか?

  • なるべく Wiki がよい
  • Wiki は基本的な装飾とページ階層化、リンク機能があるので大抵の資料は書けるはず
  • チケットや Wiki のリンク略記も便利
  • 情報を Redmine に集約することで、検索の価値が高まる
  • 編集履歴も自動保存されるため、簡易なテキスト専用リポジトリとしても有用
  • 他社とのやりとりや印刷を考慮するなら Microsoft Office も可

Redmine に関するお知らせ

Redmine に関する情報を社員に告知したい時がある。例えば

  • Redmine 本体のメンテナンス
  • Tips
  • FAQ

など。これらを通知するため、以下の方法を採用している。

チャット

現職ではチャットワークを利用しており、Redmine という専用のグループを設置。メンバーは社員全員。例えば

  • Redmine の更新
  • サーバー更新に由来する再起動
  • 影響の大きな設定変更
  • 運用ルールの改訂

について通知している。突然利用できないとか動きが急に変わったといった問題に遭遇すると不安を感じるさせることになる。これを避けるため、事前通知は重要である。

また常時、質疑応答を受け付けている。その内容を FAQ にすれば社としての Redmine 知見を貯められる。ただ、あまり質問されることはなくて私が流した Tips に対する反応とか、そんな感じのやりとりが多い。

Wiki

Redmine の運用ルールや Tips、FAQ を貯める場所として利用。

チャットと同様に Redmine 専用プロジェクトを設置しており、Redmine に関することはその Wiki に記述。ここを読んでもらえれば Redmine はバッチリ!という状態を目指している。

Redmine の推進にあたり心がけていること

Redmine の推進にあたり心がけていることをまとめる。

古い管理手法を尊重する

業務やバグ管理に Excel シートを利用することについて、Redmine や GitHub issue を経験していると旧態依然に見えることだろう。

複数人の同時編集が難しい、履歴が取りにくい、セル管理の破綻しやすさなど、Web ベースの TDD/BTS に比べるとメリットなど皆無に感じられる。

それでも、紙でないだけマシである。また、紙であったとしても管理されているだけで価値がある。業務や開発において、最もよくないのは管理されていないことだ。

非効率、または無駄なルールが多くても、管理されているのであれば状況は可視化されている。つまりは改善の対象となりえる。管理されていない場合、業務で起きていることの分析・分類から始めなくてはいけない。

以上を踏まえ、Redmine や GitHub issue による管理を提案する場合は古い手法の管理者を尊重しよう。よくぞ管理してくれていました、と。

この記事でも挙げた Excel シートによる業務管理では社員単位の作業分担が記録されていた。ということはつまりチケットの題名と説明、担当者に流用できる。あなたの管理してきた情報は価値あるもので、それをより便利なツールに移行するだけという点を強調する。あまり過剰にすると褒め殺しっぽくなるので注意。

Redmine に限らず新しいツールや手法を提案するときは、いつもこのようにしている。対立を避けながら賛同を得るための方法としてなかなかよいと考えているのだけど、どうだろう?

とはいえ私は凡人なので、旧態をけなす誘惑に苛まれることがある。

Redmine 以外だと例えば Subversion から Git、jQuery から React へ移行したときには古巣がみすぼらしく感じられたものだ。それをけなすことで簡単に自身の成長を実感できる。いままで悩まされていたことを愚痴るのは、抗いがたい快楽をともなう。

この行為の問題は、新しい手法への敵対者を増やし賛同者を減らす効果にある。古巣に残らざるを得ない人にとって、そこをけなされることは耐え難い苦痛である。移行を検討できる人は対立を知ることで、それを見送るかもしれない。まだ議論は尽くされておらず新しもの好きが騒いでいるだけ、と。

この誘惑に負けてやらかした場合はなるべく深く悩んで、そのことを忘れないように心がけている。枕に顔を埋めてジタバタするわけだ。ああ、やらかしてしまった!という感じで。

活況を演出する

大昔に在籍していたプロジェクトで、知見を貯めるとかソフトウェアのリリース ページ作成などの目的で Wiki の採用が提案された。提案者は私ではないのだが、初めて触れる Wiki の機能性に感心してすぐさま賛同した。

そして運用がはじまった。しかし一部の賛同者が利用するだけで一向に広まらない。折にふれて Wiki ありますよ〜すばらしいですよ〜と宣伝してみるのだが、反応は冷ややかである。

そこで我々は考えた。

  • 使われないのは誰も使っていないからだ
  • この状態で書き込むのは新雪を踏むようなもので、気後れするもの仕方ない
  • 我々が書きまくろう
  • ジョークさえも許容しよう
  • 使ってよいという雰囲気を醸成するのが重要

というわけで、例えば海外チームのメンバーを紹介するのにヒッピー風とあれば、ヒッピーをリンクしてその説明を書いたりした。あと砂場というページを練習用に公開した。昔のことなので記憶が曖昧だが、Sandbox の和訳としてはじめから用意されていたページだったかもしれない。そこに冗談混じりのテキストのあることが重要だった。

しばらく、おそらく数ヶ月ぐらいかかった気がするけど次第に他のメンバーも書き込むようになった。ちょっとした技術的なテクニックとか考察なんかも充実してきて、ちゃんと分類したいということで PukiWiki へも移行した。他に内製の BTS もあったのだけど、そこに書かれないような情報は Wiki に蓄積されてゆき、当初の目標は達成された。

この経験から、あるシステムを普及させたい場合、活況であることの演出は非常に重要と考えるようになった。現職ではそのために以下の施策を実施している。

  • なんでもチケット化
    • ミーティングで議論が発生しそうな時は「それ、チケットで!」
    • なにか購入したいものがあるとき「稟議はチケットで!」
    • チケットが気軽に作成できて便利なものであることをアピール
    • 目的、担当者、期限のあるものなら大抵はチケット化できることをアピール
    • チケットに関わる機会を増やすことで自然と活況になる
  • チャットによる様々な通知
    • Redmine 自体の変化が活発であることを明示
    • 放置されていませんよ、ちゃんと生きていますよ、ということを演出
    • 空回りしている可能性も否めないが、続けることが大事
  • 様々なレポートの Wiki 記載
    • 現職ではセミナー参加を推奨している
    • 業務時間に出席することもあり、レポートを書くことが暗黙の義務となっている
    • レポートは Wiki に書かれ、その更新も通知している
    • これは筆者、読者の両方で関わっているが、かなり楽しい
    • アクセスログを見るに、読者数は多い
  • 議事録ドリブン
    • 私が司会者となるミーティングは基本的に議事録ドリブンで運用している
    • 議題と議事録は Wiki に書かれる
    • ミーティング中の発言が記録されて Wiki に反映される
    • 参加している感を強調
    • ジョークも記録しますよ、と言っているのだけどそれは遠慮されている
    • 司会と書記を兼ねるのは厳しいものがあり、タイピング速度の問題もあって、これをできる社員が 2 名しかいないのが難点

マメなサポート

これまでの内容と被る部分もあるのだけど、Redmine に関する質問や悩みは可能な限り迅速に対応している。基本はチャットだがテキストのやりとりが苦手な社員には口頭での相談も可。

ときには社員本人の席を訪れ、30 分ぐらいマンツーマンで Redmine に関する指導をすることもある。

普段、自分の利用している環境で直に説明すると高度な機能でも理解してもらいやすい。ついでにチケット化されていない業務を質問して、それをどのように Redmine 管理へ持ってゆくかを提案したりもする。

私のメイン業務はソフトウェア開発なので、こうしたサポートのコストは問題に感じられるかもしれない。しかし私は社全体で強くなることを目標としており、業務の効率化も立派なハックと考えている。そのために Redmine を提案したのだし、こうしたコストを捻出するためにメイン業務の見積もりはかなりの余裕を持たせている。

こうした考えに至ったのは、かつて在籍していたプロジェクトのリーダーの影響である。Wiki や議事録ドリブンもその一部で、その方はこうしたファシリテーションを非常に重視していた。実際、それを受ける側として効果を実感したこともあり、私もそれを踏襲している。

おわりに

つきあいの長い Redmine について以前からまとまった文章を書いてみたかったのだが、なかなかその気にはならなかった。書きはじめたら長くなるのは必然で、そのため腰が引けていた。そんな折、Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索とはてブの反応はよい刺激になった。

Excel 中心で管理したい上司をどう説得するか。説得を諦めて現実解として Excel ジェネレーターを実装するのか。

幸い私は理解ある環境に恵まれて Redmine 導入に成功したが、そうではない人や環境に対して知見の一部でも役立てば、という気持ちで記事にしてみた。

もし感想や Redmine 導入についての相談などがあれば、本記事のコメント欄や Twitter などでどうぞ。

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 を普及させるための施策と課題について書く予定。数日、間が開くかもしれない。

Redmine 運用について 1/3 – はじめに

2016年7月28日 0 開発

以下の記事に触発され、私の実施している Redmine 運用についてまとめたくなった。

しかし書いているうちにものすごく長くなってしまったので、全 3 回へ分割することした。

シリーズまとめ
Redmine 運用について

初回は自身と Redmine の関わりについて。どのような立ち位置から書かれているのかを前置きすることで、読者は自身との距離感を意識しながら記事を読めるのではなかろうか。

例えば Redmine 導入を提案するのであれば、先行事例として参考に。提案されている側であれば、相手がどのような背景や思想をもっているかを理解するのに役立つ、というのが狙い。

私の Redmine 運用経験

私は前職も含めると足掛け 6 年ほど Redmine を運用してきた。バージョン更新などの環境構築や運用ルール策定なども含む、システム管理者として活動している。

導入のきっかけについて。

親戚に Ruby on Rails でアプリ開発する企業を経営している方がいて、プロジェクト管理に Redmine を採用している話を聞く機会を得た。ちょうど業務で複数プロジェクトを TDD で回したいと考えていたのだが、当時採用していた Trac では面倒そうだと感じていたところである。

語られた Redmine の機能では、特に複数プロジェクト管理に強く惹かれた。その企業では小さな実験的プロジェクトを数多く管理する必要がある。そのため気軽にプロジェクトを追加できる Redmine が重宝しているのだという。また、ある機能を共通モジュールに切り出すときも、そのプロジェクトに元となる機能のチケットを移動させるとか、モジュールのチケットを利用側のチケットに関連付けられるといった管理も便利とのこと。

この事例に強く興味を惹かれ、けれどもいきなり業務で採用するのは怖いので、まずは個人で試してみることにした。

さくらのVPS を使いはじめるはそのときの話。ちょうど Redmine v1.0 がリリースされるかも?というタイミングだったと思う。はじめは共用レンタルサーバーで動かそうとしたけど CGI モードは激重なので、Passenger のために VPS へ移行した。これは現在このブログを稼働させているサーバーでもある。

実際に個人開発で試してみた結果、気軽に複数プロジェクトを作成できること、ガントチャートやカレンダーなどのよく使う機能が標準搭載されている点が気に入った。複数プロジェクト管理を前提としているため、チケットや Wiki の参照を横断的に指定できるところもよい。

というわけで導入を提案。

前職で私が在籍していたのはソフトハウスの開発部署だったこと、既に Trac である程度 TDD に馴染んでいたことから、提案はすんなり通った。私がシステム管理者になることを明言し、本業に影響しなければいいよ、と許可を得た。

浸透もわりとスムーズだったと記憶している。基本ルール策定やインフラ面を管理していたぐらいで、割りとうまく分割統治できていた。

現職は移籍前から Redmine が運用されていたものの、あるレンタルサーバーの付属サービスを利用していた。残念ながら提供されるバージョンも数世代前であり更新予定もなさそうなので DB や添付ファイルを吸いだして VPS に立てなおした環境へ引き継いだ。

Redmine の運用期間は前職 4 年、現職 2 年ぐらい。前職はソフトウェア開発中心だったので Redmine によるチケット管理と相性がよく、基本的な運用の経験値を貯めるのに有用だった。

現職はソフトハウスではないのだが製造業の一種であるため、同様に Redmine 向きな業務が多いと認識している。現に一部の社員は積極的にチケットを利用しているのだが、熟年社員や IT リテラシーの高くない社員への浸透はイマイチである。

幸い管理職が積極的であるため、2 年を経て全社的にチケット管理で回そうという体制にはなりつつある。しかし社員個人が能動的に利用する状態になっていないと管理職の負担が増すだけなので、ここを改善するのが目下の課題であり、やりがいを感じる部分でもある。

業務におけるシステム管理の割合

Redmine のシステム管理を担当するとして、業務でどれぐらいの労力を掛けているのか?は気になるところだろう。私の場合は前職、現職ともに体感で 5 〜 10% ぐらいである。

Redmine 導入と更新、運用ルール改定にコストが掛かるものの、それ以外は分割統治がわりと上手く回っていて、メイン業務であるソフトウェア開発への影響は気にならないレベル。

Redmin 更新は基本的に Major、Minor レベルのバージョン単位で実施している。セキュリティに関する致命的な問題が解決されている場合は Revision レベルでも更新。おおむね数ヶ月に一度ぐらいで済んでおり、時間にして長くても 30 分ぐらいで済むから負担でもない。この辺、運用ルールあたりで詳しく書く予定。

v0.x 時代の Redmine は非常に不安定で、Ruby や Rails 絡みのトラブルに悩まされたものだけど、v1.0 あたりからは問題に遭遇することはほとんどなかった。また Ruby 環境を rbenv/rbenv で管理するようになったのも大きい。

Redmine の環境トラブルでよくあるのが、Gem にまつわるもの。あるプラグインを試そうとしたらグローバルな gem が必要になってインストールしたけど、依存関係の問題とかバージョンが古すぎて環境が壊れた、みたいな問題は何度か経験した。

rbenv の場合、Ruby 環境を複数同時に構築して切り替える方式となる。そのためある環境が壊れたら、安定していたものに戻すといった運用が可能。これで随分と管理が楽になった。また、Redmine 3.3.0 リリース – Enjoy*Study のように最新の Redmine 環境を Vagrant box として提供してくれる方がいるおかげで、新バージョンを検証しやすいのも助かる。

更に現職では私の他に 2 名のシステム管理者を任命、運用ルール Wiki に明記された管理業務であれば代行可能な体制にした。これも負担を下げるのに役立っている。

テーマ開発

私は akabekobeko/redmine-theme-minimalflat2 という Redmine テーマを開発している。元々、個人利用のために minimalflat を作り始めたのだが、minimalflat2 は職場で採用することを前提に開発している。

普段の業務で触れるものだと開発意欲が持続できてよい感じ。

たまに第三者から issue や Pull Request が来ることがあるのも嬉しい。励みになる。問い合わせは日本語でも受け付けているので、この記事を読まれている方でテーマへの要望があれば遠慮せずにどうぞ。

まとめ

はじめは単一記事に運用ルールも含めた内容を書くつもりだったが、今回の前書きだけでもかなりの量になり、もくじを付けても読みにくいので分割することにした。

6 年も関わっているシステムだけあり、いざ書き始めると触れたい内容が次々と湧いてくる。今回の内容も独立した記事としたこどで、当初の倍ぐらいになった。

個人的な体験談が多くて第三者からするとあまり興味のない回かもしれない。こうした回顧録は私的に楽しむものであり、当時の状況を懐かしみながら書けてよかった。私に良し、という感じ。

次回は Redmine の運用ルールと諸設定についてまとめる予定。