緻密な「設計書」という名のレシピが完成し、いよいよキッチンで実際に料理を始める「構築」、そして完成した料理が本当に美味しいか味見をする「テスト」のフェーズがやってきました。この工程は、机上の理論を物理的な現実に変える、プロジェクトの中でも特にダイナミックで緊張感のある段階です。
本記事では、この構築とテストのプロセスを5つのステップに分解し、現場でつまずきがちな「勘所」を重点的に解説します。単なる作業手順の紹介ではなく、「なぜその準備が必要なのか」「なぜそのテストが品質を左右するのか」といった、ネスペ午後試験で問われる思考の根幹に迫ります。
設計書に描かれた理想のネットワークを、確かな品質で現実のものとするための知識を身につけていきましょう。
目次
構築前の段取りと準備│プロジェクト成功は「準備が9割」
実際の構築作業(ラッキングや設定投入)に取り掛かる前の「段取り」こそが、プロジェクトの成否を分けると言っても過言ではありません。ここで必要な手配や調整を怠ると、いざ作業を始めようとしても「機器が届いていない」「データセンターに入れない」といった手戻りが発生し、計画全体が遅延する原因となります。
モノの手配:機器・ソフトウェア・回線の納期管理
ネットワーク機器は、発注してから納品されるまでに数週間、場合によっては数ヶ月かかることも珍しくありません。作業計画から逆算して、適切なタイミングで手配を完了させておく必要があります。
【仕事例】
WBS(作業分解構成図)上で、「ルーター設定投入(11/10)」というタスクがあるならば、その日までに必ず機器が現場に納品され、検品(品違いや故障がないかの確認)まで完了していなければなりません。特に海外製品は納期が不安定になりがちなため、ベンダーと密に連携し、進捗を常に把握しておくことが重要です。
- 手配リストの例:
- ハードウェア:ルーター、スイッチ、ファイアウォール、サーバー、ラック、配線ケーブル
- ソフトウェア:ネットワーク機器のOS、監視ツール、ライセンス
- ネットワークサービス:インターネット回線、専用線、クラウド接続サービスの開通申し込み
ヒト・場所の確保:作業員と作業場所の手配
機器だけでなく、作業を行う「人」と「場所」の確保も不可欠です。
手配対象 | 主なタスク |
---|---|
作業員(ヒト) | 自社のエンジニアだけでなく、必要に応じて外部の構築パートナー(協力会社)のスキルとスケジュールを押さえる。 |
作業場所(場所) | データセンターやサーバルームでの作業には、多くの場合、事前の入館申請が必要。作業者名、日時、持ち込み機材などをリスト化して申請する。 |
情報の最終連携:関係者への周知徹底
【身近な例え】
引越し作業の前に、家族や関係者に「何月何日の何時に引越し業者が来ます」と最終案内をするのと同じです。事前に伝えておくことで、当日の混乱を避け、協力を得やすくなります。
構築作業、特にサービス停止を伴う切り替え作業の前には、設計フェーズで作成した作業計画を元に、最終的な実施要領を関係者へ改めて周知します。
- 周知内容:最終的な作業日時、作業内容、影響範囲、緊急連絡先、切り戻し判断基準など。
- 周知先:プロジェクトメンバー、顧客(システムの利用者)、運用担当者、ビル管理者など。
この徹底した準備があって初めて、次の「導入作業」にスムーズに進むことができるのです。
導入作業(実装)の手順│ラッキング・配線から設定投入まで
入念な準備が整ったら、いよいよ設計書を現実のモノへと変える「導入作業(実装)」に取り掛かります。このフェーズは、大きく分けてサーバーラックなどに機器を設置する「物理作業」と、設計通りに設定を流し込む「論理作業」から構成されます。全ての作業は、必ず設計書と作業手順書に基づいて正確に行い、その記録を残すことが鉄則です。
1. 物理作業:機器の設置と配線
物理作業は、ネットワークの「身体」を作る工程です。ここでの丁寧さが、将来の運用保守のしやすさに直結します。
【身近な例え】
これは、新しいテレビと録画機器を買ってきた後の作業に似ています。まずテレビ台の決まった場所に設置し(ラッキング)、電源ケーブルやHDMIケーブル(配線)を説明書通りに繋ぎますよね。ケーブルがぐちゃぐちゃだと、後で掃除や他の機器の接続が大変になるのと同じです。
- 物理作業の主なステップ:
- 開梱・検品:納品された機器の箱を開け、発注通りの型番か、付属品は揃っているか、輸送中の破損はないかを確認します。
- ラッキング:設計書で定められた位置に従い、機器をサーバーラックへ搭載し、ネジで固定します。
- 配線(ケーブリング):電源ケーブルを接続し、配線構成図に基づいてLANケーブルや光ファイバーケーブルをポートに接続します。ケーブルには、後から見てどの機器のどのポートに繋がっているか分かるように「ラベリング」を施します。
- 電源投入:すべての配線が完了したことを確認し、機器の電源を入れます。OSが正常に起動するか、ランプの状態で異常がないかなどを確認します。
2. 論理作業:コンフィグレーションの投入
電源が入った機器に「魂」を吹き込むのが論理作業です。設計書に記載されたパラメータ(IPアドレス、VLAN設定、ルーティング情報など)を、一つひとつ正確に機器へ設定(コンフィグレーション)していきます。
【仕事例】
大規模な構築では、一台ずつ手で設定すると時間もかかり、入力ミスの原因にもなります。そのため、事前に設定内容をテキストファイル(コンフィグファイル)として作成しておき、USBメモリやTFTPサーバー経由で一括で投入(流し込み)するのが一般的です。これにより、作業の効率化と標準化を図ります。
3. 作業記録:未来の自分や仲間を助ける
導入作業で最も重要なことの一つが、「行った作業すべてを記録する」ことです。
- なぜ記録が重要か?
- 再現性の確保:障害発生時に、どのような設定がいつ投入されたのかを正確に把握できる。
- 属人化の防止:作業した本人でなくても、後から担当者が構成を理解し、メンテナンスできる。
- 構成管理の基礎:「構成管理データベース」を最新の状態に保つための元情報となる。
最終的な設定情報(ファイナルコンフィグ)や、物理的な結線状態を示した図(物理構成図)、IPアドレスの割り当て表などを「As-Built(アズビルト)ドキュメント」として整理し、いつでも参照できる状態にしておくことが求められます。
テスト仕様書の作成│「何を」「どう」確認するかの設計図
構築作業が完了したら、次はいよいよ「テスト」フェーズです。しかし、やみくもに通信確認を行うだけでは、品質を保証することはできません。そこで不可欠となるのが、テストの設計図である「テスト仕様書」です。これは、「何を、どのような手順で確認し、どうなれば合格とするか」を事前に定義した文書です。
なぜテスト仕様書が必要なのか?
テスト仕様書は、テストの客観性と網羅性を担保するために作成します。
- 客観性:作業者の主観やスキルレベルによらず、誰がやっても同じ品質でテストを実行できるようにする。
- 網羅性:確認すべき項目を洗い出し、テストの抜け漏れを防ぐ。要件定義書で定められた要件がすべて満たされていることを証明する根拠となる。
【身近な例え】
これは、料理のレシピに似ています。レシピがあれば、誰が作っても同じ味に仕上がりますよね。また、必要な材料リスト(テスト項目)と調理手順(テスト手順)が書かれているので、「塩を入れ忘れた!」(テストが漏れた!)といった失敗を防ぐことができます。
テスト仕様書に記載すべき項目
テスト仕様書には、一般的に以下の項目を記載します。
項目 | 内容 |
---|---|
テスト項目ID | 各テスト項目を識別するための一意の番号。 |
テストの目的 | そのテストで何を確認したいのか。(例:拠点間でのファイル転送が可能であること) |
テスト環境・前提条件 | テストに使用する機器、IPアドレス、必要な事前設定など。 |
テスト手順 | コマンド入力や画面操作など、具体的な作業手順を1ステップずつ記述。 |
確認内容(OK/NG基準) | どのような結果になれば「正常(OK)」と判断するかを明確に定義。(例:pingコマンドの応答が5回連続で返ってくること) |
実施結果 | テスト実施後に、OKかNGかを記録する欄。NGの場合はその内容を詳述。 |
【仕事例】Webサーバーへのアクセス確認テスト
例えば、「クライアントPCからWebサーバーへ正常にアクセスできること」を確認するテスト仕様書は以下のようになります。
- ID: NW-TEST-001
- 目的: クライアントPCセグメントからサーバーセグメントのWebサーバー(HTTP)へアクセスできることを確認する。
- 環境:
- クライアントPC (IP: 192.168.10.100)
- Webサーバー (IP: 172.16.1.10)
- 手順:
- クライアントPCでコマンドプロンプトを起動する。
ping 172.16.1.10
を実行する。- クライアントPCでWebブラウザを起動する。
- アドレスバーに
http://172.16.1.10
と入力し、Enterキーを押す。
- OK/NG基準:
- pingの応答が4回返ってくること。
- Webブラウザに「テストページ」という文字が表示されること。
このように詳細な手順と明確な合格基準を定めることで、テストの品質を担保し、次の「テスト実行」フェーズへと進むことができます。
テストの実行と種類│単体・結合・性能試験のポイント
テスト仕様書が完成したら、いよいよその手順に沿って「テストの実行」に移ります。ネットワークシステムのテストは、目的に応じていくつかの種類に分類されます。一般的には、小さな単位から始め、徐々に全体の動きを確認していくアプローチが取られます。
テストの段階的アプローチ
【身近な例え】
自動車の組み立てに例えてみましょう。まずエンジンやブレーキといった「部品(単体)」が正常に作動するかをテストします。次に、それらを組み合わせて車全体として「走る・曲がる・止まる(結合)」ができるかを確認します。最後に、サーキットで高速走行(性能)をしても問題ないかをテストします。ネットワークのテストも、この考え方と非常によく似ています。
単体テスト → 結合テスト → 性能テスト の順に進めるのが基本
テストの種類 | 目的 | テスト内容の具体例 |
---|---|---|
1. 単体テスト | 機器一台ずつが、設計書通りに設定され、意図通りに動作するかを確認する。 | ・ルーターにログインし、show running-config コマンドで設定内容が正しいかを確認。・スイッチの各ポートでVLAN設定が正しいかを確認。 |
2. 結合テスト | 複数の機器を連携させ、システム全体として機能するかを確認する。 | ・クライアントPCからサーバーへpingが通るか(正常系)。 ・メイン回線を抜線した際に、自動的にバックアップ回線へ切り替わるか(異常系/冗長化テスト)。 |
3. 性能テスト | システムに高い負荷をかけ、それでも性能要件(スループット、遅延など)を満たせるかを確認する。 | ・専用のトラフィックジェネレーターを使い、1Gbpsの負荷をかけた状態でパケットロスが発生しないかを確認。 ・多数の利用者が同時にアクセスした際のWebサーバーの応答時間(レスポンスタイム)を計測。 |
テスト実行時の注意点
テストを実行する際は、テスト仕様書に沿って淡々と作業を進めるだけでなく、以下の点にも注意が必要です。
- エビデンス(証拠)の取得:
テストが正しく実行され、結果がどうであったかを客観的に証明するために、コマンドの実行結果や画面キャプチャをすべて記録します。これが「エビデンス」となり、テスト報告書の基礎となります。 - 再現性の意識:
特に不具合(NG)が発生した場合は、どのような操作をしたらその事象が発生したのか、再現性のある手順を記録しておくことが、後の原因分析で非常に重要になります。
これらのテストをすべてクリアして初めて、構築したネットワークが要件を満たしていることを品質的に証明できるのです。
テスト結果の分析と評価│不合格(NG)への正しい対処法
テストを実行し、エビデンスを収集したら、その結果をまとめて分析・評価し、「テスト報告書」として文書化します。特に重要なのが、不合格(NG)となった項目への対処です。NGを正しく処理するプロセスこそ、ネットワークの品質を最終的に担保する上で最も重要な活動となります。
テスト結果の文書化
まず、すべてのテスト項目について、取得したエビデンスを元に「OK」か「NG」かを判定し、結果を一覧表にまとめます。これにより、プロジェクトの進捗と品質を客観的に把握することができます。
【身近な例え】
これは、健康診断の結果報告書に似ています。各検査項目(テスト項目)に対して、「異常なし(OK)」や「要再検査(NG)」といった判定が記載されていますよね。この一覧があることで、どこに問題があるのかが一目瞭然になります。
NG発生時の原因切り分けと分析
テストでNGが発生した場合、パニックになる必要はありません。これはシステムの品質を向上させるための貴重な「気づき」です。重要なのは、以下の体系的なプロセスに沿って冷静に対処することです。
- 事象の正確な把握:
まず、どのような操作をした時に、どのようなNG事象が発生したのかを正確に記録します。「〜〜のコマンドを打ったら、本来表示されるはずの〜〜ではなく、エラーメッセージ〜〜が表示された」というように、再現性のある手順を明確にします。 - 原因の切り分け:
次に、原因がどこにあるのかを切り分けます。ネットワークの世界では、問題の原因は一つとは限りません。- 物理層の問題か?(ケーブルの断線、ポートの故障など)
- データリンク層/ネットワーク層の問題か?(VLAN設定ミス、IPアドレス重複、ルーティング設定ミスなど)
- 設定の単純なタイピングミスか?
- 機器のハードウェア故障やソフトウェアのバグか?
- 対策の実施と記録:
原因を特定したら、対策(設定修正など)を実施します。そして、「なぜその問題が起きたのか」「どう対策したのか」を課題管理表などにすべて記録します。この記録が、将来同じ過ちを繰り返さないためのノウハウとなります。
再テストと回帰テスト(リグレッションテスト)
対策が完了したら、NGだった項目を再度テスト(再テスト)し、OKとなることを確認します。しかし、それだけでは不十分な場合があります。
【仕事例】
ある設定変更によってNG項目Aを修正した結果、これまでOKだった別の機能Bに予期せぬ影響(副作用)を与え、不具合を発生させてしまうことがあります。これを防ぐために行うのが「回帰テスト(リグレッションテスト)」です。
これは、修正箇所だけでなく、その周辺の関連機能や、特に重要度の高い機能も合わせて再度テストし、デグレード(品質低下)が起きていないことを確認するテストです。すべてのテスト項目がOKとなり、品質が保証されたことを顧客や関係者に報告し、承認を得て、テストフェーズは完了となります。
まとめ
今回は、設計書という「理論」を、動くネットワークという「現実」に変えるための、構築・テストフェーズにおける5つのステップを解説しました。
- 段取りと準備:作業を始める前の周到な手配が成功の鍵。
- 導入作業(実装):設計書に基づき、正確に機器を設置・設定する。
- テスト仕様書の作成:客観的で網羅的なテストの「設計図」を作る。
- テストの実行:単体→結合→性能と、段階的に品質を確認する。
- 結果の分析と評価:NG項目を潰し込み、品質を証明する。
ol>
構築はプロジェクトの花形に見えますが、その裏には地道な準備と、品質を担保するための厳格なテストが存在します。このフェーズでいかに手を抜かず、確実な作業を積み重ねるかが、リリース後の安定稼働、ひいては次の「運用・保守」フェーズの負荷を大きく左右するのです。
次回、連載第4回では、こうして無事に稼働を開始したネットワークを、いかに安定して維持していくかという「運用・保守」フェーズについて解説します。