運用と保守の違いとは？AI活用とインフラの役割を徹底解説

 

ITシステムの安定稼働に欠かせない「運用」と「保守」は、それぞれ役割が異なり、理解は初心者にとって不可欠です。本記事では、運用保守の違いを明確にし、AI技術の導入効果や、システムを支えるインフラの重要性、内製と外注の活用ポイントまでをわかりやすく解説します。運用保守の全体像を知ることで、効率化やリスク低減に役立つでしょう。

 

 

 

 

 

 

 

 

１．運用と保守の違いとは？

システムを安定して使い続けるために欠かせないのが「運用」と「保守」です。まとめて「運用保守」と呼ばれることも多いため、同じ業務だと思われがちですが、それぞれ目的や対応する業務が異なります。簡単に整理すると、運用は「システムを日々安定して使える状態に保つこと」、保守は「システムを維持し、必要に応じて修正・改善すること」です。

例えば、システムが正常に稼働しているかを監視したり、定期的にバックアップを取得したりするのは運用にあたります。一方、不具合が発生した際に原因を調査してプログラムを修正したり、OSなどの環境変化に合わせてシステムを改修したりするのは保守にあたります。どちらか一方だけを行えばよいわけではありません。運用によって日々の状態を把握し、問題が発生したときには保守によって対応することで、システムを長期的に安定して利用できるようになります。

 

システム運用とは

システム運用とは、完成したシステムを利用者が日々問題なく使えるように、稼働状況を確認・管理する業務です。システムは一度開発してリリースすれば、その後何もしなくても安定して動き続けるわけではありません。サーバーやネットワークの負荷、データ容量、バックアップ状況などを継続的に確認し、異常が発生していないかを把握する必要があります。

例えば、システム運用には次のような業務があります。

 

・システムやサーバーの稼働状況の監視
・CPUやメモリ、ストレージなどの使用状況の確認
・ログの確認
・データのバックアップ
・アカウントや権限の管理
・定期的なシステムの起動・停止
・利用者からの問い合わせ対応
・定期処理やバッチ処理の実行・確認

 

こうした作業を日常的に行うことで、障害につながる兆候を早期に発見したり、問題が発生した際に速やかに対応したりできるようになります。つまり運用は、「システムが正常に動いている状態を維持するための日常管理」と考えると分かりやすいでしょう。

 

システム保守とは

システム保守とは、不具合や障害への対応、プログラムの修正、環境変化への対応などを行い、システムを継続して利用できる状態に維持・改善していく業務です。代表的なのが、システム障害への対応です。例えば、「画面が表示されない」「データを登録できない」「処理が途中で止まる」といった問題が発生した場合、ログやプログラム、データベースなどを調査して原因を特定し、必要に応じてプログラムや設定を修正します。また、システム自体に問題が発生していなくても、周辺環境の変化によって保守が必要になることがあります。

 

例えば、OSやブラウザ、データベース、ミドルウェアなどがアップデートされたことで、これまで動いていたシステムが正常に動作しなくなるケースです。こうした環境変化に合わせてプログラムや設定を変更することも、保守の重要な役割です。さらに、業務内容の変化に伴う小規模な機能追加や改修などを、保守業務の一環として対応する場合もあります。保守は単に「壊れたシステムを直すこと」ではありません。現在のシステムを維持しながら、必要な修正や改善を行い、これからも使い続けられる状態にすることが大きな役割です。

関連記事として、突然の"保守打ち切り"がもたらすリスクと、備えるべき選択肢、サーバ保守運用の基本と効果的な体制構築ガイド、システム保守の重要性と保守引継ぎサービスの活用 ― 安定稼働を支える体制づくりとはもあわせてご覧ください。

 

運用と保守の違いを比較

運用と保守の大きな違いは、業務を行う「目的」にあります。運用は、正常に稼働しているシステムを安定して利用できる状態に保つことが中心です。一方、保守は、不具合や環境変化などに対応し、システムそのものを修正・改善することが中心となります。例えば、毎日サーバーの状態を確認することは「運用」です。その確認中にエラーを発見し、原因となっているプログラムを修正する場合は「保守」になります。

 

両者の違いを整理すると、次のようになります。

 

 

ただし、実際の現場では運用と保守が完全に分離されているとは限りません。企業や契約内容によっては、一つの担当者や一つの会社が運用と保守の両方を担当することもあります。そのため、「これは運用だから」「これは保守だから」と名称だけで判断するよりも、誰が・どこまで・どのような場合に対応するのかを明確にしておくことが重要です。

 

運用と保守の連携が重要な理由

運用と保守は役割が異なりますが、システムの安定稼働という目的は共通しています。そのため、両者を切り離して考えるのではなく、連携できる体制を整えることが大切です。例えば、運用担当者が日常的な監視の中で「最近処理時間が長くなっている」「特定のエラーが増えている」といった変化に気付いたとします。この情報を保守担当者へ共有できれば、実際にシステムが停止する前に原因を調査し、必要な対策を講じられる可能性があります。反対に、保守担当者が障害を修正した後、その原因や注意すべき兆候を運用担当者へ共有しておけば、同じような問題が発生した際に早期発見しやすくなります。

このように、

 

運用で異常や兆候を発見する
→ 保守で原因を調査・修正する
→ 再発防止策を検討する
→ 運用方法や監視項目へ反映する

 

という循環を作ることが、安定したシステム運用につながります。

特に基幹システムなど、停止すると業務全体に影響するシステムでは、障害が起きてから対応するだけでは十分ではありません。日頃から状態を把握し、問題を早期に発見できる運用と、発生した問題を適切に解決できる保守の両方を整えておくことが重要です。

 

 

 

２．システム運用の主な仕事内容

システム運用と一口にいっても、その業務内容は多岐にわたります。システムの種類や企業の運用体制によって担当範囲は異なりますが、基本的には「システムを日々安定して利用できる状態に保つための業務」が中心です。ここでは、代表的なシステム運用の仕事内容を4つに分けて解説します。

 

システムの監視・稼働状況の確認

システム運用の基本となるのが、システムやサーバー、ネットワークなどの監視です。システムが正常に動作しているか、CPUやメモリの使用率が高くなっていないか、ストレージ容量が不足していないか、エラーが発生していないかなどを継続的に確認します。監視ツールを利用し、一定の基準を超えた場合にアラートを出す仕組みを構築することもあります。重要なのは、単に「システムが停止しているかどうか」だけを見ることではありません。例えば、システム自体は動いていても、以前より処理速度が遅くなっていたり、ディスクの空き容量が徐々に減っていたりする場合があります。その変化を放置すると、将来的な障害につながる可能性があります。日常的に稼働状況を確認し、小さな変化を早めに把握することで、大きなトラブルを未然に防ぎやすくなります。

 

バックアップ・データ管理

万が一の障害に備えてデータをバックアップすることも、重要な運用業務の一つです。ハードウェアの故障やシステム障害、操作ミスなどによってデータが失われた場合でも、適切なバックアップがあれば、一定の時点までデータを復旧できる可能性があります。ただし、「バックアップを取っているから安心」とは限りません。バックアップが正常に取得できているか、必要なデータが対象になっているか、どの時点まで戻せるのか、実際に復元できるのかなども確認しておく必要があります。例えば毎日バックアップを取得していても、エラーによって数週間前から正常に保存されていなければ、障害発生時に初めて問題に気付くことになります。

そのため、

 

・バックアップの実行結果を確認する
・保存期間を決める
・バックアップデータの保存場所を管理する
・必要に応じて復元テストを行う

 

