設計書レビューで一番怖いのは「見てるつもり」
通信要件のレビューにおいて、「通信元・通信先・ポートが必要最低限になっているか」を確認するのは基本的な観点です。
通信要件のレビューをする際、この観点がテンプレートのようになっています。
ただ、この観点――どんな変更にもそのまま当てはめていいのか？という事例がありました。
あるレビューのすれ違い
通信要件の設計変更で、
「あるサーバからあるサーバへの通信をブロックする」という変更のレビュー依頼がありました。
そのレビューを担当した人は、次のように判断していました。
通信元・通信先・ポートが必要最低限になっているためOK
一見、正しそうに見えます。
ですが、この判断には重要な前提の抜けがありました。
何が問題だったのか
今回の変更は「通信を許可する」のではなく、「通信をブロックする」変更だったのです。
つまり本来見るべきなのは、
- 本当にブロックして問題ない通信なのか
- 業務影響はないのか
- 想定外の通信まで巻き込んでいないか
といった観点です。
しかしレビューでは、「許可ルールの最小化」といういつものテンプレートが適用されてしまっていました。
レビューは“チェックリスト”ではない
この事例の本質はシンプルです。
レビュー観点は固定ではなく、変更の文脈によって変わるということです。
- 許可（Allow）を追加する場合
→ 不要な通信が開いていないか（最小化） - 許可を削除・ブロック（Deny）する場合
→ 必要な通信まで止めていないか（影響範囲）
同じ「通信設定のレビュー」でも、
見るべきポイントは真逆になります。
「設計書が読める」とはどういうことか
設計書レビューで重要なのは、
単にパラメータを確認することではありません。
- この変更は何をしたいのか
- なぜこの変更が必要なのか
- どんなリスクがあるのか
といった意図や文脈を読み取ることです。
これができて初めて、適切なレビュー観点を選ぶことができます。
まとめ
- レビュー観点はチェックリストとして固定化してはいけない
- 同じ項目でも「許可」と「ブロック」で見るべきポイントは変わる
- 設計書レビューで重要なのは“意図を読む力”