この記事は、 「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」 の第10回です。
第1章で整理してきた性能・可用性・セキュリティ・運用・移行などの要件を、 「どれを絶対に守るのか」「どこまでなら調整できるのか」 という観点で整理し、基本設計へ引き継ぐ方法を学びます。
NETWORK ADVANCED｜CHAPTER 1 REQUIREMENTS
要件の優先順位を決める方法｜すべてを「最優先」にしないための整理術
「止めたくない」「高速にしたい」「セキュリティも強化したい」 「運用は簡単にしたい」「でも予算は抑えたい」。 ネットワーク案件では、複数の要件が同時に存在し、 すべてを最大限に実現できるとは限りません。 この記事では、要件を業務影響・リスク・予算・納期などから評価し、 設計判断に使える優先順位へ整理する方法を解説します。
要件定義では、多くの要望や条件が集まります。 しかし、要件を一覧にしただけでは基本設計を始められません。
設計者には、 「絶対に満たす必要がある条件」 「できれば実現したい条件」 「予算や納期によっては後回しにできる条件」 を区別する作業が必要です。
この記事を読み終えるとできること
- 要件に優先順位を付ける目的を説明できる
- Must・Should・Couldを使って要件を分類できる
- 業務影響から優先順位を判断できる
- 可用性・性能・コストなどの競合を整理できる
- 優先順位表を作成できる
- 顧客と優先順位について合意できる
要件の優先順位とは何か
要件の優先順位付けとは、 各要件について「どの程度必須なのか」を、 業務影響・リスク・制約・コスト・納期などから評価し、 設計判断に使える形へ整理することです。
たとえば、ネットワーク更改案件で次の要望があったとします。
- ネットワーク停止をできるだけなくしたい
- 通信速度を上げたい
- セキュリティを強化したい
- すべての機器を最新モデルにしたい
- 監視を自動化したい
- 予算はできるだけ抑えたい
- 3か月後には利用開始したい
これらをすべて「必須」としてしまうと、 コストや納期との整合性が取れなくなる可能性があります。
「顧客が希望している」ことと「必須要件」であることは同じではありません。
実現できなかった場合に、 業務・安全・セキュリティ・契約・法令・プロジェクト目的へ どのような影響があるのかを確認して優先度を決めます。
なぜ要件に優先順位を付ける必要があるのか
設計判断ができる
どの要件を優先するか分かれば、 冗長化、帯域、回線、セキュリティ方式などを 根拠を持って選択できます。
予算調整ができる
予算不足の場合に、 絶対に残す項目と削減可能な項目を区別できます。
納期調整ができる
必須機能を初回リリースへ含め、 追加機能を後続フェーズへ回す判断ができます。
設計変更を管理できる
新しい要求が追加されたとき、 既存の優先順位と比較して影響を判断できます。
試験基準になる
必須要件を満たしていなければ、 原則として受け入れできないという判断がしやすくなります。
説明責任を果たせる
「なぜここにはコストをかけ、こちらは見送ったのか」を 顧客へ説明できます。
優先順位は「重要そうな順に並べる」だけではありません。
設計・予算・スケジュールで判断が必要になったときに、 何を守り、何を調整できるかを決めるための基準です。
Must・Should・Couldで要件を整理する
要件の優先度を分かりやすく整理する方法の一つとして、 次の4段階で分類できます。
必須
実現できなければ、 プロジェクト目的や業務継続に重大な影響がある要件です。
重要
可能な限り実現すべきですが、 代替策や一時的な回避策を検討できる要件です。
できれば実現
実現するとメリットがありますが、 予算や納期によって調整できる要件です。
今回は実施しない
将来的な候補ではあるものの、 今回の対象範囲には含めない項目です。
| 優先度 | 判断イメージ | ネットワーク要件の例 |
|---|---|---|
| Must | 満たせなければプロジェクト成立が難しい | 主要業務について単一機器障害時も通信を継続できること |
| Must | 規程・契約などで必須 | 管理ネットワークを一般利用者ネットワークから分離すること |
| Should | 重要だが代替手段がある | 回線障害時に自動切り替えできること |
| Could | 費用対効果を見て判断できる | 監視ダッシュボードを新規構築すること |
| 今回は対象外 | 次期フェーズへ延期できる | 全拠点をSD-WANへ同時移行すること |
Must・Should・Couldという名称そのものが重要なのではありません。
「必須」「重要」「希望」「今回は対象外」のように、 プロジェクト内で意味が統一されていれば問題ありません。
要件の優先順位を判断する7つの基準
「これは重要そうだからMust」と感覚だけで判断すると、 関係者によって優先順位が変わります。
次のような観点を使って判断します。
業務への影響
要件を満たさなかった場合、 売上・受発注・生産・顧客対応などへ どの程度影響するかを確認します。
セキュリティ・コンプライアンス
社内規程、契約、監査、法令などで 必須となる条件かを確認します。
障害・リスク
実現しなかった場合に、 障害、情報漏えい、長時間停止などの リスクがどの程度増えるかを確認します。
他要件との依存関係
この要件を実現しなければ、 他の機能や設計が成立しないかを確認します。
納期
サービス開始日や拠点開設日など、 変更できない期限に関係しているかを確認します。
コスト
要件を満たすために必要な 機器・回線・ライセンス・工数を考慮します。
運用への影響
構築後に運用できるか、 運用担当者の負荷やスキルに 無理がないかを確認します。
優先順位は「技術」ではなく業務影響から考える
ネットワークエンジニアは、 技術的に重要そうな項目を高く評価しがちです。
しかし、上流工程では 「その要件を満たさなかったら、顧客の業務に何が起こるか」 を確認する必要があります。
| 要件候補 | 技術だけで考えた場合 | 業務影響から考える |
|---|---|---|
| インターネット回線の冗長化 | 冗長化した方が安全 | 回線停止時に受発注業務が停止するなら優先度が高い |
| 10Gbps化 | 高速な方がよい | 実際のピーク通信量が500Mbpsなら優先度が下がる可能性がある |
| 管理ネットワーク分離 | セキュリティ上望ましい | 社内規程で必須ならMustとして扱う |
| 監視画面の刷新 | 新しい方が使いやすい | 現在の監視で必要機能を満たすなら後続フェーズへ回せる可能性がある |
Mustかどうかを判断する質問
- この要件を満たさないと、どの業務が止まるか
- 何人・何拠点へ影響するか
- 売上や顧客対応へ影響するか
- セキュリティ事故につながる可能性があるか
- 社内規程や契約で必須か
- 他の要件が実現できなくなるか
- 代替手段は存在するか
- 次期フェーズへ延期できるか
要件同士のトレードオフを整理する
ネットワーク設計では、 一つの要件を高めると別の条件へ影響することがあります。
REQUIREMENT TRADE-OFF｜要件は互いに影響する
すべてを最大化するのではなく、プロジェクト目的に合わせてバランスを決めます。
よくある競合例
可用性 vs コスト
機器、回線、電源をすべて冗長化すれば可用性は高まりますが、 初期費用・保守費用も増加します。
セキュリティ vs 利便性
アクセス制御や認証を厳しくすると、 利用者や運用担当者の操作が増える場合があります。
性能 vs コスト
高性能機器や大容量回線を選べば余裕は増えますが、 実際の通信量に対して過剰設計になる可能性があります。
移行安全性 vs 納期
十分な検証や段階移行には時間が必要です。 短納期を優先すると移行リスクが高まる可能性があります。
優先順位は、設計者だけで決めてはいけません。
技術的な影響はエンジニアが説明し、 業務・予算・リスクを含めて顧客やプロジェクト責任者と判断します。
要件の優先順位を決める実務の進め方
- 要件候補を一覧化する 性能、可用性、セキュリティ、運用、移行など、 ヒアリングで確認した要件を一つの一覧へまとめます。
- 要件の背景・理由を記録する 「なぜ必要なのか」「満たさないと何が起こるのか」を確認します。
- 必須となる条件を先に抽出する 契約、規程、業務継続、セキュリティなど、 調整が難しい条件を確認します。
- 業務影響を確認する 要件を満たさなかった場合の利用者数、停止業務、 損失、復旧方法などを確認します。
- Must・Should・Couldへ分類する 重要度だけでなく、代替策や延期可能性も考慮します。
- 要件同士の競合を確認する 可用性とコスト、セキュリティと利便性など、 両立しにくい条件を洗い出します。
- 予算・スケジュールと照合する すべてを実現できない場合は、 Couldを延期するなど対応範囲を調整します。
- 対象外・次期対応も明記する 単に削除するのではなく、 「今回は実施しない」と判断した記録を残します。
- 関係者と合意する 優先順位、理由、対象外、未決事項を確認し、 基本設計へ引き継ぎます。
要件優先順位表の作り方
優先順位は口頭だけで決めず、 後から判断理由を追跡できるように表へ残します。
| ID | 分類 | 要件 | 優先度 | 理由・背景 | 設計への影響 |
|---|---|---|---|---|---|
| REQ-001 | 可用性 | 主要機器の単一障害時にも 受発注通信を継続できること | Must | 停止すると受発注業務が停止するため | 機器・経路の冗長化を検討 |
| REQ-002 | セキュリティ | 管理通信を一般利用者ネットワークから 分離すること | Must | 社内セキュリティ基準で必須 | 管理VLAN・アクセス制御を検討 |
| REQ-003 | 性能 | Web会議利用増加を考慮して WAN帯域を確保すること | Should | 現在ピーク時間帯に遅延が発生 | 帯域増強・QoSなどを比較 |
| REQ-004 | 運用 | 新しい監視ダッシュボードを 構築すること | Could | 運用性向上。現行監視でも最低限の監視は可能 | 予算に応じて追加 |
最低限残したい項目
- 要件ID
- 要件分類
- 要件内容
- 要求元・関係者
- 背景・理由
- 優先度
- 優先度の判断理由
- 設計への影響
- 未決事項
- 承認者・合意状況
重要なのは「Must」と書くことではなく、なぜMustなのか説明できることです。
背景が分からなければ、後工程で要件を変更してよいのか判断できません。
顧客・関係者と優先順位を合意する
要件の優先順位は、 ネットワーク担当者だけで完結するものではありません。
たとえば、次の関係者で判断基準が異なることがあります。
業務部門
「業務を止めたくない」 「使いやすさを維持したい」と考えます。
セキュリティ部門
認証、通信制御、ログ、ネットワーク分離などを 重視します。
運用部門
障害対応、監視、設定変更、 保守しやすさを重視します。
経営・予算責任者
コスト、投資効果、業務リスクなどを 重視します。
プロジェクト管理者
納期、作業工数、依存関係、 プロジェクトリスクを重視します。
ネットワーク担当
技術的な実現性、構成、 性能や障害リスクを評価します。
「全部Mustです」と言われたらどうするか
実務では、顧客から 「全部必要です」 と言われることがあります。
その場合は、次のように質問します。
確認例
「仮に予算や納期の都合で一部を次期対応にする必要がある場合、 どの条件を最優先で守る必要がありますか？」
確認例
「この要件を満たせない場合、 具体的にどの業務や利用者へ影響しますか？」
確認例
「代替運用が可能な項目と、 代替手段がなく必ず実現しなければならない項目を 分けてもよいでしょうか？」
要件の優先順位付けでよくある失敗
すべて必須では、予算や納期で問題が発生したときに 判断できません。要件間の相対的な重要度を整理します。
業務影響や予算の判断は、 技術担当だけでは決められません。 関係者と合意します。
新しい技術や高性能な構成だから重要とは限りません。 プロジェクト目的への影響で判断します。
半年後に担当者が変わると、 なぜMustだったのか分からなくなります。 背景と判断理由を記録します。
今回実施しない項目も、 「対象外」「次期検討」などとして記録します。
後から設計変更が発生しても、 判断の根拠を追跡できる状態にします。
顧客・上司へ優先順位付けをどう説明するか
「優先順位を付けます」とだけ伝えると、 顧客によっては 「要望を削られるのではないか」 と感じる場合があります。
そのため、目的を次のように説明します。
説明例
「今回確認した要件について、 すべてを同じ重要度として扱うのではなく、 業務への影響やセキュリティ、予算、納期を踏まえて 優先順位を整理します。 これにより、構成を検討するときに、 絶対に守る条件と調整可能な条件を明確にできます。」
技術ではなく業務リスクとして説明する
| 技術中心の説明 | 業務を含めた説明 |
|---|---|
| ルーターは冗長化した方がよいです | ルーター故障で受発注業務全体が停止するため、 この部分はMustとして冗長化を検討します |
| 10Gbpsの方が高速です | 実測したピーク通信量と今後3年間の増加を確認し、 必要な帯域を決めます |
| 新しい監視製品を入れたいです | 現行監視でも必須項目を確認できるため、 ダッシュボード刷新はCouldとして次期対応も可能です |
要件の優先順位付けで使われる英語表現
よく使われる単語
| 英語 | 意味 |
|---|---|
| Priority | 優先度 |
| High priority | 優先度が高い |
| Mandatory requirement | 必須要件 |
| Must-have requirement | 必須要件 |
| Nice-to-have | あれば望ましいもの |
| Business impact | 業務影響 |
| Trade-off | 一方を優先すると他方へ影響する関係 |
| Defer | 延期する |
| Out of scope | 対象外 |
| Stakeholder | 関係者 |
打ち合わせで使える表現
Which requirements are mandatory for the initial release?
初回リリースで必須となる要件はどれですか？
What would be the business impact if this requirement is not met?
この要件を満たせない場合、業務へどのような影響がありますか？
Can this requirement be deferred to a later phase?
この要件を後続フェーズへ延期できますか？
We need to discuss the trade-off between availability and cost.
可用性とコストのトレードオフについて検討する必要があります。
理解度チェック
要件の優先順位を、 技術だけでなく業務・リスク・制約から判断できるか確認しましょう。
問題1．要件へ優先順位を付ける主な目的として、 最も適切なものはどれですか。
- 要件数をできるだけ減らすため
- 高価な機器を選びやすくするため
- 設計・予算・納期で判断するときに、守る条件と調整できる条件を明確にするため
- ネットワーク担当者だけで設計を決定するため
解答を見る
優先順位は要件を削除するためではなく、 制約の中で何を優先して設計するかを判断するために使用します。
問題2．次のうち、Mustとして扱う可能性が最も高いものはどれですか。
- 監視画面のデザインを新しくしたい
- 社内セキュリティ規程で管理ネットワーク分離が必須となっている
- できれば最新モデルのスイッチを使用したい
- 機器の色を統一したい
解答を見る
規程などによって必須となっている条件は、 原則として優先度の高い要件として扱います。
問題3．顧客から「すべてMustです」と言われました。 次の対応として適切なものはどれですか。
- そのまますべてMustとして設計する
- エンジニアが勝手に優先度を下げる
- 満たせなかった場合の業務影響や延期可能性を確認する
- 優先順位を付ける作業を中止する
解答を見る
業務影響、代替手段、延期可能性などを確認し、 本当に必須なのかを関係者と整理します。
問題4．可用性を高めるため機器・回線・電源をすべて冗長化すると、 予算を超過することが分かりました。 これは何を整理する必要がありますか。
解答を見る
どこまでの障害を許容できるか、 どの業務を優先するかを確認して、 必要な冗長化範囲を決めます。
問題5．要件へ優先度を付けるとき、 優先度と一緒に記録すべき重要な情報を2つ挙げてください。
解答例を見る
- その要件が必要な理由・背景
- 優先度をその値にした判断理由
- 要求元・関係者
- 設計への影響
- 承認者・合意状況
実践演習：ネットワーク更改要件へ優先順位を付ける
あなたは、300名規模の企業の ネットワーク更改を担当しています。
ヒアリングの結果、次の要件候補が挙がりました。
| No. | 要件候補 | 背景 |
|---|---|---|
| 1 | 受発注システム通信を単一機器障害で停止させない | 停止すると営業活動ができない |
| 2 | 管理ネットワークを利用者ネットワークから分離する | 社内セキュリティ基準で必須 |
| 3 | WAN回線を現在の100Mbpsから増速する | Web会議利用時に遅延の申告がある |
| 4 | 新しい監視ダッシュボードを導入する | 現在の画面が使いにくい |
| 5 | すべてのアクセススイッチを最新モデルへ交換する | 新しい機器へ統一したい |
| 6 | 3か月後の新オフィス開設までに利用開始する | 開設日は変更できない |
課題1．優先順位を付ける
各要件をMust・Should・Couldのいずれかへ分類してください。
No.2：＿＿＿＿＿＿
No.3：＿＿＿＿＿＿
No.4：＿＿＿＿＿＿
No.5：＿＿＿＿＿＿
No.6：＿＿＿＿＿＿
解答例を見る
- No.1：Must — 主要業務停止へ直結するため
- No.2：Must — 社内基準で必須のため
- No.3：Should — 性能課題があるため重要。ただし必要帯域の追加調査が必要
- No.4：Could — 利便性向上だが、現行監視で最低限の監視が可能
- No.5：Could — 「最新モデルへ統一したい」だけでは必須理由が不足
- No.6：Must — 変更できないサービス開始条件のため
実案件では、この分類を一方的に決めるのではなく、 顧客・関係者と確認して合意します。
課題2．追加で確認すべき質問を考える
No.3「WAN回線を増速する」について、 本当に必要な優先度や帯域を判断するために 追加で確認する質問を5つ考えてください。
2．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
3．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
4．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
5．＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
解答例を見る
- 現在の平均・ピーク通信量はどの程度ですか？
- 遅延が発生する時間帯はいつですか？
- どのアプリケーションで遅延が発生しますか？
- Web会議の同時利用者数はどの程度ですか？
- 今後3年間で利用者や通信量はどの程度増加しますか？
課題3．予算不足が判明した場合を考える
見積もりの結果、すべての要件を実現すると 予算を20％超過することが分かりました。
どのような順番で対応を検討するべきでしょうか。
解答例を見る
- Must要件に必要な費用を確認する
- Could要件の延期・削減を検討する
- Should要件に代替手段がないか確認する
- 設計方式を変更してコストを下げられないか検討する
- 残る不足分について顧客へ予算増額または要件調整を提示する
- 変更後の優先順位と対象範囲について再度合意する
課題4．要件優先順位表を作る
次の形式で、今回の要件を整理してください。
| ID | 要件 | 優先度 | 理由 | 設計への影響 |
|---|---|---|---|---|
| REQ-001 | ＿＿＿＿＿＿ | ＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
| REQ-002 | ＿＿＿＿＿＿ | ＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
| REQ-003 | ＿＿＿＿＿＿ | ＿＿＿＿ | ＿＿＿＿＿＿ | ＿＿＿＿＿＿ |
自分の言葉で説明する課題
後輩エンジニアから、 「顧客が全部必要と言っているなら、全部Mustにすればいいのでは？」 と質問されました。
1分程度で説明してください。
説明例を見る
要件はすべて同じ重要度とは限りません。 実際の案件では予算、納期、既存設備などの制約があるため、 すべてを最大限に実現できないことがあります。
そのため、実現できなかった場合の業務影響や セキュリティリスク、代替手段の有無を確認し、 絶対に守る要件と調整できる要件を分けます。
重要なのは、エンジニアだけで決めるのではなく、 判断理由を示して顧客や関係者と合意することです。
まとめ
- 要件の優先順位付けとは、 各要件がどの程度必須なのかを 業務影響・リスク・制約などから整理すること
- 要件はMust・Should・Couldなどへ分類すると 設計判断で使いやすい
- 優先順位は技術的な重要度だけでなく、 業務停止、セキュリティ、契約、予算、納期などから判断する
- 可用性・性能・セキュリティ・コスト・納期などは トレードオフになる場合がある
- 「すべてMust」ではなく、 満たせなかった場合の影響と代替手段を確認する
- 優先度だけでなく、 要件の背景・判断理由・承認者も記録する
- 今回実施しない要件も削除せず、 対象外・次期検討として残す
- 最終的な優先順位は、 顧客・業務部門・運用部門などの関係者と合意する
要件定義のゴールは「希望をすべて集めること」ではありません。 制約の中で何を最優先で実現するかを合意し、 設計者が迷わず判断できる状態にすることです。
この記事で第1章「要件定義」の個別テーマは完了です。 次の記事からは、整理した要件を IPアドレス、VLAN、ルーティング、冗長化、 WAN、VPN、監視などの具体的な設計へ変換していきます。
コメント