kintoneに移行する前に整理しておきたい先代データの項目

先代が20年、30年と積み上げてきた顧客リストや受発注の記録を、そのままkintoneに移そうとして手が止まった。そんな経営者は少なくありません（そもそも今の台帳が「重くて開けない」状態なら、先代の台帳が「重くて開けない」を放置するとどうなるかも参照してほしい）。「とりあえずExcelのデータを全部インポートすればいい」と思って作業を始めたら、得意先名の表記が担当者ごとにバラバラだったり、退職した社員の名前が今も担当欄に残っていたり、先代しか意味を知らない謎の記号列が列一面に埋まっていたりして、結局手が止まる——これは承継直後の会社で驚くほど頻繁に起きています。

結論から言えば、kintoneに移す前に「先代データの棚卸し」を済ませておかないと、移行作業そのものが遅れるだけでなく、間違った情報のまま新システムに乗ってしまい、後から取引先に迷惑をかけたり、社内で二重に管理する状態が続いたりします。この記事では、二代目・三代目としてkintone導入を検討している方に向けて、移行前に必ず確認しておきたいデータ項目を、承継特有の落とし穴も含めて整理します。

こんな状態に心当たりがある方に、特に読んでいただきたい記事です。

• 先代が使っていたExcel台帳を開いたものの、列の意味が半分もわからない
• 「このお客さんはAランク」という基準が、先代の頭の中にしかない
• 退職した社員の名前が担当者欄にずっと残っている
• 社員に「これ何のデータですか」と聞いても「昔からそうなってる」しか返ってこない
• kintoneの導入自体は決めたが、データをどう移すかで作業が止まっている

一つでも当てはまるなら、この記事で紹介する項目を先に潰しておくことで、移行作業の手戻りをかなり減らせます。

先代の代のデータには「なぜこの列があるのか」が誰も答えられない部分がある

先代が現役だった頃のExcel台帳やAccessデータベースには、当時の業務都合で追加された列が必ず存在します。たとえば「A」「B」「C」としか書かれていないランク列、電話でのやり取りをそのまま書き起こしたようなフリーテキストのメモ欄、営業担当だけが読める略称。先代に聞けばすぐわかることも、代替わりした今となっては誰も答えられない「暗号」になっていることがあります。

株式の名義や登記の変更には税理士や司法書士という明確な相談先がいますが、この「データの暗号を解読する」作業には決まった専門家がいません。結果として、二代目社長自身が古いファイルと向き合い、一列ずつ「これは何のための項目か」を判断していくことになります。この地道な作業を移行前に済ませておくかどうかで、kintone導入後の使いやすさが大きく変わります。

さらに厄介なのは、こうした「暗号」が一つのファイルの中に何層にも重なっていることです。表面上は取引先の一覧に見えても、実は隣の列に営業成績の評価が混ざっていたり、さらに別の列には来期の見込み案件がメモされていたりする。先代の頭の中では自然な整理だったのでしょうが、後から見る人間には「なぜこの並び順なのか」がまったく分かりません。だからこそ、移行作業は単純なコピー&ペーストでは終わらず、一種の発掘作業に近いものになります。

なぜkintone移行のタイミングで整理すべきなのか

「とりあえず今のExcelのまま移して、後で直せばいい」と考える方もいますが、これはおすすめできません。理由は単純で、kintoneに一度データが入ってしまうと、社員はそのデータを「正しい情報」として扱い始めるからです。表記ゆれや退職者名が残ったまま社内の共有アプリとして稼働してしまうと、誤った情報が業務の前提として固定化されてしまい、後から直すコストは移行前に直すコストより何倍も大きくなります。

また、kintoneはExcelと違って複数人が同時にアクセスし、通知やワークフローと連動して動くシステムです。Excelの中でひっそり残っていた表記の乱れも、kintoneでは検索結果や集計グラフという「みんなが見る場所」に姿を変えて現れます。乱れたデータのまま移行するということは、乱れを社内全体に公開することに等しいのです。移行前の一手間は、移行後の信頼性を左右する分かれ道だと考えてください。

