「保守は社内の○○さんが見てくれている」——多くの企業で、稼働中のシステムの保守は特定の担当者に支えられています。ところがその担当者が退職や異動の話を切り出した途端、「あの人がいなくなったら、誰がこのシステムを見るのか」という不安が一気に表面化します。
保守は普段は目立たない仕事ですが、いざ障害が起きたときに即応できなければ、業務が止まり、売上や信用に直結します。それでも「では何人で、どんな体制を組めばいいのか」を体系的に教えてくれる情報は意外と少なく、費用相場の記事ばかりが目につきます。経営層から「保守体制をきちんと整えろ」と言われても、判断の軸がないまま見積もりだけが集まっていく、という状況に陥りがちです。
実は、システム保守に必要な人数は「システムの規模」だけでは決まりません。「どこまでの対応を求めるか(対応時間帯・重要度・対応スピード)」によって、同じ規模のシステムでも必要な人数は大きく変わります。この前提を押さえると、「何人が正解か」という漠然とした問いを、自社の状況に当てはめて判断できる形に変えられます。
本記事では、システム保守の体制を考える前提となる3つの観点を整理したうえで、小規模システムから24時間365日対応が必要なミッションクリティカルなシステムまで、規模・重要度別に必要な人数と役割分担の目安を一覧で示します。さらに、担当者1〜2名への属人化がなぜ危険なのか、人を増やさずに冗長化する方法、そして内製・外注・ハイブリッドのどれを選ぶべきかの判断基準まで、体制設計に必要な意思決定の道筋を解説します。読み終えたときには、自社のシステムに当てはめて「最低限必要な人数」と「内製か外注か」を自分で判断できる状態を目指します。
なお、保守費用の相場や算出方法そのものは別記事で詳しく扱っているため、本記事は「体制(何人・どんな役割)」の設計に集中します。
失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
システム保守の体制を「人数」で考える前に押さえる3つの観点

「うちのシステムは何人で保守すべきか」と考え始めると、つい「同業他社は何人でやっているか」を探したくなります。しかし、たとえ同じくらいの規模のシステムでも、求める対応のレベルが違えば必要な人数はまったく変わります。まず押さえたいのは、保守の人数を決める変数は「システムの規模」だけではなく、次の3つの観点で決まるということです。
- 対応時間帯(いつまで対応する必要があるか)
- システムの重要度(止まると何がどれだけ困るか)
- 求められる対応スピード(どれくらい早く復旧する必要があるか)
「何人が正解か」という問いは、実は「自社はどこまでの対応が必要か」という問いに置き換えられます。この置き換えができると、以降で紹介する規模別の目安を、他人事ではなく自社の状況に当てはめて読めるようになります。
対応時間帯で必要人数は大きく変わる
最も人数を左右するのが「対応時間帯」です。同じシステムでも、対応する時間帯によって必要な人員規模はまったく異なります。
- 営業時間内のみ(平日9〜18時など): 担当者が通常業務の中で対応できる範囲。少人数でも回せますが、休暇や退職への備えは別途必要です。
- 夜間・休日も一部対応(オンコール): 通常は日中対応しつつ、夜間休日は電話などで呼び出しに応じる体制。待機する担当者の負担が大きくなるため、ローテーションが組める人数が必要になります。
- 24時間365日(常時監視・即応): 誰かが常に対応できる状態を維持する必要があり、シフトを組むために最低でも5人前後が必要になります(具体的な試算は後述します)。
「24時間止められないシステム」と「平日日中だけ動けばいいシステム」では、必要人数が数倍違うことも珍しくありません。まずは自社のシステムが「いつまでの対応を本当に必要としているか」を見極めることが、体制設計の出発点になります。
システムの重要度(止まると何が困るか)で求められる体制が変わる
次に考えたいのが、システムの重要度です。これは「そのシステムが止まったとき、事業にどれだけの影響が出るか」で測ります。
たとえば社内の一部の人だけが使う管理ツールであれば、半日止まっても代替手段でしのげるかもしれません。一方、顧客が常時利用するECサイトや、止まると受発注業務全体が停止する基幹システムであれば、数分の停止でも売上機会の損失やクレームに直結します。
重要度が高いほど「すぐに対応できる人が常にいる」体制が求められ、結果として必要な人数や監視の仕組みも増えます。逆に、重要度がそれほど高くないシステムにまで過剰な24時間体制を敷くと、コストばかりかかって見合わなくなります。自社のシステムを「止まったときの困り具合」で分類しておくと、過不足のない体制を選びやすくなります。
「保守」と「運用」を分けて考えると人員設計がしやすい
体制を考えるとき、「保守」と「運用」を分けて整理すると人員設計がぐっとしやすくなります。
ざっくり言えば、運用は「システムを正常に動かし続けるための日常的な作業(監視・バックアップ・ログ確認など)」、保守は「不具合の修正や機能の改修など、システムに手を加える作業」を指します。日常的に発生する運用は当番制やローテーションで回しやすい一方、保守はシステムの中身を理解している人でないと対応が難しく、属人化しやすいという特徴があります。
この2つを分けて棚卸しすると、「日常監視は当番で回せるが、障害時の改修ができる人が1人しかいない」といった偏りが見えてきます。どこに人手が必要で、どこが属人化のリスクを抱えているかを切り分けられるのです。保守と運用の違いや、契約上どこまでが定額に含まれるかについては、保守と運用の違いとは?で詳しく解説しているので、定義を改めて確認したい方はあわせてご覧ください。
【規模別】システム保守に必要な人数・体制の目安

