顧客へのヒアリング質問｜ネットワーク要件定義で確認すべき50項目

2026年8月11日

ネットワーク上級編 09／全70記事

この記事は、「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」の第9回です。

第1章では、顧客の要望や業務上の条件を整理し、ネットワーク設計で判断できる具体的な要件へ変換する方法を学びます。

← 前の記事：移行・切り替え要件の整理上級編一覧次の記事：要件の優先順位を決める方法 →

NETWORK ADVANCED｜CHAPTER 1 REQUIREMENTS

顧客へのヒアリング質問｜ネットワーク要件定義で確認すべき50項目

要件定義では「何を聞けばよいか」だけでなく、回答の背景を確認し、曖昧な表現を設計条件まで具体化することが重要です。この記事では、ネットワーク案件で使える50のヒアリング質問と、回答を要件へ変換するための深掘り方法を解説します。

対象レベル Level 3〜4・上級

想定読了時間 約30分

身につく成果 要件定義の質問を組み立てられる

前提知識 上級編01〜08

演習環境 紙・Excel等

これまでの記事では、現状構成、利用者・端末数、可用性、性能、セキュリティ、運用・監視、移行・切り替えなど、要件定義で整理すべき内容を個別に学んできました。

しかし実際の打ち合わせでは、顧客が最初から「可用性要件は○○です」と整理して話してくれるとは限りません。

ネットワークエンジニア側から質問し、 業務上の目的・現在の課題・数値・制約・優先順位を引き出す 必要があります。

この記事を読み終えるとできること

ヒアリングの目的を説明できる
10分類・50項目の質問を使える
曖昧な回答を深掘りできる
技術質問と業務質問を使い分けられる
回答を要件候補へ変換できる
未決事項を課題として管理できる

要件定義におけるヒアリングとは

最初に覚える定義

要件定義におけるヒアリングとは、顧客の要望・業務・現状・制約を質問によって明らかにし、ネットワークが満たすべき条件へ整理する作業です。

ヒアリングというと、「質問表を上から順番に読み上げる作業」を想像するかもしれません。

しかし、実務で重要なのは質問そのものではありません。 その回答が、どの設計判断に影響するのかを考えながら聞くこと です。

質問の目的は「情報を集めること」だけではない

たとえば、次の質問をしたとします。

質問：ネットワークが停止してもよい時間はどのくらいですか？

この質問の目的は「30分です」という数字を記録することだけではありません。

どの業務が停止するのか
30分を超えるとどのような影響があるのか
すべての通信で同じ条件なのか
営業時間外であれば停止できるのか
障害時に手動切り替えでも間に合うのか

といった背景まで確認することで、冗長化や切り替え方式を検討するための材料になります。

ヒアリングは「質問 → 回答」で終わりではありません。

回答の背景を確認し、「だからネットワークは何を満たす必要があるのか」まで整理して初めて、要件定義につながります。

ヒアリングの基本的な進め方

顧客ヒアリングは、次の流れで進めると整理しやすくなります。

1 仮説事前資料を読む

2 質問事実を確認

3 深掘り 理由を確認

4 具体化 数値・条件へ

5 確認認識を合わせる

6 記録要件・課題化

事前に資料を確認しておく

ヒアリング当日に初めて案件の内容を見るのではなく、入手できる資料には事前に目を通しておきます。

現行ネットワーク構成図
機器一覧
IPアドレス一覧
回線一覧
拠点一覧
障害履歴
既存の運用資料
今回の提案依頼書やRFP

すでに資料に書かれている内容をすべて質問し直すより、「資料では○○と理解していますが、現在も同じでしょうか」と確認した方が、限られた打ち合わせ時間を有効に使えます。

ネットワーク要件定義で顧客へ確認する質問50選

ここからは、ヒアリング質問を10分類に分けて確認します。

すべての案件で50問をそのまま読み上げる必要はありません。案件の規模や対象範囲に応じて、必要な質問を選択してください。

1．目的・背景・対象範囲

最初に「なぜこの案件を行うのか」を確認します。

今回、ネットワークを新規導入・更改する主な目的は何ですか？ 老朽化、障害対策、拠点追加、クラウド移行、セキュリティ強化など、プロジェクトの出発点を確認します。
現在、どのような問題や不満がありますか？ 通信遅延、障害頻発、運用負荷、機器保守切れなど、解決すべき課題を把握します。
今回のプロジェクトで最も実現したいことは何ですか？ 複数の要求がある場合でも、特に重要な目的を確認します。
今回の対応範囲はどこからどこまでですか？ LAN、WAN、無線LAN、ファイアウォール、クラウド、監視などの対象範囲を確認します。
今回の対象外として明確にしておくものはありますか？ サーバー、端末設定、アプリケーションなど、責任分界を明確にします。

