この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第63回です。
第7章では、これまで学んだ要件定義・基本設計・クラウド・ セキュリティなどの知識を使い、 設計内容を成果物として整理し、比較・レビュー・提案する方法 を学びます。
構成案を比較する評価表の作り方｜ネットワーク設計の選定理由を点数化する
ネットワーク設計では、 「技術的に実現できる構成」が1つだけとは限りません。 回線方式、冗長化方式、クラウド接続、ファイアウォール構成などについて 複数案を作り、可用性・性能・セキュリティ・運用性・コストなどを比較しながら、 最も要件に適した方式を選ぶ必要があります。 この記事では、その判断を見える化する「構成案比較表」の作り方を解説します。
設計経験が浅いと、 「一般的によく使われているから」 「以前の案件でもこの構成だったから」 といった理由で構成を決めてしまいがちです。
しかし、実務で求められるのは 「今回の要件に対して、なぜこの構成が最も適しているのか」 を説明できることです。
その説明を助ける成果物が、 構成案比較表・方式比較表・評価マトリクスです。
この記事を読み終えるとできること
- 構成案比較表の目的を説明できる
- 比較に必要な評価軸を決められる
- 必須条件と評価項目を区別できる
- 評価項目に重みを付けられる
- 5段階評価で複数案を点数化できる
- 加重スコアから構成案を比較できる
- 点数だけに依存しない選定ができる
- 選定理由を顧客や上司へ説明できる
構成案を比較する評価表とは
構成案比較表とは、複数のネットワーク構成案を 共通の評価基準で比較し、 採用する方式とその理由を明確にするための資料です。
ネットワークを設計するとき、 要件を満たす方法が1つしかないとは限りません。
たとえば、本社と支店を接続する方法だけでも、 案件によっては次のような候補が考えられます。
- インターネットVPN
- 閉域網
- 専用線
- SD-WAN
- 複数方式を組み合わせた冗長構成
どれも通信を実現するという目的は同じですが、 可用性、性能、セキュリティ、費用、運用負荷などは異なります。
構成案比較表は、「どの方式が一番優れているか」を決める表ではありません。
「今回の要件・制約に対して、どの方式が最も適しているか」を 判断するための表です。
なぜ構成案の評価表が必要なのか
設計判断を客観化できる
「何となく良さそう」という感覚ではなく、 共通の基準で複数案を比較できます。
要件との関係を説明できる
可用性を重視したのか、コストを重視したのかなど、 設計判断と顧客要件を結び付けられます。
関係者の認識を合わせられる
技術担当者、顧客、営業、運用担当者などが 同じ材料を見ながら議論できます。
トレードオフを見える化できる
可用性を高めればコストが増えるなど、 何を得る代わりに何を負担するのかを整理できます。
レビューしやすくなる
評価基準と根拠が残っていれば、 他のエンジニアが判断内容を確認できます。
後から選定理由を追跡できる
数年後に「なぜこの方式を採用したのか」を 確認するときの記録にもなります。
構成案を決めるまでの流れ
構成案比較は、いきなり点数を付けるところから始めません。
- 要件と制約条件を確認する 可用性、性能、セキュリティ、予算、納期、 運用体制などを確認します。
- 比較する構成案を作る 最初から1案だけに決めず、 現実的に採用可能な複数案を作成します。
- 必須条件を満たしているか確認する 絶対に満たす必要がある条件に違反する案を除外します。
- 評価項目と重みを決める 今回の案件で何を重視するのかを明確にします。
- 各構成案を評価する 共通ルールを使って1〜5点などで評価します。
- 評価理由とリスクを書く 数字だけでなく、点数を付けた根拠を残します。
- 推奨案を決める 合計点だけではなく、リスク・制約・未決事項も含めて判断します。
ネットワーク構成案で使う代表的な評価項目
評価項目は案件ごとに変わりますが、 ネットワーク設計では次のような視点がよく使われます。
| 評価項目 | 確認する内容 |
|---|---|
| 可用性 | 機器・回線障害時にも通信を継続できるか |
| 性能 | 帯域、遅延、パケットロスなどの要求を満たせるか |
| セキュリティ | 暗号化、認証、通信制御、分離などを実現できるか |
| 運用性 | 監視、障害対応、設定変更、バックアップを行いやすいか |
| 保守性 | 故障交換、ベンダーサポート、保守対応を行いやすいか |
| 拡張性 | 拠点・利用者・通信量・クラウド利用が増えても対応できるか |
| 移行性 | 既存環境から安全に移行できるか |
| 構築難易度 | 設計・構築・試験の難易度や必要スキルは適切か |
| コスト | 初期費用だけでなく、回線費・保守費・運用費を含めて妥当か |
| 納期 | 必要な機器・回線をサービス開始日までに準備できるか |
| 製品・ベンダー依存 | 特定製品やベンダーへの依存が将来の制約にならないか |
評価項目を増やしすぎると、 重要な判断基準が分かりにくくなります。
案件に影響する重要項目へ絞り、 必要に応じて細分化するのが基本です。
必須条件と評価項目を分ける
評価表を作るときに重要なのが、 絶対に満たさなければならない条件と 満たし方の優劣を比較する項目を分けることです。
必須条件の例
- 通信を暗号化すること
- 単一回線障害時も重要業務を継続できること
- 既存のIPアドレス体系を維持すること
- 指定されたサービス開始日に間に合うこと
- 社内セキュリティ基準へ準拠すること
| 必須条件 | 案A | 案B | 案C |
|---|---|---|---|
| 通信暗号化 | ○ | ○ | ○ |
| 回線障害時の通信継続 | ○ | ○ | ○ |
| 3か月以内に導入 | ○ | × | ○ |
必須条件を満たさない案を、他の項目の高得点で補ってはいけません。
たとえば「納期までに導入できない」という重大な条件違反を、 「性能が高い」「価格が安い」といった得点で相殺するのは適切ではありません。
5段階評価のルールを決める
採用候補になった構成案について、 評価項目ごとに点数を付けます。
ただし、 「案Aは何となく5点、案Bは3点」 と決めてはいけません。
最初に採点ルールを統一します。
| 点数 | 評価 | 考え方 |
|---|---|---|
| 5 | 非常に優れている | 要件を十分に満たし、追加メリットもある |
| 4 | 優れている | 要件を問題なく満たす |
| 3 | 標準 | 要件をおおむね満たすが、条件や注意点がある |
| 2 | 劣る | 要件を満たすために大きな制約や追加対応が必要 |
| 1 | 非常に劣る | 採用可能ではあるが、大きなデメリットがある |
できるだけ評価基準を具体化する
特に重要な項目では、 項目ごとに具体的な評価基準を作ると判断が安定します。
| 可用性の点数例 | 判定例 |
|---|---|
| 5点 | 機器・回線の主要障害に対して自動切り替えが可能 |
| 4点 | 主要箇所を冗長化し、短時間で自動復旧できる |
| 3点 | 一部冗長化されているが、単一障害点が残る |
| 2点 | 障害時の復旧に手動作業が必要 |
| 1点 | 主要箇所が単一構成で、停止影響が大きい |
評価項目へ重み付けする
すべての評価項目が同じ重要度とは限りません。
たとえば、24時間365日稼働する業務ネットワークであれば、 初期費用より可用性を重視する可能性があります。
一方、小規模な一時利用ネットワークでは、 コストや短納期の方が重要になることもあります。
重み付けの例
| 評価項目 | 重み | 理由 |
|---|---|---|
| 可用性 | 25% | 障害時も業務継続が必要 |
| 性能 | 15% | 業務システムの通信品質が重要 |
| セキュリティ | 15% | 拠点間通信を安全に行う必要がある |
| 運用性 | 15% | 少人数の運用チームで管理する |
| コスト | 15% | 予算上限がある |
| 移行性 | 10% | 停止時間を抑えて移行したい |
| 拡張性 | 5% | 将来的な拠点追加を想定 |
| 合計 | 100% | － |
評価点 × 重み
たとえば、可用性の重みが25％で、 構成案Aの可用性評価が4点なら、 可用性から得られる加重値は次のように考えます。
4 × 25 ＝ 100
全項目を計算し、最後に100で割ると 5点満点の総合評価として扱えます。
実例：3つの拠点間ネットワーク構成を比較する
本社と複数拠点を接続する案件を想定します。
構成案
案A：インターネットVPN
異なるインターネット回線を2回線利用し、 IPsec VPNで拠点間を接続します。
案B：閉域網＋バックアップVPN
主回線に閉域網を利用し、 障害時はインターネットVPNへ切り替えます。
案C：SD-WAN
複数回線をSD-WANで統合し、 回線状態に応じた経路制御を行います。
評価結果
| 評価項目 | 重み | 案A | 案B | 案C |
|---|---|---|---|---|
| 可用性 | 25% | 4 | 5 | 5 |
| 性能 | 15% | 3 | 5 | 4 |
| セキュリティ | 15% | 4 | 5 | 4 |
| 運用性 | 15% | 3 | 3 | 4 |
| コスト | 15% | 5 | 2 | 3 |
| 移行性 | 10% | 4 | 2 | 3 |
| 拡張性 | 5% | 3 | 3 | 5 |
| 総合評価 | 100% | 3.80 | 3.85 | 4.05 |
この結果をどう読むか
単純な総合点では、 案CのSD-WAN構成が4.05点で最も高くなりました。
しかし、 「4.05点だから案Cで決定」ではありません。
次の点も確認する必要があります。
- 運用担当者がSD-WANを管理できるか
- 製品ライセンス費用を許容できるか
- 既存ネットワークとの接続に問題がないか
- 導入スケジュールに間に合うか
- ベンダーや製品への依存を許容できるか
評価点は意思決定を支援する材料です。
設計者の代わりに自動的に答えを出してくれるものではありません。
点数と一緒に評価理由を残す
実務では、点数だけを記載した比較表は十分ではありません。
数か月後に表を見ても、 「なぜ案Aの可用性が4点なのか」が分からないからです。
評価理由を追加した例
| 項目 | 案A | 評価理由 |
|---|---|---|
| 可用性 | 4点 | 異キャリア2回線で冗長化可能。 ただしインターネット網を利用するため、 通信品質を完全には保証できない。 |
| 性能 | 3点 | 必要帯域は確保可能だが、 インターネット混雑の影響を受ける可能性がある。 |
| コスト | 5点 | 専用サービスと比較して回線費用を抑えやすく、 既存VPN機器を活用できる。 |
比較表には可能であれば 評価点・評価理由・根拠資料 の3つを残します。
根拠資料には、要件定義書、見積書、製品仕様書、 回線サービス仕様、検証結果などを使用します。
リスクと不確定事項も評価表に残す
比較時点ですべての情報が確定しているとは限りません。
そこで、評価表には リスク・前提条件・未確認事項 を追加すると実務で使いやすくなります。
| 構成案 | 主なリスク | 確認事項 |
|---|---|---|
| 案A | インターネット品質の影響を受ける | 拠点ごとの回線品質を確認 |
| 案B | 回線納期が長い可能性 | キャリアから正式納期を取得 |
| 案C | 運用チームにSD-WAN経験がない | 教育・運用支援の範囲を確認 |
評価点の「確度」も意識する
同じ4点でも、 実測や正式見積もりを確認して付けた4点と、 推測で付けた4点では信頼度が違います。
重要案件では、次のような列を追加する方法もあります。
- 確定
- 確認済み
- 暫定
- 要検証
- 要ベンダー確認
情報が不足しているのに、無理に点数を確定させないことが重要です。
分からない項目は「未確認」とし、 誰がいつまでに確認するのかを課題として管理します。
コストは初期費用だけで比較しない
構成案比較で特に注意したいのがコストです。
機器購入費だけで比較すると、 実際の負担を正しく判断できない場合があります。
確認したいコスト
- 機器購入費
- ライセンス費用
- 回線初期費用
- 回線月額費用
- 保守費用
- クラウド利用料
- 設計・構築費
- 移行費用
- 運用費
- 教育・トレーニング費用
- 機器更新時の費用
初期導入費が安い方式でも、 毎月のライセンス費用や運用工数が大きければ、 数年間の総コストでは高くなる可能性があります。
評価表のおすすめフォーマット
実務用の比較表では、 次の列を用意すると整理しやすくなります。
| 列 | 内容 |
|---|---|
| 評価分類 | 可用性・性能・セキュリティなど |
| 評価項目 | 具体的に比較する内容 |
| 関連要件 | どの要件を根拠にしているか |
| 必須／評価 | 必ず満たす条件か、優劣を評価する項目か |
| 重み | 今回の案件における重要度 |
| 案A評価 | 点数または○△× |
| 案A理由 | 評価した根拠 |
| 案B評価 | 点数または○△× |
| 案B理由 | 評価した根拠 |
| リスク | 採用した場合に残るリスク |
| 確認状況 | 確定・暫定・要確認など |
| 根拠資料 | 仕様書・見積書・検証結果など |
構成案比較でよくある失敗
失敗1．最初から採用したい案が決まっている
結論ありきで評価すると、 点数を都合よく調整しただけの比較表になります。
先に評価基準と重みを決めてから、 各案を評価する方が判断の偏りを抑えやすくなります。
失敗2．評価項目と要件がつながっていない
「最新技術だから」「高性能だから」という理由だけでは、 採用理由として不十分です。
評価軸は、可能な限り 今回の顧客要件へ結び付けます。
失敗3．○△×だけで終わる
○△×は一覧性に優れますが、 なぜその判定になったのか分かりません。
重要項目には理由を書きます。
失敗4．評価基準が人によって違う
Aさんの「4点」とBさんの「4点」の意味が違えば、 比較結果の信頼性が下がります。
評価ルールを事前に定義します。
失敗5．コストが安いほど自動的に高評価になる
最安構成が必ず最適とは限りません。
安価でも障害時の業務停止時間が長くなれば、 顧客にとって大きな損失になる場合があります。
失敗6．合計点だけを見て決める
合計点は重要な参考値ですが、 必須条件、重大リスク、未確認事項を無視してはいけません。
顧客・上司へ構成案を説明する方法
比較表を顧客へ説明するとき、 いきなり点数から説明しないことが重要です。
説明の順番
- 今回の重要要件を説明する まず「何を重視して選ぶのか」を共有します。
- 検討した構成案を説明する 各案の仕組みを簡潔に説明します。
- 主な違いを説明する 可用性・性能・コストなど、差が大きいポイントを説明します。
- 推奨案を示す 比較結果から、どの案を推奨するのかを明確にします。
- 推奨理由と残るリスクを説明する メリットだけでなく、デメリットや注意点も伝えます。
説明例
今回は、回線障害時にも業務を継続できることを最重要要件としているため、 可用性の評価比重を25％としています。
3案を比較した結果、案CのSD-WAN構成が 可用性・運用性・将来拡張性の点で最も高い評価となりました。
一方で、案Aより導入費用が高く、 運用担当者への教育も必要になります。 これらを許容できる場合は案Cを推奨します。
良い提案は、「推奨案のメリット」だけでなく、 「他案を採用しなかった理由」と「推奨案に残るリスク」も説明できます。
構成案比較で使う英語表現
| 英語 | 意味 |
|---|---|
| comparison matrix | 比較表・比較マトリクス |
| decision matrix | 意思決定マトリクス |
| evaluation criteria | 評価基準 |
| weighted scoring | 重み付け評価 |
| mandatory requirement | 必須要件 |
| trade-off | 一方を得る代わりに他方を犠牲にする関係 |
| operational complexity | 運用の複雑さ |
| scalability | 拡張性 |
| migration risk | 移行リスク |
| vendor lock-in | 特定ベンダーへの依存 |
| total cost of ownership | 導入後の運用を含めた総保有コスト |
たとえば海外ベンダーとの打ち合わせでは、 次のような表現を使えます。
We compared the three options based on availability, security, cost, operational complexity, and scalability.
「3つの案を、可用性、セキュリティ、コスト、 運用の複雑さ、拡張性を基準に比較しました。」
理解度チェック
問題1．構成案比較表を作る主な目的は何ですか。
- 最も高価な構成を選ぶため
- 設計者が好きな製品を選ぶため
- 複数案を共通基準で比較し、選定理由を明確にするため
- 構成図を作成しなくてもよくするため
解答を見る
構成案比較表は、 複数案を共通の評価基準で比較し、 採用案とその理由を説明するために使用します。
問題2．必須要件を満たさない構成案が、 他の評価項目で最高得点になりました。 原則としてどう考えるべきでしょうか。
解答を見る
原則として採用候補から除外します。 必須要件は、他項目の高得点で相殺するものではありません。
問題3．すべての評価項目を同じ重要度で扱わないために使う方法は何ですか。
解答を見る
重み付けです。 案件で重視する要件ほど高い比率を設定します。
問題4．評価表に点数だけでなく評価理由を書くのはなぜですか。
解答を見る
後から見た人が、 なぜその点数になったのかを確認できるようにするためです。 レビューや意思決定の追跡にも役立ちます。
問題5．総合評価が最も高い案は、必ず採用すべきでしょうか。
解答を見る
必ずしもそうではありません。 必須条件、重大リスク、納期、未確認事項、 運用体制なども含めて最終判断します。
実践演習：新拠点のネットワーク構成を比較する
顧客要件
- 新しい支店を本社ネットワークへ接続する
- 支店利用者は約100名
- 業務システムは本社とクラウドの両方に存在する
- 回線障害時も重要業務を継続したい
- 通信は暗号化する
- 運用担当者は3名
- 将来10拠点程度まで増える可能性がある
- コストにも上限がある
候補
- 案A：インターネットVPN 2回線
- 案B：閉域網＋バックアップVPN
- 案C：SD-WAN
課題1．必須条件を決める
1．
2．
3．
課題2．評価項目と重みを決める
性能：＿＿％
セキュリティ：＿＿％
運用性：＿＿％
コスト：＿＿％
拡張性：＿＿％
合計：100％
課題3．各構成案を1〜5点で評価する
点数だけでなく、 なぜその点数を付けたのかも記載してください。
可用性：＿＿点 理由：＿＿＿＿＿＿＿＿
運用性：＿＿点 理由：＿＿＿＿＿＿＿＿
コスト：＿＿点 理由：＿＿＿＿＿＿＿＿
課題4．推奨案を決める
推奨理由：
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
主なデメリット：
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
採用前に確認すべき事項：
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
演習の考え方を見る
この演習に唯一の正解はありません。
重要なのは、 顧客要件 → 評価基準 → 点数 → 推奨理由 が一貫していることです。
たとえば「回線障害時の業務継続」を最重要要件とするなら、 可用性の重みを高く設定する理由があります。
一方で、予算が非常に厳しい案件であれば、 コストの重みが高くなる可能性があります。
自分の言葉で説明する課題
顧客から次のように質問されました。
「一番性能が高い構成を選べばよいのではないですか？」
技術に詳しくない顧客にも伝わるように説明してください。
説明例を見る
性能が最も高い構成が、 必ずしも今回のネットワークに最適とは限りません。
実際の設計では、 障害への強さ、セキュリティ、運用のしやすさ、 導入費用、将来の拡張なども考える必要があります。
そのため、今回重要な条件を整理したうえで複数案を比較し、 必要な性能を満たしながら、全体として最もバランスのよい構成を選びます。
まとめ
- 構成案比較表は、複数の設計案を共通基準で比較し、 採用理由を明確にするための資料
- 可用性、性能、セキュリティ、運用性、コスト、 移行性、拡張性などを評価する
- 必須条件と、優劣を比較する評価項目は分けて考える
- 必須条件を満たさない案を、 他項目の高得点で相殺しない
- 評価点は1〜5点などの共通ルールを決めてから付ける
- 案件で重要な項目には重み付けを行う
- 点数だけでなく、評価理由・根拠・リスク・未確認事項を残す
- 総合得点は意思決定を支援する材料であり、 得点だけで自動的に構成を決定しない
上流工程で重要なのは、 「この構成を作れる」ことだけではありません。 「なぜ他の案ではなく、この構成を選んだのか」を説明できることです。
上級編では、要件定義から基本設計、 クラウド、セキュリティ、自動化、 設計・提案までを順番に学びます。
コメント