運用・保守

運用保守の位置づけ

運用・保守の対象はシステム全般であり、ハードウェアとソフトウェアがありますが、ソフトウェアのほうが全体の費用に占める割合が大きく、考慮すべき事項も多いので、ここでは主にソフトウェアを対象にします。ここでの保守とはソフトウェア保守とほぼ同じです。

システム開発が完了し引き渡しが行われる（導入）と、運用保守のプロセスになります。「運用」は平常時にシステムを円滑に稼働させるプロセスであり、「保守」とは故障や環境変更など何らかの事態が発生したときに、それに適応すべく解決することです。
　事態の解決には「改訂」という用語もあります。保守と改訂の区分は明確ではありません。一般に小規模な変更を保守、大規模な変更（作り直し）を改訂ということが多いのですが、全体を保守ということもあります。保守が必要になる理由を掲げます。

システム運用・保守のライフサイクルは、次のようになります（参照：「バスタブ曲線」）。

• 情報システムの受入れでは厳重なテストを行ったつもりでも、かならず見落としがあります。移行直後は修正保守の作業が多くなります。そのため、システム開発の契約では、検収後１年程度の瑕疵責任契約の条項を入れているのが通常です。
• それらの対策が終息すると、システムは安定状況になり、保守作業量は少なくなります。
• ユーザがシステムに慣れるのに伴い、新たな要求が提出され、改良保守が多くなります。
• 運用期間が長くなるのに伴い、多様な環境変化が発生して適応保守が多くなります。
• そして、それまでの部分的な保守により、システムが複雑になり保守作業の効率が悪くなりますので、現行システムを廃棄して、新規システムに改訂しようという機運が高くなります。

システムの移行

従来の手作業あるいは旧システムから新システムへの移行には、一斉移行と順次移行があり、それぞれ長所・短所があります。対象システムの特徴や環境を考慮して、適切な方法を選択することが大切です。

• 一斉移行
  全社的にシステム全体を一斉に移行する方法です。
  長所：インタフェースシステム（後述）の必要がないので、移行完了までの運用の負担は順次移行に比べて少なくできます。
  短所：トラブルが発生したとき、その対象が広範囲になり、解決のための費用が大きくなります。
• 順次移行（移行対象サブシステムの拡大）
  システムのうち一部のサブシステムから移行して、逐次拡大する方法です。
  長所：移行途中でトラブルが発生したとき、その発見や修正が容易です。一時的に旧システムに戻して対応することも容易です。
  短所：旧システムと新システム（サブシステム）の間のデータ受け渡しのためのインターフェースシステムが必要になります。そのために作業量が多くなります。
• 順次移行（対象部門の拡大）
  まず一部の事業所に適用して、対象となる事業所を拡大する方法です。
  長所：一部の事業所で試行することにより、移行での問題点や留意点が明確になります。トラブルを局所的に限定することができます。
  短所：移行作業が長くなり、その間は事業所間で新旧システムが混在することによる不都合が生じます。

外注によりシステム開発をするのが通常ですが、運用保守プロセスでも外部委託が広く行われています。そのサービスをＩＴサービスといいます。ＩＴサービス提供者は、システム開発受託者と同じこともありますが、異なることもあります。ユーザ企業とＩＴサービス提供企業との間で契約をするとき、サービスのレベルについて合意することが必要ですが、それをＳＬＡ（Service Level Agreement）といいます（参照：「ＳＬＡ／ＳＬＭ」）。

入力データ管理

運用プロセスで重要なのが入力データの管理です。システム自体は正常であっても、誤ったデータが入力されたことに起因するトラブルが発生します。

• 責任の所在
  データファイルや記憶媒体の管理（保管，機密保護，不正使用防止など）はシステム部門（運用部門）の任務です。しかし、データの内容については業務部門（ユーザ部門）が責任をもちます。
• 不正防止
  権限のない者が入力するのを防ぐには、本人認証を行う必要があります。権限をもつ者の不正防止には、元票発生担当者とデータ入力者を分離することも考えられます。また、入力者のシステム操作履歴をログファイルに記録して事後検査する方法もあります。
• 元票の正当性確認
  入力する元票に不正があってはなりません。それを防ぐために元票に業務部門管理者の承認印を押すのが通常です。
• エディットバリデーションチェック
  誤ったデータがシステムに入ると、その検出・修正は非常に大変です。入力ミスにより誤りデータが入力されないように、システムの入力チェック（エディットバリデーションチェック）を厳重にすることが必要です。このチェックには、フォーマットチェックやリミットチェックなどプログラムのチェックをするのに用いた方法が使えます。
• プルーフリスト
  二重入力や入力漏れを防止するには、入力データをプルーフリストに記録して、業務部門（元票発生部門）の管理者に送付して確認をとる方法が単純で確実です。これは不正防止にも役立ちます。
  その簡便型として、あらかじめ業務部門で元票の枚数や金額合計などを計算して管理者に報告しておきます。プルーフリストにはシステムが計算したそれらの値を出力します。管理者はその値で大まかなチェックをし、必要に応じて詳細を調べます。