まず全体像を把握する棚卸しリストを作る

作業に入る前に、社内に散らばっているデータの所在を一枚のリストにまとめましょう。多くの会社では、顧客管理はExcel、受発注は紙の伝票、在庫は担当者の手書きノート、というように管理方法がバラバラになっています。

• どの業務のデータか（顧客・受発注・在庫・請求など）
• 現在どこに保存されているか（Excelファイル名、共有フォルダのパス、紙の保管場所）
• 最終更新日はいつか
• 誰が更新していたか（先代本人か、特定の社員か）
• 更新が止まっているデータかどうか

この棚卸しリストを作る過程で、「実はこの帳簿はもう使われていない」「別の担当者が独自にもっと新しいバージョンを持っている」といった事実が見えてきます。kintoneに移すべきデータは、この棚卸しを終えてから絞り込むのが安全です。

棚卸しの段階では、無理に全部を一度に洗い出そうとせず、まず「業務ごとに1シート」で分けて書き出すことをお勧めします。顧客管理・受発注・在庫・請求・人事という大分類でシートを分け、それぞれのシートに存在するファイルを一つずつ書き足していくと、途中で挫折せずに済みます。承継直後は日々の業務対応にも追われているため、棚卸し作業を一気に終わらせようとせず、1日30分でもよいので継続的に手を入れる方が現実的です。

棚卸しは先代・古参社員へのヒアリングとセットで行う

棚卸しリストを一人で完成させることは、多くの会社では不可能です。データの所在や意味を知っているのは、最終的には先代本人か、その業務を長年任されてきた古参社員だからです。棚卸しの段階から、机上の作業だけでなく「このファイルは今も使っていますか」「この列は何のためにありますか」というヒアリングを組み込んでおくと、後の項目整理がスムーズになります。

ヒアリングの際は、一度にすべてを聞き出そうとせず、業務の区切りごとに短時間で済ませるのがコツです。先代も古参社員も日々の業務がある中での対応になるため、「今週は顧客データについて15分だけ教えてください」というように、負担の少ない形で依頼すると協力を得やすくなります。

項目1：得意先名・仕入先名の表記ゆれ

最初に手をつけるべきは取引先名です。同じ会社が「株式会社山田商店」「(株)山田商店」「ヤマダ商店」のように複数の表記で登録されている状態は、長年運用されてきたExcel台帳では珍しくありません。検索や集計のキーになる得意先名・商品名は、表記ゆれをそのままkintoneに持ち込むと集計が正しくできなくなるため、移行前に統一表記を決めて置換しておく必要があると、kintoneユーザーコミュニティでも実務上の注意点として共有されています。

表記ゆれの洗い出しには、ExcelのピボットテーブルやCOUNTIF関数で「同じ会社なのに件数が分かれている名称」を抽出する方法が効率的です。承継直後は取引先の数が数百社に及ぶ会社も多いため、手作業だけでなくデータクレンジングの考え方を使って優先順位をつけながら進めるとよいでしょう。そもそも台帳をシステム化すべきかどうかの判断ラインについては、同時に開けない先代のExcel台帳、システム化の判断ラインはどこかも参考にしてほしい。

表記ゆれが起きる背景には、入力を担当していた人が複数いたという事情が多くあります。先代が一人で入力していた時代は本人なりのルールが一貫していたのに、事務員や営業担当が交代で入力するようになった時期から、法人格の有無や旧字体・略称の扱いがぶれ始める、というパターンをよく見かけます。誰がいつ入力を始めたかを大まかに把握しておくと、表記ゆれの「境目」を見つけやすくなり、修正作業の見通しも立てやすくなります。

なお、統一表記を決める際は「正式名称（登記上の名称）」を基準にするのが安全です。請求書や契約書に記載されている正式名称と、社内で通称として使われてきた略称が違う場合、kintoneのマスタは正式名称で統一し、略称は検索用のサブフィールドとして別に持たせると、法的な書類とのズレを防ぎながら日常の検索性も確保できます。

