事象にユニークなIDを採番する利点

RedmineやTestLinkなどのツールを駆使してプロジェクト運営すると、チケット、バグ、テストケース、要件などSW開発に関する事象にユニークなIDが振られるのに気付く。
すると、チーム内でこんな会話があって、お互いに事象を認識して共有しやすくなっているだろう。

今日は、チケットxxとyyのいずれを最優先で行うか？
今、チケットzzの作業状態はどうなっている？
このSVNリビジョンrrの修正理由は、チケットIDがxxにある仕様から来たんだね。

今、あのバグxxのステータスはどうなっている？
テストケースは何番まで実施した？

そのテストケースyyは、要件IDがxxから作りました。
要件IDがxxをテストするテストケースが漏れていますね。

その仕様は、要件ID xxから来ているから、勝手に修正してはいけないね。

過去を思い出そう。
Excelでバグ管理していた時、きちんとしたワークフローを踏んだ開発チームでは、バグ管理IDを振るための特別なExcelシートがあった。
そのExcelシートで、バグ管理IDをユニークに作り、それから障害報告票を作成し始める。

そんなワークフローにした理由は、IDを振ることで、バグの症状や原因、状況を最初から説明する必要がなくなるからだ。
IDが振られていなければ、MM月dd日に見つけたバグですが、とか、機能AのボタンBのバグでYYYとか、などのように、事象を逐一説明しなければならない。

1日でバグが10件以上も多発した場合、チーム内で上記のコミュニケーションを取るのは至難の業だ。

同様の事は、チケット駆動開発におけるチケットIDでも同様。
君が担当している機能Aの仕様変更はどうなった？という質問をしたい時、仕様変更の中身を説明しないといけない。
納期が迫ってタスクがどんどん溜まっていく時、タスクを説明するだけでかなりの労力をすり減らすだろう。

事象にユニークなIDを振ることで、互いのコミュニケーションのロスが減る。
だが、更なる利点は、変更管理がやりやすくなることだ。

チケット駆動開発では、チケット無しのソース変更を認めないルール(チケット・ファースト)があるので、ソースのリビジョンには必ずチケットIDが振られている。
つまり、ソースの修正理由をチケットに追記することができる。
だから、過去のバグ修正やパッチを追跡できるインフラが自然に整う。

更に、バグ管理IDと失敗したテストケースID、更には要件IDが紐づいていれば、最終的に、ソースの修正理由を要件IDまで辿ることができる。

最近気付いたことは、要件IDを振られた要件定義書を作らずにSW開発を始めているプロジェクトが殆どであることだ。
すると、受入テストで使うテストケースを作る時に、そのテストケースは要件に基づいた業務フローで作られているのか？という保証をするのが非常に難しくなる。

受入テストは要件定義のテスト工程であるから、テストの元ネタとなる要件として揃っていなければ、テストケースのレビューもできない。

IDを振るという行為には、事象をユニークに定めるという基本動作が含まれている。
そこから、IDに重複がなく漏れもないということを自然に考えるようになる。
つまり、要件や仕様がダブりなく漏れもないようにMECEで考えることを自然に行っているはず。

IDを振る行為には、コミュニケーションロスをなくすだけでなく、変更管理を容易にするだけでなく、IT技術者としての基本動作も含まれているような気がするのだ。