停止リスクをゼロにはできません。だからこそ、現状調査、検証、バックアップ、公開、監視、連絡、変更前へ戻す作業を一つの段取りとして先に合意します。改修を急ぐ前に、読み取り中心の観察から始めてください。
最初の仕事は、変更しない観察
引き継ぎ直後に本番のコードや設定を直すのではなく、次の情報を読み取り中心で集めます。権限・コード・データ・運用・契約の洗い出しは、他社開発システムを引き継ぐときのチェックリストに、仕様書が残っていない場合の調べ方は仕様書がない既存システムの調査にまとめています。
- いつ、誰が、どの画面や機能を使うか
- 本番・検証環境、データ保存先、外部連携はどこか
- 定期処理や通知がいつ実行されるか
- 監視画面や動作記録で、正常と異常をどう見分けるか
- 障害時に誰が判断し、利用者へ何を伝えるか
実際の利用者から通常業務と繁忙時間を聞き、作業を避ける時間帯も確認します。アクセス権限は必要最小限にし、受け取った認証情報を共有文書へ貼り付けないようにします。現状の画面、構成、直近の変更を、確認日とともに保存します。
停止リスクを抑える5段階
稼働を維持するレーンと、調査・改修のレーンを混ぜないことが基本です。次の順で進めると、本番をいきなり大きく変えずに済みます。
- STEP 01
現在地と成功条件をそろえる
引き継ぎの完了条件を「新しい会社がコードを持つ」だけにせず、構成図、運用手順、権限一覧、既知の課題、緊急時の連絡先が確認できる状態と定義します。改修の場合は、変更後も守る業務と、改善したい業務を分けます。
- STEP 02
変更前の状態と戻し方を確保する
コード、設定、データ、環境ごとに変わる設定値、外部連携をどこまで保存するかを決めます。バックアップがあるだけでなく、復元できるか、復元後に利用者が業務を再開できるかを、本番へ影響しない確認用環境で確かめます。戻す条件と判断者も書きます。
- STEP 03
検証環境で同じ流れを試す
本番と同じ業務の流れを検証環境で再現し、ログイン、権限、登録、更新、通知、外部連携、エラー時の動作を確認します。テストデータと本番データを混ぜず、個人情報を扱う場合のマスキングも決めます。
- STEP 04
影響の小さい変更から公開する
最初から大きな構造変更をせず、利用者が確認しやすい小さな変更を選びます。公開前に担当者が業務の一連の流れを確認し、公開後は監視と問い合わせ窓口を同じ時間帯に用意します。問題があれば、原因を調べる前に決めた条件で戻します。
- STEP 05
変更後に資料を更新する
公開後に、実際の構成、作業時間、ログの見え方、問い合わせ、残った課題を記録します。古い資料をそのまま残すのではなく、変更日と担当者を追記し、次の改修や引き継ぎへつなげます。
役割を表にしてから作業する
稼働中のシステムでは、技術担当だけでなく業務側の判断が必要です。次の表の空欄を作業開始前に埋めます。一人が複数の役割を兼ねても構いませんが、名前を曖昧にしないことが大切です。
横幅が狭いときは左右にスクロールできます
| 役割 | 作業前に決めること |
|---|---|
| 業務責任者 | 何を守るか、公開してよいか、利用者へどう伝えるか |
| 技術担当 | 調査、変更、テスト、監視、戻す作業の担当 |
| 利用者代表 | 実際の業務での確認と、使いにくさの報告 |
| 連絡・判断窓口 | 障害や予定外の影響が出たときの連絡順 |
公開の合否を技術担当だけで決めず、業務を止められない時間や優先度を共有します。
引き継ぎ後も改善できる状態を残す
引き継ぎは、現在動いているものを保つだけでなく、次の改修を安全に行える状態をつくる機会です。既存システムの引き継ぎ・継続改修でも、コード調査、ドキュメント化、引き継ぎ、継続改修、保守運用を状況に合わせて組み合わせる考え方を案内しています。
運用と改修は、確認項目を分ける
運用保守と機能追加を並行するときの考え方は、公開されている運用保守・機能追加の実績からも確認できます。自社の停止許容時間や確認体制は固有なので、実績の数字や構成をそのまま当てはめず、作業の順序と責任分担を参考にしてください。
注意点と相談の進め方
資料が少ない場合は、改修を急がず、読み取り中心の調査とドキュメント整備から始めます。作業前後の画面や動作記録を比べられるよう、確認する時刻と担当者も記録しておきます。現在分かる資料から引き継ぎを相談するなら、稼働中のURL、使う人、困っている時間帯、分かる範囲の管理権限をお知らせください。状況を確認し、止めずに進めるための調査と改修の順番をご提案します。