先代データのクレンジング、システム移行で失敗しないために

先代から会社を継いで数ヶ月、あるいは1年ほど経った頃、こんな状況に心当たりはないだろうか。古い在庫管理システムか会計ソフトの契約更新期限が迫っていて、ベンダーから「そろそろ新しいシステムに移行しませんか」と連絡が来た。見積もりを取ってみると、思っていたより高い。しかも見積書の内訳をよく見ると「データ移行費」という項目が、システム本体の導入費と同じくらいの金額で乗っている。なぜデータを移すだけでこんなに費用がかかるのか、営業担当に聞いても「既存データの状態次第です」とはぐらかされたような答えしか返ってこない。そもそも、そのデータというのは先代の時代から20年近く積み重ねてきた、得意先名や品目名の表記が微妙にバラバラな、あの古い基幹システムの中身のことだ。

株式や登記の引継ぎには税理士や司法書士という明確な相談先がいる。しかし「先代が使っていたシステムの中のデータをどう新システムに移すか」という問題には、相談先が見つからない。この記事では、事業承継後にシステム移行を控えている経営者が、何を見て、何を先代や古参社員に確認し、何をベンダーに依頼すべきかを、実務の順序に沿って整理する。結論を先に言えば、システム移行の失敗の大半は「移行先システムの機能不足」ではなく「移行元データの汚れ」に起因する。そしてそのデータの汚れの正体を知っているのは、先代でも古参の事務担当者であることが多い。承継直後の今こそ、その知識が失われる前に手を打つべき局面にある。

見積書の「データ移行費」という一行に潜む本当のリスク

先代から会社を継いだ社長が最初に戸惑うのは、たいてい金額の大きさそのものではなく、その内訳の分からなさだ。システム本体の月額利用料や導入費は他社の事例と比較しやすい。ところが「データ移行費」という一行だけは比較のしようがない。なぜなら、その金額は自社のデータがどれだけ汚れているかによって変わる、いわば「見えない負債」の請求書だからだ。先代の代から積み重ねてきたデータの中身を誰も精査したことがないまま契約日を迎えると、契約後に「想定より件数が多い」「想定より表記の揺れが激しい」という理由で追加費用の相談が来る。これは詐欺的な話ではなく、多くの移行プロジェクトで実際に起きている構造的な問題であり、承継直後の会社ほどこのリスクに気づきにくい。

なぜ「データの汚れ」が承継後のシステム移行で致命傷になりやすいのか

新システムへの移行プロジェクトが遅延したり、思うような効果が出なかったりする最大の要因は、多くの場合システムそのものの性能ではなく、移行するデータの品質にある。基幹システムのデータ移行を解説する専門記事でも、移行作業では既存データの重複や表記揺れ、入力ミスへの対処、つまりデータクレンジングが不可欠であり、データの品質そのものが新システム導入後に得られる効果を大きく左右すると指摘されている（EC-CUBE「基幹システムのデータ移行実践ガイド」）。承継直後の会社ではこの傾向がさらに強く出る。なぜなら、先代の時代に「その場で分かればいい」という前提で作られたデータ構造が、そのまま20年、30年と積み重なっているケースが多いからだ。

先代がまだ現役だった頃は、システムの中身がどれだけ雑然としていても、先代の頭の中にある「暗黙の補正ルール」でカバーされていた。「このコードの得意先は実は同じ会社の別部署」「この品目名の末尾に(旧)とついているのは廃盤だが請求だけ残っている」といった知識が、先代や長年その業務を担ってきた古参社員の記憶の中にだけ存在し、システムのどこにも記録されていない。承継した二代目・三代目の社長がこの状態のままシステム移行を発注すると、ベンダー側はデータの見た目上の項目名や件数だけを見て見積もりを作る。実際に移行作業が始まった段階で「このコード、統合していいのか分割すべきなのか分からない」という照会が山のように発生し、そこで初めて工数超過が判明する。

承継後によくある「データの汚れ」の具体的な症状

