【ネスペ午後対策】要求分析と要件定義を徹底解説！上流工程を制する4ステップ

ネットワークスペシャリスト（ネスペ）の午後問題で、「システムの目的や利用者の要望がイマイチ掴みきれない…」と感じた経験はありませんか？あるいは実務において、「顧客の曖昧な要求をどうやって具体的な設計に落とし込めばいいんだ？」と悩んだことはないでしょうか。その悩みの根源は、ネットワーク構築のまさにスタート地点である「要求分析」と「要件定義」にあります。どんなに優れた技術や製品を知っていても、この土台となる上流工程が揺らいでしまえば、その後の設計・構築はすべて的外れなものになりかねません。本連載の第1回では、この最重要フェーズである「要求分析から要件定義まで」の流れを、大きく4つのステップに分けて徹底解説します。各ステップで「何を」「なぜ」「どのように」進めるのかを具体例を交えながら深掘りすることで、現場でそのまま使える実践的な進め方が身につきます。さらに、顧客やシステムの要求を正しく読み解く力は、ネスペ午後試験の長文問題攻略にも直結します。この記事を読んで、上流工程を得意分野に変えましょう。

業務システムからの要求分析│性能・データ量・頻度のヒアリング術

ネットワーク設計の第一歩は、そのネットワークを利用する「業務システム」が何を求めているのかを正確に把握することから始まります。ここでの情報収集が、後の設計品質を大きく左右します。開発担当者や利用者にヒアリングを行う際は、単に「どうしたいですか？」と聞くだけでなく、設計の根拠となる具体的な情報を引き出す必要があります。

最低限押さえるべきは、以下の5つの情報です。

ヒアリングすべき5つの基本情報

これらの情報をまとめる「ヒアリングシート」を作成しておくと、抜け漏れなく要求を収集できます。

【仕事例】ヒアリングのコツは「なぜ？」の深掘り

ヒアリングで重要なのは、相手の言葉の背景にある「目的」を理解することです。例えば、担当者から「とにかく速いネットワークにしてほしい」という要望が出たとします。ここで「承知しました」と鵜呑みにするのではなく、「なぜ、速くする必要があるのでしょうか？」と一歩踏み込んでみましょう。

• 担当者：「とにかく速いネットワークにしてほしい」
• あなた：「承知しました。ちなみに、なぜ速くする必要があるのでしょうか？現状で何かお困りごとが？」
• 担当者：「実は、月末の売上集計バッチが夜中の3時までかかっていて、担当者の残業が問題になっているんだ」
• あなた：「なるほど、それは大変ですね。そのバッチ処理では、具体的にどのようなデータが、どこからどこへ流れているか分かりますか？」

このように「なぜ？」を繰り返すことで、「速くしたい」という曖昧な要求が「月末のバッチ処理時間を短縮したい」という具体的な課題に変わります。これにより、ネットワーク全体を無駄に高速化するのではなく、バッチ処理の通信経路を重点的に改善するという、的確な解決策に繋がるのです。

【具体例】オンラインストアの受注システムの場合

あなたがECサイトのネットワーク担当者だと仮定しましょう。事業部から「タイムセール時にサイトが重くなるのを解消したい」という相談が来ました。この曖昧な要求を、5つの基本情報に沿って分析してみます。

• 性能要件：「重い」とは、注文完了まで現状で最大30秒かかっている状態。これを「いつでも5秒以内」にしたい。
• 送受信拠点：ユーザー（不特定多数の場所）から、クラウド（AWS）上のWebサーバーへ。
• データ量・頻度：セール時のアクセス数は通常時の10倍。秒間1,000リクエストに達する。
• データ種類：商品画像の参照（HTTPS）と、注文情報の書き込み（HTTPS/API）が主。
• 通信の方向：主にユーザーからサーバーへの上り方向の通信。