といった運用まで含めて考えることが重要です。

 

セキュリティ・アカウント管理

システムを安全に利用するためのアカウント・権限管理も、運用業務に含まれます。新しい社員が入社した際にアカウントを発行したり、異動に合わせてアクセス権限を変更したり、退職者のアカウントを停止したりする作業が代表例です。必要以上の権限を付与したままにすると、本来閲覧する必要のない情報へアクセスできてしまうなど、セキュリティ上のリスクにつながります。特に人事異動や組織変更が多い企業では、「誰がどのシステムへアクセスできるのか」を継続的に管理することが重要です。また、不審なログインやアクセスが発生していないかを確認したり、セキュリティに関するログを管理したりすることもあります。システムを安定して「動かす」だけでなく、適切な人が適切な権限で安全に利用できる状態を維持することも運用の役割です。

 

問い合わせ対応・定期作業

利用者からの問い合わせ対応も、システム運用では重要な業務です。

例えば、

 

「システムにログインできない」
「操作方法が分からない」
「データが表示されない」
「パスワードを忘れてしまった」

 

といった問い合わせに対応します。問い合わせ内容を確認した結果、単純な操作方法の案内で解決することもあれば、システム自体に問題があり、保守担当者による調査が必要になる場合もあります。そのため運用担当者には、問い合わせを受け付けるだけでなく、運用で対応できる問題なのか、保守へエスカレーションすべき問題なのかを判断する役割もあります。そのほか、月次処理やデータ連携、定期バッチの実行確認、マスターデータの更新など、企業ごとに決められた定期作業も運用業務に含まれる場合があります。こうした日々の業務は、一つひとつを見ると小さな作業に思えるかもしれません。しかし、どれか一つでも適切に行われなければ、システム障害や業務停止につながる可能性があります。システム運用では、トラブルが発生してから対応するのではなく、日常的な監視・管理・確認を積み重ね、問題が起こりにくい状態を維持することが重要です。次章では、こうした運用によって発見された障害や不具合への対応を含め、「システム保守では具体的に何をするのか」を詳しく解説します。

 

 

３．システム保守の主な仕事内容

システム保守は、稼働中のシステムに発生した問題への対応や、環境の変化に合わせた修正・改善を行い、システムを継続して利用できる状態に保つための業務です。システムは長く利用していると、不具合や障害が発生するだけでなく、OSやブラウザなどの周辺環境が変化したり、業務内容の変更によって新しい機能が必要になったりします。そのため、保守では「障害が発生したら直す」だけでなく、現在のシステムを維持しながら、必要に応じて修正・改善していくことが求められます。ここでは、代表的なシステム保守の仕事内容を4つに分けて解説します。

 

障害発生時の原因調査・復旧

システム保守の代表的な業務が、障害やトラブルが発生した際の原因調査と復旧です。

例えば、

 

・システムにログインできない
・画面が正常に表示されない
・データを登録・更新できない
・処理中にエラーが発生する
・外部システムとのデータ連携が停止する
・特定の操作をするとシステムが動かなくなる

 

といった問題が発生した場合、まずはどこに原因があるのかを調査します。システムの障害は、必ずしも一つの原因だけで発生するとは限りません。アプリケーションのプログラムに問題がある場合もあれば、データベースやサーバー、ネットワーク、外部サービスとの連携などが影響している場合もあります。

そのため、エラーログや操作履歴、システムの稼働状況などを確認しながら原因を切り分け、必要な対応を行います。特に企業の基幹システムでは、販売管理や在庫管理、生産管理、受発注など日々の業務と直接結びついていることがあります。障害によってシステムを利用できなくなると、単なる「システム上の問題」ではなく、業務そのものが止まってしまう可能性があります。そのため保守では、原因を正確に特定することに加えて、影響範囲や緊急度を判断しながら、できるだけ早く業務を正常な状態へ戻すことが重要です。

 

不具合修正・アップデート

システムを利用している中で発見された不具合の修正も、保守の重要な業務です。例えば、特定の条件で計算結果が正しく表示されない、特定の操作を行った場合だけエラーになるなど、開発時には発見できなかった問題が運用開始後に見つかることがあります。こうした場合には、問題が発生する条件や原因を調査したうえでプログラムを修正し、正常に動作することを確認してからシステムへ反映します。また、システムそのものに変更がなくても、周辺環境のアップデートによって対応が必要になる場合があります。業務システムは、OS、ブラウザ、データベース、ミドルウェア、外部サービスなど、さまざまな技術やサービスと組み合わせて動作しています。これらのバージョンが変更された結果、それまで利用できていた機能が正常に動かなくなることもあります。例えば、OSのサポート終了に伴って新しいOSへ移行したところ、一部の機能が正常に動作しなくなったり、外部サービスの仕様変更によってデータ連携ができなくなったりするケースです。そのため保守では、現在発生している不具合だけを見るのではなく、システムを取り巻く環境の変化にも対応していく必要があります。

 

機能追加・システム改修

企業の業務は、システムを導入した時点から変わらないとは限りません。事業の拡大や新しいサービスの開始、組織変更、法改正、取引先からの要望などによって、システムに求められる機能も変化します。

例えば、

 

・入力項目を追加したい
・帳票のレイアウトを変更したい
・新しい検索条件を追加したい
・既存の業務フローに合わせて画面を変更したい
・外部サービスや別システムとデータを連携したい

 

といった要望が発生することがあります。このような既存システムへの機能追加や改修についても、保守を担当している会社が対応するケースがあります。ただし、どこまでを通常の保守契約に含めるかは契約内容によって異なります。軽微な設定変更であれば保守範囲内でも、大規模な機能追加や仕様変更については別途開発として扱われる場合があります。そのため、保守契約を結ぶ際には「月額の保守費用に何が含まれているのか」「追加の改修が必要になった場合はどのような扱いになるのか」を確認しておくことが重要です。システムを長く利用するのであれば、現在の状態を維持するだけでなく、業務の変化に合わせて改善していける体制があるかどうかも重要なポイントになります。

 

障害の再発防止と改善

システム保守では、発生した障害を復旧させて終わりではありません。同じ問題を繰り返さないために、障害が発生した原因を整理し、必要に応じて再発防止策を講じることも重要です。例えば、サーバーの容量不足によってシステムが停止した場合、一時的に不要なデータを削除して空き容量を確保すれば、システムを復旧できるかもしれません。しかし、それだけではデータが再び増えたときに同じ問題が発生する可能性があります。その場合には、容量が一定の水準に達した段階で通知するよう監視方法を見直したり、保存するデータのルールを変更したり、必要に応じてサーバーの増強を検討したりすることが再発防止につながります。また、障害対応で得られた情報を記録しておくことも重要です。「どのような現象が発生したのか」「原因は何だったのか」「どのような対応を行ったのか」といった情報を蓄積しておけば、同様の問題が発生した際に、より迅速に対応できる可能性があります。さらに、同じ問い合わせや軽微なトラブルが頻繁に発生している場合には、操作方法だけでなく、システムそのものに改善すべき部分がないかを検討することも大切です。このように保守では、「問題を直す」だけでなく、「同じ問題を繰り返さない」「より使いやすく安定したシステムへ改善する」という視点も求められます。

 

 

 

 

４．運用・保守を適切に行わない場合のリスク