項目2：担当者名・社員コードの現在性

先代の代から在籍する古参社員は貴重な戦力ですが、データ上の「担当者」欄には退職済みの社員名がそのまま残っているケースが頻発します。特に定年退職や独立で離れた社員の名前が、取引先レコードの担当者欄に何年も放置されていることがあります。

kintoneでは担当者をユーザー選択フィールドで管理できますが、これは実在するアカウントに紐づく仕組みです。退職者名を新システムにそのまま持ち込むと、通知が飛ばない・権限が正しく設定できないといった不具合の元になります。移行前に「現在も在籍している社員かどうか」を人事側の記録と突き合わせ、退職者は後任者名に付け替えるか、履歴列として別に残すかを決めておきましょう。

この作業には、承継特有の難しさも伴います。退職済みの社員が実は今も個人的に取引先と付き合いを続けている、あるいは独立して同業で仕事をしているような場合、後任者への付け替えを機械的に行うと、取引先側との人間関係の実態とデータがずれてしまうことがあります。特に古参の営業担当が円満退職ではなく独立や引責での退職だった場合、その人物の名前をどう扱うかは社内でも意見が分かれやすい話題です。データ上の処理と、実際の取引先対応との整合性は、事務的な付け替え作業の前に一度確認しておく価値があります。

また、社員コードやID番号についても、退職者の番号を欠番として永久に残すか、新入社員に再利用するかという運用ルールが、先代の時代には明文化されていないことが多いです。kintoneでは社員をマスタアプリとして独立させ、在籍状況を示すフラグを持たせておくと、退職者のデータを消さずに履歴として保持しながら、日常の選択肢からは自然に除外できるようになります。

項目3：ランクや記号による独自の分類ルール

「A」「B」「C」だけの列、「◎」「○」「△」だけの列は、先代の頭の中にだけ基準がある分類です。これは先代の経験に基づく重要な情報である一方、そのままでは新しい社員や外部の専門家が意味を理解できません。

「このお客さんはAランクだから月1回訪問」という運用ルールが先代の頭の中にしかなく、書面化されていなかった——このような話は事業承継の現場でよく聞かれます。

移行前に先代本人、あるいは長年その業務を見てきた古参社員にヒアリングし、ランクの定義を一文でも書き残しておくことを強く勧めます。kintoneのフィールド説明機能を使えば、入力画面にその定義を常に表示させることができ、後任者や新入社員が迷わず運用を引き継げます。

ランクの定義を聞き出す際は、「なぜAランクなのですか」という抽象的な質問より、「このお客さんとあのお客さんはどちらがAランクですか、その違いは何ですか」という具体的な比較で聞く方が、先代の判断基準が言葉になって出てきやすい傾向があります。長年の経験に基づく判断は、本人にとっては当たり前すぎて、抽象的に説明しようとするとむしろ言語化に苦労するものです。実例を挙げながら差分を確認していく方法は、事業承継の技術継承の場面全般で役立つ聞き方です。

また、ランクが売上規模だけで決まっているのか、支払いの確実性や関係の長さなど複数の要素が絡み合って決まっているのかによって、kintoneでの再現方法も変わってきます。複数の要素が絡んでいる場合は、ランクという一つのフィールドにまとめるのではなく、「年間取引額」「支払い実績」「取引年数」のように要素ごとに分けてフィールド化し、ランクはそれらから自動計算する仕組みにしておくと、先代が退いた後も判断基準が属人化せずに残ります。

項目4：日付データの形式と実態

日付列は見た目上きちんと入っているようでも、実際には「文字列として入力された日付」と「シリアル値としての日付」が混在していることがあります。特に長期間運用されてきたExcelファイルでは、途中で入力担当者が変わった箇所から書式が変わっているケースが多く見られます。

日付の乱れはkintoneの日付フィールドに正しく取り込めない典型的な原因です。移行前にExcel上で一度DATEVALUE関数などを使って統一形式に揃えておくと、インポート時のエラーを大幅に減らせます。

