第３章 ネットワーク管理項目
この章では、管理機能単位でのネットワーク管理項目を具体的に説明する。
ネットワーク管理の成功要因は、管理機能と使用する機器・ソフト、人員
であるといわれており、ネットワーク管理項目は、下記のように多岐にわた
る。管理者層の策定したネットワーク管理のマネジメント方針に従い、必要
度、重要度に応じ内容を取捨選択し、適切なネットワーク管理を実施する。
・保有システム資産管理
・物理的管理
・環境管理
・論理的セキュリティ
・データ・インテグリティ
・バックアップ／復旧
・機器の保守
・要員・体制
・ユーザサポート
・ドキュメンテーション
・ベンダーとの関係
・オペレーション
・プログラム変更管理
３．１ 保有システム資産管理
注）ここでいうシステム資産とは、ＬＡＮ等のネットワーク環境で使用
されるシステム（ＥＤＰシステム）を構成する資産をいうものとし、
機器類だけでなくソフトウェアも含むものとする．
(1) システム資産管理規定の策定
ネットワーク管理者は、システム資産管理台帳やネットワーク構成図を整
備して、ネットワークシステムを運用し更新するための手続規定を策定し
なければならない。
1-1 システム資産管理の手続規定は、ネットワーク機器やソフトウェアを自
社に適した管理レベルで分類して管理対象を明確にしなければならない。
※ネットワークの構成機器は、例えば、バックボーンとフロント・エン
ドの別、サーバ機・クライアント機（ＷＳ／ＰＣ）、ルーター・ハブ
・モデム・その他のネットワーク機器等に分類される。
1-2 システム資産管理の手続規定を策定するにあたっては、安全性、信頼性、
効率性のいづれに重点を置くかを考慮しなければならない。
※安全性の例としては、ネットワークを災害や違法な侵入から守ること、
信頼性、効率性の例としては、ネットワークの中で情報が正確にある
いは効率良く伝達されること等である．
1-3 保有しているシステム資産管理の責任者とその管理範囲を明確にする。
※ネットワーク管理者、システムアドミニストレータ等。
(2) システム資産管理台帳
2-1 システム資産管理台帳には、ハードウェアに関しては、例えば、次のよ
うな管理項目を記載することになる。
※品名、識別番号、ＩＰアドレス、ＭＡＣアドレス、製造番号、
所在場所、管理責任者、製造日、購入日、メンテナンス業者名、
無償保証期間、インストールされているソフトウェア、
ソフトウェア上の設定項目
※管理項目の中に多くの同じような名前（あるものを他のものから識別
するためのもの）が掲げられているように見えるが、これはそれぞれ
に欠かすことのできない理由を持っている．
ＩＰアドレス−−−ＴＣＰ／ＩＰによるネットワークに不可欠な名前で
ある．ＩＰアドレスに対してデータが送信受信される．
ＭＡＣアドレス−−ネットワークインターフェイスのアドレスであり、
ネットワーク機器間の関連性を規定する．
製造番号−−−−−上記の名前が現品としての機器を目の前にして識別
できない論理的な名前に対して、製造番号は、人が
見て識別することができる名前である．実地棚卸に
際して役立つ．シリアルＮＯ．のこと。
識別番号−−−−−上記の名前は、それぞれに重要であるが、命名形式
が各々で異なっている．ＩＰアドレスは４８ビット
表記であり、ＭＡＣアドレスは４つの数字の組合せ
であり、製造番号はメーカーにより一様ではない．
そこで、会社としてシステム資産を管理しようとす
ると、統一されたネーミング基準を持った名前が必
要となる．それが、ここでいう識別番号である．
2-2 各ハードウェアには、削除したり、改変のできない識別番号を付け、識
別番号は重複してはならない。
※識別番号をどのように決めるかは自社の管理目的にそって考えるべき
ものであるが、ハードウェアに張付けるものであるから、セキュリテ
ィ上、ＩＰアドレスやドメイン名は使うことができない．
2-3 識別番号やアドレスは、全社でネーミング基準を統一しておく。
※ネーミング基準が各所でまちまちであると、機器が将来増加した場合
に管理が繁雑になるが、ネーミング基準を統一しておくと、保守管理
の一助になるとともにトラブルリカバリーの迅速化にも役立つ。
2-4 システム資産管理台帳には、ソフトウェアに関しては、例えば、次のよ
うな管理項目を記載することになる。
品名、製品番号、バージョン、管理部門、管理責任者、設置場所、
ライセンスの種類（自製品、購入品、シェアウェア、フリーウェア）
(3) システム資産管理台帳は定期的に更新して、別の安全な場所に保管し、障
害又は災害が発生したときに備える。
(4) 機器が陳腐化し、または、損傷した場合の廃棄基準や方針を策定し、それ
らに従った管理を実施する。
(5) 使用されていない機器やソフトウェアは、その理由を確認し、適切かつ安
全に保管する。（例えば、予備の機器）
(6) システム資産の実地棚卸
6-1 システム資産の実在性を確認し、システム資産管理台帳の正確性を担保
するため、定期的に棚卸を実施する。
6-2 ハードウェアの更新サイクルの短さと、セキュリテイの重要度とを勘案
して、実地棚卸は年に一回以上定期的に実施する．
6-3 各サイト毎に棚卸を実施する担当者を決め、該当サイトのキーマンが棚
卸の立会人となって実地棚卸を確認する。
6-4 棚卸表は、あらかじめ、サイト毎に一定項目を記載しておき、識別番号、
製造番号、設置場所などを記入または訂正するような様式にしておくと
よい。設置場所は図表で表すようにする。棚卸結果はキーマンが入力し、
コンピュータ上で管理する。
6-5 システム資産管理台帳と実地棚卸表との照合手続は、ネットワーク管理
者が行ない、差異あるものについては調査して適切な処置を行なう。そ
の結果は、棚卸差異明細書等に記録されるが、差異が現場で許可無く機
器を移動した様な原因である場合は、担当者にＬＡＮの機器構成をみだ
りに改変しないよう指導教育をすることが大切である。
(7) システム資産の購入基準
7-1 ネットワーク機器は、システム資産の購入基準にしたがって購入しなけ
ればならない．
※ソフトウェアについては、複数本まとめて安価にライセンス契約できる
もの（コーポレートパック）もある。
7-2 システム資産の購入基準は、ネットワーク機器の金額の多寡によって対
象範囲を限定するのではなく、ネットワークの安全性、信頼性、効率性
に影響を及ぼすすべての機器を対象としなければならない．
7-3 ネットワーク管理部門で集中購買すべき機器と、ネットワーク管理部門
の承認を得て各現場で申請すべき機器とをあらかじめ示しておくと、シ
ステム資産の購入手続は簡略化できる．
(8) システム資産の移設手続
8-1 ネットワーク機器は、ネットワーク運用管理者に申請し、許可を得た後
でないと、移設又は廃却してはならない．
8-2 ネットワーク運用管理者は、移設後の機器の接続の相性や、ネーミング
の変更の必要性などを検討しなければならない．
8-3 ネットワーク機器の移設は、システム管理台帳に直ちに記録されなけれ
ばならない。
8-4 取外したネットワーク機器は、設定項目を初期化した上で、下取りに出
した業者等をシステム管理台帳に記録する．
(9) システム資産の効率的管理
ネットワーク機器の効率的利用を計画的に見直す。
9-1 棚卸結果や利用状況、稼働状況にもとづき、購入計画の策定や見直しを
行いＣＩＯに報告する。
３．２ 物理的管理
ネットワーク環境では、ハードウェア機器やドキュメントが分散され、誰
でも容易に近づける環境にあるため、サーバ機やネットワーク機器、ドキュメ
ントなどへの物理的アクセス、不正使用、盗難に対する対策が必要である。
また、ケーブルはネットワークの盗聴やノードの追加やデータ・トラヒッ
クをモニタされる危険性から、部外者が容易にアクセスできないようにする
必要がある。
(1) ネットワーク構成機器及びドキュメンテーションは安全な施設に設置・
保管する。ファイル・サーバやネットワーク機器（ルータ等）はネット
ワーク管理者しか扱えないように制限する。
(2) ファイル・サーバ等の重要機器は、不正侵入に対し合理的に保護する。不
正侵入の方法やリスクを分析し、対策を立てる。
(3) ファイル・サーバ等の重要機器の鍵は，不正使用がないように適切に管理
する。
(4) ファイル・サーバ等の重要機器の収容場所は施錠され、あるいは機器自体
が移動できないように保護する。
(5) コンピュータ施設への入退室は、鍵・バッヂ・自動セキュリティ装置等
により、許可された要員に限定する。
(6) 許可されていない人間がコンピュータ施設へ入退室する場合は、許可さ
れた要員が立ち会ったり、立ち入り地域を限定したり、入退室記録を取
る。
(7) 情報セキュリティ管理者により管理状況がレビューされ、必要な改善策
を策定、管理者に報告する。
３．３ 環境管理
分散環境における環境管理は従来のホストコンピュータ管理の内容を踏襲
すれば、ほぼ事足りる。しかし従来よりも安易に考えられがちなので注意が
必要である。ハードウェアが安価になったからといって環境管理の費用も安
上がりにすると、データ量が増えている分だけ、余分に被害を受ける結果と
なる。
(1) ＬＡＮ構成機器への電力供給は、メーカーの仕様内になるように適切に
管理する。無停電装置などで保持する時間の基準を設ける。
(2) ファイル・サーバ等の重要機器の空調、湿度コントロール・システムは、
メーカーの仕様内に維持する。温度と湿度は規格をはずれると管理者に
通知するようにしておく。
(3) ファイル・サーバ等の重要機器は、静電気防止の敷物や静電気防止スプ
レーにより、静電気の影響から保護する。
(4) ファイル・サーバ等の重要機器は、埃、煙、食物の屑等が障害の原因と
ならないように管理する。（飲食、喫煙の禁止など）
(5) ファイル・サーバ等の重要機器は、警報付きの火災検知器によって保護
する。
(6) ファイル・サーバ等の重要機器は、漏水検知器によって保護する。
(7) ファイル・サーバ等の重要機器は、地震等の極度の揺れから保護する。
(8) バックアップのテープ、光磁気ディスク、ディスケット等は、極度の高
温による損傷、磁界の影響、冠水による損傷などから保護する。
３．４ 論理的セキュリティ
分散環境における論理的セキュリティは従来のホストコンピュータ管理の
内容を踏襲すれば、原則的には事足りる。しかし、情報の収納場所が限定さ
れていたホストコンピュータとは異なり、分散環境においてはすべての情報
の収納場所を把握することが困難な程、多岐にわたっている。したがって個
々の情報の収納場所において原則を遵守することが必要である。大部分で原
則通り運用されていても、一部に不備があるとそこから全体に問題が波及す
る場合があるので、特に注意が必要である。
(1) 情報セキュリティ管理者が任命され、組織の情報セキュリティに関する
計画・方針が策定、レビューされ、定期的（１〜３ヶ月ごと）に組織の
上級管理者へ報告する。利用者・管理者・セキュリティ管理者の役割と
責任を明確にする。
(2) システムへのアクセスを許可されたユーザ及び許可されていないユーザ
を識別、制約し、報告する自動化されたセキュリティ・システムなどに
より、アクセス・コントロールする。
(3) パスワードは定期的に変更する。または定期的（３〜６ヶ月ごと）に変
更するように要求されるシステムとする。必要に応じパスワードは内部
的に暗号化する。パスワードはスクリーンに表示しない。
(4) 正規ユーザは最初のアクセスをする際、省略時のパスワードを利用する
ようになっていなければならない。その後、ユーザは直ちにパスワード
を変更するようシステムから求められるようになっていること。
(5) ファイルサーバ等の重要機器について、ゲストアカウントを無効にする。
また、ルート（スーパーバイザーやアドミニストレータ）のＩＤを変更す
る。 (6) ユ一ザのクライアント機は、３〜６回の連続した不正ログオン時に
は、自動的に使用不可とする。
(7) ユーザのアクセス権は、管理者の承認に基づき、ニード・ツー・ノウ／
ニード・ツー・ドウ（必要な人にしか知らせない、必要な人しか使えな
い）基準に基づいて与える。
(8) ユーザに対するアクセス・コントロールと、データ資源、コンピュータ
資源に対するアクセス・コントロールを実施する。
(9) ユーザ・アクセス権の権限付与は、数名のシステム管理者に限定する。
(10) システム管理者は、自分が担当するコンピュータ上のデータへのアクセ
ス権限者を定期的にレビューする。
(11) アクセス権の追加、変更、削除は所定の書式により行う。また、退社・
異動等により、アクセス権が失われた者に対しては、速やか（１週間以
内）に削除する。
(12) システム管理者とセキュリティ管理者の役割を明確に定める。異なる人
物が担当するのが望ましいが、同一人物が担当する場合、役割の相違や
工数に配慮する。
(13) 不正アクセスのフォローアップは、自動集計し、文書化されたガイドラ
インに従って実施し、管理者に報告する。また、ガイドラインは再発を
防止するのに十分なものであること。
(14) ログオン・セッションは、暫くの間（５〜１０分程度）使用していなけ
ればログオフする。
(15) 外部と接続する場合は、管理者に連絡し承認を得た後、外部との接続を
安全にするためのセキュリティシステムの導入（例えば、ファイアウォ
ール）、ダイヤルバック機能の導入等のコントロールをする。
その内容は管理者と相談する。
(16) 端末が、直接またはダイヤルインアクセスを持つ顧客／取引先に設置す
る場合、機器設置のための同意書を正規の書面として契約締結を行う。
また、論理的アクセスコントロールが適切に行え、モニターできるよう
にする。
(17) システム全体をネットワーク管理ツールを利用しモニタリングする。
また、ログを採取し、一定期間保存する。
(18) システム資源に対して、緊急または一時的なアクセスが必要な場合に備
え、その手続きを定める。また、そのアクセスはシステム管理者及びセ
キュリティ管理者に報告し承認を得る。一時的なアクセスが頻繁にある
場合は、その理由を確認し対処する。
(19) オンライン・データ処理環境へのアクセスを許可する手続きの中には、
データの参照、追加、変更、削除の更新を制限したり、申請されたアク
セスの対象データまたはトランザクションのみに制限する。
３．５ データ・インテグリティ
分散環境におけるデータ・インテグリティの確保とは、従来のホスト集中
型システムにおけるその内容に加えて、分散システム特有の内容が含まれる
と考えることができる。つまり、データベースが物理的に分散している可能
性を考慮しなければならない。このことは、従来の環境においても、例えば
オフコンシステム等で支社支店に集計されたデータを、日次処理において本
店のデータベースに大集計するなどの形で見られたものではあったが、物理
的に分散している単一あるいは複数のデータベースが、リアルタイム処理に
おいて連動して動作するという形態が現れたことは、新たな注意をもってシ
ステムのチェックを行わなければならないことを意味している。
(1) データの機密レベルについて、統一した基準を設ける。
(2) 機密度の高いファイル（ソフトウェア、データ、ドキュメンテーション）
など、機密レベルに応じた取扱規定を定める。
（不正アクセス、不正更新、消失などからの保護）
(3) データベース及びファイルの物理的配置、構成とアプリケーションの処
理におけるそれらの関連を明確にする。
(4) システムの分散化が原因でデータの不整合が起きるような事態を予め洗
い出しておく。
(5) データの整合性が取れない事態が発生した時の原因追求手段を用意する。
(6) データの重要性、機密レベルを考慮して、必要に応じデータの暗号化を
実施する。
(7) アプリケーション・ソフトウェアの開発・保守に関するガイドラインを
定め、その内容は管理者の承認を得る。
ガイドラインには、以下の項目を含む。
・ユーザ要求の承認手続き
・ユーザ用件の定義とレビュー手続き
・費用対効果の分析
・ソフトウェア変更に対する管理者の承認
・導入に先立つソフトウェア変更の詳細なテストとユーザ、管理者の承認
・ソフトウェアの旧バージョンのバックアップ
・データの移行、バックアップ
・ソフトウェアのすべての変更及び更新の記録
・導入に先立ち影響を受けるユーザへの通知
(8) アプリケーションとシステム・ソフトウェアを含む全てのソフトウェア
を網羅した記録を備える。
３．６ バックアップ／復旧
バックアップ・復旧に関して追加されなければならない新たな観点は、分
散して保存されているデータを如何に効率的に且つデータ相互の整合性を保
ちつつバックアップするかということ、そして、このバックアップデータか
ら如何に正確且つ迅速に復旧できるかということである。ＬＡＮが普及し、
オープンシステムが企業の情報システムとして当然の形態になるにつれ、デ
ータそのものはその内容にかかわらず、物理的に分散の一途をたどる。バッ
クアップ・復旧に関して明確な方針を策定し、その手法を明示すること、ま
た新規に情報システムを構築する場合には、設計段階からこれを念頭に置い
ておくことなどが重要となる。もちろん、ネットワーク系システムを従来の
オフコン、汎用機として利用している場合にはこの限りではない。
(1) 主たるハードウェアないしソフトウェアの事故、あるいは一時的もしく
は長期間に亘る施設の破壊に対して、重要なアプケーション・プログラ
ムを処理するために文書化された計画を策定し、定期的に見直す。
(2) 災害復旧計画には、担当要員の安全を確保するための緊急の手続き、業
務再開・復旧のための手続きを定め、定期的に訓練を実施する。
(3) バックアップファイルの更新及び保守に関する方針を策定する。
(4) 災害時の復旧計画のために、アプリケーションは機密度、重要度に従っ
て、優先順位付けし、一覧表としてまとめておく。
(5) バックアップは対象業務の優先度に従い、それぞれの基準に従い行う。
(6) 全てのアプリケーションとシステム・ファイルのバックアップ・コピー
は、それらが最新であることを保証できるだけの時間間隔で作成する。
(7) バックアップ処理を行う担当者を正式な形で任命する。
(8) 分散処理ネットワーク自体に対して、文書化され、マメジメントが承認
した災害時復旧計画を策定・保持する。
また、災害時における連絡体制と役割分担を明確にしておく。
(9) ネットワークの災害時復旧計画の副本は、安全な場所に保管する。
(10) バックアップ・ファイルを用いて、災害時復旧手順を定期的にテストす
る。 (11) バックアップ・ファイルは、安全な所に保管する。
(12) ネットワーク・コンピュータ施設は、保険による填補により保全する。
(13) 分散処理ネットワーク内の重要な機器は、無停電電源装置で維持する。
(14) 障害時に使用するバックアップ機器は、十分に用意しておく。
(15) 障害記録、障害対策のデータベース化・情報共有化を行い、すばやい復
旧とコストの軽減を図る。
(16) バックボーン等重要なネットワークについては、二重化する。
(17) ファイルサーバ等の重要機器のハードデスクは、冗長アレイ（ＲＡＩＤ５）
を採用する。また、これらの機器について、ホットスタンバイシステムや
コールドスタンバイシステムを採用する。
３．７ 機器の保守
分散環境での機器管理上の考慮点は、ネットワークに接続するために購入
から運用、保守に至る過程のすべてをできる限り一元化することである。一
元化が不可能または実現的でない場合は、少なくとも管理のレベル（どの機
器をどのレベルの組織までが自由に管理できるか）を取り決めておくことと、
ネットワーク機器の推奨機種などのガイドラインを用意しておくことが必要
である。
(1) 保守管理について、ネットワーク管理部門での一括管理または、部門毎
に管理する機器などの方針や連絡手続きなどを文書で明確にしておく。
※一括管理するのがよいかどうかは一概にはいえないが、少なくとも機器
の保守に関する情報は、一元化させた方がよい。特にネットワーク機器
の保守は、システム・ソフトウェアの保守も含まれる場合があるため、
一元化することは１３）プログラム変更管理の５で述べるとおり重要で
ある。
(2) ネットワーク機器部品の定期クリーニングのスケジュールや手順を文書
化する。また定期クリーニングの実施内容を記録する。
(3) クリーニングの頻度と方法は、メーカーの勧告に従って行う。
※ネットワーク機器や部品の定期クリーニングがどの程度必要かは、運用
環境により異なる。また、ベンダーやリース業社によって行われる場合
もある。一般的に、ネットワークの信頼性を維持するために、クリーニ
ングを定期的に実施するのが望ましい。
(4) 機器の保守や交換のため、システムのダウンタイムのログ、機器エラー
など稼働状況の記録を取り、稼働率を監視しておく。
(5) 稼働率向上のため、システム管理者または保守契約に基づくベンダーに
よるスケジュール化された機器類の予防保守を行う。
※ネットワーク・システムの信頼性を維持するためにも、稼働率の監視や
予防保守が必要である。
(6) 機器の保守契約を交わす際、ベンダーの権利と義務を明確にしておく。
明確な契約でこのような記述がない場合でも、ベンダーとの役割分担を
明確にする。
※特に、マルチベンダー環境の障害の切り分けを誰が何処まで責任を持っ
て行うかを明確にしておくことは、障害対応を迅速にするのに役立つ。
３．８ 要員・体制
ＬＡＮを中心とした分散処理環境は、接続される機器やアプリケーション、
ユーザの増加が継続的に予想され、またハードウェア・ソフトウェアのバー
ジョンアップ、リプレイスの頻度も高い。ネットワーク管理部門担当者は複
数のバージョン、幅広いレベルのユーザをサポートしなければならない。さ
らにホストシステムと異なりマルチベンダであるため、ベンダからの一貫し
たサポートが受けられない、ユーザサポート要員が必要であるなど、管理者
は状況の変化に応じて適宜組織を見直すと共に、要員の育成に努めなければ
ならない。
(1) 情報システム部門、ネットワーク管理部門の役割や職務、作業分担を明確
にし、文書化する。
(2) ネットワーク管理組織については、管理者からの報告により、適正な増強
・改正を図る。
(3) ネットワーク管理部門担当者の役割や職務、作業分担を明確にし、文書化
する。
(4) 短期・長期のシステム化計画や管理体制、運用体制、情報技術の発達を
にらんで、要員の教育を計画的に実施する。
(5) システム管理者、セキュリティ管理者及びネットワークユーザのための
教育プログラムを設ける。
@運用者教育
（対象）ネットワーク運用担当者、ＬＡＮヘルプデスク担当者、キー
マン
（内容・実施時期）
・職務講習：任命時に各管理担当者／担当者の役割の説明
・技術講習：任命時に基本講習（管理ツールの操作、障害対応）
定期的にレベルアップ講習
（新ツール、バージョンアップ情報等）
・障害対応：月１回ペースでの情報交換会
技術基本講習は外注化を行ってもよい。
AＥＵＣ担当者教育
（対象）ＥＵＣヘルプデスク担当者
（内容・実施時期）
・職務講習：任命時に各担当者の役割の説明
・技術講習：任命時にインストラクター基本講習
（操作指導、障害対応）
定期的にレベルアップ講習
（新ツール、バージョンアップ情報等）
技術基本講習は外注化を行ってもよい。
Bネットワーク構築担当者、ＥＵＣ推進担当者教育
上記については定常的なカリキュラムは設けない。
ＬＡＮの展開計画に従って、上位マネジメントと相談の上、各自必要
な外部講習等を受講する。
(6) ネットワーク管理担当者の勤務状況、休暇の取得状況を定期的にレビュー
（本来業務に専念できているか、オーバーワークでないか）し、負荷配分
を適切に行う。
(7) 管理担当者人数については、作業実績とクライアントの増加数により、適
正な増減を図る。
ＬＡＮ管理を実行するために必要な人的リソースの数は、多くの要因
に依存する。この要因は、
・ユーザの教育レベルや教育を受けたユーザの数
・管理するクライアント機の数
・管理するサーバ機の数
・管理する相互接続機器の数
・ＬＡＮセグメントの地理的配置や距離
・クライアント機とサーバ機の密度
・使用している通信媒体
・継続的に監視を行うための機器の有効性
・トラブルシュートを行うためのツールの有効性
・ＬＡＮ管理グループのスキル・レベル
・ネットワーク管理組織のサポート・スキル
・稼動している業務システム、ツールの数
・稼動しているシステムの重要性
・利用内容、頻度
・社外との接続状況
などが挙げられる。
(8) システム管理者、セキュリティ管理者の異動等に伴う引き継ぎの手順は、
規定・文書化し、それに従って実施する。
(9) 導入・運用等の一部外注化
ＬＡＮといっても管理対象は広く、ＷＡＮ管理といってもよい状態である
ことが多く、この状態を社内情報部門で管理するには限界がある。
そのため、導入・運用等ある程度ルーチン化できる部分は外注化を行い、
社員は情報収集や企画・調査をメインに行うようにする。
ただし、既存マシンのバージョンアップ等については、複数機種・バージ
ョンへのサポート、部門の利用状況や導入の経緯・リプレース可否も含め
た判断・個別対応が必要なため、社員が行う。
３．９ ユーザサポート（ユーザ教育・ヘルプデスク）
ユーザが増加し、パソコンに馴染みのない人、反対に生半可な知識がある
人がシステムを利用するようになる。
・ＰＣは個人でソフトのインストール、環境の設定等が可能
→ ユーザが生半可な知識で変更・破壊してしまうおそれがある。
・ＬＡＮに対する意識の低さ
→ 一般のユーザ部門の管理職は管理意識がない
・在宅勤務への使用
→ 社外で目に見えない
これらのことより、ＬＡＮネットーワーク、ＥＵＣでは教育が非常に重要
である。
特に、コンピュータ・ウイルス、著作権、セキュリティについての教育啓
蒙は必須である。
(1) 適切な指導・サポート実施のために、ユーザの意識・ニーズ・レベルの違
い（技術部門と事務部門など）を把握する
(2) 社員の情報リテラシ向上のための教育を計画的に実施する。
(3) コンピュータ・ウイルス、著作権、セキュリティについての教育、啓蒙
活動を実施する。
ニューズレター等で新聞記事や社内外の実例を継続的に報知するのも有効
である。
(4) ＥＵＣを推進していくために以下を実施する
・エンドユーザのコンピュータ利用を支援するためのヘルプデスクを設置
する。
・ＬＡＮ、ネットワーク関係
・ＥＵＣ、グループウェア、電子メール等
・個別のアプリケーションおよび一部パッケージソフト
・サポートの効率化、要員の教育のため、利用状況、問い合わせ内容と
対応を記録する。
・グループウェア、ＥＵＣは、業務システムとは異なり、ツールの操作
方法を教えただけでは使いこなせないため、
・電子掲示板等で実用的なマクロや実際の利用例等の具体的な情報流通
の仕組みを構築
・事例発表会や表彰を実施
(5) 教育は知識・スキル・能力の維持・向上を図るため、継続して行なう。
[理由]
ネットワーク系システムは、ハードウェア・ＯＳ・ソフトウェアいず
れの製品化サイクルも早い。
３．１０ ドキュメンテーション
分散環境において、ドキュメンテーションは従来以上に重要なものである。
ホスト集中型システムよりも利用者が不特定多数になり、かつシステムに対
する知識もまちまちのため操作・運用やトラブル対応のためドキュメンテー
ションの重要性は増している。また、ネットワーク化によりデータ保護やセ
キュリティなどが大きな問題としてクローズアップされてきており、その対
策のためにもドキュメンテーションが重要になっている。
また、トラブルの原因・対応等をドキュメントにまとめ、再発防止やノウ
ハウの伝達に役立てることも重要である。ドキュメントの電子化や伝送によ
る更新など維持・管理に関する工夫も重要である。
(1) ネットワーク管理において十分な規定がドキュメント化されており、デ
ータの保護やセキュリティが守られる様になっていなければならない。
(2) トラブルや災害などの対応がドキュメント化されており、速やかに対応
できるようになっていなければならない。
(3) 各部門で正確・効率的な業務ができ、かつ不正・トラブル防止等の適切
な管理が実施できるように運用マニュアルを作成しなければならない。
また、ノウハウの伝達・レベルの維持のために部門管理者用のマニュア
ルを作成しなければならない。
(4) ログオン／ログオフ、バックアップ、ハードウェア保守、トラブル時の
対処・報告等について、以下のことを適切に行うためにその手順をドキ
ュメント化する。
・ セキュリティ対策
・ トラブル対応（再発防止）
・ データ保護
(5) 円滑な業務運営のため、迅速にトラブル対応するため、ネットワーク上
のアプリケーション全体について、ユーザーマニュアルを作成する。
(6) 運用マニュアル、ユーザーマニュアルは、安全な場所に保管する。
(7) 災害対策等のためマニュアルのコピーは、離れた安全な場所に保管する。
(8) 各マニュアルは、定期的にレビュー及びメンテナンスする。
また、各マニュアルは、業務の効率化・最新技術動向を取入れ、内容を
見直さなければならない。
マニュアルの内容にそって業務を行うよう徹底しなければならない。
３．１１ ベンダーとの関係
教育、技術支援、障害・災害・事故発生時など、適切なベンダーサポート
が得られるように、ハードウェアやソフトウェアの購入時には、信頼できる
ベンダーを選択し、必要事項を契約書に明記することや協力関係を築くこと
が重要である。阪神・淡路大震災においてもベンダーの強力なサポート体制
により早期に復旧できた例が数多く報告されている。
(1) ハードウェア及びソフトウェアの購入にあたって、ベンダーの信頼性を
考慮しておく。
特に海外企業の場合は、日本に代理店があり、十分な支援が得られるか
どうか考慮しておく。
(2) ハードウェア及びソフトウェアの購入契約書には、ベンダー・サポート、
ライセンス、所有権、納期、教育、技術支援、文書化条項、支払い条件、
アップグレード条項、債務不履行の場合の買手及びベンダーの賠償につ
いての条項を含んでおく。
特に海外のベンチャー等の場合は、Ｍ＆Ａ、倒産に関して、契約内容を
考慮しておく。
(3) ベンダーのサポート・サービスを文書化するために、サービスログを取
る。
(4) ハードウェア及びソフトウェアについて、実績及びノウハウが十分ある
ベンダーを選定する。
特に海外企業の場合、日本の代理店の規模、実績も考慮する。
(5) マルチベンダーを採用する場合、例えば本店と支店や、バックボーンと
フロント・エンドというように、契約時に各ベンダー毎の責任範囲を明確
にする。
３．１２ オペレーション
分散環境において、ネットワークの構成・管理は、重要な問題である。ト
ラブルによる業務ストップが社内外に大きな影響を与え、経営危機につなが
ることすら起こりうる。また、利用者数や業務・データが拡大していくため、
円滑に業務が執り行えるよう絶えず見直すことが必要である。
(1) ネットワークの構成・管理を行うため、技術動向を把握し、的確な判断
ができるようにならなければならない。また、運営のための組織を作り、
人員を配置しなければならない。
(2) システム管理者は、技術・ネットワーク構成・運用を監督するため、ネ
ットワーク施設のオペレーションに通じた経験者でなければならない。
(3) システム管理者は、トラブルの解決・原因究明・再発防止のため、ネッ
トワークのトラブル・シューティングに責任を持たなければならない。
(4) システム管理者には、災害対策・トラブル対策のため、バックアップの
支援要員計画を用意しなければならない。
(5) システム管理者は、運用メンバーの能力及び人数が適切かどうか定期的
にチェックしなければならない。
また、必要に応じて、メンバーの教育・増員を行い、業務を円滑に行え
るようにしなければならない。
(6) システム管理者は、ネットワークで起きた問題とその解決方法を記録し、
再発を防止するようにしなければならない。
(7) 周期的に使用されるアプリケーションの文書化されたオペレーション・
スケジュールを作らなければならない。
(8) システム管理者は、システムの有効活用・システム資源のチェック・ト
ラブル発見のため、レスポンス・タイム、ディスク・ストレージのスペ
ース、ネットワークの利用度について、監視しなければならない。
また、利用状況を把握することによって、権限の無いデータへのアクセ
スやハッカー進入の発見等のセキュリティ対策やシステム資源の拡張計
画が検討できるようにしなければならない。
(9) 処理能力が制約されている場合、システム管理者は、比較的重要でない
ユーザーより重要なユーザーが利用できるように優先計画を立て、業務
が円滑に行えるようにしなければならない。
(10) システム管理者は、ハードウェアの効率性と容量を定期的にチェックし
なければならない。
(11) オペレーションは手順通りに行ない、処理の漏れや順番間違いによトラ
ブル等を防がなければならない。
(12) 処理中に発生した事故は、全て記録・分析され、適時に解決し、管理者
に報告されなければならない。
要員の作業分担・連絡・引き継ぎを明確にし、事故の発生を未然に防止
する体制を作らなければならない。
３．１３ プログラム変更管理
分散ネットワーク環境においては、特にシステム・ソフトウェアの更新に
注意を払わなければならない。システム・ソフトウェアの更新を適切に管理
することにより、バージョンが不一致のために起こる様々な障害を避けると
ともに、問題判別、障害の局所化、早期回復が可能となる。
今後、アプリケーション・プログラムが分散環境に普及してくることから、
プログラム変更管理の重要性はますます大きくなるものと思われる。
(1) 本番のアプリケーションとシステム・ソフトウェアの更新に関し、文書
化され、承認された標準的な手続きを設けなければならない。
(2) 本番のアプリケーションとシステム・ソフトウェアの更新は、セキュリ
ティ管理者、システム管理者または適切に承認された支援要員によって
行われなければならない。
(3) プログラミングがネットワーク上で実施されている時、ソフトウェア・
ライブラリーの更新は、禁止されていなければならない。
※特にＥＵＣの環境においてより重要である。ソフトウェアの配布はプロ
グラムの作成者ではなく、システム管理者またはライブラリアンが行う
ことが望ましい。
(4) 様々な分散処理環境で使用されているアプリケーションとシステム・ソ
フトウェアのバージョンが、全体のネットワーク上で、相互互換かつ一
貫性を保っていることを保証する手続きを設けなければならない。
(5) アプリケーションとシステム・ソフトウェアの異なったバージョンは、
バージョン番号によって適切に認識できるようにしなければならない。
※システム・ソフトウェアの中でもネットワーク関連については、特に気
をつける必要がある。今では過去の話となっているが、例えば古いBSD
UNIX(ALL 0ブロードキャスト)とその後のTCP/IP標準(ALL 1ブロード
キャスト)のノード間を接続したとき、ブロードキャスト・ストームが
発生した。この例は極端かもしれないが、バージョンを合わせておく
ことが重要であること強調する例として適切である。
(6) 更新されたアプリケーションとシステム・ソフトウェアのバージョンは、
バックアップ・ファイルに保存されていなければならない。
(7) 全てのプログラム変更は、文書により管理者の承認を受けなければなら
ない。
(8) 緊急時のプログラム変更に対し、事後に正しく更新し、承認を得るよう
に規定した手続きがなければならない。
(9) 緊急時の更新を含む全てのソフトウェアの更新は、監査証跡を取るよう
に定められていなければならない。
また、監査証跡は、セキュリティ管理者によってレビューされなければ
ならない。