Redmine 運用について 3/3 - 普及の施策と課題
Redmine 運用について書いてみるシリーズ 3/3。最終回は Redmine に馴染みないユーザー、例えば工程管理やバグ表を Excel で運用していたとか、そういう管理職や社員に対して 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 などでどうぞ。