• データの修正
  運用部門が、入力されたデータに誤りがあることに気付いた場合、運用部門が独断で修正してはいけません。誤りデータに関する情報を業務部門に伝え、業務部門が定められた方法により修正するようにする必要があります。
• データの保管・廃棄
  法的にはシステム内のデータ保管の規制はありませんが、財務諸表が正しいことを証明するのに、元票（あるいはその電子帳簿）から計算するのは大変です。監査等に必要なデータは、データ管理規程を作成し、規定に従った保管をする必要があります。セキュリティ対策も重要です。

保守の発生

保守は次のような理由により発生します。

• 修正保守（是正保守）
  現行のシステムに誤りがあることが発見されたので修正をすることです。
  ハードウェアでの故障多発への対処もこれに含めてよいでしょう。
• 改良保守
  システムを利用している間に、使いやすさのため、さらに高度な利用をしたいために、システムへの改良要望がでてきます。
• 完全化保守
  ソフトウェアの潜在的な障害が，故障として現れる前に，検出し訂正するための修正です。ソースコードと仕様書の不一致の修正なども含みます。
• 適応保守
  主として外部環境の変化に適応するためのものです。
  ・業務量増大やＩＴ技術進歩の発展に伴うハードウェアの性能追加
  ・関連する法律や制度の変更への対処
  ・ＯＳやＥＲＰパッケージなどのバージョンアップへの対処 （注） などがあります。

ハードウェアの保守

保守の種類

設備や機器などのハードウェアを対象とした保守は、故障した個所の修理や取替が主になります。

故障発生と保守のタイミングによる区分

　　事後保全（故障が発生してから対応）
　　　　緊急保全（人命や財産、広社会に影響を与える故障。最優先で対応）
　　　　通常事後保全（緊急性はなく通常の保守基準による対応）
　　予防保全（故障が発生する前に対応して、故障を防ぐ）
　　　　時間計画保全（ＴＢＭ：Time Based Maintenance）
　　　　　　定期保全（「毎月１５日」など、予定の時間間隔で行う）
　　　　　　経時保全（「稼働累積時間が１０００時間ごと」のように累積時間により行う）
　　　　状態監視保全（ＣＢＭ：Condition Based Maintenance、予知保全ともいう）
　　　　　　（定常的な運転状態を計測し、故障発生の前兆を察知して行う）

事後保守では、被害が大きくなるし、稼働が停止するので、予防保全により故障を防ぐことが重要です。しかし、時間計画保全は、無駄が生じるし、保全ミスによりかえって故障を招く（いじりこわし）ことがあります。状態監視保全は、それらの欠点を減らす効果があります。それには定常的な運転状態の計測と分析が必要で、それを設備診断技術といいます。

ハードウェアの保守は、メーカーや代理店と保守契約を結ぶのが通常です。保守契約には個々の障害の事後保守を対象とした個別契約と、障害の発生に関係なく月額固定料金を支払う定期契約があります。定期契約では予防保守や定期保守が含まれます。

ハードウェアのライフサイクルによる区分

製品の故障発生頻度は使用期間により、右図のように変化します。これをバスタブ曲線（浴槽のこと）といい、このような確率分布をワイブル分布といいます。

• 初期故障期
  稼働初期は仕様との違いやテストが不十分などによる故障が多発します。試運転や保証期間はそのためのものです。
• 偶発故障期
  初期の故障がなくなると、安定した状況になり、故障は偶発的なレベルになります。
• 摩耗故障期
  長期に使用するに伴い、摩耗や劣化による故障が増大します。故障が多発するようになると取替や廃棄をしまっす。

保守の方法

故障の発生を少なくすること、故障したときの復旧時間を短くすることが重要です。これについては、別章「ＲＡＳ，ＭＴＢＦ，ＭＴＴＲ」を参照してください。

ユーザ企業でのハードの保守では、メーカーから保守担当者が来て修理するのが通常ですが、それには時間がかかります。パソコンのような共通品の場合は、あらかじめ予備機を用意しておき、故障が発生したときは予備機を使用し、その間に故障機を修理することも考えられます。
　重要な機器は二重化することが望まれます。これについては、別章「システム構成」を参照してください。

異常が発生した場合，現場から離れた保守センターからネットワークを通して障害状況の調査をすることをリモート保守といいます。主にソフトウェアの保守で使われますが、ハードウェア保守でもこれを行うことにより、適切な担当者や必要な部品などを判断して修理時間を短縮できます。
　サーバなどの故障時でもユーザ自身で対処できること、あるいは、保守担当者の作業を短縮することが望まれます。例えばサーバ内部の各筐体をモジュール化して取外付けの作業に工具を必要としないようにすることをツールレス保守といいます。

運用保守管理

運用保守管理のポイント

保守を正しく効率的に行うためのポイントを列挙します。本来は、システム設計の段階から保守の容易性を高める工夫が必要なのですが、それに関しては別章「保守改訂を考慮したシステム設計」で扱いますので、ここでは既存システムの保守を対象にします。

