「今の開発会社は、頼んだ修正がいつまでも終わらない」「保守費用は毎月払っているのに、何をしてもらっているのか分からない」「担当者が替わるたびに説明し直しになる」。そう感じて、システムのベンダー（開発や保守を頼んでいる会社）を替えたいと考える方は少なくありません。一方で、「替えたら、システムの中身を誰も分からなくなるのでは」「切り替えの途中で業務が止まったら困る」と思うと、なかなか踏み出せないものです。

この記事では、ベンダーを替えるべきかの見分け方から、替える前に確かめる契約と権利、引き継ぎで受け取るものの一覧、今のベンダーが協力してくれないときの進め方、切り替えの手順までを順番に説明します。読み終えるころには、「まず何を確かめ、何を受け取り、いつ今の契約を解約すればよいか」が分かるようにしています。

私たちアストラルコードは、作った人や会社がいなくなったシステムを引き取って動かす仕事をしています。この記事は、システムを引き取るときに必ず確かめる項目をもとに、ベンダー変更で困らないための順番をまとめたものです。

替える前に「替えて解決するか」を確かめる

結論から言うと、ベンダーを替える前に、不満の原因がどこにあるかを先に確かめてください。原因が今のベンダー以外にあると、替えても同じ不満がくり返され、引き継ぎの費用と時間だけが増えるからです。

不満の原因はどちら側か

ベンダーへの不満は、原因で大きく3つに分けられます。

ベンダー側の原因：技術が足りない、人が足りない、約束した期限を守らない、説明をしない。替えることで良くなりやすい原因です。
自社側の原因：頼みたいことが決まっていない、社内の窓口が決まっていない、仕様の変更が多い。替えても、次の会社で同じことが起きます。
体制・相性の原因：保守の範囲や対応時間が契約で決まっていない、連絡の手段が合わない。契約や進め方を決め直せば、替えずに良くなることがあります。

たとえば「対応が遅い」という不満でも、社内から届く依頼の書き方がばらばらで、ベンダーが毎回確認の連絡をしているせいで遅れているなら、原因は自社側です。一方、依頼の内容がはっきりしているのに、返事が1週間ないなら、ベンダー側の原因です。

替えるべきかの目安

次のうち、当てはまるものが多いほど、替える方向で考えてよい状態です。

改善を頼んでも、いつまでに何をするかという計画が返ってこない
約束した期限や品質が、くり返し守られない
担当者が頻繁に替わり、そのたびに説明し直しになる
保守費用や見積もりの根拠を聞いても、内訳が出てこない
使っている技術が古く、今のベンダーでは改修や機能の追加ができないと言われている

1つ目と4つ目は、話し合いで変わることもあります。まずは書面やメールで「何を、いつまでに、いくらで」を聞いてみて、返ってくる答えで判断してください。

替えない選択肢もある

原因が体制や相性にあるなら、次のような方法で、替えずに良くなることがあります。

担当者の交代を頼む：会社としての技術はあっても、担当者との相性が合わないことがあります。
保守の範囲と対応時間を決め直す：「どこまでが月額に含まれるか」「障害のとき何時間以内に返事をするか」を契約に書きます。
料金を見直す：作業の記録を毎月出してもらい、払っている費用に見合うかを確かめます。保守費用の見直し方は「システム保守費用の見直し」でまとめています。

替えるかどうかは、この3つを試したうえで決めても遅くありません。ベンダー変更には、次の会社が今のシステムを調べる費用と、引き継ぎの期間が別にかかるからです。

契約と権利を先に確かめる

替えると決めたら、次の会社を探す前に、今の契約書を読み直してください。ソースコードや資料を次の会社に渡せるかどうかは、契約の書き方で決まるからです。ここを確かめずに進めると、「引き継ぎを頼んだら、ソースコードは渡せないと言われた」ということが起きます。

ソースコードの著作権はどちらにあるか

プログラムの著作権は、契約で決めていなければ、原則として作った側（開発を受けたベンダー）に残ります。お金を払って作ってもらったから自社のもの、とはならない点に注意が必要です。

契約書では、「著作権の帰属」「成果物の権利」といった条を探します。「著作権は委託者（自社）に移る」と書いてあれば、ソースコードを次の会社に渡して直してもらうことができます。ただし、著作権を移す契約でも、改変などに関わる権利（著作権法27条・28条の権利）は、契約に特に書いていないと、移した側（ベンダー）に残るものと推定されます。「27条・28条の権利を含む」と書いてあるかも確かめてください。

著作権がベンダーに残る契約でも、「委託者は自社で使うために自由に複製・改変できる」と書いてあることがあります。書き方によって、次の会社に直してもらえる範囲が変わるので、判断がつかなければ弁護士に確かめてもらうのが確実です。

