先代が契約したSaaS（受発注管理、勤怠、顧客管理など）を「もう古いから」「料金が高いから」と解約しようとして、いきなり手が止まった経験はないだろうか。管理画面のどこかに「データをエクスポート」というボタンはある。だがCSVを開いた瞬間、見慣れた取引先名が文字化けし、日付の列が「45678」のような謎の数字に変わっていて、そこで固まってしまう——これは承継直後の社長が非常によく踏む落とし穴である。
結論から言うと、先代SaaSを解約する前にやるべきことは3つしかない。「今すぐ全項目をCSVで書き出す」「文字コードと日付形式を目視で確認する」「新システムに取り込む前に一度Excelで整形する」。この3工程を解約ボタンを押す前に終わらせておけば、データ消失という後戻りできない事故は防げる。逆に、解約手続きを先に進めてから「データが欲しい」と気づいたときには、多くのSaaSでは契約終了と同時にデータへのアクセス権も失われており、サポートに問い合わせても「保存期間は過ぎました」と言われるケースが少なくない。
株式や不動産、金融機関との取引といった承継の手続きには、税理士や弁護士、事業承継・引継ぎ支援センターといった相談先が用意されている。しかし「先代の代からずっと使っているシステムのデータをどう扱うか」については、相談できる専門家が身近にいないという社長は多い。情報システム部門を持たない会社であればなおさらだ。この記事では、先代SaaSを解約する前に社長自身の手で確認・実行できる作業を、承継直後の状況を想定しながら順番に解説する。
なぜ「解約してから考える」が一番危険なのか
先代SaaSの解約は、多くの場合「経費削減」というシンプルな動機から始まる。月額数千円から数万円のツールが、先代の時代から積み重なって10本近く契約されていた、というのは承継後の棚卸しでよく出てくる話だ。しかし、解約ボタンを押す行為は「データへのアクセス権を放棄する」行為と表裏一体であることを、まず理解しておく必要がある。
多くのSaaSベンダーは、契約終了後のデータ保存期間を利用規約に定めている。長ければ数ヶ月、短ければ契約終了と同時に即座に削除されるサービスも存在する。行政書士の解説記事でも、データのエクスポートに関する条項が契約に一切ない場合、データ取り出しのためだけに追加費用が発生するケースがあると指摘されている。つまり「後でゆっくり考えよう」という先延ばしは、選べる選択肢そのものを失うリスクを伴う。
先代が契約したSaaSにまつわる承継特有の事情
承継直後の社長が抱える悩みは、通常のシステム移行とは少し性質が異なる。先代が契約の経緯や設定の意図を残していないことが多く、なぜこのSaaSを選んだのか、どの項目が業務上重要なのかを、契約情報だけから読み取ることができない。
- 先代が個人のメールアドレスで契約者登録していて、ログイン権限の引き継ぎ自体に時間がかかる
- 契約書や見積書が紙のファイルにしか残っておらず、解約条件（違約金や通知期限）が不明
- 古参の事務担当者が「昔からこのシステムでやっている」という理由だけで使い続けており、機能的な必要性を誰も説明できない
- 先代自身が「あの会社にはお世話になったから」という人間関係を理由に解約を渋る
このうち技術的に対処できるのは前半2つだが、後半2つは社内のコミュニケーションの問題になる。古参社員が長年触ってきたシステムを「使えなくなる」ことへの不安は、機能の話ではなく仕事の型が変わることへの不安であることが多い。データ移行の話を進める際は、古参社員に「データは全部残るし、むしろ今よりExcelで確認しやすくなる」と具体的に伝えることが、抵抗を減らす一番の近道になる。
解約前にやるべきこと（1）全項目のCSVエクスポートを今すぐ実行する
最初にやるべきことは驚くほど地味だ。管理画面にログインし、エクスポート機能を探し、表示されているすべてのデータ種別についてCSVを書き出す。顧客マスタ、取引履歴、在庫、勤怠、請求書データなど、思いつく項目をすべて対象にする。
ここで注意したいのは、多くのSaaSでは「直近1年分のみ表示」のようにデフォルトの表示期間が絞られていることだ。エクスポート前に、期間フィルタや表示件数の上限を必ず確認し、可能な限り全期間・全件を対象にする設定に変更してから書き出す。年度をまたいで複数回に分けてエクスポートする必要がある場合もある。
エクスポートしたファイルは、解約作業を始める前に、社内の共有ドライブと外部ストレージの2箇所以上に保存しておく。1箇所に置いたまま安心してしまい、後日そのフォルダを誤って削除してしまったという事故も実際に起きている。
解約前にやるべきこと（2）文字コードと日付形式を目視で確認する
CSVを書き出しただけでは仕事は終わらない。次にやるべきは、そのファイルをExcelやテキストエディタで実際に開き、内容が正しく表示されているかを目視で確認する作業だ。
CSVは、テキストの中身そのものに文字コードの情報を持たないファイル形式である。そのため、書き出した側がUTF-8で保存していても、開く側のアプリケーションが違う文字コードだと判断して開くと、取引先名や住所が意味不明な記号の並びに変わって表示される。これがいわゆる文字化けの正体だ。特にExcelはCSVを開く際にShift_JISとして解釈しようとする挙動が知られており、SaaS側がUTF-8で書き出す設定になっていると、そのままダブルクリックしただけでは文字化けする。
対処法としては、ファイルを直接ダブルクリックせず、Excelの「データ」タブから「テキストまたはCSVから」を選び、インポート時に文字コードを明示的に指定する方法が確実だ。UTF-8のBOM付きで書き出せるSaaSであれば、Excelでもそのまま正しく開ける場合が多い。
日付列にも同様の注意が必要だ。CSVの日付が「2026/03/15」のような文字列ではなく「45732」のような5桁の数字として表示された場合、それはExcelが日付をシリアル値として内部管理しているために起きる表示だ。セルの書式を「日付」に変更すれば元の日付に戻せるが、そのまま新システムに取り込んでしまうと、日付のズレたデータが本番環境に登録される事故につながる。
「気づいたのは新システムに取込んだ後、注文日が全部1900年代になっていたときでした」というのは、担当者が日付シリアル値のまま気づかずインポートしてしまった典型的な失敗パターンだ。取込み前の目視確認さえしていれば防げていた。
解約前にやるべきこと（3）新システムに入れる前に一度Excelで整形する
3つ目にやるべきことは、CSVを新しいシステムに直接流し込むのではなく、一度Excelなどの表計算ソフトで整形するワンクッションを挟むことだ。これは急いでいるときほど省略したくなる工程だが、省略すると必ず後で余計な手間がかかる。
具体的には以下のような整形作業が必要になる。
| チェック項目 | 内容 | やらないとどうなるか |
|---|---|---|
| 表記ゆれの統一 | 「株式会社」と「(株)」、全角・半角のスペースなど | 新システムで同じ取引先が別々に登録され重複データになる |
| 空白セルの扱い | 空欄を「未入力」か「0」か「対象外」かで統一 | 集計や検索の際に想定外の件数が出る |
| 不要な列・行の削除 | SaaS側の内部管理用ID列やテスト用データの行 | 新システムの取込エラーの原因になる |
| 項目名（列名）の対応付け | 旧SaaSの項目名と新システムの項目名が一致しない | 取込時にどの列が何のデータか分からなくなる |
この作業はデータクレンジングと呼ばれる工程にあたる。件数が数百件程度であれば手作業でも対応できるが、数千件を超える場合は、Excelの関数（重複チェックや文字列置換）を使って効率化するか、簡単な変換処理をマクロで組んでおくと作業時間を大きく圧縮できる。マクロに詳しい社員が社内にいない場合は、この整形作業だけを外部のシステム会社に切り出して依頼することも検討したい。全部を丸投げするより、要件を絞った小さな依頼の方が費用も抑えやすい。
「解約=悪」ではない。惰性契約を見直す好機でもある
ここまで解約のリスクを中心に説明してきたが、誤解しないでほしいのは、先代SaaSの解約自体が悪いことだと言っているわけではない点だ。承継は、先代の代に積み重なった惰性の契約を見直す、数年に一度しかない絶好の機会でもある。誰も使っていない機能に月額料金を払い続けていたり、似た機能のツールが複数残っていたりする状態は、多くの中小企業で見かける。
大切なのは「勢いで解約して後悔する」のではなく「データをきちんと確保した上で、必要な解約は迷わず進める」という順序を守ることだ。解約自体を怖がって先代の代の契約をそのまま引き継ぎ続けるのも、コスト面では望ましくない。データの安全確保と、契約の見直しは、両立させるべき別々の作業だと考えたほうが整理しやすい。
見積書・契約書のPDFも一緒に確保しておく
CSVでの業務データのエクスポートに気を取られていると、見積書や契約書といったPDF形式の書類の確保を忘れがちだ。SaaS内で発行した請求書や納品書のPDFは、税務上の保存義務がある書類も含まれるため、業務データと同じタイミングで一括ダウンロードしておく必要がある。
多くのSaaSでは、個別のPDFを1件ずつダウンロードする機能に加えて、期間を指定して一括でZIP形式にまとめてダウンロードできる機能を備えている場合がある。もしこの一括ダウンロード機能が見当たらない場合は、サポート窓口に「解約前に全期間分の請求書・納品書をまとめて取得したい」と伝え、対応可能か確認しておきたい。税務調査の際に過去の書類が必要になった場合、SaaS側のアカウントが既に解約済みで参照できないという事態は避けなければならない。
エクスポートできる項目とできない項目を切り分ける
先代SaaSのエクスポート機能は、想像以上に「一部の項目しか出せない」ことが多い。特に以下のようなデータは、標準のCSVエクスポートの対象外になっているケースが目立つ。
- 添付ファイル（見積書PDF、契約書スキャンなど）
- 承認フローの履歴やコメントのやり取り
- 権限設定やワークフローのカスタム設定そのもの
- 自動計算されているフィールド（値ではなく数式やロジック）
これらのデータが業務上どうしても必要な場合は、解約前にサポート窓口へ個別に問い合わせ、CSV以外の形式（PDF一括ダウンロードやAPI経由での取得）で入手できないか確認する。API連携に対応したSaaSであれば、CSVより情報の欠落が少ない形でデータを取得できることもあるが、API経由の抽出には社内にある程度の技術知識が必要になるため、対応できる人員がいなければ早い段階で外部に相談したほうが結果的に早い。
解約通知のタイミングとデータ保存期間の確認
もう一つ見落とされがちなのが、解約通知を出すタイミングとデータの保存期間の関係だ。多くのSaaSは「解約希望日の1ヶ月前までに通知」といった規定を設けており、この通知期限を過ぎると自動更新されて、望まない期間分の料金が発生してしまう。
一方で、通知を出してから実際にサービスが利用できなくなるまでの間に、データを再確認できる期間が設けられていることも多い。この期間を「移行のための最終チェック期間」として意識的に使うのがよい。解約通知を出した直後に安心してデータ確認を後回しにしてしまい、利用停止日を過ぎてからログインできないことに気づく、という失敗は避けたい。
契約終了後もある程度の期間はデータが保管され、移行のために必要な期間はサービス事業者に引き続き保管してもらうことが望ましいとされている。この考え方に基づけば、解約通知を出す前に、利用規約の「データ保存期間」「エクスポート可否」の条項を必ず読み返しておくべきだ。紙の契約書が見当たらない場合は、ベンダーのサポート窓口に直接問い合わせて確認するのが確実だ。
先代の代からの契約書・見積書が見つからないときの対応
承継直後によくあるのが、先代SaaSの契約書そのものが見つからないという状況だ。先代が個人のメールで契約していたり、紙の契約書がキャビネットの奥に紐綴じで保管されているだけだったりする。この場合、以下の順番で確認するのが効率的だ。
- 会社の銀行口座やクレジットカードの利用明細から、毎月・毎年の定額決済を探し、契約中のSaaSを洗い出す
- 洗い出したSaaSのログイン画面から「パスワードを忘れた場合」を選び、登録メールアドレスを確認する（先代の個人メールが使われていることが多い）
- ベンダーのサポート窓口に電話し、契約者名と会社名を伝えて契約状況を確認してもらう
- 契約内容が確認できたら、解約条件（通知期限、違約金、データ保存期間）を書面かメールで再確認してもらう
この一連の作業は地味で時間がかかるが、株式や不動産の名義変更と同じように「先代の代の契約を、承継した自分の名前に一度きちんと引き継ぐ」という意味を持つ。ここを飛ばして解約だけ進めると、契約者本人の同意が確認できないという理由で解約自体が受け付けられない、という手続き上のトラブルにもつながる。
新システムへの取込作業で起きやすい3つの事故
CSVの整形が終わり、いよいよ新システムへ取り込む段階になっても、まだ気を抜けない工程が残っている。実際の現場でよく起きる事故を3つ紹介する。
1つ目は文字数制限による切り捨てだ。 旧SaaSでは自由記述で長文のメモを残せていたのに、新システムのある項目には文字数上限が設定されていて、取込時に後半部分が黙って削られてしまうことがある。取込直後に必ず件数だけでなく、内容の長さも数件サンプルで確認したい。
2つ目は重複登録だ。 同じ取引先データが、表記ゆれ（前述の「株式会社」表記など）によって別レコードとして重複登録されてしまう。新システム側に重複チェック機能があっても、表記が違えば検知できないことが多い。
3つ目はマスタの対応関係の崩れだ。 例えば旧SaaSで「取引先ID:105」が新システムでは自動的に別の番号に振り直され、その番号を参照している注文データや請求データとの紐付けが切れてしまうケースがある。取込作業の前に、旧IDと新IDの対応表を残しておくと、後からトラブルが起きた際にも原因を追跡しやすい。
小さくテストしてから本番データを流し込む
整形したCSVをいきなり全件、新システムの本番環境に取り込むのは避けたい。まずはテスト用の環境やお試し用のアカウントがあれば、そこに一部のデータ（数十件程度）だけを取り込んで、表示や検索、集計が想定通りに動くかを確認する。
テスト環境がない場合でも、本番環境の中に「テスト用」であることが分かるダミーの取引先名などを使って少量のデータを取り込み、正しく反映されることを確認したうえで削除し、その後に本番データ一式を流し込むという手順を踏むと安全性が上がる。この一手間を惜しんで全件を一度に取り込み、エラーに気づかず数日運用してから間違いが発覚すると、修正の手間は最初の何倍にも膨らむ。
承継後にありがちな「システムが複数ある」問題への向き合い方
先代の代に、必要に応じてその都度SaaSを追加契約していった結果、似たような機能のツールが複数残っているという会社は多い。例えば顧客管理ツールが2つ、勤怠管理ツールが2つ、という状態だ。この場合、どちらを残すかを決める前提として、両方のデータをまず統合的にCSVで書き出しておくことをおすすめする。
どちらを残すか決めてから片方だけエクスポートしようとすると、意思決定に時間がかかっている間に、使わなくなった側のSaaSがいつの間にか解約期限を過ぎてしまうリスクがある。両方のデータを先に確保しておけば、意思決定を急がず、落ち着いて比較検討できる。
古参社員の協力を得るための伝え方
データ移行の作業そのものは社長一人でも進められる場合があるが、実際にどの項目が業務上重要かを一番よく知っているのは、日々そのシステムを使っている古参の事務担当者だ。「このシステムは解約する」という決定だけを一方的に伝えると、長年使い慣れた仕事の型を奪われるという受け止め方をされ、協力を得にくくなる。
代わりに、以下のような伝え方を心がけたい。
- 「データは全部残す。むしろExcelで見やすくして残す」と最初に伝える
- 「今使っている項目のうち、どれが一番大事か教えてほしい」と質問形式で聞く
- 解約日ではなく「データ確認が終わる予定日」を先に共有し、逆算して解約日を決める
古参社員が「自分の知っている情報が失われない」と実感できれば、システムの切り替え自体への抵抗は大きく減る。これは技術の話ではなく、承継後の人間関係づくりの一部だと捉えたほうがうまくいく。
費用をかけずに自分でできる範囲と、専門家に頼むべき範囲
ここまで紹介した作業の大半は、Excelの基本操作ができれば社長自身や事務担当者だけで対応できる。CSVエクスポート、文字コードの確認、表記ゆれの手直しといった作業に、外部への発注は必須ではない。
一方で、以下のような状況になったら、無理に自力で完結させず外部に相談したほうが結果的に安く済む。
- データの件数が数万件を超え、Excelでの手作業では時間がかかりすぎる
- 複数のSaaSに分散したデータを、項目単位で突き合わせて統合する必要がある
- 旧SaaSのエクスポート機能自体が壊れていて、CSVが正しく書き出せない
- 新システム側の取込フォーマットが特殊で、変換ロジックを組む必要がある
このあたりの作業は、Power Automateのような自動化ツールや、簡単なスクリプトを使えば数時間の手作業を数分に短縮できることも多い。ただし導入・設定にはある程度の技術知識が必要になるため、社内に対応できる人がいない場合は、必要な作業だけを切り出して外部のシステム会社やフリーランスのエンジニアに見積もりを取るのがよい。丸ごと移行を任せるのではなく「整形だけ」「変換スクリプトだけ」と工程を絞って依頼すれば、費用も見積もりやすくなる。
複数人での確認体制をつくる ― 社長一人で抱え込まない
承継直後の社長は、株式の名義変更、金融機関との面談、取引先への挨拶回りなど、やるべきことが同時多発的に押し寄せてくる時期にある。その中でシステムのデータ移行という地味な作業を、社長一人で最初から最後まで抱え込もうとすると、どこかで確認漏れが発生しやすくなる。
理想的には、CSVの書き出しとエクスポート作業を経理や総務の担当者に、文字化けや日付形式の目視確認を別の担当者に、それぞれ役割を分けて依頼したい。二人以上の目で確認する体制を作るだけで、単純な見落としのリスクは大きく下がる。もし社内に手を動かせる人員が足りない場合は、この工程だけを期間限定でアルバイトや派遣に依頼する、あるいは前述のように外部のシステム会社に整形作業だけを切り出して依頼するという選択肢もある。社長がすべてを自分の手で完結させる必要はない。大事なのは、誰が何を確認したかを後から追える状態にしておくことだ。
移行後1ヶ月は旧システムの情報を捨てずに残しておく
新システムへの移行が完了し、業務が問題なく回り始めたとしても、旧SaaSからエクスポートした元のCSVファイルや、ダウンロードしたPDF書類はすぐに削除しないでほしい。新システムへの取込作業でどれだけ丁寧に確認したつもりでも、実際に日々の業務で使い始めてから「あの取引先の過去の注文履歴が見当たらない」といった小さな見落としに気づくことは珍しくない。
目安として、移行後最低1ヶ月、できれば四半期の締め作業を一度経験するまでの期間は、エクスポートした元データをそのまま保管しておくことをおすすめする。この期間を過ぎて業務上の支障がないことを確認できてから、初めて元データの整理や削除を検討すればよい。焦って早々に元データを消してしまい、後になって「やはり必要だった」と気づいても、その時点では旧SaaSのアカウント自体が解約済みで、二度と取り戻せないという事態になりかねない。
解約前の最終チェックリスト
ここまでの内容を、解約ボタンを押す直前に確認するチェックリストとしてまとめる。
- [ ] 全データ種別（顧客・取引・在庫・勤怠など）をCSVで書き出したか
- [ ] 表示期間・件数のフィルタを外し、全期間・全件を対象にエクスポートしたか
- [ ] 書き出したCSVを2箇所以上（社内共有ドライブ＋外部ストレージ）に保存したか
- [ ] Excelで開いて文字化けがないか目視確認したか
- [ ] 日付列がシリアル値になっていないか確認したか
- [ ] 添付ファイルや承認履歴など、CSVに出せない項目の扱いをベンダーに確認したか
- [ ] 利用規約の解約通知期限とデータ保存期間を確認したか
- [ ] 契約者情報（メールアドレス・契約者名）が先代のままになっていないか確認したか
- [ ] 新システムへの取込前に、表記ゆれや重複を整形したか
- [ ] 少量のテストデータで取込を試し、表示・検索が正しく動くか確認したか
このリストを全部埋めるまで、解約通知は出さない。それだけのルールを自分に課すだけで、データ消失事故のほとんどは防げる。
ノーコード・ローコードで乗り換え先を選ぶという発想
先代SaaSを解約した後、次のシステムをどう選ぶかという話にも触れておきたい。承継直後は「先代と同じような業務システムを、また誰かに開発してもらう」という発想になりがちだが、最近はノーコード・ローコードのツールを使えば、専門のエンジニアを雇わなくても、社内の担当者が画面上の設定だけで簡易な業務システムを組み立てられるようになっている。
移行先を選ぶ際は、旧SaaSからのCSV取込に対応しているかどうかを必ず確認したい。せっかく丁寧に整形したCSVがあっても、取込機能自体が用意されていないシステムを選んでしまうと、結局は一件ずつ手入力するという事態になりかねない。契約前の比較検討の段階で、ベンダーに「CSVインポートのサンプルフォーマット」を見せてもらい、自社のデータ項目とどこまで対応するかを事前にすり合わせておくと、取込作業そのものがスムーズになる。
データ移行のスケジュールは「解約通知の1ヶ月前」から逆算する
これまでの内容を実務のスケジュールに落とし込むと、次のような順序になる。まず解約を検討し始めた段階で、利用規約の解約通知期限を確認する。多くのSaaSでは「解約希望日の1ヶ月前までに通知」といった規定になっているため、この1ヶ月という期間を、単なる事務手続きの猶予ではなく「データ移行の作業期間」として意識的に使うことがポイントだ。
具体的には、通知を出す前の2週間でCSVエクスポートと目視確認を終わらせ、通知を出した後の残り2週間で新システムへのテスト取込と古参社員への説明を行う、というように前後に分けて計画すると、慌てて作業する場面を減らせる。承継直後は他にも決めるべきことが山積みで、システムの解約は後回しにされがちだが、後回しにした分だけ移行の準備期間が圧縮されるという点は意識しておきたい。
紙の台帳との併用期間をどう設計するか
先代の代からの業務が、実はSaaSと紙の台帳の併用で成り立っていたというケースも珍しくない。SaaSにはすべてのデータが入っているとは限らず、一部の情報は紙のノートや個人のExcelファイルにしか残っていないことがある。この場合、CSVエクスポートだけでは全体像が見えないため、解約前に「そもそも先代の業務は何を根拠に動いていたか」を古参社員に聞き取っておく作業が欠かせない。
聞き取りの際は、「このシステムのこの項目は何のために使っていましたか」という具体的な質問から始めると、思い出話ではなく実務の情報として引き出しやすい。紙の台帳の情報もあわせてCSV化しておけば、新システムに移行した後も、先代の代の業務の流れを一つのデータとして参照できるようになる。
移行作業を後回しにした場合に起きる典型的な結末
最後に、ここまでの作業を「忙しいから後で」と後回しにした場合、実際にどうなるかを整理しておく。よくある結末は次の3パターンだ。
- 解約通知だけ先に出してしまい、データ確認をする前にサービスが停止し、必要な過去の取引履歴が二度と取り出せなくなる
- データはエクスポートしたが文字化けや日付のズレに気づかず新システムに取り込み、数ヶ月分の請求データが誤った状態で運用され続ける
- 古参社員への説明を後回しにした結果、システム移行への反発が強まり、結局は旧システムと新システムを並行運用する期間が想定より長引く
いずれのパターンも、事前に少しの時間を割いていれば防げた話ばかりだ。承継直後は目の前の業務を回すことに追われがちだが、システムの解約という一度きりの意思決定については、焦らず段取りを踏むことが、結果的に最短距離になる。
まとめ ― データは「先代からの申し送り」でもある
先代SaaSに残されたデータは、単なる業務記録ではない。取引先とどういう経緯で付き合いを始めたか、どの時期にどんな注文が多かったか、先代がどんな判断基準で仕事を進めてきたかという、いわば経営の履歴書でもある。解約という一つの決断の裏には、そうした記録を次にどう活かすかという、もう一段深い問いが隠れている。
CSVという一見無機質なファイル形式は、その申し送りを次の経営に引き継ぐための、いまのところ最も確実な手段だ。文字化けや日付のズレといった細かいトラブルに一つずつ向き合う作業は地味だが、それを乗り越えた先には、先代の代からのデータを土台にしながら、自分の代のやり方で経営を組み立てていく余地が広がっている。焦って解約ボタンを押す前に、まずはCSVを一枚、丁寧に開いてみることから始めてほしい。
株式や登記の手続きには税理士や司法書士という明確な相談先があるが、システムのデータ移行に関しては、承継した社長自身が最初の判断者になるしかない場面が多い。だからこそ、今回紹介したような小さな確認作業を一つずつ積み重ねていくことが、結果的に会社の記録を守る一番確実な方法になる。データが残っていれば、後からいくらでもやり直せる。データが消えてしまえば、その先にはもう選択肢が残らない。この違いを、解約ボタンを押す前に一度だけ思い出してほしい。
よくある質問
Q. 先代がまだ現役で相談できる場合、解約の判断は先代に確認すべきですか。
A. 判断そのものは承継した現経営者が下すべきだが、「なぜそのSaaSを選んだのか」という経緯だけは先代に一度確認しておくと安全だ。単なる惰性での契約継続なのか、取引先との連携上どうしても必要な機能があっての契約なのかで、解約の優先順位が変わってくる。経緯が分かれば、古参社員への説明もしやすくなる。
Q. 古参の事務担当者がシステムの変更に強く抵抗しています。どう進めればいいですか。
A. 「データは消えない、むしろ見やすくなる」という事実を先に伝え、次に「今の使い方のどこが一番重要か」を聞く姿勢を取ると、抵抗が和らぐことが多い。移行作業そのものに古参社員を関与させ、「自分の知識が新システムに引き継がれた」という実感を持ってもらうことも効果的だ。一方的に解約日だけを通知するやり方は避けたい。
Q. 契約者名義が先代の個人名や旧姓のままになっている場合、解約手続きはできますか。
A. ベンダーによって対応は異なるが、多くの場合はサポート窓口に事業承継の事実（会社の登記情報や代表者変更の書類など）を伝えれば、契約者名義の変更や解約手続きの代行に対応してもらえる。名義変更を後回しにしたまま解約だけ進めようとすると、本人確認が取れないという理由で保留にされることがあるため、早めに問い合わせておきたい。
Q. CSVで書き出したデータに文字化けが直らない場合、どうすればいいですか。
A. Excelでファイルを直接ダブルクリックせず、「データ」タブから「テキストまたはCSVから」を選んでインポートし、文字コードをUTF-8またはShift_JISに指定し直すと解決することが多い。それでも直らない場合は、旧SaaS側のエクスポート設定で文字コードを選べるか確認するか、テキストエディタで文字コードを変換してから開き直す方法を試してほしい。
