引き継ぎ資料の確認リスト

1. 引き継ぎを始める前に決めること

引き継ぎは、前の開発会社との関係が良好なうちに進めるほど円滑に運びます。契約終了の直前に切り出すと、相手側に対応の余力が残っていないことがありますし、心情的にも協力を得にくくなります。まず、いつまでに何を受け取るかの日程と、引き継ぎ作業の費用の扱いを合意してください。契約書に引き継ぎや協力義務の条項がある場合は、その内容を先に読んでおくと、話し合いの前提が整います。

• 契約書に、引き継ぎ・データ返還・協力義務の条項があるか
• 引き継ぎ作業が契約の範囲内か、別途の費用が発生するか
• 受け取り完了の期限と、その後の質問を受け付けてもらえる期間
• 新しい担当者（次の開発会社・社内のエンジニア）が同席できる日程

2. ソースコードと変更の履歴

ソースコードは、圧縮ファイルで一式を受け取るのではなく、変更の履歴が残った状態で、自社が管理するリポジトリに移すのが基本です。履歴があれば、ある機能がいつ、どういう経緯で入ったかをたどれます。履歴のない一式だけを受け取ると、次の担当者が調べる手段を失い、結果として調査の時間が費用として跳ね返ります。受け取った後は、本番で動いているものと内容が一致しているかを必ず確認してください。

• リポジトリが自社の所有するアカウントに移されているか
• 変更の履歴（コミット）が残ったまま移管されているか
• 本番で動いているものと、受け取ったコードが同じ内容か確認したか
• 自動デプロイなどの設定ファイルも含まれているか
• 他社から借りている部品やテンプレートがあれば、その一覧と利用条件

3. アカウントと権限

引き継ぎで最も詰まりやすいのがここです。サーバーやドメイン、外部サービスの契約が開発会社の名義になっていると、移管に手続きと時間がかかり、場合によっては契約を取り直すことになります。ドメインは移管に日数の制限がかかることもあるため、早めに着手してください。すべてのアカウントについて、契約名義・支払い方法・管理者権限の3点を一覧にして確認するのが確実です。

• ドメインの登録名義と、管理画面にログインできるか
• サーバー・クラウドサービスの契約名義と支払い方法
• 外部サービス（決済、メール配信、地図、解析、認証など）の契約名義
• 各アカウントの管理者権限が自社にあり、開発会社側の権限を後で削除できるか
• パスワードや鍵の受け渡しを、記録の残る安全な手段で行ったか

4. 環境と設定値

同じソースコードでも、設定値が分からなければ動きません。接続先、鍵、外部サービスの識別子などがどこに保管され、本番と検証の環境でどう違うかを説明してもらいます。鍵やパスワードの類は、引き継ぎが済んだ後に自社の手で再発行するのが安全です。過去に誰が見られる状態にあったかを、後から把握することはできないためです。再発行の手順自体も、引き継ぎの場で教わっておいてください。

• 本番・検証など環境がいくつあり、それぞれ何に使われているか
• 環境ごとの設定値の一覧（値そのものと、その保管場所）
• 外部サービスの鍵やトークンを、自社で再発行する手順
• 証明書の有効期限と、更新の方法・自動更新の有無

5. データとデータベース

利用者のデータは事業そのものです。現在の保管場所、取り出す方法、そしてバックアップの状態を確認してください。データの構造についても、どのテーブルに何が入っているかという程度の説明を受けておくと、次の担当者の立ち上がりが早くなります。個人情報を含む場合は、引き継ぎに伴って誰がアクセスできる状態になるかを整理し、不要になった側のアクセス権を確実に外すところまでを作業に含めます。

• データベースの種類・置き場所・接続方法
• データの構造の説明（どのテーブルに何が入っているか）
• バックアップの取得頻度・保存期間・復元の手順
• 引き継ぎ後、前の開発会社側に残るデータの控えをどう扱うか（削除の確認を含む）
• 個人情報を含むデータの受け渡し方法と、アクセス権の変更履歴

6. 設計と仕様の説明資料

完璧な設計書を期待すると、実態と合わない書類を受け取ることになりがちです。現実的には、全体の構成が分かる図と、外部との接続の一覧、そして設計上の判断の経緯が分かるメモがあれば、次の担当者は仕事を始められます。分量よりも、書かれている内容が現在の姿と一致していることが重要です。古い資料を渡される場合は、どこが現状と違うかを口頭で補ってもらい、その場でメモを追記してください。

• システム全体の構成図（どのサーバーに何があり、どこと通信するか）
• 外部サービスとの接続の一覧（用途・接続方式・制限）
• 主要な画面と機能の一覧
• 技術選定や設計上の判断について、理由が分かる記録
• 把握している未対応の課題・既知の不具合の一覧

7. 運用の手順

動かし続けるための手順は、書類ではなく開発会社の担当者の頭の中にあることが少なくありません。日常の作業、定期的に行う作業、異常が起きたときの対応を、その場で実演しながら説明してもらうのが確実です。可能であれば、新しい担当者が同席し、説明を聞いた直後に自分の手で一度実行してみてください。手が動かなかった箇所が、そのまま資料に書き足すべき内容になります。

• 変更を本番に反映する手順（誰が、どの操作で、どれくらい時間がかかるか）
• 日次・月次で行っている定型作業があるか
• 監視や通知の設定（どこに何が通知され、誰が見ているか）
• 過去に起きた障害と、そのときの対応の記録
• 利用者からの問い合わせ対応で、システムを操作する場面の手順

8. 引き継ぎ後に必ず行う確認

資料を受け取っただけでは、引き継げたとは言えません。新しい体制で実際に変更を加え、本番に反映できて初めて完了です。文言の修正のような小さな変更を一つ選び、自社側の手だけで最後まで通してみてください。前の開発会社に質問できる期間が残っているうちに実施するのが要点です。ここで詰まった点が、そのまま残っている課題であり、質問できるうちに解消しておくべき項目になります。

• 受け取ったコードを、新しい担当者の環境で動かせたか
• 小さな変更を、自社側の手だけで本番に反映できたか
• バックアップからの復元を、検証環境で一度試したか
• 前の開発会社のアクセス権を、すべての対象から外したか
• 詰まった点を一覧にし、質問できる期間のうちに確認したか

9. 契約と権利の確認

引き継ぎのタイミングは、成果物の権利関係を書面で確かめる機会でもあります。ソースコードや設計資料の権利が自社に移っているか、その移転がすでに完了しているか、他社の部品を使っている箇所に事業の継続を妨げる制約がないかを確認してください。権利が代金の完済時に移る契約であれば、支払いの状況も合わせて確かめます。判断に迷う点があれば、作業を進める前に整理しておくほうが安全です。

• ソースコード・設計資料・デザインデータの権利が自社に帰属しているか
• 権利が移らない部分（他社の部品、汎用の仕組み）が明示されているか
• 第三者の部品の利用条件に、事業の継続を妨げる制約がないか
• 秘密保持の義務が、引き継ぎ後も双方に有効か

10. ご注意

本資料は一般的な情報を整理したものであり、特定の契約や事案についての法的な助言ではありません。契約条項の解釈、成果物の権利の帰属、個人情報の取り扱いについては、契約全体の文言と個別の事情によって結論が変わります。特に、データの返還や削除、第三者の部品の利用条件に関わる判断は慎重を要します。実際の判断にあたっては、弁護士など専門家にご確認ください。