打ち捨てられていたRedmineが復活するまでの軌跡 #Redmine - Qiita

この記事はLIGアドベントカレンダー2017のための投稿です。

こんにちは。僕は今LIGでフロントエンドエンジニアとして働いていますが、同時に社内随一のRedmine警察であることも自負しています。

LIGではプロジェクト管理ツールとしてRedmineを導入していますが、僕の入社当初はほとんど打ち捨てられたも同然の状態で放置されかけていました。そのような状況をどうやって改善し、社内にRedmineの運用を浸透させていったかについて、経緯や施策を説明します。

当時の状況

入社当時、全社で使う決まったプロジェクト管理ツールはありませんでした。ほとんどの業務上のコミュニケーションがChatWorkで行われており、それ以外では僅かにBitbucketのWikiやIssue機能が使われている状況でした。

また、かつてはプロジェクト管理にRedmineを使っていた過去もあったようなのですが、保守のために情報を探しに行く以上の使い方はされておらず、新規の案件については担当者が思い思いの方法（エクセル、Trello、ChatWork、Slackなど）でプロジェクト管理をしている状況でした。

チャットに情報が集約されることの問題点

この状況の一番の問題は、重要なコミュニケーションが全てチャットのタイムライン内に散逸してしまうことです。これにはいくつものデメリットがあります。

異なるトピックがランダムに折り混ざり、問題の切り分けがしにくい

チャット上では不意に新しい話題が始まったりその合間に別の話題が挟まったりと、ランダムに話題が錯綜します。これを1つ1つのトピックの履歴として追い掛けるのには余計な頭を使います。

チャットへの途中参加者は、一体どこまで遡って読めば経緯が全部把握できるのかが全く分かりません。

また、一度にわーっと複数の課題が発生したときに、チャット上で都度課題を切り替えながらコミュニケーションをするのにも無駄な負担が増えてしまいます。

古いトピックの状況や結論を忘れる

チャット上で次から次へと湧いてくる新しいトピックに対応していると、以前に議論していた別トピックの経緯や結論をすぐに忘れてしまいます。その経緯を思い出そうとしても、話題の織り交ざったタイムラインを読み解かなければなりません。

メンバー外への情報共有がはかどらない

同じチャット内にいるメンバー以外に情報共有をしようとしたときに、そのメンバーをわざわざチャットに招待するか、個別にコピペして情報を送るかをしないと共有ができません。余計な手間が必要だとあえてメンバー外に情報共有するという行動自体が面倒になってしまいます。有益なナレッジはできるだけチーム間で共有できることが望ましいのに、チャットルームの壁がそのままナレッジ共有の壁になってしまうのです。

Redmineの再導入施策

TrelloのUIは単純なToDo管理には素敵ですが、コミュニケーションの履歴として使うにはシンプルすぎてしまいます。BitbucketのIssue機能はJIRAの劣化版で、BTS以上の使い方をするには機能が不足しています。ChatWork内のToDo管理やSlackのスレッド機能、チャットサービスの過去ログ検索は根本的な解決にならないばかりか、ますますチャットへの依存を強めてしまいます。

このような状況を改善するためには社内で横断的に使うITS（Issue Tracking System）が不可欠に思い、入社半年後にRedmine再導入を提案しました。一部のエンジニアやマネージャーも同様の問題意識を持っていたため、これを期にITS導入の検討が始まりました。候補としてはJIRA、Backlog、Wrikeなどもありましましたが、結局運用コストの面でRedmineが選ばれることになりました。

再導入の目的は過度なチャットへの依存を低減し、チケットやWikiを通じて有益な情報資産を社内へ残せるような仕組みを作ることです。そのためにはシステム側の整備だけではなく、ユーザー側にもITSを使うメリットや使い方を広めていかなければなりません。

このため、インフラ設計やRedmine自体のカスタマイズのほか、ユーザーへの導入サポートの面からも施策を打ちました。

バージョンアップや機能の追加、移行がしやすい環境を構築

インフラにはクラウドサーバとDockerを採用し、データ以外はできるだけイミュータブルな構成となるようにしました。それまでも自宅サーバの運用をDockerで行っていたため、その知見が社内Redmineの運用にも活かされました。Redmineのベースのコンテナにはsameersbn/reddmineを使っています。

参考：Vagrant・CoreOS・Dockerでインフラ素人が自宅サーバを立てた話 - Qiita

Dockerの採用はRedmineの運用にとって非常に良い選択でした。

Redmine本体やミドルウェアのアップデートが簡単に行える上、全く同じ環境がローカルでも再現できるので開発も楽です。

通常、Redmineのバージョンアップはプラグインの互換性が壊れたりするので面倒な印象があります。しかし、ローカルでの動作検証がしやすいおかげで割と積極的にプラグインの追加や本体のアップデートを試すことができ、安心して本番に変更を適用できます。

LIGで必要とされている機能を積極的にRedmineへ追加

前述のDocker環境が安定しているので、Redmineへはかなり積極的にプラグインを突っ込んでカスタマイズしています。以下は一例で、全部で30個くらいのプラグインが入っています。