システムが現在問題なく動いていると、「運用や保守にそれほど手をかけなくても大丈夫なのではないか」と考えてしまうことがあります。しかし、システムに関する問題は、ある日突然発生したように見えても、その前から小さな異常やリスクが積み重なっている場合があります。特に長期間利用している業務システムでは、システムそのものの老朽化だけでなく、担当者の変更、ドキュメント不足、OSやミドルウェアのサポート終了など、時間の経過とともにさまざまな問題が生じます。運用・保守を適切に行わないことで、どのようなリスクが生じるのかを確認しておきましょう。

 

障害による業務停止や機会損失

運用・保守が不十分な場合に特に大きな問題となるのが、システム障害による業務への影響です。例えば、受発注システムが停止すれば注文処理ができなくなり、在庫管理システムが利用できなければ商品の在庫状況を正確に把握できなくなる可能性があります。販売管理、生産管理、会計などの基幹システムであれば、一つのシステム障害が複数の部門へ影響することも考えられます。さらに、顧客が利用するWebサービスやECサイトなどでは、システム停止中に注文や問い合わせを受け付けられず、売上機会の損失につながることもあります。こうしたリスクを抑えるために重要なのが、日頃の運用です。システムの稼働状況やリソース使用量、ログなどを継続的に確認していれば、「ストレージ容量が残り少なくなっている」「エラーの発生件数が増えている」といった障害の兆候を早期に把握できる場合があります。そして問題が見つかった際に、保守担当者が原因を調査し、必要な対策を講じます。すべての障害を事前に防ぐことは難しいものの、問題を早期に発見できる運用体制と、発生した問題へ迅速に対応できる保守体制を整えておくことが、業務停止のリスク低減につながります。

 

セキュリティリスクの増加

システムを長期間安全に利用するためには、セキュリティ面の継続的な管理も欠かせません。OSやミドルウェア、利用しているソフトウェアなどでは、導入後に新しい脆弱性が発見されることがあります。必要なアップデートやセキュリティ対策を行わずに古い環境を使い続けると、不正アクセスや情報漏えいなどのリスクが高まる可能性があります。また、システム自体だけでなく、アカウント管理にも注意が必要です。

 

例えば、退職した社員のアカウントが残っている、異動前のアクセス権限がそのままになっている、複数人で同じアカウントを共有しているといった状態は、適切な管理とはいえません。日常的な運用によってアカウントやアクセス状況を管理するとともに、必要に応じてシステム側の修正やアップデートを行うことで、セキュリティリスクを抑えていくことが重要です。特に古いシステムでは、使用しているOSやソフトウェアがすでにサポートを終了している場合もあります。「現在動いているから問題ない」と判断するのではなく、システムを構成している技術や製品のサポート状況も含め、継続して安全に利用できる環境なのかを確認する必要があります。

 

システムの属人化・ブラックボックス化

運用・保守を長期的に考えるうえで注意したいのが、システムの属人化やブラックボックス化です。

例えば、

 

「システムのことは社内のAさんしか分からない」

「開発した会社に任せきりで、自社には仕様が分かる人がいない」

「設計書はあるものの、何年も更新されていない」

「過去に何度も改修しており、現在の仕様と資料の内容が一致していない」

 

といった状態です。

 

このような状態でも、システムが正常に動いている間は大きな問題として認識されないことがあります。しかし、担当者が突然退職したり、開発会社が保守から撤退したりしたときに、問題が一気に表面化します。障害が発生しても原因を調査できる人がいない、新しい担当者がシステムの構成を理解するまでに時間がかかる、改修したくてもどこを変更すればよいか分からない、といった状況になりかねません。特に長年使用しているシステムでは、担当者の頭の中にしかない情報が増えやすいため注意が必要です。属人化を防ぐには、システム構成や運用手順、障害対応履歴などをできる範囲で記録し、特定の担当者だけに情報が集中しない状態を作ることが重要です。また、保守会社へすべてを任せている場合でも、自社側で「どの会社が何を担当しているのか」「障害時にはどこへ連絡するのか」「どのようなシステムやサービスを利用しているのか」といった基本的な情報は把握しておくとよいでしょう。

 

老朽化による保守コストの増加

システムは、長く使えば使うほど必ずコストが下がるとは限りません。古いシステムでは、使用しているプログラミング言語やフレームワーク、データベース、OSなどの技術が古くなり、対応できるエンジニアが少なくなることがあります。さらに、長年にわたって機能追加や改修を繰り返した結果、システムの構造が複雑になり、一つの変更が別の機能へ影響しやすくなる場合もあります。その結果、以前であれば簡単にできた改修に時間がかかったり、障害原因の調査に多くの工数が必要になったりして、保守にかかる負担が増えていくことがあります。また、古いOSやハードウェアを利用している場合には、故障した機器の交換部品を確保しにくくなったり、最新環境へそのまま移行できなかったりすることも考えられます。ただし、古いシステムだからといって、すぐにすべてを新しくする必要があるとは限りません。現在のシステムが業務に合っており、安定して利用できているのであれば、適切な保守を行いながら継続利用することも一つの選択肢です。重要なのは、問題が深刻になってから初めて対応を考えるのではなく、現在のシステムがあとどの程度利用できるのか、保守を継続するのか、部分的に改修するのか、将来的に再構築するのかを早めに検討しておくことです。運用・保守は、現在のシステムを正常に動かすためだけの業務ではありません。日々の状態を把握しながら将来的なリスクを発見し、必要な対策を講じることで、システムを安全かつ安定して利用し続けるための重要な役割を担っています。

 

 

５．AIを活用してシステム運用・保守を効率化する方法

 

近年は、システムの運用・保守にもAIを活用できる場面が増えています。システム運用では、ログや監視データの確認、問い合わせ対応など、日々多くの情報を扱います。また、障害が発生した際には、大量のログや過去の対応履歴などから原因を探さなければならないこともあります。こうした「大量の情報を確認する」「異常なデータを見つける」「必要な情報を探す」といった作業は、AIを活用することで効率化できる可能性があります。ただし、AIを導入すれば運用・保守をすべて自動化できるわけではありません。AIが得意な作業と人が判断すべき作業を整理し、適切に組み合わせることが重要です。

 

AIによる監視・異常検知

AIを活用できる分野の一つが、システムの監視や異常検知です。一般的なシステム監視では、「CPU使用率が一定の数値を超えたら通知する」「ディスクの空き容量が一定以下になったらアラートを出す」など、あらかじめ設定した条件に基づいて異常を検知します。一方、AIや機械学習を活用した異常検知では、過去の稼働データなどから通常時の傾向を分析し、普段とは異なる動きを検知する方法があります。

例えば、

 

・通常よりCPU使用率が高い状態が続いている
・特定の時間帯だけ処理速度が低下している
・普段とは異なる種類のエラーが増えている
・ネットワーク通信量に通常とは異なる変化がある

 

といった変化を検知し、運用担当者による確認につなげます。システムから出力されるログや監視データは膨大になることがあり、すべてを人が常時確認するのは現実的ではありません。AIを活用して確認すべき情報を絞り込めれば、担当者の負担を軽減できる可能性があります。ただし、AIが異常と判断したからといって、必ず障害が発生しているとは限りません。業務上の理由によって一時的にアクセスが増えているなど、正常な変化を異常として検知する場合もあります。そのため、AIによる異常検知は人に代わってすべてを判断するものではなく、「人が確認すべき変化を見つけるための支援」として活用することが大切です。

 

ログ解析・障害原因の特定支援