仕様書などの資料を次の会社に見せてよいか

設計書や仕様書などの資料は、契約の「秘密情報」の決まりに入っていることがあります。秘密情報に当たる資料を、許可なく次の会社に見せると、契約違反になるおそれがあります。

「秘密情報の範囲」「第三者への開示」の条を読み、次の会社に見せてよいか、見せる前に今のベンダーの了解が要るかを確かめます。了解が要るなら、引き継ぎの依頼と一緒に書面で頼みます。

データとアカウントは誰の名義か

システムに入っている顧客や取引のデータは、ふつうは自社のものです。ただ、データが置いてあるサーバーやクラウド、ドメイン、メール配信などの外部サービスが、ベンダーの名義で契約されていることがよくあります。名義がベンダーにあると、解約したとたんにサーバーが止まったり、データを取り出せなくなったりします。

請求書がどこから届いているか、管理画面に自社のアカウントで入れるかを確かめてください。サーバーやドメインの契約先の調べ方は「サーバーの管理会社がわからないときの調べ方」と「ドメインの管理会社が不明なときの調べ方」で説明しています。

今の契約の解約の条件

最後に、解約の条件を確かめます。見るのは次の3つです。

解約の予告期間：「解約の3か月前までに書面で通知」のように決まっていることがあります。切り替えの日から逆算して、いつ通知するかを決めます。
違約金：契約期間の途中で解約すると、残りの期間分を払う決まりがないか確かめます。
引き継ぎ協力の決まり：契約が終わるときに、資料やデータを渡す、説明する、といった協力の決まりがあるか。あれば、それを根拠に引き継ぎを頼めます。

引き継ぎ協力の決まりがない契約も少なくありません。その場合、今のベンダーに引き継ぎの作業をしてもらう義務は契約上ないので、作業を有償で頼むか、引き継ぎの内容と費用を決めた覚書（契約に追加する短い取り決めの書面）を結んで進めます。

今のベンダーに伝える時期

乗り換えることを今のベンダーに伝えるのは、契約を確かめ終わり、次の会社の目処が立ってからにします。先に伝えると、次の会社が決まらないうちに今のベンダーの対応が落ち、どちらの会社にも頼れない期間ができることがあるからです。伝えるときは、解約の予告期間に間に合うよう、書面で伝えます。

次のベンダーの選び方

次のベンダーは、「今のシステムを引き継げるか」で選んでください。新しく作る力が高い会社でも、他社が作ったシステムを読み解いて引き継ぐのが得意とは限らないからです。

先に社内で決めておくこと

候補を探す前に、替える理由、次の会社に頼みたい範囲（保守だけか、機能の追加もか）、予算の上限を社内で決め、決裁する人の了解を取っておきます。ここが決まっていないと、見積もりの比べようがなく、自社側が原因の不満（頼みたいことが決まっていない）を次の会社に持ち込むことになります。

2〜3社に同じ資料で見積もりを頼む

候補は2〜3社に絞り、同じ資料を渡して見積もりを頼みます。渡すのは、システムで何をしているかの説明、使っている技術（分かる範囲で）、サーバーやドメインの契約先、頼みたい範囲です。資料がそろっていると、各社の見積もりを同じ条件で比べられます。

見積もりで比べる点

今の技術を扱えるか：同じ言語や仕組みのシステムを保守した経験があるか。
引き継ぎの進め方を具体的に出せるか：「まず中身を調べて報告し、そのあと引き継ぐ」のように、順番と期間を書面で示せるか。
調べる作業と保守を分けて見積もるか：中身が分からないうちに保守の金額を決め打ちしない会社のほうが、あとで揉めにくくなります。
名義を自社に置く方針か：サーバーやドメインを自分の名義で契約し直す会社だと、同じ問題がくり返されます。
保守の範囲と対応時間を契約に書けるか：今の不満が体制の問題なら、ここを書けない会社に替えても良くなりません。

引き継ぎで受け取るものの一覧

引き継ぎで大事なのは、「受け取った」で終わらせず、次の会社が本当にそれで動かせるかまで確かめることです。ソースコードだけ受け取っても、動かすための設定やログイン情報がなければ、システムを直すことも、サーバーを移すこともできません。

ソースコードと、動かすための設定

受け取るのは、今動いているものと同じ版のソースコードです。開発の途中の版や、古い版を渡されることがあるので、「本番で動いている版か」を聞いて、書面で答えてもらいます。

あわせて、動かすための設定も受け取ります。データベースにつなぐための設定、外部サービスの API キー（サービスを使うための鍵のような文字列）、パスワードの置き場所などです。こうした秘密の情報は、口頭で聞くと記録に残りません。どこに何があるかを書面にしてもらい、受け取ったら自社でパスワードを変えておきます。

