この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第67回です。
第7章では、設計書を作るだけでなく、 設計理由・リスク・コスト・運用方法を相手へ説明し、 合意を得るための実務スキルを学びます。
NETWORK ADVANCED｜CHAPTER 7 DESIGN & PROPOSAL
顧客に冗長化を説明する方法｜技術を業務継続・リスク・コストへ変換する
「ルーターを2台にします」「VRRPで冗長化します」と説明しても、 技術に詳しくない顧客には、その構成へ追加費用をかける理由が伝わらないことがあります。 冗長化を説明するときに重要なのは、 技術の仕組みではなく、障害時にどの業務を守るための設計なのか を伝えることです。
ネットワークエンジニアにとって 「単一障害点をなくすために二重化する」という説明は自然です。
しかし、顧客が知りたいのは 「冗長化という技術が正しいか」だけではありません。
追加費用を払うと何が守られるのか。 冗長化しなければ何が起こるのか。 どこまで冗長化すれば十分なのか。 という判断材料が必要です。
この記事を読み終えるとできること
- 冗長化を非エンジニア向けに説明できる
- 技術用語を業務影響へ言い換えられる
- 冗長化する場合としない場合を比較できる
- 可用性とコストの関係を説明できる
- 冗長化対象の優先順位を整理できる
- 顧客との会話から可用性要件を確認できる
顧客に冗長化を説明するときに重要なこと
冗長化は「機器を2台にすること」ではなく、 障害が発生しても必要な業務を継続できるようにするための手段です。
冗長化の説明で最初から機器構成やプロトコルの話をすると、 技術に詳しくない顧客は判断できません。
まず確認すべきなのは、 ネットワークが停止した場合に顧客の業務へ何が起こるのか です。
REDUNDANCY EXPLANATION｜技術ではなく業務から考える
たとえば、次の2つでは同じネットワークでも必要な可用性が異なります。
停止しても翌営業日に対応できるネットワーク
数時間停止しても大きな業務影響がないのであれば、 必ずしもすべてを二重化する必要はありません。
停止すると全社員が業務できないネットワーク
短時間の停止でも大きな影響が発生するのであれば、 機器・回線・経路などの冗長化を検討する重要性が高くなります。
冗長化の必要性は、技術だけでは決まりません。
「障害が起きる可能性」と 「障害が起きたときの業務影響」を考え、 顧客と必要な可用性を決めます。
なぜ冗長化の説明は顧客に伝わりにくいのか
理由1．正常時には効果が見えにくい
冗長化した機器や回線は、 正常時には待機系として使われることがあります。
そのため顧客から見ると、 「普段使わない機器に追加費用を払っている」 ように見えることがあります。
説明のポイント： 予備機器を購入することが目的なのではなく、 障害発生時の業務停止時間を短くするための投資であることを説明します。
理由2．技術用語では効果を判断できない
VRRPを構成し、デフォルトゲートウェイを冗長化します。
一方のゲートウェイ機器に障害が発生しても、 もう一方へ切り替えて端末の通信を継続できる構成にします。
技術用語が悪いわけではありません。 技術者同士の設計レビューでは必要です。
しかし顧客説明では、 技術 → 効果 → 業務 の順に翻訳する必要があります。
理由3．冗長化すれば絶対に止まらないと誤解されやすい
冗長化は障害リスクを下げるための対策ですが、 「冗長化したので絶対に停止しない」と説明するのは適切ではありません。
共通設備、電源、上位回線、設定ミス、ソフトウェア障害、 運用ミスなど、別の要因で通信が停止する可能性があります。
「冗長化＝無停止」と断言しないことが重要です。
どの障害を想定していて、どの障害は対象外なのかを明確にします。
技術ではなく「業務停止」を起点に説明する
顧客へ冗長化を提案するときは、 いきなり「2台構成にしましょう」と説明するのではなく、 次の順番で話すと理解されやすくなります。
- 何の業務で使っているか確認する メール、Web会議、受発注、店舗決済、クラウドシステムなど、 ネットワークへ依存している業務を確認します。
- ネットワーク停止時の影響を確認する 一部利用者だけなのか、全社なのか、 売上や顧客対応へ影響するのかを整理します。
- どれだけ停止を許容できるか確認する 数分なのか、数時間なのか、翌営業日まで許容できるのかを確認します。
- 単一障害で停止する場所を示す 機器、回線、リンク、電源など、 1か所の障害で業務全体が止まる場所を整理します。
- 必要な場所だけ冗長化を提案する 影響度とコストを比較し、 優先順位を付けて対策を提案します。
顧客が判断したいのは「どの技術を使うか」よりも、 「その対策に費用をかける価値があるか」です。
シングル構成と冗長構成を比較して説明する
冗長化の必要性は、 「冗長化した構成だけ」を見せるよりも、 シングル構成と並べて比較すると伝わりやすくなります。
シングル構成
Router Aに障害が発生すると、 インターネット通信が停止します。
冗長構成
Router Aに障害が発生した場合でも、 Router Bを利用できるように設計します。
| 比較項目 | シングル構成 | 冗長構成 |
|---|---|---|
| 機器障害時 | 通信停止につながりやすい | 待機系・別経路へ切り替えられるよう設計可能 |
| 初期費用 | 抑えやすい | 機器・回線などの追加費用が必要 |
| 構成の複雑さ | 比較的シンプル | 構成・設定・試験が増える |
| 運用 | 管理対象が少ない | 冗長状態や切替動作の監視が必要 |
| 向いているケース | 停止影響が小さい環境 | 停止時の業務影響が大きい環境 |
ポイント： 「冗長構成の方が高性能だから採用する」のではありません。 障害時に必要な業務を継続する価値と追加コストを比較して判断します。
顧客へ冗長化を説明する5つの観点
何を守るのか
最初に、冗長化によって守りたい業務やサービスを明確にします。
- 全社員のインターネット接続
- 基幹システムへの接続
- 店舗の決済通信
- 拠点間通信
- クラウドサービスへの接続
何が故障した場合を想定するのか
- ルーター障害
- スイッチ障害
- ファイアウォール障害
- 回線障害
- リンク障害
- 電源障害
どの程度の停止を許容するのか
「止めたくない」だけでは設計条件として不十分です。
数分以内なのか、1時間なのか、 営業時間外であれば停止可能なのかを確認します。
どう切り替えるのか
障害時に自動で切り替える必要があるのか、 運用担当者が手動で切り替えてもよいのかを確認します。
追加コストとのバランス
冗長化すると機器数や回線数だけでなく、 設計・構築・試験・監視・保守の対象も増えます。
そのため、すべてを一律に二重化するのではなく、 業務影響の大きい部分から優先順位を決めます。
「冗長化すると高くなる」と言われたときの説明方法
顧客説明では、 冗長化の技術的なメリットだけでなく、 費用についても正面から説明する必要があります。
「ネットワークでは普通は冗長化します。」
「障害対策なので2台必要です。」
「現在の構成では、このルーター1台が停止すると 全社員のインターネット通信が停止します。」
「今回の冗長化は、その単一障害による業務停止時間を 短くするための対策です。」
追加費用だけを見るのではなく、 対策しなかった場合に発生する可能性のある業務影響 と並べて説明します。
| 確認項目 | 顧客と整理する内容 |
|---|---|
| 停止する利用者 | 一部部署か、拠点全体か、全社か |
| 停止する業務 | メール、クラウド、決済、受発注など |
| 許容停止時間 | 何分・何時間まで許容できるか |
| 復旧方法 | 自動切替が必要か、手動切替でもよいか |
| 対策費用 | 機器、回線、保守、構築、運用など |
「高い・安い」だけではなく、 何のリスクをどこまで下げるための費用なのかを説明します。
どこまで冗長化するかを顧客と決める
ルーターを2台にしても、 その先の回線が1本だけであれば、 回線障害時には通信できません。
反対に、すべての機器・回線・電源を最大限に冗長化すると、 費用や運用負荷が大きくなります。
したがって、 どこまでの障害を想定するか を顧客と決める必要があります。
| 冗長化対象 | 確認する質問 | 説明するポイント |
|---|---|---|
| ネットワーク機器 | 1台故障すると、どの業務が停止するか | 機器単体の故障対策 |
| ネットワーク経路 | ケーブルやポート障害時に別経路が必要か | 経路上の単一障害を減らす |
| インターネット回線 | 回線障害時も外部通信を継続する必要があるか | 通信事業者・アクセス回線を含めて検討する |
| 電源 | 電源系統障害まで想定する必要があるか | 機器が2台でも同じ電源へ依存していないか確認する |
| 拠点・設備 | 建物・設備全体の障害まで対策対象にするか | 案件全体の可用性要件として整理する |
冗長化は「2台にしたか」ではなく、 単一障害点がどこに残っているかを見ることが重要です。
冗長化方式そのものを詳しく確認したい場合は、 「14. 冗長化設計」 も確認してください。
インターネット接続については、 「23. 冗長インターネット接続」 で詳しく扱っています。
実際の顧客との会話例
ケース：インターネット回線を冗長化するか迷っている
回線を2本にすると費用が上がりますよね。 1本では駄目なのでしょうか。
1本構成でも通常時の通信は可能です。 ただし、その回線が利用できなくなった場合は、 復旧するまでインターネット接続が停止します。
確認したいのですが、インターネット接続が停止した場合、 どの業務が利用できなくなりますか。
クラウド上の業務システムとWeb会議、 メールが使えなくなります。
その場合、回線障害が長時間続くと 多くの社員の業務へ影響します。 回線を冗長化すると、一方の回線で障害が発生した場合でも、 もう一方を利用して通信を継続できる構成を検討できます。
一方で回線費用と運用対象は増えますので、 許容できる停止時間と追加費用を比較したうえで 採用するか決めるのがよいと考えます。
この会話では、 「冗長化した方がよい」と結論を押し付けていません。
現状 → 障害時の影響 → 対策 → コスト の順に判断材料を提示しています。
顧客へ冗長化を説明するときのよくある失敗
失敗1．技術用語から説明する
「VRRP」「HSRP」「LACP」「BGP」などから話し始めると、 技術に詳しくない顧客は 「結局何が良くなるのか」を判断できません。
まず業務影響を説明し、 必要に応じて技術方式を補足します。
失敗2．冗長化すれば絶対止まらないと言う
冗長化していても、 想定していない障害や共通障害によって停止する可能性があります。
対策対象と対象外を明確にします。
失敗3．「普通は2台です」で説明する
一般論だけでは追加費用の根拠になりません。
顧客自身の業務影響と可用性要件を根拠に説明します。
失敗4．コストを無視する
技術的には理想的でも、 予算や運用体制によって採用できない場合があります。
構成案を複数用意して比較する方法も有効です。
失敗5．機器だけを冗長化する
機器が2台でも、回線・電源・上位経路などが 共通であれば単一障害点が残る場合があります。
失敗6．切替試験を説明しない
冗長構成を作っただけでは、 実際に障害時へ切り替わるか確認できません。
設計後は障害試験・復旧試験まで含めて考えます。
顧客へ冗長化を説明するときのテンプレート
説明に迷った場合は、 次の順番へ当てはめると整理しやすくなります。
冗長化説明テンプレート
現在は○○が1台／1回線の構成です。
この○○に障害が発生すると、△△の通信が停止します。
通信停止中は、□□の業務が利用できなくなります。
そこで○○を冗長化し、一方の障害時にはもう一方へ 切り替えられる構成を提案します。
単一の○○障害による業務停止時間を短くできます。
一方で機器・回線・保守・運用などの追加費用が発生します。
許容停止時間と費用を比較し、採用範囲を決定します。
30秒で説明する場合
現在の構成では、この機器1台が故障すると ネットワーク全体の通信が停止します。 冗長化は、同じ役割を持つ経路や機器を用意し、 一方に障害が発生した場合でも業務を継続できるようにする対策です。 追加費用は発生するため、 停止時の業務影響と許容停止時間を確認したうえで 必要な範囲を決めます。
設計レビューで説明する場合
一般的に冗長化した方がよいため、 ルーターを2台構成としました。
主要業務について単一機器障害時にも通信継続が必要という 可用性要件があるため、 ゲートウェイ機器を冗長構成としています。
構成案を複数比較する場合は、 「63. 構成案を比較する評価表」 もあわせて確認してください。
冗長化の説明で使う英語表現
海外ベンダー資料や設計資料では、 次のような表現がよく登場します。
| 英語 | 意味 | 実務での使い方 |
|---|---|---|
| redundancy | 冗長性・冗長化 | network redundancy |
| high availability | 高可用性 | high-availability network design |
| single point of failure | 単一障害点 | eliminate a single point of failure |
| failover | 障害時の切り替え | automatic failover |
| primary | 主系 | primary device / primary link |
| backup / standby | 予備・待機系 | backup link / standby device |
| downtime | 停止時間 | reduce downtime |
| business continuity | 事業・業務継続 | support business continuity |
冗長化について英語資料を調べる場合は、 network redundancy / high availability / failover / single point of failure などを検索キーワードとして使えます。
理解度チェック
技術知識ではなく、 「顧客へ説明できるか」という観点で確認してください。
問題1． 顧客へ冗長化を説明するとき、 最初に確認すべきものとして最も適切なのはどれですか。
- 使用するルーターの型番
- VRRPのPriority値
- ネットワーク停止時の業務影響
- 設定コマンド
解答を見る
冗長化は業務継続のための手段です。 まず停止時にどの業務へ影響するのかを確認します。
問題2． 「ルーターを2台にすればネットワークは絶対に止まらない」 という説明は適切ですか。
解答を見る
回線、電源、上位経路など、 ほかの単一障害点が残っている可能性があります。 冗長化の対象範囲と想定障害を明確にする必要があります。
問題3． 顧客から「絶対に止めたくない」と言われました。 追加で確認すべき内容を3つ以上挙げてください。
解答例を見る
- 停止した場合の業務影響
- 許容停止時間
- 冗長化したい対象
- 自動切替が必要か
- 計画停止は許容できるか
- 予算上の制約
問題4． 次の技術説明を顧客向けの言葉へ変換してください。
「ゲートウェイを2台構成とし、冗長化します。」
解答例を見る
「現在はゲートウェイ機器1台の障害で 社内端末の外部通信が停止する構成です。 そこで同じ役割を持つ機器をもう1台用意し、 一方が利用できなくなった場合でも もう一方へ切り替えて通信を継続できる構成にします。」
実践演習：顧客へ冗長化を提案する
次の顧客条件を読み、 冗長化の必要性を説明してください。
顧客条件
- 社員数：300名
- 業務システムはクラウド上で稼働
- 全社員がインターネット経由で利用
- 現在のインターネット接続ルーターは1台
- インターネット回線は1本
- 平日9:00〜18:00に業務を実施
- 顧客から「費用はなるべく抑えたい」と要望あり
課題1．現在の単一障害点を洗い出す
解答例を見る
- インターネット接続ルーター
- インターネット回線
実際の案件では、上位スイッチ、ファイアウォール、 電源、配線経路なども構成図から確認します。
課題2．追加で顧客へ確認する質問を作る
質問例を見る
- インターネット停止時に利用できなくなる業務は何ですか
- 何分・何時間まで停止を許容できますか
- 営業時間外であれば計画停止は可能ですか
- 障害時は自動切替が必要ですか
- 回線まで冗長化する必要がありますか
- 可用性向上のために確保可能な予算はありますか
課題3．顧客向けに1分で説明する
説明例を見る
現在はインターネット接続ルーターと回線が それぞれ1系統のため、 どちらかに障害が発生すると 全社員がクラウド上の業務システムへ 接続できなくなる可能性があります。
業務停止を短くする必要がある場合は、 ルーターや回線を冗長化し、 一方の障害時に別系統へ切り替えられる構成を検討できます。
一方で、機器費用・回線費用・保守費用などは増えるため、 まず許容できる停止時間を確認し、 どこまで冗長化するかを決めるのが適切です。
自分の言葉で説明する課題
ITに詳しくない顧客から、 次のように質問されたとします。
「予備のルーターにお金を払う意味がよく分かりません。 壊れてから交換するのでは駄目なのですか？」
技術用語をなるべく使わず、 1分程度で回答してください。
説明例を見る
壊れてから交換する方法でも復旧は可能ですが、 交換機器の準備や作業が完了するまで ネットワークが停止する可能性があります。
今回の冗長化は、 1台が利用できなくなった場合でも もう1台へ切り替えて業務を継続し、 障害による停止時間を短くすることが目的です。
そのため、追加費用と、 ネットワーク停止時の業務影響を比較して 採用するか判断していただく形になります。
まとめ
- 冗長化は「機器を2台にすること」ではなく、 障害時にも必要な業務を継続するための手段
- 顧客へ説明するときは、 技術用語より先に停止時の業務影響を説明する
- 「何を守るか」「何の障害を想定するか」 「何分停止できるか」を確認する
- 冗長化しても絶対に停止しないとは説明しない
- 機器だけでなく、回線・経路・電源などの 単一障害点も確認する
- 冗長化すると費用・構成・運用負荷も増えるため、 業務影響とコストを比較して採用範囲を決める
- 顧客説明では 「現状 → リスク → 業務影響 → 対策 → コスト」 の順番が使いやすい
設計できるだけでなく、 「なぜこの冗長化が必要なのか」を 顧客の業務と結び付けて説明できることが、 上流工程で求められる重要なスキルです。
上級編では、要件定義・基本設計・BGP・クラウド・ セキュリティ・自動化から、 設計レビューや顧客説明までを実務につなげて学びます。
コメント