
この記事の要点
- 運用はシステムを止めずに動かし続けるための日々の作業で、保守は不具合の修正や改修など、システムそのものに手を入れる作業です
- どちらも、会社や契約によって言葉の範囲が違うため、作業の一覧を作って「誰が、どこまで」を決めておくことが大切です
- 外部に頼むときは、対応する作業と時間帯、連絡の窓口、費用のかかり方、記録の残し方を、契約や取り決めに書いておきます
システムの「運用」とは、システムを止めずに動かし続けるための日々の作業で、「保守」とは、不具合の修正や改修など、システムそのものに手を入れる作業です。運用は「いまの状態を保つ仕事」、保守は「システムを直したり変えたりする仕事」と考えると分かりやすいでしょう。
ただし、言葉の範囲は会社や契約によって違います。「保守をお願いしているから、全部見てもらえると思っていた」という食い違いを防ぐには、言葉に頼らず、作業の一覧で「誰が、どこまで」を決めておくことが大切です。
運用とは
運用とは、システムを決めたとおりに動かし続けるための日々の作業です。システムに手を入れるのではなく、動いている状態を見守り、決まった手順で作業します。
運用に含まれる作業の例です。
- システムが動いているかの監視と、異常の通知を受けたときの一次の対応
- バックアップが取れているかの確認
- 利用者の登録・削除や、権限の変更
- 決まった時期の処理(月末の締めの処理など)の実行と確認
- 利用者からの問い合わせへの対応(ヘルプデスク)
- 証明書やドメインなど、期限のあるものの更新の管理
運用の作業は、手順書(ランブック)にまとめておくと、担当が替わっても同じように進められます。
保守とは
保守とは、システムそのものに手を入れて、直したり変えたりする作業です。プログラムや設定を変えるため、技術の知識が必要になります。
保守に含まれる作業の例です。
- 不具合の原因を調べて直す
- OS・プログラム言語・部品の版上げと、セキュリティの修正を当てる
- 法令や制度の変更に合わせた改修
- 業務の変化に合わせた小さな機能の追加や変更
- 動きが遅くなったときの原因の調査と改善
保守の中でも、不具合を直す作業と、機能を足す作業は分けて考えることが多いです。機能の追加は、範囲によっては保守ではなく、新しい開発として別に見積もることがあります。
違いを表で整理する
運用と保守の違いを、次の表のように整理できます。
| 比べる点 | 運用 | 保守 |
|---|---|---|
| 目的 | いまの状態を保ち、止めずに動かす | 直す・変える・新しくする |
| システムへの手の入れ方 | 基本は手を入れず、決めた手順で操作する | プログラムや設定を変える |
| 主な作業 | 監視、バックアップの確認、利用者の管理、問い合わせ対応 | 不具合の修正、版上げ、改修 |
| 必要な知識 | 手順と業務の理解 | 技術の知識と、システムの中身の理解 |
| 起きる時期 | 毎日・毎月など、決まった周期 | 不具合や変更の必要が生じたとき、計画した時期 |
まとめて保守運用と呼ぶことも多く、1つの契約で両方を頼む場合もあります。その場合も、中身を作業ごとに分けて書いておくと、範囲の食い違いを防げます。
社内と外部の分担の決め方
社内と外部の分担は、作業の一覧を作り、作業ごとに「誰がするか」を決めていきます。いきなり「保守は外部、運用は社内」と大きく分けるより、作業ごとに決めるほうが漏れが出にくくなります。
決めるときの目安は、次のとおりです。
- 業務の判断が要る作業は社内:利用者の登録の承認、業務の締めの処理の確認など
- 技術の知識が要る作業は外部(または社内の技術の担当):不具合の修正、版上げ、障害の原因の調査など
- 夜間や休日の対応:止まると困る時間帯があるなら、誰が、どの時間帯に対応するかを決める
- 作ったときの会社:システムを作った会社が保守を受けるか、別の会社に頼むかで、引き継ぎの準備が変わる
分担を表にするときは、作業ごとに「実行する人」「承認する人」「相談を受ける人」「結果を知らせる人」を分けて書くRACIという書き方も使えます。
外部に頼むときに書いておくこと
外部に頼むときは、対応する作業と時間帯、連絡の窓口、費用のかかり方、記録の残し方を、契約や取り決めに書いておきます。
- 対応する作業の一覧:運用・保守のうち、どの作業を頼むか。頼まない作業も書く
- 対応する時間帯:平日の日中だけか、夜間や休日も含むか
- 連絡の窓口と方法:誰から誰へ、どの手段で連絡するか。急ぎのときの連絡先
- 対応までの時間の目安:連絡を受けてから、どのくらいで対応を始めるか
- 費用のかかり方:毎月決まった額か、作業の時間に応じるか。範囲を超えた作業の扱い
- 記録と報告:対応した内容をどこに残し、どのくらいの周期で報告するか
対応の水準を数字で決める考え方はSLA(サービスレベル合意)の決め方、契約の条項で決めておくことはシステムの保守契約で決めておくことで詳しく説明しています。
社内に残しておくもの
外部に頼む範囲が広くても、社内には、システムの全体を把握するための情報と、判断する役割を残しておきます。すべてを外部に任せると、頼む先を替えたいときや、頼む先と連絡が取れなくなったときに、何も分からなくなるおそれがあるためです。
社内に残しておきたいものの例です。
- システムの一覧(何が、どこで、誰の管理で動いているか)
- 契約と、ドメイン・クラウド・ライセンスなどのアカウントの名義と管理の担当
- 設計書、手順書、障害や変更の記録の置き場所
- 運用・保守の作業の一覧と、社内と外部の分担の表
- 変更や追加を頼むかどうかを判断する人
アカウントの名義は、外部の会社ではなく自社にしておくのが基本です。外部の担当が作業に使うアカウントは、担当ごとに分けて発行し、作業が終わったら止められるようにしておきます。
よくある食い違い
保守と運用で起きやすい食い違いには、次のようなものがあります。
- 保守を頼んでいるつもりが、契約では「不具合の修正」だけで、版上げは含まれていなかった
- 夜間に止まったが、対応の時間帯が平日の日中だけだった
- 小さな変更のつもりで頼んだら、別の見積もりになった
- システムを作った会社が替わり、システムの中身を知る人がいなくなった
どれも、作業の一覧と範囲を前もって書いておけば防ぎやすいものです。システムの中身を知る人がいなくなる心配があるときは、設計書や手順書をそろえておくことが助けになります。開発会社を替えるときの準備は開発会社を替えるときの引き継ぎをご覧ください。
当社のご支援
当社のWebシステム開発では、作ったシステムを公開した後の運用と改善まで続けて受け持ちます。いま使っているシステムを使い続けながら、運用と改善を任せたい場合はAIインテグレーションでもお受けしており、社内で運用を続けられるようにする内製化の支援も行います。頼む範囲の整理からご一緒したい場合は、お問い合わせからご相談ください。
- 保守
- 運用
- 外部委託
- 入門
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。