その人しか知らなかった — 香港企業の一人情シスが辞めるときのIT引き継ぎ

結論から: リスクは欠員ではありません。文書化されていないIT環境が、一人の頭の中に入ったまま建物を出ていくことです。1か月の予告期間では、まずアクセス権、次に資産台帳、最後に「その人しか知らないこと」——この順番です。最初の2つは、アカウントが無効化された瞬間に取得不能になるからです。

香港の50名規模の測量事務所のマネージングパートナーは、こう一言で表現しました。「月曜に辞表を出されて、水曜になって、うちには何のパスワードも知っている人間が他にいないと気づいたんです。」

その事務所はまったく典型的です。30〜80名、専門サービス業、在籍5〜8年のIT担当が一人、そして文書化された設計ではなくその人を中心に育ってきたIT環境。物置には誰も扉を開けたことのないサーバーがある。ドメインレジストラのアカウントは彼の個人メールに紐づいている。会計システムに回避策がある理由は、彼だけが覚えている。彼の携帯には出るが会社の代表番号には出ないハードウェアベンダーがいる。

これは怠慢ではありません。文書化より速く成長した会社のITを、有能な一人が支えるとこうなるというだけのことで、香港の専門サービス業のかなりの割合がこの状態です。

以下は、手元にある4週間をどう使うかという話です。

なぜ香港のこの規模帯でこれほど多いのか

この帯域では3つの事情が重なります。

規模帯が中途半端です。 おおむね30名未満なら、ITは外注するか消費者向けツールで回します。100名を超えれば、最低2人のITチームができます。その間では、一人が「雇える」「足りる」「たぶん問題ない」という位置に収まります。この帯域で冗長性に予算を割いている会社はありません。辞表が届くまで、目に見えて悪いところは何もないからです。

香港の専門サービス業は、薄いチームで広い環境を回しています。 50名の測量・会計・コンサルティング事務所なら通常、ドメイン、Microsoft 365またはGoogle Workspaceのテナント、ファイルサーバーまたはNAS、現場要員向けのVPN、案件管理または原価管理システム、保存義務のある文書管理システム、独自のライセンスサーバーを持つ業界特化アプリケーション数本、いくつかのベンダーポータル、そしてそのすべてにまたがるPDPO上のリスクを抱えています。小さな環境ではありません。ただ一度も書き出されていないだけです。

予告期間は短く、労働市場は流動的です。 香港の非役員職の標準的な予告期間は1か月。英語と広東語を読み書きする経験豊富なインフラのジェネラリストが長く無職でいることはありません。窓は固定で、短く、他社に署名したあとの好意で延長されることはありません。

結果として、社内の誰もリハーサルしたことのない、予測可能な危機が起こります。

「その人しか知らない」とは実際に何を指すのか

具体的に書く価値があります。この問題の抽象版——「もっと文書化すべきだ」——は、誰も満足しない文書を生むだけだからです。

出ていく知識には4種類あり、それぞれ振る舞いがまったく違います。

• 認証情報。 管理者アカウント、レジストラのログイン、ファイアウォールのenableパスワード、バックアップコンソール、NASのrootアカウント、ベンダーポータル、そして彼の個人名義や個人メールで登録されているアカウント。これは二値です。最終出社日までに持っているか、数週間かかり時に公証済みの会社書類を要する復旧プロセスを始めるかのどちらかです。
• 資産台帳。 何が、どこに、どのライセンスで、どの保証で、いつ更新で、どのカードで払われているか。これは彼なしでも復元できますが、遅く、抜けが出ます。
• 依存関係。 物置の機械を落とすと何が壊れるか。どのレポートがどのスケジュールタスクに依存しているか。VPNに明らかに不自然な静的ルートがある理由。ここが2か月目に不愉快な驚きを生む層です。
• 暗黙知。 その回避策が存在する理由、実際に電話に出るのはどのベンダーか、2023年に何を試して失敗したか、技術ではなく社内政治の理由でどの利用者をどのシステムから絶対に締め出してはいけないか。本当に再構築できないのはこの層だけであり、そして多くの人が最後まで手をつけないのもこの層です。

汎用チェックリストではなく、このリストに沿って4週間を並べてください。そしてこの順序は重要度ではなく失効の早さで決まっている点に注意してください。認証情報と資産台帳はアカウント無効化とともに取得不能になります。暗黙知の劣化はもっと遅く、関係が残っていれば、後から有償のコンサルティング取り決めで部分的に回収できる余地もあります。

