他社システムの保守移管、契約満了日から逆算する進め方とチェックリスト

「今の保守会社との契約を、年度末で終わりにしたいんです」。こういう相談を受けることがあります。保守の移管を考え始めたら、システムの資料を集めるより先に、まず自社の手元にある保守契約書を開いて確認してみてください。

保守の移管でいちばん取り返しがつかないのは、技術の失敗より日付の失敗だと考えているからです。解約の申し入れ期限を1日過ぎただけで、契約がもう1年続いてしまう。新しい保守会社の準備が整う前に、古い契約が切れてしまう。どちらも、技術力ではどうにもなりません。

以前の記事では、開発会社と連絡が取れなくなったシステムの話を書きました。今回はその反対で、今の保守会社とは普通に連絡が取れていて、自分たちの判断で保守先を移したい場合の話です。相手がいるぶん受け取れるものは多いのですが、そのぶん契約と段取りの比重が大きくなります。そこで、この記事では契約満了日を起点に、さかのぼって何をしておくかを順に書いていきます。

決めておきたい3つの日付

保守移管には、混同されやすい日付が3つあります。

ひとつは、旧保守会社との契約が終わる日。次に、新しい保守会社が障害対応の責任を持ち始める日。最後に、旧保守会社のアカウントやアクセス手段がすべて止まる日です。

これを全部同じ日にしてしまう計画をときどき見かけますが、おすすめしません。新しい保守会社の責任開始を契約満了より前に置いて、両社が関わる期間を作る。旧保守会社のアクセス停止は、新しい側で一通り回せることを確かめてから行う。この順番にしておくと、切り替え当日に何か起きても、どちらかに聞ける状態が残ります。

半年ほど前：契約書を読む

契約書は分厚く見えますが、保守移管で見る場所はそれほど多くありません。

期間と更新、解約の申し入れ期限

まず確認するのは、契約期間と自動更新の条件です。IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」の保守運用向けのモデル契約にも、期間満了の一定期間前までにどちらからも申し出がなければ、同じ条件でさらに一定期間続く、という形の条文が置かれています（IPA 情報システム・モデル取引・契約書（第二版））。

実際の保守契約でも、「満了の3か月前までに申し出がなければ1年延長」といった定めは珍しくありません。年度末に終えたいなら、申し入れの期限は年内かもしれない、ということです。最初にこの日をカレンダーに入れてください。ここから先の段取りは、すべてこの日から逆算します。

ソースコードの権利と、納品物に何が含まれているか

次に、開発時の契約で、プログラムの著作権がどちらにあるかと、ソースコードが納品物に含まれているかを見ます。

ここでよく出る心配が「著作権が開発会社に残っているなら、他社に保守を頼めないのでは？」というものです。IPAのモデル契約では、ベンダーに著作権を残す案、汎用的な部分を除いてユーザーに移す案、共有にする案の3つが用意されていて、そのうちベンダーに残す案が基本の形になっています。そのうえで同じ文書の解説には、著作権を持たないユーザーでも、別の会社に保守運用を委託することは可能だという整理が書かれています。開発会社が倒産したときに備えてソースコードや付随する資料を受け取れるようにするには、納品物にソースコードを明記しておく方法があることにも触れています（IPA 情報システム・モデル取引・契約書（第二版））。

もちろん、実際にどうなるかは個別の契約の書き方しだいです。条文の読み方で旧保守会社と意見が分かれそうなら、早めに法律の専門家に相談してください。私たちが言えるのは、「著作権がないから移せない」と最初から諦める必要はない、ということです。

資料やデータの返却

保守を委託していると、旧保守会社の手元にもデータベースのコピーや資料が残っています。IPAの保守運用モデル契約では、預けた資料が不要になったときは、受託側が返却するか委託側の指示どおりに処置する、と定めています。解説では、その処置として消去や廃棄をしたうえで廃棄証明書を渡すことなどが例に挙げられています（IPA 情報システム・モデル取引・契約書（第二版））。手元の契約に同じような条文があるか見ておくと、終わり方の話がしやすくなります。

個人データの取扱い

顧客情報などの個人データが入ったシステムなら、保守会社の切り替えは、個人データの取扱いを委託する相手の切り替えでもあります。

個人情報保護委員会のQ&Aでは、保守を請け負う事業者がサービスの一部としてシステム内の個人データを扱う場合（たとえば個人データを使って不具合を再現・検証する場合）は、個人データの提供にあたるので、本人の同意を得るか、委託に伴う提供として個人情報保護法第25条にもとづき委託先を監督する必要があるとしています（個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」に関するQ&A Q7-55）。ガイドラインは、その監督の中身として、適切な委託先の選定、委託契約の締結、委託先での取扱状況の把握の3つを挙げています（個人情報の保護に関する法律についてのガイドライン（通則編） 3-4-4）。

新しい保守会社を選ぶ時点で、個人データをどう扱うかを確かめ、契約にも書いておく。旧保守会社には、契約終了時に手元のデータを消してもらう。この2つを移管の段取りに最初から組み込んでおくと、後から慌てずに済みます。

4〜5か月前：新しい保守会社に中身を見てもらう

