脱ロックインの第一歩、承継後に自社で管理すべきアカウント一覧

先代が亡くなって、あるいは引退して、あなたは社長になった。会社の実印も、銀行印も、株式も、きちんと引き継ぎの手続きを踏んだはずだ。だが、ホームページの管理画面にログインできるだろうか。基幹システムを動かしているサーバーの契約者は誰になっているだろうか。会計ソフトの契約更新は誰の名義で、誰のメールアドレスに通知が届いているだろうか。

多くの承継社長がこの問いに即答できない。株式や登記には税理士や司法書士という専門家が必ずついているのに、システムやアカウントには相談先がいないまま、先代の代からの「なんとなくの付き合い」だけが引き継がれているケースが非常に多い。この記事は、そんな状態にある社長のために書いている。具体的には、先代の名刺入れの中にベンダーの担当者名だけが書かれた名刺が数枚あり、契約書の現物がどこにあるかは総務のベテラン社員しか知らず、パソコンのログインIDは先代の名前のローマ字のままで、退職した元専務のメールアドレスがまだ生きている、という状態の会社だ。

結論を先に言う。承継後最初にやるべきことは、新しいシステムへの乗り換えでも、値段交渉でもない。自社が今どんなアカウントを持っていて、誰がその管理権限を握っているかを、まず一覧にして自分の手元に取り戻すことだ。これができていない状態で乗り換えや値下げ交渉に動くと、痛い目を見る。逆にこの一覧さえあれば、ベンダーとの関係は驚くほど対等になる。

なぜ「アカウント一覧」が承継の第一歩なのか

承継の実務では、株式・不動産・金融機関との関係など「資産の承継」には専門家が付く。税理士は相続税を計算し、司法書士は登記を変更し、場合によっては事業承継税制の特例を使うために認定支援機関が関与する。ここには明確な手続きのロードマップがある。

一方でシステムやITサービスの契約は、誰も「承継の対象物」として扱ってこなかった。先代の頭の中と、長年付き合いのある担当者との人間関係の中に、契約内容も管理権限も溶け込んでしまっている。承継社長が最初に感じる孤独感の正体はここにある。株や登記には相談先がいくらでもいるのに、「うちの会社、どんなシステムを何個契約していて、誰がパスワードを知っているのか」という質問には、誰も答えを持っていない。

この状態を放置すると、次のような事態が実際に起こる。

• 先代しか知らないIDでログインしていた基幹システムが、先代の入院・引退直後に更新手続きが必要になり、担当者不明のまま止まりかける
• 退職した経理担当者のメールアドレスが会計ソフトの契約者情報として残り、パスワード再発行の連絡がその人にしか届かない
• ホームページの管理画面のログイン情報を知っているのが、10年前に個人事業として受注していた地元のIT担当者一人だけで、その人が体調を崩すと更新も修正もできなくなる

これらは特殊な事例ではない。中小企業の情報セキュリティ対策全般を扱うIPA（情報処理推進機構）の「中小企業の情報セキュリティ対策ガイドライン」でも、情報資産の管理台帳を整備することが基本対策の一つとして位置づけられており、同ガイドラインには実際に企業が使える「資産管理台帳」のサンプル（Excel形式）が付録として公開されている。IT資産の棚卸しは、セキュリティの観点からも、事業継続の観点からも、規模の大小を問わず必要とされている取り組みだ（中小企業の情報セキュリティ対策ガイドライン｜IPA）。

つまり、これは「デジタルに詳しい社長がやる高度な話」ではなく、「会社を継いだら誰でもやるべき基礎的な後始末」だと捉えたほうが正確だ。事業承継の現場では株式や不動産の名義変更が真っ先に話題になるが、日々の業務を実際に動かしているのはシステムとそのアカウントであり、そこが放置されたまま代替わりが完了することはない。

「システムには相談先がいない」という孤独感の構造

株式承継であれば税理士、登記であれば司法書士、労務であれば社労士がいる。それぞれの専門家は「何を確認すべきか」のチェックリストを持っており、承継社長はそれに従えばよい。士業の世界では、承継のタイミングで確認すべき事項が体系化されており、初めて社長になった人でも迷わずに済むようになっている。