障害発生時の原因調査にもAIを活用できます。システム障害が発生すると、アプリケーション、サーバー、データベース、ネットワークなど、さまざまな場所にログが残ります。保守担当者は、それらのログを確認しながら「いつ」「どこで」「何が起きたのか」を調査し、障害の原因を切り分けていきます。しかし、大規模なシステムでは大量のログが出力されるため、必要な情報を探すだけでも時間がかかることがあります。そこでAIを活用し、大量のログから関連性の高い情報を抽出したり、エラーの内容を整理したり、過去に発生した類似事例を検索したりすることで、原因調査を支援できます。生成AIを活用する場合には、エラーメッセージやログの内容を整理し、「どのような原因が考えられるのか」「確認すべき項目は何か」といった候補を提示させる使い方も考えられます。これによって調査の手掛かりを得やすくなり、保守担当者が一から情報を探す負担を軽減できる可能性があります。ただし、AIが提示した原因や対応方法が必ず正しいとは限りません。特に企業ごとに個別開発された業務システムでは、一般的な情報だけでは判断できない独自の仕様や業務ルールが存在します。そのため、AIの回答をそのまま採用するのではなく、システムの構成や仕様を理解したエンジニアが内容を確認し、最終的な原因特定や対応方法を判断することが重要です。

 

障害対応・問い合わせ対応の効率化

AIは、障害発生後の対応や日常的な問い合わせ対応を支援する用途にも活用できます。例えば、過去の障害対応履歴やマニュアル、FAQなどをAIから検索できるようにしておけば、似た問題が発生した際に必要な情報へアクセスしやすくなります。「以前にも同じエラーが発生していないか」「そのときはどのような対応を行ったのか」といった情報を探す時間を短縮できれば、初動対応の効率化につながります。

また、利用者から寄せられる、

「ログイン方法が分からない」
「この機能はどのように操作するのか」
「エラーが表示された場合はどうすればよいか」

といった問い合わせに対して、社内マニュアルやFAQをもとにAIが回答候補を提示する方法もあります。

よくある問い合わせをAIで補助できれば、運用担当者は個別の調査や判断が必要な問い合わせに時間を使いやすくなります。さらに、あらかじめ安全性が確認された定型的な処理については、自動化ツールなどと組み合わせて、一次対応を自動化する方法もあります。ただし、障害対応ではシステムへの変更を伴うこともあります。誤った処理を自動実行すると、かえって影響範囲を広げてしまう可能性があるため注意が必要です。「情報収集や候補の提示まではAI」「システムへの変更や重要な判断は人」のように役割を分けるなど、影響度に応じた運用ルールを設けることが重要です。

 

AI導入時に押さえておきたいポイント

AIを運用・保守へ導入するときは、最初から広い範囲をAIに任せるのではなく、「現在どの業務に負担がかかっているのか」を整理することから始めましょう。

例えば、

 

・大量のアラート確認に時間がかかっている
・障害発生時のログ調査に時間がかかる
・同じような問い合わせが繰り返されている
・過去の障害対応履歴を探すのに時間がかかる

 

といった課題が明確になれば、AIを活用すべき場所も判断しやすくなります。また、AIへ入力する情報にも注意が必要です。システムのログや障害情報には、個人情報や顧客情報、社内システムの構成など、外部へ公開すべきではない情報が含まれている可能性があります。外部の生成AIサービスなどを利用する場合には、入力したデータがどのように扱われるのか、学習に利用されるのか、保存されるのかなどを確認し、自社のセキュリティルールに沿って利用する必要があります。

 

さらに、AI導入による効果も確認しましょう。「AIを導入した」という事実ではなく、アラート確認時間や障害調査時間、問い合わせ対応件数など、導入前に負担となっていた業務が実際に改善されているかを見ることが重要です。AIは運用・保守担当者を完全に置き換えるものではなく、大量の情報整理や定型的な作業をAIで支援し、担当者が原因分析や改善など、人にしかできない業務へ時間を使いやすくするための手段として考えるとよいでしょう。

 

 

６．インフラ基盤と運用・保守の関係

システムの安定稼働を考えるうえでは、アプリケーションだけでなく、それを動かしているインフラにも目を向ける必要があります。インフラとは、システムを動かすための土台となるIT環境のことです。代表的なものには、サーバー、ネットワーク、ストレージ、OSなどがあります。例えば、業務システムのプログラム自体に問題がなくても、サーバーに障害が発生したり、ネットワークに接続できなくなったりすれば、利用者はシステムを使用できません。そのため、システムの運用・保守では、アプリケーションとインフラの両方を意識して安定した環境を維持することが重要です。

 

サーバー・ネットワークの重要性

多くのシステムは、サーバーやネットワークなどのインフラ上で動作しています。サーバーにはアプリケーションやデータベースなどが配置され、利用者はネットワークを経由してシステムへアクセスします。そのため、サーバーに問題が発生すればシステムそのものが利用できなくなったり、ネットワークに問題が発生すれば、サーバーが正常でも利用者がシステムへ接続できなくなったりします。また、サーバーが停止するほどではなくても、CPUやメモリ、ストレージなどのリソースが不足すると、システムの動作が遅くなる場合があります。例えば、「最近システムの画面表示が遅くなった」という問題があったとしても、必ずしもアプリケーションのプログラムだけが原因とは限りません。アクセス数の増加、データ量の増加、ネットワークの混雑、サーバーのリソース不足など、インフラ側に原因がある可能性もあります。そのため、障害やパフォーマンス低下が発生した際には、アプリケーションとインフラの両方から原因を切り分ける必要があります。

 

オンプレミスとクラウドの違い

システムを動かすインフラには、大きく分けてオンプレミスとクラウドがあります。オンプレミスとは、自社内やデータセンターなどにサーバーやネットワーク機器を設置し、自社専用の環境として利用する形態です。自由度が高く、自社の要件に合わせて環境を構築しやすい一方で、ハードウェアの管理や交換、設備の維持なども考える必要があります。一方、クラウドでは、クラウド事業者が提供するサーバーやストレージなどのITリソースをインターネット経由で利用します。必要に応じてリソースを増減しやすく、物理サーバーを自社で保有・管理する負担を減らせることがメリットです。ただし、「クラウドを利用すれば運用・保守が不要になる」というわけではありません。利用するクラウドサービスによって事業者と利用企業の管理範囲は異なりますが、アカウントやアクセス権限の管理、システムの監視、データのバックアップ、アプリケーションの保守など、利用者側で対応しなければならない業務は残ります。また、クラウドサービス自体の仕様変更やメンテナンスなどへの対応が必要になる場合もあります。そのため、オンプレミスかクラウドかという違いだけでなく、「どこまでを自社で管理し、どこからをサービス提供者に任せるのか」を把握したうえで運用・保守体制を設計することが重要です。

 

インフラ障害を防ぐための対策

インフラのトラブルを完全になくすことは難しいため、「障害を起こさないこと」だけでなく、「障害につながる兆候を早く発見すること」や「障害が発生しても影響を小さくすること」が重要です。そのためには、サーバーやネットワークの状態を継続的に監視し、異常がないかを確認します。

例えば、

 

・CPUやメモリの使用率
・ストレージの空き容量
・ネットワークの通信状況
・サーバーやサービスの稼働状況
・エラーログ
・アクセス状況

 

などを監視します。

