システムの設計ミスをなくし、上流工程で品質を作り込む上で、設計レビューは大きな役割を果たす。しかし、システム開発のレビューを研究テーマの一つとしている、奈良先端科学技術大学院大学の森崎修司氏（情報科学研究科 ソフトウェア工学講座 助教）は、「設計レビューをうまく実施している開発現場は、全体の3割ほど。多くの現場では、レビューが思うように機能していない」と指摘する。
実際、日経SYSTEMS 3月号の「設計ミスをなくそう――現場を救うレビューの秘訣」という特集で、開発現場を取材したところ、二つの典型的な設計レビューの失敗パターンが浮かび上がった。
欠陥検出件数を満たすだけの“儀式”
一つめは、レビューの「形骸化」あるいは「儀式化」である。これは、レビュー会議が次の工程に進むための形式的な“儀式”と化し、「今さら欠陥をたくさん検出しても修正している時間がない」「次の工程に進むことが先決だ」という暗黙の了解のもとでレビューが甘くなる、というものだ。
レビュー会議とは名ばかりで、もっぱら設計担当者がレビューアやほかのメンバーに設計内容を説明するだけ。レビューアは、重大な欠陥があるかもしれないと薄々気付いても、あえてそこには触れない。
ただし、設計書1ページ当たりの欠陥検出件数のような、「ちゃんとレビューを行ったかどうかを検証する指標と基準値」が設定されていたりする。このためレビューアは、修正が比較的容易な、誤字・脱字や書式の間違いなどの軽微な欠陥を指摘していく。そうすることで基準値をクリアし、レビュー会議を成立させる。
ダメ出しの連発で雰囲気が悪化
二つめは、いわばレビューの「空回り」である。レビュー会議の回数や時間、参加者を増やし、従来より力を入れている現場によく見られる失敗パターンだ。空回りは次のようにして起こる。
レビュー会議にはプロジェクト・チーム外の優秀なエンジニアも招へいされ、長時間にわたって行われる。「設計ミスを完全になくそう」と意気込むレビューアは、次々と欠陥を指摘する。だが、その多くは誤字・脱字や書式の間違いなど軽微なものばかり。重箱の隅をつつくような指摘に、レビュー会議の雰囲気は次第に悪くなる。
そうして、レビューを受ける設計担当者が欠陥の指摘に反発し、ケンカごしの議論やなじり合いに発展する。もしくは、設計担当者が何人ものレビューアから一方的に責められ、一種のサンドバッグ状態に陥る。
ひどいケースになると、延々とダメ出しをされ続けた設計担当者が、「どうすれば許してもらえるのでしょうか。言われたとおりに修正しますから、すべて指摘してください」と全面的に屈服した心理状態に陥るという。
軽微な欠陥の検出に終始するのは本末転倒
やや極端なケースを挙げたが、あなたの現場のレビュー会議は、これらに近い状態に陥っていないだろうか。
これら二つの失敗パターンのどちらも、誤字・脱字や書式の間違いといった軽微な欠陥はある程度検出されるが、肝心の重大な欠陥は見逃されやすい。当然ながら、設計レビューの最大の目的は、重大な欠陥をつぶすこと。軽微な欠陥の検出に終始するのは、本末転倒である。
では、なぜこうしたレビューになってしまうのか。最大の原因は、「何のためにレビューをするのか」という目的を取り違えていることだろう。
レビューが形骸化している現場では「事を荒立てず次の工程に進む」ことが目的になり、空回りしている現場では「あらゆる欠陥をすべて取り除く」ことが目的になっている場合が多い。
前者の目的のもとでは、簡単には修正できない重大な欠陥を下手に指摘すると次の工程に進めなくなりかねないので、軽微な欠陥に目が向いてしまう。後者の目的は、言い換えると「重大な欠陥だけでなく軽微な欠陥もすべて取り除く」となる。この目的でレビューを行えば、どうしても、見つけやすい軽微な欠陥の検出に偏ってしまう。
「重大な欠陥を取り除く」という目的を再確認しよう
上記の失敗パターンに陥ることなくレビューを機能させるため、取材したいくつかの開発現場が行っていたことがある。それは、レビュー会議の冒頭で「重大な欠陥を取り除く」という本来の目的を再確認することだ。
その際、「レビュー会議を成立させるために検出欠陥数を増やそうと考えるのはやめよう」「誤字・脱字や書式の間違いなどの軽微な欠陥については、会議が終わった後で、個条書きにして設計担当者にメールを送ろう」といった宣言をすることも有効だという。
レビューは本来、開発現場が後工程で苦労しないために行うもの。いわば、自分たちを救う活動である。空回りや形骸化を防いで、設計ミスをなくしてほしい。
