先代の紙台帳をそのままWebシステム化するといくらかかる？

先代の代からずっと、事務所の書棚には分厚いバインダーが並んでいる。取引先台帳、在庫台帳、案件台帳。表紙は色褪せ、角は擦れ、付箋がめくれかけている。継いだばかりの社長であれば、この台帳を前にして一度は「これ、全部システムにしたらいくらかかるんだろう」と考えたことがあるはずだ。そして見積もりを取ろうとした瞬間、最初の壁にぶつかる。

「先代の台帳をそのままシステム化してください」という依頼が、実は最も見積もりにくい依頼だということだ。株式や登記の手続きなら、司法書士や税理士に相談すれば型が決まっている。ところがシステムの話になると、相談する相手も、相場の感覚も、何を基準に高い・安いを判断すればいいのかもわからない。この記事は、まさにその「わからなさ」を一つずつ分解し、紙台帳をWebシステム化する際に実際にいくらかかるのか、どこにコストの分岐点があるのか、そして先代の運用や古参社員の感覚を壊さずに移行するにはどうすればいいのかを、承継直後の経営者の目線でまとめたものだ。

結論を先に言うと、紙台帳のWebシステム化は「単純な入力フォームを1つ作る」なら数十万円で済むこともあるが、「先代のやり方をそのまま忠実に再現する」という条件をつけた瞬間に、金額は簡単に数百万円規模へ跳ね上がる。理由は台帳そのものの複雑さではなく、台帳の「行間」に先代の判断ロジックが染み込んでいるからだ。この記事ではその構造を丁寧に解きほぐしていく。

そもそも「台帳」とは何を指しているのか

この記事で扱う「台帳」とは、取引先の連絡先や取引履歴を記録した紙のバインダー、在庫の入出庫を手書きで管理しているノート、案件ごとの進捗をひとつのファイルにまとめたクリアファイルなど、会社の業務に紐づく記録物全般を指す。会計や税務の帳簿のように法律上の名称が決まっているものではなく、会社によって呼び方も形式もまったく異なる。

だからこそ「台帳をシステム化する」という依頼を受けた開発会社は、まず「その台帳が具体的に何を記録し、誰が何のために使っているのか」を確認しないと見積もりを出せない。逆に言えば、依頼する側がこの説明を最初にきちんとできるかどうかで、見積もりの精度も、開発会社に足元を見られるかどうかも変わってくる。承継直後の社長は、先代から台帳の存在は引き継いだが、その台帳がなぜその形になっているのかという背景までは引き継いでいないことが多い。まずこの温度差を自覚することが、システム化の第一歩になる。

なぜ「紙台帳のシステム化」は見積もりにくいのか

システム開発の見積もりは、基本的に「何を作るか」が明確であるほど精度が上がる。ところが紙台帳には仕様書がない。先代が長年の経験で調整してきた記入ルール、口頭で伝えられてきた例外処理、担当者の頭の中にだけある「この欄はこういうときは空欄にする」という暗黙知が、台帳の見た目には現れていない形で存在している。

開発会社に「この台帳をそのままWebにしてください」と伝えても、開発会社側は台帳の見た目をコピーすることはできるが、その台帳が生まれた背景にある業務ルールまでは読み取れない。結果として、開発が進んでから「あ、この欄は実はこういう場合分けがあって」という発覚が続き、追加の要件定義と追加の開発費が発生する。これが紙台帳システム化の見積もりが荒れやすい最大の理由だ。

台帳を開いて最初にやるべきこと

見積もりを依頼する前に、経営者自身が台帳を1冊持って、次の3点を洗い出しておくと精度が大きく変わる。

• 誰が、いつ、どの欄を書き込んでいるか（記入者と記入タイミングの洗い出し）
• 空欄・訂正線・手書きメモがある箇所（例外運用が隠れているサイン）
• 台帳を見て何を判断しているか（在庫を判断？支払いを判断？営業のタイミングを判断？）

この作業だけで半日はかかるが、これをやらずに開発会社に丸投げすると、要件定義フェーズで倍以上の時間がかかることになる。先代が現役であれば、この段階で一度時間を取ってヒアリングしておくのが最も安全だ。先代への配慮という意味でも、「あなたのやり方を壊さないために聞いている」という姿勢で臨むと、話がスムーズに進みやすい。