システムにはこの構造が存在しない。理由は単純で、中小企業のシステム契約は次のような特徴を持つからだ。

契約更新は自動継続がほとんどで、誰も「今何を契約しているか」を定期的に見返す機会がない。担当者は先代個人の知り合いであることが多く、契約書よりも人間関係が先に立つ。パスワードは付箋やExcelファイルに書かれ、退職者が出ても回収・変更のプロセスが存在しない。

この状態で先代が急にいなくなると、社長は「何から手をつければいいか分からない」まま、目の前のベンダーの言うことをそのまま信じるしかなくなる。これが「脱ロックインの第一歩を踏み出せない」最大の理由だ。ベンダーロックインから脱するためには、まず自分がロックインされている範囲を正確に知る必要があるが、その範囲を知るための地図（一覧）自体が存在しないのだ。ロックインがどのように生まれるかの典型パターンは、ベンダーロックインとは？先代の代から陥りがちな典型パターンで整理している。

この孤独感は、決して大げさな表現ではない。株式の分散を防ぐための遺言や、会社分割の是非を相談できる専門家は世の中に大勢いる。しかし「うちの基幹システムをこのまま使い続けるべきか」「このベンダーとの契約は適正な水準か」という問いに答えられる相談先を、多くの承継社長は持っていない。顧問税理士は税務の専門家であり、システムの契約内容や技術的な妥当性までは踏み込まない。付き合いのある商工会議所の経営相談も、個別のベンダー契約の中身までは扱わないことが多い。結果として、承継社長は「今のベンダーに聞くしかない」という、利害関係者に自分の判断基準を委ねる状態に陥りやすい。

まず一覧にすべき「アカウント」の3分類

「アカウント一覧」と言われても、範囲が広すぎて何から手をつければいいか分からないという声はよく聞く。実務上は、次の3つの分類で洗い出すとやりやすい。

分類1：業務の生命線に直結するアカウント

会社の日々のお金の流れや、顧客との接点が止まると即座に業務が止まるものだ。

• 基幹システム(受発注・在庫・生産管理など)
• 会計ソフト・給与計算ソフト
• 銀行のインターネットバンキング
• 電話・FAXのクラウド化がされていればその管理画面
• ECサイトやオンライン予約システムの管理画面

これらは仮に契約が切れたり、管理者権限を失ったりすると、その日のうちに会社の売上や支払いが止まる可能性がある。承継後の棚卸しでは、まずこの分類を最優先で確認する。

分類2：対外的な信用・情報発信に関わるアカウント

止まっても即日に業務は止まらないが、放置すると会社の信用や集客に直接ダメージを与えるものだ。

• 会社のホームページ・ドメイン・レンタルサーバー
• Googleビジネスプロフィール(旧Googleマイビジネス)
• SNSアカウント(会社公式のもの)
• メールサーバー・独自ドメインのメールアカウント

ドメインの更新を忘れて会社のホームページが数日間表示されなくなる、という事故は決して珍しくない。特にドメインの契約者情報が先代個人のメールアドレスになっている場合、更新通知そのものに誰も気づかないまま失効日を迎えてしまう。

分類3：バックオフィスの周辺サービス

契約自体は残っているが、使っているのかどうかも怪しいものだ。承継後の棚卸しで一番「これ何のために契約してるんだろう」という発見が多いのがこの分類になる。

• 名刺管理ソフト、勤怠管理ソフト
• クラウドストレージ、ファイル共有サービス
• セキュリティソフト、バックアップサービス
• 使われなくなった旧システムのサブスクリプション

この3分類でリストアップしていくと、たいてい20〜40個ほどのアカウント・契約が出てくる。従業員10〜100人規模の会社であれば、これくらいの数になることが多い。「思っていたよりずっと多い」という反応が最も一般的だ。ある会社では、5年前に導入して結局使われなくなった勤怠管理ソフトの契約が、誰も解約手続きを取らないまま毎月課金され続けていた、というようなことが後から見つかることもある。

一覧に載せるべき項目

