維持運用の発注は、発注前の準備、委託先の選定、RFPの作成、契約とSLAの設計、発注後の体制づくりの順に進めるのが基本です。
ITシステムは、導入して終わりではなく、安定して動かし続けてこそ価値を生み出します。そのため、発注の段階から運用まで見据えて進める必要があります。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
維持運用の全体像や関連トピックは、次の記事もあわせてご覧ください。
ここまで見てきた準備、委託先の選定、契約、発注後の各段階を通じて、特に押さえたい実務は次の4点です。
- 対象システムの棚卸しと委託範囲の明確化
- SIer、専門ベンダー、開発会社など委託先の比較
- RFP、契約形態、SLAの設計
- 引き継ぎ、文書化、ガバナンスの実務
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム維持運用を発注する前の準備
維持運用の外注で失敗する企業の多くは、準備が不足したまま委託先を探し始めています。何を任せ、何を自社に残すかの線引きが曖昧なままでは、見積もりの精度も委託先の評価も定まりません。
発注側は、まずは対象システムの棚卸し、委託範囲の明確化、現行体制の整理という3つの準備を丁寧に進めます。
対象システムの棚卸しと運用実態の把握
維持運用を発注する第一歩は、対象システムの全体像を洗い出すことです。サーバー構成やミドルウェア、クラウドサービスなどの技術情報に加えて、誰がどのくらいの頻度で運用作業を行っているかという実態も押さえます。
一方で、多くの企業では、こうした情報が担当者の頭の中にしかなく、ドキュメント化されていません。この棚卸しを怠ったまま発注すると、委託先は不完全な情報をもとに見積もりを出すことになり、契約後に「想定外の作業が多い」「追加費用が発生する」といったトラブルにつながります。
構成管理台帳、運用手順書、障害対応履歴、月次のバッチ処理一覧などを整理しておくと、委託先に正確な情報を渡せます。さらに、自社内に運用ナレッジを蓄積できるという効果も得られます。
委託範囲の明確化と内製・外注の線引き
維持運用といっても業務範囲は広く、稼働監視やバックアップなどの「運用」業務と、不具合修正や小規模改修などの「保守」業務では性質が異なります。どこまでを外注し、どこからを自社に残すかが曖昧だと、責任の所在がぼやけ、障害時の対応が遅れます。線引きは、「自社のコア業務に集中するために何を手放すか」という視点が有効です。
業務の切り分けは、次の3点を整理するのが一般的です。
- 外注する業務：定型的な監視やヘルプデスク対応
- 自社に残す業務：ビジネス判断を伴う改修要件の定義や予算管理
- サービスレベルの希望：対応時間帯（平日日中のみか、24時間365日か）、対応スピード（一次回答までの時間）
MSPへの委託か内製かは、24時間365日の監視が必要か、専門人材を確保・維持できるか、運用ノウハウを社内に蓄積したいかで決まります。常時監視が必須で採用が難しい場合はMSP委託が向きます。一方、システムが自社ビジネスの根幹に関わり、運用知見を競争力にしたい場合は、コア部分を内製で持ち、周辺の定常監視だけを委託するハイブリッド型が現実的です。
「すべて内製」か「すべて丸投げ」かの二択ではなく、業務ごとに最適な担い手を割り当てる発想が、失敗を防ぐうえで役立ちます。
維持運用の委託先の種類と特徴
維持運用の委託先には複数のタイプがあり、それぞれ得意領域や費用感、対応の柔軟性が大きく異なります。自社のシステム特性と求めるサービスレベルに合った委託先を選ぶことが、長期的な安定稼働につながります。代表的な3つのタイプと、開発したベンダーへ継続委託する場合の特徴を、あらかじめ押さえておきましょう。
SIerと専門ベンダー、フリーランスの違い
SIer（システムインテグレーター）は、企画・設計・開発から保守運用までを一貫して提供できるのが強みです。メーカー系、ユーザー系、独立系、外資系といった分類があり、大規模で複雑なシステムや全社横断的なインフラ運用を任せたい場合に適しています。一方で、体制が手厚いぶん費用は高めになりやすく、小回りの利く柔軟な対応を求める場合には向かないこともあります。
専門ベンダーは、特定の製品や技術領域に特化した運用保守を得意とします。なかでもMSP（マネージドサービスプロバイダー）は、サーバーやクラウド基盤の監視・運用を24時間365日体制で代行する事業者です。夜間・休日も含めた常時監視や、セキュリティ・クラウド運用の高度な技術力を固定費で利用できる点が強みで、自社で24時間体制を組むのが難しい場合の有力な選択肢となります。
フリーランスエンジニアは、SIerでは予算が合わない、ベンダーでは柔軟性に欠けるといった場合の選択肢となります。特定の技術スタックに対して、スポット的かつコストを抑えた支援を受けられます。ただし、属人化リスクや継続性の担保には注意が必要です。
開発ベンダーへの継続委託という選択肢
システムを開発したベンダーにそのまま維持運用を委託する方法は、最も自然で立ち上がりが速い選択肢です。開発担当者がシステムの内部構造を熟知しているため、障害対応や改修を素早く進められ、引き継ぎコストもかかりません。新規にドキュメントを整備する負担が小さい点も、大きなメリットです。
ただし、開発ベンダーへの継続委託は、ベンダーロックインのリスクと表裏一体であり、注意が必要です。設計書や仕様書が十分に整っておらず、システムの構造を理解できるのが開発ベンダーだけという状態になると、不満があっても他社へ切り替えられません。その結果、価格交渉力を失います。
継続委託する場合でも、ドキュメントの納品と更新を契約に明記し、自社が運用実態を把握できる状態を保つことが欠かせません。
RFP作成と委託先の選び方
適切な委託先を選ぶには、複数社に同じ条件で提案を依頼し、横並びで比較することが欠かせません。そのための文書がRFP（提案依頼書）です。
維持運用のRFPは、開発のRFPと違って、サービスレベルと運用範囲を具体的に定めるところに特徴があります。RFPの書き方と、提案を評価する基準を順に見ていきます。
維持運用RFPに盛り込むべき項目
RFPの質は、その後の委託の成否を大きく左右します。
RFPは、課題や実現したいこと、必要な要件を委託先候補に正確に伝えるための文書です。維持運用のRFPには、次の項目を盛り込みます。
- 対象システムの構成概要
- 委託する業務範囲
- 求めるサービスレベル（稼働率や障害対応時間）
- 対応時間帯、報告体制、契約期間
曖昧な記述を避け、条件をできる限り定量的に示すことで、各社の提案がぶれず、比較しやすくなります。
特に重要なのは、現状の運用負荷を数値で示すことです。月間の障害発生件数、問い合わせ件数、バッチ処理の本数といった実績を示せば、委託先は精度の高い見積もりを出せます。情報が不足すると、各社が安全側に見積もって金額が膨らむか、楽観的な見積もりで契約後にトラブルが起きます。委託仕様書の書き方に迷ったときは、官公庁の「維持管理業務委託仕様書」が参考になります。
自治体案件の仕様書では、次の条件が定められています。
- 障害対応：再委託先が1時間以内に現地到着・対処を開始し、対応開始から1時間以内に内容と予想作業時間を報告、初期報告から原則4時間以内に完全復旧
- 定期保守：原則年1回（12月）
- 定期報告：年4回（3月・6月・9月・12月末）
- 作業記録：すべての介入活動について「開始・終了時間／所要時間／理由／再発防止策」の提出
発注側は、自治体案件の仕様書にある時間要件を自社の委託仕様書のたたき台にすると、対応スピードや報告頻度を曖昧にせず、各社に同じ前提で提案してもらえます。
記録ルールを仕様書に定めると、運用のブラックボックス化を抑えられ、後述する継続的なガバナンスの土台にもなります。報告体制は、月次の運用報告会と四半期ごとの定期報告書のように、頻度と様式をセットで仕様書に落とし込んでおくと確実です。
提案を評価する基準
提案を評価する際は、価格の安さだけで判断しないことが鉄則です。維持運用は数年単位で続く取引のため、もっとも重視すべきは「安定稼働を継続できるか」です。具体的には、同規模・同業種の運用実績があるか、障害対応のプロセスが体系化されているか、担当者が交代しても品質を維持できる体制かといった観点で評価します。
あわせて、コミュニケーションの相性も軽視できません。月次報告で何を示してくれるか、改善提案を主体的に行ってくれるか、問い合わせへのレスポンスは適切かといった点は、長期的な関係の質を決めます。
提案書の比較に加え、担当予定者との面談を設けることで、書面では見えない対応力や姿勢を確認できます。そのうえで、複数社を同じ基準で評価し、総合点で選定することが失敗を防ぐ近道です。
契約形態とSLAの設計
維持運用の委託では、契約形態の選択とSLA（サービスレベルアグリーメント）の設計が、トラブルを未然に防ぐうえで欠かせません。「言った言わない」を避けるには、ベンダーの責任範囲を明確にし、契約書とSLAをセットで作り込むことが大切です。準委任契約と請負契約の使い分け、そしてSLAで定めるべき指標を順に見ていきます。
準委任契約と請負契約の使い分け
維持運用は、成果物の完成ではなく、規定された業務の遂行を目的とするため、準委任契約をベースとするのが一般的です。準委任契約では、受託者が善良な管理者の注意をもって業務を遂行する義務を負い、稼働監視やヘルプデスク対応といった継続的な運用業務がこれに当たります。月額定額で一定の業務を任せる形が多く、運用の継続性を担保しやすいのが特徴です。
一方、一定規模の改修や機能追加など、明確な成果物を伴う作業は、その都度請負契約で対応する形が実務上よく取られます。請負契約では成果物の完成と契約不適合責任が伴うため、責任範囲が明確になります。
維持運用は準委任、まとまった改修は請負という二段構えにすると、日常運用の柔軟性とスポット作業の品質保証を両立できます。契約書には「運用」「保守」の定義と、どこまで対応するかを具体的に記載しておくことが、後のトラブル防止につながります。
SLAで定めるべきサービスレベル指標
SLAは、サービス提供者と利用者の間でサービス品質を定量的に取り決める合意です。維持運用のSLAでは、稼働率（可用性）が中核となる指標で、一般的には99%以上を目標とし、ミッションクリティカルなシステムでは99.9%やそれ以上が求められます。稼働率以外にも、障害発生時の一次回答までの時間や問い合わせへの応答時間を、対応時間帯とあわせて明文化します。
RTO（目標復旧時間／Recovery Time Objective）は、障害発生から復旧までの目標時間で、たとえば「重大障害は4時間以内に復旧」と定めます。RPO（目標復旧時点／Recovery Point Objective）は、どの時点までのデータを復旧できるかの目標で、「直近1時間以内のデータまで保証する」と決めれば、最低でも1時間間隔のバックアップが必要になります。
RTOとRPOは、システムの重要度とデータ消失の許容範囲から逆算し、運用設計やバックアップ方式と合わせて設定します。SLAには、達成できなかった場合の扱い（報告義務やペナルティの有無）も定めておくと、実効性が高まります。ただし、過度に厳しい水準は費用が跳ね上がるため、重要度に応じた現実的な水準にし、運用実績をもとに定期的に見直すのが望ましいです。
発注後の体制づくりと失敗しないためのポイント
維持運用アウトソーシングの成否は、委託契約を結んだ後に、適切な体制を保てるかどうかで決まります。
「丸投げ」によるブラックボックス化やベンダーロックインを避けるには、発注側にも一定の関与が求められます。押さえるべきは、引き継ぎの徹底と継続的なガバナンスの2点です。
引き継ぎとドキュメント整備の徹底
新しい委託先に運用を引き継ぐ際は、構成情報や運用手順書を確実に移管することが欠かせません。障害対応のナレッジや各種パスワードも、必ず渡しておく必要があります。
ドキュメントが不十分なまま引き継ぐと、特定のベンダーや担当者でなければ保守できない属人化が生まれ、ベンダーロックインの温床となります。実際、ベンダーロックインの主因のひとつは、設計・開発時に十分なドキュメントが用意されていなかったことだと指摘されています。
これを防ぐには、契約段階でドキュメントの納品と定期更新を義務付け、他社が引き継げる状態を保つことが重要です。委託先まかせにせず、自社の担当者も運用の概況を把握しておくと、切り替えや内製化への移行がスムーズになります。「誰もパスワードを知らない」「設計書が存在しない」状況を作らないことが、長期的な選択肢を確保する鍵となります。
継続的なガバナンスと丸投げの回避
維持運用を外注しても、システムの最終的な責任は発注企業に残ります。安易な丸投げは、コスト構造が見えなくなり、改善が止まり、いつの間にか割高な契約を続けてしまう原因になります。
これを避けるには、月次報告会を通じて稼働状況、障害傾向、改善提案を定期的にレビューし、委託先の活動を把握し続けることが効果的です。あわせて、契約内容とサービスレベルを年次で見直し、システムの利用状況の変化に合わせて委託範囲や費用を調整していきます。
5年を超えるような長期契約を漫然と続けることは、ベンダーへの過度な依存を生むため、避けたいところです。委託先を「外部の運用部門」として適切にマネジメントする姿勢こそが、維持運用アウトソーシングを成功に導きます。発注先の選定や契約設計、運用体制の構築にお悩みの場合は、ぜひお気軽にご相談ください。
まとめ
ITシステムの維持運用を外注する際は、まず対象システムの棚卸しと委託範囲の明確化を丁寧に行うことが出発点です。そのうえで、SIer、専門ベンダー、フリーランス、開発ベンダーへの継続委託といった選択肢の特徴を理解し、自社のシステム特性と求めるサービスレベルに合う委託先を選びます。
委託先の選定では、サービスレベルを具体的に定めたRFPを作成し、価格よりも安定稼働の実現性を基準に複数社を比較することが重要です。契約は準委任をベースに、まとまった改修は請負で対応する二段構えとし、可用性をはじめとするSLAを現実的な水準で設計します。
そして発注後は、ドキュメント整備による属人化の防止と、月次レビューによる継続的なガバナンスを徹底します。丸投げによるブラックボックス化やベンダーロックインを避けることが、長期的な安定稼働への近道です。
本記事が、ITシステム維持運用の発注を検討される皆様の一助になれば幸いです。具体的な委託先選定やRFP作成、契約・SLA設計のご支援については、お気軽にご相談ください。
関連記事・詳細はこちらもご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。