第1週: アクセス権とアイデンティティ

これを最初にやってください。他の何よりも先に、そして運用上燃えている何かに後回しにさせないでください。

管理者権限を持つすべてのアカウントを列挙する。 アイデンティティテナント、ファイアウォール、スイッチ、NAS、ハイパーバイザー、バックアップシステム、エンドポイント管理コンソール、アンチウイルステナント、そして会社が支払っているすべてのSaaS。「彼が使っているもの」ではなく、サービスアカウントと緊急用アカウントを含めた全部です。

第2の管理者を「あとで」ではなく今つくる。 作成し、別の端末から独立してログインしてテストし、マネージングパートナーか財務責任者もアクセスできる会社管理のパスワードマネージャーに保管します。テストが肝心です。存在するが一度もサインインされたことのない管理者アカウントは統制ではなく、願望です。

個人名義のものをすべて洗い出す。 最も飛ばされやすく、最も頻繁に本物の危機になる工程です。ドメインレジストラ、SSL証明書、携帯キャリア、ベンダーサポートポータル、彼のメールで登録された法人カード、アプリストアの開発者アカウント、そして個人の携帯にシードされた二要素認証。まだ協力してもらえるうちに、それぞれを会社所有のアイデンティティ——共有メールボックスやロールアカウント——へ移す必要があります。最終出社日を過ぎると、いくつかはベンダーのアカウント復旧手続きが必要になり、その一部は本当に骨が折れます。

最終出社日に変更すべきものは変更する。 そして、どの変更に影響範囲があるかを事前に把握しておくこと。何がそれを使っているか分からないままサービスアカウントのパスワードを回すのは、退職翌週の月曜に会社を止める確実な方法です。

更新カレンダーを書き出す。 ドメイン期限、SSL期限、ライセンス更新日、保守契約の終了日、回線契約の終了日。退職の4か月後にドメイン更新が失効するのは、よくある、そして完全に回避可能な事故です。

第2週: 資産台帳と依存関係

アクセスを確保したら、自社が実際に何を持っているのかの絵を描きます。

論理的にだけでなく物理的にも歩いてください。誰かが彼と一緒に通信キャビネットを開け、中身を撮影し、それぞれが何をしているかを書き出す——2019年から何か重要なものに給電し続けている、ラベルのない箱も含めて。第2オフィスや現場事務所の機器も同様に。

すべての機器とシステムについて記録します。それが何か、どこにあるか、何をしているか、誰が依存しているか、いくらか、保守や保証がいつ終わるか、そして止まったら何が起きるか。資産一覧を有用なものに変えるのは、最後の列です。

非物理の部分も同様に。サブスクリプション、ライセンス、回線、モバイルプラン、クラウドテナント、そして自社システムへの常時アクセス権を持つ第三者。リモートアクセスを持つベンダーはよく出てくる驚きです——たとえば2021年の導入以来VPNアカウントを持っている案件管理システムの供給元は、運用上の依存であると同時に、一度問う価値のあるPDPO上の論点でもあります。

最後に、バックアップをテストする。 「バックアップジョブが成功と報告しているか確認する」ではなく、実際に何かを別の場所へリストアして開いてみることです。退職する一人情シスが残していくもので最も多いのが、何年も緑色を報告し続けながら一度もリストアされたことのないバックアップ体制です。クラウドとバックアップの設計そのものを見直すならマネージドITクラウドサービスの範囲ですが、まずやるべきはテストです。彼が在籍しているうちに、それを知っておきたいのです。

第3週: 暗黙知の層

多くの引き継ぎが飛ばす週であり、分厚い文書を作ったのに引き継ぎが失敗する理由でもあります。

一人で書かれた文書は、楽観的に書かれた文書です。孤立して書かせれば、退職するエンジニアはアーキテクチャを「設計されたとおり」に記録し、「ドリフトした現状」としては記録しません。回避策はきまりが悪いので省きます。そして本人にとって当たり前すぎて知識として認識されていないことは、そもそも思い出しません。

代わりにすべきは、一緒に環境を歩いて記録することです。隣に座り、システムを一つ選び、語ってもらう。これは何か、なぜこの構成か、何が壊すのか、壊れたら何をするか、誰に電話するか。セッションを記録する——音声で十分、画面収録ならなお良い。そして別の人がその語りをたどって定型作業を一つ実行してみる。抜けは即座に現れます。

