この演習は、 ネットワーク上級編 「第1章:要件定義」で学んだ内容を使って、 実際の案件を想定した要件定義に取り組む章末課題です。
第1章 実践演習|顧客要望からネットワーク要件定義書を作ろう
「ネットワークを速くしたい」「止まらないようにしたい」 「セキュリティを強化したい」という顧客の言葉を、 そのまま設計へ進めることはできません。 この演習では、架空企業のネットワーク更改案件を題材に、 情報整理・ヒアリング・要件分類・優先順位付けを行い、 最後に要件定義書を完成させます。
上流工程では、顧客が最初から技術的に整理された要件を提示してくれるとは限りません。
曖昧な要望から必要な情報を引き出し、 設計判断に使える条件へ変換すること が、要件定義の重要な仕事です。
この演習でできるようになること
- 顧客要望から確認不足の情報を発見できる
- 現状構成と課題を整理できる
- 可用性・性能・セキュリティ要件を分類できる
- 運用・監視・移行要件を整理できる
- 顧客への追加ヒアリング質問を作成できる
- 要件に優先順位を付けられる
- 曖昧な表現を定量的な要件へ変換できる
- 要件定義書として成果物をまとめられる
第1章で学んだ内容を確認しよう
この演習では、第1章の10記事で学んだ内容をまとめて使用します。 分からない項目があれば、演習の途中で各記事へ戻って確認してください。
| 記事 | 今回の演習で使う内容 |
|---|---|
| 1. ネットワーク要件定義とは何か | 要望と要件を区別する |
| 2. 現状構成を把握する方法 | 現行構成・課題・制約を整理する |
| 3. 利用者数・端末数・通信量の確認 | 規模とトラフィックを確認する |
| 4. 可用性要件の整理 | 停止許容時間や冗長化条件を確認する |
| 5. 性能・帯域要件の整理 | 帯域・遅延・ピーク時の条件を整理する |
| 6. セキュリティ要件の整理 | アクセス制御や分離要件を整理する |
| 7. 運用・監視要件の整理 | 監視・通知・運用体制を決める |
| 8. 移行・切り替え要件の整理 | 停止可能時間や切り戻し条件を確認する |
| 9. 顧客へのヒアリング質問 | 不足情報を質問によって補う |
| 10. 要件の優先順位を決める方法 | 必須要件と希望要件を整理する |
この演習の目的は「正解の構成」を考えることではありません。
まだ基本設計へ進む前なので、 「ルーターを2台にする」「回線を10Gbpsにする」といった 具体的な方式を決めるのではなく、 設計を決めるために必要な条件を整理することに集中してください。
今回の案件:本社・拠点ネットワーク更改
株式会社サンプル商事では、約7年前に導入したネットワーク機器の更新に合わせて、 本社と2つの営業拠点のネットワークを更改することになりました。
情報システム部から、あなたの会社へ 「ネットワークを安定させ、セキュリティも強化したい」 と相談がありました。
企業情報
| 拠点 | 本社、東京営業所、大阪営業所 |
|---|---|
| 従業員 | 約250名 |
| 本社 | 約170名 |
| 東京営業所 | 約45名 |
| 大阪営業所 | 約35名 |
| 主な利用 | クラウド業務システム、メール、Web会議、ファイル共有、インターネット |
| 運用担当 | 情報システム部3名 |
現在分かっている構成
本社
- インターネット回線:1回線
- ルーター:1台
- 社内スイッチ:複数台
- 社員PCと業務サーバーが同一ネットワーク内に存在
- 無線LANあり
営業所
- 各営業所にインターネット回線1回線
- 本社とはVPNで接続
- 小規模なルーター・スイッチ構成
- 詳細な構成資料は更新されていない
顧客から聞いている要望
- ネットワーク障害で仕事が止まらないようにしたい
- 昼休みやWeb会議が多い時間帯でも快適に使いたい
- 社員PCと重要なサーバーを分けたい
- 外部からの不正アクセスを防ぎたい
- ネットワーク障害を早く発見したい
- 情報システム部の運用負荷を増やしたくない
- 休日出勤をできるだけせずに切り替えたい
- 予算はできる限り抑えたい
ここで注意してください。
「止まらない」「快適」「セキュリティを強くする」 「運用負荷を増やさない」は、まだ設計に使える要件ではありません。
これらを具体化するのが、今回の演習です。
現状と課題を整理する
まず、案件情報を 「確認できている事実」「現在の課題」「まだ分からないこと」 の3つに分けてください。
課題
それぞれ3項目以上を書き出してください。
・
・
・
【現在の課題】
・
・
・
【まだ分からないこと】
・
・
・
現状・課題・未確認事項を区別できれば完成です。
回答例を見る
確認できている事実
- 本社と2営業所が存在する
- 従業員は約250名
- 本社のインターネット回線は1回線
- 本社ルーターは1台
- 営業所とはVPNで接続している
- 情報システム部は3名
現在の課題
- 単一回線・単一ルーターが障害点になる可能性がある
- 社員PCと重要サーバーが同一ネットワークに存在している
- 構成資料が更新されておらず、現状把握が不十分
- 時間帯によって通信品質に問題がある可能性がある
まだ分からないこと
- 現在の回線帯域と実際の通信量
- 許容できる停止時間
- サーバー台数と通信先
- 監視対象と通知方法
- 切り替え可能な曜日・時間帯
- 具体的な予算上限
追加ヒアリング項目を作る
現時点の情報だけでは設計へ進めません。 顧客へ追加で確認すべき質問を考えてください。
条件
- 最低10問作成する
- 「なぜ聞くのか」も考える
- YES/NOだけで終わる質問に偏らない
| 質問 | 確認する目的 |
|---|---|
| 例:ネットワーク停止を許容できる時間はどの程度ですか? | 可用性要件を決めるため |
| 1. | |
| 2. | |
| 3. | |
| 4. | |
| 5. | |
| 6. | |
| 7. | |
| 8. | |
| 9. | |
| 10. |
質問例を見る
- ネットワーク停止を許容できる時間はどの程度ですか?
- 停止すると特に影響が大きい業務は何ですか?
- 現在契約している回線速度はいくつですか?
- 通信が遅いと感じる曜日・時間帯・業務はありますか?
- 今後3年間で従業員や端末が増える予定はありますか?
- 社内に接続する端末にはどのような種類がありますか?
- 社員PCから重要サーバーへ必要な通信は何ですか?
- ゲスト端末や個人端末を接続する予定はありますか?
- 現在監視している機器と監視項目は何ですか?
- 障害発生時は誰へ、どの方法で通知する必要がありますか?
- 切り替え作業を実施できる曜日・時間帯はいつですか?
- 問題発生時に切り戻しを判断する基準はありますか?
- 今回の更改に使用できる予算の目安はいくらですか?
要件を分類する
ヒアリングによって、追加で以下の回答を得たとします。
- 平日8:00〜20:00は基本的にネットワークを停止できない
- 障害発生時も重要業務は継続したい
- Web会議利用者は最大80名程度
- 3年以内に従業員が300名程度まで増える可能性がある
- 重要サーバーには社員PCから必要な通信だけを許可したい
- 来客用Wi-Fiから社内ネットワークへ接続させたくない
- 主要ネットワーク機器の停止を5分以内に把握したい
- 障害通知は情報システム部の共有メールへ送信したい
- 夜間の常時監視要員はいない
- 切り替え作業は土曜日の22:00〜翌5:00であれば可能
- 問題発生時には旧環境へ戻せるようにしたい
各項目を次の5種類へ分類してください。
- 可用性
- 性能・帯域
- セキュリティ
- 運用・監視
- 移行・切り替え
【性能・帯域】
【セキュリティ】
【運用・監視】
【移行・切り替え】
分類例を見る
可用性
- 平日8:00〜20:00は基本的に停止できない
- 障害時も重要業務を継続したい
性能・帯域
- Web会議最大80名
- 3年以内に300名程度まで増加する可能性
セキュリティ
- 重要サーバーへの通信を必要なものだけに限定
- 来客用Wi-Fiと社内ネットワークを分離
運用・監視
- 主要機器の停止を5分以内に把握
- 共有メールへ障害通知
- 夜間の常時監視要員はいない
移行・切り替え
- 土曜日22:00〜翌5:00に切り替え可能
- 問題発生時は旧環境へ切り戻せること
曖昧な要望を具体的な要件へ変える
次の顧客要望を、設計判断に使いやすい表現へ変換してください。
| 顧客の要望 | 要件として具体化 |
|---|---|
| 障害をすぐに知りたい | 例:主要ネットワーク機器の停止を5分以内に検知し、情報システム部へ通知する |
| ネットワークを止めたくない | |
| Web会議を快適に使いたい | |
| サーバーを安全にしたい | |
| 切り替えで失敗したくない |
回答例を見る
- 止めたくない: 平日8:00〜20:00は重要業務のネットワーク通信を継続できること。
- Web会議を快適に: 最大80名が同時にWeb会議を利用する時間帯を想定して必要な通信容量を確保すること。
- サーバーを安全に: 社員PCから重要サーバーへの通信は業務上必要な通信のみ許可し、来客用ネットワークからは接続させないこと。
- 切り替えで失敗したくない: 土曜日22:00〜翌5:00を切り替え時間とし、継続困難な問題が発生した場合は旧環境へ切り戻せること。
要件定義では、できるだけ「測定・確認できる表現」に変えることが重要です。
「高速」「安全」「安定」だけでは、 完成後に要件を満たしたか確認できません。
要件の優先順位を決める
顧客との打ち合わせの結果、 予算の都合ですべての希望を同時に実現できない可能性が出てきました。
次の要件を Must/Should/Could の3段階で整理してください。
| 要件 | 優先度 | 理由 |
|---|---|---|
| 重要業務の継続性を確保する | ||
| 来客Wi-Fiと社内ネットワークを分離する | ||
| 主要機器の停止を5分以内に検知する | ||
| 今後300名まで増員できる余裕を持たせる | ||
| 監視画面を新しく見やすいデザインにする | ||
| 切り替え失敗時に旧環境へ戻せるようにする |
優先順位の一例を見る
| 要件 | 例 |
|---|---|
| 重要業務の継続性 | Must |
| 来客Wi-Fiの分離 | Must |
| 5分以内の障害検知 | Should |
| 300名までの拡張余地 | Should |
| 監視画面のデザイン刷新 | Could |
| 旧環境への切り戻し | Must |
実案件では、優先順位に唯一の正解があるとは限りません。 業務影響、セキュリティリスク、予算、納期などを顧客と確認し、 合意して決定します。
ネットワーク要件定義書を作る
ここまで整理した内容を使い、 最終成果物となる要件定義表を完成させてください。
| ID | 分類 | 要件 | 優先度 | 確認方法・備考 |
|---|---|---|---|---|
| REQ-01 | 可用性 | |||
| REQ-02 | 性能 | |||
| REQ-03 | 性能 | |||
| REQ-04 | セキュリティ | |||
| REQ-05 | セキュリティ | |||
| REQ-06 | 運用・監視 | |||
| REQ-07 | 運用・監視 | |||
| REQ-08 | 移行 | |||
| REQ-09 | 移行 |
この表が今回の章末課題のメイン成果物です。
要件定義書の回答例を見る
| ID | 分類 | 要件 | 優先度 |
|---|---|---|---|
| REQ-01 | 可用性 | 平日8:00〜20:00は重要業務の通信を継続できること | Must |
| REQ-02 | 性能 | 最大80名のWeb会議利用を考慮した通信容量を確保すること | Must |
| REQ-03 | 性能 | 従業員300名程度までの増加を想定できること | Should |
| REQ-04 | セキュリティ | 重要サーバーへの通信を業務上必要な通信に制限すること | Must |
| REQ-05 | セキュリティ | 来客用ネットワークから社内ネットワークへアクセスできないこと | Must |
| REQ-06 | 運用・監視 | 主要ネットワーク機器の停止を5分以内に検知すること | Should |
| REQ-07 | 運用・監視 | 障害検知時は情報システム部の共有メールへ通知すること | Should |
| REQ-08 | 移行 | 本番切り替えは土曜日22:00〜翌5:00以内に実施すること | Must |
| REQ-09 | 移行 | 重大な問題が発生した場合は旧環境へ切り戻せること | Must |
顧客へ要件を説明する
要件定義では、表を作って終わりではありません。 顧客と内容を確認し、 認識が合っているか合意する必要があります。
最終課題
顧客との要件確認会議を想定して、 今回の要件を1分程度で説明してください。
特に重要な要件として、__________________。
また、セキュリティについては__________________。
運用・移行については__________________。
この内容を前提として、次の基本設計工程で具体的な構成を検討します。
説明例を見る
今回のネットワーク更改では、 業務継続性の向上、通信性能の確保、 セキュリティ強化、運用負荷の抑制を主な目的とします。
特に、平日8時から20時までの重要業務を継続できることを 優先度の高い要件とします。 また、最大80名のWeb会議利用と、 将来300名程度まで従業員が増える可能性を考慮します。
セキュリティ面では、 社員ネットワークと来客用ネットワークを分離し、 重要サーバーへの通信を必要なものに限定します。
運用面では主要機器の障害を5分以内に検知し、 情報システム部へ通知できることを要件とします。 切り替えは土曜日22時から翌5時の範囲で実施し、 問題発生時には旧環境へ戻せることを条件とします。
これらの要件について合意したうえで、 次の基本設計工程で具体的なネットワーク構成を検討します。
自己評価|第1章の修了チェック
次の項目を確認してください。
現状を整理できた
不足情報を質問できた
要件を分類できた
要件を具体化できた
優先順位を付けられた
要件定義表を作れた
判断理由を説明できた
設計へ渡せる状態にした
修了の目安
- 顧客の「要望」と「要件」を区別できる
- 不足情報を自分で発見できる
- 必要なヒアリング質問を作れる
- 要件を可用性・性能・セキュリティ・運用・移行に分解できる
- 曖昧な要望を確認可能な条件へ変換できる
- 優先順位と理由を説明できる
- 要件定義書として整理できる
ここまで自力でできれば、第1章「要件定義」の目標は達成です。
次の第2章では、この要件をもとに、 IPアドレス、VLAN、ルーティング、冗長化などの 具体的なネットワーク設計へ進みます。
まとめ
- 要件定義では、顧客の要望をそのまま設計へ持ち込まない
- まず現状・課題・制約・未確認事項を整理する
- 不足情報はヒアリングによって確認する
- 可用性・性能・セキュリティ・運用・移行などに分類する
- 「速い」「安全」「止まらない」を具体的な条件へ変換する
- すべての要望を同じ重要度で扱わず、優先順位を決める
- 要件定義の最後には、顧客と内容を確認して合意する
要件定義とは、ネットワーク機器を選ぶ工程ではなく、 「何を実現しなければならないのか」を明確にする工程です。
第1章では、ネットワーク要件定義、 現状把握、利用規模、可用性、性能、セキュリティ、 運用・監視、移行、顧客ヒアリング、 要件の優先順位までを学びました。

コメント