レビューをTestLink＋Redmineで管理できないか？

SQIP2009の森崎さんの講演「レビューの壁を破る」を聞きながら、考えたことをメモ。
＃後でまとめる。

SW開発の品質UP、プロセス改善を目指すと、最終的には設計工程でどれだけバグを潰せるか、という点に落ち着く。
上流工程の品質UPが鍵を握る。
そのためには、設計レビューが必要で、きちんとすべきだね、という話にいつも行き着く。

しかし、設計レビューそのものの品質が低いように思う。
僕がいつもレビューで問題と思う点は、二つある。

一つは、レビューのプロセスがあいまいできちんと定義されていないこと。
例えば、レビューする際の観点がレビューアによってまちまちだったりする。
レビューのチェックリストがあるにはあるのだが、形骸化しており、機能していない。

もう一つは、レビューで指摘を受けた内容を反映する作業のチェックがおろそかであること。
例えば、レビュー後修正の品質チェックが個人任せで、他人のチェックができていない。
その原因は、レビューアの人数不足でレビューそのものが遅れがち、などがある。

議論を聞きながら思ったことは、「レビューを設計工程のテスト」を考えられないだろうか？
設計書をレビューのチェックリストに基づいて、ウォークスルー形式で検証しているのではないか？
となると、レビュー後修正は、設計のバグ修正に当たるのではないか？

つまり、レビューを設計のテストと考えると、下記の相関関係が成り立つのではないか？

レビューのチェックリスト＝TestLinkのテストケース
レビュー結果＝TestLinkのテスト結果
レビューで指摘を受けた内容を修正＝Redmjneでバグ修正

すると、TestLinkのビルド、ブロックはレビュー工程でどのように対応するのか？
まだ分からない。

設計工程やレビューでいつも腑に落ちないのは、Excelばかり使っていて、作業状態の把握や集計作業が大変なこと。
チケット駆動開発にレビュープロセスをのせることができれば、プロセスをBTSのワークフローで管理できるし、レビューの漏れがなくなるのではないか？

RedmineやTestLink、Mercurialなど各種ツールを使いこなすと、下流工程のプロセスはツールで制御できるようになる。
しかし、上流工程、つまり要件定義や設計をチケット駆動開発が制御するのは不十分。

色々考えてみたい。