ラベル

2/17: デブサミ 2011 / チケット管理システム大決戦

はじめに: ずーっと一参加者としての参加なので、非常に申しわけないのです..。

ただ、平日夕方や土日になかなかIT系のイベントに参加できない身のわたしにとっては、平日の昼間で東京での開催 / 参加費無し というのは凄く有難い催しです。
子どもが生まれてからの数年、なんとかこのイベントだけは参加するようにしています。

本当は通して2日間参加したいなあと思ったのですが、さすがにそれは厳しかったので、今年の参加は2/17の午後のみ、となりました。

参加したセッションは、下記の通りです。

はじめは1本のブログ記事にまとめようと思ったんですが、あまりにも長くなってしまったので（汗）、今回は『チケット管理システム大決戦』のみ取り上げます。

メモを取りながらの参加でしたが、聞き違い・認識間違いもあるので、そのあたりはご指摘いただければ幸いです。

* * *

【17-B-4】 チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか

こちらは、本日もっとも楽しみにしていたセッションです。広い会場ですが、人もたくさん！デブサミ始まって以来、一番の参加人数だったとか、あとで聞きました。気が付くと、同じ会社の方が1つおいた隣の席に座っていました。（先方はTrac派です）

実は、3つのBTS（ITS)についてのアツい戦い（！）を想像していたのですが、割と穏やかに、それぞれの特徴を紹介し、違いを認識し合うような形で進んでいました。

どちらかというと、共通の敵は『Excel』であったり、『プロジェクトマネジメント上、進捗管理やリスク管理にかかるコスト』である、という共通の認識で、こちらを使えばこうだよ、というのをお話ししてくださった感じです。

Redmineは実際使っていますし、Tracも別の部署が立てているものにアクセスしたりして、概要は知っているので、このあたりは「ふむふむ」という感じで聞いておりました。

20110217-1

0. はじめに – Issue Tracking Systemについて / 大澤さん

まずは、モデレータの大澤さんのお話し。スピーカーの方のご紹介から始まり、Excelを代表とする、プロマネのファイル上に記録されたチケット・タスクの管理の煩雑さを表すディレクトリの例を上げて下さっています。

（わたしの部署でも、企業内に閉じたプロジェクトであれば、ITS・BTSで管理する方向になっていますが、人によっては紙のWBSを作らないとダメ、細かい計画を立てないとダメ、というポリシーの方もいます。）

  • WBSを作っても、あとになるほど現状と乖離してしまい、保守に1日のほとんどを費やすことになってしまう。
  • ガントでしかリスクが見えなくなってしまい、タスクの依存関係はそこからは見えてこない、という状況になってしまう。

そうしたコストを減らすためにITSを使おうという認識は、会場の皆さんも含め一致したかと思います。

1. Tracについて / 吉羽さん

吉羽さんも、かつては複数のプロジェクトを一度にマネジメントしないといけない立場だったそうで、その時は一日1000件ものメールがあったとか。（さすが、処理の限界がありますよね…）

メールだとプロジェクト全体が把握できない、プライオリティ付けがうまくできないと仰っていて、その例をこんな風に表現されていました。

  • 後入れ先き出しになってしまう、と。

また、メールや口頭でのコミュニケーションだけでは、行き違いや認識違いが発生してしまうこともあり、そういった状況に対応しないといけない場合の、見えないコストが高いとも仰っていました。

さらに、メンバーが変わった時に、今までの情報の共有や、スキルトランスファーがメールでは難しい、ということも。

伺った限りでの、Tracの特徴は、下記の通り。

  • インストールが簡単である。
  • 吉羽さんが導入しようとした際は、他に選択肢が無かった、という理由もある。
  • プラグインが非常に豊富で、100以上ある。（http://trac-hacks.org/）
  • レポートクエリが強力で、Trac用のクエリ＆SQLのクエリの双方で記述できる。
  • お客さん向けの報告書をまとめるときにも、レポートは非常に重要！

2. Redmineについて / あきぴーさん2. Redmineについて / あきぴーさん

Redmineは実際使っているので、どちらかというと、自分が『これはイイ！』と思っている点が、他の皆さんにもあてはまるかどうか、の再確認として伺っていました。