また、OSやミドルウェアなどのサポート期限を把握しておくことも重要です。サポートが終了した環境を使い続けると、新たに脆弱性が発見されても修正プログラムが提供されないなど、セキュリティ上のリスクにつながる可能性があります。一方で、業務システムの場合は「最新版が公開されたからすぐにアップデートする」という対応が必ずしも適切とは限りません。OSやミドルウェアを変更することで、既存システムが正常に動作しなくなる可能性があるためです。アップデートを行う際には、システムへの影響を確認し、必要に応じてテスト環境で動作を検証したうえで本番環境へ反映するなど、計画的に進める必要があります。

 

バックアップ・冗長化・災害対策

インフラの運用では、障害が発生した場合に備えることも重要です。その代表的な対策が「バックアップ」と「冗長化」です。バックアップは、データやシステムの情報を別の場所に保存し、データ消失などが発生した場合に復元できるようにする仕組みです。一方、冗長化は、サーバーやネットワークなどを複数用意し、一部に障害が発生しても別の環境へ切り替えることで、システムを継続して利用できるようにする考え方です。両者は目的が異なるため、「冗長化しているからバックアップは不要」「バックアップがあるからシステム停止への対策は十分」というわけではありません。

 

また、地震や火災などの災害も考慮する必要があります。例えば、本番環境とバックアップデータを同じ場所だけに保管している場合、その場所自体が被害を受けると両方を失う可能性があります。システムの重要度によっては、異なる拠点やクラウド環境などにバックアップを保管することも検討します。さらに、バックアップを取得しているだけではなく、実際に障害が起きたときにどの程度の時間で復旧できるのか、どの時点のデータまで戻せるのかをあらかじめ考えておくことも大切です。特に企業の基幹システムでは、「何時間停止しても業務上問題ないのか」「どの程度のデータ損失まで許容できるのか」によって、必要となる対策は変わります。すべてのシステムに最大限の冗長化や災害対策を行えばよいわけではありません。対策を強化するほど費用も増えるため、システムが停止した場合の業務への影響や重要度を整理し、自社に必要なレベルの対策を選ぶことが重要です。このように、システムの安定稼働はアプリケーションの保守だけで実現できるものではありません。アプリケーション、サーバー、ネットワーク、データなどを含めてシステム全体を捉え、適切な運用・保守体制を構築することが、長期的に安心してシステムを利用するためのポイントです。

 

 

７．システム運用・保守は内製と外注のどちらがよい？

システムの運用・保守体制を構築する際、「自社で対応するべきか、外部の会社へ委託するべきか」で迷う企業も多いでしょう。自社の社員が運用・保守を担当する「内製」と、システム会社などへ委託する「外注」には、それぞれメリット・デメリットがあります。どちらが優れていると一概に決められるものではなく、システムの重要度や社内の人員、必要となる技術、対応時間などによって適した方法は異なります。また、すべてを内製または外注するのではなく、一部を自社で担当し、専門的な対応を外部へ任せる方法もあります。自社に合った運用・保守体制を考えるために、それぞれの特徴を理解しておきましょう。

 

内製するメリット・デメリット

運用・保守を内製する大きなメリットは、自社の業務やシステムについて理解した担当者が対応できることです。業務システムの場合、単にシステムの仕組みだけを理解していればよいわけではありません。例えば、販売管理システムであれば受注から売上までの流れ、在庫管理システムであれば入出庫や棚卸しなど、自社独自の業務ルールがシステムへ反映されていることがあります。社内担当者であれば、こうした業務背景を理解したうえで対応しやすく、利用部門からの要望についても直接コミュニケーションを取りながら判断できます。また、障害対応やシステム改修を自社で経験することで、システムに関する知識やノウハウを社内へ蓄積できることもメリットです。

 

一方で、内製には人材面の課題があります。運用・保守には、アプリケーションだけでなく、データベース、サーバー、ネットワーク、セキュリティなど幅広い知識が必要になる場合があります。すべての領域に対応できる人材を自社だけで確保することは、企業規模によっては難しいでしょう。さらに、特定の社員だけがシステムを理解している状態になると、担当者の休職や異動、退職によって対応できる人がいなくなる「属人化」のリスクもあります。社内に担当者がいるから安心と考えるのではなく、複数人で情報を共有したり、手順やシステム構成をドキュメントとして残したりすることも重要です。

 

外注するメリット・デメリット

運用・保守を外注するメリットは、自社だけでは確保しにくい専門的な知識や技術を活用できることです。システム会社には、さまざまなシステムの開発や保守に携わってきたエンジニアが在籍している場合があります。障害が発生した際にも、過去の経験や技術的な知見を活用しながら原因を調査できることは、外注するメリットの一つです。また、社内で運用・保守のためのエンジニアを確保する必要がなくなるため、自社の社員が本来の業務へ集中しやすくなるという利点もあります。特に、システム担当者が少ない企業や、情報システム業務をほかの業務と兼任している企業では、専門的な部分を外部へ任せることで担当者の負担を軽減できる可能性があります。

 

一方、外注すればすべてを任せられるわけではありません。外部の保守会社は、自社の業務について最初からすべてを理解しているわけではないため、業務内容やシステムの利用方法、優先度などを共有する必要があります。例えば、同じシステム障害でも「数時間停止しても影響が小さい機能」と「数十分停止するだけで受発注業務に大きな影響が出る機能」では、対応の優先順位が異なります。こうした業務上の重要度は、自社側から適切に伝えなければ分かりません。そのため外注する場合も、保守会社へ完全に任せきりにするのではなく、社内側に窓口となる担当者を置き、情報共有や判断を行える体制を整えることが大切です。

 

内製と外注を組み合わせる方法

システム運用・保守は、「すべて内製」または「すべて外注」の二択ではありません。自社で対応しやすい業務は内製し、専門的な知識が必要な部分を外部へ委託する方法もあります。例えば、日常的な利用者からの問い合わせやアカウント管理は社内の情報システム担当者が行い、プログラムの不具合修正やデータベースの調査などは外部の保守会社へ依頼するといった役割分担です。また、日々のシステム利用状況や業務上の要望は自社で把握し、技術的な判断や改修について外部のエンジニアと相談しながら進める方法もあります。このような体制であれば、自社に業務知識を残しながら、必要な部分では外部の専門性を活用できます。重要なのは、内製と外注の境界を曖昧にしないことです。

障害が発生した際に、

 

「どこまでを社内で確認するのか」
「どの段階で保守会社へ連絡するのか」
「誰が対応の優先順位を判断するのか」

 

といった役割が決まっていないと、初動が遅れる可能性があります。

平常時から対応範囲や連絡方法を決めておくことで、内製と外注を組み合わせた体制でもスムーズに対応しやすくなります。

 

 

自社に合った体制を判断するポイント

内製と外注のどちらを選ぶかを判断するときは、費用だけで比較するのではなく、自社のシステムと社内体制を整理することが重要です。まず確認したいのが、システムが停止した場合の業務への影響です。基幹システムのように、停止すると受発注や生産、販売など主要な業務に影響するシステムでは、障害発生時に対応できる体制を確保しておく必要があります。次に、社内に必要な技術を持つ人材がいるかを確認します。現在対応できる社員がいたとしても、その人だけに知識が集中していないか、将来的にも継続して担当できるのかまで考えることが大切です。

さらに、

 

・どの程度の対応時間が必要なのか
・夜間や休日の対応が必要なのか
・システムの改修がどの程度発生するのか
・社内にどの程度ノウハウを残したいのか
・運用・保守へ割ける人員や予算はどの程度か

 

といった点も判断材料になります。