優先順位はこの順です。今日会社を止めるもの。コンプライアンスや顧客機密に関わるもの。年次イベントのように、失敗するまで誰も見ないもの(年度末処理やライセンス更新など)。最後に「知っていると良い」もの。

居心地の悪いリストも直接聞いてください。どのシステムが一番心配ですか。直そうと思っていたのに手をつけられなかったのは何ですか。文書には書きたくない何かで支えられているものはありますか。監査としてではなく同業者としての礼儀として聞けば、退職するエンジニアの多くは正直に答えます。

第4週: 読んでではなく、やって検証する

文書が存在するから引き継ぎが完了するのではありません。退職する本人以外の誰かが実際にその作業を遂行したときに完了します。

最終週には、後任——社内、暫定、あるいは引き継ぐ事業者——に、彼がまだ訂正できるうちに定型作業を実際に実行させてください。

• リストアを実行する。 本物のバックアップシステムから、端から端まで、使える状態まで。
• 入社処理を実行する。 アカウント作成、ライセンス割当、端末設定、アプリケーション権限付与、そして新しい利用者が業務を遂行できることの確認。
• 退社処理を実行する。 無効化、権限剥奪、メールボックスの引き継ぎ、端末回収、そして漏れがないことの確認。これはPDPO上の統制でもあり、引き継ぎ作業と退職時のアクセス権剥奪の規律が自然に交わる地点です。あちらは一般利用者のアクセスを剥奪する話で、ここでやっているのは管理者の文書化されていない知識を獲得することであり、そちらのほうが難しい半分です。
• 変更を実行する。 パッチを適用し、何かを再起動し、文書化されたロールバックをたどる。
• エスカレーションを起こす。 記録したアカウント情報でベンダーに電話し、彼が不在でもベンダーがあなたの起票権限を認めることを確認する。

文書から実行できないものはすべてギャップであり、それを埋める数日がまだ残っています。

予告期間が終わる前に下すべき判断

道は実質2つしかなく、判断を先送りすること自体が判断です——先送りは、1つ目の道を下手に実行する形にあなたを既定値として落とし込みます。

人を入れ替える。 もう一人、一人情シスを採用する。慣れた選択肢で、組織の形も保たれます。同時に、いま置かれている状況をそっくり再生産します。新しい人が今後5年で自分だけの文書化されていない環境を積み上げ、しかも最終出社日から着任日までの空白は誰も埋めません。

モデルを入れ替える。 マネージドサービスへ移行し、文書化・監視・パッチ適用・ヘルプデスクを誰かの記憶ではなく仕組みにし、個々のエンジニアが設計上交代可能であるようにする。

正直、どちらも筋は通ります。環境の規模、事務所に名前のある人がいることへのこだわり、そして退職する人が本当にインフラ業務をしていたのか大半はヘルプデスクだったのか——すべてが判断材料です。その算数は香港のSMEにおけるマネージドIT対自社IT部門できちんと扱っています。筋が通らないのは惰性で決めることです。採用プロセスを始め、4週間では埋まらず、空白をパートナーのアシスタントと古い請求書で見つけた修理の電話番号で埋める、という形です。

比較: 一人情シスの退職への3つの対処

直接の後任を採用する

• 得られるもの: モデルの継続性、事務所にいる名前のある人、優先順位の完全な掌握。
• 代償: 予告期間内にはおそらく完了しない採用サイクル、埋まらない空白、そしてゼロから再建された同じ単一障害点。
• 向くとき: 役割が本当に広く戦略的で、会社が2人目のIT採用に向かって成長しており、引き継ぎを技術的に監督できる上位者がいる場合。

空白期間に暫定の契約要員を入れる

• 得られるもの: 早い人手と、引き継ぎが失効する前にそれを受け取れる人の存在。
• 代償: 日額と、知識移転が2回起きること——契約要員へ1回、その後任へもう1回——で、各ホップで目減りします。
• 向くとき: 恒久的な判断が4週間では本当に下せず、まず時計を止める必要がある場合。

構造化された引き継ぎを伴うマネージドサービスへ移行する

