システム開発会社の乗り換え前に確認したい引き継ぎの要点
システム開発会社を乗り換えるとき、後から困りやすいのは、新しい会社探しよりも「今の会社から何を受け取れるのか」が曖昧なまま話を進めてしまうことです。この記事では、乗り換えを決める前後に確認したい契約、ソースコード、各種アカウント、資料、運用の5点を整理します。私たちJustFit編集部が、一般的な考え方としてまとめました。
なお、契約や権利の解釈は個別の契約書の文面によって変わります。法的な判断が必要な場面では、弁護士など専門家への確認が欠かせません。この記事は、確認する項目を洗い出すための整理としてお読みください。
乗り換えを考える前に、不満の中身を言葉にする
乗り換えを検討するきっかけは、会社によってさまざまです。よくあるのは次のようなものでしょう。
- 納期が守られず、リリースが何度も延びている
- 要望を伝えても意図が正しく伝わらず、完成物とのズレが続いている
- 担当者が変わるたびに話が最初からやり直しになる
- 不具合の修正や機能追加への対応が遅い
- 事業の方向性が変わり、今の会社の得意分野と合わなくなった
ここで大切なのは、不満の原因が「会社の相性や体制」なのか、「進め方や要件の決め方」なのかを切り分けることです。後者の場合、会社だけを替えても、同じ種類のズレが再び起きる可能性があります。
遅延や認識違いの原因は、発注側の決め方にも、開発側の進め方にもあり得ます。原因の整理には、システム開発が遅延する原因と、発注時にできる防ぎ方が参考になります。また、すでに外注でうまくいかなかった経験がある場合は、システム開発の外注で失敗後のやり直し｜再依頼の見直し点も合わせて確認すると、見直す観点が揃います。
乗り換えが妥当かどうかは、「何が問題で、新しい会社なら何が変わると見込めるのか」を一文で説明できるかが目安になります。説明できない場合は、引き継ぎの準備と並行して、原因の整理から始めるほうが安全です。
引き継ぎの前に確認したい5つのもの
乗り換えでは、新しい会社に「これまでのシステムを渡す」作業が発生します。その前に、渡せる状態かどうかを確かめておく必要があります。確認したいのは、次の5つです。
1. 契約書：権利の帰属と、解約・引き継ぎの条件
最初に見るのは、現在の開発契約書です。確認したい点は次のとおりです。
- 成果物（ソースコードや設計書）の著作権が、誰に帰属すると書かれているか
- 契約期間、更新の条件、解約の申し入れ期限（何か月前までに通知が必要か）
- 保守・運用契約が、開発契約と別になっているか
- 解約時や契約終了時に、成果物や資料を引き渡す義務が書かれているか
- 秘密保持の範囲と、再委託（開発会社が別の会社に作業を任せること）の扱い
著作権については、著作権法の規定が関わります。著作権を譲渡する契約で、翻案などに関わる権利（著作権法第27条・第28条の権利）が譲渡の対象として特に書かれていない場合、その権利は譲渡した側に残っているものと推定される、という定めがあります（著作権法第61条第2項）。契約書の文言が曖昧だと、引き継ぎ後の改修で想定外の制約が出る可能性があるということです。
また、開発会社が独自に持つ共通部品やライブラリが、成果物の一部に組み込まれているケースもあります。その部品が引き渡しの対象なのか、利用許諾にとどまるのかは、契約によって異なります。このあたりは、システム開発の著作権帰属は誰のもの？契約前の確認点で詳しく整理しています。
2. ソースコードと、その変更履歴
次に、ソースコードがどこにあり、誰が管理しているかを確認します。
- ソースコードを保管するリポジトリ（Gitなどのバージョン管理の保管場所）が、開発会社の管理下にあるのか、発注側が管理者権限を持っているのか
- 変更履歴（いつ、誰が、何を変えたか）が残っているか
- 最新の本番環境の内容と、手元のソースコードが一致しているか
- 外部のオープンソース部品を使っている場合、そのライセンスの一覧があるか
特に「最新の本番環境と一致しているか」は見落とされがちです。緊急対応で本番環境だけに修正を加え、ソースコードには反映されていないケースもあります。引き継ぎ後に新しい会社が最初に困るのは、この差分であることが少なくありません。
3. サーバーや外部サービスのアカウント
システムは、ソースコードだけでは動きません。動かすための土台や外部サービスの契約情報も、引き継ぎの対象です。
- サーバーやクラウドの契約が、誰の名義になっているか
- ドメイン、DNS、SSL証明書の管理者が誰か
- 決済、メール配信、地図、認証などの外部サービスのアカウントが、誰の名義か
- 各サービスのAPIキーや接続情報が、どこに保管されているか
- 管理者権限を持つ人が、発注側に1人以上いるか
ここで特に確認したいのは「名義」です。開発会社の名義でアカウントが作られていると、契約終了とともに利用できなくなったり、名義の移管に時間がかかったりすることがあります。乗り換えを正式に伝える前に、発注側の名義で管理できているものと、そうでないものを一覧にしておくと、後の段取りが組みやすくなります。
4. 設計書や仕様などの資料
新しい会社がシステムを理解するための資料が、どこまで残っているかも確認します。
- 機能一覧、画面一覧、画面遷移図
- データベースの設計書（テーブルの定義やER図）
- 外部システムとの連携仕様（APIの仕様書）
- テストの仕様書や、テスト結果の記録
- 運用手順書、障害時の連絡フロー
- これまでの課題管理や、要望・変更依頼の履歴
資料が古い、あるいはそもそも存在しない場合もあります。その場合は、ソースコードやデータベースの現状から資料を起こす作業が、新しい会社の最初の仕事になります。この作業には時間がかかるため、乗り換え先に事前に伝えておくことが、後々の認識違いを防ぐことにつながります。
5. 運用中のデータと、停止できない時間帯
すでに利用者がいるシステムでは、運用面の確認が欠かせません。
- 本番データのバックアップが、定期的に取られているか。復元の手順は確認済みか
- 個人情報や取引情報など、取り扱いに注意が必要なデータが何か
- 切り替え時にシステムを止められる時間帯があるか
- 監視や障害通知の仕組みが、どの会社の契約・設定になっているか
- 現行の保守体制が終わってから、新しい保守が始まるまでの空白期間が生じないか
運用のなかでも「空白期間」は見落とされがちです。現行の会社との契約終了日と、新しい会社の保守開始日を重ねるか、少なくとも隙間が生まれないように設計しておくと、切り替え期間中の障害対応が宙に浮くのを避けられます。
今の会社に、どの順番で何を伝えるか
資料や権利の確認ができたら、現行の開発会社とのやり取りに進みます。ここで意識したいのは、乗り換えの意向を伝える順番です。
先に事実を確認し、その後で意向を伝える
乗り換えを先に告げてしまうと、その後の資料提供や引き継ぎ作業への協力度合いが、状況によって変わる可能性があります。そのため、私たちは次の順で進めることを一般的な考え方として挙げます。
- 契約書の内容を、社内で（必要なら専門家と）確認する
- 発注側の名義で管理できているアカウントや資料を洗い出す
- 足りないものを、通常のやり取りの延長で依頼できる範囲で集める
- 引き継ぎの範囲と期間について、現行の会社と書面で合意する
- 新しい会社との契約開始日と、現行契約の終了日を調整する
もちろん、現行の会社との関係を損なわないことが前提です。感情的な不満を主題にせず、「事業方針の変更」「体制の見直し」など、事実に沿った理由を落ち着いて伝えるほうが、引き継ぎもスムーズに進みやすくなります。
引き継ぎの範囲を、あいまいにしない
引き継ぎの範囲は、あらかじめ書面に残しておきます。たとえば次のような項目です。
- 渡してもらう資料とソースコードの一覧、渡す期限
- 新しい会社からの質問に答えてもらう期間と、その窓口
- 本番環境の切り替え当日の立ち会いの有無
- 引き継ぎにかかる作業が、現行契約の範囲に入るか、別の対応になるか
引き継ぎ作業そのものが、現行の契約に含まれていない場合もあります。その場合は、別途の取り決めが必要です。金額や条件の話は、現行の会社と個別に確認してください。
乗り換え先の会社に、事前に確かめたいこと
引き継ぎ元の準備と並行して、乗り換え先の会社にも確認しておきたいことがあります。
既存のシステムを、どう読み解くか
他社が作ったシステムを引き継ぐとき、最初に必要なのは、現状のコードや構成を読み解く作業です。そのうえで、次のどれを選ぶかを判断します。
- そのまま引き継いで、改修・保守を続ける
- 一部を直しながら使い続ける
- 作り直す
この判断を、読み解く前に断言する会社には注意が必要です。コードの状態を見てから、改修と作り直しのそれぞれで何が起きるかを説明してくれる会社のほうが、判断材料が揃いやすいと私たちは考えます。
近年はAIを使って既存コードを読み解く開発も広がっています。AIが生成したコードを含め、引き継ぎと改修で何を確認すべきかは、AI生成コードの保守は可能か｜引き継ぎと改修の確認点で整理しています。引き継ぎ後のコードの安全面については、AI生成コードのセキュリティ｜確認点と人の役割も参考になります。
責任の範囲を、どこで区切るか
引き継ぎ直後の不具合は、「前の会社の作り込みが原因」なのか「新しい会社の改修が原因」なのかが、分かりにくくなりがちです。そのため、次の点を事前に合意しておくと安心です。
- 引き継ぎ時点の状態を、どう記録しておくか（動作確認の結果、既知の不具合の一覧など）
- 引き継ぎ後に見つかった不具合を、どの範囲で新しい会社が対応するか
- 保守に含まれる範囲と、別の依頼になる範囲の線引き
会社選びの視点を、あらためて整理する
乗り換え先を選ぶ段階では、会社の実績や得意分野だけでなく、進め方や体制も比べる必要があります。選ぶ視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点に、AIを活用する受託開発会社に依頼する場合の確認点はAI受託開発に依頼する前に確かめたい6つのことにまとめています。
乗り換え後に、同じことを繰り返さないために
引き継ぎが終わっても、これで終わりではありません。前回と同じ種類の問題を繰り返さないために、発注側が持っておきたいものがあります。
発注側の窓口と判断者を決める
要望が伝わらない、判断が遅い、といった問題は、開発会社だけでなく、発注側の体制にも関わります。誰が要件を決め、誰が最終判断をするのかが曖昧だと、会社が替わっても同じ停滞が起きやすくなります。発注側で意思決定を担う役割については、発注側のプロダクトオーナーとは｜役割と判断のしかたで整理しています。
言葉だけで決めず、実物で確かめる
認識のズレの多くは、文章や口頭での要件のやり取りから生まれます。設計書や仕様書だけで進めると、完成してから「思っていたものと違う」と気づくことがあります。実際に動くものを見ながら確認する進め方は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで解説しています。
納品後の運用まで見据える
乗り換えの背景に「納品後の対応が合わなかった」という理由がある場合は、保守や改善の進め方を、契約前に確認しておくことが重要です。システムを納品後も改善し続ける考え方は、システムは納品後の改善で育てる｜新規事業の考え方が参考になります。
新規事業は、既存システムと切り離す選択肢もある
乗り換え先を探す理由が、新しい事業のためのシステムが必要になったことである場合、既存システムの引き継ぎと、新規事業の開発を同じ案件にしないほうがよいこともあります。既存システムの改修と、新規事業の立ち上げでは、求められる速度や進め方が異なるためです。切り離して考える理由と進め方は、新規事業は既存システムと切り離して作る理由と進め方にまとめています。
まとめ
システム開発会社の乗り換えで、引き継ぎの前に確認しておきたい要点を整理します。
- 乗り換えの理由が、会社の体制の問題なのか、要件や進め方の問題なのかを切り分ける
- 契約書で、著作権の帰属、解約条件、引き渡しの義務、保守契約の扱いを確認する
- ソースコードの保管場所と、本番環境との一致を確認する
- サーバー、ドメイン、外部サービスのアカウント名義と管理者権限を洗い出す
- 設計書や運用手順書などの資料が、どこまで残っているかを確認する
- バックアップ、データの取り扱い、切り替え時の停止時間、保守の空白期間を確認する
- 現行の会社には、事実を確認してから意向を伝え、引き継ぎの範囲を書面で残す
- 乗り換え先には、既存システムの読み解き方と、責任範囲の区切り方を聞く
乗り換えは、会社を替えること自体が目的ではなく、事業を前に進めるための手段です。引き継ぎの前に、権利、環境、資料、運用の状態を把握しておくほど、乗り換え先の選択肢も判断しやすくなります。
私たちJustFitは、「先に作って、後から決める」という考え方で、約1ヶ月で実際に動くプロトタイプを先に開発し、実物を見てから契約を判断していただける受託開発サービスです。仕様が固まっていない段階や、過去に開発の外注で失敗した経験がある段階でのご相談も受け付けています。サービスの全体像はJustFitのサービス紹介でご覧いただけます。