もう一つ見落とされがちなのが、和暦表記の扱いです。先代の代の記録には「平成」表記のまま残っている列が多く、これをそのまま文字列として扱うと、西暦データと並べたときに新旧の順序が正しく並ばなくなります。和暦から西暦への変換は一件ずつ手作業で行うと時間がかかるため、変換用の対応表を一度作っておき、関数で機械的に置き換えると効率的です。承継直後で日々の業務にも追われている中では、こうした地味な変換作業を後回しにしたくなりますが、日付が入り口で乱れていると、後工程の集計や履行状況の確認がすべて怪しくなってしまいます。

項目5：金額・単価の単位と税込・税抜の統一

金額データも要注意項目です。ある列は税込、別の列は税抜、さらに古い記録は単位が「千円」表記になっている、といった不統一は、複数の担当者が異なる時期に入力を担ってきた台帳では起こりがちです。基幹システムのデータ移行では、まずマスタデータを正確に整えることが優先順位の最上位に置かれるべきだと指摘されており、金額や単位のような数値の前提をそろえる作業はマスタ整備の中核にあたります。

税込・税抜の混在に気づかず移行すると、kintoneの集計フィールドやグラフ機能で誤った数字が出続けることになります。先代の代の帳簿を確認する際は、決算書や当時の請求書と突き合わせて「この数字は税込だったか」を1件でも検証しておくと、全体の傾向をつかみやすくなります。

税率の変遷も見落としやすいポイントです。消費税率は過去に複数回変更されており、長期間の記録を扱う会社では、ある年より前のデータは旧税率で計算されている可能性があります。単純に全件を現在の税率で再計算し直すと、当時の実際の請求額と食い違ってしまうため、過去のデータはあくまで「その時点の税率で記録された履歴」として保持し、現在の税率を前提にした集計とは分けて扱うのが基本方針になります。

さらに、単価が「1個あたり」なのか「1箱あたり」なのか、単位の基準が先代の時代と現在で変わっている品目がないかも確認しておきたいところです。特に長年扱ってきた商品で、包装形態や取引の最小単位が変わった経緯がある場合、古い記録の単価をそのまま新しいマスタに載せると、実態とかけ離れた金額が表示されてしまいます。

項目6：品目コード・商品名の重複と欠番

長年扱ってきた商品や部材のコードは、途中で命名ルールが変わっていたり、同じ商品に複数のコードが振られていたりすることがあります。特に、先代の代に廃番になった商品のコードが再利用されず欠番のまま残っている、あるいは逆に別の新商品に転用されてしまっている、というのは製造業・小売業でよく見られる現象です。

kintoneに移行する前に、現在も取引のある商品と、すでに廃番になった商品を分けてリスト化しておきましょう。廃番品は「アーカイブ用アプリ」に分離し、現行品だけを日常業務で使うマスタアプリに入れると、日々の入力がすっきりします。

品目コードの整理では、過去の受発注履歴との紐付けにも注意が必要です。廃番になった商品のコードを新商品に転用してしまっていた場合、過去の売上データを商品別に集計すると、廃番品と新商品の実績が混ざって表示されてしまいます。これを防ぐには、過去の履行データについては当時使われていたコードのまま履歴として固定し、現在進行中の受発注からは新しいコード体系に統一するという、時系列で区切った運用ルールを決めておくことが有効です。

また、先代の代には存在したが今は扱っていない商品カテゴリがある場合、そのカテゴリ全体をkintoneに移すかどうかも検討しましょう。将来的に扱いを再開する可能性が低いカテゴリであれば、無理に現行マスタに含めず、参照用のCSVとして別途保管しておく判断も現実的です。

項目7：契約書・見積書などの添付ファイルの紐付け

Excel台帳の中には、「契約書は共有フォルダのどこか」「見積書は担当者のPCの中」といった形で、実データではなくファイルの在り処だけがメモされている列がよくあります。この手のリンクは担当者の異動や退職とともに切れてしまい、承継後に探しても見つからないということが起こります。