• 得られるもの: 好意ではなく成果物として自社所有となる文書、誰の記憶にも依存しない監視とパッチ適用、シフトのあるヘルプデスク、臨場する人の背後にあるエスカレーションの厚み。
• 代償: ユーザー単位の月額と、きちんとやれば4週間では終わらない移行プロジェクト。
• 向くとき: 環境が特殊ではなく標準的で、退職者の時間の大半がエンジニアリングではなくサポートに費やされており、会社が人よりも仕組みを買いたい場合。

構造化された引き継ぎの実際の形

3つ目の道を選ぶなら、事業者の提案で検証すべきは、その移行に定義された形があるのか、それとも単なる申込書なのかです。

BrocentのIT移行・オンボーディングは3か月の構造化された引き継ぎで、ブランドではなく「形」が要点なので、記述する価値があります。

• 第1〜2週、調査と監査。 現地訪問、IT資産棚卸、端末監査、ネットワークトポロジー、データ分類とバックアップ/リストア方針のレビュー、そしてインフラ上の弱点トップ3の明示的な特定。この最後の項目が本件では効きます。退職者の環境には、本人が「まずい」と知りつつ手が回らなかったことが、ほぼ必ず3つあります。
• 第2〜4週、知識移転。 エンジニアが退職者に同行するか文書を精読し、管理プラットフォーム上にCMDBを構築して全資産・構成・ライセンスを目録化し、反復作業ごとに標準作業手順を定義します。
• 第3〜6週、シャドーイングと再シャドーイング。 引き継ぐエンジニアが観察下でサポートプロセスを回し、監督なしで基準を満たすまで続けます。並行して特定された3つの弱点に対処し、セキュリティ強化を行います。
• 3か月目以降、サービス開始。 完全移行、P1一次応答15分のSLA付きヘルプデスク、24/7監視、月次レポーティング、文書化されたエスカレーションマトリクス。そして稼働して初めて表面化する知識ギャップを拾うための、正式な稼働後30日レビュー。

書面で求めるべきは成果物です。保証とライセンス記録を含む完全な資産台帳、CMDB、そしてアーキテクチャ・ベンダー連絡先・エスカレーションマトリクス・ライセンス更新・バックアップとDR手順・既知の過去問題を網羅した技術ランブック。次の退職——事業者側であれ自社側であれ——を危機ではなくスケジュールの問題に変えるのは、そのランブックです。

タイムラインについて一点。3か月の引き継ぎは1か月の予告期間より長い。これは矛盾ではなく、第4週ではなく第1週に会話を始めるべき本当の理由です。退職者が在籍しているあいだに起きなければならない部分——知識移転と認証情報の捕捉——は、設計上シーケンスの前半に置かれています。

「自社所有の文書」がすべての要点である理由

一人情シスの退職から得られる深い教訓は「もっと文書化すべきだった」ではありません。人と共に生きる文書は文書ではないということであり、放置すれば同じ失敗が事業者相手にも繰り返されるということです。

検証は簡単で、検討中のどの事業者にも当ててみる価値があります。解約したら、我々は何を受け取るのか。それは契約上の権利か、好意か。

Brocentの答えは、顧客所有のドキュメントと認証情報が、すべてのManaged ITプラン階層に含まれる項目である、というものです。資産記録、認証情報、ランブック、拠点メモは、交渉で得る譲歩ではなく恒常的な方針として顧客に帰属します。どの事業者を使うにせよ、同等の内容を契約に入れてください。書面にしない事業者は、あなたがいま高い金を払って抜け出そうとしている依存を、そのまま作っています。

誇張せずに触れておくべきコンプライアンス上の側面もあります。PDPOのもとで、データ利用者は保有する個人データについて、代理人が処理するものを含めて説明責任を負い続けます。上で述べた認証情報の衛生——個人アカウントの共用をしない、管理者パスワードを個人のパスワードマネージャーに置かない、最終日にきれいに剥奪する、常時アクセス権を持つ第三者の一覧を文書化する——は、まず良いIT実務であり、コンプライアンスはその副産物です。引き継ぎをきちんとやる理由そのものではありませんが、いずれ監査人から問われる理由ではあります。

いま起きているなら、どこから始めるか

辞表がすでに机の上にあるなら、今日の午後から第1週を始めてください。管理者アカウントを列挙し、第2の管理者を作成してテストし、個人名義で登録されているものをすべてリスト化する。この3つが最も早く失効します。

辞表がない状態でこれを読んでいるなら、有用な演習はもっと短い。今週中に、IT担当者に3つ出してもらってください。すべての管理用認証情報の一覧、個人名義のアカウントの一覧、そして自社環境について本人が心配している3つのこと。それが1週間で出てこないなら、引き継ぎがどうなるかはもう分かっています。