ここからは本記事の核心です。前章で整理した「対応時間帯」と「重要度」を軸に、規模別に必要な人数・役割分担・推奨形態(内製/外注/ハイブリッド)の目安を示します。あくまで一般的な目安であり、システムの複雑さや改修頻度によって増減しますが、自社がどのあたりに位置するかの当たりをつける材料として活用してください。
規模・重要度別の体制目安(早見表)
分類 | 対象システムの例 | 対応時間帯 | 最低人数の目安 | 主な役割 | 推奨形態 |
|---|---|---|---|---|---|
小規模 | 社内の一部で使う管理ツール、止まっても代替がきく業務システム | 営業時間内のみ | 2名(兼任可) | 1次対応・改修を兼務、ナレッジ共有 | 内製+外注バックアップ |
中規模 | 顧客も利用するWebサービス、止まると業務が滞る基幹システム | 営業時間内+夜間休日は一部オンコール | 3〜5名 | 1次対応/障害対応・改修/インフラ監視を分担 | ハイブリッド(内製+外注) |
ミッションクリティカル | 24時間稼働のECサイト、止められない決済・受発注基盤 | 24時間365日 | 5名以上 | 監視・1次対応のシフト+障害対応・改修・インフラの専門担当 | 外注または手厚いハイブリッド |
ポイントは、人数が「対応時間帯」と強く連動していることです。同じ中規模システムでも、夜間休日のオンコールを求めるかどうかで必要人数は変わります。以下、それぞれの体制を補足します。
小規模システム(営業時間内対応)の体制目安
社内の一部で使うツールや、半日程度なら止まっても代替手段でしのげるシステムであれば、平日営業時間内の対応で十分なケースが多くなります。この規模では、専任を何人も置く必要はありません。
ただし、ここで陥りがちなのが「担当者1名で十分」という判断です。1名体制は平常時は回っても、その人が辞めた・休んだ瞬間に保守が止まります。小規模であっても、最低2名でナレッジを共有しておくことを目安にしてください。2人目はフルタイムの専任である必要はなく、改修の手順や障害時の対応をドキュメントで共有し、いざというときに引き継げる状態を作っておくことが重要です。社内に2人目を割けない場合は、外注をバックアップとして契約しておく方法もあります(後述します)。
中規模システム(夜間・休日も一部対応)の体制目安
顧客も利用するWebサービスや、止まると複数部署の業務が滞る基幹システムになると、営業時間内だけでなく夜間・休日にも「呼び出されたら対応する」オンコール体制が必要になってきます。
この規模では、役割を分担することを意識します。具体的には、問い合わせや軽微なトラブルを受ける「1次対応」、障害の原因調査や改修を行う「障害対応・改修」、サーバーやネットワークの状態を見る「インフラ監視」といった役割です。これらを兼務しつつ、オンコールをローテーションで回すために、目安として3〜5名程度が必要になります。
人数が確保できない場合は、夜間休日のオンコールだけを外注に任せ、日中の改修は社内で行うといった分担も現実的です。すべてを内製で抱えようとすると一部の人に負担が集中するため、ハイブリッド型が向いている規模だといえます。
24時間365日が必要なシステムの体制目安(最低5名の試算ロジック)
決済基盤や24時間稼働のECサイトのように「1分たりとも止められない」システムでは、誰かが常に対応できる状態を維持しなければなりません。ここで「最低でも5名程度必要」とされる根拠を、工数から逆算してみます。
24時間365日の体制を1か月分の必要工数に換算すると、24時間 × 30日 = 720時間。これに交代時の引き継ぎなどを加えると、月およそ750時間規模の稼働が必要になります。一方、1人が月に働ける時間は概ね160時間程度です。
750時間 ÷ 160時間 ≒ 4.7人
つまり、休みなく回し続けるには最低でも5人前後が必要になる計算です(ReSMの試算でも、24時間365日体制には最低5人が必要で月額220万円超のコストがかかると示されています)。これは「常時1人が画面を見ていればいい」という単純な話ではなく、シフトを組み、休暇や急な欠員にも耐えるための冗長性まで含めた人数です。
この規模を自社の正社員だけで賄うのは、採用・育成・コストのいずれの面でも中小企業には現実的でないことが多く、24時間監視の部分は外注し、改修などコアな部分を内製で持つといった切り分けが選択肢になります。
保守要員の必要人数を自社で逆算する考え方
ここまでの規模別目安はあくまで典型例です。自社のシステムに当てはめて必要人数を見積もるには、24時間体制の試算と同じ考え方を一般化して使えます。
必要人数 = 月間に必要な保守工数 ÷ 1人あたりの月間稼働時間
たとえば「平日日中の対応で、監視・問い合わせ対応・月数件の改修を合わせて月160時間程度の工数がかかる」と見積もれるなら、計算上は1人で回せることになります。ただし、ここに「休暇・欠員への備え(冗長化)」を必ず上乗せします。1人分の工数しかないからといって1人体制にすると、その1人が抜けた瞬間にゼロになるからです。
実務では、まず「自社の保守に毎月どれくらいの工数がかかっているか(かかりそうか)」を運用と保守に分けて棚卸しし、それを1人あたり稼働時間で割って必要人数の下限を出し、そこに冗長化分を足す、という順序で考えると過不足のない人数にたどり着きやすくなります。
担当者1〜2名の「属人化」が招くリスクと最低限の冗長化

