ITシステム維持管理の失敗は、塩漬けと属人化、ベンダーロックイン、保守移管の難航、想定外費用、監視・障害対応の不備に大別されます。発注企業が本当に学ぶべきなのは、失敗が静かに進むという点です。
費用相場や契約形態の全体像は、ITシステム維持管理の完全ガイドから先に読むと把握しやすくなります。
▼全体ガイドの記事
・ITシステム維持管理の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
維持管理の塩漬けと属人化という失敗
維持管理でいちばん静かに進む失敗が、システムの塩漬けと運用の属人化です。
動いているシステムは「触らない方が安全」と考えられがちで、更新も改善も止まりやすくなります。
その結果、システムは時代遅れになり、いざ手を入れようとしても、中身を分かる人がいないという事態に陥ります。派手な障害として表に出ない分、気づいたときには手遅れになりやすい、厄介な失敗です。
「動いているから触らない」が招く老朽化
塩漬けの典型は、「動いているから触らない」という判断が積み重なって、システムが老朽化していくパターンです。OSSやミドルウェアのサポートが切れても更新しないと、脆弱性が放置されます。さらに、外部連携の仕様変更にも追従しないままになります。
こうして維持管理が事実上止まると、ある日、サポート切れの製品に致命的な脆弱性が見つかり、慌てて対応することになります。日々の小さな更新を避けた代償は、最後にまとめて、しかも割高に請求されます。
塩漬けが危険なのは、放置するほど更新の難しさとコストが雪だるま式に膨らむからです。たとえば、数世代分のバージョンを一度に上げようとすると、互換性の問題が多発し、検証の負荷も跳ね上がります。
小さな更新をこまめに重ねていれば、一回あたりは軽い作業で済みます。それをためてしまうと、大きな移行プロジェクトに化けてしまいます。維持管理は、負担を後ろに先送りするほど高くつくという性質を理解しておくことが、塩漬けを避ける動機づけになります。
この失敗を防ぐには、発注側が維持管理を、何かあったら対応する受け身の活動から、計画的に更新し続ける能動的な活動へ位置づけ直す必要があります。
年間保守費は開発費の15〜20%が相場とされ（出典：ripla）、定期保守はその中に正規の業務として含まれます。
定期保守の目安は保守費内訳の20〜30%です（出典：ripla）。
発注側は、この定期保守を予算に組み込み、サポート期限を管理しながら計画的に更新する仕組みを持つことが大切です。これが、塩漬けという緩慢な失敗への最大の防御策になります。
塩漬けの兆しは、日常の中で見落とされがちです。
- サポート期限：OSSやミドルウェアごとに、更新が終わる時期を一覧で管理する
- 外部連携の仕様：連携先の変更予定を把握し、改修の時期と費用の負担先を決めておく
ひとり情シス依存と知識の属人化リスク
もう一つの失敗は、維持管理が特定の担当者一人に依存する属人化です。いわゆる「ひとり情シス」のように、システムの内部事情を一人だけが把握している状態では、その人が休んだり退職したりした瞬間に、維持管理が止まってしまいます。
手順や経緯がその担当者の頭の中にしか残っていなければ、引き継ぎは極めて難しくなります。
属人化を防ぐには、発注側の担当者が、維持管理の手順や構成情報、トラブル対応の記録を文書として残す習慣を持つことが欠かせません。
誰が見ても同じ品質で対応できるドキュメントがあれば、担当者が交代しても維持管理は止まりません。
人員の厚みを確保しにくい中小企業では、外部の運用保守ベンダーに一部を委託して属人化を緩和する選択も現実的です。
塩漬けと属人化の根本原因は、維持管理を「特定の人が、気が向いたときに」行う活動にしてしまうことです。
仕組みと記録で支える体制へ転換することが、その処方箋になります。
属人化による影響は、担当者の交代や不在のときに一気に表れます。
- 担当の二重化：一人が抜けても回るよう、もう一人が手順を把握している状態を保つ
- 問い合わせ窓口：社内外で誰に何を聞けばよいかを、一覧にしておく
ベンダーロックインと法的トラブルのリスク
維持管理を外部に委託していると、いつの間にか特定ベンダーから抜け出せなくなる「ベンダーロックイン」という失敗に陥ることがあります。中身がブラックボックス化すると、他社に頼もうにも引き継げず、高止まりした保守費を払い続けるしかなくなります。
発注側がいざ契約を解除しようとすると、ソースコードの著作権などを盾に移管を拒まれる法的トラブルにまで発展することもあります。
ブラックボックス化と保守費の高止まり
ロックインの入り口は、ドキュメントが整備されないまま委託を続けることです。設計書も改修履歴も最新化されず、システムの内部事情が委託先の中だけに蓄積していくと、発注側はもはやそのベンダーなしには維持管理ができなくなります。
この状態では、保守費の値上げを提示されても、他社へ乗り換える選択肢が現実的に取れないため、言い値を受け入れるしかありません。保守費が高止まりする背景には、こうした構造的な依存があります。
保守費が高くなりやすいのには、ベンダー側の事情もあります。多重下請けの構造や、いざというときに備えた待機要員のコストが、価格に乗ってくるためです。
発注側がこの事情を理解しないまま「高い」と感じるだけでは、交渉の糸口はつかめません。ブラックボックス化を防ぐには、委託していても構成情報・台帳・手順を自社にも残してもらうことを、契約の条件にしておく必要があります。
いつでも他社に引き継げる状態を保つことが、高止まりとロックインへの根本的な対抗策になります。
高止まりとロックインは、情報が委託先に偏るほど進みます。
- 値上げの根拠：作業項目ごとの内訳を示してもらい、高くなっている部分を特定する
- 待機要員の体制：どの作業に、どれだけの人員が割り当てられているかを確認する
ソースコード著作権を盾にした移管拒否
ロックインがこじれると、法的なトラブルに発展することがあります。典型は、ソースコードの著作権がベンダー側に帰属しているため、契約を解除しても成果物を引き渡してもらえないケースです。
独自パッケージから派生した部分の権利を盾に、移管を実質的に拒まれると、発注側は新しいベンダーへ引き継げず、泥沼に陥ります。この原因は、契約時に権利の帰属を曖昧にしておいたことにあります。
この失敗への防衛策は、開発や維持管理の契約段階で、成果物とソースコードの著作権の帰属、契約解除時の引き渡し義務を明文化しておくことです。著作権が自社に帰属していれば、いつでも他社へ維持管理を移せます。
すでにロックイン状態にある場合は、契約書を精査し、解除条件と引き渡しに関する条項を確かめたうえで、必要に応じて法務の助けを借りながら、段階的に脱却を図ることになります。
ベンダーロックインと法的トラブルは、契約時の権利設計の甘さが、何年も後になって表面化する失敗だと言えます。
権利の扱いは、解除の場面で初めて問題になります。
- 移管の対象物：ソースコードや設計書を、どこまで引き渡すかを契約で一覧にする
- 解除時の手続き：解除の通知から引き渡しの完了までの流れを、事前に決めておく
保守移管の難航と乗り換えの隠れコスト
維持管理のベンダーを切り替える「保守移管」には、新規の委託とは異なる固有の難しさとコストが潜んでいます。主なものは、引き継ぎ資料の不足、新旧ベンダーの並行期間に生じる二重コスト、旧ベンダーの非協力的な姿勢です。
これらを甘く見て移管に踏み切ると、想定以上の労力と費用がかかり、移管そのものが失敗に終わることもあります。
引き継ぎ資料不足と並行期間の二重コスト
移管が難航する最大の原因は、引き継ぎ資料の不足です。前のベンダーがドキュメントを十分に残していないと、新しいベンダーはシステムの中身をゼロから解析することになり、その調査だけで多大な工数がかかります。
さらに、移管の過程では新旧両方のベンダーを並行して契約せざるを得ない期間が生じ、保守費が一時的に二重にかかります。この二重コストを見込まずに移管を始めると、予算が想定外に膨らみます。
移管を成功させるには、発注側がこの隠れコストを最初から織り込んだ計画を立てる必要があります。移管を決める前に、引き継ぎ期間の長さ、その間の費用の負担先、現行システムの調査工数の見積もりを整理しておきます。
維持管理を委託する際に、あらかじめ「契約終了時の引き継ぎ協力義務」を契約に盛り込んでおけば、いざ移管するときの資料不足や二重コストを抑えられます。移管の難しさを知ったうえで、平時から備えておくことが肝心です。
移管の手間は、資料と費用の両面に表れます。
- 引き継ぎ資料：設計書や手順書が揃っているか、その更新の状態を移管の前に確かめる
- 並行期間：新旧両方の保守費が重なる期間の長さと、その負担先を決めておく
内製化移行でつまずく知見移転の壁
外部委託から自社内製へ切り替える「内製化移行」も、見た目以上に難しいものです。
委託先からノウハウを引き出して自社に蓄積するには、相応のスキルを持つ人材の採用と、既存ベンダーからの知見の強制的な移転が必要になります。
ところが、委託先にとってノウハウを渡すことは、自社の仕事を失うことにつながります。そのため、積極的な協力を得にくいのが現実です。ここでつまずくと、内製化は中途半端なまま頓挫します。
内製化を目指すなら、どのスキルを持つ人材を、どの単価で確保するかという計画と、既存ベンダーから何を、どの順番で引き継ぐかというロードマップを、現実的に描くことが欠かせません。
まずは判断やルール作りを社内に取り込み、実作業の一部は委託に残すといった段階的な移行が、無理のない進め方です。
保守移管も内製化移行も、知見をいかに自社へ移すかが成否を分けます。資料と協力体制の準備不足が、この移転の壁を高くする失敗の本質です。
内製化の進み具合は、どこまで知見が移ったかで見えてきます。
- 人材の確保：必要なスキルと単価を先に決め、採用の見通しを立てておく
- 委託先の協力：引き継ぎの範囲と期間を契約で決め、協力の前提をそろえておく
責任分界の曖昧さと想定外費用のリスク
クラウドやSaaSを前提にしたモダンなIT環境では、維持管理の失敗の多くが「責任分界の曖昧さ」と、そこから生じる想定外費用に集約されます。
クラウド事業者側の障害、連携SaaSの一方的な仕様変更、OSSの保守といった事象は、ベンダーのコントロールの外で起きがちです。こうした事象の責任と費用を曖昧にしておくと、いざというときに対応が止まり、予期せぬ請求に慌てることになります。
クラウド側障害・SaaS仕様変更の責任の所在
クラウド事業者の大規模障害が起きたとき、「なぜ復旧しないのか」と保守ベンダーに迫っても、原因が事業者側にあれば、ベンダーにできることは限られます。
一方で、連携先のSaaSが旧APIを廃止して自社システムが動かなくなった場合、その改修を誰が・どの費用で行うのかが曖昧だと、対応が宙に浮きます。責任の所在を契約で切り分けていないと、こうした事象が起きるたびに、押し付け合いと対応の遅れが生じます。
この失敗を防ぐには、維持管理の契約で「ベンダーのコントロール外で起きる事象を、誰が・どこまで・どの費用負担で対応するか」を最初に定義しておくことです。
クラウド側障害時は、ベンダーが状況把握と一次連絡を担い、復旧は事業者に委ね、その調査工数は別途精算する、といった整理をしておけば、有事の混乱を避けられます。保証型のSLAを採るなら、コントロール外を原因とする未達はペナルティの対象外とする例外条項も必要です。責任分界点を平時に書き切ることが、障害時の最大の備えになります。
責任の切り分けは、障害が起きてから決めても間に合いにくいものです。
- 契約書の確認：コントロール外の事象への対応範囲と費用負担が、条項で定まっているか
- 調査工数の精算：障害の原因調査にかかった工数を、どの条件で別途精算するか
OSS保守・データ復旧という見落とされる費用
想定外費用の典型が、OSS（オープンソースソフトウェア）の保守と、障害時のデータ復旧にかかるコストです。
OSSは無償で使えるものの、脆弱性対応やバージョン追従は自己責任であり、その保守工数は意外と大きくなります。これを保守費に含めていないと、いざOSSに重大な脆弱性が見つかったときに、想定外の追加費用が発生します。
データ復旧の費用も、平時の保守範囲に入っていなければ、障害時に高額な作業費として別途請求されることがあります。
見落とされがちな費用を防ぐには、契約段階で「何が保守費に含まれ、何が別費用か」を一つずつ確かめておくことです。
保守費の内訳は一般に、定期保守が20〜30%、監視が15〜25%、障害対応が25〜35%を占めます。残りは、問合せが10〜20%、軽微改修が10〜15%、管理報告が5〜10%です（出典：ripla）。
この内訳に照らして、OSS保守やデータ復旧といった項目がどこに位置づけられているかを確認すれば、想定外費用の落とし穴を事前に塞げます。
riplaはフルスクラッチ受託と国内運用保守の立場から、作った後の維持管理まで責任分界点を明確にして伴走し、想定外費用の事故を構造的に防ぐ支援を行っています。
見落とされやすい費用は、保守費の範囲の外に置かれがちです。
- OSSの脆弱性対応：保守費に含めるか、別費用とするかを契約書に明記する
- データ復旧の作業費：平時の保守に含まれるか、障害時に別途請求されるかを確かめる
監視・障害対応体制の不備が生む失敗
維持管理のもう一つの落とし穴は、監視と障害対応の体制が不十分なまま運用を続けてしまうことです。
維持管理は脆弱性対応や更新だけでなく、システムが正常に動き続けているかを見張り、異常が起きたときに素早く復旧する役割も含みます。ここが薄いと、障害の発見が遅れ、復旧にも手間取り、利用部門や顧客に実害が及びます。
監視の抜け漏れで障害発見が遅れる失敗
監視の体制が甘いと、障害が起きていることに自社が気づく前に、利用者からのクレームで初めて発覚する、という事態が起きます。
死活監視や性能監視（監視は保守費内訳の15〜25%が目安、出典：ripla）が適切に設定されていないと、サーバーの停止や処理の遅延を早期に検知できません。とくに、監視対象に外部連携やバッチ処理が含まれていないと、見えないところで処理が止まり、データの不整合が静かに広がります。
この失敗を防ぐには、何を・どの粒度で監視するかをあらかじめ定義し、監視対象に抜け漏れがないかを定期的に見直す必要があります。さらに、監視で異常を検知したら、誰に・どうエスカレーションするかという連絡経路も整えておきます。
維持管理の質は、トラブル後の対応力だけでなく、トラブルの兆候をどれだけ早く拾えるかで決まります。監視の抜け漏れは、後手に回る障害対応の出発点になる失敗です。
監視の抜け漏れを減らすには、対象と連絡の両面を見ることになります。
- 監視対象の一覧：サーバー、外部連携、バッチ処理を、一つずつ洗い出す
- エスカレーション先：異常時に誰へ連絡するかを、担当ごとに決めておく
SLA未設定・未達による復旧遅延の実害
障害対応のスピードをSLA（サービス品質保証）として定めていないと、「いつまでに復旧すべきか」の基準がなく、対応が場当たり的になります。
SLAの実値の例としては、稼働率99.9%（月43分の停止許容）が挙げられます。重大障害なら初報応答15分・復旧目標4時間、通常障害なら応答2時間・復旧8時間という水準です（出典：ripla）。こうした目標が共有されていないと、対応の遅れが常態化し、業務が止まる時間がいたずらに延びます。
注意したいのは、SLAを掲げても実効性が伴わない失敗です。保証型のSLAで未達ペナルティを定めても、原因がうやむやになると適用されず、減額相場も月額の数%程度にとどまることが多いためです。
未達ペナルティは、実損を補うほどの担保にはなりません。そこで、SLAは数値を掲げるだけでなく、達成・未達を客観的に判定できる記録と報告の仕組みとセットで設計する必要があります。
障害対応は保守費内訳の25〜35%を占める最大の業務であり（出典：ripla）、この体制が薄いと、維持管理全体の信頼を損なう失敗に直結します。
SLAは、目標の決め方と未達の扱いの両方で機能します。
- 復旧の目標時間：障害の重さごとに、初報の応答時間と復旧の時間を決める
- 減額の条件：原因の判定と適用の基準を、契約の段階で決めておく
まとめ
ITシステム維持管理の失敗は、突き詰めると、塩漬けと属人化、ベンダーロックインと法的トラブル、引き継ぎ資料不足と二重コストによる保守移管の難航、責任分界の曖昧さが生む想定外費用のいずれかに行き着きます。
これらは、時間をかけてじわじわと進む静かな失敗です。派手な事故として表れない分、最初の契約と運用設計の段階で芽を摘んでおく必要があります。
失敗を避ける鍵は、計画的な定期更新の予算化、ドキュメントと著作権帰属の明確化、引き継ぎ協力義務の契約化にあります。さらに、コントロール外の事象と、OSS保守・データ復旧などの想定外費用について、責任分界を明記しておくことも欠かせません。
年間保守費は開発費の15〜20%が相場とされ（出典：ripla）、その目安を手がかりに内訳まで踏み込んで契約を点検すれば、想定外の費用を減らせます。
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を創業。