第9回Redmine.tokyoに行ってきた

参加を決めたのはほぼ衝動で、以前からこういう勉強会に参加してみたかったというのと懇親会を経験してみたかったというのと内容がゆるめというかゆったりした雰囲気を感じさせたので参加しやすそうだったという点が大きかった。また、個人的にはRedmineはもうあがりに近いソフトウェアであるという印象があり、もう大きな進歩はないという見方をしていたのだが、実際にどうなのかを見極めたいという思いもあった。

今回の勉強会の参加者は経験者だけでなく初心者も多いという印象を受けた。事前アンケートの結果がそれを如実に示しており、プラグイン導入数が1～3か、10個以上という両極端に分かれる格好となっていた。使ってみればわかるがRedmine単体では機能がシンプルすぎて機能を追加したくなる。コレにドハマリすると大量のプラグインをインストールすることになり、いろんな機能を持ったRedmineが完成するが機能が豊富すぎて使いこなすのが少々難しくなる。一方でプラグイン数1～3というのは用途を絞って最低限必要なプラグインをインストールしているという見方もできる。まだ様子見なのかもしれない。私の場合、現在は9つで過去にインストールしてみたものの動かなかったり思っていたものと違ったり、チームの仕事の仕方とは合わないなどの理由でアンインストールしているものもある。

ある種メインであるオープンディスカッションも興味深かった。同じRedmineを使い続けている人の間でも、インストールの難易度、チケットの管理の仕方も結構割れたのが印象的だった。私の場合Redmineを使い始めたのが2008年で、その時はまだバージョンが0.8.xの頃だった。セットアップに関しては基本的に今とあまり変わらないのだが、rubyのバージョンやその他の関連するパッケージのバージョンが高くても低くてもダメだったりするので、今ならbundlerでそう苦労せずできたが、当時は自分でバージョンを管理しなければならなかったので煩雑だった思い出がある。今も煩雑であるのは確かだが、インストール手順やトラブルシューティングのドキュメントが整備されたり、先達のブログエントリーを参考にしたりと情報が充実しているので楽になっている。

チケットの管理についてはRedmine自身が運用について強固なルールを持っているわけではないため、ユーザーによってルールが異なるが故に運用方法に差が出てくる。これは各々の業務との兼ね合いがあっての結果だろうから、ユーザーごとに使い方が異なっていて当然とも言える。例えば、Redmineで工数管理をしたいと思うユーザーは多く、プラグインを用いてチケットごとに発生した工数を集計することをやっている人がいる。工数管理がRedmineでクローズする(もしくは他ツールとの連携がしやすいI/Fでエクスポートする)のならばそれで良いが、そうでないケースもある。弊社の場合は自社開発の工数管理ツールが有り、その使用もかなり面倒。Redmineとの連携はやろうと思えば出来そうだがコストに見合った結果は得られそうになくRedmine側で諦めたという経緯がある。

私としてはプロジェクトにまつわるあらゆる記録は1箇所に固めるほうが使いやすいと考えている。チケット、仕様書、ソースコード、バージョン/ビルド、工数記録といったものは近距離に配置する、もしくは自動的に連携する、そういったことが必要だ。手動で別のシステム(例えばIBM Lotus Notesとかね！)に転記するのは可能な限り避けたい。手動は手間だしぱっと分かる場所にないということは探すコストが発生し続けるということだからだ。

オープンディスカッションの中でテーブルごとにディスカッションを行うことになった。私たちは自己紹介の傍ら、Redmineの経験度やRedmineでどういうことをしたいのかを語り合った。私と同席した人たちは建築関連の方でスケジュール管理をRedmineに移行したい、とか医療関係でインシデント情報をRedmineで管理したい、といったもので業種の異なる人の話はとても刺激になった。比較対象としていたのはServiceNowとのことで私は存在を知らなかったのだが、調べてみるとタスク管理というよりITガバナンス、リスク、コンプライアンス、財務、リリース、インシデントなどITにかかわるあらゆる情報を統合管理するサービスということで、なるほど私との出会いはあまり期待出来そうにない。私よりもっと上の立場の人が気にするもののようだ。

ある人は会社でISMSを導入しており、システムをNotesで構築しているという。それをRedmineに移管できないか、ということを考えているようだった。個人的にこういうのは非常に難しいもので、Redmineに移管してなおシステムの妥当性を検証できる仕組みも同時に必要になるため、会社できっちり整備しているシステムの置き換えはあまり進めようと思わない。加えて会社内の政治にも関係してくるのでかかるコストは膨大になるだろう。ISMSそのものは現状維持にし、そこに影響しないIssueをRedmineで管理してはどうかという意見を提示した。

これに限らず、現行の仕組みをRedmineに置き換えたい、またはRedmineに統合させたいという気持ちを持つ人は多い。しかし、いくらプラグインで様々な拡張ができるRedmineをしても限界はある。

例えばテストを考えてみよう。テスト中に発生した不具合と進捗の管理はRedmineの得意分野といえる(元がBTSなのだから当たり前)。テスト仕様書やテスト手順を管理するのはRedmineの本領ではないがWikiを活用すれば可能である。しかし、テスト計画の管理、テストの進捗の管理といったものにRedmineを活用するのはあまりお勧めできない。テスト実行をプロジェクト化して進捗管理というのも出来なくはないが、では消化したテスト項目をどう示すかといった点でチケット管理で示すのには無理がある。テスト管理をするならばTestLinkというテストに特化したツールが有り、障害票管理でRedmineとの連携もできるようになっている。UIが使いづらかったり、きっちりとしたテスト計画を整備しないとテスト実行までこぎつけられない煩雑さなどがあるが、それを込みにしても素晴らしいツールである。

更に言うと、Redmineのブレイク後、チケット管理システムそのものも多様化し、クラウドサービスにすることで管理コストの低減が図れたり、UIをカンバンやバックログに特化することでシンプルで目的に沿ったUIを提供したりと様々なサービスが出てきている。 なので、個人的には今は何でもかんでもRedmineでなければならないという時代ではなく、プロジェクトの形態、サーバー管理コスト、自社の開発情報をクラウドに置くことの是非などを考慮してツールやサービスを選択する時代になったと思っている。

ただ、汎用性、拡張性の高さは相変わらずRedmineがトップクラスだろう。今後も使われ続けることに変わりはない。Redmineは今後も改善や既存プラグイン機能の標準機能化という形で進化していくことだろうし、そういう意味では上がりというわけでもなさそうだった。久しぶりにRedmineのバージョンを上げて触ってみたくなった。

あと、懇親会楽しかったのでまた行きたいと思った。