2．現行ネットワーク

新しい構成だけでなく、現在の環境を把握します。

現在のネットワーク構成図はありますか？ 最新の物理構成図・論理構成図が存在するか確認します。
現在使用しているネットワーク機器と回線を教えてください。 メーカー、型番、OS、保守期限、回線種別などを確認します。
現在のIPアドレス・VLAN・ルーティング方式はどのようになっていますか？ 既存設計との整合性や移行時の制約を確認します。
現在発生している障害や既知の問題はありますか？ 頻度・発生時間・影響範囲・暫定対応も確認します。
今回も継続利用しなければならない機器・回線・設定はありますか？ 既存設備を残す必要がある場合、設計上の制約になります。

3．利用者・端末・拠点

規模と将来増加を確認します。

現在の利用者数と、想定する最大利用者数は何人ですか？ 現在値だけでなく、ピーク時の利用者数も確認します。
ネットワークへ接続する端末は何台ありますか？ PC、スマートフォン、IP電話、プリンター、IoTなど種類別に確認します。
同時に接続する可能性がある端末は何台ですか？ 特に無線LANでは、総端末数より同時接続数が重要です。
対象となる拠点はいくつありますか？ 本社、支店、店舗、倉庫、データセンターなどを整理します。
今後3年程度で、利用者・端末・拠点はどの程度増える予定ですか？ 将来拡張に必要なポート、IPアドレス、帯域などを検討する材料になります。

4．性能・帯域

「速くしたい」を測定可能な条件へ変換します。

ネットワーク上で主に利用するアプリケーションは何ですか？ Web、ファイル共有、VDI、音声、Web会議、バックアップなどを確認します。
現在の平均通信量とピーク時の通信量は分かりますか？ 監視データがある場合は実測値を確認します。
通信が集中する時間帯はありますか？ 始業時、バックアップ時間、月末処理などのピーク要因を確認します。
遅延やパケットロスの影響を受けやすい通信はありますか？ 音声・映像・リアルタイム処理などを確認します。
現在、利用者が「遅い」と感じている具体的な操作は何ですか？ 単純に回線帯域の問題と決めつけず、対象アプリケーションや発生条件を特定します。

5．可用性・冗長化

「止めたくない」を業務影響と許容停止時間へ変換します。

ネットワークが停止した場合、どの業務が影響を受けますか？ 受発注、決済、電話、製造など、ビジネス影響を確認します。
ネットワーク停止を何分・何時間まで許容できますか？ 「止められない」ではなく、可能な限り時間で確認します。
特に停止させてはいけない通信や拠点はありますか？ すべてを同じレベルで冗長化する必要があるとは限りません。
障害発生時は自動切り替えが必要ですか？ 手動切り替えで許容できるかも確認します。
メンテナンスによる計画停止が可能な時間帯はありますか？ 夜間・休日など、保守作業を実施できる時間を確認します。

6．セキュリティ

守る対象・許可通信・管理方法を確認します。

ネットワーク上で特に保護する必要がある情報やシステムは何ですか？ 重要資産を把握してからセキュリティ方式を検討します。
利用者・端末・サーバー間で分離する必要があるネットワークはありますか？ 部門、サーバー、ゲスト、管理、IoTなどの分離要件を確認します。
許可する通信・禁止する通信に決まりはありますか？ 送信元・宛先・プロトコル・ポートなどの条件を確認します。
ネットワーク機器への管理アクセスは誰に許可しますか？ 管理者、接続元端末、管理経路、認証方式を確認します。
社内規程・監査・業界基準など、守る必要があるルールはありますか？ 技術だけでなく、組織上の制約を確認します。

7．WAN・インターネット・クラウド

外部接続や拠点間通信の条件を確認します。

どの拠点同士で通信する必要がありますか？ 本社集中型なのか、拠点間の直接通信も必要なのかを確認します。
インターネットへの出口はどこに配置しますか？ 本社集約、各拠点、クラウド経由など、現在と将来構想を確認します。
AWS・Azureなどのクラウドサービスを利用していますか？ 現在だけでなく、今後のクラウド移行予定も確認します。
オンプレミスとクラウド間で必要な通信は何ですか？ 通信先、通信量、遅延、暗号化、冗長化などへ展開します。
既存の回線事業者やクラウド接続方式に指定・制約はありますか？ 契約継続や社内標準が設計の制約になることがあります。