先代がすでに引退している場合はどうするか

先代が完全に引退し、日常的な相談ができない状況で台帳を引き継いだ場合、事情はさらに難しくなる。台帳に書かれた記号や略語の意味が分からず、古参社員に聞いても「昔からこうなっているから」という答えしか返ってこないことがある。この場合は、台帳を実際に使っている現場の社員から、逆算的に運用ルールを掘り出す作業が必要になる。

具体的には、直近1〜2年分の台帳のページを実際の業務の流れと照らし合わせながら、「このタイミングでこの欄に記入する」という対応関係を一つずつ確認していく。この作業は開発会社ではなく社内でしかできない部分が大きく、社長自身がある程度の時間を割く必要がある。先代がいない状態でのシステム化は、要件定義に想定より時間がかかることを前提にスケジュールを組んでおくべきだ。

システム開発費用の内訳を知る

まず前提として、システム開発の費用がどう構成されているかを理解しておく必要がある。一般的な見積もりでは、人件費が全体の6〜7割を占め、残りが環境構築費、ライセンス費、運用・保守費に分かれる。プロジェクトマネージャーの月単価は80万〜150万円程度、システムエンジニアは70万〜120万円程度、プログラマーは経験によって50万〜80万円程度が相場とされている（発注ラウンジ）。

ここで重要なのは「1画面あたりの工数」という考え方だ。単純な一覧・検索画面であれば0.5〜1人月、バリデーション付きの入力フォームなら1〜2人月、複雑なダッシュボードや帳票出力になると2〜4人月が目安とされている（発注ラウンジ）。台帳のシステム化は、この「入力フォーム」と「一覧・検索画面」の組み合わせでできていることが多いが、台帳の項目数が多ければ画面数も増え、その分工数が積み上がっていく。

台帳1冊 ＝ 画面1つ、ではない。台帳1冊の中に「登録」「検索」「編集」「一覧」「印刷」という複数の画面が隠れている。見積もりを取るときは、この分解を自分の頭でも一度やってみることをお勧めする。

要件定義フェーズの費用も見積もりに含まれるか

見積もり書を見るとき、開発フェーズの金額だけに目が行きがちだが、実は要件定義フェーズにも相応の費用がかかる。要件定義とは、台帳の内容を開発会社が理解し、画面構成やデータ項目、業務フローを文書化する工程だ。この工程を丁寧に行うほど、後工程での「発覚」が減り、追加費用の発生も抑えられる。

逆に、要件定義を簡略化して安く見せている見積もりは、開発が始まってから「これも必要でしたか」というやり取りが頻発し、結果的に総額が当初の見積もりを大きく超えることがある。台帳のシステム化においては、要件定義フェーズの丁寧さこそが総コストを左右する最大の変数だと考えてよい。承継直後で先代の判断ロジックが完全には見えていない状況では、この工程を削らないことが特に重要になる。

見積もり金額に含まれる「保守・運用費」の考え方

システムは作って終わりではなく、稼働してからも保守・運用の費用が発生し続ける。この費用は月額数千円〜数万円程度から、システムの規模によっては十万円を超えることもある。多くの経営者が見落とすのは、初期の開発費だけを見て予算を組んでしまい、稼働後の月額費用を織り込んでいないケースだ。

保守・運用費には、サーバーの維持費、ソフトウェアの不具合対応、法改正やOS更新への追従などが含まれる。台帳のシステム化を検討する際は、初期費用だけでなく、5年間・10年間といった長期の運用コストまで含めたトータルの金額感を持って判断することをお勧めする。開発会社によっては、初期費用を安く見せて保守費で回収する料金設計になっている場合もあるため、両方の数字を必ず確認してほしい。

パターン別に見る費用感

紙台帳のシステム化には、大きく3つのアプローチがある。それぞれ費用感がまったく異なるので、順に見ていく。

パターン1：Excel／スプレッドシート化（数万円〜数十万円）