規模別の目安を見て「うちは小規模だから1人でいいのでは」と感じた方もいるかもしれません。しかし、保守体制で最も多くの企業がつまずくのが、この「担当者1〜2名への属人化」です。ここでは、なぜ属人化が危険なのかを正面から扱い、人数を大きく増やさなくても実行できる冗長化の手立てを示します。
1人保守体制で起きる典型的なトラブル
担当者1名にシステム保守が集中している状態では、平常時は問題なく回っていても、次のようなトラブルが起こりがちです。
- 退職・休職で対応不能になる: その人が辞めた・倒れた瞬間に、誰もシステムの中身を理解していない状態になり、障害が起きても手の打ちようがなくなります。
- システムがブラックボックス化する: 設定や改修の経緯がその人の頭の中だけにあり、ドキュメントが残らない。引き継ぎたくても引き継げる材料がない状態に陥ります。
- 長期休暇が取れない: 「自分がいないと障害に対応できない」というプレッシャーから、当人が休めなくなり、疲弊や離職につながる悪循環が生まれます。
- 障害が重なると破綻する: 同時に複数のトラブルが起きたとき、1人では対応しきれず、復旧が大幅に遅れます。
これらは「担当者の能力の問題」ではなく、「1人に集中させている体制の問題」です。どれだけ優秀な担当者でも、1人である限りこのリスクは構造的に消えません。
最低限の冗長化(2名体制・ナレッジ共有・ドキュメント化)
属人化を解消する第一歩は、いきなり大人数を雇うことではなく、「もう1人が引き継げる状態」を作ることです。具体的には、次の3点が最低限の冗長化になります。
- 最低2名でナレッジを共有する: 主担当と副担当を決め、障害対応や改修の経緯を2人で共有しておきます。副担当は専任でなくても、いざというときに対応の入口に立てるだけで状況は大きく変わります。
- 対応をドキュメント化する: システム構成・よくある障害と対処法・改修手順を文書として残します。「頭の中にある」状態を「誰でも参照できる」状態に変えることが、ブラックボックス化を防ぐ最大の対策です。
- 属人化している箇所を可視化する: 前章で触れた運用と保守の切り分けを使い、「この作業はこの人しかできない」という箇所を洗い出します。可視化できれば、優先的にドキュメント化・共有すべき対象が明確になります。
人数を増やす前に、まずこの「最低限の冗長化」ができているかを点検するだけでも、退職・休職リスクへの備えは大きく前進します。
人を増やさずに冗長化する選択肢(外注をバックアップに使う)
「2人目を社内で確保するのが難しい」という企業は少なくありません。その場合に有効なのが、外注をバックアップとして使う方法です。
たとえば、普段の保守は社内の担当者が行いつつ、外部の保守会社と「障害時や担当者不在時に対応できる」契約を結んでおく形です。これにより、社内の人員を増やさずに「もう1人」に相当する冗長性を確保できます。担当者が長期休暇を取るときや退職したときの引き継ぎ先としても機能するため、属人化の解消と事業継続の両面で保険になります。
ポイントは、外注に丸投げするのではなく、社内にもシステムの概要を理解した人を残しつつ、いざというときの実働を外部に持たせるという発想です。次章では、こうした内製と外注をどう組み合わせて判断するかを整理します。
内製・外注・ハイブリッド、自社はどれを選ぶべきか