ここまで具体化できれば、「セール時の秒間1,000リクエストを5秒以内に処理できるネットワーク帯域とサーバー性能」という、明確な設計目標を立てることができるようになります。

現行ネットワークシステムの分析方法│トラフィック調査と問題点の洗い出し

新しいネットワークの設計図を描く前に、まず現在のネットワーク（現行システム）がどのような状態で、どんな課題を抱えているのかを正確に把握する必要があります。これを「As-Is分析（アズイズぶんせき）」と呼びます。これを怠ると、既存の問題点を新しいシステムにそのまま引き継いでしまうことになりかねません。

【身近な例え】
これは、家のリフォームに似ています。新しい間取りを考える前に、まず「今の家のどこが不便か（課題）」「柱や土台はしっかりしているか（現状）」を調べますよね。それと同じで、現状を正しく知ることが、より良い設計への第一歩となります。

トラフィック調査で見るべき5つの重要指標

現状分析の要は、ネットワーク上を流れるデータの量や性質を客観的な数値で把握する「トラフィック調査」です。以下の指標を監視することで、システムの健康状態を診断できます。

【仕事例】ツールを使った稼働状態の把握

これらの指標は、専用のツールを使って効率的に収集・分析します。現場では目的に応じて以下のようなツール（またはその技術）を使い分けます。

• SNMP監視ツール (Zabbix, PRTGなど)
  最も標準的な監視方法。ネットワーク機器から定期的に稼働情報（帯域使用率、CPU使用率など）を収集し、グラフ化します。「ネットワークの健康診断」のように、システムの全体的な状態を定常的に把握するのに適しています。
• フローコレクター (NetFlow, sFlow)
  「誰が(送信元IP)」「誰と(宛先IP)」「どんな会話(プロトコル/ポート番号)を」「どれくらいの時間(通信量)」したかを記録するツールです。これにより、「特定のPCが業務に関係ない動画ストリーミングで帯域を消費している」といった、トラフィックの内訳を詳細に分析できます。
• パケットキャプチャツール (Wireshark)
  通信データ（パケット）そのものを直接覗き見るための、いわば「ネットワークのお医者さんが使う聴診器」です。特定のエラーがなぜ発生するのか、プロトコルのレベルで詳細な原因を調査する、トラブルシューティングの最後の切り札として使われます。

これらの分析を通じて、「月末の特定の時間に経理システムの通信だけが極端に遅くなる」「特定のサーバーからのバックアップ通信が帯域を圧迫している」といった具体的な問題点を洗い出し、次の設計フェーズで解決すべき課題を明確にします。

作業範囲の確定（スコープ定義）│目的・目標・期間設定のポイント

要求分析と現状分析で集めた情報をもとに、次に行うのが「どこからどこまでを、いつまでに、どのような状態にすることを目指すのか」というプロジェクトの全体像、すなわち「作業範囲（スコープ）」の確定です。ここでの定義が曖昧だと、後から「あれもやってほしい」「これも範囲だと思った」といった要求が次々と追加され、プロジェクトが予算超過や納期遅延に陥る「スコープクリープ」という典型的な失敗パターンを招きます。

【身近な例え】
「犬小屋を作って」と頼まれて作り始めたら、途中で「やっぱり2階建てにして」「冷暖房も付けて」と次々要望が増える状況を想像してみてください。最初に「平屋で寝床だけのシンプルな小屋を作る」と範囲を決めておけば、こうした混乱を防げますよね。スコープ定義は、この最初の約束事を決める重要な工程です。

スコープ定義で明確にすべき4つの要素

スコープを定義する際は、関係者全員が同じ認識を持てるよう、以下の要素を文書に落とし込みます。

【仕事例】WBSを使ったタスクの洗い出し

スコープが決まったら、目標達成までに必要な作業をすべて洗い出し、構造化します。この際に用いられるのがWBS (Work Breakdown Structure) です。