アカウント名を並べるだけでは意味がない。承継後の管理に使える一覧にするためには、最低限次の項目を記録する。

この一覧そのものが、いわゆるシステム管理台帳と呼ばれるものだ。一度作れば終わりではなく、契約が増減するたびに更新していく前提の「生きた台帳」として運用することが望ましい。システム管理台帳という言葉自体は聞き慣れないかもしれないが、内容としては「会社の設備台帳」や「固定資産台帳」のIT版だと考えれば理解しやすい。設備であれば経理担当が台帳を持っているのが当たり前なのに、システムだけがその対象から漏れていたというのが、多くの中小企業の実態だ。

一覧を作る過程で、契約者名義が「先代個人」になっているケースに遭遇することがある。会社の看板を掲げているサービスなのに、支払いが先代個人のクレジットカードから引かれている、というパターンだ。これは承継の実務上見過ごされがちだが、法人としての契約に切り替えておかないと、先代の個人資産の整理(相続・遺産分割)のタイミングで思わぬトラブルの種になる。個人のクレジットカードが失効した瞬間に、会社の重要なサービスの支払いが止まる、という事故も実際に起こり得る。

洗い出しの実務：どこを見れば見つかるか

「そもそも何を契約しているか分からない」という状態から始める場合、次の場所を順番に確認すると効率がよい。

1. 銀行口座・クレジットカードの取引履歴(過去1年分) — 毎月決まった額が引かれている取引先をリストアップする。これが最も確実な出発点になる
2. 会社の代表メールアドレスの受信箱 — 「お支払いのお知らせ」「ご利用料金確定のお知らせ」といった件名で検索する
3. 総務・経理の担当社員への聞き取り — 特に長年勤めている古参社員は、契約の経緯や過去のいきさつを知っていることが多い
4. 顧問税理士への確認 — 決算書の「通信費」「システム利用料」「保守料」といった費目の内訳を見せてもらう
5. パソコン・スマートフォンのブラウザに保存されたパスワード — 先代が使っていた端末があれば、保存済みのログイン情報が手がかりになる

この過程で古参社員に協力してもらう際は、「先代の悪口を言っているわけではない」という前提を丁寧に伝えることが大切だ。承継直後の社長が契約を洗い出す動きを見せると、古参社員の中には「先代のやり方を否定されている」と感じる人が出てくる。角を立てずに進めるためには、「引き継ぎのために整理している」という説明を一貫して使い、個々のベンダーや契約の是非についてはこの段階では評価しない、という姿勢が有効だ。

実務上は、社長自身がすべての聞き取りを一人でやろうとせず、経理担当や総務担当に「一緒に確認してほしい」と協力を求めたほうがスムーズに進む。特に銀行の取引履歴からベンダー名を洗い出す作業は、経理担当のほうが取引先の略称や過去の経緯を知っていて早く進むことが多い。

見えてくる「古いベンダーとの関係」の実態

一覧が完成すると、多くの承継社長が次のような構造に気づく。

• ホームページも基幹システムも、先代の代からの1社にすべてを任せている(いわば「かかりつけ医」が1人しかいない状態)
• そのベンダーとの契約書が存在しない、あるいは10年以上前の古い条件のまま自動更新されている
• システムが古い技術で作られていて、今どきの改修依頼をしても「対応できない」「高額な見積もりが出る」と言われる
• そもそもそのベンダー自身が高齢化していて、後継者がいない、あるいは廃業のリスクがある

こうした構造が見えてきたときに、承継社長が取るべき態度は「即座に縁を切る」ことではない。先代の代からの付き合いには、緊急時に無理を通してくれた実績や、価格面での温情的な配慮が積み重なっている場合が多く、これを一方的に切ることは、地域での会社の評判にも影響しうる。大切なのは、関係を「感情」ではなく「契約」として見直す視点を持つことだ。

長年一社に業務を任せてきた結果、システムの内部構造も、データの持ち出し方法も、そのベンダー以外の誰も分からない状態になっていることがある。これはレガシーシステム特有の問題で、システム自体が古いことに加えて「誰も全体像を知らない」という属人化が二重に重なっている。この状態で急にベンダーとの関係が切れると、社内の誰もシステムの内部を把握していないまま取り残されることになる。