8．運用・監視・保守

導入後に誰がどのように運用するのかを確認します。

導入後のネットワークは誰が運用しますか？ 顧客自身、24時間監視部門、外部ベンダーなど、体制を確認します。
どの機器・回線・通信を監視する必要がありますか？ 死活、インターフェース、CPU、メモリ、トラフィックなどを検討する材料になります。
障害を検知した場合、誰へどの方法で通知しますか？ メール、電話、チャット、監視センターなどを確認します。
ログはどの程度の期間保存する必要がありますか？ 障害調査、監査、セキュリティ調査などの目的も確認します。
設定変更・バックアップ・障害対応にはどのような運用ルールがありますか？ 承認フローや既存運用との整合性を確認します。

9．移行・切り替え・試験

新しいネットワークへ安全に移行する条件を確認します。

新ネットワークへの切り替えは一括と段階移行のどちらを想定していますか？ 対象規模や業務影響から移行方式を検討します。
切り替え作業を実施できる日時・時間帯はありますか？ 夜間、休日、月末不可などの条件を確認します。
新旧ネットワークを並行稼働させる必要はありますか？ 並行期間が必要な場合、接続やルーティング設計にも影響します。
どの状態になったら切り戻しを判断しますか？ 切り戻し条件を事前に明確化します。
切り替え後、どの試験に合格すれば作業完了と判断しますか？ 疎通、業務アプリケーション、冗長化、性能、監視などを確認します。

10．予算・スケジュール・成果物

技術以外の制約も要件定義で整理します。

今回のプロジェクトに予算上の上限や目安はありますか？ 構成案を比較するときの重要な制約条件になります。
ネットワークを利用開始しなければならない日はいつですか？ 設計・調達・構築・試験・移行から逆算します。
機器・回線の調達について指定や納期上の制約はありますか？ 長納期製品や回線開通時期を早期に確認します。
他システムや他プロジェクトとの依存関係はありますか？ サーバー更改、クラウド移行、オフィス移転などとの前後関係を確認します。
最終的に必要となる成果物と、その承認者は誰ですか？ 要件定義書、基本設計書、構成図、試験結果などの提出物と承認プロセスを確認します。

50問すべてを聞くことが目的ではありません。

最終的な目的は、設計者が構成・方式を判断するために必要な情報を不足なく整理することです。

顧客の回答を深掘りする方法

顧客から最初に返ってくる回答は、そのまま設計条件として使えるとは限りません。

特に次のような言葉が出てきたら、追加質問が必要です。

できるだけ
なるべく
多い
速い
遅い
すぐに
ほとんど止められない
セキュリティを強く
将来増えても大丈夫なように

深掘りするときの5つの方向

方向	質問例	目的
理由	なぜその条件が必要ですか？	業務背景を把握する
対象	どの利用者・通信・拠点が対象ですか？	対象範囲を限定する
数量	何人・何台・何Mbpsですか？	数値化する
時間	何分以内・何時から何時までですか？	時間条件を具体化する
例外	この条件に例外はありますか？	見落としを防ぐ

例：「ネットワークを止めたくない」

どの業務が停止しますか？ 業務影響を確認します。
何分までなら停止できますか？ 許容停止時間へ変換します。
営業時間外でも停止できませんか？ 計画停止の可否を確認します。
どの機器・回線の障害を想定していますか？ 冗長化対象を確認します。
自動切り替えが必要ですか？ 切り替え方式の条件を確認します。

この結果、単なる「止めたくない」という要望から、たとえば次のような要件候補へ変換できます。

要件候補： 営業時間中に主要ネットワーク機器または主回線の単一障害が発生した場合も、主要業務通信を継続できること。

この段階ではまだ具体的な製品やプロトコルは決めません。どの方式で実現するかは、基本設計で検討します。

悪い質問と良い質問の違い

質問の仕方によっては、顧客の本当の目的を確認できないことがあります。

例1：冗長化

× 悪い質問

ルーターは冗長化しますか？

○ 良い質問

ルーターが故障して通信できなくなった場合、どの業務に影響がありますか？また、どの程度の停止時間まで許容できますか？

最初から「冗長化する・しない」の二択にすると、顧客が技術方式を選ばなければならなくなります。

まず業務上必要な可用性を確認し、その要件を満たす方式をエンジニアが検討します。

例2：帯域

× 悪い質問

1Gbpsで足りますか？

