基本設計書とは何か

要件定義では、 「何を実現しなければならないのか」を整理しました。

基本設計では、その要件を受けて 「どういう仕組みで実現するのか」 を決めていきます。

たとえば顧客から、 「回線障害が発生しても業務を継続したい」 という要件が出ているとします。

基本設計では、これを実現するために、 次のような方針を決めます。

• インターネット回線を2回線構成とする
• 異なる障害点となるよう回線を分散する
• エッジルーターを冗長化する
• 障害発生時はバックアップ回線へ切り替える
• 切り替え状態を監視できる構成とする

要件定義から設計までの全体像

基本設計書だけを単独で作るのではありません。 実務では、前工程と後工程を意識して作成します。

要件定義とのつながり

基本設計の入力となる代表的な情報には、次のものがあります。

• 利用者数・端末数
• 通信量・必要帯域
• 可用性・許容停止時間
• セキュリティ要件
• 拠点数・接続先
• クラウド利用状況
• 運用・監視要件
• ログ保存要件
• 移行条件
• 予算・納期・既存設備などの制約

要件定義の基本については、 「ネットワーク要件定義とは何か」 で詳しく解説しています。

要件定義書・基本設計書・詳細設計書の違い

設計経験が少ないと、 「基本設計書にどこまで書けばよいのか」 が分かりにくいことがあります。

まず、3つの資料の役割を分けて考えましょう。

ネットワーク基本設計書に記載する主な内容

基本設計書の章立てに絶対的な正解があるわけではありません。 案件規模や対象範囲によって変わります。

企業ネットワークであれば、代表的には次の内容を整理します。

基本設計書を作る手順

最初からWordを開いて文章を書き始めるのではなく、 要件と設計判断を整理してから文書化すると作りやすくなります。

1. 要件定義書を読み込む 性能、可用性、セキュリティ、運用、移行など、 ネットワークが満たすべき条件を確認します。
2. 設計対象と対象外を確認する LAN、WAN、ファイアウォール、クラウド、無線LANなど、 自分が設計する範囲を明確にします。
3. 制約条件を整理する 既存機器、指定製品、予算、納期、既存IP体系、 回線契約など設計を制限する条件を確認します。
4. ネットワーク全体構成を考える 本社、拠点、データセンター、クラウド、 インターネットなどを大きな単位で配置します。
5. 設計項目ごとに方式を決める IPアドレス、VLAN、ルーティング、冗長化、 セキュリティなどを順番に設計します。
6. 設計理由を整理する 「なぜその方式を選んだのか」を 要件・制約・運用条件と結びつけます。
7. 構成図と文章を対応させる 文書だけで説明せず、物理構成図・論理構成図・通信図などを使います。
8. 設計間の矛盾を確認する VLAN、ルーティング、冗長化、FW、監視などが 互いに矛盾していないか確認します。
9. 要件を満たしているか確認する 要件ごとに、どの設計で実現しているかを追跡します。
10. 関係者レビューを実施する 顧客、PM、サーバー、セキュリティ、運用担当などと認識を合わせます。

小規模ネットワークを例に基本設計書を作る

具体例として、ある企業の本社ネットワーク更改を考えます。

要件

• 利用者は約200名
• 一般端末とサーバーをネットワーク分離する
• インターネット接続を提供する
• 主要ネットワーク機器の単一障害で業務を停止させない
• 障害発生時に管理者へ通知する
• 将来300名程度まで利用者が増える可能性がある

基本設計への変換

基本構成イメージ

基本設計書には「設計理由」を残す

設計書で特に差が出るのが、 なぜその設計にしたのか を説明できるかどうかです。

どちらも「2台構成」という設計内容は同じです。

しかし、後者であれば、 「なぜ2台必要なのか」 「1台へ減らした場合に何が問題になるのか」 を説明できます。

設計理由は3つの情報から考える

基本設計ではどこまで細かく書くのか

基本設計書と詳細設計書の境界で迷う場合は、 「その情報だけで機器設定を投入できるか」 を一つの判断基準にできます。

基本設計レビューで確認するポイント

基本設計書が完成したら、 文書の誤字だけでなく「設計として成立しているか」を確認します。

• 要件定義書の要求がすべて設計へ反映されているか
• 対象範囲と対象外が明確になっているか
• 物理構成図と論理構成図に矛盾がないか
• IPアドレス体系に重複や不足がないか
• VLANとセキュリティ方針が一致しているか
• 正常時だけでなく障害時の通信経路も成立するか
• 単一障害点が残っていないか
• 監視・ログ・運用まで考慮されているか
• 将来拡張を妨げる設計になっていないか
• 他システム・サーバー・クラウドとの責任分界が明確か
• 設計理由を要件へ結びつけて説明できるか
• 詳細設計へ進むために必要な情報が揃っているか

基本設計書作成でよくある失敗

1．要件を確認せずに設計を始める

エンジニアが慣れている構成をそのまま採用してしまうケースです。

技術的には正しくても、 顧客の可用性・性能・予算・運用要件を満たしていなければ適切な設計とはいえません。

2．構成図だけで終わる

構成図は非常に重要ですが、 図だけでは設計理由や通信方針までは説明できません。

構成図と文章を組み合わせて説明します。

3．機器名・型番だけを並べる

「Cisco○○を2台設置する」 と書くだけでは、その構成が必要な理由が分かりません。

先に設計要件や方式を説明し、 製品選定とは分けて整理します。

4．正常時しか考えていない

冗長化設計では、 障害時にどの経路へ切り替わるのかまで確認します。

5．運用を考慮していない

技術的に高度な構成でも、 運用担当者が扱えなければ障害対応や変更作業が難しくなります。

設計時には、監視、バックアップ、ログ、保守方法、 運用チームのスキルも考慮します。

6．資料間で値や名称が違う

構成図では「CORE-SW01」、 設計書では「L3SW-A」、 パラメータシートでは「SW01」のように名称がばらばらだと、 レビューや構築時のミスにつながります。

機器名、VLAN名、拠点名などの命名規則を統一します。

7．設計理由が残っていない

数年後に構成変更するとき、 「なぜこの設定が必要なのか分からない」 という状態になりやすくなります。

重要な設計判断には理由を残しましょう。

顧客・上司へ基本設計を説明する方法

顧客へ説明するときに、 最初からOSPF、VRRP、BGPなどの技術用語だけを並べると、 設計の価値が伝わりにくくなります。

次の順番で説明すると整理しやすくなります。

1. 要件を確認する 「今回、主要機器の単一障害時にも業務通信を継続するという要件があります。」
2. 設計方針を説明する 「そのため、主要な通信経路を冗長化しています。」
3. 具体的な構成を説明する 「コアスイッチを2台構成とし、各アクセススイッチから双方へ接続します。」
4. 障害時の動きを説明する 「片方のコアスイッチが停止した場合も、もう片方を経由して通信を継続します。」
5. 残るリスクを説明する 「ただし、建物全体の停電や両回線同時障害については別途対策が必要です。」

基本設計で使う英語表現

海外ベンダーの設計資料やクラウドドキュメントでは、 次のような表現がよく使われます。

自分の言葉で説明する課題