契約を見直すときに角を立てない進め方

古いベンダーとの関係を整理する際、次の順番で進めると関係を壊さずに済むことが多い。

1. まず自社の一覧を完成させる(ここまでの作業)。相手に何かを言う前に、自分たちの立ち位置を正確に把握する
2. 契約書・見積書の現物を取り寄せる。「代替わりしたので、引き継ぎのために契約内容を確認させてください」という説明で問題なく取り寄せられることが多い。取り寄せるべき資料の具体的な一覧は、開発会社の乗り換え手順、承継を機に整理する引き継ぎ資料一覧を参照してほしい
3. 今のシステムを離れる場合に、自社のデータをどの形式で、どの範囲まで持ち出せるかを事前に確認する。これを確認せずに関係を切ると、大量のデータが手元に戻らないまま孤立するリスクがある
4. 今後の方針を相手に伝える際は、「切る」ではなく「見直す」という言葉を使う。全部を一度に変える必要はなく、優先度の高いものから段階的に見直すという姿勢を示すと、相手も協力的になりやすい
5. サポート終了が近いシステムは、関係の良し悪しにかかわらず先に対応する。感情面の調整より前に、動かなくなるリスクへの対応を優先する

このうち3番目の「データの持ち出し」の確認は、特に見落とされやすい。長年付き合いのあるベンダーであるほど、「いつでも出せますよ」という口約束だけで済まされ、実際に出力形式やAPI連携の可否まで確認する社長は少ない。契約を見直す本気度が固まる前の、雑談レベルの段階でこの点だけは早めに確認しておくと、後の判断がしやすくなる。確認すべき具体的な観点は、データをエクスポートできるか、古参ベンダーからの乗り換え前に確認すべきことにまとめている。

よくある失敗パターン

一覧作りを後回しにした結果、実際に起こりがちな失敗をいくつか紹介する。

• 退職者アカウントの放置。経理担当が退職した後も、会計ソフトの管理者権限がそのアカウントに残っていた。退職者本人に悪意がなくても、アカウントが有効なままであることはセキュリティ上のリスクになる
• 契約の多重化。似た機能のクラウドサービスを、部署ごとに別々に契約していたことが後から発覚し、毎月無駄なコストを払い続けていた
• 更新忘れによる停止。ドメインの更新通知が先代の個人メールアドレスにしか届かず、契約更新を忘れてホームページが一時的に表示できなくなった
• 交渉材料の欠如。「このシステム、今の使用状況に対して割高では」と感じても、そもそも契約内容や競合の相場を把握していないため、値下げ交渉の材料がなく、言われた額をそのまま払い続けている。割高なSaaS契約をどう見直せるかは、高くなった先代契約のSaaSを乗り換え・縮小する選択肢で選択肢を整理している
• 後任への引き継ぎ漏れ。社長自身が一覧を整理した後、今度は自分が退任するときのために引き継ぎ資料を作り忘れる。承継の連鎖は一代で終わらないという意識が薄い

これらはどれも、一覧さえあれば事前に防げたか、少なくとも早期に気づけた問題だ。特に退職者アカウントの放置は、悪意の有無にかかわらず、外部からの不正アクセスの入り口になりうるという点で軽視できない。実際に使われていないアカウントほど、パスワードの変更や監視の対象から漏れがちで、結果として最も脆弱な入口になってしまう。

一覧を作った後にできること

アカウント一覧が完成すると、承継社長の手元には次のような「交渉力」が生まれる。

• どのシステムにどれだけのコストがかかっているかが一目で分かるので、コスト全体の優先順位付けができる
• 契約者名義・管理者権限を会社(法人)に統一できるので、担当者の退職や引退があっても業務が止まらない体制になる
• ベンダーとの契約更新のタイミングを自分で把握できるので、「言われるままに更新する」状態から「こちらから条件を提示する」状態に変わる
• どこまで自社の人材で対応できて、どこを外部のベンダーに任せるべきかの判断を、感覚ではなくデータに基づいて考えられるようになる