実際にどのような汚れがシステムの中に潜んでいるのか、承継後の会社で典型的に見られるパターンを整理する。

• 同じ取引先が「株式会社山田商店」「(株)山田商店」「ヤマダショウテン」など表記違いで複数の得意先コードとして登録されている
• 廃業・倒産した取引先や退職した社員のレコードが削除されずに残り続けている
• 先代の代で使われていた品目コードの命名規則と、その後の担当者が引き継いだ命名規則が途中で変わっており、同じ商品が別コードで存在する
• Excelで別管理されている「裏帳簿」的な単価表や掛率表があり、基幹システムの数字と一致しない
• 住所や電話番号が旧市町村名のまま、あるいは会社移転後も旧住所のまま更新されていない
• 先代が個人的にメモしていた「この客は掛売り不可」「この客には季節ごとに特別価格」といった取引条件が、システムのどの項目にも反映されていない

これらは新システムに移行した瞬間に「システムが使えない」という表面上の不具合として現れるわけではない。むしろ移行直後は動いているように見えて、数ヶ月後に「この得意先の売上が二重に計上されている」「この商品の在庫数がおかしい」という形で遅れて発覚する。承継したばかりの社長にとって最も避けたいのは、まさにこの「後から出てくる」タイプの不具合だ。

承継後の会社ほどデータが汚れやすい構造的な理由

承継後の会社のデータが特に汚れやすいのには、はっきりした理由がある。まず、システムの導入担当者と現在の運用担当者が異なる場合が多い。先代の代でシステムを導入した当時の担当者がすでに退職しているケースでは、なぜそのコード体系になっているのかという「設計思想」が誰にも分からなくなっている。次に、事業の規模拡大や業態変化に応じて運用ルールが何度か変わっているにもかかわらず、古いルールで作られたレコードがそのまま残り続けていることが多い。たとえば取引先が10社程度だった創業期には手作業での管理で十分だったものが、100社を超えた現在も当時のコード命名規則のまま拡張され続けている、という状態だ。

さらに、先代が現役だった時期には「困ったら先代に聞けばいい」という安全網が機能していたため、データの不整合を正式に修正する必要性が生まれなかった、という側面もある。承継によってこの安全網が外れた瞬間に、データの不整合が組織としての実害に転化する。つまり、承継そのものがデータの汚れを「潜在的な問題」から「対処すべき現実の問題」へと引き上げるきっかけになっているとも言える。

移行費用の内訳を分解して理解する

システム移行の見積もりで「データ移行費」がなぜシステム本体導入費に匹敵するのか、その構造を理解しておくと、ベンダーとの交渉で不利な立場に立たされずに済む。データ移行の作業は大きく分けて、既存データの現状分析、データクレンジング、移行先フォーマットへの変換、テスト移行と検証、本番移行という工程で構成される。このうち最も工数が読みにくく、後から膨らみやすいのがデータクレンジングの工程だ。

基幹システムの入れ替えにおいては、データの種類ごとに優先度を分けて扱うべきだとされており、カスタマイズデータ、マスタデータ、トランザクション（取引履歴）データという順で重要度と作業の複雑さが変わってくる（EC-CUBE「基幹システムのデータ移行実践ガイド」）。得意先マスタや品目マスタといった「マスタデータ」は件数自体は少なくても、表記の統一や重複の解消に人手と判断が必要になるため、想定以上に時間がかかりやすい部分だ。一方で日々の売上や仕入れの記録である「トランザクションデータ」は件数が膨大だが、機械的な変換で処理できる割合が高い。

見積書に「データ移行費一式」としか書かれていない場合は、この工程分解を依頼し、特にマスタデータのクレンジングにどれだけの工数が割かれているかを確認するとよい。ここが薄い見積もりは、後から追加費用が発生する典型的なパターンだからだ。

見積もりの「前提条件」を必ず書面で確認する

