運用保守とは？運用と保守の違い・範囲と、外注する前に決めておく線引き

社内の業務システムができあがり、開発会社から「このあとの運用保守はどうされますか」と聞かれて、どこまでを頼めばよいのか迷った、という声をよく聞きます。見積もりには「運用保守費」と1行で書かれているものの、その中に何が入っていて、何が入っていないのかは、発注する側からは見えにくいものです。

運用と保守は、ひとまとめに呼ばれることが多い一方で、目的も、やる人も、お金のかかり方も違う仕事です。この違いを分けないまま契約すると、「それは保守の範囲外です」「それは運用でやってください」と、困ったときに話が止まってしまいます。

運用はシステムを毎日動かし続ける仕事、保守はシステムそのものを直して使える状態に保つ仕事で、外注する前に、この2つと改修の境目を自社のシステムで線引きしておくことが大切です。この記事では、運用と保守の違い、保守の種類、改修との境目、自社と外注の分け方を、発注する側の目線で順に説明します。

運用保守とは｜システムを使い続けるための2つの仕事

運用保守とは、できあがったシステムを止めずに使い続けるための仕事をまとめた呼び方です。開発が「作る」仕事だとすれば、運用保守は「使い続ける」仕事で、システムを使っている限り終わりがありません。

「保守運用」と書かれることもありますが、指している中身は同じです。ただ、一つの言葉にまとめられているぶん、運用と保守のどちらを指しているのかが、話す人によってずれやすい言葉でもあります。

運用と保守の違い

運用と保守の一番の違いは、システムの中身に手を入れるかどうかです。運用は、決めた手順に沿ってシステムを動かし、様子を見て、使う人を支える仕事で、システムそのものは変えません。保守は、不具合を直したり、部品や環境の変化に合わせて手を入れたりして、システムそのものを使える状態に保つ仕事です。

運用は手順書があれば社内の人でも回せることが多い一方、保守はシステムの中身が分かる人でなければできません。この差が、あとで述べる「何を自社に残し、何を外に頼むか」を決める手がかりになります。

保守の4つの種類

保守は、何のために直すかで4つに分けられます。日本産業規格の JIS X 0161（ソフトウェア技術－ソフトウェアライフサイクルプロセス－保守）では、次のように分類しています。

• 是正保守: 引き渡し後に見つかった問題を訂正するために行う、受け身の修正
• 予防保守: 引き渡し後のソフトウェアの潜在的な障害が、表に出る前に見つけて是正するための修正
• 適応保守: 変化した、または変化している環境で、ソフトウェアを使えるように保ち続けるための修正
• 完全化保守: 引き渡し後のソフトウェアの性能や保守性を改善するための修正

出典: JIS X 0161:2008 ソフトウェア技術－ソフトウェアライフサイクルプロセス－保守（日本規格協会）の分類による。

発注する側が「保守」と聞いて思い浮かべるのは、壊れたときに直す是正保守であることが多いものです。ところが実際には、OSやサーバーの部品の更新、使っている外部サービスの仕様変更に合わせる適応保守が、時間とともに増えていきます。契約の「保守」がこの4つのどこまでを含むのかを確かめておくと、あとで食い違いが起きにくくなります。

運用保守に入らないもの｜改修・追加開発との境目

運用保守の話でいちばん揉めやすいのが、改修や追加開発との境目です。画面に項目を一つ足したい、帳票の形を変えたい、といった依頼は、発注する側には「ちょっとした直し」に見えても、多くの契約では保守ではなく改修として別に見積もられます。

目安は、「今あるものを、今のとおり使えるように保つ」のが保守で、「今にない働きを足す、変える」のが改修だと考えると分けやすくなります。前の節の完全化保守は、この二つのあいだに当たるため、どこまでを保守の月額に含めるのかを、契約の前に例を挙げて決めておくのが確実です。

• 運用: 決まった手順でシステムを動かす（中身は変えない）
• 保守: 今の働きを保つために直す（不具合・環境の変化への対応）
• 改修・追加開発: 今にない働きを足す、変える（別に見積もることが多い）

線引きが曖昧なまま外注すると起きること

運用と保守と改修の線引きをしないまま「運用保守一式」で頼むと、困ったときに次のようなことが起きやすくなります。どれも、誰かが手を抜いたというより、最初に範囲を言葉にしていなかったことから起きる食い違いです。

一つ目は、障害が起きたときに、どこまでを誰が調べるのかが決まっていないことです。監視で異常を見つけた運用の担当と、原因を直す保守の担当が別の会社だと、互いに相手の範囲だと考えて、調べ始めるまでに時間がかかります。

二つ目は、月額の保守費を払っているのに、頼みたい直しのたびに別の見積もりが出てくることです。前の節で書いた、保守と改修の境目を決めていなかった場合に起きやすく、見積もりの根拠が分からないという不満につながります。

三つ目は、中身が一社の担当者の頭の中にしか無くなっていくことです。運用保守を長く同じ会社に任せ、変更の記録や手順書を受け取らないままにしておくと、別の会社に頼み替えたいときに、誰も中身が分からない状態になります。この状態から抜け出す順番は「システム保守の移管とブラックボックスからの脱却｜ベンダーロックインを外す順番と進め方」で詳しく書いています。

