情シスの引き継ぎは「受け取った」ではなく「理解した」で確認する【実録】

情シス担当の退職、IT ベンダーの切り替え。どちらの場面でも、引き継ぎの最後はたいてい「資料はひと通り受け取りました」で終わる。

だが、資料を受け取っても、一人で回せるようにはならない。この2か月、前任ベンダーからの全面引き継ぎと、前任の社員からの引き継ぎを、別々の会社で並行して受けた。両方で痛感したのは、引き継ぎの完了は「受け取った」ではなく「理解した（一人でできる）」で判定しなければならないということだ。

▼引き継ぎ資料をもらっても、一人でできるようにはならない

前任ベンダーから引き継いだ会社では、資料は3点セットでそろっていた。運用の概要書、手順書（PDF にして約200ページ）、ID や端末をまとめた管理シート。量としては十分だ。

それでも、読んだだけでは回せない。手順書には「なぜその設定なのか」が書かれていない。管理シートは実態とずれている。そして何より、ベンダーの契約上の義務は「事前に合意した目次の資料を渡すこと」までだった。理解の移転、つまり「後任が一人でできるようになること」までは契約に入っていない。

これはベンダーが不誠実なわけではない。契約がそうなっているだけだ。だからこそ、受け取る側が「理解した」を基準に引き継ぎを設計しなければ、誰もその責任を持たない。

▼パターン1：前任ベンダーから引き継ぐとき

ある消費財の輸入販売会社（約35名、物流倉庫あり）で、前任ベンダーから情シス運用を全面的に引き継いだ。ヘルプデスク、ネットワーク、端末管理、サーバー、ベンダー管理まですべてだ。前任のヘルプデスクの最終日まで、引き継ぎ期間は実質2週間だった。

管理シートは「マスター」、でも実態の正は管理画面

ID とパスワードをまとめた管理シートは、引き継ぎの中心になる資料だ。複製やローカルへの持ち出しはせず、マスターとして1か所で管理する。ここは前任の運用を引き継いだ。

ただし、シートは古いことがある。実態の正は各サービスの管理画面だ。シートを信じて作業すると、すでに存在しないアカウントや、変わった権限を前提に動いてしまう。「シートはマスター、実態は管理画面」という二重の線引きを、最初に決めておく。

前任名義のものを最初にリストにする

長く同じベンダーが入っていた会社では、ベンダーの名義で作られたものが大量に残っている。今回は、20年以上の蓄積で前任名義の ID が約100件あった。前任の担当者自身も全容を把握していなかった。

残りやすいもの	対応
前任名義のアカウント（SaaS・管理ポータル・ドメインなど）	会社の共有管理アドレス（メーリングリストを新設）へ数か月かけて付け替える。前任 ID の削除は引き継ぎ終了の3〜4か月後
前任のクレジットカードで契約した回線・サービス	名義変更の手続きを洗い出す。自動更新で気づかないまま請求が続く
前任の手持ち機器（ライセンスなしのファイアウォールなど）	返却が前提になる。代替機の手配を先に計画する
緊急用の管理者アカウント	付け替えても最後の砦として残す。全部を一人の管理者に寄せない

使われていない契約は「実態に合わせる」と言う

引き継ぎで必ず見つかるのが、誰も使っていないのに払い続けている契約だ。今回は、配布率0%のウイルス対策ソフトが契約されたままだった。DLP の機能も実質休眠していた。

これを解約するとき、「新しい施策として、別の製品に切り替えます」と言うと、比較検討や稟議が始まる。「契約を実態に合わせるだけです」と言えば通りやすい。実際に使われていないものを止めるだけだからだ。

ただし落とし穴がある。この会社では、監査向けに「ウイルス対策ソフトの管理画面を週1回確認している」と報告していた。契約を止めるなら、監査に報告している運用の置き換えも同時に必要になる。解約の前に、その製品が監査報告の中でどう扱われているかを確認する。

保守契約のないシステムは「触らない」から始める

クラウド上のデータベースが、保守契約なし（使用権のみ）で動いていた。最強権限はこちらに移ったが、方針は「操作を覚えるまで触らない、構成は変えない」にした。

最初に共有したのは、管理画面の「停止」と「終了」の違いだ。このサービスでは「停止」はシャットダウン、「終了」はインスタンスの削除を意味する。名前が似ている操作の違いを、権限を持つ全員が知っている状態にしておく。こういう基本の確認こそ、資料には書かれていない。

