第二回では、一枚のリストをお渡ししました。重要なファイル、その担当者、それに依存しているもの、そしてバックアップの有無です。そのリストは何を移すかを教えてくれます。今回は、何をそのまま移してはいけないかをお伝えします。

よくある思い込みは、移行は技術的な一工程にすぎないというものです。ファイルをエクスポートし、新しいシステムにインポートすれば終わり。技術的にはその通りですが、実務上は小さな問題を高くつく問題に変える最短ルートです。スプレッドシートはもともと寛容に作られています。どのセルに何を入力しても受け入れ、その解釈はあなたに任せます。システムはそうではありません。日付は日付であること、数値は数値であること、顧客は一つのレコードを持つ一つのエンティティであることを求めます。そのため、クレンジングしていないデータを移しても混乱は消えません。合わないレポート、顧客にひも付かない請求書、一致しない残高として表に出てきます。そして、多くのプロジェクトを終わらせるあの一言が出ます。新しいシステムは使えない、と。

クレンジングを移行の後ではなく前に行うべき理由

先送りしたくなるのには、もっともな理由があります。クレンジングはどのプレゼンにも出てこない地味な作業ですが、新しいシステムの画面は出てくるからです。そこで、今移して後でクレンジングしようという判断が下されます。しかし、データが入った瞬間から動き始めます。重複した顧客に請求書が発行され、重複した品目に注文がひも付き、不完全な数字の上にレポートが作られます。新しい取引のたびに誤りの上に層が重なり、修正はより難しく、よりリスクの高いものになります。財務取引が動いたレコードを編集することは、ファイルのセルを編集することとはまったく別物だからです。

クレンジングされていないデータは、システムプロジェクトが停滞する原因として一般的に繰り返し現れるものであり、他の原因とあわせてERPプロジェクトが失敗する理由と成功させる方法で解説しています。実務上の結論は、クレンジングはデータが静的なファイルにあるうちが最も安く、稼働中のシステムに入ってからが最も高くつくということです。

ほぼすべてのシートにある五つの欠陥

これらは珍しいエラーではありません。何でも許すツールの自然な結果です。その大半は、あなた自身のファイルにも見つかるはずです。

  • 一つの取引先が複数の名前で存在する。同じ顧客が三回登場します。一度は屋号で、一度はオーナーの名前で、もう一度は急いでいた誰かが入力した略称で。ファイルの中では、誰が読んでも分かる隣り合った行です。システムの中では、それぞれ独自の残高と履歴を持つ三つの別々の顧客になり、取引関係の記録は分断され、三つのどれを見ても全体像は得られません。同じ欠陥は品目や仕入先にも起こります。
  • 日付形式の混在。一つの列の中で、ある日付は日/月、別の日付は月/日、三つ目は休暇明けや月末のようなテキストで書かれています。人間だけが読んでいるうちは通用しますが、その列に基づく並べ替え、期間の計算、時系列のレポートはどれも自信満々に誤った答えを返します。これは目に見えるエラーを返すより危険です。
  • テキストとして保存された数値。セル内に通貨記号付きで入力された金額、同じ欄に単位まで入った数量、先頭に余分な空白がある数字。目には数値に見えても機械にとっては数値ではないため、合計も比較も移行もできません。そして多くの場合、移行後最初の財務レポートで初めて気づきます。
  • 誰も定義できない列。備考、ステータス、一時といった名前の列で、何年も前にすでに終わった目的のために追加され、埋まっていることもあれば空のこともあります。誰も削除する勇気がないため、たいていそのまま移され、定義も担当者もないフィールドとしてシステムに入り、画面に表示され続けてあなたの後任を混乱させます。
  • 意味を持つ色付きセル。リストの中で最も危険なものです。黄色は期限超過、赤は保留、緑は回収済み。これは書式ではなくデータです。ただし、色と、その色を付けた人の記憶の中に保存されたデータです。ファイルをエクスポートすると、テキストは移っても色は落ち、毎日の事業運営に使っていた情報を、何の警告もないまま失うことになります。

唯一のルール：セルの外にある意味はすべてフィールドにする