• 記録性の重視
  新規開発と比較して、保守では規模が小さいこと、短期間対処が求められることなどから、ややもすると、プログラムを修正しただけで、仕様書などの関係文書の修正をなおざりにする傾向があります。これでは、仕様書と実際に稼働しているシステムが異なることになり、仕様書が役に立たないだけでなく、誤った情報を提供することにもなります。
  修正が必要になった理由、修正個所、テスト結果などを記録することが大切です。
• 稼働システムとの分離
  稼働システムに直接修正を加えることは厳禁です。修正すべきプログラムを保守用のライブラリにコピーして、それを修正して、正しく修正されたことを確認してから、稼働システムに移します。
  また、稼働システムを運用している運用担当者と、保守を行う担当者は別人であることが求められます。同一人にすると、運用時にプログラムを改ざんして不正行為を行う危険があるからです。
• 修正の波及確認
  あるプログラムを修正することにより、他のプログラムに影響を与えることがあります。しかも、日次処理のプログラムを修正したのに、月次処理や期末処理に関係するプログラムの修正を、それらの処理が行われるまで気付かなかったというようなことがよく起こります。影響範囲の調査を効率よく行うために、リポジトリ（辞書、体系表）などのツールを使用することが望まれます。
• 保守管理体制
  保守案件は続出します。その順序に考慮しないと、異なる修正作業で同一のプログラムを修正して矛盾が生じることがあります。また、緊急を要する修正が後回しにされてしまうことも起こります。このようなことを回避するために、保守管理の統一的な管理を行う体制が必要になります。

保守の優先順位

保守を要する案件は、数多く発生します。対応する優先順位は、３つの観点で決定します。

• システムの重要性
  システムが停止したときの影響度です。代替手段の困難性も考慮します。
  ・生命や財産に影響を与えるシステム。社会的に大きな影響を与えるシステム
  （災害検知システム、銀行のＡＴＭシステム、交通管制システムなど）
・組織にとって重要なシステム
（オンライン販売システムなど）
・組織にとって軽微なシステム
• 対処の緊急性
即時対応が必要か、復旧までに数日、数か月の余裕があるかなどです。
• 他の保守案件との関係
  Ａ案件を解決するには、Ｂ案件が解決している必要があるというような関係です。

「重要性＞緊急性＞他との関係」で重視します。通常は、重要性と緊急性は一致することが多いのですが、他との関係では一致しないことが多くあります。Ａの重要性、緊急性が高い場合、二度手間になってもＢの解決を待たずにＡを行うことを考えるべきです。

保守のマネジメント基準とアウトソーシング

運用保守の重要性が高まりマネジメントとして認識されるようになりました。それに伴い、マネジメントの基準がＩＳＯなどの規格になり、管理実務を請け負うサービスも出現してきました。

• ＢＣＰ（事業継続計画）
  災害時などにおいても事業を継続することは企業の社会的責任です。それには情報システムの維持が重要だと認識されるようになりました（参照：「事業継続計画（ＢＣＰ／ＢＣＭ）」）。
• ＩＴサービスマネジメント
  保守・運用は、ＩＴサービスと呼ばれています。ＩＴサービスをマネジメントとして管理することをＩＴサービスマネジメントといい、その標準規格をＩＴＩＬといいます（参照：「ＩＴサービスマネジメントとＩＴＩＬ」）。
• ＳＬＡ
  ＩＴサービスを請け負う業種が普及してきました。ユーザ企業とＩＴサービス提供者との間で契約するとき、サービスのレベルについて合意することをＳＬＡ（Service Level Agreement）といいます（参照：「ＳＬＡ／ＳＬＭ」）。
• クラウドコンピューティング
  ハードウェアを外部のデータセンターに設置して、機器の稼働状態の監視とオペレーション、不正アクセスの監視や対策などの業務をアウトソーシングする傾向は以前からが進んできました（参照：「運用外部委託の種類」）。
  近年ではさらに進んで、ハードウェアだけでなくソフトウェアやデータまで外部に保存し、自社にはインターネットに接続するパソコンだけがあればよいいうクラウドコンピューティングが注目されています（参照：「クラウドコンピューティング」）。
  このような傾向は、運用保守管理が社内から社外を対象になるという変化を生じてきました。
• ファシリティマネジメント
  ファシリティとは施設や設備のことです。ファシリティマネジメントとは、施設や設備の管理、効果的活用、防犯対策を行うことで、必ずしもＩＴに限定したものではありませんが、ＩＴでも重要なマネジメント対象になっています。例えば、コンピュータ室の電源、空調などの管理や入退室管理などが物理的環境面での管理が基本機能ですが、さらにハードウェアや通信機器の監視などを含むこともあります。これらの実務を外部委託することもあります。
• アセットマネジメント
  アセットとは資産のことです。施設や設備も資産です。アセットマネジメントには２つの意味があります。
  官公庁や地方自治体は道路、水道、港湾、ダムなどの管理をしていますが、それをアセットマネジメントといっています。この意味では、アセットマネジメント＝ファシリティマネジメントと考えられます。
  「資産運用」の意味でアセットマネジメントということがあります。現金や有価証券を対象にすることもありますが、施設や設備などの固定資産を貸したり売却して利益を上げることを指すこともあります。この意味では、アセットマネジメントはファシリティマネジメントの一部だといえます。