仕様書をSubversionとTracで管理する

議事録をTracへ載せる話は「議事録はTracへ」に書いたけれど、今度は仕様書の話。ソフトウェア開発の構成管理にはSubversionを使っており、その中にはソースコードだけではなく、Wordã‚„Excelで作った資料も入れるようにしている。以前はサーバの共有フォルダに入れていたけれど、色々な面で問題が有ったのでSubversionとTracを使うようにした。目的は下記の通り。

1. 仕様変更の確実な履歴管理
   Wordファイル自体に変更履歴を管理する機能はあるけれど、ファイルを開いてみなければ分からないし、必ず履歴が残っているという保証も無い（誰かが変更箇所を承認してしまった等）ので、あまり使える機能ではない。確かに、短期的に変更点を知ってもらうには分かりやすくて便利なのだけど、長期的な保存に耐えうる機能ではないと思う。そこで構成管理へ入れるようにすれば、遙か昔の履歴も確実に残るので安心だ。
2. ソースコード、チケットとの連携
   Tracを併用するメリットとして、「この仕様変更」が「どのソースコード変更」に紐付くのか容易に分かる点が上げられる。例えば、対応すべき要件をwikiに記載しておき、該当する仕様書やソースコードのコミット時のリビジョン番号を追記すれば、「要件と仕様書、ソースコード間の相互参照」が可能になり、トレーサビリティは向上する。（これをもっとシステマチックに行うと、要件そのものをチケットに入れるという「チケット駆動開発」になるわけだ）
3. Tracによる仕様変更の見える化
   Tracのタイムラインには、Subversionでのコミット操作の日時やログが表示される。開発グループの中で、誰がいつどのような作業を進めているのか進捗状況を確認することが出来るので、管理者としては便利。もちろん、TortoiseSVN等のツールで同じ情報にはアクセス出来るけど、Trac経由の表示になることで見やすくなるし、TortoiseSVNを使わない人でもWebブラウザ経由でログを見れるメリットがある。
4. ファイルの上書き防止
   メール添付や共有フォルダ経由でファイルを受け渡ししていると、誤ってマスター版のファイルに別ファイルを上書きしてしまう事故が発生することがあるけど（あるよね？）、こんな場合も構成管理を使っているなら、元のファイルを容易に復旧できる。
5. ファイルの紛失防止
   こんなお粗末な問題が発生するなんて情けないのだけど、誰かが誤ってサーバ上のファイルを削除してしまいファイルが消え失せたことがあった。すぐに気がつけば、サーバのバックアップから救出できるとは言え、「半年前に見たのが最後」なんて言うファイルはバックアップにも残っておらず復旧は不可能。これに懲りて、ファイルを構成管理に入れるようになった。

今のところ、この方法で上手くいっている。最近はさらに一歩進んで、仕様書自体をtracのwikiで書くようにしているのだが、これについては別途記載したい。