納品後の運用と保守は誰が担いますか？
担当者がいない前提で、外注先と社内の分担を発注の段階で決めておきます。納品後に考え始めると、決める人がいないまま時間が過ぎます。
業務システムは、納品されて終わりではありません。障害が起きれば誰かが一次受けをします。法令や外部サービスの変更にも追従が要ります。その担い手を先に決める話です。
社内に担当者がいない企業の割合
そもそも担当者を置けていない企業が多数あります。株式会社kubellの調査では、「システム担当者がいない」中小企業は3割弱でした。従業員数10人から29人の企業に限ると、5割弱に上がります。
出典: 株式会社kubell 調査（2025年12月公表）
同じ調査では、中小企業の5割弱が日常的な取引や情報管理にデジタルを利用していないと回答しています。業務システムを入れること自体が、社内では初めての経験という企業が珍しくありません。
この状況で「詳しい人が出てくるはず」という前提を置くと、運用が止まります。前提を置かずに設計するほうが安全です。
担当者がいても兼任が増えている
担当者がいる場合も、専任とは限りません。ノークリサーチの調査では、年商500億円未満の中堅・中小企業のうち24.5%が「ひとり情シス」でした。2023年時点の21.3%から3.2ポイント上昇しています。
専任から兼任への移行も進んでいます。年商5億円から50億円の層では、専任の割合が16.7%です。一方、兼任は61.1%を占めます。
出典: ノークリサーチ 調査（TechTargetジャパンが報道）
兼任の担当者は、本業の合間に対応します。急ぎの障害が起きたとき、必ず手が空いているとは限りません。分担を決めるときは、この点を織り込みます。
人材の供給側にも余裕はありません。経済産業省の「IT人材需給に関する調査」では、IT人材の不足は2030年に最大で約79万人と試算されています。
出典: 経済産業省 商務情報政策局 情報処理振興課「IT分野について」
採用で解決する前提も置きにくい状況です。だからこそ、誰が何をするかを契約の段階で文字にしておきます。
分担を決める前に、運用と保守の作業を分解しておきます。次のセクションで整理します。
運用と保守には、具体的にどんな作業が含まれますか？
障害対応、問い合わせ対応、データの管理、法令や外部サービスの変更への追従、機能改修の5つに分かれます。この5つに分けると、どれを誰が持つかを決めやすくなります。
「運用保守」とひとくくりにすると、見積もりの範囲が曖昧になります。まず中身を分解します。
5つの作業に分けて考える
それぞれの中身と、発生の頻度の目安は次のとおりです。
| 作業 | 中身 | 頻度の目安 |
|---|---|---|
| 障害対応 | 画面が開かない、データが保存されない等の復旧 | 不定期。まとまって起きることがあります |
| 問い合わせ対応 | 使い方の質問、パスワードの再発行、データの修正依頼 | 導入直後に集中し、その後は減ります |
| データの管理 | バックアップの確認、保存期間を過ぎたデータの扱い | 月次または年次 |
| 変更への追従 | 法令改正、外部サービスの仕様変更、端末やブラウザの更新 | 年に数回 |
| 機能改修 | 業務の変化に合わせた画面や項目の追加 | 半年から1年に1回程度 |
この5つのうち、上の3つは「止めないための作業」です。下の2つは「合わせ続けるための作業」になります。性質が違うため、契約の形も変わります。契約については後述します。
なお表の頻度は、発注前に見当をつけるための目安です。システムの規模、利用者数、連携先の数によって変わります。実際の頻度は発注先と確認してください。
既存システムの保守が新しい取り組みを圧迫する
保守の負担は、次の投資を止めることがあります。ノークリサーチの調査を見ます。中堅・中小企業のIT担当者の課題として、「既存システムの管理・運用で手一杯」という状況が挙がっています。
出典: ノークリサーチ 調査（TechTargetジャパンが報道）
担当者が兼任であれば、なおさらです。前のセクションで見たとおり、年商5億円から50億円の層では兼任が61.1%を占めます。
内製に寄せる方向も、簡単ではありません。IPAが2025年6月26日に公表した「DX動向2025」では、日本、米国、ドイツの3か国を比較しています。システム開発の内製化について、「内製化（進めている、済）」の割合が米国企業で高いことが示されています。
出典: IPA「DX動向2025」
自社で抱える前提でも、外注に任せきる前提でもなく、作業ごとに分ける考え方が要ります。次のセクションで線引きの方法を示します。
委託する範囲は、どこで線を引きますか？
社内で判断が要る作業は残し、技術的な作業は委託する線引きが現実的です。技術力ではなく、判断の所在で分けます。
「詳しくないから全部お願いしたい」という分け方は、運用開始後に行き詰まります。業務の正解を知っているのは社内だからです。
社内に残す作業
次の4つは、外注先に渡せません。渡すと判断が止まります。
- データの中身が正しいかの判断。取引先名や単価が誤っていても、外注先には正誤が分かりません。所要時間の目安は、月次で30分程度です。
- 誰にどの権限を与えるかの決定。人事異動のたびに発生します。つまずきやすい点は、退職者の権限停止が漏れることです。
- 業務が変わったときの、変更するかどうかの判断。改修を頼むかどうかは社内の意思決定です。
- 外注先への一次連絡。誰が窓口になるかを1人決め、不在時の代理も決めておきます。
4番は担当者を置く話ではありません。連絡先を決める話です。兼任の総務担当でも務まります。
外注先に委託する作業
次の作業は、委託したほうが早く安全です。
| 作業 | 委託する理由 |
|---|---|
| 障害の原因調査と復旧 | ログの読み方とシステム内部の知識が要ります |
| サーバやミドルウェアの更新 | 更新を止めると脆弱性が残ります |
| バックアップの取得と復元の確認 | 復元できるかの確認は技術的な作業です |
| 外部サービスの仕様変更への追従 | 変更の告知を追い続ける必要があります |
| 機能改修の実装 | 設計と実装の作業そのものです |
バックアップは、取得しているかだけでなく、復元できるかまで確認してもらってください。実装者としてお伝えすると、取得はできていても復元の手順が誰も分からない状態は珍しくありません。年1回の復元テストを契約に入れておくと確実です。
判断に迷う作業の扱い
線引きが難しいのは、問い合わせ対応です。使い方の質問は社内で答えられる範囲もありますが、原因が不具合か操作ミスか、最初は判別できません。
おすすめの形は、初期の3か月だけ外注先が直接受ける方式です。その間に質問と回答を記録し、社内で答えられるものを切り分けていきます。記録が溜まれば、社内の窓口で対応できる範囲が見えます。
この記録は、後から作れません。運用開始と同時に残し始めてください。記録の残し方は、最後のセクションで整理します。
保守の契約は、準委任と請負のどちらが向きますか？
作業量が読めない運用保守は、準委任が向く場面が多くなります。完成すべき成果物を先に定義できないためです。
ただし、機能改修のように作るものが決まる作業は請負が合います。保守契約の中で、作業の種類によって分ける形も取れます。
準委任と請負の違い
2つの違いは、何に対して責任を負うかにあります。
| 項目 | 準委任 | 請負 |
|---|---|---|
| 責任の対象 | 業務の遂行 | 仕事の完成 |
| 根拠 | 民法第644条の善管注意義務 | 完成した仕事に対する契約不適合責任 |
| 向く作業 | 障害対応、問い合わせ対応、監視 | 機能改修、データ移行 |
| 費用の決め方 | 想定する作業量に対する月額 | 作るものに対する見積もり |
準委任でベンダが負う義務の根拠は、民法第644条です。善良な管理者の注意をもって委任事務を処理する義務を指します。完成の保証ではなく、適切に作業する義務です。
請負の場合は、契約不適合責任が付きます。通知の期限は1年以内です。
出典: BUSINESS LAWYERS「システム開発契約は請負と準委任どちらを使う？」
運用保守で準委任が選ばれる理由
障害がいつ何件起きるかは、契約の時点では分かりません。請負にすると、完成の定義ができないためです。
そのため運用保守では、次の形が一般的です。
- 月額の準委任で、対応の受付と一次調査までを含める。所要時間の目安は、契約の議論で1時間から2時間です。
- 実際の改修は、規模が決まった時点で個別に請負で見積もる。つまずきやすい点は、どこまでが月額に含まれるかの線引きです。
- 月額に含む作業量の上限を、時間または件数で決める。上限を超えた分の扱いも決めておきます。
3番を決めないまま契約すると、「これは含まれるのか」というやり取りが毎回発生します。時間数で区切るのが分かりやすい形です。
契約書の形式については、IPAが「情報システム・モデル取引・契約書（アジャイル開発版）」を公開しています。公開日は2020年3月31日です。その後、2021年10月に改訂されています。
出典: IPA「情報システム・モデル取引・契約書（アジャイル開発版）」、＠IT
アジャイル開発版は、作るものを進めながら決める前提の契約書です。運用保守のうち、継続的に改修を重ねる形と考え方が近くなります。
準委任と請負の違いをさらに詳しく知りたい場合は、当社の別記事で開発段階を含めて整理しています。
発注前に決める運用保守の要件は何ですか？
受付時間、対応の期限、対象範囲、作業量の上限、データの扱い、終了時の引き継ぎの6点を決めます。この6点が契約書に書かれていれば、後の認識違いはかなり減ります。
前のセクションまでで、作業の分解と契約の形は決まりました。ここからは具体の数字と条件を決めます。
6つの決めごと
上から順に決めます。所要時間の目安は、全体で2時間程度の打ち合わせ1回分です。
- 受付時間を決める。平日9時から18時が基本です。業務の開始時刻が早い場合は、その時間帯を含めるか確認します。つまずきやすい点は、時間外の扱いを決め忘れることです。
- 対応の期限を決める。受付からの一次回答までの時間と、復旧の目標時間を分けて書きます。復旧時間の保証は難しいため、目標として合意する形が現実的です。
- 対象範囲を決める。自社が作ったシステムだけか、連携先や端末の不具合まで見るかを決めます。範囲外の切り分けも、実際には手間がかかります。
- 作業量の上限を決める。月あたりの時間数または件数で区切ります。上限を超えた分の単価も、同時に決めておきます。
- データの扱いを決める。バックアップの頻度と保存世代、復元テストの実施頻度、保存期間を過ぎたデータの扱いを書きます。
- 終了時の引き継ぎを決める。契約を終えるときに何を渡すかを、開始時に決めます。ソースコード、設計書、データの形式、アカウントの一覧が対象です。
6番は後回しにされがちです。ただし契約を終える場面では、双方に交渉の余地が無くなります。開始時に決めておくほうが穏当です。
つまずきやすい点
3番の対象範囲が、実務で最も揉めます。
たとえば「システムにログインできない」という連絡があったとします。原因はシステム側かもしれません。社内の回線かもしれません。端末の設定かもしれません。切り分けが終わるまで、どちらの範囲か分かりません。
そのため範囲は、結果ではなく作業で書きます。次のように書き分けます。
| 書き方 | 起きること |
|---|---|
| 「本システムの不具合に対応する」 | 切り分け前は受けてもらえるか分かりません |
| 「本システムに関する障害の一次切り分けまでを行う」 | 原因がどこでも、まず受けてもらえます |
下の書き方であれば、切り分けの結果が社内の回線でも、そこまでは対応の範囲に入ります。社内に判断できる人がいない状況では、この違いが効いてきます。
もう1点は、2番の期限です。24時間365日の対応を求めると費用が上がります。業務が止まる時間帯を整理し、必要な時間帯だけ手厚くするほうが費用を抑えられます。