チャットツールとの統合

Redmine単体ではメールの通知しかできませんが、今時それだけだと辛いものがあります。これでは、

チケットの更新に気付けないので結局重要なやりとりはチャットでやってしまい、わざわざチャット上のやりとりをチケットへ転記するのは面倒だからやらない→結果Redmineが打ち捨てられる

というストーリーが容易に想像できます。これを阻止するためにChatWorkとSlackのルームへRedmineの更新を飛ばせるプラグインを導入しました。

※ChatWorkプラグインはSlackプラグインを元に自作。

実際やってみると、チャットへチケットの通知が飛んでくることで、Redmineに不足しているリアルタイム感がいい感じに補えるようになります。通知はチャットで読み、コンテクストはRedmine側でチケットとして把握する、という理想的な棲み分けが可能になりました。

ガントチャート機能の強化

Redmine標準のガントチャートは、普段エクセルでガントを作ってる人からすると「ガント自体を直接操作してスケジュールを組めない」というのが致命的に使い難いようです。

これを改善するために、EasyRedmin社から配布されている「Easy Gantt」プラグイン（無料版あり）を導入しました。

Redmine Gantt Plugin - Easy Redmine

これを使うと、見やすいUIで直接ガントを操作してスケジュールが組めます。この機能は非常に好評でこれなしでは導入は成功しなかったと思います。また、魔改造によってチャートへ祝日を表示できるようにもなりました。

参考：Redmineの無料版Easy Ganttへ自由に祝日を表示する方法 - Qiita

追加テーマとTheme Changer Pluginの導入

RedmineのUIはBacklog、Trello、Wrikeなどの最近に製品に比べてすこぶる社内での評判が悪いです。いかにRedmine警察といえどもこれには同意します。

Theme Change Pluginを入れると、通常はシステム全体でしか変更できないテーマをユーザーが個人の好みで変更できるようになります。

できるだけ今風のテーマをたくさんインストールし、不満があるユーザーには個別に好きなものを選んでもらう、という運用をしています。

大量のメンバーやプロジェクトをさばけるselect2

LIGくらいの規模になると、Redmine上で扱うユーザー数やプロジェクト数はそれなりのボリュームになります。自分が参加しているプロジェクトを見つけるのも、通常のセレクトボックスでは使いものになりません。

A common librariesというプラグインにはセレクトボックスを拡張できるjQueryライブラリselect2が含まれています。これとView Customizeを使うと、jQueryでselect2を任意のselect要素に対して適用できるため、プロジェクトの選択やユーザーの選択でリッチなインクリメンタルサーチが使えます。

常に大量のプロジェクトが動いている環境ではほとんど必須とも言える機能です。

(図)導入するとこのUIでプロジェクトや担当者をインクリメンタルサーチにできる。

導入の理由を説明し、使い方をレクチャーする

導入に際し、エンジニア・デザイナー・ディレクターの職種別のミーティングに参加し、導入のレクチャーを行いました。

いきなり具体的なRedmineの話をするのではなく、なぜチャットログではなく構造化されたドキュメント（=チケット）を残した方が良いのかを説明してから具体的な話に入っています。

レクチャーの後半では具体的な機能の話まで説明しました。

レクチャーはおおむね好評で、ITSに不慣れな人も多いなか比較的スムーズに導入が進むことになりました。

※実際のレクチャー資料と構成は異なりますが、「なぜ」の部分はこちらのスライドとほとんど同じ内容です。

参考：Redmine勉強会 Vol.1 なぜ組織にはドキュメンテーションが必要なのか

プロジェクト作成や起票など、よく行うタスクについてマニュアルを整備

導入初期はプロジェクトの作成やチケットの作成方法の方法をよく質問されため、一般的なことがらについてはRedmine内にマニュアルを用意してすぐに参照できるようにしました。

Redmine警察としてみんなの運用の相談にのる

「この案件のタスクはどんな粒度で起票すれば良いか」「バージョンと子チケットの棲み分けはどうするべきか」といった微妙な問題があれば、立ち話で相談に乗るようにしています。また、ITSの運用に慣れている同僚をRedmineマイスターに認定し、Redmine警察と共同でチケット運用の普及に努めています。

パフォーマンスの監視と改善

GoogleAnalyticsによる速度の監視をしながら、Redmine高速化のプラクティスを検討したり、動作を重くしていたプラグインを特定して取り除くなどの改善を実地しています。現在総チケット数が1万の大台を越えていますが、まだまだいけそうな状況です。

参考：Redmineチューニングの実際と限界 - Redmine performance tuning

Redmineの再定着

このような様々な施策の実施と継続により、Redmineは再び中心的なプロジェクト管理ツールとして返り咲きました。

既に再導入から1年以上が経過し、多くの情報がチケットに蓄積されています。この調子でもっともっと組織全体で運用の習熟度を上げていきたいです！

それでは、明日も引き続きLIGアドベントカレンダー2017をお楽しみください！