例えば、日常的な問い合わせは社内で十分対応できるものの、障害調査やプログラム改修まで対応できるエンジニアはいないのであれば、その部分だけ外部へ委託する方法も考えられます。大切なのは、「内製か外注か」を先に決めるのではなく、自社で対応できる範囲と、外部の専門家へ任せるべき範囲を整理することです。自社のリソースやシステムの重要度に応じて役割を分担することで、無理のない運用・保守体制を構築しやすくなります。

 

８．運用・保守を外注するときの会社選びのポイント

システムの運用・保守を外注する場合、費用だけで委託先を決めるのはおすすめできません。システムは企業によって使用している技術や構成、業務内容が異なります。また、同じ「システム保守」というサービスでも、対応範囲や対応時間、契約内容は会社によって異なります。特に長期間利用している業務システムや、開発した会社とは別の会社へ保守を依頼する場合には、「その会社が現在のシステムを理解し、継続して対応できるか」という視点が重要です。ここでは、運用・保守会社を選ぶ際に確認したいポイントを解説します。

 

対応可能なシステム・技術を確認する

まず確認したいのが、自社のシステムで使用している技術に対応できるかどうかです。システムは、プログラミング言語だけで構成されているわけではありません。

例えば、

・プログラミング言語
・フレームワーク
・データベース
・OS
・サーバー環境
・クラウドサービス
・外部システムやAPIとの連携

 

など、さまざまな技術を組み合わせて構築されています。そのため、「Javaに対応している」「PHPに対応している」といったプログラミング言語だけではなく、システム全体を見て対応可能か確認することが重要です。特に長年利用しているシステムでは、現在では使用する企業が減っている言語や古いバージョンのソフトウェアが残っている場合があります。古い技術だからといって直ちにシステムを再構築しなければならないわけではありませんが、対応できるエンジニアが限られる可能性があるため、保守会社を選ぶ際には確認が必要です。また、現在のシステムを維持するだけでなく、将来的なバージョンアップや環境移行について相談できるかも確認しておくとよいでしょう。

保守範囲・対応時間・連絡体制を確認する

「保守を依頼したから、システムに関することはすべて対応してもらえる」と考えるのは注意が必要です。保守契約に含まれる業務は、会社や契約内容によって異なります。

例えば、

 

・障害発生時の原因調査
・プログラムの不具合修正
・問い合わせ対応
・データ修正
・設定変更
・機能追加や改修
・サーバーやインフラへの対応

 

などのうち、どこまでが契約範囲なのかを事前に確認しましょう。

また、対応可能な時間も重要です。

平日の営業時間内のみ対応する契約もあれば、夜間・休日を含めた対応が可能なサービスもあります。必ずしも24時間365日の対応が必要とは限りません。例えば、平日の営業時間中だけ利用する社内システムと、顧客がいつでも利用するWebサービスでは、求められる対応体制が異なります。重要なのは、自社の業務に必要な対応レベルと契約内容が合っていることです。あわせて、障害が発生した際の連絡方法も確認しておきましょう。「誰に連絡するのか」「どの方法で連絡するのか」「緊急時はどのような流れで対応するのか」が明確になっていれば、実際のトラブル時にも動きやすくなります。

ドキュメントや引継ぎへの対応力を確認する

現在の開発会社とは別の会社へ保守を依頼する場合、特に重要になるのが「引継ぎへの対応力」です。理想的なのは、ソースコードや設計書、データベースの仕様書、サーバー構成図、運用手順書などが整理されている状態です。

しかし、長年利用しているシステムでは、

 

「設計書が残っていない」
「資料はあるが内容が古い」
「何度も改修しており、現在の仕様と一致していない」
「システムに詳しい担当者がすでに退職している」

といったケースも考えられます。

こうした場合、既存資料を受け取るだけでは保守を引き継げません。実際に動いているシステムやソースコード、データベースなどを調査し、「現在どのような仕組みになっているのか」を把握する必要があります。そのため、保守会社を選ぶ際には、資料が十分にそろっていることを前提とするのではなく、ドキュメントが不足している場合にどのような方法でシステムを調査し、保守可能な状態まで持っていくのかを確認するとよいでしょう。また、現在の保守会社から新しい会社へ変更するのであれば、契約終了前に可能な限り情報を受け取っておくことも重要です。保守会社を変更することが決まってから慌てて資料を探すのではなく、現在どのような資料や情報を保有しているのかを早めに確認しておくと、引継ぎを進めやすくなります。

 

将来的な改修・再構築まで相談できるか確認する

保守会社を選ぶ際には、「現在のシステムを維持できるか」だけでなく、将来的なことまで相談できるかという視点も重要です。

システムを長く利用していると、

 

「業務が変わり、現在の機能では対応しにくくなった」
「改修を繰り返してシステムが複雑になった」
「古い技術を使用しており、対応できる人材が減っている」
「OSやミドルウェアのサポート終了が近づいている」

 

といった課題が出てくることがあります。

このとき、現在のシステムを保守し続けることが最も適切とは限りません。一部を改修すれば十分なのか、インフラだけを変更するのか、段階的に新しいシステムへ移行するのか、システム全体を再構築するのかなど、複数の選択肢があります。反対に、「古いから」という理由だけで、まだ問題なく利用できるシステムをすぐに再構築する必要もありません。大切なのは、現在のシステムの状態や業務上の課題、今後の事業計画などを踏まえて判断することです。そのため、保守会社を選ぶ際には、障害が発生したときだけ対応する会社なのか、それとも日々の保守を通じてシステムの状態を把握し、必要に応じて改修や再構築についても相談できる会社なのかを確認するとよいでしょう。「今のシステムをできるだけ長く使う」「必要な部分だけ改善する」「将来的に再構築する」など、状況に応じた選択肢を一緒に検討できることも、長期的な保守パートナーを選ぶうえで重要なポイントです。

 

 

 

９．他社が開発したシステムでも保守は引き継げる？

「システムを開発した会社でなければ、そのシステムの保守はできない」と思われることがありますが、他社が開発したシステムでも、別のシステム会社へ保守を引き継げる場合があります。

例えば、

 

・開発会社が保守サービスを終了することになった
・現在の保守会社と連絡が取りにくい
・障害や改修への対応に時間がかかっている
・保守を担当していた社内のエンジニアが退職する
・長年付き合っていた開発会社が廃業する
・現在の保守体制を見直したい

 

といった理由から、保守会社の変更が必要になることがあります。

ただし、他社が開発したシステムを引き継ぐためには、現在のシステムがどのような構成・仕様になっているのかを新しい保守会社が把握しなければなりません。そのため、保守引継ぎでは単にソースコードや資料を渡すだけでなく、システムの調査や業務内容の確認など、保守を開始するための準備が重要になります。

他社開発システムの保守引継ぎとは

保守引継ぎとは、現在システムを担当している会社や社内担当者から、新しい保守会社へシステムに関する情報や対応業務を移し、継続して保守できる体制を構築することです。一般的には、既存の資料やソースコード、システム環境などを確認しながら、新しい保守会社がシステムの構成や仕様を把握していきます。

例えば、

 

・どのような機能があるのか
・どのような業務で利用されているのか
・どのプログラミング言語やデータベースを使用しているのか
・どのサーバーやクラウド環境で動作しているのか
・外部のシステムやサービスとどのように連携しているのか
・過去にどのような障害や改修があったのか

 

といった情報を確認します。

