ITシステム保守管理の発注は、保守タイプごとに発注範囲を分け、対象資産を洗い出すことから始まります。続いて保守範囲を仕様書に明文化し、契約形態を決めてから委託先を見極めます。レガシーシステムでは、発注前にドキュメントを整える作業も欠かせません。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム保守管理の発注前の準備
発注で失敗する最大の原因は、委託先選びそのものより、発注側の準備不足にあります。
ITシステム保守管理は「修理」だけを指す言葉ではありません。機能の変化に追従する適応保守や、性能・保守性を改善する完全化保守まで含む、幅広い概念です。
この範囲を発注者が把握しないまま見積もりを依頼すると、各社の提案が比べられないほどばらばらになり、結果として安いだけの委託先や、対応範囲の狭い委託先を選んでしまいます。
まずは発注側が、自社の保守業務を性質ごとに分解し、どこを外注したいのかを言葉にすることが出発点です。
保守タイプごとの発注範囲の分解
ITシステム保守管理は、国際規格ISO/IEC 14764でも整理されているとおり、次の4分類が基本となります。
- 是正保守：発生した障害やバグを修正する、後ろ向きの対応。
- 予防保守：障害が顕在化する前に、潜在的な不具合を取り除く先回りの対応。
- 適応保守：OSのバージョンアップや法改正への追従。
- 完全化保守：性能改善やコードのリファクタリングなど、システムをより良くする前向きの対応。
発注時には、この4つのうちどれを委託対象に含めるかを明示することが大切です。多くのトラブルは「障害対応は頼んだが、OSアップデートに伴う改修は契約外だった」といった、適応保守の抜け漏れから生じます。
近年は、ログやメトリクスのデータ分析で故障を予知する予測保守が、独立した技術領域として扱われるようになっています。監視と一体で発注するかどうかも、論点のひとつです。
自社のシステムにとってどのタイプが必須で、どこからが任意かを発注前に仕分けておくことが、見積もりの精度を大きく左右します。
現状の保守対象資産の棚卸し
保守タイプの整理と並行して必要なのが、対象となるシステム資産の棚卸しです。発注側は、サーバーやネットワーク機器などのハードウェアから、OSやミドルウェア、アプリケーション、外部連携しているSaaSやAPIまでを一覧にし、構成・バージョン・サポート期限を把握します。
この情報がないまま発注すると、委託先は安全を見込んで高めの見積もりを出さざるを得ず、発注者は不利な条件を飲むことになります。また、棚卸しの際は、システムごとの重要度ランクも併せて設定しておくことをおすすめします。
基幹システムのように停止が許されないものと、社内向けの軽微なツールでは、求める復旧時間も保守の手厚さも異なります。重要度に応じて保守レベルに差をつければ、無駄なコストを抑え、守るべきシステムに資源を集中できます。この棚卸し資料は、後述する保守範囲の明文化や見積もり依頼の基礎資料としてそのまま使えるため、発注準備の中でも特に投資対効果の高い作業です。
保守範囲の明文化と発注仕様書
発注準備が整ったら、それを発注仕様書という形に落とし込みます。保守管理の委託で後悔しないためには、「何を、どの品質で、どのくらいの時間で対応してもらうのか」を文書として確定させることが欠かせません。
保守は障害という不確実な事象を扱うため、口頭の合意や曖昧な記述では、必ず認識のズレが生まれます。
官公庁が実際に用いている維持管理業務委託仕様書の数値要件は、実務に耐える仕様書をつくる際の参考になります。
対応範囲と対象外の明記
仕様書づくりで見落とされがちなのが、「対応する範囲」だけでなく「対応しない範囲」も明記することです。たとえば、次のような境界線を文章で固定しておきます。
- 修正の範囲：アプリケーションのバグ修正は含むが、ハードウェア交換は含まない
- 対応の時間帯：平日日中の障害対応は含むが、夜間休日は別契約とする
この対象外の明記がないと、障害時に「これは保守の範囲か否か」で委託先と押し問答になり、復旧が遅れます。
境界を引く際の物差しとしては、官公庁の維持管理業務委託仕様書が参考になります。ある自治体案件では、障害時の対応について次の規定がありました。
- 到着と対処：再委託先が1時間以内に現地到着・対処開始
- 報告：対応開始から1時間以内に内容と予想作業時間を発注者へ報告
その上で、「初期報告から原則4時間以内の完全復旧」を求めていました。こうした数値を仕様書に書き込めば、委託先は曖昧な努力義務ではなく、明確な達成基準を負うことになります。
自社で同等の厳しさが必要かは別として、提案された対応時間が妥当かを判断する物差しになります。
記録提出義務によるブラックボックス化の防止
外注の最大のデメリットは、保守ノウハウが委託先に蓄積され、自社にとってシステムがブラックボックス化することです。この対策として、仕様書に記録の提出義務を盛り込むことが極めて有効です。
前述の官公庁仕様書では、すべての介入活動について記録を提出させる運用が義務化されていました。記録には、介入の開始時間と終了時間、所要時間を書き、あわせて対応理由と再発防止策も残します。
この記録が積み上がれば、たとえ委託先を切り替えることになっても、過去の対応履歴が資産として残ります。
あわせて、定期報告の頻度も仕様書で定めておきます。官公庁の例では、次のように定める形が採られていました。
- 定期保守：原則として年1回12月に実施
- 定期報告：年4回（3月・6月・9月・12月末）に求める
こうした定期的な報告サイクルを設けることで、障害が起きていない平常時でもシステムの健康状態を可視化でき、突発対応に頼らない予防保守へとつなげられます。記録と定期報告の二本立てを仕様書に組み込むことが、丸投げによるブラックボックス化を防ぐ実務的な歯止めとなります。
レガシーシステムの解きほぐし
長年運用してきたシステムを外部に保守委託する際、最大の障壁となるのがドキュメントの欠落です。当時の開発者が退職し、仕様書も更新されないまま動き続けているシステムは、委託先にとって中身の分からない箱でしかありません。
この状態のまま発注すると、委託先は調査に膨大な工数を要し、見積もりは高騰し、障害時の復旧も遅れます。発注前にこのブラックボックスをある程度解きほぐしておくことは、保守委託を成功させるうえで見落としやすい要点です。
リバースエンジニアリングの進め方
ドキュメントのないシステムは、リバースエンジニアリングの手順で解きほぐします。まず、ソースコードやデータベース構造から現状の機能とデータの流れを抽出し、現行仕様書として再構築します。
たとえば、図書館システムでは、会員の状況や貸出延長回数に応じて新規貸出を制限するといった業務ルールを、次のような成果物の形に落とし込みます。
- ER図：データ同士の関係を示す図
- CRUD図：データの作成・参照・更新・削除の対応を示す図
- 業務処理定義書：業務の処理内容を定めた文書
ER図などの図表があれば、委託先はコードを一から読み解かずとも全体像をつかめます。
この作業をすべて自社で行う必要はなく、現状調査とドキュメント化だけを切り出して専門会社に発注する選択肢もあります。むしろ第三者が解析したほうが、属人的な思い込みを排した正確なドキュメントになることも少なくありません。
重要なのは、本格的な保守委託契約に入る前に、いわば健康診断としてシステムの現状を可視化しておくことです。この一手間が、保守見積もりの精度と障害時の復旧スピードを大きく改善します。発注の進め方や全体フローについては、ITシステム保守管理の進め方の記事も参考になります。
引き継ぎ資料の整備と委託先への提供
解きほぐしで得た成果物は、そのまま委託先への引き継ぎ資料として活用します。これにより委託先の立ち上がりが早まり、初期の調査費用も抑えられます。
委託開始時には、次の資料を体系的にまとめて提供します。
- システム構成図：システム全体の構成を示す図
- データベース定義：テーブルや項目の定義
- 業務フロー：業務の流れを示した資料
- 既知の不具合一覧：把握している不具合の一覧
- 運用手順書：日々の運用の進め方をまとめた文書
引き継ぎ資料の充実度は、そのまま見積もり金額に跳ね返ると考えてよいでしょう。IPAも、情報が少ない超上流段階での見積もりはリスクが大きいと指摘しており、「不確定要素が多い中での見積もりを、プロジェクトの確定目標値として設定すべきではない」とされています。
レガシーシステムの保守発注は、まさに不確定要素の塊です。そのため、最初から固定金額で縛るのではなく、現状調査フェーズを別建てにして段階的に見積もりを精緻化していく進め方が現実的です。
引き継ぎ資料を整えるほど、この不確定性を減らし、適正な金額での契約に近づけられます。
契約形態と責任分界点
保守範囲とドキュメントが整ったら、次は契約条件を詰める段階です。
保守管理の委託では、契約形態の選び方と責任分界点の取り決めが、後のトラブルを左右します。
とくに複数のベンダーが関わる現代のシステム環境では、障害が起きたときに誰が原因を切り分け、誰が復旧の主導権を握るのかを、事前に決めておく必要があります。決めないままだと、各社が責任を押し付け合う事態に陥ります。
ここを契約段階で固めることが、安心して任せられる保守体制の土台となります。
準委任契約と請負契約の使い分け
保守委託の契約形態は、主に準委任契約と請負契約の2つから選びます。障害がいつ起きるか分からない保守業務は、成果物の完成を約束しにくいため、多くの保守委託は準委任契約が基本となります。
- 準委任契約：決められた業務を遂行すること自体に対して報酬を支払う形で、月額固定の保守運用に向いています
- 請負契約：成果物の完成に責任を負う形で、特定の改修や追加開発のように、明確なゴールがある作業に適しています
実務では、日常の監視・障害対応は準委任契約で月額契約を結び、大きな改修が発生したらその都度請負契約で別発注する、という組み合わせがよく用いられます。
この使い分けを理解しておかないと、本来は個別見積もりであるべき大型改修まで月額保守費の範囲だと誤解し、委託先との認識がずれます。また、IPAの共通フレームでも、開発と運用保守の責任分界点や、請負と準委任の使い分けの重要性が示されています。契約書には、どの業務がどちらの契約に属するのかを明記しておくことが肝心です。
マルチベンダー環境での責任分界点
現代のシステムは、クラウド事業者、アプリ開発会社、運用委託先など、複数の事業者が層をなして関わっています。
障害が起きると、原因がインフラ層かアプリ層か、外部APIの問題かが切り分けにくく、各社が「うちの領域ではない」と主張し合って復旧が止まることがあります。
これを防ぐには、契約段階で原因切り分けの主導権を誰が持つのかを明確にしておく必要があります。その際は、次の2点を取り決めておくと実務的です。
- 一次受付と切り分け：保守委託先に担わせる
- 連携の基準：自社や他ベンダーへのエスカレーション基準を定めておく
「まず保守委託先が受け、切り分けの結果インフラ起因と判明したらクラウド事業者へ連携する」といった調整プロセスを文書化しておけば、障害時に責任の所在で立ち往生せずに済みます。
委託費を抑えるために安易に範囲を狭めると、この調整役が不在になり、いざというときに自社が火消しに奔走する羽目になります。費用とのバランスについては、ITシステム保守管理の費用相場の記事も併せて確認しておくと、契約条件と金額の妥当性を判断しやすくなります。
失敗しない委託先の見極め方
仕様書と契約条件が固まったら、いよいよ委託先の選定です。保守管理の委託先は、開発会社・MSPと呼ばれる運用専門事業者・フリーランスなど多様で、それぞれに得意領域と価格帯があります。
重要なのは、提案書や見積書の表面的な金額だけで判断せず、丸投げ体質や低スキル要員のアサインを見抜くことです。
提案書と見積書の確認ポイント
提案書を読む際は、保守の各タイプにどう対応するかが具体的に書かれているかを確かめます。「障害があれば迅速に対応します」といった抽象的な表現しかない提案は要注意です。たとえば、是正保守と予防保守の進め方、適応保守としてのOS更新への追従方針、監視・予測保守の体制まで踏み込んで記述されている提案は、保守を体系的に理解している証拠です。
逆に、こうした分類への言及がなく価格の安さだけを強調する提案は、現場対応力が伴わない可能性があります。見積書では、内訳の透明性が判断材料になります。人件費・監視ツール費・夜間対応の体制費などが項目ごとに分かれているか、一式という言葉で丸められていないかを見ます。
対応する要員の体制が一人に依存していないかも、確認しておきたい点です。たとえば、担当者が一人だと、退職や休暇で保守が止まり、結局ブラックボックスが委託先側に移るだけになります。複数名でのバックアップ体制があるかを必ず確認しましょう。委託先候補の比較検討には、ITシステム保守管理でおすすめの開発会社6選の記事が役立ちます。
SLAの設定と合意
委託先を決めたら、サービス品質を保証するSLA（サービスレベルアグリーメント）を取り交わします。SLAでは、稼働率・障害一次対応までの時間・復旧目標時間（RTO）といった項目を、具体的な数値で合意します。たとえば、稼働率99.9パーセント、障害受付から30分以内の一次回答、重大障害は4時間以内の復旧目標、といった形です。
前述の官公庁仕様書の数値は、こうした目標値を設定するときの参考レンジになります。SLAは設定して終わりではなく、未達時の扱いと定期的な見直しまで取り決めておくことが欠かせません。目標を下回った場合の報告義務や費用減額の条件を定めておけば、委託先に品質を維持する動機が働きます。
また、システムの利用状況は時間とともに変わるため、半年や1年ごとにSLAの妥当性を見直すサイクルを契約に組み込むことをおすすめします。発注前に自社の保守体制全体を整理したい場合は、ITシステム保守管理の完全ガイドで全体像を確認しておくとよいでしょう。
まとめ
ITシステム保守管理の発注・外注を成功させる鍵は、委託先選びより前の段階にあります。
是正・予防・適応・完全化という保守タイプごとに発注範囲を分解し、対象資産を棚卸しします。
対応範囲と対象外を両方明記した発注仕様書をつくります。
官公庁仕様書に学んだ到着・報告・復旧の数値要件や記録提出義務を盛り込めば、ブラックボックス化を防げます。
ドキュメントの欠落したレガシーシステムは、リバースエンジニアリングで現状を可視化し、引き継ぎ資料を整えてから発注します。
事前の準備によって、見積もり精度と復旧スピードが大きく向上します。
契約面では準委任と請負を使い分け、マルチベンダー環境での責任分界点を文書化します。
提案書と見積書から丸投げ体質を見抜き、最後にSLAを数値で合意して定期的に見直します。
一連の流れを踏めば、保守委託は単なるコストではなく、システムを安定稼働させ続けるための堅実な投資となります。
本記事で示した物差しを、自社の発注準備にぜひ役立ててください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。