kintoneには添付ファイルフィールドがあるため、移行のタイミングで散らばったファイルを一箇所に集約するチャンスでもあります。ただしファイルの量が多い場合は、まず「直近1〜2年分の重要書類」から優先して集約し、古いものは段階的に移す計画を立てるのが現実的です。

ファイルを集約する際は、ファイル名の付け方も見直しておくとよいでしょう。先代の時代のファイルは「見積書.xlsx」「契約書最新版.docx」のように、内容が特定できない名前で保存されていることが多く、これをそのままkintoneに添付しても検索性は上がりません。取引先名と日付を含めたファイル名に統一しながら移す、あるいはkintone側でファイル名とは別に「文書種別」「対象年度」といったフィールドを持たせて管理する方法が有効です。

項目8：先代個人の携帯番号・私的な連絡先が紛れていないか

古い顧客台帳や取引先リストには、会社の代表電話ではなく先代個人の携帯番号がそのまま登録されていることがあります。長年の付き合いの中で「社長に直接電話してもらう」運用が定着していた名残ですが、事業承継後にそのまま公開のkintoneアプリへ移すと、思わぬ形で先代のプライバシーに関わる番号が社内に共有されてしまいます。

移行前にこの手の個人情報が紛れていないかをチェックし、必要であれば会社の代表番号や後継者自身の連絡先に置き換えておきましょう。逆に、先代がまだ相談役として現場に関わる予定がある場合は、どの範囲まで先代の連絡先を残すかを本人と相談して決めておくと、後々の気まずさを避けられます。

似た問題は、社員個人の私用スマートフォンの番号や、家族の緊急連絡先といった人事関連の項目にも起こりえます。承継前は総務担当が一人で紙の名簿を管理していたため厳密な区分がなくても運用できていたものが、kintoneで全社員がアクセスできるアプリに載せた瞬間、閲覧範囲が意図せず広がってしまうことがあります。個人情報に類する項目は、移行の際にアプリごとのアクセス権限を設計し直すタイミングでもあると意識しておきましょう。

項目9：重複レコードの存在

同じ取引先が、部署や担当者が違うだけで別レコードとして重複登録されているケースは非常に多く見られます。特に合併や事業統合の経緯がある会社では、旧システムの名残でひとつの会社が3つ、4つのレコードに分かれて存在していることもあります。

重複の洗い出しには、会社名・電話番号・郵便番号などの複数キーを組み合わせて突き合わせる方法が有効です。件数が多い場合は、CSV形式で一度書き出し、表計算ソフトの重複チェック機能や関数を使って機械的に絞り込むと作業が早く進みます。FAXや手書き台帳からの脱却を並行して進めている場合は、FAX・手書き台帳からの受発注、抜け出すための第一歩のCSV連携の考え方も役立ちます。

重複レコードの統合作業では、どちらのレコードを「正」として残すかの判断も必要です。単純に新しい方を残せばよいとは限らず、古い方のレコードにしか記録されていない取引履歴や担当者情報が残っている場合もあります。統合の際は、消す前に両方の内容を見比べて、必要な情報を残す側にコピーしてから削除する、という手順を徹底しましょう。焦って片方を削除してしまうと、貴重な過去の履行記録が失われてしまいます。

項目10：VBAマクロやリレーションに依存した「隠れた計算ロジック」

先代の代のExcelファイルには、ボタンを押すと自動で集計してくれるマクロや、複数シートを参照して自動計算する数式が組み込まれていることがあります。これは一見便利な仕組みですが、その内部ロジックを理解している人が社内にいない状態で移行を進めると、kintoneに数字だけを移した瞬間にその計算ロジックが失われてしまいます。

VBAマクロで構築された自動集計の仕組みは、ファイルを開いて数式バーやマクロの内容を1つずつ確認しないと、何を計算しているのか分からないことが多いです。移行前に「このシートの数字はどうやって出しているのか」を紙にフローとして書き出しておくと、kintoneのフィールド設計やルールの仕組みに落とし込みやすくなります。

