チケット管理システムの頂上決戦！？ - Shibuya.trac第12回勉強会に参加してきました

はじめに前置き。。。頂上は決していません。はい。

本日（<-昨日か）、6月30日 Shibuya.trac 第12回勉強会 【通常枠】(東京都)に参加してきました。

概要

チケット管理システム大決戦第二回という名前のとおり、今年のDevsumiTokyoで行われたチケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのかの続編という位置づけ。前回は45分という短い時間だったのですが、今回は2時間半の大増枠で開催されました。さらに、前回までのTrac、Redmin、JIRAに加えヌーラボさんが提供するチケット・プロジェクト管理ASPサービスのBacklogを加えた4大チケット管理システムの使い手のパネラーさんたちによるディスカッションが繰り広げられました。

◆モデレーター
[twitter:@ryuzee]氏

◆パネリスト
JIRA [twitter:@ohnuki]氏
JIRA [twitter:@yusukey]氏
Redmine [twitter:@daipresents]氏
Redmine [twitter:@takanafu]氏
Trac [twitter:@kanu_]氏
Trac [twitter:@haradakiro]氏
Backlog [twitter:@ikikko]氏
Backlog [twitter:@ikeike443]氏

チケット管理システムを使っていたりするものの、開発プロセスの中にうまく組み込めていないと感じる今日この頃なので、今回、現場で活用されているパネラーさんたちのお話とても参考になりました。（もちろん現場に活かせなければ仕方ないんだけどね♪）

ということで、相変わらず理解が浅いのですが、熱が冷めないうちに、取り急ぎ備忘録的にまとめます。（注：理解に誤りがあるかもしれませんので、もしも見られた方は他の方のブログもご参照ください）

第一部 自分たちが使っているチケット管理システムの良い所/悪い所

というテーマで各パネラーさんたちが自分たちの使っているシステムの良い所/悪い所を議論しました。今回面白かったのは、各パネラーさんたちが決まった順番で単に良い所/悪い所をしゃべっていくだけではなく（基本的に順番はあるのですが）、あるパネラーの考えるシステムの良い所に対して、モデレーターの[twitter:@ryuzee]さんが（流石）他のパネラーに対して反論はないかアジテートするという展開が随所にあり、議論が白熱していました。（良く知りませんが、ヒップホッパーさんたちの世界でいう、ラップの掛け合い・ディスりあいみたいな感じ？ｗ）また、前置きが長くなりましたが、それぞれの発表から気になった点をまとめると、以下のような論点と意見があったと思います。