ベンダーから提示される見積もりには、多くの場合「前提条件」という欄がある。ここには「得意先マスタは500件までを想定」「表記統一済みのデータであることを前提とする」といった注記が小さく書かれていることが多い。承継直後で自社データの実態を把握していない社長は、この前提条件を読み飛ばしてしまいがちだ。しかし、実際のデータがこの前提を超えていた場合、追加費用の請求は契約上正当な扱いとなる。

見積もりを受け取った段階で、次の3点は必ず確認しておきたい。第一に、想定件数と自社の実際のマスタ件数が合っているか。第二に、「表記統一済み」を前提にしているかどうか、していない場合はクレンジング作業がどこまで含まれているか。第三に、想定を超えた場合の追加費用の算出方法があらかじめ明示されているか。この3点を契約前に確認するだけで、後から想定外の請求書に驚くリスクは大きく減らせる。

「データ移行費が高すぎるのでは」と感じたら、まず確認すべきは金額そのものではなく、その金額の中に「先代の時代の表記揺れをどう統一するか」という作業が含まれているかどうかである。含まれていない見積もりは、後で必ず追加費用の請求書として戻ってくる。

先代に聞くべきこと、聞けるうちに聞いておくこと

承継直後というタイミングには、システム移行において決定的に重要な意味がある。先代がまだ相談に応じられる状態にあるうちに、システムの中身について次のようなことを確認しておく必要がある。

1. 得意先コード・品目コードの命名規則に、あとから見ても分からない「裏ルール」がないか
2. システムに登録されていない「口約束の特別条件」（掛売り、特別価格、リベートなど）がある取引先はどこか
3. Excelや紙の台帳で別管理している情報があるか、あるとすればそれは何のためか
4. 過去に一度システムを入れ替えた経験があるか、あるとすればその時に何が問題になったか
5. 「このデータだけは絶対に消してはいけない」という認識があるものは何か

これらは経営権や株式の引継ぎとは違い、契約書や登記簿には残らない。先代の記憶がすべてであり、記憶は時間とともに薄れる。事業承継ガイドラインでも、後継者への引継ぎを円滑に進めるためには経営状況や経営資源を見える化し、現状を正確に把握するプロセスが出発点になるとされている（中小企業庁「事業承継ガイドライン（第3版）」）。ここで言う経営資源には、有形の設備や人材だけでなく、業務の中で蓄積されたデータやその運用ノウハウも含まれると捉えるべきだろう。株式の名義や会社の登記といった制度的な引継ぎには税理士や司法書士という専門家がついているが、システムの中身の引継ぎには誰もついていない。この記事を読んでいるあなたが、その空白に最初に気づいた人になる可能性が高い。

聞き取りは一度で終わらせず、時期をずらして繰り返す

先代への聞き取りは、一度きりの面談で終わらせようとすると取りこぼしが多くなる。先代自身も、日々の業務の中で「ああ、あの件も伝えておかなければ」と思い出すことが後から出てくるものだ。決算期、棚卸しの時期、大口取引先との契約更新の時期など、業務の節目ごとに「この場面でシステムを使うとき、何か注意することはありますか」と短く聞く機会を作ると、一度の面談では出てこなかった情報が拾えることが多い。

聞き取った内容は、その場でメモを取るだけでなく、できれば箇条書きの形で文書化し、先代本人にも「こういう理解でよいか」と確認してもらうことをお勧めする。記憶に基づく情報は、聞いた側の解釈によって微妙にずれることがあるため、文書化と本人確認のワンクッションを置くことで、後々の食い違いを防げる。

古参社員が持っている「暗黙知」をどう吸い上げるか

先代がすでに引退している、あるいは頻繁には相談できない状況にある場合、次に頼るべきは長年その業務を担当してきた古参の事務担当者やベテラン社員だ。彼らは日々の入力作業を通じて、システムの矛盾や表記のクセを肌感覚で知っている。ただし、古参社員に「システムのデータについて教えてください」と抽象的に聞いても、有効な情報はあまり出てこない。実務上有効なのは、次のような具体的な依頼の仕方だ。

