対象レベル：Level 2〜3
想定読者：運用・構築経験から、要件定義や基本設計へ進みたいネットワークエンジニア
この記事で得られる成果：顧客ヒアリングで使える質問リストを作成できる
関連スキル：要件定義／顧客ヒアリング／ネットワーク設計／リスク管理
ネットワークの要件定義では、顧客から「拠点間をつなぎたい」「Wi-Fiを導入したい」「ネットワークを速くしたい」といった要望が提示されます。
しかし、その言葉をそのまま設計に落とし込むことはできません。
例えば「ネットワークを止めたくない」という要望だけでは、次の内容が分からないからです。
- 何分までの停止なら許容できるのか
- どのシステムを優先して守るのか
- 回線だけを冗長化するのか
- ルーターやスイッチも冗長化するのか
- 障害時に自動で切り替える必要があるのか
- 冗長化にどこまで予算を使えるのか
要件定義で重要なのは、顧客の言葉を聞くだけではありません。
曖昧な要望を、設計・試験・運用で確認できる具体的な条件へ変換すること
本記事では、ネットワークエンジニアが要件定義で確認すべき50の質問を、10の分野に分けて解説します。
無料Excelテンプレートを用意しました
また、本記事で紹介する「ネットワーク要件定義で確認すべき50の質問」を、実際の顧客ヒアリングで使えるExcelテンプレートにまとめました。
質問を確認するだけでなく、次の項目も一緒に管理できます。
- 顧客からの回答
- 確認状況
- 要件への反映内容
- 担当者
- 回答期限
- 備考・追加確認事項
確認状況は「未確認・確認中・確認済・対象外」から選択でき、確認済み件数と進捗率も自動で集計されます。
案件ごとにコピーし、内容を自由に編集してご利用ください。
ファイル形式： Excel（.xlsx）
料金： 無料
メールアドレス登録： 不要
収録内容： ネットワーク要件ヒアリング50項目
※個人学習、社内業務、担当案件で編集して利用できます。ファイルそのものの転載、販売、再配布はご遠慮ください。
ネットワーク要件定義で確認する10分野
ネットワークの要件定義では、主に次の10分野を確認します。
- プロジェクトの目的と対象範囲
- 現行ネットワークの構成
- 利用者・端末・拠点
- 通信量と性能
- 可用性と冗長化
- セキュリティ
- WAN・インターネット・クラウド接続
- 運用・監視・保守
- 移行・試験・切り替え
- 予算・スケジュール・成果物
最初から機器の型番やプロトコルを決めるのではなく、まずは業務上の目的と制約を整理します。
1. プロジェクトの目的と対象範囲
質問1：今回のネットワーク導入・更改の目的は何ですか？
最初に確認すべきなのは、プロジェクトの目的です。
単なる機器の老朽化対応なのか、拠点追加、クラウド移行、セキュリティ強化、通信速度の改善なのかによって、設計の優先順位が変わります。
「ネットワークを新しくすること」ではなく、その先にある業務上の目的を確認しましょう。
質問2：現在、どのような問題が発生していますか？
現行環境に対する不満や障害を確認します。
例えば、次のような問題です。
- 通信が遅い
- 特定の時間帯に切断される
- 障害原因を特定できない
- 拠点追加に時間がかかる
- 管理者しか設定内容を把握していない
- 保守期限が切れている
問題を具体化することで、新しいネットワークで何を改善すべきかが明確になります。
質問3：今回の対象範囲はどこまでですか？
対象範囲が曖昧なまま進むと、後から「それも対応範囲だと思っていた」という認識齟齬が発生します。
次の対象を明確にします。
- LAN
- WAN
- インターネット回線
- 無線LAN
- ファイアウォール
- クラウド接続
- DNS・DHCP
- 監視システム
- 配線工事
- 運用設計
対象外の範囲も、要件定義書に明記することが重要です。
質問4：今回の変更によって影響を受ける業務やシステムは何ですか？
ネットワーク変更が、どの業務に影響するかを確認します。
例えば、販売管理、Web会議、IP電話、工場設備、電子カルテなど、ネットワーク停止が直接業務停止につながるシステムもあります。
業務への影響度は、冗長化や移行方式を決める判断材料になります。
質問5：今回のプロジェクトで最も優先する項目は何ですか？
すべての要望を同時に最大化することは困難です。
次のうち、何を優先するのかを確認します。
- コスト
- 通信性能
- 可用性
- セキュリティ
- 運用のしやすさ
- 拡張性
- 導入スピード
優先順位が分からない場合は、「予算が増えても止まりにくい構成を選ぶのか」など、比較形式で質問すると回答を得やすくなります。
2. 現行ネットワークの構成
質問6：現在のネットワーク構成図はありますか？
まずは既存の構成図を確認します。
ただし、構成図が存在していても、現状と一致しているとは限りません。
最終更新日、作成者、更新ルールを確認し、必要に応じて現地調査や機器の設定確認を行います。
質問7：現在使用しているネットワーク機器と型番は何ですか？
ルーター、スイッチ、ファイアウォール、無線LANアクセスポイントなどの情報を確認します。
あわせて次の情報も整理します。
- メーカー
- 型番
- OS・ファームウェア
- 導入時期
- 保守期限
- 設置場所
- 管理担当者
保守終了製品が含まれている場合は、更改対象として検討します。
質問8：現在のIPアドレス体系とVLAN構成はどうなっていますか？
IPアドレス、サブネット、VLANの割り当て状況を確認します。
特に注意したいのが、ルールなく増設されたネットワークです。
- 空きアドレスは十分にあるか
- 拠点ごとの割り当てルールがあるか
- サーバーと端末が分離されているか
- 用途不明のVLANが残っていないか
- クラウド側のアドレスと重複していないか
将来的な拡張を考慮したIPアドレス設計が必要です。
質問9：現在利用しているルーティング方式は何ですか？
スタティックルート、OSPF、BGPなど、現在のルーティング方式を確認します。
あわせて、経路制御に関する次の情報も確認します。
- 経路の優先順位
- デフォルトルート
- 冗長経路
- 経路集約
- 再配送
- クラウドとの経路交換
既存環境と新環境を一時的に並行稼働させる場合、経路制御が複雑になりやすいため注意が必要です。
質問10：現在のネットワークで定期的に発生している障害はありますか？
障害管理表、問い合わせ履歴、監視アラートなどを確認します。
顧客から「特に問題はない」と言われた場合でも、現場担当者に確認すると、通信遅延や瞬断が日常的に発生していることがあります。
既知の問題を新環境へ引き継がないことが重要です。
3. 利用者・端末・拠点
質問11：ネットワークを利用するユーザー数は何人ですか？
現在の人数だけでなく、将来の増加も確認します。
例えば、現在100人でも、3年後に200人へ増える予定があれば、スイッチポート数、DHCPのアドレス数、無線LANの収容数などに影響します。
質問12：接続する端末にはどのような種類がありますか？
パソコンだけでなく、ネットワークへ接続するすべての端末を確認します。
- パソコン
- スマートフォン
- タブレット
- IP電話
- 複合機
- 監視カメラ
- IoT機器
- 工場設備
- ゲスト端末
- 私物端末
端末ごとに必要な通信先やセキュリティポリシーが異なります。
質問13：対象となる拠点数と各拠点の規模はどの程度ですか？
本社、支店、工場、店舗、データセンターなど、対象拠点を整理します。
拠点ごとに次の情報を確認します。
- 利用者数
- 端末数
- フロア数
- 回線
- 重要業務
- 管理者の有無
- 利用時間
- 将来の増員予定
すべての拠点に同じ構成を導入するのではなく、規模や重要度に応じた標準パターンを作る方法もあります。
質問14：無線LANを利用するエリアと利用者数はどの程度ですか？
無線LANでは、単にアクセスポイントを設置するだけでは不十分です。
次の情報を確認します。
- 利用するフロア
- 会議室
- 執務室
- 倉庫
- 屋外
- 同時接続台数
- 端末の移動範囲
- 壁や棚などの遮蔽物
- 電波干渉の可能性
必要に応じて、現地で無線LANのサイトサーベイを行います。
質問15：社外や自宅からネットワークへ接続する利用者はいますか？
リモートワーク、出張、保守作業など、社外からの接続要件を確認します。
接続方式としては、リモートアクセスVPN、ゼロトラスト型のアクセスサービス、仮想デスクトップなどが考えられます。
利用者数、利用端末、認証方式、接続可能時間も確認しましょう。
4. 通信量と性能
質問16：どのようなアプリケーションや通信を利用しますか？
ネットワークを流れる主な通信を確認します。
- Webアクセス
- メール
- ファイル共有
- Web会議
- 音声通話
- 基幹システム
- クラウドサービス
- バックアップ
- 監視カメラ
- 大容量データ転送
通信の種類によって、帯域、遅延、パケットロスに対する要件が異なります。
質問17：現在の通信量とピーク時間帯はどの程度ですか？
平均値だけでなく、最大通信量を確認します。
特に、始業時間、昼休み、バックアップ実行時、月末処理など、特定の時間帯に通信が集中することがあります。
可能であれば、既存機器や監視システムから実測値を取得します。
質問18：必要な回線速度やポート速度はどの程度ですか？
「速いネットワークが欲しい」という要望を、具体的な数値へ変換します。
例えば、次の選択肢があります。
- 端末接続：1Gbps
- サーバー接続：10Gbps
- スイッチ間接続：10Gbps以上
- インターネット回線：1Gbps
- 拠点間回線：100Mbps〜1Gbps
ただし、契約回線速度だけでなく、実効速度や共有型・帯域保証型の違いも確認する必要があります。
質問19：許容できる遅延、パケットロス、ジッターはどの程度ですか？
音声通話、Web会議、リアルタイム制御などでは、帯域だけでなく通信品質が重要です。
顧客が具体的な数値を把握していない場合は、利用アプリケーションの推奨要件を確認します。
試験時に測定できる形で、性能要件を定義することが重要です。
質問20：今後、通信量が増加する予定はありますか？
将来の利用者増加、クラウド移行、拠点追加、監視カメラ導入などを確認します。
現在の通信量だけで設計すると、導入後すぐに帯域やポートが不足する可能性があります。
3年後や5年後の想定も含めて確認しましょう。
5. 可用性と冗長化
質問21：ネットワークが停止した場合、どの業務に影響しますか？
ネットワーク停止による業務影響を確認します。
「止めたくない」という要望だけでなく、停止によって発生する損失や影響を整理することが重要です。
- 売上が止まる
- 顧客対応ができなくなる
- 工場の生産が止まる
- 社内業務だけが一時的に利用できなくなる
影響度に応じて、冗長化の範囲を決定します。
質問22：許容できる停止時間はどの程度ですか？
「24時間365日停止できない」のか、「夜間であれば数時間停止できる」のかを確認します。
可能であれば、次のような具体的な数値にします。
- 年間停止時間
- 1回あたりの許容停止時間
- 復旧目標時間
- 切り替えに許容できる時間
質問23：どこまで冗長化する必要がありますか？
冗長化する対象を確認します。
- インターネット回線
- WAN回線
- ルーター
- ファイアウォール
- コアスイッチ
- 電源
- 配線経路
- クラウド接続
- DNS・DHCPサーバー
一部だけを冗長化しても、単一障害点が残っている場合があります。
質問24：障害時の切り替えは自動と手動のどちらが必要ですか？
自動切り替えが必要なのか、運用担当者による手動切り替えでよいのかを確認します。
自動化すると復旧は速くなりますが、構成の複雑化や誤検知による不要な切り替えも考慮する必要があります。
質問25：計画停止が可能な曜日や時間帯はいつですか？
メンテナンス、機器交換、ファームウェア更新などのために、停止可能時間を確認します。
- 平日夜間
- 土日
- 月末以外
- 営業時間外
- 年末年始
停止可能時間が非常に短い場合、事前構築や段階的な切り替えが必要になります。
6. セキュリティ
質問26：ネットワークをどの単位で分離する必要がありますか？
部署、端末、システム、利用者属性などに応じて、ネットワーク分離の要件を確認します。
例えば、次の分離が考えられます。
- 社内端末とゲスト端末
- サーバーとクライアント
- 開発環境と本番環境
- 管理端末と一般端末
- IoT機器と業務端末
分離した後に、どの通信を許可するかも確認します。
質問27：許可する通信と禁止する通信は何ですか？
ファイアウォールやアクセスリストを設計するために、通信要件を整理します。
最低限、次の情報が必要です。
- 送信元
- 送信先
- プロトコル
- ポート番号
- 通信方向
- 利用目的
- 必要となる期間
「すべて許可してから不要な通信を閉じる」のではなく、必要な通信だけを許可する考え方が基本です。
質問28：ネットワークへ接続する際の認証は必要ですか？
誰が、どの端末から接続しているのかを識別する必要があるか確認します。
認証方式には、次のようなものがあります。
- IEEE 802.1X
- MACアドレス認証
- Web認証
- 多要素認証
- 証明書認証
- VPN認証
端末や利用者の管理方法も含めて検討します。
質問29：遵守すべき社内規程や業界基準はありますか？
顧客のセキュリティポリシーや、業界固有の基準を確認します。
例えば、ログ保存期間、暗号化方式、外部接続制限、管理者認証などに指定がある場合があります。
規程の存在だけでなく、具体的にネットワーク設計へ影響する項目を確認しましょう。
質問30：管理アクセスはどの端末・場所から許可しますか？
ルーター、スイッチ、ファイアウォールなどへの管理アクセス要件を確認します。
- 管理用端末だけに限定する
- 管理用VLANを使用する
- 社外からの接続を禁止する
- VPN経由だけ許可する
- 踏み台サーバーを経由する
- 多要素認証を使用する
管理通信には、TelnetではなくSSHやHTTPSなどの暗号化された方式を使用します。
7. WAN・インターネット・クラウド接続
質問31：拠点間でどのような通信が必要ですか？
拠点間で利用するシステムと通信方向を確認します。
すべての拠点が本社を経由するのか、拠点同士が直接通信するのかによって、WAN構成が変わります。
質問32：インターネットへの出口はどこに設置しますか？
本社に集約するのか、各拠点から直接インターネットへ接続するのかを確認します。
クラウドサービスの利用が多い場合、すべての通信を本社経由にすると、回線負荷や遅延が増える可能性があります。
質問33：利用中または利用予定のクラウドサービスは何ですか？
AWS、Azure、Google Cloud、Microsoft 365、各種SaaSなどの利用状況を確認します。
クラウドとの接続方式として、インターネットVPN、専用線、閉域接続などを検討します。
質問34：クラウドや外部環境とIPアドレスが重複していませんか？
オンプレミス、クラウド、取引先のIPアドレスが重複していると、相互接続が難しくなります。
接続前に、各環境のIPアドレス範囲を確認します。
重複がある場合は、アドレス変更やNATなどの対応を検討します。
質問35：インターネット回線やWAN回線に指定事業者はありますか？
既存契約、グループ会社の標準、調達ルールなどにより、利用できる回線事業者が限定される場合があります。
回線の契約期間、解約条件、開通までの期間も確認しましょう。
8. 運用・監視・保守
質問36：導入後は誰がネットワークを運用しますか？
顧客自身が運用するのか、保守事業者へ委託するのかを確認します。
運用担当者のスキルによって、採用する構成や運用手順の複雑さを調整する必要があります。
質問37：監視対象と監視項目は何ですか？
監視対象として、次の項目を確認します。
- 機器の死活
- インターフェース状態
- CPU・メモリー
- トラフィック量
- パケットロス
- VPN状態
- 冗長化状態
- 温度・電源
- ログ
- 設定変更
監視するだけでなく、異常を検知した後の対応も定義します。
質問38：障害通知は誰に、どの方法で行いますか？
通知先と通知手段を確認します。
- メール
- 電話
- チャット
- 監視ダッシュボード
- チケット管理システム
障害の重要度によって通知先や方法を変えるのかも確認します。
質問39：ログはどこに、どのくらいの期間保存しますか？
機器内だけにログを保存すると、再起動や容量不足によって必要な情報が失われる可能性があります。
Syslogサーバーやクラウド型ログ基盤への転送、保存期間、閲覧権限を確認します。
質問40：設定変更や構成管理はどのように行いますか？
ネットワーク機器の設定変更ルールを確認します。
- 変更申請
- 承認者
- 作業手順
- 設定バックアップ
- 作業後確認
- ロールバック
- 構成図の更新
- 変更履歴の保存
設定ファイルを誰がどこで管理するのかも明確にします。
9. 移行・試験・切り替え
質問41：既存環境から新環境へどのように移行しますか？
一括切り替え、拠点単位、フロア単位、システム単位など、移行方式を確認します。
影響範囲が大きい場合は、段階的な移行を検討します。
質問42：移行作業中に既存環境と新環境を並行稼働させますか？
並行稼働する場合、ルーティング、VLAN、IPアドレス、DNS、DHCPなどの整合性を保つ必要があります。
一時的な接続構成についても、設計書へ記載します。
質問43：切り替えに失敗した場合、元の環境へ戻せますか？
切り戻し条件と切り戻し手順を確認します。
例えば、次のような判断基準を事前に決めます。
- 指定時刻までに通信確認が完了しない
- 重要システムへ接続できない
- 原因不明の通信障害が発生した
- 性能が基準を満たさない
切り戻しに必要な時間も見積もります。
質問44：どのような試験を実施する必要がありますか？
試験内容を要件定義段階で整理します。
- 物理接続試験
- 疎通試験
- ルーティング試験
- 冗長化試験
- 性能試験
- セキュリティ試験
- 障害試験
- 運用試験
- 業務アプリケーション試験
「正常に通信できること」だけでなく、障害時に想定どおり動作することも確認します。
質問45：誰が受け入れ判定を行い、合格条件は何ですか？
試験結果を誰が確認し、どの条件を満たせば完了とするのかを決めます。
数値や確認方法が曖昧なままだと、プロジェクト終了時に認識齟齬が発生します。
10. 予算・スケジュール・成果物
質問46：予算の上限または想定金額はありますか？
予算を確認せずに理想的な構成だけを提案すると、後から大幅な設計変更が発生します。
顧客が具体的な予算を回答できない場合は、最低構成、標準構成、高可用性構成のように複数案を提示します。
質問47：利用開始日はいつですか？
機器の納期、回線開通、工事、試験、移行などを考慮し、実現可能なスケジュールか確認します。
特に回線や海外製品は、手配に時間がかかる場合があります。
質問48：他システムや他プロジェクトとの依存関係はありますか？
サーバー更改、クラウド移行、オフィス移転、セキュリティ製品導入など、関連プロジェクトを確認します。
ネットワークだけ予定どおりに完成しても、関連システムが準備できなければ利用を開始できません。
質問49：必要な成果物は何ですか？
納品するドキュメントを確認します。
- 要件定義書
- 基本設計書
- 詳細設計書
- ネットワーク構成図
- IPアドレス一覧
- パラメーターシート
- 試験仕様書
- 試験結果報告書
- 移行手順書
- 運用手順書
- 障害対応手順書
顧客指定のフォーマットがあるかも確認します。
質問50：要件の承認者と変更管理のルールは決まっていますか？
要件を誰が承認するのかを明確にします。
現場担当者の希望と、予算や方針を決定する責任者の意見が異なることもあります。
要件確定後に変更が発生した場合の申請、影響調査、見積もり、承認手順も決めておきましょう。
要件定義の質問をするときの5つのポイント
1. Yes・Noだけで終わる質問を避ける
「冗長化は必要ですか？」と聞くだけでは、必要か不要かしか分かりません。
次のように、背景まで確認します。
ネットワークが停止した場合、どの業務が停止しますか。
また、何分程度までの停止であれば許容できますか。
2. 顧客の言葉を数値へ変換する
「速くしたい」「止めたくない」「安全にしたい」という表現は、そのままでは試験できません。
可能な限り、次のような数値に変換します。
- 必要帯域
- 同時接続台数
- 許容停止時間
- 復旧目標時間
- ログ保存期間
- 将来の利用者数
3. 現在だけでなく将来も確認する
現在の利用者数や通信量だけでなく、3年後や5年後の計画も確認します。
将来の拠点追加やクラウド移行が分かっていれば、拡張しやすい設計を選択できます。
4. 回答だけでなく根拠も記録する
「回線を冗長化する」という要件だけでなく、なぜ必要なのかも記録します。
営業時間中にインターネット回線が停止すると、受注システムを利用できなくなるため、異なる回線事業者による冗長化を行う。
判断理由を残しておくと、設計レビューや予算調整で説明しやすくなります。
5. 未決事項を放置しない
ヒアリング中に決まらなかった内容は、「確認中」「担当者」「回答期限」を記録します。
「後で確認する」と口頭で終わらせず、課題管理表で管理しましょう。
要件ヒアリングシートの記入例
| No. | 分類 | 質問・確認事項 | 顧客回答 | 要件への反映 | 担当者 | 期限 |
|---|---|---|---|---|---|---|
| 1 | 可用性 | 許容停止時間はどの程度か | 営業時間中は5分以内 | 回線・FWを冗長化 | 顧客A様 | 7月20日 |
| 2 | 性能 | 最大同時接続数は何台か | 現在300台、3年後500台 | 500台以上を収容 | 顧客B様 | 確認済み |
| 3 | 運用 | 障害通知先は誰か | 情報システム部3名 | メールと電話で通知 | 運用担当 | 7月25日 |
| 4 | セキュリティ | ゲスト端末の社内接続可否 | インターネットのみ許可 | 社内LANと分離 | セキュリティ担当 | 確認済み |
よくある失敗
失敗1：顧客の要望をそのまま要件にする
「安くて、速くて、止まらないネットワーク」という要望を、そのまま設計することはできません。
優先順位と予算を確認し、実現可能な条件へ変換する必要があります。
失敗2：機器の型番を早い段階で決めてしまう
要件が固まる前に製品を選ぶと、製品に合わせて要件を変更することになりかねません。
基本的には、次の順番で進めます。
業務要件
↓
システム要件
↓
ネットワーク要件
↓
構成方式
↓
製品・型番
失敗3：正常時の通信だけを確認する
通常時に通信できることだけでなく、障害時の動作も確認します。
- 回線が切断された場合
- 機器が停止した場合
- 電源が停止した場合
- VPNが切断された場合
- 監視サーバーへ接続できない場合
障害時に誰が何をするのかも、要件として整理します。
失敗4：現場担当者だけに確認する
現場担当者、情報システム部門、セキュリティ部門、運用担当者、責任者では、それぞれ重視する内容が異なります。
一人の回答だけで要件を決めず、関係者ごとの要求を整理しましょう。
失敗5：確認した内容を文章に残さない
口頭で合意した内容は、後から認識が変わる可能性があります。
議事録、課題管理表、要件定義書に記録し、関係者の承認を得ることが重要です。
無料Excelテンプレートを用意しました
本記事で紹介する「ネットワーク要件定義で確認すべき50の質問」を、実際の顧客ヒアリングで使えるExcelテンプレートにまとめました。
質問を確認するだけでなく、次の項目も一緒に管理できます。
- 顧客からの回答
- 確認状況
- 要件への反映内容
- 担当者
- 回答期限
- 備考・追加確認事項
確認状況は「未確認・確認中・確認済・対象外」から選択でき、確認済み件数と進捗率も自動で集計されます。
案件ごとにコピーし、内容を自由に編集してご利用ください。
ファイル形式： Excel（.xlsx）
料金： 無料
メールアドレス登録： 不要
収録内容： ネットワーク要件ヒアリング50項目
【ネットワーク要件ヒアリングシートを無料ダウンロード】
※個人学習、社内業務、担当案件で編集して利用できます。ファイルそのものの転載、販売、再配布はご遠慮ください。
50の質問をExcelで管理したい方へ
要件定義では、質問するだけでなく、顧客の回答を記録し、設計や試験へ確実に反映することが重要です。
しかし、案件ごとに質問項目を一から作成していると、確認漏れが発生しやすく、準備にも時間がかかります。
そこで、本記事で解説した50の質問を、すぐに使えるExcel形式にまとめました。
このテンプレートでは、次の内容を一つのシートで管理できます。
- 要件定義で確認すべき質問50項目
- 各質問の確認目的
- 顧客からの回答
- 要件や設計への反映内容
- 確認状況
- 担当者と回答期限
- 確認の進捗率
顧客とのヒアリング、社内レビュー、未決事項の管理にご活用ください。
※冒頭で紹介したテンプレートと同一のものです
メールアドレスの登録は不要です。ダウンロード後、案件に合わせて自由に編集できます。
まとめ
ネットワークの要件定義では、技術知識だけでなく、顧客の要望を整理する質問力が求められます。
確認すべき主な分野は、次の10項目です。
- プロジェクトの目的と対象範囲
- 現行ネットワークの構成
- 利用者・端末・拠点
- 通信量と性能
- 可用性と冗長化
- セキュリティ
- WAN・インターネット・クラウド接続
- 運用・監視・保守
- 移行・試験・切り替え
- 予算・スケジュール・成果物
50個すべてを機械的に質問する必要はありません。
案件の目的や規模に応じて必要な質問を選び、顧客の曖昧な要望を、設計や試験で確認できる具体的な条件へ変換してください。
要件定義で評価されるネットワークエンジニアは、単に質問が多い人ではありません。
顧客がまだ言葉にできていない条件やリスクを見つけ、設計判断につなげられる人です。
この50の質問をヒアリングシートとして活用し、要件の抜け漏れと手戻りを減らしていきましょう。
コメント