最も手軽な方法は、台帳の項目をそのまま表計算ソフトに移すことだ。この場合、開発費はほとんどかからず、簡単な関数やフィルタ機能の設定だけで済む場合が多い。ただし複数人での同時編集や検索性、アクセス権限の管理には限界があり、台帳を使う人数が3人を超えると運用が崩れやすくなる。また、表計算ソフトはあくまで「表」を扱うためのツールであり、台帳同士の連携や承認フローのような業務ロジックを組み込むことには向いていない。台帳の記入者が少数で、内容もシンプルな場合に限って選択肢になる方法だと理解しておくとよい。

パターン2：ノーコード・ローコードツールでの構築（数十万円〜200万円程度）

ノーコード・ローコードのツールを使えば、画面のレイアウトや入力項目をドラッグ操作で組み立てられる。開発期間も比較的短く、フルスクラッチに比べて費用を抑えられるのが利点だ。ただし台帳特有の複雑な条件分岐（「取引先の種別によって入力項目が変わる」など）が多い場合、ノーコードツールの標準機能では対応しきれず、追加のカスタマイズ費用が発生することがある。

パターン3：フルスクラッチ開発（200万円〜1000万円超）

台帳の項目数が多く、複数の台帳が相互に連携している場合（在庫台帳と受注台帳と請求台帳が実は連動しているようなケース）は、フルスクラッチでの開発が現実的な選択になる。この場合、要件定義・基本設計・実装・テスト・運用移行という全工程を通しで積み上げる必要があり、規模によっては1000万円を超えることもある。中小企業のDX投資全体で見ると、システム開発費に運用・人材・教育・外部委託費まで含めた総合的な投資額は数百万円〜2000万円が目安とされている（中小企業DXナビ）。

以下は3パターンの比較を表にまとめたものだ。

パターンを迷ったときの判断基準

3つのパターンのどれを選ぶべきか迷った場合、次の質問に答えてみると方向性が見えてくる。

• 台帳を同時に見る・書き込む人は何人か（1〜2人ならExcel化、3人以上ならシステム化を検討）
• 台帳の項目に条件分岐が多いか（取引先の種類によって記入項目が変わるなど）
• 他の台帳・他のシステムとデータを連携させる必要があるか
• 5年後、10年後も同じ業務フローが続く見込みか、それとも会社の成長に応じて変わっていく見込みか

特に最後の質問は承継直後の会社にとって重要だ。先代の代の業務フローをそのまま将来にわたって維持するのか、それとも自分の代でやり方を変えていく計画があるのかによって、投資すべき金額感は変わってくる。将来的に大きく業務フローを変える予定があるなら、最初から高額なフルスクラッチに投資するのではなく、ノーコードツールでの構築から始めて、様子を見ながら投資規模を判断するという進め方も合理的だ。

なぜ「そのまま」がいちばん高くつくのか

多くの経営者は「先代のやり方を変えたくない」という思いから、「台帳をそのままシステム化してほしい」と依頼する。この気持ちは非常に理解できる。しかし開発の現場から見ると、「そのまま」という要件が最も費用を押し上げる要因になりやすい。

理由は2つある。1つは、紙の台帳は「自由に書ける」という特性を持っているため、Webシステムに置き換えると自由記述欄をどう扱うかで判断が分かれること。もう1つは、台帳の運用が長年の間に少しずつ変化していて、「表紙のルール」と「実際の記入内容」が食い違っているケースが多いことだ。台帳を1ページずつ見ていくと、途中から書式が変わっていたり、ある時期だけ特定の欄が使われていなかったりすることがよくある。これをすべて「仕様」として汲み取ろうとすると、要件定義だけで数週間〜数ヶ月かかることもある。

現実的な折り合いとしては、「台帳の見た目や項目構成は活かしつつ、記入ルールは現時点の運用に合わせて一度整理し直す」というアプローチが費用対効果として優れている。先代のやり方を否定するのではなく、「今の運用に合わせて整える」という説明であれば、先代にも古参社員にも受け入れられやすい。

「自由記述欄」がシステム設計を難しくする理由

紙台帳の多くには、決まったフォーマットの欄とは別に、余白や備考欄のような自由記述の部分がある。ここには担当者がその場の判断で気づいたことを書き込んでいることが多く、内容も形式もバラバラだ。Webシステムでこの自由記述欄をどう扱うかは、実は設計上の大きな分かれ道になる。