自社と外注の分け方｜責任の分け方の表

運用保守のすべてを外に頼む必要はなく、すべてを社内で抱える必要もありません。仕事ごとに、自社でやるのか、外に頼むのか、決めるのは誰かを表にしておくと、契約の範囲と社内の役割が同時に決まります。

表の右の「決める人」が空いたままだと、外注しても判断が止まります。社内に詳しい人がいなくても、窓口になる担当と、お金のかかる判断をする人だけは自社で決めておくことが大切です。

社内の手順を残すときは、担当が替わっても回るように、何を見て判断しているかまで書いておきます。書き方は「業務引継書テンプレート｜AIに聞き取らせて作る、後任が困らない書き方」が参考になります。障害のあとに同じことを起こさないための記録は「再発防止策の書き方と例文｜報告書の項目と、「注意します」で終わらせない記録の残し方」にまとめています。

外注先を決める前に確かめること

運用保守を頼む会社を選ぶ前に、自社の側で確かめておくと話が早く進むことが5つあります。どれも、見積もりを比べるより先に済ませておきたいことです。

1. 運用・保守・改修のうち、どれを頼むのかを表にしたか

2. ソースコードの最新版と、今の中身に合った資料が自社の手元にあるか

3. ドメイン・サーバー・クラウドの名義と管理者の権限が自社にあるか

4. 障害のときに、何時間以内に誰へ連絡が来るのかを決めたか

5. 契約が終わるときに、何を渡してもらえるのかが契約書に書かれているか

2と3は、あとで頼み替えるときにいちばん効いてきます。今の会社とまだ付き合いのあるうちに、最新のソースコードと資料、管理者の権限を受け取っておくと、運用保守の相手を替える自由が残ります。契約書に書く項目は、Webサイト向けの内容ですが「【雛形配布】Webサイトの保守契約書テンプレート｜揉めやすい条項と書き方」も参考になります。

想定の例｜受発注のシステムで、運用と保守の分け目を引き直す

ここからは、実際の案件ではなく、よくある場面をもとにした想定の例です。社内で受発注を管理するシステムを数年前に作り、作った会社に「運用保守一式」で月額を払っている会社を考えます。

困りごとは、取引先が増えたので項目を足したいと頼むと毎回別の見積もりが来ること、夜間の処理が止まったときに誰が気づくのか決まっていなかったことの2つでした。そこで、前の節の表を自社で埋めてみると、月額で頼んでいたのは不具合の直しだけで、監視も項目の追加も最初から範囲に入っていなかったことが分かりました。

この会社は、利用者の登録と問い合わせの一次受付を社内に残し、夜間の処理の監視を保守の範囲に足す相談をし、項目の追加は年に何回かまとめて改修として頼む形に分け直しました。あわせて、最新のソースコードと管理者の権限を受け取り、将来の頼み替えにも備えました。

作った会社と別の会社に頼むとき

運用保守は、作った会社に頼むのが自然に見えますが、作った会社が保守をやめる、連絡が取れなくなる、費用や対応に納得がいかない、といった理由で、別の会社に頼むこともあります。その場合、新しい会社はまず中身を調べるところから始めるため、資料が少ないほど、引き受ける前の調べに時間がかかります。

作った人がいない、保守を断られたという場面は「他社が作ったシステムの引き継ぎ｜作った人がいない・保守を断られたときの進め方」で、開発会社と連絡が取れなくなった場面は「開発会社・制作会社と連絡が取れないときに最初の1週間でやること｜倒産・廃業でもサイトとシステムを止めない」で詳しく書いています。Webサイトの保守費用の内訳を知りたい場合は「ホームページの保守費用相場はいくら？月額に含まれる作業と料金を抑えるポイント」をご覧ください。

当社の保守の進め方

デイワンの引き継ぎ・立て直しでは、他社が作ったシステムの保守を、立て直しを伴わない保守だけでもお引き受けしています。残っているソースコードをAIで解析して仕様を文書に書き起こし、中身が分かる状態に戻したうえで、保守と改修を引き継ぎます。

あわせて、ドメイン・サーバー・ソースコードの権利と名義を確かめ、特定の会社に頼らずに済むかをご報告します。なお、前の開発会社が作ったコードの保証はお受けしていません。運用と保守の線引きを決めかねている段階でも、前の節の表を分かる所だけ埋めてお持ちいただければ、話が早く進みます。

あわせて読みたい：要件定義とは？、サイバー攻撃とは？

運用保守の範囲の決め方や、作った会社以外への保守の頼み替えは、引き継ぎ・立て直しのページからご相談ください。

まとめ｜運用保守は、頼む前に線を引く

運用保守は、システムを使い続けるための仕事をまとめた呼び方で、中身に手を入れない運用と、中身を直して使える状態に保つ保守に分かれます。保守はさらに是正・予防・適応・完全化の4つに分かれ、今にない働きを足す改修とは別に考えるのが一般的です。

外注する前に、運用・保守・改修のどれを誰がやり、誰が決めるのかを表にし、ソースコードと資料、名義と権限を自社の手元に置いておくことが大切です。そうしておけば、困ったときに話が止まらず、相手を替える自由も残ります。