開発会社を変更したい。システムの移管は可能か、最初に何を確認すればよいか

開発会社と連絡がつかなくなった場合でもシステムは移管できます。ただし、今のコードを引き継いで改修を継続できるか（継続改修）、新規に開発し直す必要があるか（再構築）は、発注者の側に何があるかによって変化します。次の会社を選定する前に、自社にあるものを確認してください。

何を移管するのかを先に決定する

「別の会社に移管する」には保守・運用の移管と開発の移管があり、どちらを移管するかによって、自社が用意するものと移管の重さが異なります。

移管するもの	次の会社が行うこと	自社が用意するもの
保守・運用	現状のまま運用を継続する。障害の対応、夜間や月末に自動で稼働する定期処理の監視、証明書やライブラリの更新、データの手修正	権限と名義、データ、本番への反映の手順、定期処理の一覧、過去の障害の記録
開発	機能の追加や改修を継続する	保守・運用に必要なものすべてと、本番と同じソースコード、それを別の環境で再現できる状態

保守・運用だけを移管するならコードを隅々まで読解できる必要はなく、稼働を継続するための権限と手順が自社にあれば十分です。開発を移管するならコードを読解して改修できる状態まで必要になり、費用と期間の差もこの点に起因します。

どちらを移管するか未定の場合は保守・運用を先に移管し、開発の継続は次の会社が中身を把握した後に依頼します。この順序ならシステムが停止する危険を低減できます。

最初に確認する順番

ドメインとメールは1日目に確認します。

AWSのようなクラウドや、決済、メール配信のような外部サービスのアカウントの多くはメールアドレスにひも付いていて、パスワード再設定の案内もそのメールアドレスに送信されます。そのメールアドレスが旧社のドメインのものだったり、旧社の社員個人のものだったりすると、パスワードを再設定できる人がその人に限定されます。契約上の所有者が自社でも実際の操作はその人にしかできません。

逆に自社のドメインでも登録者が旧社なら、旧社が更新を中止するかドメインを放棄した時点でメールが停止し、すべてのアカウントの再設定が不可能になります。

確認は次の順で実施します。

1. ドメインの登録者と、レジストラのアカウントに自社がログインできるか
2. 各アカウントに登録されているメールアドレスが、自社で受信できるものか
3. クラウドの管理者アカウントと請求の名義
4. 外部サービスの契約と名義
5. ソースコードとデータ
6. 稼働方法と運用の情報

1〜4は、旧社との関係が終了した時点でシステムが停止するかどうかを左右する項目です。5〜6は移管後に改修できるかどうかを左右する項目で、1〜4の後に確認します。

システムを停止させないための権限と名義

この節の権限と名義は保守・運用と開発のどちらを移管する場合にも必要です。

確認するもの	確認の方法	無いと発生すること
ドメイン	ドメインを登録・更新するサービス（レジストラ）のアカウントに自社がログインできるか。レジストラの管理画面にある登録者情報が自社になっているか。更新期限と自動更新の設定	更新期限と猶予期間を経過すると、URLとメールが利用できなくなる。失効後に第三者が取得すると、回復できないことがある
DNS	ドメイン名とサーバの対応の設定をどこで管理しているか。レジストラとは別のサービスのことが多い	ドメインだけ移管しても、DNSの設定内容を移管しなければ、サイトとメールが停止する
クラウドの管理者アカウント	AWSならルートユーザー、GCPなら組織の管理者に、自社の担当者がログインできるか。登録メールアドレスと請求先のカード。旧社の組織や請求代行の配下に含まれていないか	旧社が契約を停止するか支払いが中断した時点で、システムが停止する。次の会社は中身も確認できない
外部サービス	決済、メール配信、SMS、地図、ログイン、監視などの一覧と、それぞれの契約者名義と支払い方法	名義が旧社なら、契約の再締結と再審査が必要になる。決済はカードの種類によって審査に1か月ほどかかることがあり、定期課金は再作成が必要になることがある
アプリストア	AppleとGoogleの開発者アカウントが誰の名義か	名義が旧社のままだと、自社からはアプリの更新を公開できなくなる。新規に再公開すると別のアプリ扱いになり、既存の利用者に再インストールを依頼することになる
SSL証明書	自動更新か、手動更新か。手動なら有効期限はいつか	有効期限を経過すると、ブラウザに警告が表示されてサイトを閲覧できなくなる。有効期間の上限は、認証局とブラウザの事業者で構成するCA/Browser Forumの決議で段階的に短縮され、2029年3月以降は47日になる。手動更新ほど期限切れが発生しやすい

