[trac]システム開発の現場にtracを

社内の他のプロジェクトが火を噴いた。

例によって私を含むメンバーが集められ、対策のため打合せをしたが、相変わらずExcel に課題入力して、メンバーに状況を聞いてメンテナンスするということをリーダーが1人でやってる。
せっかくtracを使える環境を作ったのに...

2年ほど前に自分のプロジェクトが火を噴き、他の仕事している社員をみんな集め、助けてもらったことがある。

当時、残課題の管理をExcelで行っていたが、忙しさが尋常ではなかった為、状況の確認のため全員を集めて打合せをしたり、みんなに状況を聞きまわって管理表のメンテナンスをするのが煩わしく、同じような表フォーマットをAccessでつくり、ファイルサーバに置いて対応状況を入れてもらうようにした。

メンテナンスが煩わしいということもあったが、もっと問題だったのは、Excelを使った管理表では、

    • あとどのくらい残課題があるか
    • あとどのくらい工数がかかるか
    • 着手中の課題について、どこまで対応したのか

といった、必要な情報を得られなかったり、情報を得るために加工が必要だったこと。

Accessにしたことにより、残課題や工数もクエリ一発で計算できるようになったし、課題ごとに子レコードを作って対応履歴も入れられるようにしたため、管理はすごくやりやすくなった。
一応社内に「こんなん作りました」ってことでお知らせをしたが、無反応。まぁ、フォームとか作らずにテーブルに直接データを入れる形だったから、多少使いにくかったかもしれないけど...
それよりも、自分にとっては上に挙げたようなメリットのほうが大きかった。

そんなわけで、昨年tracの存在を知った時は衝撃だった。

「俺のやりたいことがほとんどできてるじゃん」
「去年(火噴いたとき)知っていたらどれほど楽だったろう」

自宅でのみながらセットアップを始め、「こいつはすげー」と1人で盛り上がって酒が進んだ挙句、次の日会社を休んでしまった...

それからほぼ1年、ネットでもわりと情報を見掛けるようになってきており、Webサービスや個人プログラマの開発環境としては当り前に使われるようになってきたが、上述のようにまだまだわれわれのような業務システム開発の現場では一般的ではないみたい。
そこで、自分が今の会社に導入する上で気を付けたポイントや、使ってきて気づいたことなどを書いてみる。

環境構築

  • DBにPostgreSQLを使う
    • tracのデフォルトはSQLiteだが、DBデータを取り出していろいろ加工したりできた方がよいと思い、PostgreSQLを選択。
  • TimingAndEstimationプラグイン
    • 工数の見積/実績管理を行うために導入。
  • ScrumBurndownプラグイン
    • TimingAndEstimationとあわせ、残工数の減り具合から期日までに作業が完了するのかの見極めに使用。
  • リポジトリは顧客単位に複数作成、その他全体を見渡せる管理リポジトリを作成
    • 複数プロジェクトを扱えないので、このようにした。新規リポジトリを簡単に行えるバッチなどつくれば、プロジェクト単位でリポジトリ作成したほうが良いと思う。
    • リポジトリのチケットを見渡すビューなど作成した。

運用

  • 保守業務や仕様変更など、既存システムに対する保守、改修などには本来の使いかたで威力を発揮した。
  • 新規開発を経験したが、正直あまり効果的には使えなかった。

新規開発については、まぁ、慣習的にどうしてもウォーターフォール的な進め方をしてしまうので、もともとあまりそぐわないかもしれないが、うまい活用ができないか、これからもいろいろ試してみようと思う。