保守・運用 ほしゅ・うんよう
システム運用メンテナンス障害対応バグ修正SLAライフサイクル
保守・運用について教えて
簡単に言うとこんな感じ!
システムって、作って終わりじゃないんだよ!「運用」は毎日ちゃんと動かし続ける仕事、「保守」はトラブルを直したり壊れないようにメンテする仕事だよ。車で言うと「運転」と「車検・修理」みたいな関係ってこと!
保守・運用とは
システムの開発(リリース)後に行われる継続的な活動を総称して「保守・運用」と呼びます。どんなに完璧に作られたシステムも、世に出た後は「動かし続ける」「問題を直す」「時代に合わせて変えていく」という作業が必要です。ITプロジェクトのコストや工数の大半は、実はリリース後のこのフェーズに集中します。
「運用」 とは、システムを日々安定して稼働させるための活動です。サーバーの監視、ユーザーからの問い合わせ対応、バックアップの取得、定期的なパッチ(修正プログラム)の適用などが含まれます。一方 「保守」 は、バグ(不具合)の修正、機能の改善・追加、老朽化したソフトウェアの更新(マイグレーション)など、システムそのものに手を加える活動です。
ビジネスパーソンがシステムを発注する際、「作る費用(初期費用)」だけに目が行きがちですが、リリース後の保守・運用コストはしばしば初期費用の数倍に上ることがあります。発注時には必ずランニングコストとして見込んでおくことが重要です。
保守と運用の違い
| 項目 | 運用(Operations) | 保守(Maintenance) |
|---|---|---|
| 目的 | システムを安定して動かし続ける | システムの問題を直し・改善する |
| 頻度 | 毎日・常時 | 必要に応じて(定期 or 臨時) |
| 主な作業 | 監視、バックアップ、問い合わせ対応 | バグ修正、機能改善、バージョンアップ |
| 車で言うと | 「毎日運転する」 | 「車検・修理・カスタム」 |
| コスト性質 | 固定的(月額・年額) | 変動的(案件ごと) |
保守の4分類(覚え方:「是正・適応・完全・予防」)
ソフトウェア工学では保守を4種類に分類しています。語呂合わせで 「ぜてかんよ(是適完予)」 と覚えると便利です!
| 分類 | 英語 | 内容 | 例 |
|---|---|---|---|
| 是正保守 | Corrective | バグ・障害の修正 | 計算ミスのある処理を直す |
| 適応保守 | Adaptive | 環境変化への対応 | OSやブラウザの新版に対応 |
| 完全化保守 | Perfective | 機能追加・性能改善 | 新しい検索機能を追加する |
| 予防保守 | Preventive | 将来の問題を未然に防ぐ | 読みにくいコードを整理する |
運用の主な業務一覧
- 監視(モニタリング) — サーバーの負荷・エラーを24時間チェック
- インシデント対応 — 障害発生時の原因調査・復旧作業
- バックアップ・リストア — データの定期保存と復元手順の確認
- アカウント管理 — ユーザーの追加・削除・権限変更
- パッチ適用 — セキュリティ修正プログラムの適用
- ドキュメント更新 — 手順書・構成図の最新化
歴史と背景
- 1960〜70年代 — ソフトウェアが大型コンピュータで動き始め、「納品後も手を加え続ける必要がある」ことが認識され始める
- 1980年 — IEEEがソフトウェア保守の標準定義を整備。保守が開発と同等に重要な工程として位置づけられる
- 1990年代 — インターネットの普及でシステムが24時間365日稼働することが当たり前になり、運用の重要性が急上昇
- 2000年代 — ITIL(ITサービスマネジメントのベストプラクティス集) が普及し、運用を体系的に管理する考え方が広まる
- 2010年代 — クラウドの台頭で「インフラの運用」をクラウド事業者に任せられるようになり、開発チームが運用も担う DevOps の考え方が登場
- 2020年代 — SRE(サイト信頼性エンジニアリング) などの手法が注目され、自動化・可観測性(オブザーバビリティ)による運用の高度化が進む
システムライフサイクルにおける位置づけ
システム開発から廃棄までの流れの中で、保守・運用がどこに位置するかを整理します。
発注者が知っておくべき「保守・運用の費用感」
システムのTCO(Total Cost of Ownership:総所有コスト)を考えると、初期開発費はほんの一部に過ぎません。
【10年間のTCO例(概算)】
初期開発費: 1,000万円 ──── ここだけ見て発注しがち
-------------------------------------------------
年間運用費: 200万円/年 × 10年 = 2,000万円
保守・改修費: 100万円/年 × 10年 = 1,000万円
インフラ費: 120万円/年 × 10年 = 1,200万円
-------------------------------------------------
10年間のTCO合計: 5,200万円(初期費用の5倍以上!)
発注・契約時のポイント
保守・運用を外部ベンダーに委託する場合、契約内容に以下が含まれているか必ず確認しましょう。
| 確認項目 | チェックポイント |
|---|---|
| SLA(サービスレベル合意) | 稼働率・障害対応時間の目標値が明記されているか |
| 対応時間 | 平日のみか、24時間365日対応か |
| 対応範囲 | バグ修正のみか、機能追加も含むか |
| エスカレーション先 | 重大障害時の連絡先・体制が決まっているか |
| ドキュメント整備 | 手順書・構成図の更新義務があるか |
| 移行・引き継ぎ | 別ベンダーへの切り替え時のサポートはあるか |
関連する規格・RFC
| 規格番号 | 内容 |
|---|---|
| ISO/IEC 14764 | ソフトウェア保守の国際標準。保守の4分類(是正・適応・完全化・予防)を定義 |
| ISO/IEC 20000 | ITサービスマネジメントの国際標準(ITILのベースとなった規格) |
関連用語
- SLA(サービスレベル合意) — 運用品質の目標値をベンダーと取り決める契約上の合意
- インシデント管理 — 障害発生時に迅速に復旧させるための管理プロセス
- DevOps — 開発(Dev)と運用(Ops)を一体化して高速にシステムを改善する考え方
- SRE(サイト信頼性エンジニアリング) — Googleが提唱した、エンジニアリングで運用を自動化・効率化するアプローチ
- TCO(総所有コスト) — 導入から廃棄まで含めた全コストを把握する概念
- バグ — ソフトウェアの不具合・誤動作の原因となるプログラムの誤り
- リリース — 開発したシステムや機能を本番環境に展開・公開すること
- ITIL — ITサービスマネジメントのベストプラクティスをまとめたフレームワーク