単純にテキストボックス1つとして扱えば実装は簡単だが、その場合、後から「あの案件どうだったか検索したい」というときに、自由記述の中身までは検索対象にならないことがある。逆に、備考の内容を分類・タグ付けできる構造にしようとすると、その分類ルールを新たに決める必要があり、要件定義の工数が増える。どちらを選ぶかは、その台帳が「記録のためのもの」なのか「後から検索・分析するためのもの」なのかという使い方次第であり、この判断を最初にしておくことが見積もり金額を左右する。

台帳の「例外運用」をどこまでシステムに組み込むか

長年運用されてきた台帳には、必ず例外的な処理が積み重なっている。「この取引先だけは特別な扱いをする」「決算期だけは記入のタイミングが変わる」といったルールは、台帳の見た目には表れず、記入者の頭の中にだけ存在していることが多い。

これらの例外をすべてシステムに組み込もうとすると、条件分岐が増え、開発工数も比例して増えていく。一方で、例外運用を無視してシステムを作ると、現場から「これでは今までのようにできない」という不満が出て、結局システムが使われなくなるリスクがある。現実的な対応としては、頻度の高い例外だけをシステムに組み込み、頻度の低い例外は「手動で処理する」という運用ルールとして残す、という切り分けが有効だ。この切り分けの判断は、開発会社ではなく社内の人間にしかできない。

見落とされがちな「データ移行」というコスト

見積もりの話をするとき、多くの経営者は「システムを作る費用」だけを考えてしまう。しかし紙台帳のシステム化で実際にコストと時間がかかるのは、過去の紙のデータをシステムに入れ込む作業、つまりデータクレンジングの工程だ。

台帳には、同じ取引先が表記ゆれ（「株式会社」の位置が違う、旧社名のまま、担当者の手書きで住所が省略されているなど）で複数回登場していることが珍しくない。これをシステムに移す前に統一しないと、システム上で同じ取引先が別の取引先として扱われてしまい、検索や集計が機能しなくなる。この整理作業は、システムそのものの開発費とは別に、人手による確認作業として費用が発生する。台帳が10年、20年分積み重なっている場合、この作業だけで数十万円規模になることもある。

• 過去何年分をシステムに取り込むか（全件か、直近3年分だけか）
• 表記ゆれ・重複データの統一作業を誰がやるか
• 手書き文字の判読が必要な箇所をどう処理するか

これらを事前に決めておくだけで、見積もり金額の振れ幅を大きく抑えられる。データの表記ゆれをどう整理するかは先代データのクレンジング、システム移行で失敗しないためにで詳しく扱っている。

手書き文字の判読という地味だが重い作業

台帳のデータをシステムに入れる際、避けて通れないのが手書き文字の判読だ。特に先代や退職した社員が書いた古いページは、独特の癖字や略字が使われていることがあり、今の社員では読み取れない場合がある。この場合、判読できる人に一時的に協力を依頼するか、判読不能な箇所は「不明」として空欄で登録し、後から分かる範囲で埋めていくという運用にするしかない。

判読作業を開発会社に依頼すると、原稿を読み取ってシステムに入力する分の人件費が別途発生する。台帳の枚数が多い場合、この作業だけで見積もりの中で意外と大きな割合を占めることがある。あらかじめ社内で判読できる分は済ませておき、開発会社に依頼する範囲を絞ることで、コストを抑えられる。

過去データを「全部」移す必要は本当にあるか

紙台帳をシステム化する際、多くの経営者が「せっかくやるなら全部のデータを移したい」と考える。しかし、10年、20年分の台帳をすべてシステムに取り込むことが、本当に業務上必要かどうかは一度立ち止まって考えたほうがよい。

過去の取引履歴を参照する頻度が実際にはそれほど高くない場合、直近2〜3年分だけをシステムに移行し、それより古いデータは紙のまま保管しておく、という判断も十分に合理的だ。移行するデータの範囲を絞ることで、データクレンジングにかかる時間と費用を大きく圧縮できる。逆に、税務・法務上の保存義務がある期間のデータについては、システムに移すかどうかとは別に、紙またはスキャンデータでの保存を継続する必要がある点も忘れずに確認しておきたい。

古参社員の「使えない」を防ぐための工数

紙台帳からシステムへの移行で失敗する最大の要因は、実は技術的な問題ではなく、現場が新しいシステムを使ってくれないことだ。特に、長年紙の台帳に慣れてきた古参社員にとって、画面の操作を新たに覚えることは大きな負担になる。

