ITシステムを安定して使い続けるには、IT資産ライフサイクルを見据えた維持管理が欠かせず、社内だけで担うのが難しければ外注も検討します。
外注を進めるには、委託範囲の切り分けと資産の棚卸し、対応レベルの数値化を済ませたうえで、仕様書、契約形態、委託先の順に決めていきます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム維持管理を外注する前の全体像
ITシステム維持管理は、ただシステムを動かし続ける運用とは違い、IT資産のライフサイクル全体を最適化する、最も上位の枠組みです。
発注で失敗しないためには、まず維持管理が日常の運用や保守とどう違うかを理解し、委託範囲をはっきり線引きしておく必要があります。ここが曖昧なままだと、後になって「それは契約の範囲外です」と言われ、追加費用や対応漏れに悩まされかねません。
維持管理・運用・保守の委託範囲の切り分け
維持管理を外注するうえで最初に整理すべきは、「維持管理」「運用」「保守」という三つの言葉が指す業務範囲です。
運用と保守は、どちらも稼働中のシステムを支える業務ですが、性質が違うため、混同すると見積の範囲がずれてしまいます。
- 運用：監視、バックアップ、定時処理などの定常業務。
- 保守：障害修正、アップデート、機器交換などの対応。
- 維持管理：資産台帳、更新計画、ライセンスまでを含む上位概念。
これに対して維持管理は、運用と保守を内包したうえで、ライフサイクルコスト（LCC）の最適化まで扱う、より上位の概念です。この階層を理解しないまま「維持管理をお願いします」とだけ伝えると、ベンダーごとに解釈が分かれ、見積金額にも大きな開きが出てしまいます。
発注前には、自社が委託したいのは日常の監視までか、資産ライフサイクルの計画策定まで含むのかを明確にしておきましょう。委託範囲を文書にしておけば、複数社の見積を同じ条件で比べられます。
外注で得られるメリットと避けたいリスク
維持管理を外部に委託する最大のメリットは、24時間365日の監視体制や高度なセキュリティ技術、クラウド環境のパフォーマンス管理といった専門スキルを、自社で人材を抱えずに使える点です。委託料が固定費になるため、コストを予測しやすくなります。さらに、情報システム部門は採用や教育の負担から離れ、DX推進などのコア業務に集中できます。
また、資産更新計画の立案を任せれば、担当者の勘に頼らず、中長期の投資判断につながります。一方で、社内にノウハウが残らず業務がブラックボックス化するリスクと、システム情報を外部に渡すことによる情報漏洩のリスクは、避けたいところです。
これらは、委託先を選ぶ目利きだけでなく、契約と仕様書の作り込みによっても大きく抑えられます。後述するように、なかでも対応記録の提出やドキュメント整備を仕様書に義務として盛り込むことが、ブラックボックス化を防ぐ最も効果的な手段になります。
発注前の自社での準備
発注の成否は、ベンダーに声をかける前の準備でほぼ決まります。委託対象の資産を洗い出し、求める対応レベルを数値にしておけば、見積の精度が上がり、契約後のトラブルも大きく減らせます。
ここでは、発注前に手元にそろえておきたい情報と、その整理のしかたを順に見ていきます。
資産台帳と構成情報の棚卸し
維持管理を発注するには、対象のIT資産を漏れなく把握しておくことが土台になります。資産台帳には、サーバーやネットワーク機器のハードウェア、OSやミドルウェアのバージョン、稼働中のアプリケーションを記載します。保有ライセンスの数と更新期限も、同じ台帳にまとめます。
導入年月日や保守契約の残りの期間も併記しておけば、ベンダーは更新時期を見越して提案しやすくなります。もし社内のシステムが長年放置され、構成情報が断片的にしか残っていない場合は、リバースエンジニアリングで現状を明らかにする作業そのものを、発注範囲に含める方法もあります。
なお、レガシー化したシステムは、いきなり全機能の保守を任せるより、まず現状調査とドキュメント化を切り出して依頼したほうが、双方のリスクを抑えられます。発注前の棚卸しは、こうした段階的な委託を設計するときの判断材料にもなります。
求める対応レベルの数値化
「障害が起きたらすぐ対応してほしい」といった曖昧な要望のままでは、ベンダーは見積を出せません。発注前に、どの業務がどのくらい止まると経営に影響するかを整理し、復旧までの時間と対応開始までの時間を数値で決めておきましょう。基幹システムは1時間の停止も許されない一方で、社内の補助システムは翌営業日の対応で足りるといったように、メリハリをつけます。
そうすれば、過剰なコストを払わずに済みます。この数値を決める際の物差しとして参考になるのが、官公庁の維持管理業務委託仕様書です。たとえば自治体の案件では、障害発生時に再委託先が「1時間以内に現地到着・対処開始」する水準が明記される例があります。
さらに、「対応開始から1時間以内に内容と予想作業時間を報告」や「初期報告から原則4時間以内に完全復旧」といった水準も示されます。こうした公的な数値を叩き台にすると、自社に合った現実的な復旧目標時間を見つけやすくなります。
失敗しない委託仕様書の作り方
委託仕様書は、発注の意図とベンダーの提供内容をすり合わせる、契約の核となる文書です。官公庁の維持管理業務委託仕様書には、民間企業もそのまま参考にできる、厳しく実務的な要件が詰まっています。
ここでは、ブラックボックス化を防ぎ、対応品質を保つために仕様書へ盛り込みたい要素を、具体的に紹介します。
RTOと報告頻度の明記
仕様書には、復旧目標時間（RTO）と報告のタイミングを、具体的な数値で書き込みます。官公庁の仕様書では、障害対応の開始から1時間以内の状況報告や、原則4時間以内の完全復旧といった水準が示されることがあります。そのうえで、これを自社システムの重要度に応じて調整します。
重要度の高いシステムには厳しい数値を、影響の小さいシステムには緩やかな数値を割り当てます。こうすれば、コストと品質のバランスを取れます。定期的な報告の頻度も、あわせて書いておきましょう。
公的仕様では、定期保守を「原則年1回12月」、定期報告を「年4回（3月・6月・9月・12月末）」と定める例があります。維持管理は資産ライフサイクルを見据える業務です。そのため、定期報告の場でハードウェアの劣化状況や更新提案を受け取れる仕組みを契約に組み込んでおくと、計画的な投資判断につなげられます。
記録提出義務によるブラックボックス化の防止
外注の最大のリスクであるブラックボックス化を防ぐ切り札は、対応記録の提出を義務づけることです。官公庁の仕様書では、すべての介入活動について記録を提出させる例があります。記録には、開始・終了時間と所要時間に加えて、対応理由や再発防止策を含めます。
この一文を仕様書に入れるだけで、ベンダー側も作業を透明に保つ動機が働き、社内にノウハウが残りやすくなります。あわせて、システム構成図や運用手順書、設定変更履歴といったドキュメントの整備と更新を、契約上の義務として明記しておくとよいでしょう。
こうしておけば、担当者が替わっても引き継げ、特定ベンダーへの過度な依存を避けられます。また、電力料や通信費といった付帯コストは、どちらが負担するかを公的仕様にならって明文化しておくと、後の費用トラブルを防げます。
契約形態と責任分界点の決め方
維持管理の委託では、契約形態の選び方と責任分界点の取り決めが、後々の紛争を防ぐ要になります。とくに、複数のベンダーが関わるマルチベンダー環境では、障害時に誰が原因を切り分け、誰が調整を主導するかを事前に決めておく必要があります。決めていないと、責任のなすり合いで復旧が遅れかねません。
ここでは、契約形態の使い分けと責任分界点の整理のしかたを見ていきます。
準委任と請負の使い分け
維持管理の業務は、成果物の完成を約束する請負契約より、専門的な役務の提供を続ける準委任契約が適するケースが多くなります。日々の監視や問い合わせ対応のように、明確な完成形がなく、稼働を保つこと自体に価値がある業務は、準委任のほうが実態に合います。一方で、資産更新計画の策定やドキュメント一式の作成のように、成果物を明確に定義できる業務は、請負として切り出すこともできます。
また、IPAの共通フレームでも、開発から運用保守に至る各工程で、請負と準委任を使い分ける必要性が示されています。契約期間や更新条件、中途解約時の扱いも確認し、ベンダーを乗り換えにくい状態（ロックイン）に陥らないよう注意しましょう。
維持管理は長期の付き合いになるため、契約の初期に出口の条件まで決めておくことは、健全な関係を保つうえで役立ちます。
マルチベンダー環境での調整主導権
クラウド事業者、アプリ開発会社、運用委託先など、複数のベンダーが絡む環境では、障害時に「どこに原因があるのか」を切り分ける作業が難航しがちです。発注時に、障害の一次受付窓口をどこに置くか、原因切り分けの主導権を誰が持つかを、はっきり取り決めておきましょう。
窓口を一本化し、調整役のベンダーを決めておけば、自社が各社の間を駆け回る事態を避けられます。責任分界点は、ネットワークからアプリケーションまでの層ごとに、どこからどこまでを誰が受け持つかを図にしておくと、認識のズレが起きにくくなります。
とくにクラウドネイティブな構成では、コンテナやマイクロサービスのどの層に問題があるのか分かりにくいものです。そのため、監視の責任範囲を事前にはっきりさせておくことが、迅速な復旧の前提になります。
委託先を見極める実務ポイント
仕様書と契約形態が固まったら、いよいよ委託先を選びます。提案書や見積書には、その会社の体質が透けて見えます。
ここでは、丸投げ体質や低スキルの要員配置を見抜くために、提案内容のどこに注目すべきかを具体的に見ていきます。前提は、複数社から提案を取り、同じ観点で横並びに比べることです。
提案書と見積から見る丸投げ体質
見積書が「運用保守一式」のように大づかみな項目しか並んでいない場合は、注意が必要です。どの作業に何人月を割り当て、どんなスキルの要員が担当するのかが明示されているか、SLAの数値が提案に具体的に織り込まれているかを見ておきましょう。
要員が一名だけの体制では、担当者が休んだり退職したりすると対応が止まってしまいます。そのため、複数名の体制やバックアップ要員の有無も確認しておきたいところです。
また、仕様書で求めた記録提出やドキュメント整備に対して、提案書が運用の仕組みを具体的に説明できているかも、見極めの材料になります。質問に具体的な手順や事例で答えられる会社は、現場の運用ノウハウを蓄えている証拠といえます。逆に、抽象的な言葉が並ぶだけの提案は、実際の作業を下請けに丸投げしている体質を疑ったほうがよいでしょう。
見積金額のROIでの判断
維持管理の費用は、システム開発費の15〜20%、年間で50万円から800万円程度が一般的な相場とされています。ただし、金額の安さだけでベンダーを選ぶと、対応品質の低さや隠れた追加費用で、結局高くつくことがあります。
委託で削減できる社内の人件費や、障害のダウンタイムを短縮して避けられる機会損失の額と比べ、投資対効果（ROI）の観点で判断しましょう。経営層に予算を説明するときは、維持管理を、単なるコストとしてだけでなく、安定稼働による事業継続性を確保する攻めの投資として位置づけると、説得力が増します。
たとえば、監視自動化ツールの導入費と、それによって削減できる夜間対応の人件費を並べて示すなど、数字で語れる材料を用意しておくと、社内の合意を得やすくなります。そのため、発注を成功させるには、技術面だけでなく、こうした社内説得のロジックづくりまで含めて準備することが大切です。
ITシステム維持管理の関連記事
ITシステム維持管理は、発注方法だけでなく、進め方や費用相場、委託先選びまで含めて理解すると、失敗の少ない意思決定につながります。合わせて、関連記事もぜひご覧ください。
それぞれ異なる切り口から、維持管理の検討を後押しする情報をまとめています。
・ITシステム維持管理の進め方/やり方/流れや方法/手法/工程/手順
・ITシステム維持管理でおすすめの開発会社/ベンダー6選と選び方
・ITシステム維持管理の見積相場や費用/コスト/値段について
・ITシステム維持管理の完全ガイドをご覧ください。
まとめ
ITシステム維持管理の発注を成功させる鍵は、ベンダーに声をかける前の準備にあります。
委託範囲を切り分け、資産台帳を洗い出し、求める対応レベルをRTOや報告頻度といった数値にしておけば、見積の精度が高まり、契約後のトラブルも大きく減らせます。
官公庁の維持管理業務委託仕様書に見られる「対応開始から1時間以内に報告」「4時間以内に復旧」「全介入活動の記録提出義務」といった厳しい数値は、自社の仕様書を作るときの貴重な物差しになります。
また、契約形態は業務の性質に応じて準委任と請負を使い分けます。マルチベンダー環境では、障害時の調整主導権と責任分界点を事前に明確にしておきましょう。
委託先を選ぶときは、見積の内訳や要員体制、提案の具体性から丸投げ体質を見抜き、金額の安さだけでなくROIの観点から判断します。
本記事で紹介した準備と着眼点を踏まえれば、ブラックボックス化を避けながら、安心して維持管理を任せられるパートナーを選べるはずです。発注前のひと手間が、長期的な安定稼働とコストの最適化につながります。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。