特に業務システムでは、プログラムだけを確認しても、なぜその機能が必要なのか分からないことがあります。例えば、一見すると不要に見える処理でも、特定の取引先との契約や社内独自の業務ルールに合わせて実装されている可能性があります。こうした背景を理解せずにシステムを変更すると、別の業務へ影響が出ることも考えられます。そのため、他社システムの保守を引き継ぐ際には、技術面だけでなく、システムがどのように業務で利用されているのかを把握することも重要です。

保守引継ぎに必要な情報・資料

保守引継ぎをスムーズに進めるためには、現在のシステムに関する情報を可能な範囲で整理しておきましょう。

代表的なものには、次のような情報があります。

 

・システムのソースコード
・設計書や仕様書
・データベースの設計情報
・サーバーやネットワークの構成情報
・利用しているOSやミドルウェアなどの情報
・外部システムやAPIとの連携情報
・アカウントや権限に関する情報
・運用手順書や操作マニュアル
・過去の障害・問い合わせ・改修履歴
・現在の保守契約や対応範囲に関する情報

 

ただし、すべての資料がそろっていなければ引継ぎができないというわけではありません。長年利用しているシステムでは、開発当時の資料が残っていなかったり、改修を繰り返したことで設計書と現在のシステムが一致していなかったりすることもあります。その場合でも、まずは「何が残っていて、何が不足しているのか」を整理することが重要です。また、現在の開発会社や保守会社と連絡が取れるのであれば、契約終了前に必要な情報を確認しておくと引継ぎを進めやすくなります。特に、ソースコードやシステムへのアクセスに必要な情報がどこにあるのか分からない状態になると、新しい会社が調査を開始するまでに時間がかかる可能性があります。保守会社の変更を検討し始めた段階で、現在自社がどのような情報を保有しているのかを確認しておくとよいでしょう。

ドキュメントがない場合の対応

保守引継ぎの相談で問題になりやすいのが、「システムに関するドキュメントがほとんど残っていない」というケースです。

特に長期間利用しているシステムでは、

「設計書を作成した担当者がすでに退職している」
「何度も改修しているが資料が更新されていない」
「開発会社へ任せきりで、自社には資料がほとんどない」

といった状況も考えられます。

ドキュメントが不足している場合には、実際に稼働しているシステムやソースコード、データベースなどを調査し、現在の状態を把握していく必要があります。例えば、ソースコードから処理内容を確認したり、データベースの構造やデータの関係を調査したり、実際の画面を操作しながら機能を整理したりします。さらに、システムを利用している担当者へのヒアリングも重要です。資料には残っていなくても、現場の担当者が、

「この画面は受注処理のときに使用している」
「月末にはこのデータを出力している」
「この処理だけは特定の取引先向けに必要」

といった業務上の情報を把握している場合があります。

技術的な調査と業務ヒアリングを組み合わせることで、資料だけでは分からない現在のシステムの使われ方を整理していきます。ただし、ドキュメントがないシステムは、資料が十分にそろっているシステムと比べて、調査や引継ぎに時間がかかる可能性があります。そのため、「資料がないから保守会社を変更できない」と最初から諦めるのではなく、まずは現在残っている情報でどこまで調査できるのか、保守会社へ相談することが大切です。

保守会社を変更するときの注意点

保守会社を変更するときは、現在の契約が終了してから新しい会社を探し始めるのではなく、できるだけ早い段階から準備することが重要です。新しい会社がシステムを理解するまでには、一定の期間が必要になる場合があります。特に規模が大きいシステムや、ドキュメントが不足しているシステムでは、ソースコードやデータベースの解析、業務ヒアリング、環境確認などに時間がかかります。現在の保守契約が終了する直前に引継ぎを始めると、新しい保守会社が十分にシステムを理解できないまま旧会社との契約が終了してしまう可能性があります。その状態で障害が発生すると、原因調査や復旧に時間がかかることも考えられます。そのため、可能であれば現在の保守会社と新しい保守会社の契約期間を一部重ね、質問や確認ができる期間を設けると引継ぎを進めやすくなります。

 

また、保守会社を変更する際には、契約内容についても確認が必要です。ソースコードや設計書などの成果物を自社が保有しているか、システムへアクセスするためのアカウントを引き継げるか、利用しているサービスの契約名義が誰になっているかなども確認しておきましょう。保守引継ぎは、単なる「会社の変更」ではありません。現在のシステムを新しい会社が理解し、問題が発生した際に対応できる状態を作ることが本来の目的です。そのため、価格や契約開始日だけで判断せず、どのような手順で引継ぎを進めるのか、保守開始までに何を確認するのかを新しい保守会社と相談しながら進めることが重要です。

 

１０．運用・保守体制を見直すべきタイミング

システムの運用・保守体制は、一度構築したらそのままでよいものではありません。システムを利用する期間が長くなるにつれて、業務内容や社内体制、使用している技術、外部環境なども変化していきます。そのため、現在大きな問題が発生していなくても、状況によっては運用・保守体制を見直した方がよい場合があります。特に次のような変化が見られる場合には、「まだシステムが動いているから大丈夫」と考えるのではなく、現在の体制で今後も安定して利用できるかを確認してみましょう。

 

システム障害や不具合が増えている

以前と比べてシステム障害や不具合が増えている場合は、運用・保守体制を見直すタイミングの一つです。

例えば、

 

・システムが頻繁に停止する
・画面表示や処理速度が以前より遅くなった
・同じエラーが繰り返し発生している
・データ連携が定期的に失敗する
・一度修正しても別の問題が発生する

といった状況が続いている場合、個々の障害へその都度対応するだけでは根本的な解決にならないことがあります。

システムの利用者やデータ量が増え、現在のサーバー環境では性能が不足している可能性もあれば、長年の改修によってプログラムが複雑化している可能性もあります。また、運用監視が十分でないため、問題が大きくなってから初めて気付いているケースも考えられます。障害のたびに応急処置を繰り返す状態になっているのであれば、一度システム全体の状態を確認し、原因や今後必要となる対策を整理することが重要です。その結果、監視方法を変更するだけで改善できることもあれば、一部のプログラム改修やインフラの増強が必要になることもあります。

 

保守会社との契約終了・担当者退職がある

現在システムを理解している人がいなくなることも、保守体制を見直す大きなきっかけです。

例えば、現在の開発会社から、

「今後は保守サービスを継続できない」
「使用している技術に対応できるエンジニアがいなくなった」

といった連絡を受けることがあります。

また、社内でシステムを管理している場合には、担当者の異動や退職によって、システムに詳しい人がいなくなる可能性もあります。このようなケースで注意したいのが、「実際に担当者がいなくなってから対応を考える」ことです。システムに詳しい人がいるうちであれば、仕様や過去の経緯、障害時の対応方法などを確認できます。しかし、担当者が退職した後では、「なぜこの仕様になっているのか」「この処理を変更するとどこへ影響するのか」といった情報を確認できなくなる可能性があります。保守会社から契約終了の連絡を受けた場合も同様です。契約終了までの期間を利用して資料やソースコード、アカウント情報などを整理し、新しい保守会社への引継ぎを進めることが重要です。「まだ数か月あるから大丈夫」と後回しにせず、保守を担当できる人がいるうちに情報を残すことが、スムーズな引継ぎにつながります。

古いシステムの維持が難しくなっている

システムを長期間利用していると、システムそのものには問題がなくても、使用している技術や周辺環境が古くなっていきます。

例えば、

 

・OSのサポートが終了している
・データベースやミドルウェアのバージョンが古い
・古いプログラミング言語や開発環境を使用している
・対応できるエンジニアが少なくなっている
・ハードウェアの交換部品を入手しにくくなっている

