ITシステム保守構築の主な失敗は、責任分界の曖昧さ、ベンダーロックインと法的トラブル、保守移管の失敗、想定外費用の四つです。どれも開発時のトラブルと違って表面化しにくく、気づいたときには抜け出せなくなっています。
本記事は、ITシステム保守構築の失敗・課題・注意点・リスクを、発注企業の視点から掘り下げる「失敗・リスク特化」の解説です。また、どう避けるのかを、一次データとあわせて具体的に紹介します。全体像をまだ把握していない方は、まずITシステム保守構築の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム保守構築の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
責任分界の曖昧さが招くリスク
現代のシステムはクラウド基盤や外部SaaSと連携して動いているため、障害が起きたときに、原因がどこにあり、誰が対応するのかが曖昧になりがちです。
これは保守構築で最も頻発する失敗です。
責任分界を契約で定めないまま運用を始めると、いざ障害が起きたときに当事者同士が押し付け合い、復旧が遅れてしまいます。
これは技術の問題ではなく、設計と契約の不備が招くリスクです。
クラウド・SaaS起因の障害で生まれる対応の空白
障害の中には、保守ベンダーのコントロールの外で起きるものがあります。たとえば、クラウド基盤の大規模障害、連携SaaSのAPI仕様変更、AIの想定外の振る舞いなどです。そうした障害は、責任分界が曖昧だと対応の空白地帯になります。
ベンダーが「アプリの問題ではないので対象外」と言い、自社にも対応する力がなければ、システムは止まったまま打つ手がなくなります。この空白は、競合の保守契約でも見落とされがちな、現代特有の危険です。
この空白を防ぐには、外部要因で障害が起きたときに誰が何を支えるかを、保守構築の最初に取り決めておくことです。
- 責任範囲の明文化：自社、ベンダー、クラウド事業者、SaaS提供元の範囲を表にまとめたもの
- 外部要因時の支援範囲：原因の切り分け、暫定対応、復旧後の影響確認までの支援
保守ベンダーが外部要因の障害時にどこまで支援するかを取り決めておけば、外部要因が原因の障害でも放置されることはありません。責任分界を曖昧にしないことが、保守の失敗を防ぐ最初の一歩です。
この空白は、悪意より「想定の漏れ」から生まれやすい点に注意が必要です。契約時は、クラウドやSaaSが安定して動く前提で話が進みがちです。そのため、それらが止まったときの取り決めまで決めないまま、運用に入ってしまいます。
だからこそ、起こりうる最悪のシナリオを先に並べ、それぞれで誰が動くかを文書にしておくと効果的です。特にAIを組み込んだシステムでは、誤った出力を返したときに誰が検知し、どう直すかも、あらかじめ役割を決めておくべき論点です。
原因が曖昧でSLAペナルティが適用されないリスク
責任分界が曖昧だと、SLAペナルティの実効性も損なわれます。保証型のSLAを結んでいても、障害の原因がベンダー起因か外部要因かを特定できなければ、ペナルティの適用が見送られてしまいます。
減額の相場は月額の数%程度にとどまることが多いうえ、原因が有耶無耶になりがちなのが現実です（出典：ripla）。「保証型だから安心」と思い込むのは危険です。
このリスクへの対策は、ペナルティを実際に機能させられるよう、契約でSLAの決め方を具体的に詰めておくことです。
- SLAの計測方法：達成をどう測り、どこまでを障害として扱うか
- 原因が曖昧な場合の扱い：原因究明の進め方と、責任の所在の判定方法
障害の原因究明と責任の判定を取り決めておけば、いざというときに「原因不明で不適用」となる事態を減らせます。
数値を掲げるだけのSLAは、それを支える計測と判定の仕組みまで設計して初めて実効性を持ちます。
ベンダーロックインと法的トラブルのリスク
保守を同じベンダーに長く任せるうちに、そのベンダーなしではシステムを維持できない「ベンダーロックイン」に陥ることがあります。これも深刻なリスクです。
ロックインが進むと、保守費が高止まりしても交渉できず、不満があっても乗り換えられない「塩漬け」の状態になります。さらに、いざ乗り換えようとすると、法的なトラブルにまで発展することがあります。
保守費が高止まりする構造的なリスク
保守費が下がらない背景には、ベンダー側の利益構造があります。多重下請けの構造や、いつでも対応できるように確保している待機要員のコストが、保守費に上乗せされていることがあります。
発注側がこの構造を知らないと、提示された金額をそのまま受け入れるしかありません。そのうえ、年間保守費が開発費の15〜20%という目安を超えて膨らんでも、根拠を問えません（出典：ripla）。
このリスクへの対策は、保守費の内訳を項目ごとに出してもらい、相手の構造を理解したうえで交渉することです。内訳の項目には、定期保守、監視、障害対応があります。また、問い合わせ、軽微改修、管理・報告の項目もあります。
内訳が見えると、惰性で払っていた無駄が浮かび上がり、交渉の材料になります。相手の利益構造を知ることが、高止まりを崩す第一歩です。
内訳は、自社で担える部分とツールで代えられる部分に分けて見ます。
- 自社で担える部分：社内で巻き取れる運用作業
- ツールで代えられる部分：ツールに置き換えられる作業
あわせて、定期的にセカンドオピニオンを取ることも、高止まりを防ぐ有効な手段です。別のベンダーに概算の見積を依頼すれば、いま払っている保守費が相場と比べて妥当かを客観的に測れます。
現ベンダーへの依存度が高いほど、この比較の機会を持つこと自体が難しくなります。だからこそ、ロックインが進む前に外部の目を入れる習慣をつけておくことが肝心です。高止まりは、放置するほど抜け出しにくくなる構造的なリスクです。
ソースコード著作権を盾にした移管拒否のリスク
ロックインが法的トラブルに発展する典型が、ソースコードの著作権や独自パッケージの派生を盾にした移管拒否です。
契約上、ソースコードの権利がベンダー側にあると、乗り換え時に「コードは渡せない」「独自部品は使わせない」と主張され、移管が泥沼化します。交渉で決着しない場合は、契約解除に向けた法務ステップが必要になることもあります。
このリスクを根本から避けるには、開発・保守の契約時にソースコードと成果物の権利帰属を明確にしておくことです。
発注側が権利を持つか、少なくとも保守の継続と移管に必要な範囲で利用できる契約にしておけば、後のロックインを軽減できます。
riplaはフルスクラッチ受託と国内運用保守の立場から、発注側が主導権とコードの権利を保てる形を重視しています。権利関係を最初に押さえることが、将来の法的トラブルを防ぐ最大の保険です。
移管を拒まれないためには、契約書で権利の帰属と独自部品の扱いを確かめておく必要があります。
- ソースコードの権利帰属：契約で、権利が発注側とベンダーのどちらにあるか
- 独自パッケージへの依存：移管時に、どの独自部品をどこまで使えるか
権利関係に加えて、独自パッケージやフレームワークへの依存度も、ロックインの強さを左右します。ベンダー固有の作り込みが多いほど、他社が引き継ぐ難度は上がり、移管の見積もりも高騰します。
契約段階で汎用的な技術を採用してもらい、独自部分があれば設計の意図を文書化させておくと、将来の選択肢が広がります。
塩漬けは、小さな依存の積み重ねが数年後に「もう動かせない」状態を作り上げる構造です。この構造を理解しておくことが大切です。
保守移管が失敗するリスク
ロックインを脱して新しいベンダーへ乗り換えようとしても、保守移管そのものが失敗するリスクがあります。引き継ぎがうまくいかず、新ベンダーがシステムを十分に把握できないまま運用が始まると、障害対応が遅れ、かえって品質が下がってしまいます。移管は、ベンダーを変えるだけの単純な作業ではありません。
ドキュメント不足で引き継ぎが難航するリスク
移管が失敗する最大の原因は、ドキュメントの不足です。中身が文書として残っていないと、新ベンダーは手探りで把握するしかなく、引き継ぎが難航します。
旧ベンダーが非協力的だと、必要な情報が出てこず、移管はさらに難しくなります。この状態では、移管後の運用が安定するまでに、長い時間と多くのトラブルを覚悟しなければなりません。
このリスクを避けるには、平常時からドキュメントを整備し、いつでも引き継げる状態を保っておくことです。
保守契約にドキュメントの維持・更新を義務として組み込んでおけば、いざ移管というときに引き継ぎ資料が揃っています。移管は突然始まるものではなく、日々のドキュメント整備という地道な積み重ねが、その成否を決めます。
移管の前に、システム構成と運用手順の二つを文書として整えておくと、新ベンダーが手探りにならずに済みます。
- システム構成の資料：システムの全体像と、機能ごとの構成がわかる文書
- 運用手順の資料：日々の運用と、障害時の対応の流れを記した文書
二重コストが膨らむ移管期間のリスク
移管期間には、旧ベンダーと新ベンダーへ支払う二重コストが発生します。引き継ぎがだらだらと長引けば、この二重コストが膨らみ、乗り換えのメリットを食い潰してしまいます。
「安いベンダーに変えたのに、移管に手間取って結局高くついた」という失敗は、移管の段取りを甘く見たときに起こります。
このリスクへの対策は、移管を工程化し、期限を区切って進めることです。いつまでに何を引き継ぎ、いつ切り替えるかをスケジュールに落とし、並走期間を最小限に抑えます。
さらに、TCO（総保有コスト）で比べ、乗り換えに本当に価値があるかを見極めます。移管は勢いで始めず、段取りとコストを冷静に設計することが、失敗を避ける条件です。
移管の損得を見極めるには、二重払いの期間の費用と、移管の一時費用や安定までのコストを並べて比べることです。
- 二重払いの期間：旧ベンダーと新ベンダーの両方に支払う期間の費用
- 移管の一時費用と安定までのコスト：移管にかかる費用と、運用が安定するまでの費用
想定外費用が発生するリスク
保守を続けるなかで発注側を悩ませるのが、契約に含まれていなかった想定外の費用です。月額保守に入っていない作業が突然必要になり、高額な追加見積で予算を圧迫する失敗は、珍しくありません。平常時の月額だけを見て契約すると、非常時のコストで足をすくわれかねません。
OSS保守・データ復旧という見落とされがちな費用
想定外費用の代表例が、OSS（オープンソースソフトウェア）の保守や、大規模なデータ復旧です。
利用しているOSSにセキュリティ上の問題が出た場合、通常の保守に含まれていないと、その作業は追加費用になります。
クラウド側の障害に起因する大規模なデータ復旧も、ベンダーのコントロール外として別費用になりがちです。
このリスクへの対策は、契約時に非定常作業の扱いを明確にしておくことです。保守に含めるのか別費用とするのか、また別費用ならどう算定するのかを取り決めます。想定外を「想定済み」に変えておくことが、突発的な高額請求から自社を守ります。
想定外費用になりやすいのは、通常の保守から外れがちな二つの作業です。
- 大規模アップグレード：OSやミドルウェアの大規模な更新
- セキュリティインシデント対応：問題が見つかったときの緊急対応
これらの想定外費用は、システムの構成を把握していれば、ある程度は事前に予測できます。利用しているOSSの一覧とサポート状況、ミドルウェアのサポート期限、データ量の増加ペースを定期的に洗い出しておけば、「来年あたりに大きな対応が必要になる」という見通しが立ちます。
突発に見える費用の多くは、実は予兆があったのに見ていなかっただけです。定例報告のなかに中長期のリスクの確認を組み込んでおけば、突発を計画的な投資に変えられ、予算を組んで落ち着いて備えられます。
失敗を防ぐ継続伴走という考え方
ここまで見てきた失敗の多くは、保守を「開発が終わった後の付け足し」として軽く扱ったことに根があります。
責任分界からロックインの回避、移管の備え、想定外費用の手当てまで、すべて開発時から保守を見据えて設計しておけば、リスクを減らせます。保守は受け身の維持ではなく、システムの寿命とビジネス価値を守り続ける能動的な営みです。
riplaはフルスクラッチ受託と国内運用保守の立場から、「作った後も継続して伴走する」保守構築を一貫して重視しています。
SaaS・クラウド・AIが当たり前になった時代だからこそ、最初から、発注側が主導権を保てる形で設計することが、失敗を未然に防ぎます。リスクを知ったうえで備えることが、安心して使い続けられるシステムへの確かな道筋です。
保守を見据えるなら、開発の早い段階で、責任分界の線引きと、移管に備えたドキュメントの整備を決めておくことです。
- 責任分界の明確化：開発の時点で、自社とベンダー、外部事業者の範囲を決めること
- ドキュメントの整備：移管に備えて、日々の記録を積み重ねること
属人化と監視不在が招くリスク
契約面のリスクと並んで根深いのが、保守の体制そのものに起因するリスクです。特定の担当者に保守を依存させたまま放置する属人化が、その代表例です。
一方で、異常に気づく仕組みを持たない監視不在は、平常時には表面化しません。いざというときには、被害を一気に拡大させます。これらは「動いているから大丈夫」という油断のなかで静かに育つ、保守構築の盲点です。
ひとり情シスの属人化による運用のブラックボックス化
多くの企業では、社内のIT担当者がたった一人で全システムの保守を抱える「ひとり情シス」の状態が、そのまま放置されています。
運用手順やシステム構成が担当者の頭の中にしかない状態では、退職や急病で一気に立ち行かなくなるおそれがあります。
引き継ぎ資料がないまま担当者が去ると、誰もシステムの中身を把握できません。障害が起きても手も足も出ない、という最悪の事態に陥ります。
このリスクを避けるには、構成や障害履歴も含めて文書に残し、特定の個人に頼らない体制へ移すことです。社内で担当者を二重にできないときは、外部委託で体制を厚くすることも選べます。
サービス委託は月20万〜50万円、専門の運用要員は人月60万〜150万円が目安です（出典：ripla）。担当者一人が抜けたときの損失を考えると、属人化を解消する投資は十分に合理的といえます。
保守の失敗の多くは、技術ではなく「一人に頼りきった体制」から始まります。
属人化の解消は、社内に残る手順を形にするところから始まります。
- 運用手順の文書化：担当者の頭の中にある手順を書き出すこと
- 外部委託の活用：社内だけでは足りない部分を外部に任せること
監視不在で遅れる障害の発見
監視の仕組みを持たない保守では、障害が起きても、利用者からの「使えない」という連絡で初めて気づくことになります。この受け身の状態では、夜間や休日の障害が翌朝まで放置され、被害が静かに広がります。
ディスクの逼迫やメモリの枯渇のように、予兆をつかめば防げたはずの障害も、監視がなければ突然のダウンとして表れます。
火消しに追われ続ける運用は、根本原因の分析や再発防止に手が回らず、同じ障害を繰り返す悪循環に陥ります。
このリスクへの対策は、異常を早期に検知できる体制を作ることです。
保守費の内訳でも監視は15〜25%を占めるとされています（出典：ripla）。これを惜しんで監視を省くと、結果的に障害対応のコストや事業損失のほうが大きくなります。
監視不在は、目先の保守費を削った代償を、いざというときの大きな被害として支払う典型的な失敗です。保守構築では、監視を「あれば安心」ではなく「なければ致命的」な必須機能と位置づけるべきです。
riplaはフルスクラッチ受託と国内運用保守の立場から、属人化を解消し、監視を土台に据えた継続伴走型の保守構築を重視しています。
監視は、稼働とリソースを見る層と、ログを追う層に分けて考えます。
- 稼働監視・リソース監視：サービスの稼働状況と、ディスクやメモリの使用状況を見ること
- ログ監視：ログに現れる異常を早く拾う仕組み
まとめ
ITシステム保守構築の失敗・リスクを振り返ると、責任分界が曖昧なために対応の空白やSLAの不適用が起きます。
ベンダーロックインで保守費が高止まりし、著作権を盾にした移管拒否が法的トラブルを招きます。さらに、ドキュメント不足と二重コストで移管が失敗します。
また、OSS保守やデータ復旧といった想定外費用が予算を圧迫する、という構図が見えてきます。
これらはどれも、開発時から保守を見据えて設計していれば、避けられるリスクです。
失敗を防ぐ鍵は、平常時の便利さだけでなく、障害時・乗り換え時・非常時まで含めて契約と体制を設計しておくことです。
責任分界を明文化し、コードの権利を押さえ、ドキュメントを整え、想定外費用を想定済みに変えておけば、保守は安心して任せられるものになります。
riplaはフルスクラッチ受託と国内運用保守を組み合わせ、リスクを先回りして手当てする継続伴走型の保守構築を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。