見積もりの中に、この「運用移行・研修」の工数が含まれているかどうかは、依頼前に必ず確認したい項目だ。開発会社によっては、システムの納品までしか見積もりに含めておらず、現場への説明会や操作マニュアルの作成が別料金になっているケースがある。承継直後の会社では、社長自身がまだ全社員の信頼を完全に得ていない場合もあり、「社長が急に決めたシステム」という受け止め方をされると、現場の協力を得にくくなる。

古参社員を最初のヒアリング段階から巻き込み、「今の台帳のどこが不便だと感じているか」を聞いておくと、システム化そのものへの抵抗感が下がりやすい。先代の代からのやり方を否定するのではなく、「もっと楽にするための道具を入れる」という文脈で伝えることが、承継後のシステム導入では特に重要になる。こうした古参社員の抵抗にどう向き合うかは、先代の台帳が「重くて開けない」を放置するとどうなるかでも触れている。

紙とシステムの「並行運用期間」をどう設計するか

システムを導入したその日から、いきなり紙台帳を廃止するのは現実的ではない。多くの会社では、一定期間、紙とシステムを並行して運用し、システムの動作や入力内容に問題がないことを確認してから、紙を廃止するという段取りを踏む。この並行運用の期間をどの程度に設定するかも、見積もりや導入計画に影響する部分だ。

並行運用期間が長ければ、現場の負担は増えるが、システムの不具合や運用ルールの見直しにじっくり対応できる。短ければ移行は早く進むが、想定外の不具合が見つかったときの後戻りが難しくなる。承継直後で現場との信頼関係がまだ十分に築けていない場合は、多少長めの並行運用期間を設定し、古参社員が「これなら大丈夫」と納得できるまで紙を残しておく判断も一つの選択だ。開発会社との契約の中で、この並行運用のサポート期間がどこまで含まれているかも確認しておきたい。

見積もりを取る前に社長がやるべき5つの準備

開発会社に相談する前に、次の5点を整理しておくと、見積もりの精度と金額の妥当性を判断しやすくなる。

1. 台帳の現物を全種類集め、それぞれ何のために使っているかを一言でまとめる
2. 台帳を見ている人（記入者・参照者）を全員リストアップする
3. 台帳同士で連携している部分（在庫台帳の数字が請求書に反映されるなど）を図にする
4. 過去データをどこまで移行するか、範囲を決める
5. 予算の上限を先に決めておく（後出しで下がると開発会社との調整が難しくなる）

この準備を社長一人で行うのは難しい場合、まず台帳の一部だけを試験的にExcelへ書き出し、簡単な集計をしてみるという方法もある。既存の台帳がすでにExcelで一部管理されている、あるいは一部だけデジタル化されている場合、この試験的な整理を通じて、システム化すべき範囲や項目の全体像が見えてくることがある。いきなり開発会社に相談するのではなく、社内でできる範囲の下準備を済ませておくことが、結果的に見積もり交渉を有利に進めることにつながる。

準備に時間をかけすぎることのリスクもある

一方で、準備を完璧にしようとするあまり、着手が何ヶ月も先延ばしになってしまうケースもある。台帳の全項目を洗い出し、すべての例外運用を文書化し尽くそうとすると、それだけで半年、1年とかかってしまうことがある。承継直後は他にもやるべきことが山積みの時期であり、システム化の準備だけに時間を割き続けるわけにはいかない。

現実的には、準備は「8割程度の完成度」で開発会社に相談を始め、残りの2割は要件定義のプロフェッショナルであるエンジニアやディレクターとの対話の中で埋めていく、というくらいの姿勢がちょうどよい。準備不足を過度に恐れる必要はなく、むしろ「一緒に整理してくれる開発会社かどうか」を見極める材料として、最初の相談の場を活用するとよい。

相見積もりでチェックすべきポイント

システム開発の見積もりを複数社から取る際、金額だけを比較するのは危険だ。同じ「台帳のシステム化」という依頼でも、開発会社によって前提としている範囲が異なるため、金額の差が生まれる理由を必ず確認する必要がある。