○ 良い質問

どのアプリケーションを何人で利用しますか？現在のピーク通信量や今後の利用増加予定は分かりますか？

例3：セキュリティ

× 悪い質問

VLANを分けますか？

○ 良い質問

相互に通信させてはいけない利用者・端末・システムはありますか？管理ネットワークへ接続できる人は誰ですか？

顧客には「何を実現したいか」を聞き、エンジニアが「どう実現するか」を考えます。

ヒアリングする順番も重要

最初からIPアドレスやルーティングの細かな話を始めると、プロジェクトの本来の目的を見失うことがあります。

基本的には、次の順番で確認すると整理しやすくなります。

目的・背景を聞く なぜ今回のネットワーク導入・更改が必要なのかを確認します。
対象範囲を決める 今回どこまで対応するのかを明確にします。
現状を確認する 現行構成、利用者、端末、通信、課題を整理します。
将来像を聞く 拠点・端末・クラウド利用などの増加計画を確認します。
非機能要件を確認する 性能、可用性、セキュリティ、運用などを確認します。
移行条件を確認する 切り替え方法、作業時間、試験、切り戻し条件を確認します。
制約を確認する 予算、納期、既存設備、指定製品などを整理します。
最後に認識を読み合わせる 決定事項・未決事項・次回までの宿題を確認します。

実際の打ち合わせでは話題が前後することがあります。順番どおりに進めることより、 最終的に必要な情報が整理できていることが重要です。

顧客がその場で回答できない場合はどうするか

要件定義では、すべての質問にその場で答えが返ってくるとは限りません。

むしろ、複数部署が関係する案件では、「ネットワーク担当者だけでは分からない」という項目が多く発生します。

分からない回答を推測で埋めない

「たぶん100人くらいだと思います」「おそらく停止できないと思います」といった曖昧な回答を、そのまま確定要件として扱わないようにします。

回答できない項目は、次の形で課題管理します。

確認項目	担当者	回答期限	状態
3年後の想定利用者数	総務部	○月○日	確認中
受発注システムの許容停止時間	業務システム担当	○月○日	未回答
ログ保存期間	セキュリティ担当	○月○日	確認中

「誰が」「いつまでに」回答するかまで決めることで、未決事項の放置を防ぎます。

ヒアリングシートに残す内容

ヒアリングでは質問と回答だけを記録するのではなく、後工程で使える形に整理しておくことが重要です。

ヒアリングシートの推奨項目

項目	記載内容
分類	性能、可用性、セキュリティなど
質問	顧客へ確認した内容
回答	顧客から得た事実
背景・理由	なぜその条件が必要なのか
要件候補	設計条件として整理した内容
状態	確定・暫定・未決
確認先	追加回答が必要な担当者
期限	回答・決定期限

回答だけでなく「背景」を残す

質問	回答	背景	要件候補
停止時間はどの程度許容できますか？	営業時間中は5分以内	受発注業務がネットワークに依存	主要業務通信の長時間停止を防止する構成とする
管理アクセスは誰が行いますか？	インフラ担当5名のみ	一般端末から管理画面へ接続させたくない	管理通信を一般利用者ネットワークから分離する

背景が残っていれば、後から設計変更が発生した場合も「なぜこの要件を設定したのか」を追跡できます。

顧客とのヒアリング会話例

実際のヒアリングでは、質問表を読み上げるのではなく会話の中で条件を具体化します。

顧客：今回は、とにかくネットワークを止まりにくくしたいです。

エンジニア： 承知しました。現在ネットワークが停止した場合、特に影響の大きい業務は何でしょうか？

顧客： 受発注システムですね。営業中に止まると注文処理ができません。

エンジニア： その場合、どの程度の停止時間までであれば業務上許容できますか？

顧客： 数分なら何とかできますが、30分も止まるとかなり困ります。

エンジニア： ありがとうございます。では、営業時間中の主要業務通信については短時間で復旧できることを要件候補として整理します。あわせて、機器障害だけでなく回線障害時も通信継続が必要か確認させてください。

このように、 要望 → 業務影響 → 数値・条件 → 要件候補 の順番で整理します。

上流工程では、技術用語を多く話すことより、顧客の業務を理解して設計判断に必要な情報を引き出す力が重要です。

顧客ヒアリングで使われる英語表現

海外拠点や海外ベンダーとの打ち合わせでは、要件確認を英語で行う場合があります。