サーバー・ドメイン・クラウドのログインと名義

サーバー、ドメイン、クラウド、メール配信や決済などの外部サービスについて、管理画面のログイン情報を受け取ります。名義がベンダーなら、自社の名義に移してもらうか、自社のアカウントを管理者として加えてもらいます。ログイン情報だけ受け取って名義がベンダーのままだと、解約したあとに使えなくなることがあります。

データそのものと、変更の履歴

システムに入っている顧客や取引のデータは、データベースから書き出した形でも受け取ります。サーバーの名義を移す前に手元に一式あれば、移し替えで問題が起きてもデータを失いません。書き出す形式（CSV など）と、項目の意味の説明もあわせてもらいます。

もう1つは、ソースコードの変更の履歴です。Git などのバージョン管理（いつ、誰が、どこを、なぜ直したかを記録する仕組み）を使っていれば、その履歴ごと受け取ります。履歴があると、次の会社が「なぜこう作ってあるのか」を追いやすくなります。

設計書・運用の手順・障害の記録

設計書、日々の運用の手順（バックアップの取り方、毎月の作業など）、過去の障害と直し方の記録を受け取ります。こうした資料がないシステムも少なくありません。資料がないときは、引き継ぎの打ち合わせで画面を見せながら説明してもらい、その様子を録画して残しておくと、あとから何度でも見返せます。

受け取ったら、次の会社に動かせるかを確かめてもらう

受け取ったものがそろったら、今のベンダーとの契約が残っているうちに、次の会社に確かめてもらいます。ソースコードから同じものを組み立てて動かせるか、ログイン情報で管理画面に入れるか、設定が足りているか、です。足りないものが見つかっても、契約が残っていれば、今のベンダーに追加で頼めます。

今のベンダーが協力しない・連絡が取れないとき

今のベンダーが引き継ぎに協力してくれないときや、連絡そのものが取れないときは、「自社で取り戻せるもの」から先に動くのが近道です。ドメイン・サーバー・クラウドは、名義とお金の流れをたどれば、ベンダーを通さずに取り戻せることがあるからです。

依頼は書面やメールで残す

まず、引き継ぎの依頼を書面かメールで送ります。電話や口頭だけだと、頼んだ記録が残りません。依頼には、何を渡してほしいか（上の一覧）、いつまでに渡してほしいか、契約のどの条を根拠に頼むかを書きます。返事がなくても、送った記録はあとで弁護士に相談するときの材料になります。

自社で取り戻せるもの

ドメイン、サーバー、クラウドの契約は、ベンダーではなく、サービスを提供している会社（登録事業者やサーバー会社）とのあいだにあります。契約の名義が自社で、料金を自社が払っているなら、サービスの会社に直接問い合わせて、ログイン情報の再発行を頼めることがあります。

名義がベンダーで、料金もベンダーが払っている場合は、自社だけで取り戻すのは難しくなります。それでも、請求書や振り込みの記録で「自社のために契約されたもの」と示せれば、サービスの会社が相談に乗ってくれることがあります。まずは、どれが誰の名義かを一覧にしてください。

ソースコードが手に入らないときの考え方

ソースコードがどうしても手に入らないときは、作り直しを考えます。今動いている画面と、画面での動き（どこを押すと何が起きるか）をすべて記録し、それを仕様として次の会社に作ってもらいます。

プログラムの書き方そのものは著作権で守られますが、機能やアイデア、処理の考え方は守られません。今のシステムと同じことができるシステムを、別の会社が一から作ることは、原則として問題になりません。ただし、元のソースコードを写したり、画面の文章や画像をそのまま使ったりするのは避けます。

話がこじれたら、弁護士に相談する

ソースコードの引き渡しを拒まれた、違約金の額で折り合わない、といったように話がこじれたら、契約書、注文書、請求書と支払いの記録、送った依頼のメールを持って、IT の契約に詳しい弁護士に相談してください。手元の記録がそろっているほど、相談は早く進みます。

切り替えの進め方

切り替えは、「受け取りと確認が終わってから、今の契約を解約する」順番を守ることがいちばん大事です。先に解約すると、足りないものが見つかったときに、頼める相手がいなくなるからです。

一度に替えるか、段階的に替えるか

ベンダーの替え方には、全部を一度に替える方法と、範囲を分けて少しずつ替える方法があります。

一度に替える：切り替えが1回で済み、2社に払う期間が短くなります。そのかわり、問題が出たときの影響が大きくなります。システムが小さく、機能が少ない場合に向いています。
段階的に替える：たとえば「先に保守だけ次の会社に移し、機能の追加はそのあと」「先にサーバーとドメインの名義を自社に移す」のように分けます。期間は長くなりますが、1回ごとの影響が小さくなります。システムが大きい場合や、業務を止められない場合に向いています。