• 見積もりに要件定義のフェーズが含まれているか、それとも別料金か
• データ移行・クレンジングの費用が含まれているか
• 保守・運用費用は月額でどの程度発生するか
• 台帳の項目が増えた場合の追加開発費の目安が示されているか
• 納品後、社内で軽微な修正ができる範囲はどこまでか

複数社から見積もりを取得し、費用だけでなく提案内容や技術力も含めて比較検討することが重要だとされている（発注ラウンジ）。特に承継直後の経営者は、先代の代からの付き合いがある業者にそのまま発注してしまうケースが多いが、システム開発は税理士や司法書士のように「型が決まった専門家」ではなく、会社ごとに提案内容が大きく異なる分野だ。先代の代からの関係性を大切にしつつも、一度は他社の見積もりも取ってみることをお勧めする。システム化そのものを検討すべきタイミングかどうかは、同時に開けない先代のExcel台帳、システム化の判断ラインはどこかも参考になる。

「先代の代からの業者」に頼み続けるかどうかの判断

先代の時代からシステムや事務用品を発注していた業者がいる場合、承継後もそのまま同じ業者に依頼するかどうかは、意外と悩ましい判断になる。長年の関係性があり、会社の事情をよく分かっているという安心感は大きいが、その業者がWebシステムの開発を専門としているかどうかは別問題だ。事務機器の販売や紙の帳票印刷を専門にしてきた業者が、Webシステムの開発も「できます」と言うケースもあるが、実際の開発体制や実績を確認せずに任せてしまうと、後になって技術的な限界にぶつかることがある。

判断に迷う場合は、既存の業者にも声をかけつつ、Webシステム開発を専門とする会社にも並行して相談し、提案内容を比較してみるとよい。先代の代からの関係を切ることになったとしても、それは先代を否定することにはならない。会社の次のステップに合った専門性を選ぶことは、承継した経営者としての正当な判断だ。

補助金という選択肢

紙台帳のシステム化にかかる費用の一部は、公的な補助金でカバーできる可能性がある。中小企業・小規模事業者のITツール導入を支援する制度として、2026年度は名称が「デジタル化・AI導入補助金」に変わり、通常枠では補助率1/2、補助上限額450万円という枠組みが示されている（デジタル化・AI導入補助金2026 公式サイト）。

補助金の詳細な要件や対象となるツールの範囲、申請スケジュールは公募回によって変更されることがあるため、実際に申請を検討する際は必ず公式サイトの最新の公募要領を確認してほしい。補助金の申請には、導入するITツールが登録されたものである必要があるなど、いくつかの条件があるため、開発会社に依頼する段階で「補助金の対象になるかどうか」を早めに確認しておくと、後から対象外だったと分かる事態を避けられる。

補助金をあてにして予算計画を立てる場合は、採択されなかった場合の代替プランも同時に用意しておくことが望ましい。補助金は「申請すれば必ず通る」ものではなく、審査を経て採択されるかどうかが決まる制度である点は留意しておきたい。

補助金申請のスケジュール感を先に把握しておく

補助金の活用を検討する場合、申請から採択、実際の補助金交付までには一定の期間がかかることも押さえておきたい。公募期間が設定されており、そのタイミングを逃すと次の公募回まで待つ必要が出てくる。台帳のシステム化を急いでいる場合、補助金の公募スケジュールと開発スケジュールがうまく噛み合わないこともあるため、両方の日程を早い段階で照らし合わせておくことが望ましい。

また、補助金の対象となるのはITツールの導入費用が中心であり、社内の業務整理やデータクレンジングにかかる人件費までは対象にならないことが多い。補助金でカバーできる範囲とできない範囲を区別しておくことで、実際の自己負担額のイメージが明確になる。

名義・権利関係とシステムの落とし穴

承継の場面で見落とされやすいのが、台帳に記録されている情報の「名義」の問題だ。先代個人の名義で管理されていた取引先情報や、先代個人のメールアドレス・電話番号が台帳に記載されているケースは少なくない。システム化するタイミングで、これらの情報を会社としてどう扱うかを整理し直す必要がある。

