ユニークなID付け
バグIDが30の状況はどうなっている？とか、SVNリビジョン100のせいでテストが失敗するようになったとか、現在はテストケースIDが200のテストを試験しているとか、のように事象にユニークなIDを付けて管理することによりコミュニケーションコストを下げるということはソフトウエア開発において一般的に行われているだろう。
そうじゃないと、「〜のバグはどうなっている？」→「〜のバグって何ですか？」→「〜のとき〜すると〜なるヤツだよ！」のようにいちいち説明しないとコミュニケーションできなくなってしまう。
他の例としてはログのメッセージIDだったり、
ESSR0001={0} not found
Seasar - DI Container with AOP -
注文(Order)機能だからOdr001Action.javaみたいな画面ID(6桁)+Action形式もある。
これに関しては反対意見も多いと思うが、採用理由としては画面ID見れば何の機能だかわかるということとなんらかの一貫した命名規約が無いと大量生産できないということだろう。
良くも悪くもこれが大規模（に限らないか）受託開発（製品開発でもそうかも）の実態じゃないでしょうか。
例えば注文明細画面ならOrderDetailAction.javaでいいじゃんというのはそれはその通りなのですが、一貫した命名規約が無い場合は開発担当者が名前付けをいちいち考えないといけなくなります。大規模開発だとExcelからソース自動生成して開発担当者はそれに対して開発する（クラスを作ることは無い）という流れになりがちなので、一貫した命名規約が良かったりするわけです。ま、画面IDと機能一覧のマッピング表を別Excelで作ってたりするわけですが。--);
他のユニークなIDとしてはバージョン番号、ビルド番号なんかもそう。
例えばVer2.0の開発が進んでいて、RC(Release Candidate)1を出すとする。
この場合はv02-00-rc1みたいなタグを打ってリリースするだろう。Tracを使っている場合はバージョンはv02-00にしてマイルストーンがv02-00-rc1になる感じ。RC2を出すならv02-00-rc2というタグを打ってリリースする。１つのバージョンに複数のタグ、マイルストーンがひもづくイメージ。
もうちょっとこまかいモジュールのバージョン付け（例：hoge-1.0.jar）はやったことない。サードパーティのモジュールで既にバージョン番号が付いているモジュール（例：log4j-1.2.16.jar）はそのまま使うけど、自作モジュールに関してのバージョン番号付けはやったことないな。うん。たぶん。
リリースするアプリケーションがWebアプリでJavaならWarファイル１個ならやってもいいけど、たいていそうじゃない。例えばバッチアプリなんかはjarファイルがあってそれをキックするシェルスクリプトがあったりする。jarにバージョン番号（例：hoge-1.0.jar）とかあったらシェルスクリプトで
というような記述が必要なのでバージョンが変わったらここも書き換えないといけない。（ビルド時に書き換えればいいじゃんとかJava6からクラスパス指定にワイルドカード使えるじゃんというツッコミはある）
リリース物が複数のモジュールで成り立っている場合（たいていそうだよね）は、個々のモジュールにバージョン番号付けて管理するのは結構面倒なんじゃないかと思ったりする。Maven使えば多少スマートにできそうだがシェルスクリプトや設定ファイルの記述を変えてビルド、パッケージングするのは大変そう。
ビルド番号はHudsonのアレね。ソースが変わってなくてもビルド番号が違うということはあり得る。これはバイナリ管理だな。Hudsonのファイル指紋を使えばバイナリ管理できるからね。
ちなみに僕はビルド番号を管理体系として使ったことは無い。やったほうがいいのかなー。
使うならv02-00-rc2のビルド番号300に対してテストケースID400から500を試験したらバグID600が摘出されたっていう感じかな。
どこまでユニークなID付けをして管理するかはコンテキスト依存ですが、バグ、リビジョン、テストケース、全体バージョン、タグぐらいまでは必要でしょう。個々のモジュールやビルド番号はシチュエーションによるって感じかな。厳密にやると管理が面倒なのでROI的な落としどころを見極めてやるのがいいでしょう。最近は各ツールが連携しているのでかなりやりやすくなっています。Excelに書いて手動でマッピングの必要性はだいぶ薄れているはずです。
