ネットワークエンジニアがアウトプットをレビューするうえで必要の資料

ネットワークエンジニアってそもそも何を作っているのか

ネットワークシステムに関する資料だったりルータやスイッチのconfigを作成しています。
当たり前ですね(笑)
ネットワークエンジニアというくくりにもいろいろな扱いがあって、それこそセキュリティ周りをやっていることもあればサーバやOA端末もまとめてやっている人もいるかと思いますが、今回の記事は「ネットワーク」に限定したいと思います。
大体下記をレビューするときの参考にしてもらえればと思います。
・config (ルータやスイッチ、GUIで設定を変えるものであれば用意不要の場合有）
・作業手順書
・パラメータシート
・ポート収容表
・ラック構成図
・IPアドレス台帳
・機器台帳

私が様々な資料を作成してレビューしてたくさんダメ出しを受けたり、褒められたりした経験を踏まえてお伝えいたします。

レビューに必要な資料3点

①ネットワーク構成図
②通信要件表
③スケジュール

その①　ネットワーク構成図

一番大事です。ほぼすべての資料を説明するうえでの必須の資料と考えています。
まずは全体像をつかんでもらうために全体の「どこの部分」のレビューなのかを明確に伝える必要があります。
用意した構成図に対して作業対象箇所を赤丸で囲むことや、吹き出しをつけること、経路を書き込むなど加筆するもの様々です。
視覚的にわかりやすく説明をするためには既存の構成図に対して情報を書き加えるのがよいと思います。

例えば、
・config (ルータやスイッチ）/作業手順書　→どこの作業をする上でのものなのか
・パラメータシート　→どの機器のパラメータシートなのか
・通信要件表　→どの経路を指しているのか
・ポート収容表/ラック構成図/IPアドレス台帳　→どこにある機器なのか

こうすることで、ここの機器は対象じゃないんだっけ、とか、この経路でいいんだっけなど「資料単体」だったら見えてこない部分まで見ることができ、より良いレビューをすることができます。

あれ、じゃあそのネットワーク構成図はどこからもってくるの？と思うかもしれませんが、
基本的には方式設計書や基本設計書を作成するタイミングで要件が出てきますのでそれをもとにネットワーク構成図を作成しています。
たまーーーにない場合があります。システムによりけりですね。
そういう場合はリバースエンジニアリングをしてネットワーク構成図を作成します。
めんどくさいかと思いますがあって損はまずしないです。トラブル発生時の切り分けにも使えたり、維持管理資料としても利用できます。

1から丁寧に作成する時間がない！という場合には概要図でもOKです。
私はもともとあるネットワーク構成図のほかに簡易的な概要図も合わせて作成してするケースが多々あります。
全体を見渡すのが大事なのでそこだけはおさえておくとよいと思います。

★余談ですが、新人研修では物理構成図と論理構成図を別々に作成する、ということを教えられていた記憶があります。業務を通して別々で作るメリットをあまり感じられなかったので、私個人的には物理＆論理でまとめて1つで作成してしまうことがほとんどです。
機会があれば構成図の書き方についてもQiitaに残しておきたいですね。

通信要件

主にインプット情報になるものです。
色々なネットワークシステム基盤を見てきましたが大体の通信要件表というものは以下で構成されていると思います。
・送信元IP,送信元NAT-IP,送信元ポート番号
・宛先IP,宛先NAT-IP,宛先ポート番号
　※もちろんNATの有り無しは要件によりけりです。

これ無くして用意できないものは多々あります。
・config　⇒通信要件が無いと作れない
・作業手順書　⇒上記同様
・パラメータシート　⇒上記同様
・ポート収容表　⇒新しいケーブル接続が無い場合であれば不要
・ラック構成図　⇒新しい機器を導入しない場合であれば不要
・IPアドレス台帳　⇒新しいIPアドレスを払い出さなければ不要
・機器台帳　⇒新しい機器を導入しない場合であれば不要

○○という要件があるから××とういうアウトプットを作成した、なのでそのレビューをしたい。
という流れが基本だと思います。
あいまいに要件をもらっていたり、それこそテキストベースやメールベースで簡単に要件をもらっている場合、そのまま利用するのではなく、きちんと「通信要件表」まで昇華させ、活用してみるが良いと考えております。

スケジュール

そのレビューする資料はいつまでに作成するのかを明確にするための資料となります。
「ネットワークに限定しない資料じゃん！」
はい、おっしゃる通りですが、今回はネットだけではなく全体を見渡せるようにするための資料として必要と考えていただければと思います。
私の経験上、ネットワークシステム単体でリリースが成立することは少ないです。
例えばネットワーク構築後に今度はサーバの基盤総合テストをやったり、アプリテストをやったりとその後のアクションが多いです。
その場合、ネットワークのいつまでに実施しなければならないと言う日程と後続のスケジュールはどうなっているのかを確認しておくことがポイントになってきます。
どうしてもその日までに準備ができなかった場合、どう言う後続の作業に影響するのか、どの程度の日程までなら影響しないのか、レビュー時に確認しておくと流れとしてイメージしやすくなります。

あれこれまとめ

ここまでずらずらっと書きましたが、数をこなして慣れを作る必要もあれば、その企業やシステムの特異な文化が強く根付いてしまっているとどうしても偏りが生じてしまい、その特性に合わせて対応しなければならない場合があると思います。

そんな中でも品質の高いものを作りたい、リリース作業は絶対失敗したくない、今後のことを考えて維持管理していく資料は大事にしたい、などの気持ちは共通しています。

ここに書いたものは1つの意見としてとらえ、今後のネットワークエンジニアとしての生活をより良いものしていただければ幸いです。