特に、先代が個人で契約していたクラウドサービスや電話番号がそのまま業務台帳の一部として機能していた場合、システム化と同時に契約の名義変更や引き継ぎが必要になる。これは開発会社の範囲外の作業になるため、社長自身か顧問の専門家（税理士・行政書士など）と別に進めておく必要がある。システムの見積もりには含まれない部分だが、システム化のタイミングでまとめて片付けておくと、後々の手続きの手間が減る。

取引先の個人情報をシステムに載せる際の注意点

台帳には、取引先の担当者名や個人の携帯番号など、個人情報に該当する情報が多く含まれている。紙のままであれば台帳を鍵付きの棚にしまっておくといった管理で済んでいたが、Webシステムに載せる場合は、誰がその情報にアクセスできるのか、外部からの不正アクセスに対する対策がどうなっているのかを、システム設計の段階で決めておく必要がある。

特に、社外からもアクセスできるようにしたいという要望がある場合、アクセス権限の設計や通信の暗号化など、セキュリティに関わる要件が増え、その分の開発費も上乗せされる。個人情報を扱う以上、パスワードの管理体制や、退職した社員のアカウントを速やかに無効化する運用ルールも、システムの機能だけでなく社内の運用として決めておくべきだ。開発会社に見積もりを依頼する際は、セキュリティ面の要件をどこまで含めるかも明確に伝えておくとよい。

段階的に進めるという選択

最初から全ての台帳を一気にシステム化しようとすると、要件定義の範囲が膨らみ、見積もり金額も大きくなりやすい。承継直後で予算にも限りがある場合は、最も業務のボトルネックになっている台帳から段階的に着手するという進め方がある。

例えば、まずは検索性が最も課題になっている取引先台帳だけをシステム化し、在庫台帳や案件台帳は次のフェーズに回す、という進め方であれば、初期投資を抑えつつ、システムが実際に現場で使われるかどうかを検証しながら進められる。この進め方は開発会社にとっても提案しやすく、フェーズごとに見積もりを分けて出してもらうことで、予算の見通しも立てやすくなる。

• 第1フェーズ：最もボトルネックになっている台帳1つをシステム化
• 第2フェーズ：運用が定着したことを確認してから、関連する台帳を追加
• 第3フェーズ：台帳同士の連携（自動反映など）を実装

一度にすべてを変えようとせず、現場が新しい仕組みに慣れる時間を確保しながら進めることが、結果的に総コストを抑えることにもつながる。

フェーズ分けをするときの契約の結び方

段階的に進める場合、契約の結び方にも工夫が必要になる。最初から全フェーズの契約を一度に結んでしまうと、第1フェーズの結果を見て方針を変えたいと思っても、契約上の変更が難しくなることがある。可能であれば、フェーズごとに契約を分け、前のフェーズの結果を評価してから次のフェーズに進むかどうかを判断できる形にしておくと、リスクを抑えられる。

開発会社によっては、複数フェーズを前提とした契約でなければ割引が適用されない、という料金設計をしているところもある。フェーズを分けることによる安心感と、まとめて契約することによる割引のどちらを優先するかは、会社の資金繰りの状況や、システム化そのものへの確信度によって判断すればよい。承継直後で資金の見通しがまだ立てにくい時期であれば、多少割高でもフェーズごとの契約を選び、都度判断できる余地を残しておくほうが安全なことが多い。

台帳のデータを他システムと連携させる場合の追加費用

台帳をシステム化した後、さらに会計ソフトや在庫管理システムなど、他のシステムと連携させたいという要望が出てくることがある。この連携には、追加の開発費が発生するのが一般的だ。特に、既存の基幹システムが古い場合、データの受け渡し形式がCSVでのやり取りしかできないこともあり、その場合は定期的な手動エクスポート・インポート作業か、自動化するための追加の仕組みが必要になる。

社内で定型的なデータの変換・転記作業が発生している場合は、Power Automateのような自動化ツールを使うことで、フルスクラッチの連携開発をせずに済むケースもある。台帳システムと他システムの間で「毎月同じ形式のファイルをやり取りするだけ」であれば、自動化ツールでの対応がコストを抑える現実的な選択肢になる。

見積もり金額が「高い」と感じたときの考え方

開発会社から出てきた見積もりを見て、「思っていたより高い」と感じることは多い。ここで判断を誤りやすいのが、金額の高さだけで良し悪しを決めてしまうことだ。金額が高い場合、次のいずれかに当たっている可能性がある。

