レビュー631回1件ICTソフトウェア開発で設計レビューをしているが、やり方が人それぞれバラバラで効果がよくわからない。いうことはないだろうか。時間をかけてレビュー会をやっているのに形式だけになっているのならば、戦略的なレビューを実施することで、効果のあるレビューにしたい。プロジェクト完了後の見直しレビューの目的とは工程の漏れや間違いを見つけ、後工程での修正コストを少なくすること。以上つまり誤字脱字系の軽微な間違いは後で直してもたいしたコストはかからないが、設計の漏れや間違いは後工程になればなるほど修正コストが増大する。最終的にリリースした製品に発生した不具合は修正コストもさることながら損害賠償問題にまで発展すれば経営にインパクトを及ぼすような膨大なコストとなる。事前準備プロジェクトリーダーが「見逃し問題リスト※1」から、過去の類似案件の指摘事項や、レビューをすり抜けてテストや本番で大きな手戻りが発生した内容を洗い出して、今回のレビューで使用するチェックリストを作成する。プロジェクトリーダーがレビューでどんな問題種別を検出すべきかを考え、その要点をまとめたシナリオをいくつか作成する。上記の問題種別について、どの部分をどういった観点からレビューするのかがわかるようにシナリオを作成する。例:「アイテムアクセスのセキュリティの機能に漏れがないかどうかを調べるために、アイテムのセキュリティに関連する設計をチェックする。クライアント側でのセキュリティチェックをすりぬけたデータがあっても、サーバー側で正しくチェックされていることを確認する。例:「各機能間で受け渡しされるデータに不整合がないかどうかを調べるために、CRUD図をチェックする。入力はされていないのに、読み込みされているデータや、入力のみで読み込まれないデータが無いことをチェックする。レビュアーは今回のプロジェクトの分野に詳しいか、レビューのスキルが高いメンバーを割り当てて、上記で作成したシナリオをそれぞれに割り当てます。一人のレビュアーには2~3個のシナリオを割り当てます。することでレビュアーはそれぞれが違った箇所を精査することができます。ドキュメントの事前レビューを行う。レビュー会前に対象ドキュメントをレビュアーに配布して事前チェックを行う。レビュアーはシナリオとチェックリストを元に事前レビューを行う。レビューの指摘事項にレビューアーが深刻度をつける。軽微なものはレビュー会でとりあげずメモを渡すようにする。事前レビューでみつかった指摘事項のうち、深刻度の高いものから取り上げて議論する。誤字脱字系や記票ルール系の間違いはレビュー会でとりあげない。)グランドルールとして以下のルールを守ってもらう。視点はドキュメントに絞る。議論が脱線したら、内容を新たな課題としてホワイトボードに記録して別の会議を設けることで本題に戻す。レビューで指摘した事項は指摘者が責任をもって解決するまでフォローする。プロジェクト完了後の見直しプロジェクトの完了時にテスト工程や稼働後に発生した不具合を洗い出して「見逃し問題リスト」を作成する。属性の異なる同意フィールド(商品番号)がありエラーとなった。属性を同じに合わせ、修正後に単体試験からやり直した。登録画面で参照するマスターの設定画面が無かった。要求仕様書からやり直した。項目の桁数が多く画面からはみ出した。項目の配置を変更した。3Hこちらの記事も合わせてお読みください。設計レビュー方法」でした。PMP試験を受験して、2回目で合格しました。