導入の手軽さ
  • TracはTrac Lightning（Windows環境）を使えばさくっと環境を作れる。Linux環境でTrac Kanonがいいよ。
  • Redmineの場合もWindows環境ではRedmineLEを使って簡単に作れる*1。
  • JIRAの場合は・・・、導入には一定のコストがかかる。しっかりと導入しようとするとインストールに丸一日くらいかかっちゃうかも。（この部分の説明で聴き逃したのですが、それを簡単にしてくれるようなツールもある、とおっしゃっていたような・・・）
  • Backlogの場合、ASPなのでインストール不要！アカウントを作るだけのお手軽導入！(ただし、[title:@ryuzee]氏から、「稟議を通す時間が〜」という鋭いツッコミが入りましたww）
プラグイン
  • あまり良くわかっていない人間からすると、trac、Redmine、JIRAともに豊富なプラグインがある印象。
  • 話題に上らなかった気がするのですが、BacklogはASPなのでプラグイン自体ない？のでしょうか・・・。ここも理解不足だったら申し訳ない。
操作感・UI・カスタマイズ
  • tracは「漢らしいとさえ言われる操作感」（会場爆笑）と、素のままだとかなり機能が貧弱との[twitter:@kanu_]さんの残念アピール。ですが、同じtrac使いの[twitter:@haradakiro]さんは素のまま使っていることのメリットを説いていましたのでここらへんは人によりけりなのかも。
  • Redmine。聞き逃しました・・・orz。*2
  • さすがは有償製品のJIRAの操作感・UIは優れもの。ユーザーのダッシュボードのiGoogleライクなカスタマイズや、ビジュアルに設定可能なワークフローとかは秀逸。ただし、複雑なワークフローが定義できるのは良いけど、あんまり難しいワークフロー自体がどうなのか？というような[twitter: @haradakiro]さんの意見もごもっともだなー、と感じました。
  • Backlogはｶﾜ(・∀・)ｲｲ!!バーンダウンチャートもどことなくポップだし、絵文字を使えたり、ユーザーの写真を設定できたり。非エンジニアの人たち（デザイナーさんやディレクターさん達）も含めたプロジェクトメンバーのコラボレーションツールという設計思想が良く現れているようです。
複数プロジェクトの管理
  • tracは複数プロジェクトを作れるけど、プロジェクト間の関連付けは行わない。
  • Redmineは複数プロジェクトの管理が可能。*3
  • JIRAとBacklogは話に出たかもしれませんが・・・よくキャッチアップできず。でも、多分どっちも複数プロジェクトはOKなはず。
レポーティング機能
  • tracはSQLを使って様々なチケットの検索、集約が出来る。でもSQLが複雑になりがちで、そうなるとメンテナンスも大変なので注意が必要なようです。
  • Redmineは、、、はい。また聴き逃していました。*4
  • JIRAはレポーティングクエリーのカスタマイズも行えるようですが、特徴はその検索条件を保存でき、他のメンバーに共有できるようなところに強みがあるようです。
  • Backlogは今のところレポーティングに弱いようです。今後の改善に期待！

第二部 どのようにチケット管理システムを開発プロセスに組み込んでいるか？

ここからがきっと私を含めオーディエンスが本当に聞きたかった部分かと思います。実際、ある程度チケット管理システムを使ったことはあっても有効に開発プロセスの改善に使えていない、と感じているのは私だけではない、、、はず。このテーマについても、分かったつもりの部分を。。

アナログとデジタルの併用

おそらくほとんどのパネラーさんが一致していたのが、チケット管理システムだけでなく付箋＆ホワイトボードのタスクボードや手書きのバーンダウンチャート等の「アナログなツール」を併用している点だったと思います。

デジタルだけで完結させずにアナログなツールを使うことのメリットとしては、紙で残っていると記憶に残る、とか、メンバー間で情報の共有がしやすい、等のメリットがあるようです。

一方で、どのパネラーさんも苦労しているのは、付箋とチケット管理システムの二重管理がどうしても発生してしまい、情報の同期に結構なコストがかかっているようです。この点はみなさん決定的な答えがないようで、きっと現場によってケースバイケースの工夫をしなければならない点なのだと思われます。

そんな中で、ボーダフォン社がJIRAで入力したチケットを即座にプリントアウトして、それをタスクボードに貼り付ける、という事例も紹介されました。

チケットの階層化について

WBS(Work Breakdown Structure)のようにタスクを階層構造に分解していくような作業にチケット管理システムを適用させる点についても議論が大きかったと思います。

たしかに、redmineやJIRA、そして意外とtracも階層構造を作れるようなのですが、意見はチケットの階層関係を作るのは意味が無い、という多数派の意見だったと思います（というかそれに対しての反論が出なかったという意味で）。1000人を超えるユーザーが使うまでにRedmineを使う文化を根付かせた[twitter:@daispresents]さんもチケットの階層関係を作っても結局管理しきれなくなるし、階層関係を意識したガントチャートを作っても結局あまり見られない、というご意見でした。

チケット管理システムで扱うタスクの粒度

[twitter:@daispresents]さんからは、チケット管理システムはあくまでメンバー間のコラボレーション促進ツールとして使う点にもっとも価値があり、個人のTODO的なタスクまで管理するのにはマッチしない、という意見がありました。一方で、同じくRedmine代表の[twitter:@takanafu]は逆に個人のTODOも含めて良いのではないか、とのご意見がありました。

この点に関しては自分もRedmineを使いながらいつもどのくらいの粒度が良いのかな〜、と模索している点で、個人的には細かすぎるタスクは管理が面倒になるので、なるべく共有に値するものを入れるようにしたほうが良いのかな〜、と思っていた点です。

チケット管理システム上での非エンジニアの方とのコミュニケーション

これは第一部の終りに、一部のテーマを無視して私が[twitter:@daispresents]さんに質問してしまったことなのですが（汗、非エンジニアの方とRedmine上の情報をどこまで共有しているのか伺いました。

この質問の意図としては、開発的な内容（例えばアーキテクチャとか設計に関すること）を管理しているプロジェクトを見ても、非エンジニア（デザイナーとかWEBディレクターさん）は意味がわからないだろうし、いったいどうしているのだろう、と気になっていました。

[twitter:@daispresents]さんの回答としては、ビューやプロジェクトを分けて管理しているとのことだったのですが、その後、ツイッター上でご本人が「これをわけないようにしたいなーと最近思います」とおっしゃっていたように、ここについても最適なやり方をみなさんまだまだ模索しているようです。

所感

各ツールの良い所悪い所については結構、お互いの「潰し合い」的な場面があって「大決戦」ぽかったのですが、開発プロセスの話になると、やはりパネラーさん達の意見はわりと近寄っていました。結局ツールは違えど、やりたい事、目指していることには大きな違いはないということなんじゃないかと思います。そして、色々な事例の中でみなさん明確で確立したやり方を必ずしももっているわけではなく、創意工夫しながらプロジェクトを作り上げているのだな、と感じました。そして、結局のところ、この手のことも聞くだけではどうしようもなく、学んだことを現場に活かさないとな〜。。

＊プログラムの詳細は後日スライドシェアでアップされるようなのでそちらをご期待ください。

*1:今回の話にはでませんでしたがLinux環境ではRedmine Cloud Hosting, Redmine Installer, Docker Container and VMなんかがall in oneかつインストールが簡単なRedmineパッケージだと思います。

*2:個人的には4つのチケット管理システムの中で一番使っているツールなのですが、素のまま使っても特に不便さを感じ無いUIとデフォルトのレポート機能だと感じています

*3:これも補足ですが、Redmineでは複数プロジェクトをまたいだロードマップを作れたり、プロジェクトの階層関係を作ったりすることが出来ます。ただし、実際にそのような使い方をすると管理が逆に複雑になる、という話もありますが

*4:自分が知っている範囲だと、検索条件をweb画面上でカスタマイズ＆保存できました