TracからRedmineへ移行しない、たった一つの理由
今更公開した新年会の資料を「チケット駆動開発の運用例: プログラマの思索」で取り上げていただいたのですが、ちっと補足しておきますよ〜っと。
喋る用の資料であることと説明不足ですかね、修行が足りなさを痛感します。
この辺とかこの辺を良く読んで勉強し直せって感じですね。*1
チケットをExcelで一括インポート
ごく初期だけで日常的な運用には使っておらず、複数のツールを使って管理するのは運用(利用)負荷が上がるだけなので、基本はtracのチケットのみで管理しています。
チケットの入力負荷の軽減を図るためにコンポーネントだとかチケットタイプ・関係者などの定型的な情報をリンクにパラメータとして埋め込んでwikiにまとめてあります。チケット分類によってはチケットの中身までテンプレート化して用意しているパターンもあります。
チケット集計結果をExcelで出力
社内向け月次報告用の工数集計はTracのReportに置き換えてしまっているので、別段作業の必要はなくTracにアクセスすれば何時でも確認できる状況にしてあります。
社内での報告については「随時更新されているからTrac見てね」の一言で紙の資料は廃止しました。
Excelで別管理し一括インポートを日常的には使わないのはここに理由があって、発生時点で作業記録としてのTicketを書くだけで、自動的に集計された表が公開されることになるわけです。結果として日々の報告作業や月次の集計作業を大幅に削減することが出来ました。
ちなみに当月分の集計表、三ヶ月分(当月含む)の集計表をメインとして使っています。*2
エクセルの使いどころ
使うのは顧客報告用の見栄えを求められる報告書や、顧客からフォーマットを指定されている報告書についてはReportやクエリを作成しExportしたものをExcelで再加工するぐらいです。社内向けでは殆ど使ってないです。
Tracにこだわり続ける理由
TracはTracの持つReport機能を利用することにより、SQLを使って柔軟なレポートを作成することが出来ます。
私はTracをチケットやタスク管理といったプロジェクト管理のためのツールではなく、情報の公開のため・見える化のためのツールとしても捉えていて活用しようと考えてます。
DBへ直接アクセスしExcel/Accessで集計をし見栄えの良い報告書を作ることは難しくありません。しかし他のツールを挟むことにより情報の入手まで手間がかかったり、集計までタイムラグが有るのでは折角のデータも参照されることが少なくなり生かされません。
チケット集計結果を含めてTrac単体で公開・運用が出来て、利用者(エンドユーザ)の1システム(Trac)で完結できる。結果として開発者にとっても管理者にとっても必要な情報を必要なときに簡単に得ることが出来る。そこがTracの強みであり使い続けている一番の理由です。*3 *4
というわけでRedmineはTracで言うところのクエリしかなく、単体では十分なレポートを公開・参照することが出来ないので、浮気せずTracを使い続けています。私自身は言語がRubyでもPythonでもPHPでも全く気にしないのでcandycaneがTracなみのReport機能を持つのであれば浮気しちゃうかもしれません(笑)
おまけ
前回の資料を使った時の動画も貼っておきます。
