システムが納品されたあと、見積書に「保守運用費 月額◯万円」とだけ書かれていて、これで何をしてもらえるのかが分からない。そんな状態で契約の判断を迫られている方は多いと思います。
運用と保守は、名前が並んで使われるので同じもののように見えますが、中身は別の仕事です。そして委託しても、自社に必ず残る作業があります。ここを分けずに「保守運用は全部お願いします」と決めてしまうと、稼働してから「それは範囲外です」と言われるか、逆に自社で誰も見ていない領域が生まれます。この記事では、システム開発の運用と保守の違いと、どこまでを委託してどこからを自社で持つのかの線引きを整理します。
この記事のポイント
- 運用は動かし続ける仕事、保守は直して変化に合わせる仕事
- 保守は開発会社、運用は別の会社という分け方もある
- 委託しても権限の承認と業務の正しさの判断は自社に残る
- 稼働時間や復旧の目標は納品後ではなく要件定義で決める
目次
システム開発の運用保守とは何をする仕事か
まず言葉を分けます。ここが混ざったままだと、見積書の金額が何に対する対価なのかを判断できません。
運用は動かし続ける仕事、保守は直す仕事
運用は、システムを止めずに動かし続けるための日々の作業です。動いているかを見張る、バックアップを取る、新しく入社した人のアカウントを作る、月次の締め処理を回す。何も起きていなくても毎日発生する種類の仕事だと考えてください。
保守は、おかしくなったものを直したり、まわりの変化に合わせて手を入れたりする仕事です。エラーが出たときの原因調査と修正、OSやライブラリの更新への対応、法改正で計算式が変わったときの修正などが入ります。こちらは何かあったときに発生します。
| 観点 | 運用 | 保守 |
|---|---|---|
| 目的 | 止めずに動かし続ける | 不具合を直し、変化に合わせる |
| 主な作業 | 監視、バックアップ、アカウント発行、定期処理、問い合わせの一次受け | 障害の原因調査と修正、更新への追随、法改正対応、小さな改修 |
| 発生の仕方 | 毎日決まって発生する | 何かあったときに発生する |
| 費用の出方 | 作業量が読めるので月額にしやすい | 発生量が読めないので上限や時間枠で決めることが多い |
この違いが分かると、見積書の読み方が変わります。月額に含まれているのが監視だけなのか、それとも月に何時間かの改修まで含むのか。同じ「保守運用費」という名前でも、中身は会社によってかなり違います。
頼む相手が別の会社になることがある
保守は、基本的にそのシステムを作った開発会社に頼むのが自然です。中身の構造を知っている人が直すのがいちばん早く、他社が引き取ると解析からになるためです。
一方で運用は、必ずしも開発会社である必要がありません。24時間の監視や、社内からの問い合わせを受けるヘルプデスクのような仕事は、それを専門にしている会社のほうが体制も価格も整っていることがあります。実際、開発会社に運用まで頼むと「夜間は対応できません」と言われる場合があります。
分けるかどうかの判断は、規模と時間帯で考えると整理しやすくなります。利用者が社内の数十人で、平日の日中しか使わないシステムなら、開発会社に運用まで含めて頼んだほうが窓口が1つで済み、結果的に安く付きます。逆に、24時間動かす必要がある、あるいは社外の顧客が触るシステムなら、監視や一次受けを専門の会社に出す価値が出てきます。人数が少ない会社ほど、窓口の数を増やさないことのほうが効いてきます。
ただし分けるなら、必ず決めておくことがあります。障害が起きたとき、それが運用側の対応で終わる話なのか、保守側が直すべき不具合なのかの切り分けを誰がやるのかです。ここを決めずに2社に分けると、双方が「うちの範囲ではない」と言い合う時間が生まれます。障害の一次受けはどちらかに寄せ、切り分けの結果をもう一方へ渡す経路まで先に決めておいてください。
委託しても自社に残る作業がある
「全部お任せ」にできると考えていると、稼働してから慌てます。委託先が引き受けられるのは、あくまで動きに関することです。業務として正しいかどうかは、外からは判断できません。
私の感覚では、次のあたりは何を委託しても自社に残ります。
- 誰にどの権限を与えるかの承認（人事異動のたびに発生します）
- マスタや設定の中身が業務として正しいかの確認
- 業務ルールが変わったときに、システムをどう変えるかの判断
- 社内から上がってくる「使い方が分からない」への一次対応
- 委託先への依頼内容の決定と、費用の承認
この作業量は、意外と無視できません。稼働直後は問い合わせが集中するので、最初の1〜2か月は担当者の時間がかなり取られます。運用が始まってからの体制は、検収の前に決めておくのが安全です。検収そのものの進め方はシステム開発の検収とは？基準と期間の決め方で整理しています。
システム開発で運用保守を委託する範囲の決め方
ここからは決め方です。やることは単純で、作業を業務単位に分解し、それぞれに担当を書き込むだけです。ただ、この単純な作業をやっていない現場がとても多いのが実情です。
委託範囲は業務単位で書き出して合意する
契約前にやってほしいのは、「保守運用一式」という書き方をやめて、作業を並べることです。並べたうえで、それぞれを委託するのか自社で持つのかを埋めていきます。埋まらない欄が出てきたら、そこが今まさに抜けている領域です。
委託範囲として担当を決めておく項目
- 監視する時間帯（平日日中だけか、24時間か）
- 障害連絡を受け付ける時間と、一次対応を始めるまでの目安
- バックアップの取得と、実際に戻せるかの確認
- OSやミドルウェアの更新への対応
- アカウントの発行と削除
- 社内からの問い合わせ窓口
- 軽微な改修に使える月あたりの時間枠
- 法改正や制度変更に伴う修正
とくに揉めやすいのが「軽微な改修」という言葉です。開発会社が想定しているのは画面の文言修正や項目の並び替え程度で、発注側は帳票の追加まで含むつもりでいる、という食い違いをよく見ます。月に何時間までを枠として使えるのか、その枠で何ができて何ができないのかを、契約前に具体例で確認しておいてください。「軽微かどうか」を後から言葉で争うより、時間枠で決めておくほうが揉めません。
この一覧を先に自社で作って、見積もりを取るときに一緒に渡すのが効きます。開発会社ごとに「保守」の指す範囲が違うため、同じ土俵で比べられるようになるからです。金額の比較は、範囲をそろえて初めて意味を持ちます。
費用の相場感や、契約に入れるべき条項、開発会社が撤退したときの備えについては受託開発の保守はどこまで頼む？費用相場と契約の判断軸で扱っているので、範囲を決めたあとにそちらを見てください。
運用の条件は納品後ではなく要件定義で決める
ここは見落とされがちなのですが、運用の条件は作りに影響します。24時間止められないシステムと、夜間は止まっていいシステムでは、構成そのものが変わります。障害から30分で戻したいのか、翌営業日でいいのかでも同じです。
そのため、これらを納品後に持ち出すと、たいてい追加費用の話になります。要件定義の段階で、少なくとも次の4つは決めておいてください。使う時間帯、止まってはいけない時間、障害からどれくらいで戻したいか、データをいつまで保存しておくか。
こうした機能以外の要求を整理する枠組みとして、IPAが非機能要求グレードを公開しています。非機能要求についてのユーザーと開発者の認識の行き違いを防ぐ目的で、要求項目を網羅的に並べ、重要な項目から順に受発注者のあいだで要求レベルを確認していく形のツール群です。なお、この事業は2009〜2018年度に実施されたもので、現在はアーカイブとして公開されています。項目の細かさは中小企業の案件にはかなり過剰ですが、「どういう軸で決めるべきか」の地図としては今も使えます。要件定義書にこれらをどう書くかは要件定義書のサンプルと作り方を参照してください。
自社側に置く担当と連絡経路を決める
委託範囲が決まったら、自社側の受け手を決めます。ここが空白のまま稼働すると、委託先は誰に連絡していいか分からず、社内の人はどこに聞けばいいか分からない状態になります。
最低限、次の3つの役割を誰かに割り当ててください。委託先とやりとりする窓口、費用が発生する依頼を承認する決裁者、そして業務側で「その変更をしていいか」を判断する人です。小さい会社なら1人が兼ねても構いませんが、兼ねていること自体は明示しておきます。
この3役を決めたうえで、委託先とどう付き合うかの型を持っておくと、毎月の報告や依頼のやりとりが安定します。委託先の管理の進め方はベンダーコントロールパーフェクトガイドに手順としてまとめてあります。
あわせて、夜間や休日に障害の連絡が来たとき誰が受けるのかも決めておいてください。ここを決めていないと、契約上は24時間対応でも、実際には翌朝まで誰も気づかないという状態になります。
情シス専任がいない会社の現実的な体制
中小企業では、情シス専任がいないほうが普通です。総務や経理の方が兼任で見ている、という会社をよく見ます。この前提で現実的な線を引くなら、自社で持つのは判断が要る仕事だけにして、手を動かす作業は出してしまうのがよいと考えています。
ただし、外に出したときも自社の手元に残しておいてほしいものがあります。アカウントと権限の一覧、契約書と委託範囲を書いた資料、ソースコードとドキュメントがどこにあるかの記録、そして毎月いくら払っているかの把握です。これらが自社にないと、担当者が異動したり、委託先を変えたくなったりしたときに何も分からなくなります。
兼任で回す場合、いちばん危ないのは担当者が1人に固定されて、その人しか状況を知らない状態になることです。異動や退職のときにまとめて分からなくなります。手間はかかりますが、委託先とのやりとりはメールやチャットの共有される場所で行い、決めたことは短くても記録に残してください。運用保守は数年単位で続くので、その間に担当が変わることのほうが普通だと考えておくのが安全です。
逆に言えば、この4つさえ自社で持っていれば、実作業はかなり任せてしまっても取り返しがつきます。丸投げが危ないのは作業を任せることではなく、何を任せているのかを自社の誰も把握していない状態のことです。
- Q. 運用と保守はどちらを先に決めますか？
- 順番としては、要件定義の段階で運用の条件（稼働時間や復旧の目標）を先に決め、保守の範囲と費用は開発の終盤、検収の前あたりで詰めるのが自然です。運用条件はシステムの作りに影響するため、後から言うと追加費用になります。
- Q. 開発した会社以外に保守を頼めますか？
- 頼めますが、ソースコードとドキュメントが揃っていること、そして著作権や利用条件の面で他社が触れる契約になっていることが前提です。実際には解析の手間が乗るので、同じ内容でも費用は上がりやすくなります。契約時にソースコードの引き渡しと第三者による改変の可否を確認しておいてください。
- Q. 保守契約はどのくらいの期間で結ぶものですか？
- 私が見てきた範囲では、1年契約で自動更新という形が多いです。ただし運用保守は年単位で続く長期の関係になるため、更新のタイミングで範囲と金額を見直せるようにしておくこと、そして解約したいときの通知期間を確認しておくことが大事です。
- Q. 保守契約を結ばない選択はありますか？
- あります。社内で完結する小規模なシステムで、止まっても業務が回るなら、都度依頼の形にして基本料金を払わない判断もありえます。ただしその場合、障害時に「いつ見てもらえるか」の約束がなくなります。止まったときに業務がどうなるかを基準に決めてください。