いずれにせよ、環境を誰かの記憶ではなく仕組みで文書化・監視・支援したいのであれば、それがユーザー単位のマネージドプランの役割です。退職が目前で、移行シーケンスを自社の予告期間に当てて並べてほしい場合はご相談ください。Brocentは2016年から香港でこの引き継ぎを運用しており、2007年の北京創業以来、構造化された移行を手がけています。

よくあるご質問

IT引き継ぎにはどれくらいかかりますか

捕捉フェーズ——認証情報、資産台帳、依存関係、暗黙知——は、第1週に着手し、重要度ではなく失効の早さで並べれば1か月の予告期間に収まります。マネージドサービスへの完全移行はもっと長く、Brocentの構造化された引き継ぎは3か月で、知識移転は退職者が在籍しているうちに済むよう意図的に第2〜4週に置かれています。両者は直列ではなく重なります。

すでに退職してしまった場合は

引き継ぎではなく復旧の局面で、遅くはなりますが絶望的ではありません。管理権限の回復を優先してください。ベンダーのアカウント復旧手続き(会社登記書類と取締役の承認を求められることが多い)、資産台帳を再構築するための全体ディスカバリースキャン、そしてバックアップが本物かを知るためのリストアテスト。変更能力が落ちる期間を見込んでおいてください——まだ理解していないシステムにリスクのある変更をすべきではありません。前任者が応じてくれるなら、暗黙知の層について短期の有償コンサルティングを組むのは、たいてい価値ある支出です。

ドキュメントは誰のものですか

常にあなたのものであるべきで、契約にそう書かれているべきです。Brocentでは、顧客所有のドキュメントと認証情報はすべてのManaged ITプラン階層に含まれる項目であり、交渉事項ではありません。現在または候補の事業者が文書を自社の財産として扱うなら、あなたは抜け出そうとしている単一障害点を、請求書付きで買い直していることになります。

認証情報が個人のパスワードマネージャーにある場合は

在籍中に処理すれば移管作業ですが、放置すればベンダーごとの個別のアカウント復旧作業になります。業務関連エントリのエクスポートを依頼し、一つずつ独立してログインして検証し、少なくとも2名がアクセスできる会社管理の保管庫に格納してください。以後のルールは、会社の認証情報は会社の保管庫に置くということです。個人のパスワードマネージャーは個人アカウント用であり、これは技術的な好みではなくマネージングパートナーが決める方針の問題です。

引き継ぎなしで事業者が引き受けることはできますか

できますし、実際よくあります。ただし費用も時間も増えます。引き継ぎがあれば単に教えてもらえたことを、監査フェーズで再構築しなければならないからです。ディスカバリーの工数は重くなり、事業者が変更に意図的に保守的になる期間が生まれ、最初の四半期に想定外が出る確率も上がります。退職者との重なりが少しでも——数時間の録画ウォークスルーでも——あれば、その両方を実質的に減らせます。

先に後任を採用すべきですか

必ずしもそうではなく、順序の罠は現実です。採用プロセスを始めても予告期間の時計は止まりません。まず「人を入れ替えるのか、モデルを入れ替えるのか」を決めてください。それが4週間の使い方を決めます。本当に決めかねるなら、引き継ぎをきちんと受け取れる暫定的な体制のほうが、空席よりましです。引き継ぎの窓は二度と開きません。

最も見落とされる項目は何ですか

退職者の個人名義または個人メールで登録されたアカウントです。筆頭はドメインレジストラ、次いでSSL証明書、ベンダーサポートポータル、個人の携帯にシードされた二要素認証。見落とされるのは、自社システムの内側からは見えないからです。ドメイン更新通知が誰かのGmailに届いていることを、あなたのテナントは何も教えてくれません。第1週に、この言葉どおり明示的に聞いてください。

これは退職時処理に含まれますか

退職時処理を含みますが、それよりかなり大きい話です。一般社員の退職時処理は、その人が到達できたものを剥奪することです。管理者の退職時処理は、その人だけが知っていたことを獲得し、そのうえで到達できたものを剥奪することです。そして2番目の手順は、1番目が本当に完了してから実行してはじめて安全です。順序を逆にするのが、会社が自社システムから締め出される典型的な道筋です。