引き継ぎ期間は「会社によってまちまち」が実情です

「先代と一緒に動ける期間は何ヶ月あれば十分ですか」という質問には、実は決まった正解がありません。半年で先代が完全に退いてしまう会社もあれば、2年、3年と会長職で残り、システム周りの相談だけは続くという会社もあります。業種、先代の年齢や体調、後継者側の準備期間によって大きく変わるからです。

ただし、システムの引き継ぎという観点に限って言えば、「期間の長さそのもの」より「期間の長さに応じて、何を優先するか」を早めに決めておくことのほうが重要です。時間が短ければ短いなりの動き方があり、長ければ長いなりの落とし穴があります。この記事では、その分かれ目を整理します。

判断の分かれ目その1: 引き継ぎ期間が数ヶ月と短いケース

引き継ぎ期間が数ヶ月と短いケースと1年以上と長いケースで、優先順位のつけ方がどう変わるかを対比した図。

先代が体調面の事情や年齢、あるいは既に退任時期が決まっているなどの理由で、並走できる期間が数ヶ月しかない場合です。この場合、やるべきことは一つに絞られます。知識の移転より先に、アクセス権と記録を確保することです。

数ヶ月しかない状況で、先代の頭の中にある知識をすべて言語化してもらおうとするのは現実的ではありません。優先順位は次の順番になります。

  1. 先代しか持っていないID・パスワード・契約情報を洗い出すことを最優先にする
  2. システムが「何のためにあるか」を一覧化してもらう(動きの詳細は後回しでよい)
  3. 開発会社・ベンダーとの連絡窓口を先代同席で一度は顔合わせしておく

この優先順位の考え方は会社を継いだ最初の1週間。先代のシステムをどう引き継ぐかで詳しく扱っています。とにかく「先代がいなくなった瞬間に何が止まるか」を先に潰しておく発想です。逆に、業務フローの細かい改善提案や、システムを刷新すべきかどうかの検討は、先代が退いた後で腰を据えて取り組めば十分間に合います。短い期間で欲張って全部やろうとすると、肝心のアクセス権確保が中途半端に終わってしまうのが一番の失敗パターンです。

もし先代からの引き継ぎ書がほとんどない状態で残り期間が少ないと分かったら、引き継ぎ書がない会社が承継後すぐに始めるシステム記録術も参考にしてください。先代がいる間に何を聞いておくべきかの逆算にも使えます。

判断の分かれ目その2: 引き継ぎ期間が1年以上と長いケース

一方で、先代が会長や相談役として長く残る、あるいは後継者が数年前から役員として入っているようなケースでは、時間はたっぷりあります。この場合の注意点は短い場合とは正反対で、「時間があるからこそ、いつまでも先代に判断を委ね続けてしまう」という停滞リスクです。

時間の余裕があると、次のような状態が長く続きがちです。

  • システムの契約更新やベンダーとのやり取りを、結局今も先代が窓口をしている
  • 「そのうち聞けばいい」と思って、細かい仕様の確認を先延ばしにしている
  • 後継者自身がシステムの全体像を把握しないまま、日々の業務だけ回している

引き継ぎ期間が長い場合は、期間の長さに甘えず、あえて早い段階で区切りを設けて権限とアクセスを段階的に移していくことが重要です。たとえば「契約更新のタイミングでは後継者が窓口に立つ」「半年ごとに、先代しか分からない業務を1つずつ棚卸しする」といった具合に、時間を区切ったマイルストーンを自分から作りにいく姿勢が必要です。

また、時間があるからこそ、先代のシステムを「延命するか、作り直すか」をじっくり見極められるのも長期引き継ぎの利点です。焦って刷新を決める必要はなく、先代のシステムを「延命するか、作り直すか」の判断基準を参考にしながら、実際に業務を動かしてみて判断材料を集める時間として使うのが賢明です。

期間の長短に関わらず共通してやるべきこと

短くても長くても、共通して外せないのが「先代の頭の中にしかない情報」を記録に変えていく作業です。これは引き継ぎ期間の途中経過として、定期的に進捗を確認する項目にしておくとよいでしょう。

  • 退職者・異動者のアカウントとPCの棚卸し状況
  • 「触ると壊れる」と言われているシステムがどこにあるか
  • 保守契約・ライセンス契約の名義と更新時期

これらの棚卸しの具体的な手順は先代の退職者PCとアカウント、承継前にやる棚卸しの手順にまとめてあります。引き継ぎ期間がどれだけ残っているかを最初に見極めたうえで、この記事で示した優先順位に沿って動いてみてください。