先代の紙業務・Excel台帳をノーコードで置き換える選択肢比較

先代の代からの紙台帳と、担当者しか触れない「秘伝のExcel」。事業承継後に社長が最初にぶつかる壁は、実は財務や人事ではなく、この足元の業務システムだったりします。結論から言うと、いきなり大がかりな基幹システムを入れる必要はありません。まず選ぶべきは「ノーコード・ローコード」というジャンルのツールで、しかも一気に全部を置き換えるのではなく、台帳ごとに置き換え方式を比較して段階的に進めるのが最も失敗が少ない進め方です。

この記事は、こんな状態の社長に向けて書いています。先代が退任してから半年〜2年、引き継いだ会社の受注台帳・在庫表・顧客リストが紙とExcelのままで、更新できる人が総務のベテラン社員1人しかいない。その社員に「これって将来的にどうするつもりですか」と聞かれても答えられず、かといって古参社員に気を遣って強引にシステムを入れ替える踏み込みもできない。IT担当も情報システム部もいないので、税理士や弁護士のように相談できる専門家が見当たらない——そんな孤独な状況です。株式や登記の手続きには顧問税理士や司法書士という頼れる相手がいますが、「Excel台帳をどうするか」には決まった相談先がありません。だからこそ、選択肢を整理して自分の頭で比較できる状態を作ることが第一歩になります。

なぜ承継直後に台帳問題が表面化するのか

先代が現役だった頃は、台帳が紙やExcelでも問題になりませんでした。理由は単純で、先代自身か、先代が長年育てた特定の社員が、台帳の「読み方」と「更新の作法」を頭の中に持っていたからです。承継が起きると、この暗黙知の継承が途切れます。新しい社長は台帳のセルに何が書かれているか分かっても、「なぜこの列だけ手入力なのか」「なぜこの行だけ色がついているのか」という背景を知りません。これが表面化するタイミングが、承継後半年〜1年というケースが多く見られます。

属人化の実態はどこにでもある

中小企業庁が公開している事業承継の事例集でも、業務が個人の頭の中にしかなく、情報共有の仕組みがないまま拡大した結果、承継のタイミングで一気に負債として噴き出す構図が紹介されています。ある建設会社の事例では、業務の大半が属人化し、社内の情報がすべて紙で管理されていたことが、承継後の業務効率化の出発点になったと報告されています。つぎてなびの読者の会社でも、似た状況を抱えている方は少なくないはずです。

Excel台帳が承継後に「詰む」典型パターン

Excel台帳が限界を迎えるタイミングには、いくつかの典型パターンがあります。

• 担当者が休むと台帳が更新できず、受注や出荷の判断が止まる
• 同じファイルを複数人が同時に開こうとして「読み取り専用」で開かれ、片方の更新が消える
• スマートフォンやタブレットからは実質的に閲覧・入力ができない
• バージョンが分岐して「_最新」「_本当の最新」「_2」のようなファイル名が並ぶ
• 先代のマクロが複雑で、触ると壊れそうで誰も手を入れられない

これらは技術的な欠陥というより、「1人が全部管理する」という運用を前提にした仕組みの限界です。承継によって管理者が変わる、あるいは組織が拡大するタイミングで、この前提そのものが崩れます。台帳が「重くて開けない」状態を放置した場合に何が起きるかは、先代の台帳が「重くて開けない」を放置するとどうなるかで詳しく解説している。

承継のタイミングだからこそ変えやすいという逆説

一見すると、承継直後は社内が不安定で、システムを変えるには不向きなタイミングに思えます。しかし実際には逆の側面もあります。新しい社長が就任したという事実そのものが、社内に「何かが変わる時期だ」という心理的な準備を作ります。先代が長く在任していた間に同じ提案をしても、「今のままでいい」という空気に押し戻されていたかもしれない変更が、承継直後であれば「新社長の方針だから仕方ない」という形で受け入れられやすくなることがあります。この意味で、承継後の1〜2年は、システムを見直す上で会社にとって最も好機な期間だとも言えます。先延ばしにすればするほど、新しい体制が定着し、変更へのハードルはむしろ上がっていきます。

選択肢を整理する前に決めておきたい3つの軸