• 要件定義の範囲が広く、複数の台帳・複雑な業務ロジックを含んでいる
• データ移行・クレンジングの作業量が多い
• 保守・運用体制まで含めた提案になっている
• 単純に開発会社の単価が高い（大手・実績重視の会社ほど単価は上がりやすい）

逆に、極端に安い見積もりが出てきた場合は、要件定義が浅いまま金額だけを提示している可能性や、保守・運用の費用が別途大きく発生する可能性を疑ったほうがよい。見積もりの金額そのものより、その金額が何を含み、何を含んでいないかを確認する姿勢のほうが重要になる。

社内に相談できる相手がいないときの動き方

税理士や司法書士のように「決まった相談先」がいないシステムの分野では、社長一人で判断を迫られる場面が多い。この孤独感は、承継した経営者にとって特有の悩みだと言える。株式や登記の手続きは専門家に頼めば型が決まっているのに、システムの話になると誰に聞けばいいのか分からない、という感覚を持つ社長は少なくない。

こうした状況では、いきなり1社に絞って発注するのではなく、まず複数の開発会社に「相談だけ」してみることをお勧めする。多くの開発会社は、正式な見積もりの前に無料の相談や、業務内容のヒアリングを行っている。この段階で、自社の状況をどう説明すればいいか、何を準備すればいいかを聞くだけでも、判断材料が大きく増える。一社の意見だけを信じるのではなく、複数の視点を取り入れることが、判断の孤独さを和らげる一つの方法になる。

まとめではなく、次にやるべき一歩

紙台帳をそのままWebシステム化する費用は、Excel化なら数万円から、フルスクラッチなら1000万円を超えることもあり、金額の幅は非常に大きい。この幅を決めるのは、台帳の複雑さそのものよりも「先代の運用ロジックをどこまで汲み取るか」「過去データをどこまで移行するか」「古参社員が使い続けられる形にできるか」という、技術以外の要素であることが多い。

先代の代からの台帳には、単なる記録以上の意味がある。そこには先代が長年かけて調整してきた業務のリズムが刻まれている。それを壊さずに、しかし今の会社に合った形で次の世代に引き継ぐ。それがこのシステム化という作業の本質だ。まずは台帳を1冊開いて、誰が何を書き込んでいるかを眺めてみることから始めてほしい。その小さな一歩が、見積もりの精度を上げ、承継後の会社に合ったシステムへの最短ルートになる。

よくある質問

Q1. 先代がまだ経営に関わっている場合、システム化を進める前に何を確認すべきですか？

まず、先代が台帳のどの部分を最も重視しているかを確認することをお勧めする。長年の運用の中で、先代にしか分からない例外処理や判断基準が存在することが多く、これを聞かずに進めると、システム化後に「これでは使えない」という指摘を受けることになる。先代への配慮という意味でも、「やり方を変える」ではなく「やり方を今の形に整理し直す」という説明で合意を取ってから進めるのが安全だ。

Q2. 古参社員がシステムに抵抗を示す場合、どう説明すればいいですか？

古参社員が抵抗を示す背景には、長年の台帳運用への誇りや、新しい操作を覚える負担への不安がある場合が多い。要件定義の段階から古参社員にヒアリングし、「今の台帳のどこが不便か」を聞く形で巻き込むと、システムが「社長が勝手に決めたもの」ではなく「現場の声を反映したもの」として受け入れられやすくなる。

Q3. 先代個人の名義で管理されていた取引先情報は、システム化のときにどう扱うべきですか？

台帳に記載された取引先情報や連絡先が先代個人の名義・連絡先に紐づいている場合、システム化のタイミングで会社としての管理形態に整理し直す必要がある。これはシステム開発会社の作業範囲には含まれないことが多いため、税理士や行政書士など専門家に別途相談し、契約や名義の引き継ぎを並行して進めておくとよい。

Q4. 見積もりが会社によって大きく異なるのはなぜですか？

同じ「台帳のシステム化」という依頼でも、開発会社が前提としている範囲（要件定義の深さ、データ移行の有無、保守・運用の含み方）が異なるため、金額に大きな差が生まれる。金額だけで比較せず、見積もりに何が含まれ、何が含まれていないかを必ず確認してから判断することが重要だ。