英語表現	意味
What is the primary objective of this project?	このプロジェクトの主な目的は何ですか？
What problems are you experiencing with the current network?	現在のネットワークでどのような問題が発生していますか？
How many users and devices will connect to the network?	何人の利用者と何台の端末が接続しますか？
What is the acceptable downtime?	許容できる停止時間はどの程度ですか？
Are there any security or compliance requirements?	セキュリティやコンプライアンス上の要件はありますか？
Are there any technical constraints?	技術上の制約はありますか？
What is the expected growth over the next three years?	今後3年間でどの程度の増加を想定していますか？
Who will operate and maintain the network?	ネットワークの運用・保守は誰が担当しますか？
When can the cutover be performed?	切り替え作業はいつ実施できますか？
Who is responsible for approving this requirement?	この要件の承認責任者は誰ですか？

英語でも考え方は同じです。 Yes / Noだけで終わる質問より、 What、How many、How long、Who、Whenなどを使って条件を具体化します。

理解度チェック

ヒアリングの目的と質問の組み立て方を理解できているか確認しましょう。

問題1．顧客から「ネットワークを止まりにくくしてください」と言われました。最初の追加質問として適切なのはどれですか？

VRRPを使いますか？
ルーターを2台購入しますか？
ネットワーク停止時にどの業務へ影響がありますか？
Cisco製品でよいですか？

解答を見る

正解：C

最初に技術方式を決めるのではなく、停止時の業務影響や許容停止時間を確認して可用性要件へ変換します。

問題2．「通信が遅い」という回答を得た場合、次に確認すべき内容として不適切なものはどれですか？

どのアプリケーションが遅いか
いつ発生するか
現在の通信量
すぐに10Gbpsスイッチへ交換するか

解答を見る

正解：D

原因や必要性能を確認する前に製品・速度を決めてはいけません。

問題3．顧客が質問へ回答できなかった場合、どのように扱うべきですか？

解答を見る

推測で確定せず、 未決事項として確認担当者と回答期限を設定します。

問題4．ヒアリングシートに「回答」だけでなく「背景・理由」を残すメリットは何ですか？

解答を見る

後工程で「なぜその要件が必要なのか」を追跡でき、設計判断や変更時の影響確認に利用できます。

問題5．顧客ヒアリングの目的を一文で説明してください。

解答例を見る

顧客の要望・業務・現状・制約を確認し、ネットワークが満たすべき具体的な設計条件へ整理することです。

実践演習：顧客ヒアリングを組み立てよう

あなたは、ある企業の本社ネットワーク更改を担当することになりました。

顧客から最初に聞いている情報

社員数：約300人
本社ネットワークを5年以上使用している
最近「インターネットが遅い」という申告が増えている
ネットワーク障害で業務を止めたくない
今後クラウドサービスの利用を増やす予定
半年後までに新ネットワークへ切り替えたい

課題1．追加質問を10個考える

この情報だけでは設計できません。顧客へ追加で確認したい質問を10個考えてください。

1．
2．
3．
4．
5．
6．
7．
8．
9．
10．

質問例を見る

「インターネットが遅い」と感じる具体的なアプリケーションは何ですか？
遅延が発生しやすい時間帯はありますか？
現在のインターネット回線の帯域とピーク通信量は分かりますか？
ネットワーク停止時に影響を受ける主要業務は何ですか？
許容できる停止時間はどの程度ですか？
現在使用している主要ネットワーク機器と回線を教えてください。
今後利用を予定しているクラウドサービスは何ですか？
クラウド利用時にオンプレミスとの通信は必要ですか？
切り替え作業を実施できる日時・時間帯はありますか？
今回の予算上限や既存設備の継続利用条件はありますか？

課題2．曖昧な回答を具体化する

顧客から次の回答を得ました。

「営業時間中はネットワークをほとんど止められません。」

この回答を要件へ変換するために、どのような追加質問が必要でしょうか。

追加質問を書いてみましょう。

解答例を見る

営業時間は何時から何時までですか？
何分までの停止なら許容できますか？
停止した場合、どの業務に影響しますか？
すべての通信で同じ可用性が必要ですか？
回線障害と機器障害の両方で通信継続が必要ですか？
自動切り替えが必要ですか？
営業時間外の計画停止は可能ですか？

課題3．ヒアリング結果を要件候補へ変換する

次のヒアリング結果を確認してください。

質問	顧客回答
ネットワーク停止時の影響	受発注・Web会議・クラウド利用が停止する
許容停止時間	営業時間中は5分程度まで
障害対象	回線・主要機器の故障に備えたい
計画停止	日曜日深夜なら可能