抽象的な質問より、具体的な業務のシーンに紐づけて質問した方が、記憶に残っている情報が引き出しやすい。承継直後で古参社員との関係がまだ固まっていない社長にとって、この聞き取り作業自体が信頼関係を築く機会にもなる。「先代の時代からのやり方を軽視せず、まず理解しようとしている」という姿勢が伝われば、システム移行の協力も得やすくなる。

聞き取った情報をどこに記録しておくか

古参社員から聞き出した暗黙知は、その場でメモを取るだけでは、時間が経つと結局また埋もれてしまう。理想的には、得意先マスタや品目マスタの一覧に「備考」列を追加し、聞き取った内容をそのレコードに直接紐づけて記録していく方法が効果的だ。たとえば「株式会社山田商店」というレコードの備考欄に「旧・有限会社山田商店。2015年に法人化。請求書の宛名は変更後のものを使用」と書き加えておけば、次にこのデータを見る人が同じ疑問を先代や古参社員に聞き直す必要がなくなる。

この備考欄への記録作業自体は、特別なシステムを必要としない。既存のExcel台帳やシステムからの出力データに列を1つ追加するだけで始められる。承継直後の今、時間をかけてでもこの記録作業を進めておくことが、次のシステム移行の際にクレンジング工数を大きく削減する下準備になる。

移行前に自社でできる下準備

ベンダーに依頼する前、あるいは依頼と並行して、自社側でもできる下準備がある。すべてを外部に委ねてしまうと、費用がかさむだけでなく、社内に「このデータはこういう理由でこうなっている」という理解が残らない。

• 得意先・品目・仕入先などの主要マスタをCSVやExcelで一覧出力し、目視で重複や表記揺れをチェックする
• 過去1〜2年使われていない得意先・品目コードをリストアップし、削除候補か保持すべきか古参社員に確認する
• 表記統一のルール（全角半角、法人格の書き方など）を1枚のルール表としてまとめる
• Excelで別管理されている情報がどこにあるか、部署ごとに聞き取りをして一覧化する

こうした下準備は移行費用そのものを直接下げるわけではないが、ベンダーとの見積もり交渉で「うちはここまでは自分たちで整理済みです」と示せる材料になる。また、単純な文字列の整形やCSVでの重複チェックといった作業であればVBAマクロで自動化できる部分もあり、必ずしも高額な外部ツールを導入しなくても着手できる。

下準備をどこまで自社でやるべきかの判断基準

自社での下準備には限度がある。すべてを完璧に整理してからベンダーに依頼しようとすると、いつまでも移行に着手できず、かえって旧システムの契約期限やサポート終了のタイムリミットに追われることになる。目安としては、次のような判断基準を持つとよい。単純な表記の統一（全角半角、法人格の位置など）や、明らかに使われていないレコードの特定は自社で行い、どのレコードを「同じもの」として統合すべきかという業務判断が必要な部分、複数の担当者の意見が分かれる部分は、無理に自社だけで結論を出さずベンダーやシステム移行の専門家を交えて整理する。

自社でできる範囲とベンダーに委ねるべき範囲を最初に切り分けておくことで、見積もりの精度も上がり、移行プロジェクト全体の進行も早くなる。この切り分け自体を、契約前の打ち合わせでベンダーに相談してみるのも一つの方法だ。

データクレンジングという工程を正しく発注するために

データの汚れを取り除く作業、つまりデータクレンジングは、システム移行プロジェクトの中でも特に「見えにくい」工程だ。プログラムのバグのように動作確認で発見できるものではなく、実際にデータを使う業務の場面まで進んでから「おかしい」と気づくことが多い。だからこそ発注段階で、この工程が具体的にどう進められるのかを確認しておく必要がある。

確認すべき論点は次のようなものだ。