一覧が無くても会社の請求書とカード明細を確認すれば、誰も利用を記憶していない外部サービスも含めて、毎月課金されているサービスをほぼ特定できます。ただし、旧社が一括で契約して保守費に含めているサービスは明細に記載されないので、旧社への支払いの内訳も確認します。

外部サービスの支払いに旧社のカードや前任者個人のカードが利用されていると、そのカードが停止した後、支払いの猶予期間を経過した時点で外部サービスごと本番が停止します。

全部が自社の名義だった例のほうが少数です。どれか1つは旧社か個人の名義になっている前提で、引き継ぎを実施するほうが安全です。

稼働を継続するためのものと改修するためのもの

確認するもの	必要な場面	確認の方法	無いと発生すること
データ	両方	本番データベースのバックアップがどこにあり、どの頻度で取得されているか。実際に復元できたことがあるか	顧客情報や取引履歴は再作成できない
本番への反映の手順	両方	誰が、どこから、どの手順で本番に反映しているか	手順が前任者のパソコンの中にしかないと、障害の修正も本番に反映できない
設定値と秘密情報	両方	環境ごとの設定値、パスワード、APIキーがどこに保管されているか	コードには含まれず、受領したコードだけでは稼働しない
定期処理	両方	毎晩・毎月・年度末に自動で稼働する処理の一覧と、それぞれの実行基盤	月末の請求や年度末の集計が、移管後の最初の締めで初めて停止し、その時点で発覚する
過去の障害と手作業	両方	障害の記録、手作業で実施している定期作業、変更すると危険な箇所	同じ障害を同じように再発させる。誰も実施しなくなった手作業が、後で問題になる
ソースコード	開発	リポジトリ（GitHubなど）の所有者権限を自社が保有しているか。フロント、サーバ、スマホアプリ、インフラの定義、定期処理の小規模なスクリプトなど、リポジトリが全部でいくつあるか	稼働中の画面を参照しながら再構築するほかない。費用が最も高額になる
本番と同じコードか	開発	本番で稼働しているものが、受領したコードのどの時点のものと一致するか	納品後に本番だけが修正されていると、受領したコードで本番を上書きした時点で、修正したはずの不具合が再発する
仕様書と設計書	開発	仕様書、設計書、課題管理の記録。なぜその設計にしたかの説明	変更してよい箇所と危険な箇所を区別できない。改修のたびに別の箇所で不具合が発生する

ソースコードはzipで受領するより、リポジトリごと所有者を移管してもらうほうが確実です。リポジトリの所有者を自社のアカウントへ変更するGitHubのリポジトリ移管なら、公式の説明どおり変更の履歴、課題、レビューの記録がそのまま保持されます。いつ・なぜその変更をしたかが後から改修するときの手がかりになりますが、zipにはこの履歴が含まれません。

1つのはずのリポジトリが実は複数あり、管理画面、夜間に稼働する小規模なスクリプト、インフラの定義が別の場所で管理されていたという例は珍しくありません。主要なリポジトリだけを受領すると、システムの一部が欠落したまま移管することになります。

バックアップは存在を確認するだけでなく実際に別の環境へ復元し、データに欠落が無いことまで確認します。復元できることを一度も検証していないバックアップは、いざという時に復元できないことがあります。

復元した環境から本番の外部サービス経由で通知や請求を送信しないよう注意します。データと設定をそのまま複製すると、試験用の環境から本物の顧客へのメール送信や本物のカードへの請求をしてしまうことがあります。

