この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第64回です。
第7章では、これまで学んだ要件定義や設計の知識を使い、 設計書・比較資料・レビュー・移行計画など、 実際のプロジェクトで必要になる成果物と進め方を学びます。
ネットワーク設計レビューの進め方｜確認観点・指摘管理・レビュー手順を実務向けに解説
設計レビューは、完成した設計書を眺めて誤字を探す作業ではありません。 要件を満たしているか、障害時に業務を継続できるか、 運用できる構成になっているかなどを複数の視点から確認し、 本番環境へ問題を持ち込むリスクを減らす工程です。 この記事では、レビューの準備から指摘管理、完了判定までを実務の流れに沿って解説します。
設計者本人が何度読み返しても、 自分で作った設計の抜けや思い込みには気づきにくいものです。
そこで重要になるのが設計レビューです。 別のエンジニアや運用担当者、セキュリティ担当者などの視点を加えることで、 設計段階で問題を発見し、本番障害や手戻りを減らします。
ただし、レビュー参加者を集めて設計書を1ページ目から読み上げるだけでは、 効果的なレビューにはなりません。 何を、誰が、どの基準で確認するのかを事前に決めることが重要です。
この記事を読み終えるとできること
- 設計レビューの目的を説明できる
- レビュー前に準備すべき資料を整理できる
- 要件・可用性・性能・セキュリティなどの観点で確認できる
- レビュー会議を効率よく進行できる
- 指摘事項を重要度別に管理できる
- レビュー完了の条件を定義できる
設計レビューとは何か
設計レビューとは、作成した設計が要件を満たし、 技術的・運用的に実現可能であることを、 複数の関係者が確認する工程です。
ネットワーク設計では、 IPアドレス、VLAN、ルーティング、冗長化、セキュリティ、 監視、ログ、運用、移行など、多数の要素が相互に関係します。
そのため、各項目だけを個別に確認して正常でも、 組み合わせたときに問題が発生することがあります。
たとえば、次のようなケースです。
- 冗長構成にしたが、2台が同じ電源系統へ接続されている
- バックアップ回線はあるが、正常時と同じ経路広告ができない
- ファイアウォールで通信を制限した結果、監視通信まで遮断される
- 新しいIPアドレス体系が既存拠点と重複している
- 障害時の切り替えはできるが、運用担当者が確認する方法が決まっていない
レビューの目的は、設計者を評価することではありません。
本番環境へ問題を持ち込む前に、 チームとして設計上のリスクを発見し、品質を高めることが目的です。
なぜ設計レビューが必要なのか
要件とのズレを発見する
技術的に正しい設計でも、 顧客要件を満たしていなければ適切な設計とはいえません。 レビューでは要件と設計の対応を確認します。
設計者の思い込みを減らす
設計者本人には当たり前に見える前提条件でも、 他の人が確認すると不足していることがあります。
障害リスクを事前に減らす
単一障害点、経路の非対称性、ループ、 セキュリティ制御漏れなどを構築前に発見できます。
運用できる設計か確認する
技術的に動くだけでなく、 監視・ログ確認・設定変更・障害対応まで実施できる構成か確認します。
後工程の手戻りを減らす
構築後や試験時に設計ミスが判明すると、 設定変更だけでなく設計書・試験項目・手順書まで修正が必要になります。
設計理由を共有する
なぜその方式を選択したのかを共有することで、 構築担当者や運用担当者も設計意図を理解できます。
設計レビューは品質確認であると同時に、知識共有の場でもあります。
設計理由や制約条件をチームで共有しておくと、 構築・試験・運用へ移った後の認識違いを減らせます。
設計レビューの全体像
設計レビューは、レビュー会議だけを指すものではありません。 実務では、事前準備から指摘対応、再確認までを含めて管理します。
DESIGN REVIEW FLOW｜設計レビューの基本フロー
特に重要なのは、レビュー会議までに資料を読んでもらうことです。
会議の時間を設計書の読み合わせだけに使うのではなく、 判断が必要な部分や、意見が分かれる部分について議論できる状態にしておきます。
レビュー前に準備するもの
レビューの品質は、会議当日よりも事前準備で大きく変わります。
1．レビュー対象を明確にする
「ネットワーク設計をレビューしてください」だけでは範囲が広すぎます。
たとえば、次のように対象を明確にします。
- 基本設計書 Ver.1.2
- 物理構成図・論理構成図
- IPアドレス設計
- VLAN設計
- ルーティング設計
- 冗長化設計
- ファイアウォール通信要件
- 監視設計
レビュー中に設計書が更新されると、 「どの版を確認したのか」が分からなくなります。 レビュー対象のファイル名・版数・更新日を固定しましょう。
2．設計の前提資料をそろえる
設計書だけを見ても、その設計が正しいか判断できないことがあります。
- 要件定義書
- 現行ネットワーク構成図
- 顧客ヒアリング結果
- 構成案比較表
- 製品仕様・制約事項
- 既存標準・設計ガイドライン
- 課題管理表
特に重要なのが要件です。 設計は「一般的に正しいか」ではなく、 今回の要件を満たしているかという基準で確認します。
要件整理については、 第1回「ネットワーク要件定義とは何か」 も確認してください。
3．レビュー参加者を決める
| 役割 | 主な役目 |
|---|---|
| 設計者 | 設計内容・設計理由・制約条件を説明する |
| 技術レビュー担当 | 構成・設定・性能・冗長化などを確認する |
| セキュリティ担当 | 通信制御、認証、管理経路、ログなどを確認する |
| 運用担当 | 監視、障害対応、バックアップ、変更作業の実現性を確認する |
| プロジェクト責任者 | 対象範囲、コスト、スケジュール、リスクを確認する |
| 顧客・承認者 | 業務要件や前提条件との認識差がないか確認する |
すべてのレビューに全員を参加させる必要はありません。 設計内容に応じて必要な専門家を選びます。
ネットワーク設計の主なレビュー観点
「何となく設計書を読む」のではなく、 レビュー観点を決めて確認すると抜けを減らせます。
- 要件定義書の条件が設計へ反映されているか
- 要件に対する実現方式が説明できるか
- 対象外の機能を誤って含めていないか
- 未決要件を勝手に決めていないか
- 物理構成と論理構成に矛盾がないか
- 機器の役割が明確か
- 通信経路を説明できるか
- 不要に複雑な構成になっていないか
- アドレス重複がないか
- 必要なアドレス数を確保できるか
- 将来拡張分を考慮しているか
- VLANの分割方針が要件と一致しているか
- 正常時の経路が意図どおりか
- 障害時の代替経路が存在するか
- 経路ループの可能性がないか
- 経路集約やデフォルトルートの範囲が適切か
- 非対称通信が発生する場合の影響を確認しているか
- 単一障害点が残っていないか
- 機器だけでなく回線・電源・接続経路も確認したか
- 障害切り替え方式が明確か
- 切り替え時間が要件を満たすか
- 正常系へ戻す方法を考慮しているか
- ピーク通信量に対して十分な帯域があるか
- インターフェース速度にボトルネックがないか
- 機器性能が必要セッション数・経路数などを満たすか
- 数年後の利用者・端末・通信量増加を考慮しているか
- 不要な通信を許可していないか
- 管理通信が利用者ネットワークから分離されているか
- 認証・認可方式が適切か
- インターネット公開範囲が必要最小限か
- ログを取得できる構成か
- 死活・性能・インターフェース状態を監視できるか
- SyslogやSNMPなどの管理通信経路があるか
- 設定バックアップ方法が決まっているか
- 障害時に運用担当者が状態を確認できるか
- 定期的な証明書・ライセンス更新などを考慮しているか
- 現在の環境から移行可能な設計か
- 新旧環境の並行期間に問題がないか
- 設計内容を試験で確認できるか
- 障害試験・冗長化試験が可能か
- 切り戻しできる構成になっているか
- 構成図と設計書の内容が一致しているか
- 基本設計書と詳細設計書で矛盾していないか
- 用語や機器名が統一されているか
- 前提条件や制約条件が記載されているか
- 設計理由を第三者が理解できるか
レビューでは「設定値が正しいか」だけを見ないことが重要です。
要件、正常時、障害時、運用時、移行時という複数の場面を想定して確認します。
レビュー会議の進め方
レビュー会議では、 設計書を最初から最後まで読み上げるのではなく、 判断や議論が必要な部分へ時間を使います。
- レビューの目的と対象を確認する 今回確認する資料・版数・範囲と、今回対象外の範囲を最初に共有します。
- 要件と設計方針を確認する 「何を実現するための設計なのか」を共有し、 個別技術の議論だけにならないようにします。
- 全体構成を先に説明する 物理構成図や論理構成図を使って、 機器の役割・主要通信・冗長化方針を説明します。
- 重要な設計判断を説明する 複数方式から選択した項目、 制約条件がある項目、リスクが残る項目を重点的に説明します。
- レビュー指摘を確認する 事前に出された指摘を順番に確認し、 修正・回答・保留・課題化などの処置を決めます。
- 未決事項と担当者を決める 会議中に結論が出ないものは、 担当者と期限を設定します。
- 次のアクションを確認する 修正版の提出日、再レビューの要否、 次工程へ進める条件を共有して終了します。
レビュー冒頭で説明する内容
本日は基本設計書Ver.1.2のレビューを行います。 今回の対象はLAN、WAN、ルーティング、冗長化、監視設計です。
ファイアウォールポリシーの個別ルールと機器ごとのCLIパラメータは 詳細設計レビューで確認するため、今回は対象外とします。
特に確認いただきたい点は、 回線障害時の経路切り替え方式と、 既存ネットワークとの接続方法です。
指摘事項の管理方法
レビューで出た指摘を口頭だけで終わらせてはいけません。
指摘管理表へ記録し、 誰が・いつまでに・何をするのかを明確にします。
指摘管理表の例
| No. | 重要度 | 対象 | 指摘内容 | 対応 | 担当 | 期限 | 状態 |
|---|---|---|---|---|---|---|---|
| 01 | Critical | 冗長化 | 上位SWが単一障害点になっている | 構成変更を検討 | 設計担当A | 8/20 | 対応中 |
| 02 | Major | 監視 | バックアップ回線の監視方法が未記載 | 監視項目を追記 | 設計担当B | 8/20 | 未対応 |
| 03 | Minor | 構成図 | インターフェース名の表記が一部不統一 | 表記修正 | 設計担当A | 8/21 | 未対応 |
| 04 | Question | WAN | 回線事業者側のBGP仕様を確認したい | 回線事業者へ確認 | PM | 8/19 | 確認中 |
重要度を分ける
| 分類 | 考え方 | 例 |
|---|---|---|
| Critical | 要件未達、本番障害、重大なセキュリティ問題につながる | 冗長化要件があるのに単一障害点が残っている |
| Major | 設計品質や運用へ大きく影響するため修正が必要 | 障害監視方法が設計されていない |
| Minor | 基本動作には影響しないが修正した方がよい | 図と本文で機器名称が異なる |
| Question | 設計意図や前提条件を確認したい | この経路を優先している理由を確認したい |
重要度を付ける目的は、 指摘した人の意見の強さを示すことではありません。
プロジェクトへの影響度と、対応優先順位を明確にすること が目的です。
レビュー完了条件を決める
「会議が終わったからレビュー完了」ではありません。
レビューで見つかった指摘について、 必要な対応が完了したことを確認して初めてクローズします。
レビュー完了チェックリスト
- レビュー対象となる設計書をすべて確認した
- Critical指摘がすべて解消されている
- Major指摘について修正または対応方針が決定している
- 未決事項に担当者と期限が設定されている
- 要件と設計の対応関係を確認した
- 構成図と設計書の内容が一致している
- 修正版の版数が更新されている
- 必要な承認者がレビュー結果を確認している
- 次工程へ引き継ぐ課題が明確になっている
期限までに解消できない指摘を、 何となく「対応不要」として閉じてはいけません。
残存リスクとして受け入れる場合は、 なぜ受け入れるのか、誰が承認したのかを記録します。
設計レビューでよくある失敗
1．会議で初めて資料を読む
その場でページを読み始めると、 内容確認だけで時間を使い切ってしまいます。 事前配布し、コメントを集めておきます。
2．細かい表記だけを見る
誤字やフォントの違いばかり確認し、 要件未達や単一障害点など重大な問題を見落とさないようにします。
3．一般論だけで指摘する
「普通は二重化します」ではなく、 今回の要件・制約・障害影響を根拠に判断します。
4．指摘者の好みを押し付ける
方法が自分の好みと違うだけで、 要件を満たしている設計を否定しないよう注意します。
5．指摘を記録しない
口頭指摘だけでは対応漏れが発生します。 管理番号、担当、期限、状態を記録します。
6．設計者だけで完結する
運用・セキュリティなど、 実際に設計の影響を受ける担当者の視点も必要です。
顧客・上司への説明方法
顧客や上司へレビュー結果を説明するときは、 指摘件数だけを報告しても設計品質は伝わりません。
次の4点に整理すると説明しやすくなります。
- 何をレビューしたか
- どの観点で確認したか
- 重大な問題があったか
- 残っている課題・リスクは何か
基本設計書について、 要件との整合性、冗長性、性能、セキュリティ、 運用性の観点からレビューを実施しました。
当初、上位スイッチが単一障害点になる構成となっていたため、 可用性要件を満たすよう構成を修正しています。
その他の主要指摘も修正版へ反映済みです。 現在残っているのは回線事業者への仕様確認1件で、 回答期限を設定して管理しています。
「指摘が20件ありました」だけでは品質は判断できません。
重要なのは件数よりも、 重大なリスクを発見し、必要な修正や意思決定が行われたかです。
設計レビューで使う英語表現
海外ベンダーやグローバルチームとのプロジェクトでは、 設計レビューでも次のような表現が使われます。
| 英語 | 意味・使い方 |
|---|---|
| Design review | 設計レビュー |
| Review comment | レビュー指摘・コメント |
| Design rationale | 設計理由・その方式を採用した根拠 |
| Single point of failure | 単一障害点 |
| Requirement traceability | 要件と設計・試験などを追跡できること |
| Open item | 未決事項・対応中の項目 |
| Action item | 担当者が実施すべき対応事項 |
| Risk acceptance | 残存リスクを理解した上で受け入れること |
| Could you clarify the design rationale? | この設計を採用した理由を説明していただけますか。 |
| Please confirm whether this meets the availability requirement. | この構成が可用性要件を満たしているか確認してください。 |
| This may become a single point of failure. | ここが単一障害点になる可能性があります。 |
理解度チェック
設計レビューについて理解できたか、 次の5問で確認してみましょう。
問題1．設計レビューの最も重要な目的はどれですか。
- 設計者の技術力を評価する
- 設計書の文字数を減らす
- 設計上の問題やリスクを本番導入前に発見する
- レビュー参加人数を増やす
解答を見る
設計レビューの目的は、 要件未達や技術的問題、運用上の問題などを事前に発見し、 本番環境へ問題を持ち込む可能性を減らすことです。
問題2．ルーターを2台にしていても、 2台が同じ1台の上位スイッチへ接続されている場合、 主に確認すべきものは何ですか。
解答を見る
上位スイッチが停止すると2台のルーターが同時に外部通信できなくなる場合、 機器台数だけは冗長でもシステム全体では冗長になっていません。
問題3．レビュー指摘を 「事実・懸念・影響・提案」に分けるメリットは何ですか。
解答を見る
なぜ問題なのか、何に影響するのか、 何を確認・修正すべきかが明確になるためです。 設計者個人への批判ではなく、 設計内容について客観的に議論しやすくなります。
問題4．レビュー会議で設計書を1ページ目から読み上げる方法が 効率的でない理由を説明してください。
解答を見る
会議時間の多くを内容確認に使ってしまい、 本来議論すべき設計判断、リスク、 未決事項などに十分な時間を使えなくなるためです。 設計書は事前配布し、レビュー会議では重要論点を中心に確認します。
問題5．Critical指摘が未解決のままレビューを完了してよいですか。
解答を見る
Criticalは要件未達や重大障害につながる重要な指摘です。 修正するか、やむを得ず残す場合には、 リスク・理由・影響を明確にして適切な承認を得る必要があります。
実践演習：ネットワーク設計をレビューしてみよう
あなたは、新拠点ネットワークの設計レビュー担当者です。
顧客要件
- 拠点内には約150台の端末を設置する
- インターネット障害時も業務を継続したい
- 管理用通信は一般利用者から分離する
- ネットワーク障害を監視システムで検知する
- 将来200台程度まで端末が増える可能性がある
設計案
レビュー対象構成
追加情報は次のとおりです。
- 管理端末もUser VLANへ接続する
- Router-AとCore-SWのSNMP監視を設定する予定
- 監視サーバーの配置先は未決定
- User VLANは192.168.10.0/24を使用する
課題1．レビュー指摘を3件以上挙げる
解答例を見る
- インターネット回線が1本しかなく、 回線障害時も業務継続するという要件を満たしていない可能性がある
- Router-Aが1台のため、ルーター障害時にインターネット通信が停止する
- Core-SWが1台のため、拠点LANの単一障害点となっている
- 管理端末がUser VLANへ接続されており、 管理通信を一般利用者から分離する要件を満たしていない
- 監視サーバーの配置先と監視通信経路が未決定で、 実際にSNMP監視できるか確認できない
課題2．最も重要な指摘を1つ選ぶ
あなたが最優先で確認すべきだと考える指摘を1つ選び、 その理由を書いてください。
理由：＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
例として、 「インターネット回線が1本しかない」点は Critical相当として扱うことが考えられます。
顧客要件に「インターネット障害時も業務継続」と明記されているため、 単に改善した方がよいという問題ではなく、 要件未達につながる可能性があるからです。
課題3．レビューコメントを書く
「Router-Aが1台しかない」という問題について、 事実・懸念・影響・提案の4項目でレビューコメントを作成してください。
懸念：
影響：
提案：
解答例を見る
事実：インターネット接続用ルーターがRouter-Aの1台構成です。
懸念： Router-Aの機器障害やメンテナンス時に、 インターネット通信が停止します。
影響： 「インターネット障害時も業務を継続する」という 可用性要件を満たせない可能性があります。
提案： 回線だけでなくルーターについても冗長化要否を確認し、 障害時の切り替え方式を設計してください。
自分の言葉で説明する課題
後輩から 「設計者が自分でチェックすれば、レビューは不要ではないですか？」 と質問されました。 1分程度で説明してください。
説明例を見る
設計者自身のセルフチェックは必要ですが、 自分で決めた前提や思い込みには気づきにくいことがあります。
また、ネットワーク設計は技術だけでなく、 セキュリティ、運用、移行など複数の視点で確認する必要があります。 そのため、別の担当者が要件や障害時の動作まで確認することで、 本番導入前にリスクを発見しやすくなります。
まとめ
- 設計レビューは、設計が要件を満たし、 技術的・運用的に実現可能かを複数の関係者で確認する工程
- レビュー会議だけでなく、 計画・事前確認・指摘対応・クローズまで含めて管理する
- レビュー対象となる設計書の版数・対象範囲を事前に固定する
- 要件、構成、IP、ルーティング、可用性、性能、 セキュリティ、運用、移行など複数の観点で確認する
- 指摘は「事実・懸念・影響・提案」に分けると伝わりやすい
- 指摘事項には重要度、担当者、期限、状態を設定する
- 会議終了ではなく、必要な指摘対応を確認してレビューを完了する
良い設計レビューとは、設計者の間違いを探す場ではありません。 要件・技術・運用・リスクを複数の視点から確認し、 チームとして「なぜこの設計でよいのか」を説明できる状態にする工程です。
第7章では、設計書の作成だけでなく、 構成案比較、設計レビュー、移行・切り戻し計画、 顧客説明、大規模障害分析まで、 設計・提案業務を実践形式で学びます。
良い指摘の伝え方
レビューでは、指摘内容だけでなく伝え方も重要です。
「この設計は間違っています」とだけ伝えても、 設計者は何を直せばよいか判断できません。
指摘は4つに分けて伝える
避けたい指摘
「これだと冗長化になっていません。」
理由や影響範囲が分からず、 何を変更する必要があるか判断しにくい指摘です。
良い指摘
「2台のルーターが同一スイッチへ収容されているため、 スイッチ障害が単一障害点になります。 可用性要件との整合性を確認してください。」
人ではなく設計内容をレビューします。
「なぜこんな設計にしたのですか」ではなく、 「この構成を選択した理由を確認させてください」のように、 設計判断を確認する表現を使います。