設計レビューで手戻りを減らすために見るべき観点

設計レビューは間違い探しではなく前提合わせ

設計レビューというと、記載漏れや表記ゆれを探す場だと思われがちです。もちろん細部の確認も必要ですが、個人的には設計レビューの本質は、関係者の前提をそろえることだと考えています。

設計書は、開発者だけが読むものではありません。テスト担当者、運用担当者、プロジェクトマネージャー、場合によっては業務側の関係者も、設計内容をもとに次の判断をします。だからこそ、レビューでは「書いてあるか」だけでなく「この内容で後続工程が迷わないか」を見る必要があります。

レビューで見る観点を事前に共有しておくと、指摘が属人的になりにくくなります。特に上流工程では、レビューの質がそのまま後続工程の迷いの少なさにつながると思います。

設計レビューでいきなり文言やレイアウトから見ると、重要な論点を見落とすことがあります。私は、まず全体構造を確認し、その後に詳細を見る方がよいと考えています。

この順番で見ると、表面的な指摘だけでレビューが終わることを避けやすくなります。特に責務の境界が曖昧なままだと、実装時に「これはどちらで対応するのか」という確認が何度も発生します。

レビューでよくあるのが、指摘は出たものの、結局どう直すのかが曖昧なまま残るケースです。指摘は多ければよいわけではありません。大切なのは次に何をすればよいか分かる状態で残すことです。

この4点が整理されていると、レビュー後の対応が進めやすくなります。単に「要確認」と書くだけでは、確認する人も判断する人も迷ってしまいます。

設計レビューでは、指摘の数よりも、判断が進む指摘になっているかを意識したいと考えています。

設計レビューで手戻りを減らすには、誤字や記載漏れの確認だけでなく、要件とのつながり、責務の境界、例外時の振る舞い、運用面まで含めて確認することが重要です。

個人的には、設計レビューは設計書をきれいにする作業ではなく、後続工程の人たちが迷わず作業できる状態を作るための活動だと思っています。