ソースコードを受領しても、それだけでは稼働しない場合が多いです。よくある欠落の型は次のとおりです。1つの引き継ぎで複数が同時に発生する例は珍しくありません。

• 本番とコードの不一致: 納品後に本番だけが修正されていて、受領したコードと一致しない
• 設定と秘密情報が無い: 環境ごとの設定値やキーを旧社しか保有しておらず、受領したコードを稼働させられない
• リポジトリの不足: 管理画面、定期処理のスクリプト、インフラの定義が別の場所にあり、提供されていない
• 旧社独自のライブラリに依存している: 旧社の社内ライブラリや独自の仕組みが無いと、ビルドも起動もできない

移管しても旧社のアクセスが存続する場所

名義や所有者を自社に移管しても、次の場所では旧社のアクセスが存続することがあります。

• リポジトリの設定: 外部への通知（Webhook）、本番に反映するための鍵、自動処理の秘密情報は、リポジトリを移管しても設定として保持される。
  旧社のサーバや鍵に接続されたままのことがある
• リポジトリの利用者: 移管すると、移管元の旧社がコラボレーターとして自動で追加される。
  移管前から参加している旧社の担当者も削除されない
• クラウドの利用者: 旧社の担当者ごとの利用者アカウントやアクセスキーは、管理者を変更しても削除されない
• 監視とアラート: 障害の通知が旧社や前任者の個人メールに送信される設定のままだと、障害が発生しても誰も把握できない
• 個人名義のキー: 前任者の個人アカウントで発行したAPIキーを外部サービスとの接続に利用していると、その人がアカウントを削除した時点で接続が不可能になる
• コードの履歴に含まれる秘密情報: 以前コードへ記載したパスワードやキーは、後で削除しても変更の履歴に保持される

旧社のアクセスを停止する際は、順序に注意します。旧来のパスワードやキーを先に無効にすると、それを利用している処理が稼働しなくなるためです。旧来のものはどこで利用されているかを特定し、新規のものへ置換して稼働を確認してから無効にします。引き継ぎ期間中は旧社がまだ作業することもあるため、無効にする時期は旧社の作業の完了後にします。

契約書で確認する箇所

契約書では著作権の帰属先、納品物の範囲、保守契約の解約の条件を確認します。

著作権の帰属

契約に「成果物の著作権は発注者に帰属する」といった条項があれば、引き渡しを求める材料の1つになります。

ただし、何を提供する義務があるかは納品物として何を定めたかで確定します。条項が無い、または著作権が開発会社に帰属したままの契約なら、引き渡しには開発会社の協力が必要です。

譲渡の条項があっても、「著作権を譲渡する」とだけ記載されている場合は注意が必要です。著作権法第61条第2項は次の権利が譲渡の対象として契約に明記されていなければ、譲渡した側の開発会社に留保されたものと推定すると定めています。対象は改変に関する第27条の翻案権などと、改変したものを利用する第28条の権利です。次の会社に画面の追加や不具合の修正を依頼することも、ソースコードの改変に該当します。そのため「著作権を譲渡する」とだけ記載された契約では、受領したソースコードを他社が改修して利用できるかに疑義が生じます。「著作権法第27条及び第28条の権利を含む」という一文が含まれているかを確認します。

著作者人格権はそもそも譲渡できません。そのため、「著作者人格権を行使しない」という条項がセットで含まれているかも確認します。

開発会社が以前から保有していたプログラムや汎用のライブラリは、譲渡の対象から除外されていることが多くあります。それが無いとシステムが稼働しない場合は、利用の継続が認められるかも確認します。

納品物の範囲

ソースコード、設計書、手順書が納品物として記載されていなければ、旧社に提供する義務はありません。納品されていないものは、契約上は自社のものでも自社にはありません。過去の改修ごとに別の契約や注文書があると、改修分の納品物が分散していることもあります。

保守契約の解約の条件

解約の予告期間、解約時に引き継ぎへ協力する義務の有無、その費用を確認します。協力の義務の記載が無い場合、引き継ぎへの協力は旧社の好意に期待するしかありません。

