効率的な設計レビュー方法

ソフトウェア開発で設計レビューをしているが、やり方が人それぞれバラバラで効果がよくわからない。ということはないだろうか。せっかく時間をかけてレビュー会をやっているのに形式だけになっているのならば、戦略的なレビューを実施することで、効果のあるレビューにしたい。

【広告】

レビューの目的とは

• 工程の漏れや間違いを見つけ、後工程での修正コストを少なくすること。

以上

つまり誤字脱字系の軽微な間違いは後で直してもたいしたコストはかからないが、設計の漏れや間違いは後工程になればなるほど修正コストが増大する。最終的にリリースした製品に発生した不具合は修正コストもさることながら損害賠償問題にまで発展すれば経営にインパクトを及ぼすような膨大なコストとなる。

事前準備

1. プロジェクトリーダーが「見逃し問題リスト※1」から、過去の類似案件の指摘事項や、レビューをすり抜けてテストや本番で大きな手戻りが発生した内容を洗い出して、今回のレビューで使用するチェックリストを作成する。
2. プロジェクトリーダーがレビューでどんな問題種別を検出すべきかを考え、その要点をまとめたシナリオをいくつか作成する。(1～２Hで作成する)
   1. システムに求められる性能や機能、メンバーの状況などから考えられる問題種別
   2. 今回のプロジェクトと類似の案件で、過去に大きな手戻りが発生しているような不具合から考えられる問題種別
   3. 上記の問題種別について、どの部分をどういった観点からレビューするのかがわかるようにシナリオを作成する。
      例：「アイテムアクセスのセキュリティの機能に漏れがないかどうかを調べるために、アイテムのセキュリティに関連する設計をチェックする。たとえクライアント側でのセキュリティチェックをすりぬけたデータがあっても、サーバー側で正しくチェックされていることを確認する。」
      例：「各機能間で受け渡しされるデータに不整合がないかどうかを調べるために、CRUD図をチェックする。入力はされていないのに、読み込みされているデータや、入力のみで読み込まれないデータが無いことをチェックする。
3. レビュアーは今回のプロジェクトの分野に詳しいか、レビューのスキルが高いメンバーを割り当てて、上記で作成したシナリオをそれぞれに割り当てます。一人のレビュアーには２～３個のシナリオを割り当てます。そうすることでレビュアーはそれぞれが違った箇所を精査することができます。
4. ドキュメントの事前レビューを行う。レビュー会前に対象ドキュメントをレビュアーに配布して事前チェックを行う。
   レビュアーはシナリオとチェックリストを元に事前レビューを行う。
5. レビューの指摘事項にレビューアーが深刻度をつける。軽微なものはレビュー会でとりあげずメモを渡すようにする。
   深刻度は後行程で大幅に工数がかかるものやトラブルになりそうなもの度

レビュー会

1. 事前レビューでみつかった指摘事項のうち、深刻度の高いものから取り上げて議論する。
2. 誤字脱字系や記票ルール系の間違いはレビュー会でとりあげない。(メモを書いて渡す。)
3. グランドルールとして以下のルールを守ってもらう。
   • 個人攻撃をしない。あくまでも視点はドキュメントに絞る。
   • 議論が脱線したら、内容を新たな課題としてホワイトボードに記録して別の会議を設けることで本題に戻す。
4. レビューで指摘した事項は指摘者が責任をもって解決するまでフォローする。

プロジェクト完了後の見直し

プロジェクトの完了時にテスト工程や稼働後に発生した不具合を洗い出して「見逃し問題リスト」を作成する。

※1　見逃し問題リスト　問題の混入工程や修正工数も付記

こちらの記事も合わせてお読みください。

JavaScript1st

ソフトウェア開発で失敗を繰り返さないためのレビュー技術 | JavaScript1st ソフトウェア開発において、レビューは品質確保においてとても重要なものです。しかしながら、実際の開発現場では疎かになってしまっていることが往々にしてあります。今一...

以上、「効率的な設計レビュー方法」でした。

【広告】