今回の内容から一文だけ覚えておくなら、これにしてください。色や行の位置、誰かの頭の中に保持されている意味はすべて、移す前に明文化された列にしなければなりません。テストは単純で容赦がありません。ファイルを書式なしのプレーンテキストにエクスポートし、どの情報が失われたかを確認します。このテストで消えるものこそ、今フィールドにしなければならないものです。

変換そのものは技術的な作業ではなく、定義の作業です。ステータス列を作るだけでは足りません。許容される値を確定し、重なり合う値を整理する必要があります。保留とキャンセルは一つの状態ですか、それとも二つですか。レコードは正確にどの時点で期限超過になりますか。これらはプログラミングではなく会社の仕組みに関する問いであり、オーナーがクレンジングの段階から得る最も価値のあるものです。一度明確に答えておけば、これまで毎回口頭で決着をつけていた議論が終わるからです。

Origamiの見解

私たちはサウジアラビアの企業向けにシステムを構築するテクノロジー企業であり、クレンジングの段階をその前の事務作業ではなく、システム設計の一部として扱っています。データの欠陥はどれも、書かれていない業務ルールを浮き彫りにするからです。重複した顧客は取引先について合意された識別子が存在しないことを示し、色付きセルは誰も正式に認めたことのない実際の業務状態を示します。こうした発見は正しい設計の原材料です。だからこそ私たちは、それをインポートツールに流し込むのではなく、お客様と一緒に読み解きます。

私たちが勧める順序は、まず定義を統一することです。誰を一人の顧客とみなすか、何を一つの品目とみなすか、各判断フィールドでどの値を許容するか。その後で、移行は繰り返し実行でき、検証できるクリーンな作業になります。そこがシステム構築における私たちのサービスの出発点であり、店舗からシステムへで取り上げた実例から読み取ったのと同じ考え方です。整った業務と場当たり的な業務を分けるのはインターフェースではなく、その下にあるデータの規律なのです。

クレンジングの実践的な順序

すべてのファイルを完全にクレンジングするのは終わりのないプロジェクトです。数日のうちに移せるものが手に入る順序で進めてください。

  • 取引ではなくマスターデータから始める。顧客、品目、仕入先は繰り返し使われる短いリストであり、これらをクレンジングすれば、後からひも付く何千行ものデータが自動的に正されます。請求書と注文はその後です。
  • エンティティごとに一つの識別子を採用する。決して変わらず、決して再利用されない固定のコードまたは番号を決め、古い名前や略称をすべてそれに対応付けます。特に顧客については、正確な法定の買い手情報は些細なことではありません。ザカート・税関総局（ZATCA）の電子インボイス要件が、税務請求書に記載すべき内容を定めているからです。入出庫とその請求書のつながりについては、工場と倉庫における電子インボイスで解説しています。
  • 複合セルはすべて分割する。数量と単位は別々の列に、金額と通貨も別々に、氏名と携帯電話番号も別々にします。ルールは、一つの欄に一つの情報です。
  • インポートの前に形式を統一する。ファイル全体で一つの日付形式、セル内に記号を含まない数値、携帯電話番号の統一形式。作業は単調で退屈ですが、一度で済みます。
  • クレンジングの判断を別シートに記録する。何を何に統合したか、何を削除したか、何が疑わしいまま残っているか。二か月後に誰かがある顧客はどこへ行ったのかと尋ねたとき、そのシートが答えになります。それがなければ、チームは移行全体への信頼を失います。
  • 元のファイルを削除しない。クレンジング前のファイルを、閉じた読み取り専用のコピーとして保管してください。クレンジングには判断が伴い、判断には立ち返るための基準が必要です。

そして、完璧なデータがそろうまで移行を待たないでください。そんな日は決して来ません。必要なきれいさとは、重要なフィールドが正確で一貫して定義されていること、そして不完全なまま残るものが後から想定外として見つかるのではなく、把握され記録されていることです。

今後の回では

データは移せる状態になりました。残るのは、移行期間中に業務が続くか止まるかを決める問いです。何を最初に移すのか。次回は移行の順序、マスターデータが常に取引より先である理由、そして終了日を開いたままにせず明示したうえでの並行稼働の進め方を取り上げます。その後、権限と誰が何を見られるか、次にこれまで手作業で作っていたレポートを扱い、移行後の最初の三十日間でシリーズを締めくくります。

出典