比較を始める前に、社長自身の頭の中で次の3つの軸を仮でも決めておくと、ツール選びがぶれません。

この3軸を最初に固定しておくと、後述する各ツールの向き不向きを自分の会社に当てはめて判断しやすくなります。まだ社長に就任する前で権限がない立場からできる観察の仕方は、まだ社長じゃないうちに、権限がなくてもできる観察のコツも参考にしてほしい。

選択肢1: 表計算の延長で使えるクラウド化(Google スプレッドシート/Excel Online)

最も踏み出しやすい選択肢は、今のExcelファイルをGoogleスプレッドシートやMicrosoft 365のExcel Onlineに移すことです。見た目も操作感もほぼ変わらないため、古参社員への説明コストが最も低く済みます。複数人での同時編集、変更履歴の自動保存、スマートフォンからの閲覧ができるようになる点だけでも、紙とローカルExcelの課題の多くは解消します。

一方で限界もはっきりしています。台帳が数千行を超えて肥大化すると動作が重くなり、また「入力ルールを守らない人が自由に列を追加してしまう」といった属人化の別パターンが再発しやすい点は変わりません。あくまで「次の一手を考えるまでの応急処置」と位置づけるのが現実的です。

選択肢2: ノーコード業務アプリ(kintone・AppSheet)

台帳を「アプリ」として作り直す選択肢です。日本の中小企業で最も導入例が多いのがサイボウズのkintoneで、テンプレートから顧客管理や受注管理のアプリを短時間で作成できます。2026年時点の料金は、最小契約10ユーザーからのライトコースが1ユーザー月額1,000円(税抜)、スタンダードコースが1ユーザー月額1,800円(税抜)という体系です(参照: kintone公式サイト)。10人規模の事務所であれば月1万円前後からのスタートになる計算です。

もう一つの有力な選択肢がGoogleのAppSheetです。今使っているスプレッドシートをそのままアプリ化できる点が最大の特徴で、Google Workspaceを既に契約している会社であれば、プランによって追加コストなしで使えるケースもあります。Workspaceを使っていない会社は、単体でのStarterプランからの契約が必要です。

どちらを選ぶかは、社内の基盤がGoogle系かMicrosoft・独自基盤かで判断するのが分かりやすい基準です。すでにGoogle Workspaceでメールやスプレッドシートを使っているならAppSheet、グループウェアも含めて業務を一つにまとめたいならkintoneという整理になります。

選択肢3: 既存Excelの延命(VBAマクロの改修・引き継ぎ)

先代が作ったマクロが複雑でも、それを捨てずに「読める状態」に整備し直す道もあります。VBAマクロの内容をドキュメント化し、担当者を古参社員だけに依存させない体制にする方法です。台帳の運用そのものを大きく変えたくない、システム移行にかけられる時間が少ない、という会社には現実的な選択肢になります。ただし、マクロを書ける人材を社内で育てるか外部に依存するかという課題は残るため、あくまで時間を稼ぐための選択肢と捉えておくのが安全です。

選択肢4: 業種特化のパッケージSaaS

在庫管理、受注管理、勤怠管理など、業種で必要な機能がある程度定型化されている場合は、ノーコードで自作するより、業種特化型のクラウドサービス(SaaS)を契約する方が早いこともあります。ノーコードツールは「何を作るか」を自分たちで設計する自由度がある一方、設計・運用の負荷も自分たちで負う必要があります。パッケージSaaSは設計済みの型にはめる分、自由度は下がりますが立ち上げが速いという特性があります。台帳の中身が業界標準的な帳票に近いなら、パッケージSaaSも比較対象に入れておくべきです。

4つの選択肢をコストと難易度で並べる

ここまでの4つの選択肢を、承継直後の会社が気にする「初期コスト」「月額コスト」「社内の学習負荷」「業務フロー変更の度合い」で整理すると、次のようになります。

この表を見て分かるのは、コストの低さと属人化解消の効果は必ずしも一致しないということです。VBAマクロの延命はコストが低い代わりに属人化リスクを引き継いでしまいます。逆にkintoneやAppSheetは初期の設計負荷こそありますが、複数人で運用できる状態を作れるという点で、承継後の「担当者が1人しかいない」問題への効果が最も大きい選択肢です。