これは特定のベンダーを非難するための資料ではない。自社の現状を正確に把握し、今後の投資判断を自分の頭で行うための土台だ。株式承継における「株主名簿の確認」や、登記における「不動産の権利関係の確認」と同じ意味を持つ、承継実務の一部だと考えてよい。

一覧をもとに全体像を眺めると、「このシステムは1社にすべて任せる形になっているが、契約更新のタイミングで一部だけ別の選択肢を検討してもよいのではないか」という気づきが生まれることもある。マルチベンダーという発想は、必ずしも「複数のベンダーと同時に契約する」ことを意味しない。重要な業務ほど「もし今のベンダーが対応できなくなったら、代わりの選択肢があるか」を事前に把握しておく、という保険的な考え方として理解しておくとよい。

一覧作りにかかる時間の目安

従業員10〜100人規模の会社であれば、次のような時間感覚で進められることが多い。

• 銀行・カード履歴の確認と洗い出し：半日〜1日
• 社員への聞き取り・契約書の収集：1〜2週間(相手の都合に合わせる時間を含む)
• 一覧の整理・記入：数時間〜1日

つまり、本気で取り組めば1ヶ月以内に一通りの一覧は完成する。承継直後は株式・登記・取引先への挨拶など、やるべきことが山のようにあるが、その合間にこの作業を差し込んでおくことで、後々の負担を大きく減らせる。

一覧作りを後回しにしがちな理由の一つは、「今すぐ困っていないから」という感覚だ。しかし承継直後というのは、実は最もこの作業をしやすいタイミングでもある。先代がまだ健在で相談できるうちに、あるいは古参社員が在籍しているうちに情報を集めておかないと、時間が経つほど手がかりが失われていく。逆に承継から数年が経ち、契約の経緯を知る人が誰もいなくなってから洗い出しを始めると、格段に手間がかかる。

社内に一覧を定着させるための工夫

一覧を一度作っただけで終わらせず、社内に根付かせるためには、いくつかの運用上の工夫が必要になる。

まず、一覧の更新を「誰か一人の仕事」にしないことだ。社長が一人で作って、社長の頭の中だけにしまっておくと、結局は先代の時代と同じ属人化を繰り返すことになる。経理担当・総務担当と共有し、新しい契約を結ぶときには一覧に追加することをルール化しておく。

次に、新しいシステムを導入する際に、契約前の段階で一覧の項目(契約者名義・管理者権限者・データの持ち出し可否)を確認する習慣をつけることだ。これを最初から徹底しておけば、次の代への引き継ぎのときに、今回のような苦労を繰り返さずに済む。

最後に、年に一度程度、決算のタイミングなどに合わせて一覧を見直す機会を設けることだ。決算書の費目を見返すタイミングは、契約の棚卸しをするのに都合がよい。顧問税理士との面談の場で「今契約しているシステム、一度整理してみようと思う」と一言添えるだけでも、税理士側からも有益な視点が返ってくることがある。

管理者権限を「個人」から「会社」に付け替える

一覧が完成したら、次にやるべき実務的な作業が、管理者権限の付け替えだ。多くのシステムでは、契約時のメールアドレスが「先代個人のもの」や「すでに退職した社員のもの」になっている。これを会社の代表アドレスや、承継社長が実際に使うアドレスに変更する作業は、地味だが確実に効果がある。

具体的な手順としては、次のような流れになる。

1. ベンダーに連絡し、契約者情報(名義・メールアドレス・電話番号)を会社名義に変更したい旨を伝える
2. 管理者権限を持つアカウントを、先代個人のものから会社の代表アドレス、または承継社長個人のアドレスに変更する
3. パスワードをこのタイミングで一新する。先代の代から変更されていないパスワードは、外部に流出しているリスクを否定できない
4. 変更が完了したら、一覧の「ログインID・管理者権限者」欄を更新する

