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