• クレンジングの判断基準（どの表記を正とするか）を誰が決めるのか。ベンダー任せにすると、現場の実情と合わない統一がされる恐れがある
• 重複データの統合作業で、統合後にどちらの履行履歴が優先されるのか
• クレンジング後のデータをテスト環境で確認する機会が、本番移行前に何回設けられているか
• 移行後に問題が見つかった場合、どの期間まで無償で手直しに対応してもらえるか

基幹システムの入れ替えを解説する複数の専門記事が共通して指摘しているのは、テストデータでの移行リハーサルを行い、そこで問題を洗い出してから本番移行に進むという段階を踏むことの重要性だ。一度の本番移行で全てを切り替える「一斉移行」は速いが失敗時のリスクが大きく、段階的に移行するか、旧システムと並行稼働させて結果を確認しながら進める方式の方が、承継直後で社内の目が届きにくい会社には向いている場合が多い。

リハーサル移行で発見しておきたいポイント

本番移行の前に行うリハーサル移行、いわゆるテスト移行では、実データの一部を使って新システムに実際に取り込み、業務担当者に確認してもらう工程を設けることが望ましい。このとき、システムが正しく動くかどうかだけでなく、次のような観点で確認するとより実効性が高まる。第一に、移行後のデータを見て「あれ、これ違う」と気づく人が現場にいるかどうか。気づく人がいなければ、そもそも誰もそのデータの正しさを判断できない状態にあるということになる。第二に、移行前と移行後で集計結果（売上合計、在庫総数など)が一致するかどうかを、経理担当者を交えて突き合わせる。第三に、日常的によく使う検索・絞り込みの操作が、新システムでも同じ手順でできるかどうかを、実際に業務を担う社員に試してもらう。

このリハーサルの段階で古参社員に積極的に関わってもらうことは、単に不具合を発見するためだけでなく、新システムへの心理的な抵抗感を和らげる効果もある。「自分が確認した上で移行された」という実感があれば、本番稼働後のトラブルにも冷静に対応してもらいやすくなる。

移行方式の選び方と承継期の相性

システム移行には大きく3つの方式がある。一斉に全データ・全機能を切り替える方式、モジュールごとに段階的に移行する方式、そして旧システムと新システムを一定期間並行稼働させて結果を照合する方式だ。それぞれにメリットとデメリットがある。

承継直後の会社では、社長自身がまだ業務の細部を把握しきれていないことが多い。この状態で一斉移行に踏み切ると、問題が起きたときに「何が正しい状態だったか」を判断できる人が社内にいない、という事態に陥りかねない。段階的移行であれば、1つのモジュールを移行するごとに古参社員に確認を取りながら進められるため、承継期特有の「知見の分散」というリスクを緩和しやすい。こうした老朽化システムの段階的な作り替えはシステムリプレース（運営会社ゼットリンカーの受託メニュー）として専門に扱う会社に相談する選択肢もあります。

業務の繁忙期を避けて移行時期を決める

移行方式と並んで重要なのが、移行を実施する時期の選び方だ。決算期の直前直後、棚卸しの時期、業界特有の繁忙期にシステム移行を行うと、業務担当者が移行の確認作業に十分な時間を割けず、結果として不具合の見落としが増える。承継直後の社長は、旧システムの契約更新期限に引きずられて移行スケジュールを決めてしまいがちだが、可能であれば契約更新の交渉を先に行い、猶予期間を確保した上で、業務が比較的落ち着く時期に移行を設定する方が安全だ。システム化そのものを検討すべきタイミングかどうかの見極めは、同時に開けない先代のExcel台帳、システム化の判断ラインはどこかも参考になる。

ベンダーとの契約更新交渉では、「システム移行を検討しているため、その間の短期契約や移行完了までの猶予期間を設けてもらえないか」と早めに相談しておくとよい。多くのベンダーは、次の契約に進む可能性がある顧客に対しては、一定の柔軟性を持って対応してくれることが多い。

古参社員との関係を壊さずに進めるための配慮

システム移行というテーマは、単なる技術的な作業に見えて、実は社内の人間関係に強く影響する。古参社員にとって、長年使い慣れたシステムや、自分たちが工夫して作り上げてきたExcelの管理表を「非効率だから廃止する」という話は、自分の仕事のやり方そのものを否定されたと感じさせてしまうことがある。