契約書に権利が記載されていても、旧社が実際に作業して提供するとは限りません。好意に期待した依頼は後回しにされやすいため、引き継ぎの作業は有償で発注するか、何をいつまでに提供するかを覚書にしたうえで依頼するほうが確実です。

旧社が協力しないとき

連絡がつかない場合や引き渡しを拒否された場合に、自社だけで回復できる範囲は限られます。

対象	旧社の協力なしで可能なこと	限界
ドメイン	ほぼ無い。登録者が旧社なら、名義の移管には原則として旧社の承認が必要	レジストラが契約書の提示だけで名義を移管することは、基本的にない
リポジトリ	GitHubのサポートへの相談	所有権を移管してもらえる保証はない。所有者である旧社による移管が原則
クラウド	登録メールアドレスが自社のドメインなら、AWSではそのメールボックスを復旧させてパスワードを再設定できる。不可能ならAWSサポートに相談する	AWSは登録情報を代理で変更しない。登録メールアドレスが旧社のドメインだと、回復はかなり困難

どれも回復できなければ旧社と交渉し、応じてもらえない場合は弁護士に相談して、契約上の権利として引き渡しを請求します。交渉と請求の材料になる契約書と支払いの記録は、旧社と協議する前に自社で用意しておきます。

ソースコードがどうしても入手できない場合でも、稼働中の画面、入出力されるデータ、実際の動作を外部から調査すれば、再構築のための仕様を作成できます。ただし大規模な作業になり、継続改修より費用も期間も必要です。

今の会社に通知する前に

移管の話を提示すると旧社の協力が消極的になることがあります。旧社への通知の前に、自社の担当者が自分で次のことを確認しておきます。

• ドメイン、クラウド、外部サービスの管理画面に、自社が受信できるメールアドレスでログインできるか
• それぞれの請求が誰の名義で、どの手段で決済されているか
• 本番データのバックアップがどこにあり、自社で取得できるか

旧社の名義になっているものがあれば、旧社への通知の前に名義の移管方法を調査しておきます。ドメインには登録者の変更があり、JPドメインなら移転申請もあります。アプリストアにはAppleとGoogleのアプリ移管の仕組みがあります。どの手続きも名義を保有する旧社による開始か承認が必要で、自社は受領する側です。上記のAppleとGoogleの説明では、アプリ移管なら評価やレビューも保持され、利用者は引き続き更新を利用できます。ただし、プッシュ通知の鍵など一部の設定は移管の対象外で、移管後に再設定します。

ソースコードの引き渡し、手順書の作成、引き継ぎの打ち合わせは、多くの場合、旧社への通知の後で実施できます。

次の会社への相談は旧社への通知の前に実施しても支障ありません。自社にある資料を提示して移管の段取りと費用の見積を依頼しておけば、次の手段を用意したうえで旧社と協議できます。ただし、旧社の了承なしに本番環境へ他社を参加させることや、移管先が確定する前に今の保守契約を停止することは避けます。関係が悪化した勢いで先に解約すると、権限もコードも受領できないまま関係だけが終了します。

パスワードやキーはメールや表計算ファイルで送信せず、パスワード管理のサービスで共有するか、次の会社の担当者を各サービスの利用者として追加して提供します。

継続改修と再構築の判断

開発を移管するときは受領したシステムの処遇を選択します。選択肢は次のとおりです。

選択肢	内容
継続改修	受領したコードを引き継ぎ、そのコードに機能の追加や修正を継続する
部分刷新	問題のある機能から順に新規のものへ置換し、残りは今のコードのまま利用する
再構築	今のコードは利用せず、業務の仕様を調査し直して新規に開発する

保守・運用だけを移管するなら、受領したコードを改修しないので、この選択は不要です。稼働を継続できるかを確認すれば十分です。

どれを選択するかは受領したコードの状態で判定します。

