前任者がいない PHP システムの引継ぎ調査、最初の1週間でやること

結論から書くと、前任者のいないシステムを引き継いだ最初の1週間は、コードを1行も直さず、調査だけに使う のが安全です。優先するのは、次の3つの問いに答えられる状態を作ることです。

• 必要なものにアクセスできるか
• 本当に動いているのはどのコードか
• 止まると困るものは何か

順番を間違えると、壊しても戻せない、直した場所が本番と違っていた、という事態が起こります。以下は1週間に割り振った進め方ですが、日数は順序を示すための区切りです。規模によって必要な時間は変わるので、順番のほうを守ってください。

1日目: アクセス権を確保して、バックアップを取る

最初の仕事はコードを読むことではありません。前任者しか知らない情報を、会社の管理下に戻す ことです。これが最も緊急です。次のものを一覧にして、誰が管理者か、ログインできるかを確認します。

• サーバー（SSH、FTP、レンタルサーバーの管理画面）
• ドメインと DNS の管理画面、SSL 証明書
• データベース
• ソースコードの置き場所（リポジトリ、または本番サーバーのみ）
• メール送信や決済、地図など、外部サービスのアカウント
• それぞれの契約名義、支払い方法、更新日

前任者の個人メールアドレスで契約されたサービスが見つかることがあります。ドメインやサーバーの更新通知がそこへ届いていると、気づかないまま失効する恐れがあるので、見つけたら最優先で名義と連絡先を変更します。

次に、コードとデータベースのバックアップを取ります。既存のバックアップがあっても、調査の開始時点のものを自分で取得して、戻せることを確認します。以降の作業はすべて、ここへ戻れることが前提です。

本番サーバーへの接続は読み取りだけにして、この時点では何も変更しません。

2〜3日目: 動いているものを特定し、構成を把握する

本当に動いているものを特定する

リポジトリのコードが本番と同じとは限りません。本番サーバーを直接修正していて、リポジトリに反映されていないことはよくあります。

• 本番のコードとリポジトリの差分を取る。リポジトリがなければ、本番のコピーを最初のコミットにする
• PHP のバージョンを確認する（Web 側とコマンドライン側の両方）
• フレームワークとライブラリのバージョンを確認する（composer.lock があるか、vendor が手で書き換えられていないか）
• サーバーの設定を確認する（.htaccess、Web サーバーの設定、php.ini）
• 定期処理を確認する（crontab -l、サーバー管理画面のスケジュール設定）
• 本番にしかない設定ファイルの所在を確認する（中身をメモにそのまま写さない）

見落としやすいのは定期処理です。画面からは見えないのに、夜間の集計やメール送信など、業務の要になっていることがあります。

この日の成果物は、動いているものの一覧 です。ここまでで、検証環境を作る材料が揃います。

構成とデータの流れを把握する

全部のコードを読もうとしないでください。入口から順に、地図を作るイメージで見ていきます。

1. 入口を洗い出す。 ルーティング、公開ディレクトリ、API、定期処理、メールの受信処理など、外からの処理の始まりをすべて挙げます。
2. データベースを見る。 テーブルの一覧と件数、更新日時を確認します。実際に増え続けているテーブルが、業務の中心です。逆に更新が止まっているテーブルは、使われていない機能の手がかりになります。
3. 外部との接続を探す。 API のキーや接続先、メール送信、ファイル連携を確認します。
4. 構成図を書く。 サーバー、アプリケーション、データベース、外部サービスのつながりを1枚にまとめます。きれいな図でなくて構いません。

コードの読み解きには AI が役立ちます。ファイルをまたいだ処理の流れの説明や、使われていそうにない箇所の洗い出しは特に速くなります。ただし、AI の説明は推測を含むので、重要な点は実際のコードや動作で確かめます。また、顧客データや接続情報を含むものは、入力前に利用規約とデータの扱いを確認し、除外します。

4日目: 業務の話を聞き、リスクを洗い出す

コードだけでは「何が重要か」は分かりません。実際に使っている人に、次のことを聞きます。

• 毎日、毎月、年に一度、どの機能をどう使っているか
• 止まったら、どの業務がどのくらい困るか
• 今困っていること、諦めていること
• 過去に起きたトラブルと、そのときの対応

年に一度しか動かない処理（年次の帳票、更新案内など）は、担当者に聞かないと見つからないことがあります。

並行して、技術面のリスクを洗い出します。

• PHP のサポート期限と、フレームワークのサポート状況
• ライブラリの既知の脆弱性（Composer を使っているなら composer audit で確認できる）
• バックアップが取られているか、戻せるか
• 公開すべきでないファイルが公開されていないか（設定ファイル、バックアップファイル、管理画面）
• 入力値の扱い、ログイン、権限といった実装の懸念（IPA の安全なウェブサイトの作り方が参考になる）

5日目: 報告にまとめ、次の一手を決める

最後に、関係者に判断してもらえる形でまとめます。次の4点があれば十分です。

リスク一覧で大事なのは、「当面やらないこと」も明記する ことです。古いシステムには直したい箇所がいくらでもあります。業務上の影響で順番を決めないと、気になるところから手を付けて、肝心な対応が後回しになります。分からなかったことも「不明」と明記します。推測で埋めると、後の判断を誤らせるからです。

最初の1週間にやらないこと

調査のあいだは、次のことを避けます。善意でやってしまいがちなことばかりです。

• 本番を直接修正する。 緊急の不具合でなければ、検証環境と戻し手順が揃ってから対応します。
• 気になったコードをリファクタリングする。 動作の基準が分かっていないうちは、壊したことに気づけません。
• ライブラリや PHP を更新する。 影響を調べる前の更新は、原因の分からない不具合を生みます。
• 作り直しを結論にする。 読みにくさと、作り直す必要があることは別の問題です。判断には業務の情報が要ります。
• 前任者の批判を報告に書く。 当時の事情は分かりません。報告すべきなのは、今の状態と対応です。

調査の途中で緊急の不具合が起きた場合は、原因の究明より先に、業務を止めないための最小限の対応を優先します。直す前にバックアップを取り、何をいつ変えたかを記録します。応急の修正は後でリポジトリに反映して、本番とのずれを増やさないようにしてください。

自社で引継ぎ調査を行った案件では、調査に要した期間は1週間前後でした。典型的に判明する問題は、ドキュメントが無いことと、ローカルで環境を再現できないことです。

h-system でできること

h-system では、他社や前任者が作った PHP システムの引継ぎ調査を、開発者本人がお引き受けしています。ソースコード、データベース、サーバー環境を確認し、構成図、リスク一覧、改修見積のうち必要なものを、調査の範囲に合わせてご報告します。資料がない状態からでも構いません。調査だけをご依頼いただき、結果を見てから保守や改修を進めるかどうかをご判断いただくこともできます。初回のご相談と概算のお見積りは無料で、詳細な調査は有償です。範囲と費用は着手前にご案内します。