この作業を後回しにしていると、次のような事態が起こりやすい。たとえば会計ソフトの契約者メールアドレスが退職した経理担当のものになっていた場合、パスワードを忘れて再発行が必要になったときに、本人にしか届かないメールを待つしかなくなる。退職者と連絡が取れなくなっていれば、最悪の場合はサポートセンターに事情を説明して本人確認からやり直す、という手間のかかる対応を迫られる。

管理者権限の付け替えは、一つひとつは数分から数十分の作業だが、20〜40件のアカウントすべてに対して行うとなると、まとまった時間が必要になる。一覧の「業務への影響度」が高いものから優先順位をつけて進めるとよい。

実際によくある「発覚」のパターン

承継社長がこの棚卸し作業を実際にやってみると、想定していなかった発見に遭遇することが多い。ここでは、よく見られるパターンをいくつか紹介する。

一つ目は、「もう使っていないはずのシステムが、実は裏側で稼働していた」というパターンだ。表向きは新しいシステムに切り替えたはずなのに、旧システムのデータ連携部分だけが解約されずに残っており、毎月の請求が発生し続けていた、というケースがある。

二つ目は、「同じような機能のサービスを、部署ごとに別々に契約していた」というパターンだ。営業部と製造部でそれぞれ別のクラウドストレージを契約していて、しかも互換性がなくデータのやり取りに毎回手間がかかっていた、というような状態が見つかることがある。

三つ目は、「契約者が先代個人のまま、しかも既に支払い方法(クレジットカードなど)が失効していた」というパターンだ。幸い自動的にサービスが止まる前に発覚したケースもあれば、実際に一定期間サービスが止まってから気づいた、というケースもある。

四つ目は、「先代が個人的な好意で無償対応してくれていたベンダーが、実は正式な契約書を結んでおらず、口約束だけで長年運用されていた」というパターンだ。この場合、承継後にそのベンダーの姿勢が変わり、急に有償化を求められたり、対応の質が変わったりすることがある。口約束の関係は、先代個人との信頼関係の上に成立していたものであり、代替わりを機に見直されるのは自然な流れだと理解しておいたほうがよい。

これらはいずれも、日頃から一覧を運用していれば早期に気づけたはずの事象だ。逆に言えば、一覧作りは「今何が起きているか分からない」という不安を解消するための、最も直接的な手段だといえる。

顧問税理士・社労士との連携で見えてくること

システムの棚卸しは、社内だけで完結する話ではない。顧問税理士や社労士との連携によって、思わぬ発見につながることもある。

顧問税理士に決算書の「通信費」「システム利用料」「保守料」「リース料」といった費目を一件ずつ確認してもらうと、社長自身も把握していなかった契約が見つかることがある。特にリース契約になっているシステム関連の機器(複合機やサーバー機器など)は、通常の「システム契約」とは別の書類・別の担当窓口で管理されていることが多く、見落としやすい。

社労士との連携では、勤怠管理システムや給与計算システムのアカウント管理について、労務管理の観点から助言をもらえることがある。特に退職者のアカウントが残っている状態は、情報漏洩のリスクだけでなく、労務トラブルが起きた際の記録管理の観点からも望ましくない。

このように、一覧作りは社長一人の作業ではなく、既存の専門家(税理士・社労士)の視点を借りながら進めることで、より確実なものになる。専門家側も、普段は税務や労務の相談を受けることが多いため、システムやアカウントの整理について相談されることは新鮮に受け止められることが多く、むしろ良好な関係づくりにつながることもある。

一覧を「次の代」にも引き継ぐという発想

ここまでは、承継社長自身が先代からの引き継ぎに苦労した経験を前提に話を進めてきた。しかし、せっかく苦労して作った一覧も、自分が退任するときに同じように次の後継者に引き継がなければ、結局は一代限りの取り組みで終わってしまう。

事業承継は一度きりの出来事ではない。今のあなたが先代から会社を継いだのと同じように、いずれあなたも誰かに会社を引き継ぐ日が来る。そのときに、今回のような苦労を次の代に負わせないためには、一覧を「作った本人が困らないための資料」ではなく、「会社に残る資産」として位置づける必要がある。

具体的には、次のような運用を心がけるとよい。

