開発会社を乗り換えるときの引き継ぎ手順
システム開発会社を乗り換えるときの引き継ぎ手順を解説。乗り換えを考える典型的な理由、引き継ぐべき資産の一覧、保守契約の解約タイミング、新しい会社への現状調査の依頼方法を紹介します。
今の開発会社に不満があっても、「乗り換えたら動かなくなるのでは」と不安で踏み切れない発注担当者は多いはずです。開発会社の乗り換えは、引き継ぐものを事前に洗い出し、順番を守って進めれば、リスクを抑えて実行できます。この記事では、システムの引き継ぎ手順を、乗り換えを考える典型的な理由、引き継ぐべき資産、保守契約の解約タイミング、新しい会社への現状調査の依頼方法の順に説明します。
開発会社の乗り換えを検討する典型的な理由
乗り換えを考えるきっかけは、おおむね次のどれかです。
乗り換えにはそれなりの費用と時間がかかります。理由が「担当者との相性」など今の会社との話し合いで解決できるものであれば、まず改善を申し入れる方が早いこともあります。乗り換えが本当に必要かを判断する材料として、次の節以降の引き継ぎ作業の重さを見積もっておくとよいでしょう。
引き継ぐべき資産の一覧
乗り換えの成否は、何を引き継ぐかの棚卸しで決まります。次の資産について、「どこにあるか」「誰の名義か」「最新か」を確認してください。
特に注意したいのは、アカウントとドメインの名義です。開発会社の名義になっていると、移管の手続きに今の会社の協力が欠かせません。関係が悪化してからでは協力を得にくいため、乗り換えを伝える前に名義を確認しておきましょう。
ソースコードが手元にない、または権利が開発会社に残っている場合は、引き継ぎそのものが難しくなります。このような状態を防ぐ方法はベンダーロックインを防ぐにはで説明しています。
保守契約の解約タイミングと契約書の確認箇所
今の保守契約をいつ解約するかは、引き継ぎの成否を左右します。新しい会社の準備が整う前に解約すると、障害が起きたときに誰も対応できない期間が生まれます。
基本の順番は次のとおりです。
- 契約書を確認する
- 新しい会社を選び、現状調査を行う
- 引き継ぎ期間を設け、新旧の会社が並行して関わる
- 新しい会社が対応できる状態になってから、今の保守契約を終了する
契約書では、次の箇所を確認してください。
- 契約期間と更新の方法: 自動更新か。更新を止めるための通知の期限はいつか。
- 解約の予告期間: 何か月前までに通知が必要か。途中で解約するときの費用はあるか。
- 納品物と権利の扱い: ソースコードや設計書は納品物に含まれているか。著作権はどちらにあるか。
- 契約終了時の協力: 引き継ぎへの協力義務や、その費用の定めがあるか。
- 秘密保持: 新しい会社に資料を渡すことが契約上問題ないか。
契約書に引き継ぎへの協力が書かれていなくても、有償で協力を依頼することはできます。引き継ぎの説明会や資料の作成を、作業として依頼する形が現実的です。契約の権利関係は著作権とソースコードもあわせて確認してください。
今の会社に乗り換えを伝えるタイミング
乗り換えを伝えるのは、資産の名義と契約書の確認を終え、新しい会社の目処が立ってからにします。早すぎると、対応が消極的になったり、協力を得にくくなったりすることがあります。遅すぎると、更新の通知期限を過ぎて、もう1期分の契約が自動で延びてしまうことがあります。
伝えるときは、感情的な不満ではなく、事業の方針や体制の変化といった理由を簡潔に説明し、引き継ぎへの協力を具体的にお願いします。たとえば「引き継ぎ説明会を2回」「設計書とアカウント情報の提供」のように、依頼する作業を一覧にして渡すと、相手も見積や日程を出しやすくなります。
新しい会社に現状調査を依頼する方法
新しい会社には、いきなり保守や改修を任せるのではなく、まず現状調査を依頼するのがおすすめです。現状調査では、引き継ぐ資産がそろっているか、システムがどのような状態かを確認してもらいます。
現状調査を依頼するときは、次の内容を伝えます。
- 乗り換えの理由と、今後やりたいこと
- 手元にある資料とアカウントの一覧
- システムの利用者数や、止まったときの業務への影響
- 調査の期限と、結果として受け取りたいもの
調査の結果として受け取りたいのは、次のような情報です。
調査は小さな発注として独立させ、その結果を見てから保守や改修を発注すると、新しい会社を見極める機会にもなります。
受託開発の現場から
既存システムの引き継ぎを手がけてきた受託開発の現場の経験から、発注者に役立つ考え方を紹介します。
- 最初にアカウントと資料の所在を棚卸しする: 引き継ぎでは、まずアプリストアの審査用アカウントなどのアカウント情報と、ドキュメントの所在を洗い出すことから始めるのが有効です。そのうえで、前任の会社には最低限、引き継ぎへの協力を求めます。
- 中身が見えない部分は事前に試す: ソースコードが開示されていない部分を引き継ぐ場合は、動きを外から解析して再現できるかを、本格的な作業の前に小さな検証（PoC）で確かめます。
- 作り直しの方が安全なこともある: 別の会社が作ったスクリプトを引き継いで改修する予定が、ソースの解析と棚卸しの結果、既存のスクリプトを前提にしない新規の実装に切り替わった例があります。引き継ぎにはソース解析の工程が必要で、その結果によって最適な進め方が変わります。
- 次に引き継げる形で作る: 引き継ぎを経験した開発会社の提案では、処理の部品化、設定の外出し、書き方のルールの統一、自動テスト、障害対応の手順書を品質として約束し、「技術ドキュメント整備・引継ぎ支援」を見積の独立した項目にしています。
また、乗り換えの時期は、発注者側のキーパーソンの在任期間にも左右されます。システムの経緯を知る担当者が異動や退任をする前に、今の会社とのやり取りを済ませておくと、引き継ぎが進めやすくなります。
まとめ
- 乗り換えの前に、その理由が今の会社との話し合いで解決できないかを確認します。
- ソースコード、データベース、設計書、アカウント、ドメインの所在と名義を棚卸しします。
- 今の保守契約は、新しい会社が対応できる状態になってから終了します。
- 新しい会社には、まず現状調査を小さく依頼し、結果を見てから本格的に任せます。
本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。
新しい開発会社を探す前に、引き継ぎたいシステムと今後やりたいことを整理しておくと、相談がスムーズに進みます。FastProposal の無料AI相談では、案件の内容を整理し、費用の目安を数分で確認できます。