やはり、プラグインの追加無しで、チケット管理だけでなく、バージョン管理やWik・フォーラムなどのコミュニケーションツール、ガントチャートの利用ができる点は、管理する側にとっては楽だと感じています。

あきぴーさんの仰る通り、わたしもバージョン（ロードマップ）の使い方がうまく理解できたのは、Redmineを使ってからでした。

  • Redmineはデフォルトでも集計・レポート機能が使える。
  • チケットのバージョン紐づけて使うことで、進捗の管理が行いやすい。

なお、海外ではRedmineの利用は少ない、というお話しがありました。これについては、@haru_iida さんのブログに面白いデータが載っています スマイル

3. JIRAについて / 鈴木さん, 大澤さん

一方で、JIRAについての知識がほとんどなかったので、鈴木さん、アトラシアンの大澤さんのお話は、貴重な収穫になりました。

Jenkins (旧Hudson)のIssue Trackerのプラットフォームとして使われているので、私もバグレポートのためにアカウントを作り、触ったりしてはいるのですが、てっきり有料だと思っていました…。

伺った限りで、JIRAの特徴をまとめておきます。

  • 基本はチケット管理に特化したもの。チケット管理しかしない。
  • 1つのJIRAで、マルチプロジェクト（複数プロジェクト）での利用が可能。
  • チケット管理の機能はシンプルに作られている。
  • ワークフロー設定が柔軟にできている。（ただし、設定が非常に難しい or 煩雑らしい？)
  • Office製品との連携が可能で、Excelだけでなく、Wordにも出力できる。（マネージャ向けには便利）
  • アトラシアンの自社開発で、まず自分たちで使い、フィードバックし、製品としてリリースするスタイルを取っている。この点については、大澤さんは、『ドッグフーディング』と表現されていた。
  • ソースコードはオープンである。
  • オープンソース開発でJIRAを利用する場合は、無償で利用できる。（じゃあ、Jenkinsもそうなんですね！）
  • 10名のプロジェクトなら、月額1000円で利用できる。
  • 1000円と言っても、じつは名のある基金への寄付金に充てられる。
  • プラグインという形ではなく、JIRAとは別のアトラシアン製のモジュールを併用することで、拡張ができる。

「ドッグフーディング」について、このレポをまとめている間に気になったので、検索をしてみると、ズバリ、大澤さんのブログそのものが一番にヒットしました。

ドッグフーディングと頻繁な内部リリース: http://blogs.atlassian.jp/2009/12/post-12.html

  • ドッグフーディングとは、自分たちの製品を使用することをまさに意味しています。これは、素晴らしい原則です。
    なぜなら、自分たちのソフトウェアを使用することにより、顧客と同じような痛みを共有することが出来るからです。

もちろん、アトラシアンに限らず、いろんなところでそういう開発はされていると思いますが、端的に表す言葉として、これはいいなあと感じました。
また、アトラシアンの方は、チケットに登録することを『JIRAっといて』と言うのだそう。なかなか良い言い回しですよね。

＃単純な私は、『JIRAっといて』と言いたいばかりに、JIRAを試してみようかな、と強く思いました。月1000円なら主婦のお小遣いでも捻出できますので…。

4. フリーの討論

ひととおり各ITSの紹介が終わった後は、フリースタイルの討論になりました。
ここから先、メモしたものを書いてみます。

  • 案件のかけもちがなく、みんな同じ場所にすぐ集まれるなら、アジャイル的にポストイットでタスク・進捗を管理するのが一番。
  • でも、ISMSの規定により、「カベに貼るな！」という決まりになっているところもあるのだそう…。（切ないですね）
  • 朝会のときにだけ貼り出し、あとは巻いてしまっておく、という涙ぐましいやり方もあるらしい。
  • BTS・ITSを導入すると、たくさんチケットやタスクを積みたがる人が出てくる。どういった粒度で記録するか、この辺をうまくコントロールすることが大事。
  • 仕様書とWikiの使い分けは？
  • 履歴管理が必要な仕様書はSVNに、プロジェクトを遂行するために共有すべき情報やテスト、振り返りといったものは、Wikiに記述する形で使い分けている。（あきぴーさん）
  • アジャイル開発だけではなく、ウォーターフォール型の開発でも、特にバグトラックのフェーズではITS/BTSの導入は有効。