こうした隠れたロジックは、多くの場合、先代が業務改善の一環として自分で少しずつ作り込んできたものです。マクロを組んだ本人がすでに引退している、あるいは外部の詳しい人に頼んで作ってもらったが今は連絡が取れない、というケースも珍しくありません。フローを書き出す作業は根気が必要ですが、これを済ませておくことで、kintoneの計算フィールドやプロセス管理機能に置き換えられる部分と、置き換えが難しく別の方法を検討すべき部分の見分けがつくようになります。

見落としやすい項目：休眠顧客・失注案件のデータ

現在アクティブに動いている取引先だけでなく、過去に取引があったが今は動いていない「休眠顧客」や、商談したものの成約しなかった「失注案件」のデータも、移行の判断が分かれるところです。これらは日常業務では使わないものの、将来的に再度アプローチする際の貴重な記録になります。

すべてを新しいマスタに混在させると現行の取引先が探しにくくなるため、休眠顧客や失注案件は「ステータス」フィールドで区別し、通常の一覧からは絞り込みで除外できるようにしておくと、データを捨てずに済みながら日常業務の見やすさも保てます。

項目11：紙の記録しか残っていない古い履行データ

すべてのデータがデジタル化されているわけではありません。先代の時代の重要な取引履歴が、いまだに紙のノートやファイルにしか残っていない会社もあります。これらをすべてkintoneに入力し直すのは現実的ではないため、「直近数年分だけデジタル化する」「それ以前は紙のまま保管し、必要時に参照する」といった線引きを最初に決めておくことが大切です。

承継特有の視点：先代への配慮とデータ整理の進め方

データの棚卸しを進める中で気をつけたいのは、先代本人への配慮です。長年かけて作り上げてきた管理方法を「非効率だ」「古い」と切り捨てるような伝え方をすると、先代が協力的でなくなってしまうことがあります。データの意味を確認するヒアリングは、あくまで「引き継ぐために教えてほしい」という姿勢で行うのが望ましいでしょう。

また、古参社員が長年その台帳を使い慣れている場合、突然の刷新に不安を感じることもあります。移行作業と並行して、なぜkintoneに移すのか、何が良くなるのかを丁寧に説明する時間を取ることが、結果的にデータ整理そのものの協力を得やすくする近道になります。

移行方法の選択肢を知っておく

データの棚卸しが済んだら、実際の移行手段を検討します。kintone公式のガイドでは、他システムからエクスポートしたファイルをkintoneのアプリに読み込むことで、他システムのデータを移行・反映できるとされています。またレコードの一括登録・一括更新機能を使えば、CSVやExcelファイルから既存アプリへまとめてデータを取り込むことが可能です。

社内に専門のIT担当者がいない会社であっても、ノーコード・ローコードの仕組みを持つkintoneであれば、事前にデータ項目を整えておけば、比較的少ない工数で移行が完了します。逆に、項目の整理を後回しにしたまま一括登録を行うと、エラーの原因を1件ずつ追いかける作業に時間を取られることになるため、順番を間違えないことが肝心です。

移行後に自動化まで見据えておくと二度手間にならない

kintoneへの移行を機に、これまでExcelで手作業で行っていた集計や通知を自動化したいと考える会社も多いはずです。あらかじめ「この作業は将来自動化したい」という項目を意識しながらデータを整理しておくと、後から外部の自動化ツールと連携させる際にも、項目名や形式の食い違いに悩まされずに済みます。

移行のタイミングで一度きれいにしたデータ構造は、その後の業務改善の土台になります。逆に、汚れたデータのまま移行してしまうと、自動化を検討する段になって「そもそも項目がバラバラで自動化できない」という壁に再びぶつかることになります。

移行前チェックリストのまとめ

ここまで挙げてきた項目を、実際に着手する際のチェックリストとして整理します。