問い	継続改修	部分刷新	再構築
受領したコードから本番と同じものを再現できるか	再現できる	再現できない箇所が一部にある	再現できない。不足しているプログラムが旧社にしかない
利用している言語やライブラリのサポートは継続しているか	継続している	一部のライブラリだけ終了している	中心となる言語やフレームワークのサポートが終了していて、更新先への移行が再構築と同等
1か所を改修すると、別の箇所で不具合が発生するか	発生しない。改修の範囲を把握できる	特定の機能の周辺だけ不具合が発生しやすい	どこを改修しても不具合が発生する。テストも無い
業務の方法とシステムの設計は一致しているか	一致している	一部の業務だけ変化した	業務がかなり変化し、改修より新規開発のほうが短期間

すべての問いが左の列なら自社は継続改修を選択します。中央の列を含み右の列を含まない場合は、該当する機能だけを刷新する部分刷新を選択します。右の列が1つでもある場合は再構築を検討しますが、その問題が一部の機能に限られるなら部分刷新で対応できます。

全面的な再構築は最後の手段です。仕様書に記載されていない業務のルールが長年の改修で今のシステムに内包されていて、再構築にはそれを特定して実装する費用が必要になります。特定できなかったものはそのまま不具合になります。再構築の間も今のシステムの保守は停止できません。

部分刷新では新旧を同時に稼働させ、機能ごとに新規のほうへ移行します。一度に全部を移行するより、失敗した際の切り戻しが容易です。

引き継ぎの対象はシステムの種類によっても変化します。

種類	引き継ぎの対象	交渉の相手
SaaSをそのまま利用している	契約、設定、データ。システムそのものは移管されない	SaaSの提供元。旧社は設定の代行をしていただけのことが多い
パッケージを改造している	改造した部分。パッケージ本体の利用は、提供元との契約の範囲内	パッケージの提供元と旧社の両方
個別に開発した	コードを含めて全部。ただし契約の著作権の条項が前提	旧社

移管にかかる費用

移管の費用は元のシステムの開発にかかった人月を基準にすると概算できます。調査も再構築も、作業の量はコード、画面、業務の規則の量に比例して増加し、それらの量は元の開発人月におおむね比例するためです。業務の規則が画面の数に対して複雑なシステムや、外部との連携が多いシステムでは、目安を上回ります。

元の開発人月が不明な場合は、当時の開発費を人月単価で除算すると推定できます。

項目	目安	増減する条件
現状の調査	元の開発人月の5〜10%。期間も規模に比例する	資料が完備され旧社が協力するなら下限、どちらも無ければ上限
並行期間	旧社と次の会社の両方の保守費を1〜2か月分	月次の処理と本番への反映を次の会社が経験できなければ延長
再構築	同じ機能のまま作り直すなら元の開発人月とほぼ同じ	旧社の協力、同時に修正する問題、セキュリティ上の問題の量で増加

たとえば元の開発が12人月なら、現状の調査は0.6〜1.2人月です。

今のシステムを同じ機能のまま再構築するだけなら、元の開発とほぼ同じ規模になります。次の条件に該当するほど費用は増加します。

• 旧社の協力が無く、仕様を画面やデータから特定し直す必要がある
• 業務の変化への対応や、今のシステムの不具合の修正を同時に実施する
• セキュリティ上の問題が多く、認証の方式やデータの保管方法も再設計する

次の会社には調査、並行期間、移管後の保守に分割した見積を提出してもらいます。解約の予告期間中に旧社へ発生する保守費と引き継ぎの費用も同じ表に記載すると、移管全体の費用を把握できます。

生成AIでコードの解析は容易になったが専門性は依然として必要

設計書が無く前任者もいないコードを解析する作業は、以前は移管の費用の大きな部分を占めていました。誰も説明できないコードを、引き継ぐ側のエンジニアが一から読解するしかなかったためです。

LLM（大規模言語モデル）を利用すると、この作業の所要時間は以前よりかなり短縮されました。利用方法には次のようなものがあります。

• コード全体を解析させて、構成と処理の流れを記述させる
• 画面や機能ごとに、どのコードが関係しているかを対応づけさせる
• 今の動作を固定するテストを先に記述させる