といった状況です。

こうしたシステムは「レガシーシステム」と呼ばれることもあります。古いシステムだからといって、直ちに利用できなくなるわけではありません。現在の業務に適しており、安定して動作しているのであれば、保守しながら継続利用することもできます。一方で、古い環境を使い続けることで、徐々に保守の選択肢が少なくなる可能性があります。例えば、障害が発生したときに対応できるエンジニアが見つからない、現在使用しているソフトウェアが新しいOSに対応していない、といった問題です。そのため、古いシステムでは「今動いているか」だけではなく、今後も保守できる状態なのかという視点で確認することが重要です。サポート期限や技術者の確保状況、現在のシステム構成などを把握し、問題が深刻になる前に対応方法を検討しておきましょう。

 

改修・再構築を検討している

システムの改修に以前より時間や費用がかかるようになった場合も、運用・保守体制を見直すタイミングです。長年利用しているシステムでは、その間に何度も機能追加や修正が行われていることがあります。改修を重ねた結果、プログラム同士の関係が複雑になり、「一つの機能を変更しただけで別の機能へ影響する」といった状態になることもあります。また、システムを導入した当時と現在では、企業の業務そのものが大きく変わっている場合があります。

例えば、

「現在の業務に合わないシステムを、社員がExcelなどで補いながら使っている」
「同じデータを複数のシステムへ入力している」
「必要なデータをシステムから取り出せず、毎回手作業で集計している」

といった状態です。

 

このような場合、既存システムの機能を追加することで解決できる可能性もありますが、改修を繰り返すよりシステム全体を見直した方がよいケースもあります。

 

ただし、「古い」「使いにくい」という理由だけで、すぐに全面的な再構築を決める必要はありません。

現在のシステムを調査したうえで、

 

・現在のシステムをそのまま保守する
・問題のある部分だけ改修する
・インフラや一部の機能を段階的に更新する
・新しいシステムへ全面的に再構築する

 

といった選択肢を比較することが重要です。

システム再構築には費用や期間が必要になるため、現在のシステムを維持するコストやリスクと比較しながら判断する必要があります。運用・保守を継続していると、システムの障害履歴や利用状況、改修内容などの情報が蓄積されていきます。こうした情報は、「現在のシステムを使い続けるべきか、それとも再構築すべきか」を判断するための材料にもなります。運用・保守は単に現在のシステムを維持するだけではなく、将来のシステムのあり方を考えるうえでも重要な役割を持っているのです。

 

 

１１．エイ・エヌ・エスのシステム保守の現場から

エイ・エヌ・エスでは、自社で開発したシステムの保守だけでなく、他社が開発したシステムの保守引継ぎにも対応しています。保守引継ぎのご相談では、「現在の保守会社が対応できなくなった」「システムを開発した会社との契約が終了する」「社内でシステムを把握していた担当者がいなくなる」といった事情を抱えているケースがあります。こうしたシステムを引き継ぐ際に重要なのは、単にソースコードを受け取ることではありません。現在のシステムがどのような仕組みで動いているのか、どのような業務で使われているのかを把握し、障害や改修の相談が発生した際に対応できる状態を作る必要があります。

 

エイ・エヌ・エスでは、保守を引き継ぐ際、現行システムのソースコードやデータベース、業務仕様などを確認し、システムの構成や処理内容を把握していきます。特に長年利用されているシステムでは、開発当時の設計書が残っていなかったり、その後の改修内容がドキュメントへ反映されていなかったりすることもあります。そのような場合でも、残っている資料だけで判断するのではなく、実際のシステムやソースコード、データベースなどを確認するとともに、必要に応じてお客様へのヒアリングを行いながら、現在の仕様や業務との関係を整理していきます。例えば、システム上では一見すると用途が分かりにくい処理でも、実際には日々の業務に欠かせない機能である可能性があります。反対に、以前は必要だったものの、現在の業務ではほとんど利用されていない機能が残っていることもあります。そのため、システムの技術的な構造だけを見るのではなく、「現在どのような業務で、どのように使われているシステムなのか」まで確認することを大切にしています。

 

また、古い技術で構築されたシステムだからといって、必ずしもすぐに新しいシステムへ置き換えなければならないわけではありません。エイ・エヌ・エスでは、15種類以上の開発言語と5種類以上のデータベースに対応しています。AccessやVB、COBOLなどの古い言語を使用したシステムについても、現在の状態を確認したうえで対応いたします。現在の業務に合っており、安定して利用できるのであれば、必要な保守を行いながら継続して利用するという選択肢もあります。一方で、保守を続ける中で、老朽化や複雑化によって維持する負担が大きくなっていることが分かる場合もあります。そのような場合には、現在のシステムを無理に使い続けるのではなく、必要に応じて改修や将来的なシステム再構築について検討することも重要です。

「今あるシステムを安定して使い続けること」と「将来を見据えて必要な改善を考えること」の両方が、システム保守では大切です。

保守会社の変更や担当者の退職などが決まってから慌てて対応するのではなく、現在のシステムについて分かる人がいるうちに、システムの状態や保守体制を確認しておくことをおすすめします。

 

１２．まとめ｜運用と保守の違いを理解し、安定したシステム運用につなげよう

 

運用と保守は、どちらもシステムを安定して利用し続けるために欠かせない業務ですが、その役割には違いがあります。運用は、システムの監視やバックアップ、アカウント管理などを通じて、日々安定してシステムを使える状態に保つことが中心です。

一方の保守は、障害発生時の原因調査や不具合修正、環境変化への対応、必要に応じた改修などを行い、システムを維持・改善していくことが中心となります。

また、安定したシステム運用を実現するためには、運用と保守だけでなく、サーバーやネットワークなどのインフラ、セキュリティ、バックアップなども含めて考える必要があります。

近年ではAIを活用し、異常検知やログ解析、問い合わせ対応などを効率化する方法も登場しています。ただし、AIにすべての判断を任せるのではなく、人による確認や判断と組み合わせながら活用することが重要です。

そして、運用・保守を自社だけで行うことが難しい場合には、外部のシステム会社へ委託することも選択肢となります。

特に、

 

「現在の保守会社との契約が終了する」
「システムに詳しい担当者が退職する」
「他社が開発したシステムの保守先を探している」
「設計書や仕様書が十分に残っていない」
「古いシステムを今後も使い続けられるか不安がある」

といった状況では、問題が発生する前に現在の保守体制を確認しておくことが大切です。

 

エイ・エヌ・エスでは、既存の開発会社が保守を継続できなくなったシステムや、他社が開発したシステムについて、調査・解析を行い、新たな保守体制を構築する「システム保守引継ぎサービス」を提供しています。ドキュメントが不足している場合でも、ソースコードやデータベース、現在のシステム環境などを確認し、お客様へのヒアリングを行いながら、保守に必要な情報を整理していきます。「今の保守会社から変更できるのか分からない」「資料がほとんど残っていない」「古いシステムなので対応してもらえるか不安」といった段階でも、まずは現在の状況をご相談ください。システムが正常に動いているうちに保守体制を見直しておくことが、将来的な業務停止やシステムのブラックボックス化を防ぐことにもつながります。

システムの運用・保守や保守引継ぎでお悩みの際は、エイ・エヌ・エスへお気軽にお問い合わせください。

 

実際のシステム保守引継ぎの取り組みについては、株式会社シルバーライフ様のシステム保守引継ぎ事例をご覧ください。