先代の代からその業務を任されてきた社員であればなおさらだ。「先代のやり方が古いから変える」という言い方は避け、「先代の時代に積み上げてきたやり方を、次の20年も活かせる形に残したい」という伝え方をする方が、協力を得やすい。データクレンジングの過程で見つかる矛盾や非効率も、「間違っていた」と指摘するのではなく、「その時代の事情でそうなっていた背景を教えてほしい」という姿勢で聞くことが、結果的に正確な情報を引き出すことにもつながる。

名義や権限の問題も一緒に整理する好機にする

システム移行のタイミングは、データそのものの問題だけでなく、システムの契約者名義やアカウント権限の問題を洗い出す好機でもある。先代個人の名前で契約されているクラウドサービスのアカウント、先代の個人メールアドレスが管理者権限になっているシステム、退職済みの社員のアカウントがまだ有効なままになっているケースなど、承継後に放置されがちな「名義の後始末」がシステム移行の作業の中で自然に発見されることが多い。

これらは法律的な株式や登記の名義変更とは別の問題だが、放置すると先代に何かあった場合にシステムへのアクセス自体ができなくなるという実務上のリスクを抱えることになる。移行作業の中で契約者情報の一覧を作る過程で、こうした名義の問題も洗い出し、あわせて新しい契約者名義に変更しておくとよい。

契約書類とパスワード管理も一緒に見直す

システムの名義とあわせて見直しておきたいのが、契約書類の保管場所とログイン情報の管理方法だ。先代の代では、システムのID・パスワードが先代のデスクの手帳や、先代しか開けない引き出しの中に手書きでまとめられている、という状態は決して珍しくない。承継後にシステム移行を進める段になって、そもそも既存システムにログインするための情報が見つからず、ベンダーへの問い合わせから作業が始まるということも起こり得る。

新システムへの移行を機に、社内で使っているすべてのシステムのアカウント情報を一覧化し、パスワード管理ツールなどを使って複数人がアクセスできる状態に整備しておくと、次に同じような承継の場面が来たときにも困らずに済む。これは今のシステム移行の直接の作業ではないが、承継直後というタイミングだからこそ合わせて手を付けておく価値がある。

小規模な移行から始めて感覚を掴む

社内にシステム移行の経験者がいない状態で、いきなり基幹システム全体の移行に着手するのはリスクが高い。可能であれば、比較的影響範囲が小さいシステム、たとえば勤怠管理や経費精算といった業務から移行を経験し、データクレンジングとはどういう作業なのか、どこにどんな時間がかかるのかを社内で体感してから、基幹システムの移行に進む方が、結果的に大きな失敗を避けやすい。

小規模な移行であれば、CSV形式でのデータ書き出し・読み込みだけで完結する場合も多く、外部ベンダーに大きな費用を払わずに社内で試すこともできる。ここで得られた「うちの会社のデータはどこが汚れやすいか」という感覚は、次の大きな移行プロジェクトの発注内容を精度高く詰めるための土台になる。こうした業務自動化をどの領域から着手すべきかは、生成AIの次に手を出す業務自動化、経理と現場のどちらを先にすべきかにも判断軸を整理している。

移行後に必ず設けるべき検証期間

データ移行が完了した直後は、見た目上問題なく動いているように見えても、実際の業務で使い込まれるまで発覚しない不具合が潜んでいることが多い。月次の請求処理、四半期ごとの棚卸し、年次の決算処理など、業務のサイクルの中で初めて通る処理経路があるためだ。

移行完了後、最低でも1つの月次サイクルと可能であれば四半期のサイクルを旧システムのデータと突き合わせながら検証する期間を設けることを、契約時にあらかじめベンダーとの間で合意しておくべきだ。この検証期間をどこまで無償の保守範囲に含めるかは、見積もり段階での重要な交渉ポイントになる。「移行完了」の定義を、単に新システムにデータが入った時点ではなく、1〜2サイクルの業務を実際に問題なく回せた時点に置くという認識を、発注前にベンダーと共有しておくことが望ましい。