• 一覧は個人のパソコンやクラウドストレージの奥深くにしまわず、経理や総務など複数の担当者がアクセスできる場所に置く
• 新しい契約を結ぶたびに、その場で一覧に追記することを社内のルールとして明文化する
• 年に一度は経理担当・総務担当と一緒に見直しの時間を取り、契約内容の変化を反映する
• 管理者権限は、可能な限り個人名義ではなく、役職や部署に紐づいたアカウント設計にしておく

この最後の点は特に重要だ。「社長個人」のメールアドレスをすべての管理者権限の受け皿にしてしまうと、結局は今回と同じ問題が次の代でも繰り返される。可能であれば、システムの管理者権限は「代表者」という役職に紐づけるか、複数人がアクセスできる共有の窓口(共有メールアドレスなど)を用意しておくと、個人の異動や退任があっても引き継ぎがスムーズになる。

デジタルの引き継ぎも、事業承継の一部だと捉える

事業承継の議論では、株式の分散防止、後継者への集中、相続税対策といった「資産」の話題が中心になりやすい。もちろんこれらは重要だが、日々の業務を実際に動かしているのはシステムであり、そのシステムへのアクセス手段であるアカウントだ。ここが整理されていない状態は、実質的には「会社の運転席の鍵の場所が分からないまま、車だけを譲り受けた」状態に近い。

株式の承継には税務上の期限があり、登記の変更には法律上の手続きがある。一方でアカウントの整理には明確な期限は存在しない。だからこそ後回しにされやすく、気づいたときには「誰も分からない」状態が何年も続いていた、ということが起こる。承継後のタイミングで一度腰を据えて取り組んでおくことが、後々の負担を大きく減らす最も確実な方法だ。

まとめ：一覧は「攻め」のための土台である

承継後にアカウント一覧を作るという行為は、後ろ向きな整理作業に見えるかもしれない。しかし実際にはこれは、これから先代の代よりも会社を良くしていくための、最も地味で最も重要な準備作業だ。

株や登記には専門家がいて、進め方の型がある。システムやアカウントにはその型がまだ存在しないからこそ、承継社長が自分の手で最初の一覧を作ることに価値がある。一覧が完成した瞬間から、あなたは「先代の頃からのやり方をなんとなく続けている社長」から、「自社の状況を正確に把握し、次の一手を自分で選べる社長」に変わる。それが、脱ロックインの実質的な第一歩になる。

よくある質問

Q. 先代が亡くなっていて、本人から話を聞けない場合はどうすればいいですか。

A. 銀行・カードの取引履歴と、顧問税理士が持っている決算書の内訳が最も確実な出発点になる。加えて、先代が使っていたパソコンやスマートフォンが残っていれば、ブラウザに保存されたログイン情報や、メールの受信履歴が重要な手がかりになる。古参社員への聞き取りも並行して進めるとよい。

Q. ベンダーに「契約内容を教えてほしい」と言うと、警戒されませんか。

A. 「代替わりに伴い、引き継ぎのために契約内容を確認したい」という説明であれば、通常のベンダーであれば違和感なく応じてくれる。もし契約書の開示すら渋る、あるいは曖昧な返答しかしないベンダーがいた場合、それ自体が今後の関係を見直す際の重要な判断材料になる。

Q. 一覧を作るのは自分でやるべきですか、それとも外部に頼んでもいいですか。

A. 最初の洗い出し(銀行履歴の確認や社員への聞き取り)は、社内の事情を知っている人間が動いたほうが早い。ただし、一覧が完成した後に「このシステム構成は今の会社の規模や業務に合っているか」を評価する段階では、第三者の技術的な視点を入れたほうが客観的な判断ができる。すべてを自分だけで抱え込む必要はない。

Q. 一覧を作った結果、乗り換えたほうがいいシステムが見つかったら、すぐに動くべきですか。

A. すぐに動く必要はない。まずサポート終了が迫っているもの(動かなくなるリスクがあるもの)を優先し、それ以外は契約更新のタイミングに合わせて段階的に見直すのが現実的だ。一度に全部を変えようとすると、業務への負荷も、既存ベンダーとの関係悪化のリスクも大きくなる。