システムの保守開発を進めるとき、成功事例以上に発注企業が学ぶべきなのが「なぜ失敗したのか」というリアルな教訓です。保守開発は、すでに動いているシステムに変更を加え続ける営みであり、しかも他社が作ったシステムを引き継ぐケースが多いため、新規開発とは異なる固有の落とし穴が数多く存在します。ベンダーロックインによる塩漬け、旧ベンダーとの法的紛争、クラウドの責任共有モデルのグレーゾーン、SLAの免責見落とし、そして属人化による保守崩壊。これらは事前に知っていれば確実に避けられた失敗ばかりです。
本記事は、保守開発の失敗・課題・注意点・リスクを、発注企業の視点から生々しく解説する「失敗特化」の記事です。乗り換えられず塩漬けになるベンダーロックイン、著作権・所有権をめぐる旧ベンダーとの法的紛争、クラウドベンダーロックインの責任共有モデルの落とし穴、SLAの免責を見落として返金ゼロになった失敗、そして属人化による保守崩壊と内製化回帰の人事的失敗まで、公的データと一次情報に基づいて掘り下げます。読み終えるころには、自社が同じ轍を踏まないための防衛策が頭に入るはずです。なお、全体像をまだ把握していない方は、まず保守開発の完全ガイドから読むことをおすすめします。
ベンダーロックインによる塩漬けの失敗
保守開発で最も根深く、最も多い失敗が、ベンダーロックインによる塩漬けです。一つのベンダーに保守を任せきりにした結果、システムの中身が社内でも他社でも把握できなくなり、不満があっても乗り換えられず、言い値で保守費を払い続けるしかなくなる。この状態に陥った企業は驚くほど多く、それは公的なデータでも裏づけられています。
公取委98.9%が示すロックインの実態
ベンダーロックインの深刻さを物語るのが、公正取引委員会が2022年2月8日に公表した調査です。これによると、自治体の98.9%が既存ベンダーと再契約しており、そのうち48.3%が「既存ベンダーしかシステムの機能詳細を把握できなかった」ことを再契約の理由に挙げています（出典：公正取引委員会）。つまり、ほぼすべての自治体が既存ベンダーを使い続けざるを得ず、その約半数は「他社では中身が分からないから」という消極的な理由で縛られているのです。
この数字が示すのは、ロックインが「一部の不運な組織の問題」ではなく、構造的に起きる普遍的なリスクだということです。ロックインには、特定企業に依存するコーポレートロックインと、特定技術に縛られるテクノロジーロックインがあります。いずれも、保守を任せきりにし、システムの中身を社内で把握する努力を怠った結果として生じます。失敗を避けるには、「今のベンダーに不満がなくても、いつでも乗り換えられる状態を平時から保つ」という発想が不可欠です。具体的には、ドキュメントの最新化、業務の標準化、特定ベンダー独自技術への過度な依存の回避が、ロックイン予防の三本柱になります。
クラウドベンダーロックインと責任共有モデルの落とし穴
近年、新たに増えているのがクラウドベンダーロックインです。特定のクラウドサービス独自の機能に深く依存してシステムを構築すると、別のクラウドへ移行したくても、作り直しに膨大なコストがかかり、事実上ロックインされます。クラウドは便利な反面、その独自機能に寄りかかりすぎると、保守の自由度を失う落とし穴になります。
さらに見落とされがちなのが、クラウドの責任共有モデルのグレーゾーンです。クラウドでは、インフラ側の責任はクラウド事業者が、その上で動くアプリケーションやデータの責任は利用者側が負う、という線引きがされています。しかし、障害が起きたときに「どちらの責任範囲か」が曖昧なケースがあり、保守ベンダーとクラウド事業者の間で責任の押し付け合いになり、誰も対応しないまま時間だけが過ぎる、という失敗が起こり得ます。クラウドを使う保守では、責任分界点を契約や運用設計で明確にしておかないと、いざというときに対応の空白地帯が生まれます。これは内製・外注の選択とも深く関わるため、メリット・デメリットを整理した関連記事もあわせてご覧ください。
旧ベンダーとの法的紛争という失敗
ロックインを打破しようと保守の乗り換え（移管）を試みると、今度は旧ベンダーとの間に新たな火種が生まれることがあります。それが、ソースコードの著作権や所有権をめぐる法的紛争です。これは保守移管における最も泥沼化しやすい失敗の一つで、知らずに進めると訴訟にまで発展しかねません。
著作権・所有権の争いとADRによる解決
ソースコードの著作権は、契約で明記していない限り、開発したベンダー側に帰属することがあります。発注側は「お金を払って作らせたのだから自社のものだ」と考えがちですが、法的にはそう単純ではありません。移管を進めようとした段階で、旧ベンダーが「ソースコードは当社の著作物であり、第三者への提供はできない」と主張すれば、移管そのものが頓挫します。所有権についても、サーバーやデータ、ドメインの扱いをめぐって認識が食い違い、争いに発展するケースがあります。
こうした紛争が起きたとき、いきなり訴訟に進むと時間も費用も膨大にかかります。そこで、ADR（裁判外紛争解決手続き）を活用し、第三者を交えて話し合いで解決を図る選択肢もあります。ただし、最善はそもそも紛争を起こさないことです。そのためには、システムを発注する時点で、ソースコードの著作権・所有権の帰属、引き継ぎ時の協力義務を契約に明記しておくことが決定的に重要です。保守移管のRFPや契約に何を盛り込むべきかは、要件定義を扱った関連記事もあわせてご覧ください。著作権の所在を契約で押さえておくだけで、この泥沼の失敗は未然に防げます。
引き継ぎ拒否とドキュメント不在の課題
法的紛争にまで至らなくても、旧ベンダーが引き継ぎに非協力的だと、移管は難航します。関係が悪化したベンダーは、ドキュメントの提供を渋ったり、質問への回答を遅らせたりして、引き継ぎを実質的に妨げることがあります。とくに、もともとドキュメントが整備されていないシステムでは、旧ベンダーの協力が得られないと、新ベンダーはソースコードだけを頼りに保守を引き継ぐことになります。
この課題への現実的な対処が、リバースエンジニアリングへの対応力を持つパートナーを選ぶことです。ソースコードからシステムの仕様を読み解き、必要な範囲で設計情報を復元することで、ドキュメントがなくても、旧ベンダーの協力が得られなくても、保守を継続できます。実際に、ドキュメントが存在しないシステムに対してリバースエンジニアリングで伴走し、保守を引き継ぐサービスも提供されています。引き継ぎ拒否やドキュメント不在という失敗のリスクは、移管前の交渉だけに頼らず、技術的にコードから復元できる体制を確保することで、ヘッジできます。
SLAの免責見落としで返金ゼロになる失敗
保守契約の失敗で見落とされがちなのが、SLA（サービス品質保証）の中身、とくに免責条項の読み落としです。「SLAがあるから安心」と思い込み、その保証の実体や免責の範囲を確認しないまま契約すると、いざ障害が起きたときに何の補償も受けられない、という事態に陥ります。
SLAとSLOの違いを知らずに被る損失
SLAの失敗で典型的なのが、SLA（保証）とSLO（努力目標）の違いを理解していないことです。同じ「稼働率99.9%」という表記でも、それが法的な保証なら未達時に減額や返金が受けられますが、努力目標にとどまるなら、未達でも何の補償もありません。実在例で言えば、Amazon S3は稼働率95%未満で100%返金という明確な保証を示す一方、サイボウズは稼働率をSLO（努力目標）と位置づけつつ、規約20条で「連続24時間以上停止しないことを保証する」という形を取っています。同じ「稼働率」でも、提供者によって法的な重みはまったく異なるのです。
この違いを知らずに「稼働率を保証してくれている」と思い込んでいると、障害で大きな損害が出ても、契約上は努力目標だったために返金ゼロ、という失敗に直面します。なお、こうしたSLA条項は民法548条の2が定める定型約款の論点とも関わり、内容によっては一方的に不利な条項が無効と判断される余地もありますが、それを争うのは容易ではありません。契約段階で「保証か努力目標か」「未達時に何があるか」を確認することこそ、最も確実な防衛策です。
免責条項と対応時間帯の見落としによる追加費用
免責条項の見落としも、深刻な失敗を招きます。契約書に「天災・通信障害・第三者の不正アクセスによる損害は免責」といった条項があれば、それらが原因の障害では補償を受けられません。また、対応時間帯の確認漏れも典型です。「平日9時から18時まで」の保守契約なのに、それを把握せず夜間や休日の障害対応を期待していると、いざ夜間に障害が起きたときに「対応範囲外」と言われ、緊急対応を別料金で発注せざるを得なくなります。こうした一言の見落としが、数百万円規模の追加費用につながった事例は実在します。
これらの失敗に共通するのは、「契約書をきちんと読んでいれば防げた」という点です。保守契約は、システムが平穏に動いている間は読み込む動機が湧きにくく、つい雛形のまま締結してしまいがちです。しかし、契約が真価を発揮するのは障害という非常時であり、そのときに初めて「免責だった」「対応時間外だった」と気づいても手遅れです。稼働率・復旧時間・対応時間帯・免責・ペナルティを、契約時に一つずつ確認することが、SLAをめぐる失敗を防ぐ唯一の方法です。
属人化と内製化回帰の失敗
保守開発の失敗は、外注側だけでなく、内製側にも潜んでいます。代表的なのが、保守の属人化と、安易な内製化回帰（インソーシング）の頓挫です。これらは組織や人事の問題と絡むため、技術的な対策だけでは解決できない、根の深い失敗です。
担当者の退職で保守が崩壊する属人化リスク
保守を特定の担当者一人に任せきりにすると、その人がシステムの全てを把握する代わりに、他の誰もシステムを理解できない状態が生まれます。これが属人化です。属人化したシステムは、その担当者が退職したり長期離脱したりした途端、保守が立ち行かなくなります。残されたメンバーはコードを読み解くところから始めねばならず、障害が起きても迅速に対応できません。これは、社内で起きるベンダーロックインとも言える失敗です。
属人化を防ぐには、ドキュメントを整備して保守の知識を個人の頭から組織の資産へ移し、複数人で保守できる体制を作ることが欠かせません。一人に依存した体制は、平時には効率的に見えても、その一人を失ったときのリスクが極めて大きいのです。保守開発の体制を内製で組む際は、この属人化リスクを常に意識し、知識の共有とドキュメント化を仕組みとして回すことが、保守崩壊という失敗を防ぐ前提になります。内製と外注それぞれのメリット・デメリットや判断基準については、関連記事で詳しく解説しています。
内製化回帰（インソーシング）の人事・組織的失敗
外注のロックインに懲りて、「やはり保守は社内に取り戻そう」と内製化回帰（インソーシング）に踏み切る企業もあります。しかし、これも安易に進めると失敗します。保守を担える人材を採用・育成するには時間とコストがかかり、外注で回していた保守をいきなり社内で引き受けると、人手不足や知識不足で品質が落ちます。とくに、外注先からの引き継ぎが不十分なまま内製に切り替えると、社内に十分な知識がないまま障害対応に追われ、現場が疲弊します。
内製化回帰の失敗の本質は、技術ではなく人事・組織の問題にあります。保守人材の採用市場は厳しく、育成にも年単位の時間がかかります。内製化を成功させるには、段階的な移行計画と、外注先からの丁寧な引き継ぎ、そして保守人材を遊ばせない程度の保守ニーズの確保が前提になります。これらを欠いたまま「コスト削減のため」と内製化に飛びつくと、かえって保守の質が落ち、コストも下がらない、という二重の失敗を招きます。内製か外注かは、人事・組織の実態まで踏まえて判断すべき、奥の深いテーマなのです。
まとめ
保守開発の失敗を振り返ると、その大半は「ベンダーロックインによる塩漬け」「乗り換え時の法的紛争・クラウドロックイン」「SLA免責の見落とし」「属人化と内製化回帰の頓挫」の4類型に集約されます。自治体の98.9%が既存ベンダーと再契約していた公正取引委員会のデータは、ロックインが構造的に起きる強力なリスクであることを示しています。乗り換えを試みれば著作権・所有権の法的紛争が待ち、SLAの免責を見落とせば障害時に返金ゼロ、保守を一人に任せれば退職とともに崩壊する。これらはいずれも、事前の備えで確実に避けられる失敗です。
失敗を防ぐ鍵は、平時からのドキュメント最新化と業務・技術の標準化、著作権や責任分界を明記した契約設計、SLAの精読、そして複数人体制による属人化の解消にあります。すでに失敗しかけていても、資産の棚卸しとリバースエンジニアリング、契約の見直しで、被害は最小限に抑えられます。riplaはフルスクラッチ受託と国内伴走を組み合わせ、こうした失敗を構造的に防ぎ、陥った状態からのリカバリーまでを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。