なぜ「ノーコード・ローコード」が承継期の会社に向くのか

ノーコード・ローコードという言葉は、プログラミングの専門知識がなくても業務アプリを作れる開発手法を指します。承継期の会社にこの手法が向いている理由は、外部のシステム会社に高額な発注をしなくても、社内の非IT出身者が自分たちの手で台帳を組み立てられる点にあります。先代の時代は「外注してシステムを作ってもらう」か「Excelで我慢する」かの二択に近かった会社でも、ノーコードという第三の道であれば、初期投資を抑えながら、業務を知る社員自身が試行錯誤して形を作っていけます。これは、外部の専門家に頼れる場面が少ない承継直後の会社にとって、相談先の不在を自分たちの手でカバーできるという意味でも相性がいい選択肢です。

情報システムの現場でも中小企業のノーコード活用は加速している

中小企業のノーコード・ローコード活用は一過性の流行ではなく、既存のスプレッドシート運用からの移行先として定着が進んでいる分野です。特にAppSheetのように「今あるスプレッドシートをそのままアプリ化する」という設計思想は、Excel台帳をゼロから作り直す心理的ハードルを下げる効果があります。台帳をすべて捨てて作り直すのではなく、今あるデータ構造を土台にして拡張していく発想が、承継期の会社の「今のやり方を大きく変えたくない」という要望と噛み合いやすいのです。同時に開けない台帳をどこまで放置していいかの判断ラインは、同時に開けない先代のExcel台帳、システム化の判断ラインはどこかでも整理している。

台帳の種類ごとに置き換え優先度を決める

すべての台帳を同時に置き換える必要はありません。むしろ一括で進めようとすると混乱し、古参社員の反発も大きくなります。優先度の付け方の一例です。

1. 更新頻度が高く、複数人が同時に触る台帳(受注管理・在庫管理)を最優先にする
2. 紙の記入が残っている台帳(検査記録・作業日報)は次点で電子化する
3. 年に数回しか更新しない台帳(規程類・組織図)は最後で構わない

このように優先度をつけることで、「まず一番困っている台帳だけ小さく試す」という進め方が可能になります。小さく始めて成功体験を作ることが、社内の心理的なハードルを下げる一番の近道です。

古参社員との関係を壊さない進め方

承継直後にシステムを変えるときに最も気をつけるべきは、長年その台帳を守ってきた古参社員のプライドと不安です。頭ごなしに「もう古いから変える」と伝えるのではなく、次のような手順を踏むと反発が小さくなります。

「今のやり方を否定するのではなく、あなたが今やっている作業の一部を楽にするための道具を試したい」という伝え方をすると、抵抗が和らぎやすくなります。

• 最初から全面移行を宣言せず、「並行運用期間」を必ず設ける
• 古参社員に新しいツールの「テスト運用担当」という役割を与える
• 移行後も、その社員が長年蓄積した台帳の使い方・注意点をヒアリングして記録に残す

古参社員が持っている暗黙知は、先代から受け継がれた会社の資産の一部です。ツールを変えることと、その知識を尊重することは両立できます。

先代への配慮をどう扱うか

先代が生前(あるいは会長として)残した台帳やマクロには、本人なりの工夫や思い入れが詰まっていることがあります。承継した社長が「使いにくいから全部消す」という判断を急ぐと、先代との関係がこじれることもあります。可能であれば、先代がまだ相談できる立場にいるなら「今の台帳の仕組みで困っている点」を一度率直に聞いてみるのがおすすめです。先代自身も後継者に負担を残したくないと考えているケースは多く、思いのほか協力的な反応が返ってくることもあります。

データクレンジングという地味だが避けられない工程

ツールを選ぶ前に、もう一つ避けて通れない作業があります。それがデータクレンジングです。先代の代から積み上げられたExcel台帳には、表記のばらつき(「株式会社」と「(株)」の混在など)、重複データ、更新が止まった古い行が必ず残っています。どんなに優れたノーコードツールを選んでも、汚れたデータをそのまま移せば、新しいシステムでも同じ混乱が再生産されます。移行作業の初期段階で、最低限のクレンジングに時間を割く覚悟を持っておくべきです。

移行を進める際の実務ステップ

実際に置き換えを進める際は、次のステップで進めると失敗が少なくなります。

