レビューで失敗しない8つのポイント：レビューがうまくいかない理由（1/4 ページ）

しっかりレビューしたはずだけど……

―― サブシステムのリーダーが参加する進捗会議でシステムテストの結果を見ながら……

統括リーダー　「サブシステムXで見つかっている欠陥は、レビューで検出されていて良さそうな欠陥が多いように見える。原田さんのところだと思うが、レビューが不十分だったのでは？」

サブシステムXのリーダー原田氏　「詳細な業務知識が必要でロジックも複雑な部分だったので、この分野に詳しい片山さんにお越しいただいてレビューしていただいたのですが……」

統括リーダー　「うーん。でもこの程度の異常系の定義漏れがあるのはレビューの質を疑うなぁ。他にもスループットをだいぶ改善すべき部分があるのも気になる」

サブシステムXのリーダー原田　「……」

―― 帰宅途中の電車でレビューを振り返る原田

サブシステムXのリーダー原田　（そう言えば、片山さんはかなり忙しそうでレビュー会議で詳細設計書を初めて見る感じだった。目に付きやすい表記揺れの指摘をしていたような気がする。

　片山さんとソリの合わない高原さんと些細な内容で長時間言い争っていて仲裁に苦労したんだっけか。そのせいか片山さん、高原さんの担当部分だと分かると必要以上に確認を繰り返していたような。そういうオレ自身も超多忙な片山さんのスケジュールが確保できて安心してしまって、レビュー会議中に重要な指摘をしてもらえているか、確認しなかったんだっけ。

　「有識者が参加するレビューを実施した」というエビデンスができることで必要以上に安心してしまってた。久々に参加した千原さんと同期入社の鈴木さんも同じレビュー会議に参加していて、楽しそうに昔話をしていた。レビューの後半は時間不足になってドキュメントの終盤はざっと見るだけで終わってたな。あらためて考えると、見逃しがあっても仕方のないレビューだったのかもしれない。）

　「レビューの効果が出るかどうかは、レビューアーの知識やスキルに依存している」と考えられていることが多いにもかかわらず、有識者を呼んで準備万端なはずだったレビューの効果がそれほどでもなかったということも少なくありません。何が問題なのでしょうか？

　連載の初回である今回は、レビューから効果を得るための前提を紹介します。前提の中には気を付けさえすればすぐにできるものもあれば、準備が必要であったり、定着まで少し時間がかかったりするものもあります。すぐに結果を求めず、少しずつ改善していきましょう。2回目以降で紹介するやり方や技法を取り入れる際には、今回の前提と併せて検討します。

　本連載では、レビューを取りまとめる立場の方（リーダー）向けに、うまくいっていないレビューを改善していく方法を紹介していきます。拙著「間違いだらけの設計レビュー」では、リーダー、レビューアー、作成者（レビューイ）の3つの視点からレビューの具体的な手順を示し、レビューの方法とともに関係者が持つべきマインドを紹介しています。「レビューではどうやって欠陥や問題（※）を検出したらいいの？」という、基本的でありながら極めて重要な疑問に答えています。

※「欠陥」は「誤りや抜け」、「問題」は「欠陥にはなっていないものの欠陥の原因となる可能性が高く、修正しておいた方が良いもの」を指しています。

参考リンク：設計レビューに私情を持ち込んでいませんか？

　本連載では、今のレビューを改善したいリーダーの視点から解決策を示します。もちろん、リーダー以外の立場でレビューに参加されている方にとっても、普段と異なる視点からレビューを知ることで、改善に役立つさまざまな気付きが得られるよう解説していきます。

　では早速本論に入りましょう。今回は論点を8つのポイントに整理しています。まずはレビューの効果を得るための前提を示します。レビュー全体を通じたマインドの問題（1〜3）です。