前任者がいないシステムを引き継ぐ手順

前任者が退職しています。設計書はありません。動いているものは分かりません。この状態でシステムを引き継ぐ場面は、珍しくありません。

つらいのは調べること自体ではなく、何を調べ終えれば引き継げたと言えるのかが分からないことです。終わりが見えないまま手を動かすと消耗します。

終わりの条件を先に決めて、そこから逆に進めます。

引き継げたと言える条件

次の5つが埋まった時点で、引き継ぎは完了と見なしてよいです。

中身をすべて理解する必要はありません。理解は運用しながらで間に合います。上の5つがない状態で運用に入ると、事故のときに何もできません。

手順1. 動いているものを数える

最初にやるのは、コードを読むことではなく棚卸しです。

「ない」ことの確認まで含めて一覧にします。後から「実はここにもあった」が出るのが一番こわいです。

一覧の形は次の通りです。

「何をしているか」は1行でよいです。この段階で深追いしません。

手順2. 止まったら困る順に並べる

一覧ができたら、順番を付けます。基準は止まったときに誰が困るかです。

最後の区分が重要です。使われていない処理は必ずあります。止めてよいか関係者に確認するだけで、管理する対象が減ります。

確認の仕方は、出力先（テーブル、レポート、通知先）を見て、直近3か月に誰かが参照しているかを調べます。参照が無ければ、その部署に「止めてよいか」と聞きます。

手順3. 気づける状態にする

上位のものから順に、失敗したときに通知が飛ぶようにします。

3つ目を見落としやすいです。異常でも正常の応答を返す実装だと、呼び出し側は成功と判断します。この場合、通知を足しても飛びません。

手順4. 復旧の手順を書く

すべてに書かなくてよいです。優先度が高いものだけ、次の3行を書きます。

症状：（何が起きたら、この手順を使うか）
確認：（どの画面・どのログを見るか）
復旧：（再実行の方法。再実行してよい条件）

「再実行してよい条件」を必ず書きます。同じ処理を2回動かすと二重に取り込まれるものがあります。ここを書いていないと、復旧が事故になります。

手順5. 権限と契約を洗う

技術よりも、ここで詰まります。

前任者のアカウントで動いている処理が残っていることがあります。アカウントを消した瞬間に止まるため、棚卸しの段階で確認します。

聞ける人がいない場合

聞ける相手がいても、答えが返らないことはあります。その場合の進め方は次のとおりです。

設定画面に入っている値が事実です。ドキュメントと違う場合、動いているほうが正しいです。

やること

調査の記録の残し方

調べたことは、その日のうちに書きます。形式は問わないが、次を入れます。

調査日：
調べたもの：
分かったこと：
分からなかったこと：
次に見るところ：

「分からなかったこと」を残すのが要点です。次に調べる人（自分を含む）が同じ場所で止まらずに済みます。

期限を切る

棚卸しは、放っておくと終わりません。

1か月で運用に入れる状態にすると決めて動きます。完璧を目指すと、いつまでも引き継ぎ中のままになります。

触らないと決めておくこと

調査中は、次をやらないでください。

• 元の処理の書き換え
• 権限の変更
• データの削除・再取り込み
• 使っていなさそうな処理の停止（確認前）

削除と再取り込みが一番危ないです。洗い替えの仕組みだと、再取り込みの失敗でその日の分が消えます。

失敗例

まとめ

• 引き継ぎのつらさは作業量ではなく、終わりの条件がないこと
• 完了の条件は5つです。一覧化・影響範囲・検知・復旧手順・権限です。中身の理解は含めません
• 最初にやるのはコードを読むことではなく、動いているものを数えること
• 「無かった場所」まで一覧に書きます。後から出てくるのが一番こわい
• 使われていない処理は必ずあります。止めてよいか確認するだけで管理対象が減ります
• 異常時に正常の応答を返す処理では、通知を足しても飛びません
• 復旧手順には再実行してよい条件を書きます。書かないと復旧が事故になります
• 調査中は、元の処理・権限・データに触らないでください
• 1か月で運用に入れる状態にすると決めます。完璧を目指すと終わりません

最初の1週間でやることは、動いているものを数えて表にするだけです。その表ができた時点で、引き継ぎの半分は終わっています。