1. 台帳の棚卸し(どの台帳が何のために使われているかをリスト化する)
2. 優先度の高い台帳を1つ選び、小さくテスト運用する
3. データクレンジングを行い、汚れたデータを持ち込まない
4. 古参社員を交えた並行運用期間を設ける
5. 問題がなければ本運用に切り替え、紙・旧Excelは一定期間だけ保管する
6. 次の台帳へ同じ手順を繰り返す

一気に全社展開しようとせず、この6ステップを台帳の種類ごとに繰り返すのが、承継期の会社には最も無理のない進め方です。

台帳の「見えないコスト」を可視化する

Excel台帳を使い続けるコストは、月額の請求書には出てきません。だからこそ経営判断として後回しにされやすいという特徴があります。しかし実際には、次のような形で確実にコストが発生しています。

• 担当者が台帳の更新に費やす時間(残業や休日対応につながっているケースもある)
• 台帳の内容を別部署に説明・転記する二重入力の手間
• ファイルの破損やバージョン違いによる、やり直し作業の時間
• 担当者が退職・休職した際に、後任が台帳の使い方を覚え直す時間

これらを厳密に金額換算するのは難しいものの、「担当者の残業時間のうち、台帳関連の作業が何割を占めているか」を一度本人に聞いてみるだけでも、見えないコストの大きさに気づくきっかけになります。中小企業庁の事業承継事例でも、業務の属人化が従業員の残業時間の多さと結びついていたという報告があり、台帳の仕組みを変えることは、単なるIT投資ではなく労務環境の改善にもつながる話だと捉えることができます。

承継前の先代の判断を否定せずに引き継ぐ視点

承継後の社長がやりがちな失敗の一つが、「先代のやり方は古い」という前提で全てを語ってしまうことです。しかし、先代がExcelや紙で運用してきたのは、当時の会社の規模やIT環境、取引先の事情に合わせた合理的な選択だった場合がほとんどです。会社が成長し、従業員が増え、取引先とのやり取りがデジタル化した今だからこそ、次の仕組みが必要になっているだけで、先代の判断そのものが間違っていたわけではありません。この視点を持っておくと、社内への説明も「先代のやり方が悪かったから変える」ではなく「会社が成長したから、次の仕組みに進化させる」という前向きな言葉で伝えられます。古参社員も、先代のやり方を否定されると身構えますが、「進化」という言葉であれば受け入れやすくなります。

名義問題という承継特有の落とし穴

システムの話とは少し異なりますが、台帳を電子化する過程で見落とされやすいのが、契約者名義の問題です。先代個人の名義でExcelファイルやクラウドサービスの契約が残っていたり、社用のGoogleアカウントが先代個人のメールアドレスに紐づいていたりするケースは珍しくありません。新しいツールを契約する際は、契約者名義を会社名義・後継者名義に揃え直すタイミングとしても活用すべきです。ここを放置すると、将来先代に連絡が取れなくなった際にアカウントへのアクセス自体ができなくなるという、承継特有のリスクが残ります。

CSVでのデータ移行という橋渡し役

ノーコードツールへの移行時、Excel台帳のデータをそのまま手入力し直す必要はありません。多くのノーコードツール・SaaSはCSV形式でのデータ取り込みに対応しています。Excelから同じ形式で書き出し、新しいツールに読み込ませることで、何百行・何千行のデータでも一括で移行できます。この工程を知らずに手打ちで入力し直そうとすると、移行作業だけで数週間かかることもあるため、必ず事前に確認しておきたいポイントです。

書き出す前に確認しておきたいのが、列の並び順と項目名です。先代の台帳は「取引先名」だったり「顧客名」だったりと、同じ意味の項目でも表記がゆれていることが少なくありません。取り込み先のツールがどの項目名を期待しているかを先に確認し、書き出す側のExcelでヘッダー行を合わせておくと、取り込み時のエラーを大きく減らせます。ここも一種のクレンジング作業で、地味ですが移行の成功率を左右する工程です。移行先としてkintoneを検討する場合に整理しておきたいデータ項目は、kintoneに移行する前に整理しておきたい先代データの項目でまとめている。FAXや手書き台帳からの受発注を抜け出す第一歩を先に踏み出したい場合は、FAX・手書き台帳からの受発注、抜け出すための第一歩も参考になる。