WBSは、大きな作業項目をより小さな管理しやすい単位に分解していく手法です。例えば、「ルーターの交換」という作業は、以下のように分解できます。

• ルーター交換
  • 1.1. 設定設計
    • 1.1.1. 現行設定のバックアップ
    • 1.1.2. 新規設定の作成
    • 1.1.3. 設定レビュー
  • 1.2. 機器の設置
    • 1.2.1. データセンター入館申請
    • 1.2.2. 物理設置（ラッキング）
    • 1.2.3. 配線作業
  • 1.3. 切り替え
    • 1.3.1. 事前テスト
    • 1.3.2. 深夜帯での回線切り替え
    • 1.3.3. 動作確認

ここまで分解することで、各タスクの担当者や必要な工数を正確に見積もることが可能になります。最終的に、これらの内容をまとめた計画書を作成し、プロジェクトの責任者や関係部署から「この内容で進めます」という合意形成を得て、このフェーズは完了となります。

ネットワーク要件定義の進め方│機能要件と非機能要件の策定【午後試験対策】

これまでのステップで集めてきた顧客の「要求」を、具体的なシステムの「仕様」に落とし込む工程が「要件定義」です。要求分析が「何に困っているか（What）」を聞き出すことだとすれば、要件定義は「それを技術的にどう解決するか（How）」を定義することです。ネスペ午後試験では、問題文に書かれた要望から、この「要件」を正しく読み解く能力が問われます。

【身近な例え】
医者の診察に例えると分かりやすいでしょう。

• 要求分析：患者の訴えを聞くこと。「お腹が痛いんです」「熱っぽいんです」（＝顧客の要求）
• 要件定義：診察と検査を経て、具体的な治療方針を決めること。「胃炎と診断します。この薬を1日3回飲んで、消化の良いものを食べてください」（＝システムの要件）

要件は、大きく「機能要件」と「非機能要件」の2つに分けて定義します。

機能要件：システムが「何ができるか」

機能要件とは、そのネットワークシステムが提供すべき「機能」に関する要件です。つまり、「～ができること」という形で定義されます。

• 【例1】拠点間接続：東京本社と大阪支社のネットワークを、インターネットVPN（IPsec）で安全に接続できること。
• 【例2】リモートアクセス：社員が自宅から社内ファイルサーバーにアクセスできるVPN機能を提供すること。
• 【例3】ゲストWi-Fi：来客向けに、社内ネットワークとは分離されたインターネット接続専用のWi-Fiを提供できること。

非機能要件：システムの「品質」をどう担保するか

非機能要件は、機能要件以外のすべての要件を指し、システムの品質や性能、信頼性を定義するとても重要な項目です。ネットワーク設計の勘所とも言える部分で、ここで定義した数値が設計のベースラインとなります。

これらの要件をすべて定義し、顧客や関係者と合意した成果物が「要件定義書」です。この文書が、次の工程である「設計」フェーズのインプットとなり、プロジェクト全体の道しるべとなるのです。

まとめ

今回は、ネットワーク構築の最上流工程である「要求分析」から「要件定義」までの4つのステップを解説しました。

1. 業務システムからの要求分析：利用者の要望をヒアリングする
2. 現行システムの分析：現状の課題を客観的に把握する
3. 作業範囲の確定：プロジェクトのゴールと範囲を明確にする
4. 要件定義：要求を具体的な技術仕様に落とし込む

一見地味に見えるかもしれませんが、この上流工程の品質が、プロジェクト全体の成否を決めると言っても過言ではありません。特に、ネスペの午後試験では、長文で書かれた状況設定の中から、今回学んだような「顧客の真の要求」や「システムが満たすべき要件」を正確に抜き出す力が試されます。本記事で解説した思考プロセスは、きっと試験本番でもあなたの助けとなるはずです。

次回、連載第2回では、今回定義した要件定義書をインプットとして、具体的な「ネットワークシステムの設計」フェーズに進んでいきます。