体制を考えるうえで最後に立ちはだかるのが、「結局、社内で抱えるべきか、外に出すべきか」という判断です。ここでは、内製と外注のメリット・デメリットを並べるのではなく、自社がどちらに当てはまるかを辿れる判断の道筋として整理します。
外注を検討すべきサイン
次のようなサインが当てはまる場合、保守の全部または一部を外注に出すことを前向きに検討する価値があります。
- 担当者が1〜2名で、退職リスクが大きい: 前章で見た属人化の状態。社内で2人目を確保できないなら、外注でバックアップを持つのが現実的です。
- 障害時に即応できる体制がない: 夜間休日や障害発生時にすぐ動ける人がいない場合、対応時間帯をカバーする外注が有効です。
- 高度なセキュリティ・インフラ対応のスキルが社内にない: 専門性が必要な領域は、内製で育てるより外部の専門家に任せたほうが早く確実なことがあります。
- 情シスが保守に忙殺され、本来の業務に手が回らない: 担当者が日々の保守に追われて、社内のIT企画やDXが進まないなら、定型的な保守を外に出して人的リソースを取り戻す判断が有効です。
ひとつでも強く当てはまるなら、外注やハイブリッドの検討を始めるタイミングだといえます。
内製が有利なケース
一方で、次のようなケースでは内製(社内で保守を持つこと)が有利に働きます。
- 改修が頻繁に発生する: 仕様変更や機能追加が日常的にあるシステムは、中身を熟知した社内チームが持つほうがスピーディーに対応できます。
- システムが事業の核(競争力の源泉)である: 自社の強みに直結するシステムは、ノウハウを社内に蓄積する意味が大きく、外部に依存しすぎるとリスクになります。
- 保守できるIT人材が社内にいる、または育てられる: 既にスキルのある人材がいるなら、その強みを活かして内製で回す選択は合理的です。
内製は「ノウハウが社内に残る」「事業の変化に即応できる」という強みがある反面、人材の採用・育成・冗長化のコストを自社で負う必要があります。この負担を負えるかどうかが、内製か外注かの分かれ目になります。
中小企業に現実的な「ハイブリッド型」の組み方
実際のところ、多くの中小企業にとって「完全内製」も「完全外注」も極端な選択になりがちです。現実的なのは、両者を組み合わせるハイブリッド型です。
代表的な組み方は次の2つです。
- コアは内製、周辺は外注: 事業の核となる改修や仕様判断は社内に残し、24時間監視や夜間休日のオンコール、定型的なインフラ対応は外注に任せる。社内のノウハウを守りつつ、人手のかかる部分を外に出せます。
- 当面は外注、段階的に内製移管: 立ち上げ期は外注で安定運用を確保し、社内に人材が育つにつれて少しずつ内製へ移していく。逆に、内製で抱えきれなくなった部分を段階的に外注へ移すパターンもあります。
ハイブリッド型は「社内にノウハウを残す」と「人手・専門性を補う」を両立できるため、属人化リスクと体制不足の両方に効きます。自社のどこを内に残し、どこを外に出すかを、前章までの役割分担(1次対応/障害対応・改修/インフラ監視)に沿って切り分けてみてください。
判断に迷ったときの優先順位の付け方
それでも迷う場合は、次の順序で考えると整理しやすくなります。
- まず「止まると一番困るもの」を守る: 重要度の高いシステムから、対応時間帯をカバーできる体制(内製でも外注でも)を優先して整える。
- 次に「属人化している箇所」を冗長化する: 1人しか対応できない箇所を、2人体制か外注バックアップで補う。
- 最後に「内製で育てる価値があるか」で持ち方を決める: 事業の核なら内製寄り、定型的・専門的な領域なら外注寄りに振り分ける。
完璧な体制を一度に作る必要はありません。リスクの大きい順に手を打っていくことで、限られたリソースでも着実に属人化と障害リスクを減らせます。
保守体制を外注する場合に確認すべきこと
外注やハイブリッドを選んだ場合、「外に出したのに、結局また属人化や即応不足が起きた」という事態は避けたいところです。ここでは、費用や契約の細部ではなく、体制の妥当性を見極めるための観点に絞って確認すべき点を挙げます。
体制面で確認すべき5つの観点
外注先を評価するとき、料金の安さだけで選ぶと体制面の落とし穴を見落としがちです。次の5点は、体制が機能するかを見極めるために最低限確認してください。
- 対応時間帯: 自社が必要とする時間帯(営業時間内/夜間休日/24時間)を本当にカバーできるか。「24時間対応」とうたっていても、夜間は受付のみで実作業は翌営業日、というケースもあります。
- SLA(応答時間・復旧時間の目標): 障害発生からどれくらいで応答し、どれくらいで復旧を目指すかが契約で明示されているか。数値で約束されているかを確認します。
- 担当者の体制(属人化していないか): 外注先の中で1人の担当者に依存していないか。チームで対応し、担当者が不在でも引き継げる体制かを確認します。自社の属人化を解消するために外注したのに、外注先が属人化していては意味がありません。
- 障害時のエスカレーションフロー: 障害が起きたとき、誰がどう判断し、どこまで対応するのかの流れが決まっているか。連絡経路と責任の所在が曖昧だと、いざというとき動きが止まります。
- 引き継ぎ・ドキュメントの整備: 既存システムの情報をどう引き継ぐか、対応履歴をドキュメントとして残してくれるか。外注先任せでブラックボックス化しないよう、情報が社内にも残る形が望ましいです。
これらは、保守会社を選ぶときの評価基準とも重なります。会社選びの観点をより詳しく知りたい場合は、Webシステム保守会社の選び方もあわせてご覧ください。
費用・契約・会社選びは別記事で
本記事は「体制(何人・どんな役割)」の設計に集中しているため、費用や契約形態の詳細には深入りしていません。次の論点については、それぞれの記事で詳しく解説しています。
- 保守費用が予算内に収まるか、相場と妥当性を判断したい場合はシステム保守費用の相場と算出方法を参照してください。
- 契約形態(準委任と請負の違いなど)や、定額にどこまで含まれるかの境界については保守と運用の違いとは?で整理しています。
体制の妥当性を見極めたうえで、費用・契約の条件を詰めていくと、過不足のない外注契約に近づけます。
よくある質問(FAQ)
最後に、システム保守の体制を考えるうえで多く寄せられる疑問にお答えします。
Q. システム保守は最低何人いれば回せますか?
対応時間帯によって大きく変わります。平日営業時間内のみの対応で、改修頻度も多くないシステムなら、計算上は1人でも工数は足りる場合があります。ただし退職・休職への備えを考えると、最低2名でナレッジを共有しておくことを目安にしてください。夜間休日のオンコールが必要なら3〜5名、24時間365日なら最低5名前後が目安になります。
Q. 担当者1人だけで保守するのは危険ですか?
平常時は回っていても、構造的にリスクが高い状態です。その担当者が辞めた・休んだ瞬間に保守が止まり、システムがブラックボックス化します。人数を増やせない場合でも、ドキュメント化と外注バックアップで「もう1人が引き継げる状態」を作っておくことを強くおすすめします。
Q. 24時間365日の保守を自社で組むと何人・いくら必要ですか?
シフトを途切れさせないために、最低でも5名前後が必要になります(月間必要工数およそ750時間 ÷ 1人月160時間 ≒ 4.7人)。コストも相応に大きくなるため、中小企業では24時間監視の部分を外注し、改修などコアな部分を内製で持つハイブリッド型が現実的なことが多いです。具体的な費用感はシステム保守費用の相場と算出方法を参照してください。
Q. 外注すると社内に保守ノウハウが残らないのでは?
丸投げすればその懸念は現実になります。これを避けるには、システムの概要や仕様判断を社内に残しつつ、実働や専門領域を外部に持たせるハイブリッド型が有効です。外注先に対応履歴をドキュメントで残してもらい、その情報を社内でも参照できる形にしておくと、ノウハウの空洞化を防げます。
Q. 保守体制は誰が決めるべきですか(情シス/経営層/ベンダー)?
体制の選択は事業判断であり、最終的には経営層が関与すべきテーマです。ただし、現場の工数や属人化の実態を把握している情シスが、対応時間帯・重要度・必要工数を整理して選択肢を提示するのが現実的です。ベンダーの提案は有力な情報源ですが、自社の判断軸を持たずに鵜呑みにすると過剰な体制を勧められるおそれがあるため、本記事の観点を判断材料として活用してください。
まとめ:自社の規模に合った保守体制を設計するために
システム保守の体制は、「システムの規模」だけでなく「どこまでの対応を求めるか」で必要人数が決まります。本記事の要点を整理します。
- 必要人数を左右するのは、対応時間帯・システムの重要度・対応スピードの3つ。「何人が正解か」は「自社はどこまでの対応が必要か」に置き換えて考える。
- 規模別の目安は、小規模なら最低2名、夜間休日も対応する中規模なら3〜5名、24時間365日のミッションクリティカルなら最低5名前後。
- 最大のリスクは担当者1〜2名への属人化。人数を増やせなくても、2名でのナレッジ共有・ドキュメント化・外注バックアップで冗長化できる。
- 内製・外注・ハイブリッドは、外注を検討すべきサイン(属人化・即応不足・専門性不足・情シスの忙殺)に当てはまるかで判断し、多くの中小企業にはハイブリッド型が現実的。
次の一手として、まずは自社のシステムについて「対応時間帯」と「重要度」を整理し、本記事の規模別目安に当てはめてみてください。そのうえで、属人化している箇所を洗い出し、内製で守るべき部分と外注で補う部分を切り分ければ、過不足のない体制の輪郭が見えてきます。費用感を詰める段階に進んだらシステム保守費用の相場と算出方法を、外注先の比較に進んだらWebシステム保守会社の選び方を参照すると、体制設計から具体的な発注判断までスムーズにつなげられます。
失敗しないためのシステム保守の引継ぎチェックリスト

この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。



