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