担当者がいないWebシステムを引き継ぐには｜PHPなどのコード・契約・業務の確認

担当者がいないPHPシステムを引き継ぐときは、ソースコード、稼働環境、業務上の使い方をそろえます。サーバーへログインできても、サービスを再構築・改修できるとは限りません。

最初から新しい環境へ移そうとせず、現在何が動いていて、どの権限を誰が持っているかを記録します。脆弱性の通知がある場合は、この調査と並行して現環境の運用事業者へ対応状況を確認してください。

管理画面のIDと、開発に必要な権限は異なる

サービスの管理画面は、利用者や記事を操作するためのものです。改修には、ソースコードの保管場所、サーバーの契約、公開手順なども必要になります。

パスワードを一つの文書に集める運用にはせず、権限を付与する方法と秘密情報の共有方法を決めます。契約や利用権限が確認できない場合は、所有者への確認を先に進めます。

コードがあっても、必要なライブラリ、環境設定、画像ファイル、データが不足していると起動できません。本番サーバー上で行われた修正が、保管されているコードに反映されていないこともあります。

PHPのライブラリ管理にComposerを使っている場合、composer.jsonは依存条件、composer.lockは解決された版の記録になります。Composer公式の基本説明を参照し、開発担当者に再現できる状態か確認してもらいます。

検証環境へ本番の顧客データをそのままコピーする必要があるかも見直します。操作確認には、用途を満たすテストデータを用意できる場合があります。実データが必要な調査は、範囲とアクセス権を限定します。

夜間の集計、毎月の請求書、外部サービスとの同期。こうした処理は、画面だけ見ても見つけにくい機能です。

「毎朝届くメール」「月末にダウンロードするファイル」「特定の曜日に更新される数字」から聞くと、業務側からも情報を出しやすくなります。実行時刻、入力元、出力先、失敗時の連絡先を記録します。

権限も同じです。管理者の画面だけでは、一般ユーザーの制限や、部署ごとの閲覧範囲を確認できません。実際の利用者区分をもとに操作を整理します。

調査中に分かった挙動が、本来の仕様とは限りません。「コードではこう動く」「業務担当者はこう使う」「意図が確認できない」を分けて記録すると、改修時の判断に使えます。

引き継ぎ資料には、構成図、画面・定期処理の一覧、外部連携、公開手順、バックアップ、未確認事項を含めます。すべての仕様を復元できなくても、どこまで調べたかが分かれば次の担当者が続けられます。

引き継ぎが難しいことだけを理由に、全面的な作り直しを決める必要はありません。現行構成を更新できるか、特定の部品が障害になっているかを調べてから比較します。

改修と作り直しの判断基準と見積もりの確認点を使って、次に依頼する作業を決めます。全体の進め方はPHPの保守・改修ガイドへ。相談時には、用途と管理情報の所在が分かる範囲で十分です。