毎年、梅雨明けの7月末に情報化研究会のコアなメンバーで旅行会をしている。1995年以来だから今年で16年目だ。梅雨明けの時期にしているのは天候が安定していて盛夏らしい強烈な日射しや、群青色の海を楽しむことができるからだ。烈日と呼ばれる強い陽を浴びると、体にエネルギーを注ぎ込まれるように感じる。

　今年は東京、名古屋、松山から12人が参加し、2001年以来、9年ぶりに高知へ行った。もちろん大河ドラマ「龍馬伝」の影響だ。前回は桂浜の龍馬像、岩崎弥太郎の生家などを見学した。今回も高知が初めてという三菱グループの方が3人いたので、この2カ所も再訪したのだが、筆者の目当ては武市半平太と岡田以蔵の墓に参ることだった。

　さて、今回は企業ネットワークの設計や試験、移行の準備がきちんと行われ、サービス開始（旧ネットワークから新ネットワークへの移行開始）が可能かどうか判断する「サービス可否判定」（以下、サービス判定）について述べたい。

サービス判定会議

　7月上旬、筆者がプロジェクト責任者を務める企業のネットワーク設計・構築プロジェクトで、お客様とサービス判定会議を行った。もちろん、社内（筆者の所属する会社）における判定会議は既に実施済みで、社内の承認は受けていた。

　現代の企業ではネットワークの障害がそのまま業務停止につながるほど影響が大きいため、新ネットワークのサービスを開始するには、安全に移行できて十分な品質で運用できる裏付けが必要となる。それを経営者やシステムの実務者に説明し、サービス開始の許可を得るのがサービス判定会議の目的だ。重要なネットワークやシステムをカットオーバーする前には同様の会議がなされているはずだ。以下、一般的なサービス判定会議について述べる。

　会議で審議する主な項目は次の通りだ。

  • 課題管理：プロジェクトの課題が適切に管理され解消されていること
  • 要件の充足：所期する機能、性能などの要件が満たされていること
  • 試験計画・試験成績：必要十分な試験が行われ、結果が良好であること
  • 移行計画：移行体制・手順が適切であり、切り戻しも考慮されていること

　「課題管理」とはネットワーク設計・構築プロジェクトを進めて行く過程で出てくる課題を管理し、一つひとつ解決することだ。設計チーム、工事展開チーム、監視・保守チーム、回線開通チームがそれぞれの課題を管理する。

　課題として数が多いのは設計ではなく、回線開通や工事に関するものだ。技術的な課題より、泥臭い課題が多い。実際、筆者自身がプロジェクト責任者として一番エネルギーを使ったのはセンターの回線を予定通りに開通できるようキャリアに働きかけ、その進捗をチェックすることだった。以前、このコラムで書いた通り（「回線開通物語」の回を参照）センター回線が予定通りに開通できないと、移行スケジュール全体が遅れるからだ。

　また、各拠点の電源設備（コンセントや分電盤）に空きがあるか、回線開通のために配管工事が必要かどうか、現状調査を行い「正確に」把握することも骨の折れる仕事だ。工事ができる環境を整える上で問題のある拠点を洗い出し、それを解消していく過程は工事展開チームの課題管理表で進捗管理する。

　「要件の充足」とはRFP（Request For Proposal：提案要請書）で実現するよう求められた機能・性能・信頼性などの要件を満たしているかどうか判定することだ。我々SIerの社内試験でも評価するが、重要なのはお客様の実際のサーバーや端末を接続した本番と同等の環境で行う疑似環境試験だ。これはお客様データセンターに環境を作り、お客様と一緒に評価する。機能や性能もさることながら、ネットワーク障害のオンライン業務への影響を最小限にするため、機器や回線の障害時にRFPで指定された時間内にバックアップして業務が継続できるか、という信頼性対策の有効性の確認が重要だ。

　「試験計画・試験成績」は正常系（ネットワークに障害がない状態での機能・性能評価）、異常系（ネットワーク機器・回線が障害になったときのバックアップなどの動作確認）のそれぞれについて必要十分なテストが行われ、結果が良好であることを確認する。

　「移行計画」は現行ネットワークから新ネットワークへの移行方法が安全かつ効率的であるかどうか、移行時の体制（お客様宅に設ける移行本部の体制、本部と監視センター、現場との連絡方法など）、現場での作業手順書（手順、タイムスケジュール、不具合発生時の切り戻し判定基準、切り戻し手順など）をチェックする。