未分類

なぜ JIRA を選んだのか、なぜ JIRA を選び続けるのか #jiraadvent

JIRA Advent Calendar 2011の2番手です。このブログでは時々Atlassianの手先ではないかというくらいJIRAに傾倒したエントリーを起こしていますが、どうしてJIRAを選択したのか、そしてなぜJIRAを使い続けているのかを改めて書いてみたいと思います。

結論:
Bugzilla、Clarify、Trac、JIRAを使った。JIRAが一番。

自分Issue trackingツール史
・記憶ベース
小中高大と趣味でプログラミングをしていた頃、issue trackingはしていませんでした。
自分の中で特にマイルストーンがあるわけでもなく、なんとなくやってみたいことを書いてみて、思った通りに動くと技術的関心が薄れ、おしまい。
自分が書いたものを公開する場はパソコン通信とかTAKERUとかオープンなようで閉ざされた空間しかなく、フィードバックもなかなか得られないので長続きしないのはしかたないです。
長続きしないので、継続的にバグをトラッキングしたり、追加機能のアイディアを書き留めておいたりという必要をそもそも感じないのでissue trackingをするという発想すらありませんでした。

・口頭とかメールとかExcelとか
新卒で入ったSIerでいくつかB2C、イントラ系のWebシステム開発をしました。
1人から数人規模のプロジェクトばかりで、進捗状況やバグの管理は体系立てて行わなくても問題を感じませんでした。共有フォルダにExcelスプレッドシートを置いたり、メールや口頭ベースで状況を伝え合うだけで済んでいた気がします。

・Bugzillaとの出会い
仕事で開発をするようになったのと同じくらいの時期、Jakarta ProjectのCommonsやStruts、Velocity、sourceforgeのSAXONといったオープンソース製品を使うようになりました。多くのプロジェクトは当時Bugzillaでバグトラッキングが行われていたように記憶しています。
あーこうやってバグとか新機能案とかを記録しておくんだーと感心しましたが、同時にBugzillaはどうも質実剛健で使っていてワクワクしないなーとも思いました。たぶんCSSはほとんど使っておらず素のHTMLの塊という感じの見栄えでした。(今ではだいぶしっかりしたL&Fになってます)

・ブログの立ち上げ、MovableTypeの導入
仕事で必要が生じて作ったツール「」を公開するにあたり、ブログを立ち上げたいなーと思い、当時流行っていたMovableTypeを自宅サーバに導入しました。
movabletypeをインストール – 侍ズム
MovableTypeはブログウェアの走りなだけあってかなり良く出来たソフトでした。ただPerlベースでパフォーマンスが悪い(というと異論を呼びそうだけど・・・)のは難点。

・MovableTypeからPebbleへ、JIRAとの出会い
最初はあまり気にならなかった再構築(MovableTypeがデータベースに記録されているブログデータから静的HTMLを作成する処理)はエントリが増えれば増えるほど処理時間が長くなっていき、いよいよ耐えられなくなってきました。
#PHPを使って再構築を避けることは一応できるけど設定が面倒でやらなかった
そこで新しいブログウェアを、特に自分が扱いやすいようJavaで出来たものを探しました。確か@akrに教えて貰ったのがBlojsom。
Blojsom味見 – 侍ズム
たぶんJavaベースのブログウェアでは当時一番ホットだったかも?
しかしシンプルさとカスタマイズのしやすさ、それからファイルベースかつLuceneを使っており動作が高速ということでPebbleを選択しました。
今度はPebble味見 – 侍ズム

カスタマイズのしやすさから選択したこともあり、実際数々の改造を施し、パッチを送りつけました。
Pebble改造歴 – 侍ズム
パッチを送りつけるにあたり、Pebbleで当時使われていたJIRAに出会いました。見た目の良さ、高速な検索、使いやすさとどれをとっても良い感じでした。

・Clarify、Footprint
テクニカルサポート職で使ったケースマネージメント/CRMツールがAmdocsのClarifyやNumaraのFootprint。
どちらも商用ツールなだけあってナカナカの見栄え。
ただClarifyはパフォーマンスがイマイチ。検索するたびに海の向こうでOracleがガリガリをディスクを舐めているのが聞こえそうでした。(今は改善されてるかも?)
Amdocs – Customer Experience Systems Innovation
Help Desk Software | Service Desk Software | IT Service Management

・JIRA最高!

JIRAはオープンソース製品では無償で使わせてくれるので確か2007年からTwitter4J向けにライセンスを頂いています。
記念すべき第一号のissueはこれ↓
[#TFJ-1] need support for destroying directmessage – JIRA
趣味だけでなく、ここ最近勤めて来た3社はどれもJIRAを使っているので公私ともにJIRAにお世話になっています。

ネタを考えることなくadvent calendarに参加表明してしまい、だらだらとまとまりのないエントリになってしまいました。
色々使ってきたけど機能の豊富さ、カスタマイズのしやすさ、見た目の良さ、パフォーマンスの良さとどれをとってもJIRAが一番良いと感じているというのが結論です。

明日は@oota_kenの予定です。何を書いてくれるんでしょう?
そして12/5(月)は@daisuke_mがやはりJIRAに対する愛を、
12/6(火)は@j5ik2oがGroovyを使ったJIRA黒魔術を、
12/7(水)は@EwigkeitがJIRA管理のtipsを書いてくれます。

追記:
Tracはインストールが大変だった。予算の関係からJIRAを使えずTracを使ったことがあるけどちょっと苦労した。
Subversion, Trac のビルド / インストール – 侍ズム
Subversion リポジトリの初期化 & Trac に認識させる – 侍ズム
Trac in action – 侍ズム
mod_python による Trac と Apache の連携 – 侍ズム

Scarabもちょっと使ったことあります。JIRAをインポートできるのがすごいと思った。
バグトラッキングシステムの 選別 – 侍ズム

Redmine/Mantisは使ったことないです。どちらも見た目がかっこよくて良い感じ。
ただTrac/Redmine/Mantisを使っている人はプラグイン開発やカスタマイズにものすごく手間暇かけている印象。インストールしたらさくっと使えて標準の機能で必要なことが一通りできると言う点でJIRAが好き。
githubとの親和性が高いのもJavaベースなのも好き。
githubのissueトラッキング機能はいまのところ残念。