コードの規模や記述の仕方によっては、全体像を把握するまでの日数が以前の数分の一になる場合もあります。

ただし、作業が容易になっても、引き継ぐ側の専門性が不要になったわけではありません。むしろ、LLMの出力を検証する能力の差が、移管の結果の差として顕在化しやすくなりました。

LLMの説明にはもっともらしい誤りが含まれます。誤りを発見するには説明の元になったコードを読解し、実際の動作と比較できる能力が必要です。説明の元になったファイルを必ず提示させ、不明な箇所は不明と記載させたうえで、そのファイルの中身と実際の動作を人が確認してください。

どこを質問すべきかの判断にも専門性が必要です。LLMは質問された範囲には回答しますが、変更すると危険な箇所や、本番だけで発生する問題のように、経験が無いと質問できない事項は回答の対象になりません。解析の速度が向上したぶん、作業時間に占める検証と判断の比重が増大しています。

コードをどれだけ解析しても、次のものは判明しません。

• ドメイン、クラウド、外部サービスの権限
• パスワードやAPIキーの実物
• 本番のデータ
• なぜその設計にしたかという業務上の理由と、過去にどんな障害が発生したか
• 本番で稼働しているものが、受領したコードのどの時点のものか

解析の時間は短縮されても、これらを取得する時間は変化しません。移管の成否を左右する要素は、コードの可読性から、権限、データ、稼働方法が自社にあるかどうかと、LLMの出力を検証できる次の会社の能力へ変化しました。

次の会社を選定する基準

移管先の選定では新規開発の実績より、他社が開発したシステムを引き継いで保守した実績を重視します。新規開発は自社で設計を決定できますが、引き継ぎでは他社の設計と不足した資料を前提に作業するため、必要な能力が異なります。

基準	確認の方法	重視する理由
言語とフレームワーク	今のシステムが利用している言語やフレームワークで、稼働中のシステムを保守した実績があるか。サポートが終了した旧式のバージョンにも対応できるか	同じ言語でも最新のバージョンの経験しか無いと、旧式のコードの読解と更新に余分な時間が必要になる
システムの種類	業務システム、EC、スマホアプリ、データの集計基盤など、同種のシステムを担当した実績	業務システムなら業務の理解、スマホアプリならストアの審査と配信、ECなら決済の運用のように、種類ごとに固有の知識が必要
引き継ぎの経験	他社のコードを引き継いだ事例で、何が不足していて、どう補完したか	回答が具体的なら、引き継ぎで発生する問題を経験している。一般論しか回答できない会社は、問題が発生してから対応することになる
品質の担保	テストの有無、コードレビュー、CI/CD（ビルド、テスト、本番への反映の自動化）、作業の記録の残し方	引き継いだ直後は変更すると危険な箇所が不明なので、テストとレビューが無いと改修のたびに不具合が発生する
開発の進め方	仕様を先に確定してから開発するか、短い単位で確認しながら開発するか。担当者が固定か、窓口と実装の担当が別か	発注側の体制と進め方が合致しないと、連絡の遅さや認識の違いという、旧社と同じ不満が再発する

確認には過去に作成した調査の報告書を、サンプルとして提示してもらうのが有効です。報告の詳細さで、調査の段階からどこまで把握できる会社かを判定できます。

継続改修か部分刷新を選択する場合は、今の言語の経験が基準になります。再構築を選択するなら今の言語の経験は不要で、新規の構成を提案し、今のシステムから業務の仕様を特定できる能力を重視します。どちらを選択するかが未定の段階では、両方を評価できる会社に現状の調査を依頼します。

次の会社への最初の発注は現状の調査にする

次の会社には最初から改修や再構築を発注せず、現状を調査して報告してもらう作業だけを、期間を限定して発注します。調査の前は継続改修か再構築かを誰も判定できず、その段階で提出された改修の見積は当てになりません。報告には次の項目を含めてもらいます。

