システムの移行
従来の手作業あるいは旧システムから新システムへの移行には、一斉移行と順次移行があり、それぞれ長所・短所があります。対象システムの特徴や環境を考慮して、適切な方法を選択することが大切です。
- 順次移行（移行対象サブシステムの拡大）
- システムのうち一部のサブシステムから移行して、逐次拡大する方法です。
長所：移行途中でトラブルが発生したとき、その発見や修正が容易です。一時的に旧システムに戻して対応することも容易です。
短所：旧システムと新システム（サブシステム）の間のデータ受け渡しのためのインターフェースシステムが必要になります。そのために作業量が多くなります。
- 一斉移行
- 全社的にシステム全体を一斉に移行する方法です。
長所：インタフェースシステムの必要がないので、移行完了までの運用の負担は順次移行に比べて少なくできます。
短所：トラブルが発生したとき、その対象が広範囲になり、解決のための費用が大きくなります。
- 順次移行（対象部門の拡大）
- まず一部の事業所に適用して、対象となる事業所を拡大する方法です。
長所：一部の事業所で試行することにより、移行での問題点や留意点が明確になります。トラブルを局所的に限定することができます。
短所：移行作業が長くなり、その間は事業所間で新旧システムが混在することによる不都合が生じます。
入力データ管理
システム自体は正常であっても、誤ったデータが入力されたことに起因するトラブルが発生します。
誤りデータが入力されないように、システムとして入力時のチェックを厳重にする機能が必要ですが、万全を期することはできません。ここでは、誤ったデータが発見されたときの対処を対象にします。
データを保管しているファイルや記憶媒体の管理（保管，機密保護，不正使用防止など）はシステム部門（運用部門）の任務です。しかし、データの内容については業務部門（ユーザ部門）が責任をもちます。
運用部門が、入力されたデータに誤りがあることに気付いた場合、運用部門が独断で修正してはいけません。誤りデータに関する情報をユーザ部門に伝え、ユーザ部門が定められた方法により修正するようにする必要があります。
ユーザ部門から渡された伝票を運用部門が入力する場合では、入力原票１件ごとの入力結果の確認は，処理結果リストをユーザ部門に送付し，ユーザ部門が行うことにしるのが適切です。
これらは不正防止の観点からも重要です。
ハードウェアの保守
ハードウェアの信頼性に関しては、「ＲＡＳ，ＭＴＢＦ，ＭＴＴＲ」や「システム構成」などを参照してください。主にハードウェアを対象とした保守をタイミングで区分すると次のようになります。
- 事後保守
- 障害が発生した後で行われる保守
- 予防保守
- 定められた使用期間を経過したら部品を交換するなどの保守
- 定期保守
- 例えば、毎月点検を行い、必要に応じて部品交換を行う保守。予防保守の一部だともいえます。
本来は、ハードウェア、ソフトウェアに区分するのではなく、システム全体として行うべきです。しかし、ハードウェアは経年劣化や故障などがあるのに対して、ソフトウェアでは作成段階でのエラーや新機能追加などによる保守が主になります。また、一般的には契約ベンダも異なるのが通常です。
以降は主としてソフトウェアを対象します。
保守改訂の発生
保守と改訂の区分は明確ではありません。一般に小規模な変更を保守、大規模な変更（作り直し）を改訂といういうことが多いのですが、全体を保守ということもあります。
保守が必要になる理由を掲げます。
- 修正保守
- 現行のシステムに誤りがあることが発見されたので修正をすることです。
- 改良保守（完全化保守）
- システムを利用している間に、使いやすさのため、さらに高度な利用をしたいために、システムへの改良要望がでてきます。
- 適応保守
- 主として外部環境の変化に適応するためのものです。
・関連する法律や制度の変更への対処
・ＯＳやＥＲＰパッケージなどのバージョンアップへの対処
・Ｗｅｂサイトへのアクセス頻度増大への対処
などがあります。
（注）バージョンアップが実務的に深刻な問題になっています。
現状のＯＳやＥＲＰパッケージなどで一応満足しているのに、ベンダがバージョンアップを行い、現行のバージョンのサポート打切りをすることがあります。
ベンダは、最新のバージョンのほうが優れているし、あまり古いバージョンまでもサポートするのは費用がかかるといいます。しかし、ユーザとしては、これらへの対処には、膨大な量の既存アプリケーションが新バージョンで正常に稼働するかどうかの点検が必要になります。また、現行バージョンのサポートが打ち切られると、誤りが発見されても修正してくれないし、最新のセキュリティへの対処も受けられません。バージョンアップをすべきかどうかの判断が経営問題にすらなっているのです。
保守管理
システム運用・保守のライフサイクルは、次のようになります。
- 情報システムの受入れでは厳重なテストを行ったつもりでも、かならず見落としがあります。移行直後は修正保守の作業が多くなります。そのため、システム開発の契約では、検収後１年程度の瑕疵責任契約の条項を入れているのが通常です。
- それらの対策が終息すると、システムは安定状況になり、保守作業量は少なくなります。
- ユーザがシステムに慣れるのに伴い、新たな要求が提出され、改良保守が多くなります。
- 運用期間が長くなるのに伴い、多様な環境変化が発生して適応保守が多くなります。
- そして、それまでの部分的な保守により、システムが複雑になり保守作業の効率が悪くなりますので、現行システムを廃棄して、新規システムに改訂しようという機運が高くなります。
保守を正しく効率的に行うためのポイントを列挙します。本来は、システム設計の段階から保守の容易性を高める工夫が必要なのですが、それに関しては別章で扱いますので、ここでは既存システムの保守を対象にします。
- 記録性の重視
新規開発と比較して、保守では規模が小さいこと、短期間対処が求められることなどから、ややもすると、プログラムを修正しただけで、仕様書などの関係文書の修正をなおざりにする傾向があります。これでは、仕様書と実際に稼働しているシステムが異なることになり、仕様書が役に立たないだけでなく、誤った情報を提供することにもなります。
修正が必要になった理由、修正個所、テスト結果などを記録することが大切です。
- 稼働システムとの分離
稼働システムに直接修正を加えることは厳禁です。修正すべきプログラムを保守用のライブラリにコピーして、それを修正して、正しく修正されたことを確認してから、稼働システムに移します。
また、稼働システムを運用している運用担当者と、保守を行う担当者は別人であることが求められます。同一人にすると、運用時にプログラムを改ざんして不正行為を行う危険があるからです。
- 修正の波及確認
あるプログラムを修正することにより、他のプログラムに影響を与えることがあります。しかも、日次処理のプログラムを修正したのに、月次処理や期末処理に関係するプログラムの修正を、それらの処理が行われるまで気付かなかったというようなことがよく起こります。影響範囲の調査を効率よく行うために、リポジトリ（辞書、体系表）などのツールを使用することが望まれます。
- 保守管理体制
保守案件は続出します。その順序に考慮しないと、異なる修正作業で同一のプログラムを修正して矛盾が生じることがあります。また、緊急を要する修正が後回しにされてしまうことも起こります。このようなことを回避するために、保守管理の統一的な管理を行う体制が必要になります。