• 取引先名・商品名の表記ゆれを統一したか
• 担当者欄に退職済み社員の名前が残っていないか
• ランクや記号による分類の意味を書面化したか
• 日付データの形式が統一されているか
• 金額の税込・税抜、単位が統一されているか
• 廃番品と現行品を分けてリスト化したか
• 添付ファイルの在り処を集約したか
• 先代個人の連絡先が紛れていないか
• 重複レコードを洗い出したか
• マクロや数式に依存した計算ロジックを書き出したか
• 紙しか残っていないデータの扱いを決めたか

このリストを社内で一度確認するだけでも、移行作業の見通しが大きく変わります。

全部を一人で背負わなくていい

先代からの引き継ぎの中で、システムのデータ整理だけは相談先が見えにくい領域です。株式の名義変更なら税理士、登記の変更なら司法書士というように、承継の実務には専門家が用意されていますが、「このExcelの列は何を意味するのか」を一緒に考えてくれる相手は、社内を見渡してもなかなか見つかりません。

だからこそ、まずは自分ひとりで全項目を洗い出そうとせず、古参社員へのヒアリングを軸に進めることをお勧めします。長年現場で台帳を触ってきた社員は、先代が言葉にしていなかった運用ルールを体で覚えていることが多く、二代目社長がゼロから解読するよりもはるかに効率的です。

まとめ

kintoneへの移行は、単なるシステムの入れ替えではなく、先代が積み上げてきたデータの意味を棚卸しし、今の会社に合った形に整え直す機会でもあります。表記ゆれ、退職者の名前、意味不明なランク記号、日付や金額の形式不統一——これらを移行前に一つずつ潰しておくことで、kintone導入後の運用がぐっと楽になります。

最初は地道で骨の折れる作業に見えるかもしれませんが、この棚卸しを終えた先には、先代の時代よりも見通しの良い、次の世代に引き継ぎやすいデータ基盤が待っています。焦らず一歩ずつ、まずは棚卸しリストを作るところから始めてみてください。

よくある質問

Q1. 先代がまだ現役で関わっているのですが、データの整理を進めてよいか判断に迷います。どう進めればいいですか。

先代の協力を得ながら進めるのが最も効率的です。「非効率だから変える」という伝え方ではなく、「引き継ぐために教えてほしい」という姿勢でヒアリングを行うと、先代も協力的になりやすい傾向があります。特にランクや記号による独自の分類は、先代本人にしか意味が分からないことが多いため、対立するのではなく一緒に棚卸しする時間を作ることをお勧めします。

Q2. 古参社員が長年使ってきたExcel台帳を刷新すると、反発されないか心配です。

古参社員の反発を避けるには、いきなり運用を変えるのではなく、まず「今のデータをどう整理すればいいか教えてほしい」と相談する形で関わってもらうのが有効です。台帳の意味やルールを一番知っているのは古参社員自身であることが多いため、移行作業の協力者として位置づけると、抵抗感が薄れやすくなります。

Q3. 取引先名義や契約情報など、名義変更が必要なデータもkintoneに移してよいのでしょうか。

契約上の名義変更が完了していない情報をそのまま新システムの正式なマスタとして扱うと、後で法的な整合性の問題が生じる可能性があります。名義変更の手続き状況が不明な契約や取引先については、司法書士や顧問の税理士に確認したうえで、確定した情報のみをkintoneのマスタに反映することをお勧めします。

Q4. データ整理をする社内の人手が足りません。全部を移行前にやりきる必要がありますか。

すべてを一度に完璧にする必要はありません。まずは日常業務で頻繁に使う顧客・受発注データなど、優先度の高いマスタから整理し、使用頻度の低い古いデータは後回しにする、あるいは紙のまま保管するという判断も現実的です。基幹システムのデータ移行では、マスタデータを正確に整えることが最優先とされているため、限られた人手であれば、まずそこに絞って着手するのが効率的です。

逆にSaaSから別のツールへ乗り換える・解約する場面では、CSVでのデータ移行、先代SaaSを解約する前にやるべきことの手順が役立つ。