• 権限、名義、外部サービス、定期処理の一覧と、それぞれの状態
• 受領したコードから本番と同じものを再現できたか
• 旧式のライブラリ、セキュリティ上の脆弱性、テストの有無
• 継続改修、部分刷新、再構築のいずれが適切かの推奨と理由
• 移管の段取り、旧社に依頼する作業、並行稼働の期間、費用

調査の費用は元の開発人月を基準に概算できますが、実際の見積は次の要素でも変化します。調査の依頼前にこれらを共有しておくと、見積の精度が向上します。

• 移管するのは保守・運用か、開発もか
• リポジトリ、サーバ、外部サービスがそれぞれいくつあるか
• 画面や機能の数と、利用者の数
• 設計書、手順書、障害の記録がどのくらい存在するか
• 旧社が引き継ぎに協力するか
• 停止できない業務を処理するか

並行期間と引き継ぎの完了条件

旧社と次の会社の両方が関与する並行期間の長さは、次の会社が月次の処理と本番への反映をそれぞれ1回以上自力で完了するまでにします。月に1度しか稼働しない処理は、1か月以内の引き継ぎでは一度も確認しないまま終了するためです。年度末にしか稼働しない処理があるなら、その時期も考慮します。

停止できない業務を処理するシステムでは、新旧を一定期間並行して稼働させ、結果が一致するのを確認してから移行します。移行した後もすぐ切り戻しできる状態をしばらく維持します。

引き継ぎの完了は次の会社が旧社に一度も質問せずに、次のことを実行できた時点です。

• 小規模な修正を追加して、本番に反映する
• 月次の処理を実行する
• 障害の通知を受信して、原因を調査する
• バックアップから別の環境に復元する

引き継いだ直後は新規の機能の追加を先行させず、最初の1か月ほどはこの状態の達成を優先してください。

よくある誤解

著作権が自社にあればソースコードは旧社から確実に受領できる

旧社が提供する義務があるのは、納品物として契約で定めたものだけです。著作権が自社に帰属していても、納品物に含まれないソースコードや設計書の提供は旧社の協力次第です。提供してほしいものは、有償の発注か覚書の対象に含めます。

ソースコードを受領すれば次の会社はすぐに改修できる

改修に必要なのはコードだけではありません。次の4つのいずれかが欠如していると、改修を開始する前に、それを補完する作業が必要になります。

• 本番と一致する時点のコード
• 別の環境で再現する手順
• 各サービスの権限
• 設計の理由

名義を自社に移管すれば旧社はアクセスできなくなる

名義を変更しても、旧社の担当者の利用者アカウント、APIキー、自動実行の設定は存続します。旧社のアクセスを遮断するには、それぞれを特定して1つずつ無効にする必要があります。

先に解約を通知してから引き継ぎを依頼すればよい

解約を先に通知すると権限とコードを受領できないまま関係が終了する危険があります。解約の通知は名義と権限の確認、移管先の確定、引き継ぎの依頼の後にします。

再構築するなら今のシステムを調査する必要はない

新規のシステムの仕様は今のシステムの画面、データ、動作から特定します。調査を省略すると文書に記載されていない業務の処理が新規のシステムから欠落します。

生成AIを利用すれば引き継ぎの費用はほとんど不要になる

生成AIを利用して削減できるのは、コードの解析にかかる費用です。権限とデータの取得、LLMの出力の検証、並行期間の保守にかかる費用は削減できません。

会社を変更しなくてよい場合

会社を変更しても、不満の原因によっては解消しません。

修正の遅さや費用の高さの原因がシステムの設計そのものにあるなら、次の会社でも修正は遅いままで、費用も高額なままです。その場合は会社の変更より、設計の見直しが必要です。連絡の遅さや進捗の見えにくさの原因が、要望の共有方法や体制にあるなら、今の会社と協議して改善することもあります。

移管の前に、不満の原因が会社、システムの設計、発注側の進め方のどれにあるのかを区別して検討します。原因が会社なら移管を、設計なら会社を変更しない設計の見直しを、進め方なら社内の体制の見直しを優先します。どれに該当するかが判別できない場合は、現状の調査の結果で特定できます。