リポジトリを受け取ることは、チームが保守できるシステムを受け取ることと同じではありません。PHPプロジェクトを社内チームへ引き継ぐには、引き継ぎを受ける側がアプリケーションを実行し、変更をデプロイし、障害を調査し、システムの制約を理解したうえで判断できなければなりません。
移行は最後の会議としてではなく、作業の一部として計画する必要があります。どの能力を引き継ぐのか、誰が実演するのか、受け入れ側のチームがその能力を実際に発揮できることをどう確認するのかを合意しておきましょう。目的はあらゆる不確実性をなくすことではありません。リスク、未決定事項、引き続き調整が必要な依存関係を明らかにすることです。
運用準備が整った状態を定義する
文書を集める前に、退任するチームの即興的な指示に頼らず、社内チームが何を実行できる必要があるのかを定義しましょう。システムによっては、ローカル環境の起動、リリースのデプロイ、ログの確認、データの復元、連携機能の障害への対応などが含まれます。
こうした期待を、観察可能なテストに落とし込みます。たとえば、受け入れ側の担当者が既存の手順に従って低リスクの変更をデプロイできることや、問題のあるマイグレーションを特定してロールバックする方法を説明できることです。テストは実際の権限と環境に合わせる必要があります。復旧計画があることを示すために、本番環境で障害を発生させてはなりません。
対象外となる範囲も明確にします。特定の運用が別のチーム、プロバイダー、セキュリティ承認に依存している場合があります。その依存関係とエスカレーション手順を記録し、引き継ぎ済みの能力として扱わないでください。
システムと依存関係を棚卸しする
技術インベントリから、アプリケーションの開発と運用に必要なコンポーネント、およびその担当者を特定できるようにします。最低限、以下を含めてください。
- コードと自動化：リポジトリ、関連ブランチ、継続的インテグレーションの設定、スケジュール実行タスク、運用スクリプト。
- アプリケーション：必要なPHPバージョン、依存関係マネージャーと依存関係ファイル、拡張機能、ビルドコマンド、環境ごとの設定。
- インフラストラクチャと環境：各環境の実行場所、プロビジョニング方法、テスト環境と本番環境の重要な違い。
- データ：使用するデータベースエンジン、マイグレーション、バックアップ、復元、保持期間、保護が必要な機密データ。
- 接続サービス：API、メール、決済、ストレージ、キュー、IDサービスと、それぞれの担当者および既知の障害時の挙動。
技術名の一覧だけでは不十分です。重要な依存関係ごとに、管理者、必要な認証情報や権限、停止の検知方法、応答がなくなった場合のアプリケーションの挙動を記載してください。文書やリポジトリにシークレットを含めてはいけません。保管場所とアクセス申請方法を記してください。
アーキテクチャ、決定事項、制約を文書化する
有用な文書は、実作業で生じる疑問に答えます。どのコンポーネントがリクエストを処理するのか、データの検証場所はどこか、この情報を更新するプロセスは何か、マイグレーションの調整なしに変更できない部分はどこか。個々のファイルをすべて説明するより、コンポーネントと重要なフローを簡潔に示したマップのほうが実用的な場合が多くあります。
重要な決定事項は、その背景、検討した代替案、結果とともに記録してください。連携機能に制約がある、定期タスクが冪等でない、古い領域にテストがないといった点は、明示しておきましょう。確認済みの事実と仮説を分け、情報をいつ確認したかも示してください。
未決定事項も記載します。選択肢、決定を先送りする影響、解決責任者、見直し日または見直し条件を含めてください。こうすることで、引き継いだ選択をあたかも義務であるかのように扱うのではなく、受け入れ側のチームが判断する余地を保てます。
実行・運用手順を引き継ぐ
チームが繰り返し実行する必要のある手順を文書化し、メンバーと一緒に検証します。最低限、ローカル環境の準備、テストの実行、スキーマ変更、ビルドとデプロイ、リリースの確認、ロールバックや復元が必要な場合の対応を扱ってください。
手順には、前提条件、権限、コマンドまたは操作、期待される結果、停止すべき兆候を明記します。デプロイに非互換なマイグレーションや手動タスクが必要な場合は、実行順序とリスクを記してください。復旧手段を説明しただけでは、それが機能する証明にはなりません。安全に実施できる場合は適切な環境でテストし、結果、制約、使用を承認する担当者を記録してください。
ログやメトリクスの確認場所、設定済みのアラート、通知先、シグナルと業務フローの関係を示し、オブザーバビリティを運用手順に加えてください。重要なリスクに対するアラートがない場合は、ギャップとして記録します。後任チームが問題に間に合うよう気づくと決めつけてはいけません。
アクセス権、所有権、管理方法を確認する
受け入れ側のチームには、将来アクセスできるという約束だけでなく、コードや必要なツールに対する実効性のある権限が必要です。リポジトリ、インシデント管理、デプロイパイプライン、クラウド、ドメイン、証明書、監視、プロバイダーのアカウントを確認してください。ユーザーを管理できる人と、誰かが組織を離れた場合にアクセスを復旧できる人も確認します。
また、コード、文書、ドメイン、設定など、関連する資産の所有権と管理方法を確認してください。最小権限の原則を適用します。自律性を確保することは、個人認証情報を共有したり、無制限の権限を付与したりすることではありません。個人に紐づくアカウントまたは承認済みの仕組みを使い、社内ポリシーに従って退任チームのアクセスをローテーションまたは取り消す計画を立ててください。
共同作業を通じて引き継ぎ、完了を検証する
紹介会議は役立ちますが、知識が引き継がれた証明にはなりません。実際のタスクを使ったガイド付きの確認を行い、進行役を交代しましょう。まず退任するチームが説明し、その後、受け入れ側の担当者が同じ手順を実行し、何を確認するのか、なぜ確認するのかを説明します。質問の時間を確保し、調査が必要な疑問を記録してください。
検証では、変更の開発とテスト、代表的な障害の診断、手順に沿ったデプロイ、重要な依存関係の担当者の特定など、複数の能力を確認します。システムに見合った安全な演習を選んでください。タスクに失敗した場合は、文書の不足、権限不足、技術的制約、トレーニングの必要性を区別します。原因ごとに必要な対応は異なります。
移行を終える際は、説明、影響、担当者、緩和策、見直し日を含む未対応事項の一覧を作成します。受け入れ側のチームは、残存リスクを理解したうえで受け入れる必要があります。受け入れたからといって制約が解消済みのリスクになるわけではありません。誰がその制約を把握し、どう管理するのかを記録するものです。
移行完了のチェックリスト
- 受け入れ側のチームがコードの場所を把握し、実行して必要なテストを実施できる。
- 環境、依存関係、スケジュール実行プロセス、外部サービスが棚卸しされている。
- アーキテクチャ、重要なフロー、決定事項、既知の制約を示す見直し可能な情報がある。
- デプロイ、確認、ロールバック、復旧の手順に、担当者と前提条件が明記されている。
- 必要なアクセス権がテストされ、所有権が明確で、シークレットが安全に管理されている。
- 受け入れ側のチームが説明を聞くだけでなく、実作業を行っている。
- リスクと未決定事項に担当者、緩和策、明示的な受け入れが設定されている。
- 移行に関する疑問を解決するための連絡手段と期間が合意され、対象範囲が明確になっている。
合意した能力を社内チームが実証でき、支援が必要な状況を認識できるとき、引き継ぎの準備が整います。テスト、アクセス権、担当者が不足していれば、文書をすべて共有していても引き継ぎは不完全です。この基準によって完了を検証可能な移行にし、PHPプロジェクトを保守・発展させる自律性を維持できます。