移行にかかる期間の目安を持っておく

「いつまでに終わらせるべきか」という問いに正解はありませんが、目安を持たずに始めると、忙しさに追われていつまでもExcelのままという状態が続きがちです。台帳1つあたりの規模にもよりますが、棚卸しから小さなテスト運用の開始までを1〜2ヶ月、並行運用を含めた本運用への切り替えまでをさらに1〜2ヶ月と見積もっておくと、社内の期待値をコントロールしやすくなります。承継後の最初の1年で1〜2つの主要台帳を置き換えられれば、十分なペースと考えて構いません。

情報システム部がない会社の運用体制の作り方

情報システム部門を新設する余裕がない会社でも、担当を「1人だけに集中させない」という発想は今すぐ実践できます。具体的には、台帳ごとに正担当者と副担当者を最低1人ずつ決めておくことです。正担当者が不在でも副担当者が最低限の入力・確認をできる状態を作っておくだけで、承継前の「1人しか触れない」というリスクの大部分は解消されます。副担当者は必ずしもITに強い人でなくても構いません。むしろ日常的に台帳を使う現場の社員を割り当てる方が、実運用に即した気づきが得られます。

社長自身がどこまで手を動かすべきか

非IT出身の社長にとって、「自分がどこまでツールの設定に関わるべきか」は悩ましい問題です。結論としては、細かな設定作業まで社長が担う必要はありませんが、台帳が何のために存在し、どのデータが経営判断に直結するかという設計思想の部分だけは、社長自身が把握しておくべきです。設定作業は古参社員や外部のパートナーに任せてよい一方、「この台帳がなぜこの形なのか」を説明できる状態を保っておくことが、次の代への引き継ぎでも役に立ちます。承継を1度経験した社長だからこそ、次に引き継ぐときのために、今のうちから台帳の設計思想を言語化しておく価値があります。

補助金・支援制度の活用も視野に入れる

ノーコードツールの導入や台帳の電子化には、IT導入補助金など公的な支援制度を活用できる場合があります。制度の対象範囲や申請要件は年度によって変わるため、導入を具体的に検討する段階になったら、独立行政法人中小企業基盤整備機構や、各地の商工会議所が公開している最新の募集要領を確認することをおすすめします。制度の詳細をこの記事で断定的に書くことは避けますが、「使えるかもしれない支援制度がある」という前提を持っておくだけで、予算面での踏み出しやすさは変わってきます。

複数拠点・複数部門がある場合の注意点

会社の規模が大きく、拠点や部門が複数に分かれている場合は、台帳の置き換えをさらに慎重に進める必要があります。本社で使っている台帳と、現場拠点で使っている台帳が微妙に異なるフォーマットになっていることは珍しくありません。この場合、いきなり全拠点を1つのツールに統一しようとすると、現場の反発が本社よりも強く出ることがあります。まずは本社か、最も協力的な拠点1つで小さく試し、成功事例を作ってから他拠点に展開する方が、結果的に早く全社展開できることが多いです。

ツール選定で陥りやすい失敗パターン

最後に、ノーコードツール選定でよく見られる失敗パターンを整理しておきます。

• 機能の多さだけで選び、実際に使う機能はごく一部だったため費用が見合わなかった
• 導入を決めた社長や情報システム担当だけで盛り上がり、現場の意見を聞かずに展開して定着しなかった
• 最初から全台帳を一度に移行しようとして、途中で頓挫した
• 無料プランやトライアル期間だけで判断し、本番運用に必要な料金体系を確認していなかった
• データクレンジングを省略し、汚れたデータのまま移行してしまった

これらはいずれも、技術的な難しさではなく、進め方の順序を誤ったことが原因です。逆に言えば、この記事で紹介した「優先度をつける」「小さく試す」「古参社員を巻き込む」という進め方を守るだけで、多くの失敗は回避できます。

外部への相談先をどう確保するか

株式や登記の手続きには、顧問税理士や司法書士という決まった相談先がいます。しかしシステムについては、承継直後の会社に「これが正解」という相談先が用意されていないことが実情です。以下のような相手を組み合わせて頼るのが現実的です。

