結論から書くと、前任の担当者や開発会社と連絡が取れる状態での引継ぎでは、受け取るものの一覧を打ち合わせの前に渡し、受け取った後の確認までを、前任がいるうちに終える ことが大切です。前任が離れた後では、聞けば済んだことを調査で掘り起こすことになります。
この記事では、前任者がいない場合の調査と、開発会社と連絡が取れない場合の権限の回復は扱いません。それぞれ「前任者がいない PHP システムの引継ぎ調査、最初の1週間でやること」と「開発会社と連絡が取れなくなった PHP システムを引き継ぐ手順」で説明しています。
受け取るものは、打ち合わせの前に一覧で渡す
「何か資料はありますか」と聞くだけでは、前任がその場で思い出せないものが漏れるおそれがあります。先に一覧を渡し、項目ごとに「渡せる」「無い」「分からない」を書いてもらいます。「無い」と分かれば、作るか、後で調べて補うかを決められます。
ただし前任が開発会社なら、一覧を渡す前に、引継ぎの作業が今の契約に含まれるかを確かめます。 資料づくりや打ち合わせが契約の範囲外なら、別に見積が出ることがあります。
アカウント・ソースコード・環境で受け取るもの
アカウントと権限
共有のアカウントより、担当者用のアカウントを作ってもらい、パスワードは受け手が設定する ほうが、前任のアカウントを後で止められて安全です。
| 受け取るもの | なぜ要るか | 無いときは |
|---|---|---|
| ドメインと DNS（ドメインとサーバーを結ぶ設定）の管理画面、名義 | 期限が切れるとサイトもメールも止まる | 前任がいるうちに名義変更を進める |
| サーバーとデータベースの管理画面、FTP・SSH（ファイル転送やサーバー操作の接続） | 障害の確認、ファイルの取得 | 契約者の権限で追加してもらう |
| システムの管理画面の管理者 | 利用者や設定の変更 | 新しく作ってもらう |
| 外部サービス（決済、メール配信、地図）の管理画面、契約名義と支払い方法、API キー（利用のための鍵） | 切れると一部の機能だけが止まる | 設定ファイルのキーと請求書から一覧にする |
| ソースコードの置き場（リポジトリ） | 変更の履歴をたどれる | 本番のファイル一式を最初の版にする |
ソースコード
| 受け取るもの | なぜ要るか | 無いときは |
|---|---|---|
| 本番で動いているソースコード | 違うコードを直しても本番に反映されない | 本番サーバーから取得する |
| 本番に出ている版と、反映の手順 | 未反映の変更を見分け、同じ方法で修正を出せる | 本番と突き合わせる（後述） |
composer.lock（依存パッケージのバージョンの記録） |
誰がセットアップしても同じバージョンが入る（Composer 公式） | 本番の vendor（Composer が入れたライブラリ）を丸ごと保管する |
環境
| 受け取るもの | なぜ要るか | 無いときは |
|---|---|---|
| PHP・データベース・Web サーバーのバージョン | 検証環境を本番に揃える | 自分で確かめる（下記） |
設定ファイル（.env、.htaccess、php.ini） |
本番にしかない設定を把握し、移転でも同じ状態を作る | 本番から取得する（.env の値はメモやチャットに写さない） |
| 定期処理（cron＝決まった時刻に処理を動かす仕組み） | 止まっても気づきにくい | crontab -l とサーバーの管理画面で確かめる |
PHP は php -v と php -m（拡張の一覧）で確かめます（PHP マニュアル）。ただし、コマンドラインの PHP は、Web の PHP と設定ファイル（PHP マニュアル）やバージョンが違うことがあります。Web 側は phpinfo()（PHP の設定を表示する関数）で確かめ、使ったファイルはすぐ消します。環境変数まで表示されるためです（PHP マニュアル）。
crontab -l は実行したユーザーの分しか表示しません（POSIX）。Laravel 8 以降なら、公式ドキュメントに載っている php artisan schedule:list の出力も受け取ります（Laravel 公式）。
文書・契約・進行中の作業で受け取るもの
文書
| 受け取るもの | なぜ要るか | 無いときは |
|---|---|---|
| 仕様書、画面の一覧 | 正しい動きの基準になる | 主な画面を操作してもらい、録画する |
| データベースの定義 | データの修正や集計に要る | 分かりにくい項目だけ聞き取る |
| 運用の手順（日次・月次・年次） | 担当者がいないと止まる作業が分かる | 1年間の作業を月ごとに挙げてもらう |
| バックアップの有無と保存先、戻したことがあるか | 壊れたときに戻せるかが決まる | 引継ぎの前に自分で1回取っておく |
| 障害の記録、未対応の不具合 | 前からの問題かを区別できる | 分かっている範囲で書き出してもらう |
契約と権利
| 受け取るもの | なぜ要るか | 無いときは |
|---|---|---|
| 開発・保守の契約書 | 改修や他社への依頼ができるかが決まる | 発注書や請求書を集め、前任に確かめる |
| ライブラリなどのライセンス（有償の購入記録を含む） | 利用や改変の条件が分かる | 購入の記録と composer licenses（ライセンスの一覧。Composer 公式）で確かめる |
ソースコードの著作権は、契約で移す定めが無ければ、原則として作った側に残ります（著作権法第15条・第17条・第61条）。どちらにあるかは契約書の条項で確かめ、読み方の判断は法律の専門家に相談してください。
進行中の作業と課題
| 受け取るもの | なぜ要るか | 無いときは |
|---|---|---|
| 作業中の改修と、本番に出たか | 途中の変更を知らずに出さない | 記録が無ければ、途中の作業を一覧にしてもらう |
| 近く期限を迎えるもの（ドメイン、サーバー、SSL 証明書） | 引継ぎの直後に期限が来ることがある | 管理画面で更新日を一覧にする |
| 利用者との約束、前任が気にしていた箇所 | 忘れられる約束や、壊れやすい処理が分かる | 打ち合わせで聞き取る |
パスワードや API キーの受け渡し方
- メールやチャットの本文に平文で書かない。 暗号化したファイルと、それを開くパスワードを同じ経路で送るのも避けます。
- 共有が要るものは、会社で管理するパスワード管理ツールで渡す。
.envの値も、この方法で別に受け取ります。 - 受け取った後に変える。 その前に、使っている設定ファイルや定期処理を確かめます。
ただし Laravel の APP_KEY は、ほかのパスワードと同じ感覚で作り直さないでください。そのまま変えると、ログイン中の利用者はすべてログアウトされ、前の鍵で暗号化したデータも復号できなくなります。Laravel 11 以降の公式ドキュメントには、前の鍵を APP_PREVIOUS_KEYS に残して切り替える方法があります（Laravel 公式）。
受け取った後に確かめること
実際にログインできるか
すべての管理画面にログインし、管理者の権限があるか、2段階認証のコードや、更新・障害の通知メールが前任個人に届く設定になっていないかを見ます。
本番と受け取ったソースが一致するか
本番から取得したファイルと受け取ったソースを、GNU diff でディレクトリごと比べます（GNU diffutils）。違いが出たら、本番で直接直したものか、未反映の変更かを前任に確かめます。
# 内容が違うファイルと、片方にしか無いファイルを表示する（vendor などは除く）
diff -rq -x vendor -x storage -x .git /path/to/production-copy /path/to/received-source受け取ったもので別の環境に立ち上がるか
受け取ったソースコード、設定、データベースのダンプ（中身を書き出したファイル。個人情報を含むなら扱いを決めてから）で、本番とは別の環境に立ち上げてみます。動かなければ、足りないものを前任に聞けます。聞いても分からなかったものは、引継ぎの後に調べて補います。h-system が行った引継ぎ調査では、期間は1週間前後で、典型的に判明する問題は、ドキュメントが無いことと、ローカルで環境を再現できないことでした。あくまで一例で、規模や構成で変わります。
h-system でできること
h-system では、他社や前任者が作った PHP・Laravel のシステムを、開発者本人が窓口から調査・実装まで直接お引き受けしています。資料がない状態からでも構いません。ソースコード、データベース、サーバー環境を確認して現状を整理し、構成図、リスク一覧、改修見積のうち必要なものを、調査の範囲に合わせてご報告します。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。