見積もりを比べる前に、候補の保守会社に今のシステムを実際に見てもらう段階を入れてください。画面を見せて説明するだけでは、保守できるかどうかは判断できません。サーバーの構成、言語やフレームワークのバージョン、データベース、外部サービスとのつながり、定期的に動いている処理。このあたりを読み取り権限で確認できれば、見積もりの精度はかなり変わります。

サーバーやクラウドが自社名義の契約なら、自社の判断で調査用のアクセスを用意できます。旧保守会社の名義で借りている環境だと、調査の段階で旧保守会社の協力が必要になります。そうなると、移管を考えていることを伝える時期も早まります。

伝えにくい話ではありますが、隠したまま進めるより、早めに伝えたほうがうまくいくことが多いと私たちは感じています。旧保守会社にとって、引き継ぎへの協力は契約外の追加作業になることがあります。どこまで協力してもらうか、期間と費用を含めて最初に決めておくと、お互いに気持ちよく進められます。

申し入れ期限まで：旧保守会社に依頼するもののチェックリスト

解約の申し入れと一緒に、引き継いでほしいものを一覧で渡します。口頭で「資料一式ください」と頼むと、手元にある設計書だけが届いて終わることがあるからです。

下の表は、私たちが引き継ぎの際に確認している項目を、発注側の方向けに整理したものです。右の列には、旧保守会社から「ありません」と言われたときにどうなるかを書きました。

依頼するもの	「ない」と言われたら
本番で動いているものと同じソースコード一式（変更履歴があればそれごと）	本番サーバーから回収して解析できる。ただし最新版の確認に時間がかかる
データベースの構成と、データの出し方	本番のデータベースから構成を読み取れる
サーバー、ドメイン、DNS、SSL証明書、外部サービスの一覧と、それぞれの名義・更新日	一覧は調査で作れるが、名義の変更や契約の移し替えは自社で動くしかない
定期的に動く処理（夜間・月次・年次のバッチなど）の一覧	サーバーの設定から洗い出せる。年1回しか動かない処理は見落としやすいので要注意
監視の設定と、アラートの通知先	新しい保守会社で監視を作り直す
バックアップの場所と、戻す手順	移管前に新しく取り直す。戻せるかどうかも試す
過去の障害や問い合わせの記録	調査では補えない。担当者に覚えている範囲で聞いておく
対応中の不具合、保留になっている改修依頼	調査では補えない。社内の依頼メールなどから拾う
旧保守会社の手元にあるデータやコピーの扱い	契約終了時の削除と、可能なら廃棄証明書の発行を依頼する

見てほしいのは、右の列が二種類に分かれていることです。ソースコードや設定のように、時間をかければ調査で取り戻せるものがある一方で、名義や契約、過去の経緯のように、技術ではどうやっても取り戻せないものがあります。旧保守会社と話ができるうちに確実に受け取っておきたいのは、後者です。

ないものは「ない」と書いて返してもらってください。ないことがわかっていれば、新しい保守会社はそれを調査の範囲に入れて見積もれます。困るのは、あるのかないのかわからないまま切り替え日を迎えることです。

1〜2か月前：並行期間に一度は本番に触る

新しい保守会社の責任開始から旧契約の満了までの間が、並行期間になります。この期間は、資料を読むだけで終わらせないことが大事です。

私たちが並行期間でやっておきたいと考えているのは、たとえば次のようなことです。小さな修正を1件、新しい保守会社の手で本番に出してみる。月末の締めや請求のように、決まった時期にだけ動く処理を一度は見届ける。監視のアラートを新しい側で受け取る。バックアップから別の環境に戻してみる。

期間の長さは、日数より「どの処理を一周させるか」で決めるのが現実的です。月次処理があるなら月末をまたぐように、年に一度の処理がある時期なら、それを並行期間に含められないか検討してください。

満了日のあと：鍵を替えて、窓口を一本にする

契約が終わったら、最後に必ずやってほしいことがあります。

旧保守会社が知っているパスワード、APIキー、サーバーへの接続用の鍵は、切り替えのタイミングですべて替えます。悪意を疑っているわけではなく、知っている人を減らすのが鍵の管理の基本だからです。旧保守会社の担当者ごとのアカウントがあれば、止めます。

あわせて、障害の通知先、問い合わせの窓口、各種サービスの登録メールアドレスが、旧保守会社のままになっていないかも確かめます。ここが残っていると、更新の案内や障害の通知が、もう関係のない会社に届き続けることになります。旧保守会社には、手元に残っているデータの削除をお願いし、終わったら連絡をもらいます。

おわりに

保守移管は、技術の作業より先に、日付と契約の作業から始まります。申し入れ期限を確かめる、新しい保守会社に中身を見てもらう、取り戻せないものから受け取る。この順番さえ守れば、旧保守会社と円満に、システムを止めずに移すことは十分にできます。

ディレクターズ・リベロでは、他社が開発・保守してきたシステムの調査と引き継ぎ、その後の保守を行っています。「今の契約書のどこを見ればいいかわからない」「移すべきかどうかをまず相談したい」という段階でもかまいません。詳しくはシステム引き継ぎ・保守とサーバー保守のページをご覧いただくか、info@directorz-libero.co.jp までご連絡ください。