ベンダーが保守から撤退するリスクに備える

委託先が保守サービスを終了する、担当者が退職する、会社そのものがなくなる——保守を受けられなくなる事態は、めったに起きないからこそ備えが後回しにされがちです。事前にできる備え方を整理します。

保守が受けられなくなる場面は複数ある

「ベンダー撤退」と聞くと廃業のような極端な状況を思い浮かべますが、実際にはもっと身近な理由で起こります。開発会社が事業方針を変えて特定分野の保守受託をやめる、担当していたエンジニアが退職して同等のスキルを持つ人が社内にいなくなる、契約更新のタイミングで金額や条件が折り合わず契約が終了する、といったケースです。

どの場合も共通しているのは、「システムは動いているのに、それを面倒見てくれる相手がいなくなる」という状態になることです。

事前に確認・整備しておきたいこと

ソースコードと構成情報の引き渡し条項 ：契約書に、契約終了時にソースコード一式・データベース設計書・インフラの構成情報を発注側に引き渡す義務を明記しておきます。これがないと、契約が終わった瞬間にシステムの中身が「ブラックボックス」になります。

ドキュメントを日頃から最新に保つ ：引き渡し条項があっても、実際のドキュメントが古いままでは意味がありません。仕様変更のたびにドキュメントを更新する運用を、保守契約の一部として組み込んでおくと安心です。

ソースコードの所在を把握する ：開発会社のプライベートなリポジトリで管理されている場合、発注側がいつでも参照・取得できる状態になっているかを確認します。契約終了後に慌てて依頼しても、スムーズに応じてもらえるとは限りません。

属人化していないかを確認する ：特定の担当者しか把握していない仕様や運用ノウハウがないか、委託先側の体制も意識しておきます（自社内の属人化対策については「あの人がいないと直せない」を防ぐ体制づくりで扱っていますが、これは委託先にも当てはまる視点です）。

代替先を探すための準備

技術スタックを一般的なものに保つ ：特殊すぎる技術や、特定の開発会社しか扱えない独自フレームワークに依存していると、代替ベンダーを探すこと自体が難しくなります。標準的な技術基盤を選んでおくことは、将来の選択肢を残すことにもつながります。

引き継ぎにかかる期間を見込んでおく ：新しいベンダーがシステムを理解し、保守を引き受けられる状態になるまでには、規模にもよりますが数週間から数ヶ月かかることもあります。契約終了の通知から実際の移行までの猶予期間を、契約時にあらかじめ確保しておきます。

「今の関係が続く前提」で契約しない

長年付き合いのある委託先ほど、関係が終わることを想定した準備がおろそかになりがちです。しかし、良好な関係だからこそ、いざというときに困らないよう準備しておくことが、双方にとって誠実な付き合い方だとも言えます。撤退リスクへの備えは、委託先を疑うためではなく、システムを長く運用し続けるための保険と捉えるのが現実的です。