切り替えの時期

切り替えの日は、繁忙期や月末・年度末の締めを避けて決めます。切り替えの直後は、思わぬ不具合が出やすく、すぐに直せる余裕がある時期のほうが安心です。また、ドメインやサーバーの更新期限が近い場合は、期限の前に名義の移し替えを済ませておきます。

並行期間と、今の契約を解約する時期

次の会社が引き継いだあとも、しばらくは今のベンダーとの契約を残しておきます。この期間を並行期間と呼びます。並行期間のあいだに、次の会社が日々の運用や小さな修正を実際にやってみて、困ることがないかを確かめます。困ることがなくなってから、解約の予告期間に合わせて解約を通知します。

引き継ぎの計画と、切り替え当日の備え

引き継ぎは、計画を書面にしてから始めます。項目ごとに「誰が、何を、いつまでに」と「何ができたら完了とするか」を決めておくと、終わったかどうかで揉めずに済みます。

サーバーを移すなど、切り替えに作業が伴う場合は、次の3つを用意します。

予行（リハーサル）：本番の前に、同じ手順を試しの環境で一度やってみる。
元に戻す手順：うまくいかなかったときに、切り替え前の状態に戻す方法と、戻すと決める条件。
当日の連絡先：今のベンダーと次の会社の両方に、当日すぐ連絡が取れるようにしておく。

よくある質問

開発の途中でもベンダーは替えられますか

替えられます。ただし、作りかけのものを引き継ぐことになるため、完成したシステムを替えるより難しくなります。どこまでできていて、何が残っているかを、今のベンダーに書面で出してもらうところから始めます。作りかけの部分の権利と、途中までの費用の払い方も、契約で確かめてください。

費用と期間はどのくらい増えますか

システムの大きさで大きく変わりますが、次の会社が今のシステムを調べる費用と、引き継ぎ・並行期間の費用が、ふだんの保守費用とは別にかかります。並行期間のあいだは、2社に費用を払うことになる点も見込んでおきます。見積もりは、調べる作業と、引き継いだあとの保守を分けて出してもらうと比べやすくなります。

目安の1つとして、私たちの点検（今のシステムの中身・名義・契約の確かめるべき点を調べて報告書にする作業）は、15万円（税別）・2週間です。並行期間は、毎月の作業がひと通り回るのを確かめられるよう、少なくとも1か月は見ておくと安心です。

次の会社が期待どおりでなかったらどうしますか

この記事の一覧にあるものを自社で持っていれば、また別の会社を選べます。ソースコード、設定、ログイン情報、名義を自社で持っておくことが、次のベンダー変更を楽にする、いちばん確かな方法です。

まとめ

替える前に、不満の原因がベンダー側・自社側・体制や相性のどれかを確かめる。替えない選択肢（担当の交代、保守の範囲の決め直し、料金の見直し）も試す
次の会社を探す前に、契約書で4か所を確かめる。著作権の帰属（27条・28条の権利を含むか）、秘密情報、データとアカウントの名義、解約の条件と引き継ぎ協力
次のベンダーは、今の技術を扱えるか、引き継ぎの進め方を具体的に出せるか、名義を自社に置く方針かで選ぶ。2〜3社に同じ資料で見積もりを頼む
引き継ぎでは、本番と同じ版のソースコードと変更の履歴、動かすための設定、データ、ログイン情報と名義、資料を受け取り、次の会社に動かせるかを確かめてもらう
協力が得られないときは、書面で依頼→名義が自社のものは直接取り戻す→作り直しを考える→こじれたら弁護士に相談、の順で進める
引き継ぎの計画を書面にし、切り替えには予行と元に戻す手順を用意する。今の契約の解約は、受け取りと確認と並行期間が終わってから

まずは、今の契約書を出して「著作権」「秘密情報」「解約」の条を読むところから始めてください。今日すぐにできる最初の一歩です。

ベンダーを替える前に、今のシステムを点検します

「契約書を読んでも、ソースコードを渡してもらえるのか分からない」「サーバーやドメインが誰の名義なのか分からない」「何から手を付ければよいか判断がつかない」。そんなときは、ご相談ください。

アストラルコードでは、点検（15万円（税別）・2週間・報告書つき）をご用意しています。今のシステムのソースコード・サーバー・ドメイン・アカウントがどこにあり、誰の名義かを調べ、契約で確かめるべき点とあわせて、ベンダーを替えるときの順番と危ない所を報告書にしてお渡しします。点検の結果をもとに、引き継ぎや保守をご依頼いただくかどうかは、そのあとで決めていただけます。

「替えるかどうか、まだ決めていない」という段階から、お気軽にご相談ください。