引き継ぎ書がない会社が承継後すぐに始めるシステム記録術
先代が急に倒れた、あるいは「そろそろお前に」と言われて引き継いだ会社に、システムの引き継ぎ書は存在しない。パスワードは先代の頭の中、契約書はどこかのキャビネット、業務システムを触れる人間は経理担当のベテラン社員一人だけ——こうした状態で社長になった人は、決して少数派ではない。
株式や登記の引き継ぎには税理士や司法書士という専門家がついてくれる。しかし会社のシステムやITまわりを「誰に相談すればいいのか」は、驚くほど誰も教えてくれない。先代に聞いても「そんなの分からん、〇〇さんに聞け」と言われ、その〇〇さんも実は全体像を把握していない、というのがよくある展開だ。
この記事は、次のような状態にある人に向けて書いている。
- 先代からシステムの説明を一切受けないまま代表印を受け取った
- 会社のどこにどんなシステムがあるか、誰に聞けば分かるのか見当がつかない
- 「今は動いているから」で放置されている仕組みが怖い
- 古参社員に気を遣いつつ、システムの実態を聞き出したい
結論を先に言う。引き継ぎ書がない会社がまずやるべきことは、壮大なIT改革でも高額なシステム刷新でもない。「何が」「どこで」「誰の手で」動いているかを1枚の記録に書き出すこと、それだけだ。中小企業庁の事業承継ガイドラインでも、経営者の頭の中にしかない業務知識やノウハウは、文書化されなければ承継後に失われると指摘されている（事業承継ガイドライン第3版｜中小企業庁）。これはシステムにもそのまま当てはまる。この記事では、承継直後の限られた時間と人手の中で、実務としてどう記録をつけていくかを具体的に説明する。
なぜ承継直後の会社にシステムの引き継ぎ書が存在しないのか
多くの中小企業では、先代がシステム導入の判断から契約、パスワード管理までを一人で担ってきた。売上や資金繰りには目を配っても、「このExcelは誰が更新しているか」「このソフトの契約はいつ切れるか」は記録する習慣そのものがなかったケースが大半だ。
これは先代の怠慢というより、多くの中小企業に共通する構造的な問題だ。IT担当を専任で置く余裕がなく、経理や総務の誰かが片手間で管理する、いわゆる「ひとり情シス」状態に陥りやすく、属人化が進みやすいことは複数のITベンダーの調査コラムでも繰り返し指摘されている。専任担当が不在のまま業務を回している以上、引き継ぎ書という発想自体が生まれにくい。
情シスの業務を手順書として整理し、業務フローを標準化することが大切。責任者や他部署と手順書を共有し、社内でいつでも確認できるようにすれば、担当者が不在でも業務を円滑に行える
この指摘は退職者の引き継ぎ問題として語られることが多いが、承継はその極端な形だ。前任者（先代）が二度と社内にいない前提で、記録をゼロから作り直す必要がある。
さらに承継特有の事情として、先代が「経営」と「現場の仕組み」を分けて考えていなかったことが多い点も挙げられる。創業者や二代目が自ら販売管理ソフトの選定をし、請求書のフォーマットを決め、時には自分でExcelマクロを組んでいたようなケースでは、その人がいなくなること自体が「仕様書の消失」に等しい。中小企業庁の事業承継ガイドラインは、事業承継のステップを「準備の必要性の認識」「経営状況・経営課題の見える化」「事業承継に向けた経営改善（磨き上げ）」の3段階で整理しているが（事業承継ガイドライン｜中小企業庁）、多くの中小企業ではこの「見える化」の対象に業務システムが含まれていない。財務諸表や株主構成は見える化されていても、日々の業務を支えるツールやソフトウェアは見落とされたまま承継の日を迎えてしまう。
つまり、あなたの会社に引き継ぎ書がないのは特殊な事情ではなく、多くの中小企業が通る道だと理解しておいてほしい。自分を責める必要はない。今からリカバリーすればいいだけの話だ。
承継直後2週間の動き方：ヒアリングとその場でのメモ化
いきなり立派な台帳を作ろうとすると挫折する。承継直後は経営の意思決定、取引先への挨拶、金融機関対応などやることが山積みで、システムの棚卸しに何日も割く余裕はない。だからこそ、最初の2週間は「聞いたその場でメモする」ことに徹する。
具体的には、次の3者に個別にヒアリングする。
- 先代（まだ会社に関われる場合）：契約しているソフト・サービス、パスワードの保管場所、過去のトラブル履歴
- 経理担当：会計ソフト、給与計算、請求書関連のツール
- 現場の古参社員：日常業務で使っているExcelやAccessの業務ツール、VBAマクロで自動化された処理
ヒアリングは身構えさせないことが重要だ。「システムの調査をします」と切り出すと、古参社員は「自分の仕事のやり方を否定されるのでは」と警戒しやすい。「先代から引き継ぎがなくて困っている。教えてほしい」という姿勢の方が、情報は集まりやすい。
- 「このファイル、誰が最初に作ったか覚えてますか」
- 「これが止まったら、他に代わりにできる人はいますか」
- 「パスワードを忘れたとき、誰に聞いてますか」
- 「最近、システムがおかしいと感じたことはありますか」
- 「このソフト、いつ頃から使っていますか」
この5つの質問だけでも、属人化の実態と、特定の一人に業務が集中している危険な箇所がかなり見えてくる。特に「代わりにできる人はいますか」という質問は重要だ。答えが「いない」であれば、それは会社にとって最も脆い箇所であり、優先的に手当てすべき対象だとその場で分かる。
ヒアリングの順番にもコツがある。先代がまだ元気に会社に出入りしている場合は、先代への聞き取りを最初に済ませておきたい。健康上の理由や急な引退で承継が発生したケースでは、この機会自体が失われていることも多く、その場合は経理担当・古参社員からの情報収集に頼らざるを得ない。誰からも聞けない部分については「不明」として台帳に書き残しておくこと自体に意味がある。「分からないことが分かっている状態」と「そもそも存在に気づいていない状態」には、リスク管理上、天と地ほどの差があるからだ。
システム管理台帳という「地図」を作る
ヒアリングで集めた情報は、その日のうちに1つの表にまとめる。これがシステム管理台帳の原型になる。承継直後に必要なのは網羅性ではなく、まず「地図があること」自体だ。列は最低限、次で足りる。
| 項目 | 記入例 |
|---|---|
| システム/ツール名 | 販売管理ソフト〇〇 |
| 用途 | 受注・在庫管理 |
| 利用部署 | 営業・倉庫 |
| 契約会社・担当者 | 〇〇システムズ 担当:山田氏 090-xxxx |
| ログイン情報の保管場所 | 経理部ロッカーの手帳 |
| 詳しい人（社内） | 経理の佐藤さん |
| 稼働年数・導入年 | 2011年〜 |
| 次回更新・契約更新時期 | 毎年3月 |
IPA（情報処理推進機構）が公開している「中小企業の情報セキュリティ対策ガイドライン」には、資産管理台帳のサンプル書式が付録として用意されており、機器・ソフトウェアの管理項目を洗い出す際の参考になる（中小企業の情報セキュリティ対策ガイドライン｜IPA）。自社でゼロから項目設計をするより、既存の書式を土台に必要な列を足し引きする方が早い。
台帳を作る過程で、次のようなシステムが見つかることが多い。
- 誰も更新方法を知らないAccess（データベースソフト）の顧客管理ツール
- サポートがとうに切れている古い会計ソフト（EOL（サポート終了）状態）
- 特定の社員のPCにしか入っていないマクロ付きExcel
これらは即座に置き換える必要はない。まず「存在する」と認識し、台帳に載せることが第一段階だ。古くから使われてきた仕組みの扱いをどうするかは、事業の状況が落ち着いてから検討すればいい。
台帳を作る際によくある失敗は、いきなりExcelで凝った表を作ろうとして時間を溶かしてしまうことだ。承継直後の2〜3ヶ月は、紙のノートでも、スマホのメモアプリでも構わない。まず書き出すことを優先し、清書は後回しにする。清書の完成度より「今日聞いた情報を今日のうちに書き残す」スピードの方が、この段階では圧倒的に重要だ。
また、台帳の粒度についても悩みどころだ。「販売管理ソフト」のような大きな単位だけでなく、「見積書のExcelテンプレート」「請求書送付用のメール共有アカウント」のような小さな単位まで書き出すべきか迷うことがある。目安としては、「それが止まったら、誰かが仕事で困るかどうか」で判断するとよい。困る人が一人でもいれば、規模の大小にかかわらず台帳に載せる価値がある。
契約書・パスワードという「物理的な引き継ぎ漏れ」を潰す
台帳作りと並行して、物理的な資料の所在確認も進める。承継の実務では株式や不動産の名義変更に意識が向きがちだが、システム関連の契約名義も見落とされやすい。
- ソフトウェアやクラウドサービスの契約者名義が先代の個人名になっていないか
- ドメインやレンタルサーバーの契約者・支払い方法が先代のクレジットカードのままになっていないか
- 銀行系のインターネットバンキングの管理者権限が先代のIDしか登録されていないか
これらは「システムの契約」であると同時に「名義」の問題でもある。名義変更を放置すると、先代が完全に会社を離れたあと、パスワードリセットすらできなくなるリスクがある。特にドメインとレンタルサーバーは契約更新が止まった瞬間に会社のホームページやメールが止まるため、優先順位を上げて確認したい項目だ。
ドメインの名義移管については、契約している登録事業者（レジストラ）のマイページから「WHOIS情報の名義変更」あるいは「オーナー移管」という手続きで対応できることが多い。管理会社そのものを変更する「レジストラ移管」と、登録者名義だけを変更する「名義移管」は別の手続きなので、混同しないよう注意したい（ドメイン移管の手順を管理会社別に解説｜サイト売買クラブ）。口約束や引き継ぎ資料なしに名義だけ放置してしまうと、後々トラブルの火種になりやすいため、契約者情報の書面またはメールでのやり取りを最低限残しておくことが望ましい。
パスワードそのものについては、台帳に生パスワードを書き込むのは避け、「保管場所」を記録するに留めるのが安全だ。パスワード管理ツールへの移行は、承継直後の混乱期にはハードルが高いので、まずは「金庫の中の手帳」「経理の引き出し」のような物理的な保管場所を全員が把握できる状態にするだけでも前進になる。
見落とされがちだが、ドメインやサーバーだけでなく、以下のような契約も名義確認の対象にしておきたい。
- 会計ソフト・給与計算ソフトのクラウド契約
- 電子帳簿保存法対応のために導入した請求書クラウドサービス
- 防犯カメラやクラウド録画サービスなど、店舗・工場に紐づく契約
- 先代個人のスマートフォンにインストールされている業務用アプリ
これらは日々の業務では意識されにくいが、契約者が先代個人のままだと、支払いが滞った瞬間にサービス停止という形で表面化する。台帳の「契約会社・担当者」の欄には、契約者名義が「法人」か「個人（先代）」かも書き添えておくと、後で名義変更の優先順位をつけやすい。
台帳を「作って終わり」にしないための更新ルール
台帳は作った瞬間から古くなり始める。中小企業庁のガイドラインが強調するように、知的資産の見える化は一度きりの作業ではなく、経営者自身が振り返りながら関係者と対話を重ねるプロセスとして位置づけられている。システムの記録も同様に、承継直後の一過性のイベントで終わらせず、運用の一部に組み込む必要がある。
最低限、次のルールだけは決めておきたい。
新しいソフトやクラウドサービスを契約するときは、契約と同時に台帳に1行追加する。これを「システム導入時の必須手順」として社内周知する。
このルールがないと、半年後にはまた新しいツールが誰にも知られないまま増え、台帳と実態が乖離していく。台帳の更新担当者を経理や総務の誰か一人に固定し、四半期に一度は内容を見直すサイクルを作ると、記録が形骸化しにくい。
更新のタイミングは、契約の発生時だけでなく、次のようなイベントとセットにするとさらに漏れが少なくなる。
- 社員の入社・退職時（その社員が使っていたアカウント・ツールを確認する）
- 決算のタイミング（経費として計上されているソフトウェア利用料を洗い出す）
- パソコンやサーバーの入れ替え時（旧機器に何が入っていたかを確認してから廃棄する）
また、記録した情報の中には、脆弱性が放置されたままのソフトウェアが見つかることもある。パッチマネジメントが長期間行われていないシステムが判明した場合は、台帳の「備考」欄にリスクとして書き添えておくと、後で対応の優先順位をつけやすい。パッチが当たっていないシステムは、それ自体がすぐに事故を起こすわけではないが、台帳に記録がなければ「気づかれないまま放置される」という点で最も危険な状態にある。記録があるだけで、少なくとも「知らなかった」という事態は避けられる。
台帳の置き場所についても決めておく必要がある。承継直後にありがちな失敗は、社長個人のPCやクラウドストレージだけに台帳を保存してしまい、結局それが「新しい属人化」になってしまうことだ。台帳自体は経理担当・後継予定者・信頼できる古参社員の複数人がアクセスできる場所に置き、社長一人しか見られない状態を避けたい。皮肉なことだが、引き継ぎ書がなかったことに苦労した本人が、次の代のために同じ失敗を繰り返してしまうケースは意外と多い。
台帳を作ったら次に見えてくる「単一障害点」という問題
台帳がある程度形になってくると、必ず気づくことがある。「これ、この人がいなくなったら本当に詰む」というシステムやツールが、1つや2つは見つかるはずだ。これが単一障害点（SPOF）と呼ばれる状態で、特定の一人・一台・一つの仕組みに業務が完全に依存し、そこが止まった瞬間に全体が止まってしまう箇所を指す。
先代がまさにそうだったはずだ。先代しか知らないパスワード、先代しか判断できない見積もりの基準、先代の携帯電話にしか連絡先が入っていない取引先——これらはすべて単一障害点であり、承継直後の混乱はその単一障害点が一斉に表面化した結果だとも言える。
台帳を作る目的の一つは、次の単一障害点を先回りして見つけることにある。例えば、次のようなケースは要注意だ。
- 経理担当が一人しかおらず、その人が休むと請求書も出せない
- 特定のExcelマクロを組んだ社員が退職予定で、後任が中身を理解していない
- 取引先とのやり取りが、会社のアドレスではなく担当者個人のメールアドレスで行われている
これらはシステムの問題であると同時に、組織の問題でもある。台帳に「詳しい人（社内）」の欄を設けたのは、まさにこの単一障害点を可視化するためだ。同じ欄に同じ人の名前ばかりが並ぶようであれば、その人物に依存が集中しているサインだと捉え、業務の一部を他の社員にも分散させる、マニュアル化を進めるといった対策を検討する材料にできる。
単一障害点をすべて解消することは、承継直後の段階では現実的ではない。まずは「どこにあるか」を把握し、リスクの大きさに応じて優先順位をつけることが目標になる。
クラウド化・システム刷新を急がない理由
承継後、危機感から一気にシステムを刷新したくなる社長は多い。「こんな古いやり方では今の時代についていけない」という焦りは自然な感情だが、台帳も整っていない段階での全面刷新は、かえって傷口を広げることがある。
理由は単純で、何が動いているか分からない状態のままシステムを入れ替えると、今まで見えていなかった業務ルールや例外処理が、置き換えた瞬間に一斉に噴き出すからだ。長年使われてきたレガシーシステムには、非効率に見えても、実は特定の取引先の特殊な要望や、過去のトラブルを踏まえた例外処理が組み込まれていることが少なくない。それを知らずに「新しくて効率的なシステム」に飛びつくと、思わぬところで業務が回らなくなる。
だからこそ、承継直後の優先順位は次の順番で考えたい。
- 何が動いているかを記録する（台帳作り）
- 誰が困っているか、何が危ういかを把握する（単一障害点の洗い出し）
- 危険度の高いものから、小さく手を打つ（バックアップを取る、担当者を増やすなど）
- 十分に実態を理解した上で、必要な範囲だけシステムを刷新する
台帳という土台がないまま4番目から手をつけると、システム会社に見積もりを頼む際も「何をどう変えたいか」を説明できず、話が噛み合わないまま高額な提案を受け入れてしまうリスクもある。焦って刷新するより、まず現状を記録し、承継から半年から1年程度をかけて実態を把握してから動く方が、結果的に投資が無駄にならない。
専門家に頼れない領域だからこそ、記録が最初の相談材料になる
冒頭で触れたとおり、株式や登記には税理士・司法書士という頼れる専門家がいる。一方でシステムについては、よほど大きな会社でない限り、顧問のIT専門家がついていることは少ない。何かトラブルが起きたときに初めて、慌てて業者を探すことになりがちだ。
ここで台帳が生きてくる。仮に業者やITコンサルタントに相談する場面が来たとしても、「うちには何があるのか分からない」状態で相談するのと、「このシステムがこういう状態で、ここが不安」と伝えられる状態で相談するのとでは、話の進み方がまったく違う。台帳は社内向けの備忘録であると同時に、将来外部の専門家に相談する際の「症状を説明する資料」にもなる。
逆に言えば、台帳が全くない状態で業者に相談すると、まず現状把握のための調査から始まり、時間もコストもかさむ。承継直後の身軽なうちに最低限の記録をつけておくことは、将来的な相談コストを下げる先行投資でもある。
承継直後にありがちな3つの失敗パターン
台帳作りを実際に始めると、いくつか典型的なつまずき方がある。あらかじめ知っておくことで、無駄な回り道を減らせる。
失敗パターン1：完璧主義で手が止まる
「全部のシステムを漏れなく、正確に記録しなければ」と考えすぎて、結局1行も書けないまま時間だけが過ぎるケースだ。台帳は完成品ではなく、常に更新され続ける「生きた記録」だと割り切ることが大切だ。8割の情報で構わないので、まず作り始める。残りの2割は、後から気づいた都度追記すればいい。
失敗パターン2：一人で抱え込む
社長自身がすべてのヒアリングと記録作業を担おうとして、他の業務に手が回らなくなるケースもよくある。台帳作りの初期段階は社長主導で構わないが、ある程度形になったら、経理担当や信頼できる社員に「台帳の維持係」を任せることを検討したい。承継直後の社長にしかできない仕事（対外的な信頼構築や意思決定）に時間を使い、記録の維持は分担するという発想の切り替えが必要だ。
失敗パターン3：見つけた問題を全部その場で解決しようとする
台帳作りの過程で「これはまずい」という問題が次々に見つかると、その都度対応したくなる衝動に駆られる。しかし優先順位をつけずに手当たり次第に手を打つと、かえって収拾がつかなくなる。まずは台帳を一通り作り終え、全体像を把握してから、リスクの大きい順に対応する方が結果的に早い。
この記録術がもたらす孤独感からの解放
引き継ぎ書がない状態での承継は、多くの場合「何が分からないのかも分からない」という不安が最初にくる。台帳作りは、その漠然とした不安を「見えるリスクのリスト」に変換する作業でもある。全部を一度に解決する必要はない。まずは1枚の表に、社内にあるシステムを書き出すこと。そこから、優先順位をつけて一つずつ手を打っていけばいい。
完璧な台帳を最初から目指す必要はない。今日聞き出せた情報を、今日のうちに1行書く。それを2週間続ければ、先代が何十年もかけて積み上げてきた「頭の中の地図」の輪郭が、少しずつ紙の上に浮かび上がってくる。
この作業は、単なる事務作業以上の意味を持つ。先代がどんな判断をしながら会社を回してきたのか、古参社員がどんな工夫で日々の業務を支えてきたのかを知る過程でもあるからだ。台帳を埋めていくうちに、これまで見えていなかった会社の歴史や、先代なりのリスク管理の跡が見えてくることも少なくない。それは、経営を引き継いだ者にしか得られない気づきでもある。先代が守ってきた会社を、次はあなたの手で守りやすい形に整理していく——その最初の一歩が、この記録術だ。
よくある質問
Q. 先代がまだ会社に関わっている場合、根掘り葉掘り聞くと角が立ちませんか。
A. 「否定」ではなく「記録」という目的を明確に伝えると角は立ちにくい。「お父さん（先代）が積み上げてきたものが、自分の代でも止まらないようにしたい」という言い方であれば、多くの先代は協力的になる。むしろ聞かれずに引退することの方が、先代にとっても心残りになりやすい。ヒアリングの際は「なぜこうしたのか」を問い詰める形ではなく、「教えてほしい」という姿勢を崩さないことが、関係を壊さずに情報を引き出すコツだ。
Q. 古参社員がシステムの実態を教えたがりません。どうすればいいですか。
A. 「あなたのやり方が正しいかどうかを評価するためではなく、あなたが休んだときに会社が困らないようにするための記録」だと伝えると警戒が和らぐことが多い。台帳が完成した後も、その社員の役割やノウハウを否定する目的では使わないという姿勢を、言葉と行動の両方で示す必要がある。長年その業務を一人で支えてきた社員にとって、属人化していた状態は「自分の存在価値」でもあるため、記録化がその価値を奪うものではないと伝わるまで、時間をかけて向き合う覚悟も必要だ。
Q. システムの契約が先代個人の名義になっていました。どう対応すべきですか。
A. まずはそのサービスの契約者専用ページやサポート窓口に連絡し、名義変更または管理者権限の追加が可能か確認する。特にドメイン・レンタルサーバー・クラウド会計などは、先代が完全に引退する前に法人名義または後継者のアカウントに切り替えておくことが望ましい。ドメインについては「レジストラ移管」と「名義移管」が別の手続きである点に注意し、契約している登録事業者のサポート窓口に問い合わせれば案内してもらえることが多い。専門家を挟まずに社長自身で進められる場合も多いので、まずは契約先に確認するところから始めるとよい。
Q. 台帳を作る時間が全く取れません。優先順位はどうつければいいですか。
A. 全システムを一度に洗い出そうとせず、まず「止まったら会社の売上や支払いが止まるもの」から着手する。具体的には会計・請求書発行・受発注・給与計算に関わるシステムを最優先にし、社内の業務効率化ツールなどは後回しにしてよい。代わりが利かない仕組みから記録していくのが、限られた時間での最も効果的な進め方だ。全体の完成を待たず、優先度の高いものから台帳に載せ、随時更新していく姿勢で十分に効果がある。
この記事の次に読みたい記事
記録を始めようとした矢先に、そもそも開発会社自体が既に存在しないと分かるケースもある。先代が契約していた開発会社が倒産していた。ソースコードがない場合の選択肢にまとめた。