▼パターン2：前任の社員から引き継ぐとき

ある大手グループ傘下の会社では、社内の情シス担当が長期不在になる前に、業務を引き継いだ。期限は約1か月。前任は在籍しているが、自分の業務も抱えている。

不在日から逆算して、1時間枠を積む

前任が対応できる時間帯と最終日を先に聞き、そこから逆算して1時間の引き継ぎ枠を細かく積み上げた。1回で全部を説明してもらおうとすると、前任の負担が大きく、日程も決まらない。テーマを分けて小さく刻む方が、結果的に早い。

最初に依頼したのは、権限の付与だ。Google Workspace、Slack、Microsoft 365、MDM、Notion。権限がないと、引き継ぎの内容を自分で確かめられない。説明を聞く前に、触れる状態を作る。

途中で「説明中心」から「質問ベース」に切り替える

最初の数回は、前任に説明してもらう形で進めた。だが、説明は前任が大事だと思っている順に進む。こちらが詰まりそうな箇所とは、必ずしも一致しない。

そこで途中から、事前にツールを触って具体的な質問を用意し、質問ベースで進める形に切り替えた。見ればわかることは省き、「この設定はなぜこうなっているのか」「この依頼が来たら誰の承認が要るのか」に時間を使う。1回あたりの密度がまったく違った。

録音には認証情報が出る

引き継ぎの打ち合わせは録音し、文字起こしからサマリを作って社内に共有した。ここで注意がいる。口頭で伝えられた PIN や初期パスワードが、文字起こしにそのまま残る。

議事録やサマリには書かない。原本の保管場所を限定する。資格情報の受け渡しはダイレクトメッセージで行い、受け取ったらすぐ変更し、確認後にメッセージを消す。この流れを最初に決めておくと、引き継ぎの途中で慌てない。

▼引き継ぎ期間の稼働は、先に範囲を決める

引き継ぎは稼働が増える。前任との打ち合わせ、資料の読み込み、質問シートの往復。通常の運用に上乗せになる。

外部の立場で引き継ぐなら、引き継ぎの範囲と、想定を超えたときの扱いを先に確認する。ここで聞き方を誤ると「そんなに余裕があるのか」と受け取られかねない。「引き継ぎに必要な作業を洗い出したので、範囲を確認させてください」と、作業ベースで切り出すのがいい。

逆に、前任の不在で依頼が減り、稼働が想定を下回る月もある。その場合は、稼働を「引き継ぎ分」「こちらからの提案と実装」「依頼分」の3本に分けて考え、提案を定例で出して取りに行く。引き継ぎ期間は、前任が手をつけられなかった改善を提案する好機でもある。

▼「理解した」を判定するチェックリスト

引き継ぎ項目ごとに、次の問いに自分で答えられるかを確認する。答えられないものは、前任に質問できる期限までに潰す。

観点	「理解した」と言える状態
権限	自分のアカウントで管理画面に入り、実際の設定を確認できる
名義	前任名義のアカウント・契約・機器の一覧があり、付け替えの期限が決まっている
理由	主要な設定について「なぜそうなっているか」を説明できる
依頼フロー	入社・退社・権限付与の依頼が来たら、誰の承認で何をするかがわかる
障害時	止まったときの連絡先（ベンダー・親会社のサービスデスクなど）と、切り分けの線引きがわかる
監査	監査に報告している運用（定期確認・記録）を把握している
実作業	入退社が重なる週などに、前任といっしょに一度は実作業をやっている

最後の「実作業」は特に効く。今回は、前任ベンダーのヘルプデスク最終日と入退社が重なる週を引き継ぎ期間に含め、実際の入社対応をいっしょにやって覚えた。手順書を読むより、1回やる方が早い。

▼まとめ

• ▶ ベンダーの引き継ぎ義務は「資料を渡す」まで。「理解した」は受け取る側が設計する
• ▶ 管理シートはマスター、実態の正は管理画面。前任名義のものを最初にリストにする
• ▶ 使われていない契約は「実態に合わせる」と説明する。監査報告の運用の置き換えも忘れない
• ▶ 社員からの引き継ぎは、1時間枠を積み、途中から質問ベースに切り替える
• ▶ 録音・文字起こしに出る認証情報は、議事録に書かない