275ページの引き継ぎ手順書は直さない。ずれ17件を一覧にする

情シスを引き継ぐと、前任から分厚い手順書を渡されることがある。ありがたい。だが、それが「今の環境」の手順書だとは限らない。

前任ベンダーから情シスを引き継いだ会社（30名規模、Microsoft 365・Intune）で、引き継ぎの資料として 275ページの IT 運用手順書を受け取った。日々の作業で使う章から順に読んできたが、残りの章（ID 管理、PC の復旧、退職者対応、各アプリ、停電対応、拠点、会議室、Web サイト）を今日まとめて読み、今の環境と1項目ずつ突き合わせた。食い違いと未対応が17件出てきた。この記事では、何がずれていたか、どう突き合わせたか、手順書をどう扱うことにしたかを書く。

▼出てきた17件を、4つに分けた

17件を並べると、性質の違うものが混ざっていた。対応の急ぎ方も違うので、まず分けた。

分類	例	急ぎ
前任に紐づいたまま	ドメイン契約の連絡先メールが前任ベンダーのアドレス。停電前の機器設定のバックアップの保管先が前任ベンダーのクラウド。検索サービスの管理が、会社の管理外の個人 Gmail	高
期限が来る	ある SaaS の SSO（SAML）の署名証明書が、来年1月に切れる。手で貼る方式なので自動では更新されない	高（日付が決まっている）
今の運用と食い違う	「ファイル共有は移行済み」とあるのに、別の章では NAS に依存する業務（申請のマスターデータ、インストーラー）が残っている。LAPS について、冒頭は「ローテーションしない」、本文は「30日でローテーション」。ドメインの管理先の記載が whois と違う	中（止める前に確認）
書きかけ・古い	LAN 配線図の章が「記載予定」のまま空。退職時の各システムの担当者が2年前の名前。会議室の機器の管理画面が初期パスワードのまま、と書かれている	低〜中

いちばん危ないのは「前任に紐づいたまま」

ドメインの契約の連絡先が前任ベンダーのアドレスだと、更新の案内やパスワードの再設定のメールが、前任ベンダーに届き続ける。契約が切れたあと、前任側でそのメールを誰も見ていなければ、更新漏れでドメインが失効することもありうる。手順書を読まなければ、この紐づきには気づけなかった。

停電前に取っていた機器の設定のバックアップが前任ベンダーのクラウドにある、というのも同じ種類だ。今は困らないが、いざ機器が壊れたときに「バックアップは前の会社のところ」では取りに行けない。

次に、日付が決まっているもの

SAML の署名証明書は、期限が切れた日にその SaaS へのシングルサインオンが止まる。今は困っていないので、誰も気にしていなかった。期限の前月に新しい証明書を作って貼り替えることにして、作業の予定に入れた。

▼どう突き合わせたか

275ページを頭から読んで直すのは現実的でない。次の順でやった。

1. 日々の作業で使う章から先に読む。PC のキッティング、複合機、勤怠、基幹システムは、実際に作業する日に手順書を見ながらやり、その場で今の手順に書き直した
2. 残りの章は、章ごとに「今もこの通りか」を確かめる。管理画面・whois・Intune の設定・過去の打ち合わせの記録と照らす
3. 手順は今の手順書（自分たちの側）に移す。今はやらない手順（廃止した NAS への接続、旧 VPN など）は「現在は実施しない」と明記して残す
4. ずれと未対応だけを、番号を振って一覧にする。それぞれに「次のアクション」を1つ書く

▼手順書は直さない。ずれの一覧を育てる

前任の手順書そのものを今の内容に書き直す、という手もある。だがやめた。理由は2つある。

• ▶ 書き直すと、前任が何を前提にしていたかが消える。「ここは前はこうだった」は、障害のときに効く情報だ
• ▶ 17件の一覧の方が、引き継ぎの残りとして管理しやすい。1件ずつ潰せば、引き継ぎの完了条件「手順書が今の運用と一致している」に近づく

以前、引き継ぎは「受け取った」ではなく「理解した」で確認する、という記事を書いた。手順書を受け取った時点では、まだ何も引き継げていない。今の環境と突き合わせて、ずれを1件ずつ自分の言葉で説明できるようになって、ようやく引き継いだと言える。

▼まとめ

• ▶ 前任の手順書は「ある時点の環境」の記録。今と1項目ずつ突き合わせる
• ▶ 急ぐのは「前任に紐づいたまま」と「期限が来るもの」
• ▶ 平文の秘密情報が残っていないかを最初に見る
• ▶ 手順は自分たちの手順書に移し、ずれだけを番号付きの一覧にして潰していく