承継直後の社長が陥りやすい判断ミス

最後に、承継したばかりの経営者がシステム移行の場面で陥りやすい判断ミスをいくつか挙げておく。

• 「先代の時代のやり方は古いから、全部最新のやり方に変えよう」と一気に刷新しようとし、古参社員の反発と業務の混乱を同時に招く
• データの中身を確認せずに、機能の新しさだけでベンダーやシステムを選定する
• 見積もりの「データ移行費」を単なる作業費と捉え、内訳を確認せずに契約する
• 先代や古参社員への聞き取りを「今さら聞くのは恥ずかしい」と後回しにし、聞けるタイミングを逃す
• 移行後の検証期間を軽視し、契約上「移行完了」の時点を曖昧にしたまま進める

これらのミスの多くは、技術的な知識の不足ではなく、承継期特有の「聞くべき人が身近にいるうちに聞いていない」という時間軸の問題に起因する。先代の記憶、古参社員の暗黙知は、時間とともに確実に薄れていく。システムの契約更新のタイミングが来たからという理由だけで移行を急ぐ前に、まずは社内に残っている記憶を掘り起こす作業から始めることが、結果的に移行費用も工期も抑えることにつながる。受発注のFAX・手書き対応から抜け出す際の考え方はFAX・手書き台帳からの受発注、抜け出すための第一歩にも通じるものがある。

まとめにかえて

システムの移行は、一度きりの大仕事に見えて、実際には次の10年、20年の業務の土台を作る作業でもある。先代が築いてきたデータの中には、非効率に見える部分もあれば、その会社ならではの取引の知恵が刻み込まれている部分もある。それを一方的に切り捨てるのではなく、丁寧に読み解いてから次のシステムに引き継ぐという姿勢が、結果的に古参社員との信頼関係も、移行後のシステムの使いやすさも守ることになる。焦らず、聞けるうちに聞き、整理できるところから整理していく。それが、承継直後の今だからこそできる、次の世代への確実な引継ぎ方だ。

よくある質問

Q1. データ移行の前に、まず何から手をつければよいですか。

最初にすべきは、既存システムの主要マスタ（得意先・品目・仕入先など）をCSVなどで一覧出力し、表記の揺れや重複がどの程度あるかを目視で確認することだ。同時に、先代や古参社員に「システムの中で分かりにくいと感じる部分」を具体的な業務シーンに紐づけて聞き取っておくと、後のクレンジング作業の精度が上がる。

Q2. 先代がすでに引退していて、システムの経緯を聞ける人がいません。どうすればよいですか。

先代本人に聞けない場合でも、長年その業務を担当してきた古参の事務担当者やベテラン社員が同等の知識を持っていることが多い。抽象的に「データについて教えてください」と聞くのではなく、「今月の請求書を見ながら、システムと違う項目を教えてください」といった具体的な業務シーンに落とし込んで質問すると、記憶が引き出しやすくなる。

Q3. 古参社員が長年使ってきたExcelの管理表を廃止しようとすると、強い反発を受けます。どう進めればよいですか。

「先代のやり方が古いから変える」という伝え方は反発を招きやすい。「先代の時代に積み上げてきた知恵を、次の20年も活かせる形で残したい」という姿勢で伝え、Excel管理表の中身がなぜそうなっているのかを先に理解しようとする聞き取りから始めると、協力を得やすくなる。

Q4. データ移行費用が見積もりの中で高額に見えるのですが、妥当かどうかどう判断すればよいですか。

「データ移行費一式」としか書かれていない見積もりは要注意だ。マスタデータのクレンジングにどれだけの工数が充てられているか、その工程分解を依頼して確認するとよい。ここが薄い見積もりは、移行作業が始まってから追加費用が発生しやすい典型的なパターンだ。