チケットがすべてか？という問いには、こんな意見が。

  • なんでもTrac,メッセで済まそうとしてはダメ。
  • 本当に必要なもの、共有したいもの、残しておきたいものをプラットフォーム上に残すこと。
  • 一過性の会話で、すぐに解決してしまうものならチケット化する必要は無い。
  • 大事なのは、やはり Face To Face だよ。

また、使い方のポイントとしては、こんな意見も。

  • 導入だけじゃ効果がでない。チームで使い方、運用方法を決めないとダメ！（吉羽さん）
  • 使うならプロジェクトの最初から使おう。
  • プロジェクト成功のための『場』として、全員がつねに見るんだというように教育することが大事。
  • 毎日使う、毎日更新。
  • 積まれたタスクは放置しない。ゴミ箱のような状況になるのを放置しない。
  • タスクが多ければ多いほど不健康なプロジェクト。週1回は放置チケットをチェックし、アラートを上げるなどの方法で、棚卸すること。
  • プロジェクトのふりかえりと一緒に、ツールそのものの使い方についての振り返りも行い、改善を図ること。（あきぴーさん）

JIRAについては、まだ商用（有償）ベース、日本語の情報が少ないといった課題を上げ、これから拡販を目指すとのことです。

20110217-2

5. 補足 / 感想

セッションのタイトルの、「なぜ私はこのツールをつかうのか」というテーマなんですが、それぞれ良いところがあるし、どれが一番とは言えないなあと感じました。

セッションの最後でも、「どれが一番、というのではない。プロジェクト毎に一番フィットするものがあるかもしれない」というコメントが出ていました。
まあ、もしかしたらその後のLTやShibuya.tracの勉強会で、アツい戦いが繰り広げられていたのかもしれませんが…。

レポを書いている間に、いろいろとプレゼン資料や比較表がアップされていたので、下記に貼っておきます。

また。今回のセッションをきっかけに、JIRA、Mantis、そしてKanonといったBTS/ITSについての話題もハッシュタグ (#itsjp)に乗っていろいろ出てきたのは、とても有難いことです。

* * *

実は、個人的には、TracはTrac月を入れようとして挫折した経験があります…。

当時、なぜ難しかったのか思い起こすと、素のTracだけでは機能がシンプルすぎて何か追加しようとしても敷居が高すぎたこと、それから、リポジトリとTracが同じサーバにないとダメだったこと、マルチプロジェクトに対応していないことがネックになったような気がします。

ちなみに、Tracは、私にとっては『漢（おとこ）らしい』とか、『エンジニア気質』といったイメージがあります。
そういうイメージが、Shibuya.trac のロゴに出ているかな…と思っています。

今はもっと簡単になっているかと思いますが、もともと、産休前に自分のタスクを引き継いでもらいたくて、何か管理しやすいものは無いかと思ってBTSを探したのが始まりです。

ただし、自分はあと3か月くらいでいなくなってしまうので、そのあとに設定が難しいシステムもろとも、引き継ぎ担当者に渡すのは申し訳ないなあ…と判断し、一回入れれば済むだけのRedmineに軍配があがりました。

そんなこんなで、「なぜそのツールを使うのか」というと、人と人とのように、プロジェクトにもそのツールと出会う『縁』みたいなものがあるのかもしれませんね。

Face To Faceのやりとりの大切さは、スピーカーの皆さんが仰っておりましたが、会話の中で出てきた本当に共有すべきことや、お互いに合意し合った証、アイディアの種は、大切にプラットフォーム上に記していきたいな、と思いました。
きっと、あとでITS上のタイムラインを眺めることで、自分たちのプロジェクトの軌跡をたどることができる、大切な『場』になってくれるんじゃないかな～、と思っています。

ラベル:

コメント

  1. たかのあきこ2011年2月21日 14:31

    スピーカーの方の役割（モデレータ、JIRA代表スピーカー）の記載が間違っておりました。
    JIRAについては鈴木さん、大澤さんそうほうお話し下さったかと思います。
    内容を少し訂正いたしました。

    返信削除

コメントを投稿

人気の投稿