他社開発システムを引き継ぐときのチェックリスト

先に結論

改修の見積もりより先に、手元の資料と不足を8項目で洗い出します。「不明」は失敗ではなく、調査を始める前に見える化できた状態です。本番を直接変えず、読み取り中心の確認から始めます。

最初に集める8項目

引き継ぎの依頼を出す前に、手元にある資料と不足しているものを次の表へ記入します。確認は大きく、権限・コード・データ・運用・契約の5領域に分かれます。

横幅が狭いときは左右にスクロールできます

一覧の「不明」は失敗ではありません。むしろ、調査を始める前に不明点を見える化できた状態です。パスワードをメールや共有文書へ貼り付けるのではなく、権限を持つ人と安全な受け渡し方法を決めてください。

稼働中のシステムでは、確認のために本番データを直接変更しないことが基本です。まず現在の画面、定期処理、外部連携、問い合わせの流れを観察し、読み取り中心の調査から始めます。検証環境があれば、同じ手順をそこで再現し、変更の影響と戻し方を確かめます。

特に次の状態では、急いで改修の見積もりを確定しない方が安全です。

この場合は、まず調査とドキュメント化を一つの作業として見積もり、改修は調査結果の後に分けます。既存システムの引き継ぎ・継続改修でも、現状を確認し、優先事項と必要な作業を共有してから引き継ぎ・整理へ進める流れを案内しています。費用の切り分けは初期開発・月額保守・追加改修の考え方も参考になります。

資料が揃っていなくても、次の順で進めると、止まっているシステムを無理に動かさず、次の担当者へ渡せる形へ近づけます。

STEP 01
現状を記録する
画面、URL、利用者の役割、定期作業、連携先、障害時の連絡先を、確認日とともに記録します。資料が古い可能性も書き添えます。
STEP 02
触ってよい範囲を決める
本番・検証・開発の環境を区別し、読み取りだけの人、変更できる人、承認する人を整理します。作業前にバックアップと戻し方を確認します。
STEP 03
仕組みを読み解く
コードと設定を読み、画面の動き、データの流れ、権限の境界、外部連携、定期処理を図や文章へ変換します。理解できない部分は推測で埋めず、確認待ちとして残します。
STEP 04
小さな変更で確認する
影響範囲が限定された修正を検証環境で試し、テスト、レビュー、公開、監視、必要なら変更前へ戻す作業まで通して手順を確認します。
STEP 05
次の担当者へ渡せる形にする
構成図、運用手順、権限一覧、既知の課題、変更履歴、連絡先を更新し、引き継ぎ後も読める場所へ保管します。

「仕様書がないから何もできない」と決めつける必要はありません。動いている画面とコードから読み解き、今後の改修に必要な資料を整備できます。一方で、資料がない状態を理由に、いきなり全面改修や本番の大きな変更を始めるのは避けます。調査の範囲、確認できないリスク、次に必要な資料を先に合意してください。

既存システムの保守と機能追加をどのように分けるかは、公開されている運用保守・機能追加の実績からも考え方を確認できます。特定の構成や規模を自社に当てはめるのではなく、安定運用と改善を別の確認項目として扱う点を参考にしてください。

コードや資料が揃っていなくても、現在分かる資料から引き継ぎを相談できます。管理権限の所在、動いているURL、分かる範囲の困りごとをお知らせください。現状を調査し、必要な整理と継続改修を分けてご提案します。