運用・監視要件とは何か

ネットワーク要件定義では、性能や可用性だけでなく、実際に運用するところまで考える必要があります。 そのため、運用担当者、監視対象、障害通知、ログ管理、設定バックアップ、変更管理などを確認します。

たとえば顧客から、次のような要望を受けたとします。

このままでは要件として不十分です。「すぐ」の意味や、何を障害として扱うのか、誰へ通知するのかが分からないからです。

• 監視する対象はルーターだけか、スイッチや無線LANも含むか
• 機器停止だけを監視するのか、回線・インターフェース・性能も見るのか
• 監視する時間帯は業務時間だけか、常時か
• 障害を検知したら誰へ通知するのか
• 夜間・休日は誰が対応するのか
• 障害ログをどの程度の期間残すのか

このような条件を確認し、後工程で監視設計や運用設計に落とし込める状態にするのが、運用・監視要件の整理です。

なぜ運用・監視要件が重要なのか

運用・監視・保守の違い

実務では「運用」「監視」「保守」がまとめて語られることがありますが、要件定義では役割を分けて考えると整理しやすくなります。

案件によっては、監視を社内で行い、故障時だけ保守ベンダーへ連絡する場合もあります。 反対に、監視から一次切り分けまで外部サービスへ委託する場合もあります。 重要なのは、担当範囲と引き継ぎ条件を曖昧にしないことです。

運用・監視の全体像を1枚で理解する

要件定義では、この流れのそれぞれについて「誰が」「何を」「いつ」「どこまで」行うのかを確認します。

運用・監視要件で確認する6項目

要件定義では、最低限次の6項目を整理しておくと、後の監視設計・ログ設計・運用設計へつなげやすくなります。

1．運用担当者と責任範囲

最初に、「誰が運用するのか」を確認します。

• ネットワーク運用の主管部署はどこか
• 社内担当者だけで対応するのか
• 外部ベンダーや運用会社へ委託するのか
• 一次切り分けと二次対応の境界はどこか
• 回線事業者や機器ベンダーへの問い合わせは誰が行うか
• 夜間・休日の対応者はいるか

2．監視対象

次に、何を監視する必要があるかを確認します。

具体的な監視方式やしきい値は基本設計・詳細設計で決めますが、要件定義では どの異常を見逃してはいけないかを業務影響と結びつけて整理します。

3．障害通知

障害を検知しても、通知先や優先順位が決まっていなければ対応につながりません。

• 誰へ通知するか
• 通知が必要な時間帯はいつか
• どの種類の障害を即時通知するか
• 情報レベルのイベントまで通知するか
• 通知が確認されない場合の次の連絡先は誰か
• 障害の重要度をどのように区分するか

4．ログ管理

障害調査、変更確認、セキュリティ調査、監査などでログが必要になる場合があります。 要件定義では、少なくとも次を確認します。

• どの機器・システムのログが必要か
• どの程度の期間保存するか
• 障害調査に必要な期間はどの程度か
• 監査や社内規程で保存期間が決められているか
• ログを誰が参照できる必要があるか

「ログを長く保存したい」という要望は曖昧です。 保存期間○か月・○年のように、可能なものは数値化します。

5．設定バックアップ

ネットワーク機器の設定が失われたり、変更後に問題が発生したりした場合に備えて、 設定を復旧できる条件を整理します。

• どの機器の設定をバックアップするか
• 変更前後の設定を残す必要があるか
• どの程度の期間、世代を保持する必要があるか
• 障害時に誰が復元するか
• バックアップデータへのアクセス権をどう扱うか

6．変更管理

ネットワークは稼働開始後も、VLAN追加、ACL変更、回線変更、ファームウェア更新などの変更が発生します。 そのため、変更をどのように承認・記録するかも要件として確認します。

• 変更申請が必要か
• 誰が承認するか
• 作業可能な時間帯はいつか
• 事前試験やレビューが必要か
• 変更履歴をどの程度残すか
• 障害時の切り戻し判断を誰が行うか

曖昧な運用要望を具体的な要件へ変換する

運用・監視でも、「しっかり監視したい」「すぐ連絡してほしい」「ログを残してほしい」といった曖昧な表現がよく出てきます。 これらを設計・試験で確認できる条件へ変換します。

良い要件は「満たしたか」を確認できる

運用・監視でも「要件」と「設計」を分ける

要件定義では「何を満たすか」を決め、設計では「どう満たすか」を決めます。 運用・監視でもこの考え方は同じです。

顧客ヒアリングで確認する質問

運用・監視要件を整理するときは、次のような質問を使えます。

1. ネットワークの運用を担当する部署・担当者は誰ですか？社内と外部委託の役割分担も確認します。
2. 監視が必要な機器・回線・サービスはどこまでですか？今回の対象範囲と対象外を明確にします。
3. 監視が必要な時間帯はいつですか？業務時間、夜間、休日などを確認します。
4. どのような障害を即時通知する必要がありますか？業務影響の大きさと優先度を確認します。
5. 障害通知は誰が受け取りますか？一次連絡先とエスカレーション先を確認します。
6. ログは何のために、どの程度の期間必要ですか？障害調査、監査、セキュリティなど目的を確認します。
7. 機器設定のバックアップはどのように管理していますか？現行運用と改善要望を確認します。
8. 設定変更時に必要な申請・承認・レビューはありますか？変更管理のルールを確認します。
9. 障害時の一次切り分けはどこまで実施しますか？運用チームと設計・保守担当の境界を確認します。
10. 現在の運用で困っていることはありますか？アラート過多、属人化、ログ不足、連絡遅延などの現状課題を把握します。

要件定義書にはどう残すのか

ヒアリング結果は、後から設計理由を追跡できる形で残します。 「顧客回答」だけでなく、要件、背景、未決事項まで整理すると後工程で使いやすくなります。

運用・監視要件でよくある失敗

顧客・上司へ運用・監視要件をどう説明するか

技術に詳しくない相手には、「SNMP」「Syslog」「しきい値」といった技術用語から話すより、 障害時の業務影響と対応の流れから説明すると伝わりやすくなります。

技術を業務影響へ変換する

運用・監視要件で使われる英語表現

よく使われる単語

ヒアリングで使える表現

自分の言葉で説明する課題