SaaSやWebサービス全般の運用保守では、失敗は順調なうちは目立ちませんが、つまずくと事業全体を揺るがします。代表的なのは、責任のなすり合い、ロックインと塩漬け、引き継ぎの破綻、想定外費用の4つです。
なお、全体像をまだ把握していない方は、まずサービス運用保守の完全ガイドからお読みください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
セキュリティ事故時の責任なすり合いと訴訟
運用保守の失敗の中でも、最も深刻なのがセキュリティ事故をめぐる責任のなすり合いです。情報漏えいや不正アクセスが起きたとき、「設定の不備は自社の責任か、それとも運用ベンダーの監視や対応の漏れか」をめぐって、自社と運用ベンダーが対立しやすくなります。
さらに、クラウド事業者との間でも責任の押し付け合いが始まります。対応が後手に回るうちに被害が広がり、最悪の場合は損害賠償をめぐる訴訟に発展します。
この失敗は、技術の問題というより、契約での責任分界の曖昧さが招く人災です。
責任分界の曖昧さが紛争を生む構造
なすり合いが起こる根本原因は、運用保守の契約で「どこまでが誰の責任か」が明確に定められていないことです。
クラウドサービスでは、自社、クラウド事業者、運用ベンダーの各社が関わり、責任共有モデルのもとで管理範囲が分かれます。
この分界を契約書に表で明記していないと、たとえばセキュリティパッチの適用漏れが起きたときにも、「それは運用ベンダーの仕事のはずだ」「いや、自社が指示すべき範囲だ」と解釈が対立します。
事故という非常時に解釈を争っている間に、被害はどんどん広がります。
とくに争点になりやすいのが、免責の範囲と損害賠償の上限です。ベンダー側は契約で責任を限定しようとし、発注側は広く責任を負わせたいと考えるため、事故後は契約書の解釈をめぐって激しく対立します。
契約の段階で対象範囲、含まれない業務、免責を明記していなければ、この対立は避けられません。
セキュリティ事故の責任問題は、起きてから決めるのでは遅く、契約時に「事故が起きたら誰が何をするか」まで取り決めておかなければ防げません。
契約書を見直すときは、紛争の起点になりやすい箇所を項目ごとに確かめておくと、抜けが減ります。
- 契約書の文言：責任の境界が、解釈が割れない言葉で書かれているか
- 事故後の争点：賠償の上限と免責の範囲を、事前に発注側と合意しているか
責任分界表と事故対応手順による防止策
この失敗を防ぐ最大の防衛策は、責任分界表を契約に添付することです。
まず、OSのパッチ適用、脆弱性の監視、アクセス権限の管理、ログの保全、インシデント発生時の通報といった項目を、項目ごとに洗い出します。
そのうえで、それぞれを「自社」「クラウド事業者」「運用ベンダー」のどこが担うのかを表にして決めます。この表があれば、事故時に「これは誰の担当か」を争う余地がなくなり、速やかに対応を始められます。
責任分界を明文化しても、事故そのものを防げるわけではありません。ただし、事故後の混乱と紛争は確実に減らせます。
あわせて、事故が起きたときの対応手順とエスカレーション経路も、事前に決めておく必要があります。誰が一次対応をし、誰に報告し、どの順番で何をするかを手順にしておけば、非常時にも慌てずに動けます。
事故は起こさないことが理想です。とはいえ、万一起きたときに責任を争う時間をなくし、すぐに対応へ入れる体制を整えておくことが、被害を最小限に抑える現実的な備えです。
責任分界とSLAをどう要件化するかは、要件定義やRFPの設計と直結するため、関連記事もあわせてご覧ください。
分界表は、項目と担当を並べて見ると抜けを見つけやすくなります。
- 分界表：契約書に添付し、事故時にすぐ開ける状態にしておく
- 事故対応手順：一次対応、報告、実施の順番を書いた手順書
ベンダーロックインと塩漬けのリスク
運用保守で長期的に見過ごせないのが、ベンダーロックインです。特定のベンダーでしかシステムの中身が分からない状態が続くと、保守費の値上げを受け入れざるを得なくなることもあります。
また、改善したくても他社に頼めず、塩漬けのまま使い続けることもあります。最初は問題なく回っていても、時間がたつにつれて自社の選択肢が狭まり、気づけば「このベンダーから離れられない」状態に陥ります。これがロックインの怖さです。
ブラックボックス化による塩漬け
ロックインの根本原因は、システムのブラックボックス化です。ドキュメントが整備されず、設計の意図や処理の中身が「作ったベンダーにしか分からない」状態になると、他社が引き継ごうとしても調査に膨大な工数がかかります。そのため、現実的に乗り換えができなくなります。
一次データでも、見積もりの変動要因として理解容易性やドキュメント整備度が大きいことが示されています。ドキュメントの欠如は、そのまま乗り換えコストの高騰につながります。こうして塩漬けが固定化していきます。
塩漬けの問題は、サービスが時代遅れになっても改善できず、競争力を失っていくことです。加えて、古いまま放置されたシステムは、セキュリティの面でも脆弱性の温床になります。
「動いているから触らない」という判断は、長期的には大きなリスクを蓄積させます。ロックインによる塩漬けは、目先のコストには表れにくいため、気づいたときには手遅れになりやすい、静かに進むリスクです。
ブラックボックス化は、ドキュメントの有無で早めに気づけます。
- 設計の意図：処理の中身を、作ったベンダー以外の人も説明できるか
- 引き継ぎの見積もり：他社へ移す場合の調査工数を、事前に見積もれるか
ドキュメント義務化と乗り換え検討による脱却
ロックインを防ぐ最も確実な方法は、ドキュメントの整備と引き渡しを契約で義務づけることです。設計書、運用手順書、構成情報、障害対応の記録といったドキュメントを、ベンダーが常に最新の状態で維持し、自社に引き渡す義務を契約に盛り込みます。
そうすれば、いざ乗り換えが必要になったときも、他社がスムーズに引き継げる状態を保てます。ドキュメントの整備は、目先の運用には不要に見えても、将来の選択肢を確保するための投資です。
もう一つの脱却策が、定期的な乗り換え検討です。一次データでは、ベンダー乗り換えに移行コスト300〜500万円をかけても、5年TCOで逆転して安くなるケースがあると報告されています。さらに、既存ベンダーをあえてRFPに参加させ、競争を通じて条件を見直して継続するケースも30〜40%あります。
乗り換えを実際にするかどうかは別として、定期的に他社と比べる姿勢そのものが、現行ベンダーに緊張感を与え、塩漬けや不当な値上げを防ぎます。「離れられる状態」を保つことが、ロックインへの最大の抑止力です。
内製と外部委託の判断や、こうしたリスクを踏まえた選択については『サービス運用保守のメリット・デメリット・効果と判断基準について』もあわせてご覧ください。
ドキュメントと乗り換えの比較は、契約の見直しの時点でセットで確かめると進めやすくなります。
- 引き渡しの義務：最新の状態を保った文書を、自社に渡す条項があるか
- 乗り換えの比較：移行コストを5年TCOで見て、現行の継続費と並べる
引き継ぎの失敗とキーマン退職のリスク
ベンダーを乗り換える、あるいは内製から外部委託へ切り替えるとき、最大の難所になるのが引き継ぎです。引き継ぎがうまくいかないと、移行直後に障害が頻発し、サービス品質が大きく落ちます。
とくに、運用を支えてきたキーマンの突然の退職や、現行ベンダーの非協力に直面すると、引き継ぎは一気に破綻します。引き継ぎの失敗は、運用保守の移行で最も現実的かつ深刻なリスクの一つです。
キーマン退職・現行ベンダー非協力という罠
引き継ぎが破綻する典型が、システムを熟知したキーマンが途中で退職してしまうケースです。属人化した知識が頭の中にしかない状態で、その人が抜けると、誰も全体像を把握できなくなり、移行が立ち往生します。
また、乗り換えられる側の現行ベンダーが、引き継ぎに非協力的になることもあります。失注したベンダーが後任への情報提供を渋ったり、ドキュメントの引き渡しを遅らせたりすると、新ベンダーは手探りでの運用を強いられ、障害リスクが跳ね上がります。
これらの罠を避けるには、引き継ぎを計画的かつ段階的に進めることが欠かせません。一次データでは、引き継ぎ期間を約8週間（2か月）確保し、委託先のPM0.25人月とリードエンジニア1.0人月を充てる形が示されています。また、現行の担当者には週2日の協力を求める体制が、一つの目安とされています。
具体的には、新旧の体制を並走させながら段階的に移管します。こうすれば、キーマンの知識を新ベンダーへ移せ、不測の事態にも備えられます。引き継ぎは「期間」と「体制」を事前に設計することが、成否を分けます。
キーマンの退職に備えるには、知識が誰に残っているかを引き継ぎの前に確かめておくと、影響を小さくできます。
- 属人化の解消：頭の中にある知識を、文書や手順に移しておく
- 協力の取り決め：現行ベンダーの協力期間と担当者の稼働量を、契約に書き込む
契約満了6か月前からの計画的な見直し
引き継ぎの失敗を防ぐのは、計画的なスケジュールです。
契約切れの直前になって慌てて乗り換えようとすると、引き継ぎ期間を十分に取れず、移行直後の障害頻発という典型的な失敗に陥ります。一方で、時間に余裕があれば、現行ベンダーの協力も得やすく、引き継ぎを冷静に設計できます。
計画的な見直しは、現行ベンダーの非協力への対策としても有効です。早い段階で見直しを始め、現行ベンダーにも条件改善の機会としてRFPへの参加を打診すれば、敵対的にならずに引き継ぎを進められます。
引き継ぎへの協力を契約条項として事前に定めておくことも、非協力のリスクを下げる手段です。とくに、引き継ぎの失敗は「時間がない」状況で起こりやすいものです。
見直しの時期は、契約満了日から逆算して決めると、着手が遅れにくくなります。
- 着手時期：契約満了の6か月前
- 協力条項：引き継ぎへの協力を、契約条項として定めるかどうか
一次データでは、ベンダー選定や見直しの全体を4〜6か月かけて進めるのが目安とされています。そのため、契約満了の半年前から動き出す習慣をつけることが、移行リスクを下げる最もシンプルで効果的な防衛策になります。
想定外費用と運用コスト見積もりの失敗
運用保守でしばしば起こるのが、当初の見積もりに含まれていなかった想定外費用に苦しむ失敗です。保守費はソフトウェア全体のコストの40〜80%（平均60%）を占めるため、ここの見積もりを誤ると、事業の収益性に直接響きます。
「月額いくら」という表面的な金額だけで判断すると、後から追加費用が次々と発生し、結果的に当初の想定を超えるコストを負担することになります。
OSS保守・データ復旧という隠れ費用
想定外費用の代表が、OSS（オープンソースソフトウェア）のサポート切れへの対応と、障害時のデータ復旧です。一方で、無償のOSSを使っていても、サポートが切れたときの移行や脆弱性への対応には、まとまった費用がかかります。
これを通常の保守費に含めていないと、ある日突然「OSSのバージョンアップ対応で別途費用が必要です」と言われ、困惑することになります。また、データ復旧では、大規模障害でデータが破損したときの復旧作業が、月額の範囲外として高額な追加請求になりがちです。
隠れ費用を防ぐには、契約段階で「含まれない業務」を明確にし、それらが発生した場合の費用の扱いを定めておく必要があります。
また、ハードウェア保守を含む契約では、交換後の故障部品の所有権が保守会社に帰属するといった細かな取り決めもあります。こうした条項も見落とさないことが大切です。想定外費用は、あらかじめ想定しておけば想定外ではなくなるものです。
隠れ費用は、契約書のどこを見れば分かるのかを押さえておくと、見落としにくくなります。
- 費用の区分：別途見積もりとするか、年間の枠内に収めるか
- ハードウェア保守：交換後の故障部品の扱いを、契約書で確かめる
具体的には、OSS保守、データ復旧、大規模改修といった非定常的な作業が、この取り決めの対象です。
生産性過信による赤字という見積もり失敗
見積もりの失敗は、発注側だけでなく受注側でも起こり、それが結果的に発注側のリスクにもなります。
一次データでは、生産性を過信して当初見積もりの1/3で受注し、数千万円の赤字を出した事例が報告されています。また、パッケージのカスタマイズで効率20%を想定していたのに、実際は全体で5%しか効率化できなかった事例もあります。
受注側が無理な見積もりで赤字を抱えると、品質の低下や撤退といった形で、最終的に発注側のサービスにしわ寄せが来ます。
こうした失敗の背景には、システムの理解度を過信し、改修の難易度を見誤ることがあります。とくにパッケージのカスタマイズは、パラメータ設定、アドオン、モディファイの順に保守が難しくなります。また、モディファイ（本体改造）まで踏み込むと、保守の困難さと費用が跳ね上がります。
発注側は、極端に安い見積もりを「お得」と受け取る前に、「なぜこの金額で可能なのか」を問うことが大切です。その見積もりが妥当かを見極めることは、めぐりめぐって自社のサービスを守ることにつながります。
riplaはフルスクラッチ受託と国内運用保守の立場から、無理のない現実的な見積もりと、想定外費用の事前定義を重視しています。
受注側の金額の根拠は、作業量の内訳を聞くと確かめやすくなります。
- 見積もりの根拠：生産性の前提と、改修の対象範囲が示されているか
- 改修の深さ：設定、追加機能、本体改造のどこまでを金額に含むか
まとめ
サービス運用保守の失敗は、セキュリティ事故時の責任なすり合いと訴訟、ベンダーロックインによる塩漬け、引き継ぎの破綻、想定外費用の4つに集約されます。
運用保守の失敗は、いずれも契約と要件定義の段階での詰めの甘さが原因です。
責任分界を表で明文化すれば事故時の紛争を抑えられ、ドキュメントを義務化すればロックインを避けられ、契約満了の6か月前から計画的に動けば引き継ぎの破綻を防げます。
また、想定外費用を事前に定義すれば、追加請求の不意打ちを避けられます。これらは技術力よりも、契約と体制の設計で左右される、防げる人災です。
運用保守の失敗は、起きてから対処するのでは手遅れになりがちです。だからこそ、契約段階で責任分界、含まれない業務、免責を明記し、ドキュメントの引き渡しを義務化して、引き継ぎと想定外費用に備えることが、何よりの保険になります。
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を創業。