• ノーコードツールの公式サポートやパートナー企業(導入設計の相談)
• 商工会議所・中小企業診断士(業務全体の整理・優先順位づけ)
• 同業他社の経営者(似た規模・業種での導入事例のヒアリング)

一人の専門家に全部を委ねられる体制はまだ整っていない分野だからこそ、複数の相談先を薄く広く持っておくことが、承継期の社長にとって現実的なリスク分散になります。

小さく始めて、育てるという発想を持つ

ノーコード・ローコードの最大の利点は、最初から完璧な設計をしなくてもよいという点です。台帳を1つ電子化してみて、使いにくい部分が見つかれば直せばいい。この「作って、使って、直す」というサイクルを回せることが、外部発注のシステムにはない身軽さです。承継直後は資金にも余裕がないことが多いため、いきなり大きな投資をせず、小さく始めて会社の実情に合わせて育てていくという発想を持つことが、結果的に一番コストを抑える道になります。

導入後にツールを乗り換える判断が必要になることもある

一度選んだノーコードツールが、会社の成長とともに合わなくなることもあります。例えば、最初は数人規模で使っていたkintoneやAppSheetのアプリが、事業拡大に伴ってユーザー数が増え、料金体系上不利になってくるケースや、逆に機能が足りなくなり業種特化のパッケージSaaSへ乗り換えたくなるケースです。この記事で紹介した比較の軸は一度決めたら固定というものではなく、会社の状況が変わるたびに見直してよいものです。ノーコードで作ったアプリは、フルスクラッチで開発したシステムに比べて作り直しの負荷が小さいという特性もあるため、「一度選んだら一生そのツールを使い続けなければならない」と気負う必要はありません。

外部発注が必要になるタイミングの見極め方

ノーコードツールで対応できる範囲には限界があります。台帳の規模が数万件を超えて重くなってきた、複数の基幹業務(会計・在庫・受発注)を横断して連携させたい、外部の取引先システムとAPI連携する必要が出てきた——こうした要望が出てきたら、ノーコードの範囲を超え、専門の開発会社への相談を検討するタイミングです。承継直後にいきなりフルスクラッチのシステム開発を発注するのはリスクが大きいですが、まずノーコードで小さく試して業務要件を固め、その要件を持って開発会社に相談するという順番であれば、発注の失敗リスクを大きく減らせます。ノーコードでの試行期間は、外部発注前の「要件整理の練習期間」としても機能します。会社の体制が安定してきた段階で、自社開発するか既存ツールを組み合わせるかを最初に決めておく判断軸は、攻めのIT投資を自社開発するか既存ツールを組み合わせるか、最初に決めておくことで扱っている。

まとめの前に: 比較の軸をもう一度確認する

最後に、比較検討の軸を振り返っておきます。予算、社内のITリテラシー、業務フローを変える許容度。この3つを最初に固定していれば、どのツールが自社に合うかはおのずと絞られます。表計算の延長で十分なら移行だけで済ませ、複数人での運用が必要ならkintoneかAppSheetを比較し、今のマクロをまだ活かしたいなら延命の道も選べます。正解は1つではなく、会社の状況によって変わるという前提を持つことが、遠回りを避ける一番のコツです。

先代が積み上げてきた紙とExcelの台帳は、否定すべき遺産ではなく、次の仕組みに引き継ぐための土台です。焦って一気に変えるのではなく、比較しながら自社に合う一手を選び、小さく試して育てていく。それが、承継したばかりの社長にとって、最も無理のない前進の仕方です。

次の後継者のために今から記録を残す

自分がいつか会社を次の世代に引き継ぐ立場になることも、承継直後の社長であれば想像しておいて損はありません。今回、先代からの台帳を引き継ぐ際に「なぜこの仕組みなのか分からず苦労した」のであれば、その苦労を次の後継者に繰り越さないという選択ができます。ノーコードツールで台帳を作り直す際に、設計の意図や運用ルールを簡単なメモとして残しておくだけで、次の承継がずっと楽になります。台帳そのものだけでなく、「なぜこの形にしたか」という記録を残すことが、システムを引き継ぎやすい会社を作る一番の近道です。今の苦労を、次世代への贈り物に変える視点を持っておきましょう。