エンジニアが現場で使えるPMOの失敗回避術第8回

【ネットワークエンジニア編】「ブラックボックス」を解消するー属人化を防ぎ、セキュリティと品質を守るマネジメント術

第8回の今回は、ネットワークの「ブラックボックス化」と通信遮断漏れという2つの失敗事例から、属人化を防ぎセキュリティと品質を守るPMO視点の打ち手について解説します。

6:30

はじめに

「エンジニア」とひと口に言っても、ソフトウェア、フロントエンド、サーバーなど、その役割によって現場で直面するトラブルはさまざまです。
本連載では、PMO(Project Management Office)として多くの現場を経験してきた甲州が、それぞれのエンジニアが抱える課題の回避策を深掘りしていきます。

第8回の主役は、「ネットワークエンジニア」です。ネットワークエンジニアは、前回のサーバーエンジニアやクラウドエンジニアと領域が近く、現場によっては兼務されることも多い職種です。自社の情報システム部(情シス)でネットワーク資源やセキュリティを管理している方や、社内SEとしてインフラ全般を支えている方も多く含まれます。

オフィスでWi-Fiがつながる、拠点間で安全にデータが送受信できる、本番環境・ステージング環境・テスト環境が適切に遮断されている――これら「つながって当たり前」の環境を作り上げているのが、ネットワークエンジニアです。近年ではサイバー攻撃の猛威により、大手企業でさえシステム停止に追い込まれるニュースが連日のように報じられています。防犯対策の要であるネットワークエンジニアの重要性は、かつてないほど高まっています。

サイバー攻撃対策を専門に行うセキュリティエンジニアとして専門領域が分かれていたりしますが、ネットワークとセキュリティは切っても切れない領域です。しかし、現場では度重なる仕様変更や継ぎ足し構築により「構成の全体像を把握している人が誰もいない」「昔からいる特定の人しか触れない」という属人化の問題が頻発しています。

この記事は、日々のネットワーク管理やトラブル対応に追われ、「自分の知識はこれで足りているのだろうか」と悩みを感じているネットワークエンジニアや情シス担当者に向けて書いています。ネットワーク全体の全体像を捉え、セキュリティや負荷分散といった広い視野を持つことで、単なる「トラブル対応要員」から「組織を守るセキュリティ・インフラの専門家」へとキャリアアップするためのPMO視点を解説します。

組織の通信とセキュリティをどう守り、透明性を高めていくのか。ここでは、現場でよく発生する2つの失敗事例を見ていきましょう。

失敗事例1：
誰も全体像を分かっていないネットワーク構成

ある企業で、基幹システムの全面刷新プロジェクトが立ち上がりました。PMOとしてネットワーク構成の現状把握を行おうとしたところ、提出された設計書は数年前のもので、実態とは全く異なっていました。

長年にわたり、部署の追加や新しいPaaSの導入、拠点の増設を行うたびに「導入プロジェクトでシステム構築を継ぎ足し」してきたため、旧来の構成図が役に立たなくなっていたのです。ネットワークの全体像を把握しているのは、10年以上在籍しているベテランの社内SEただ1人。「あの設定は〇〇さんに聞かないと分からない」という完全な属人化(ブラックボックス化)に陥っていました。

結果として、刷新プロジェクトの初期段階で「現物調査」をゼロからやり直すことになり、数ヶ月のスケジュール遅延と追加費用が発生してしまいました。さらに最悪なことに、調査の過程で「既に使われていないはずの通信経路」が放置されており、セキュリティ上の大きな抜け道になっていたことも判明したのです。

失敗事例2：
開発効率を優先した「通信遮断漏れ」による本番障害

別の開発現場での話です。アプリケーションエンジニアがテスト環境で新しい機能を検証する際、ネットワークのアクセス制限が厳しく「検証しづらい」という理由で、一時的にネットワークエンジニアへ権限設定の緩和を依頼しました。

ネットワークエンジニアは「開発期間中だけ」という口約束で制限を解除し、テスト環境と本番環境の通信を一部通す設定に切り替えました。しかし、開発工程が進む中でその設定変更は記録に残されていないことから、メンバの変更や体制の変更を繰り返すうちに放置され、設定が元に戻されることもありませんでした。

システムをリリースした数ヶ月後、追加機能の試験を行おうとアプリケーションエンジニアがテスト環境でデータクリーニング処理のスクリプトを実行しました。しかし、そのスクリプトは本番環境にも処理が適用される事を把握しておらず、顧客のデータが一部消失するという大事故に発展してしまったのです。システムリリース前後でテスト環境と本番環境のネットワークが遮断され、相互にアクセスできないように設定を切り替えていれば防げるシステム障害でした。

マネジメント視点でトラブルを未然に防ぐ！回避策

これらの失敗は、担当者の技術力不足だけが原因ではありません。「ドキュメントの形骸化」や「ルール運用の曖昧さ」といったマネジメント視点の欠如が招いた結果です。どうすれば防ぐことができたのでしょうか。

回避策1：ドキュメントの「手動更新」を諦め、現物主義と自動化を取り入れる

失敗事例1の原因は、「構成変更のたびにマニュアルでドキュメントを更新する」という運用が破綻したことにあります。人間が手動で図面を書き直す運用は、忙しい現場では必ず形骸化します。

PMO視点を持つエンジニアは、以下の2つのアプローチで「全体像の可視化」を図ります。

現物主義の徹底：ドキュメントを100%信用せず、定期的にコマンドやネットワークスキャンを用いて「現在の通信経路と接続機器の実態」を確認する癖をつける
ネットワーク構成の自動可視化ツールの導入：最新のネットワーク管理ツールやクラウド機能を活用し、ネットワーク構成図や機器の接続状況がリアルタイムで自動更新される仕組みを構築する

「ドキュメント更新に手間をかける」のではなく、「勝手に最新化される仕組みを作る」ことで、担当者が変わってもブラックボックス化しない環境を作ることができます。

このとき、「新しいツールを入れることができないから」という理由でドキュメント更新に切り替える現場があります。ドキュメント更新の運用が回る場合はそれでも良いですが、可能な限り自動化をおすすめします。

新しいツールを導入できなくても、スクリプトを作成することでネットワーク状態を自動的に把握することは可能です。ぜひ取り組んでみてください。