３年間Redmineでチケット駆動開発をしてきて思うこと
いまのプロジェクトを初めてもう３年ほどになりますが、この課題管理をずっとチケット管理システムであるRedmineでやってきました（Trac本を執筆したというのにRedmineを使った理由はいろいろありますが、マルチプロジェクトが必要だったのが大きいですかね）。とくにノウハウと言うほどのものはありませんが、年度末なので使ってきて思ったことを色々書いてみます。かなりまとまりがないのでご注意ください。
まず、プロジェクトの特徴から。
基本的に少人数のプロジェクトです。多いときでも４人。作っているのは、Windows向けのパッケージ製品（言語はC#）で、開発を初めて一年半ほどで正式リリースをしました。正式リリース後の保守＋追加開発フェイズはほとんどメンバーはぼく1人でした。リリース計画はメジャーリリースの一回のみははっきり決まっていましたが、その後のマイナーリリースについては、お客様からの要望があってからはじめてリリースするというようなラフなかたちでの運用でした。
チケットはお客様にも公開しており、お客様自身がバグチケットを起こすことが出来るようにしました。チケット管理以外の部分としては、ソースコード管理はSubversion、技術文書もリポジトリに入れることにしました。お客様とのやりとりはDropboxで、打ち合わせの大半はSkypeの電話で行い、あとは適宜Skypeのチャットを利用しました。
大枠はこんなところです。これらの特徴をふまえていくつか思ったことをまとめてみたいと思います。
メンバー数について
これはチケットそのものを管理するための時間を大きく割くことが出来にくいと言うことがあります。時間入力などもしてはいるのですが、漏れも多く、チケット自体の粒度をそろえたり、リリース計画などをしっかりつくることはできませんでした。ただ、リリース計画についてはメジャーリリース時のみが決定的で、あとは流動的だったため、大きな問題にはなっていません。そんなわけで、厳密なチケット管理という意味では出来ていないと思いますが、タスク管理や履歴が蓄積されることで十分意味はありました。
お客さんについて
お客さんにもサイトの権限を与えて自由にチケットを発行、閲覧できるようにしました。
これによってお客さんの追加要求もチケット管理に集約できるようになりました。いっぽうで、チケット管理になれていないために発生する部分をサポートする手間もありました。さらには、チケットを公開することで内部タスクのような細かいものまでオープンになることになり、不都合もありましたが、Redmineのプロジェクトはサブプロジェクトを切ることが出来、かつその公開範囲を限定できたので、リファクタリングや作業タスクなどのものはそちらに登録することで何とかなりました。
ただ、ひとつこれが出来たら良いのにと思うのは、現在のRedmineではプロジェクトを跨いだチケットの親子関係が作成できないことです。たいていバグとか要望とかトラッカーが登録されると、そのチケットに対しての作業を細かいタスクに分割し、子チケットとしてぶら下げるのですが、これをメインプロジェクトに登録してしまうとかなりの数になってしまうため、本当はこれらの子チケットは開発メンバーのみが見られるサブプロジェクト側に移動したかったのです。しかし、現行のRedmineではそれを許していないようです（現在はチケットをプライベートにできて、かつ開発メンバーが自分1人であるのでそれでも対応できますが……)
とまあ、痛し痒しの部分もありましたが、お客様自身にチケットを作ってもらうことのメリットのほうが勝っていました。自身で入力する手間をいとわない理解のあるお客様だったので良かったです。
リリース計画について
上記にも書きましたが、保守フェーズに入ると毎回のマイナーリリースに何を入れるか、ということがかなり流動的でした。ある程度要望を解決したのでそろそろリリースしてください、という依頼が多かったので、あらかじめバージョンを作ってそこのタスクを減らしていく、というような開発サイクルはとりませんでした。したがってバーンダウンチャートのようなものもなし。これがないので、将来の見積もりがやりにくかったのも事実で、ここはこちらからある程度勝手に想定してでもやっておいたほうがよかったかな、とは思います（ただひとりでプロジェクトをやっていると、どうしても開発のほうに意識が傾いてしまい、チケット全体の管理がおろそかになりがちなので、いずれにせよ厳密にチケットを運用するのは難しかったかもしれません）
計画的な見積もりについて
「アジャイルな見積と計画づくり」を読んで感銘を受けたので、本当はやりたかったことがあったんですが、結局あまりうまくできませんでした。
・フィーチャ・要望・不具合のチケットには開発見積としてSP（ストーリーポイント）を入力する
・それぞれの子チケットとしてタスクというトラッカーのチケットを作業単位で切っていくつもぶら下げる。こちらは開発見積として時間（作業時間）を入力する
・タスククローズ時には実働時間を必ず入れる
というルールを想定していましたが、これは失敗しました。システム側で制限をつけたりしない限り自発的に入力するのは難しいですね。一定期間入力を忘れている期間があって急に思い出して入力してみたり。入力漏れがあっても忘れないうちに補うのも、定期的にベロシティを計測するのもマンパワーがそれなりに必要で、少人数ではあまりうまく機能しないような気がしています。もっとも、システム側にうまくそれを防止する仕掛けを導入すれば良かったかもしれません。
ソースコード管理について
Redmineとは直接関係ないのですが、いちおう。
メンバーの習熟度もあって、Subversionを使いましたが、パッケージ製品という性質上ほんとうはブランチが気軽に切られる分散型の方が良かったかもしれません。いまのところブランチを気軽に切れないことは大きな問題にはなっていませんが、マイナーバグのリリースがあるとローカルブランチを切りたいな、と思うことはしばしばなくはないです（ただ、開発用のドキュメントが日本語名で運用されていたので、Gitだと厳しいかなあと思っています。最近Bazaarがいいんじゃないかと思い始めているんですが、こっちはちょっとVisual Studioからの運用に難がありそう）
なお、チケット番号をコミットに必ず入れる、というのだけは徹底しました（まあ、これはシステム的にチェックできるから）。ただ、油断するとコミットコメントに「修正した」とか意味のないことを書いてしまいがちです。
CIについて
前に少し書きましたが、Jenkinsを入れようとして挫折しているところです。ビルドまでは上手くいくのですがテストが開始してすぐに落ちてしまいます。解決する時間が取れず今に至る……。少人数でソースコードが多い場合、目が行き届かない古いコードを「生きた」状態に保つためにCIはとくに重要だと分かっているのですが。
以上、まとまりがありませんが、感じたところを書いてみました。うーん、書いてみるとうまく使いこなせてないことの方が多いですね。上にも何度も書きましたが、管理リソースの不足がやはり気になるところです。プロジェクトにチケットシステムを導入すると人数に寄らず発生する管理コストがあるため、人数が少ないほどのそのウェイトが増えてしまうことになります。なので、その負荷を請け負えない場合は、どこかで妥協する必要がありそうです。今回はチケット駆動に近い部分だけでも導入の意味がありましたが、それ以外の部分で管理コストをシステム側にゆだねられる方法を考えた方が良さそう。このあたりは今期の課題ですが、すでにチケットの積み重ねとしての資産がある状態ではやりにくいこともあるので、今後別プロジェクトで試して見たいですね。