移行後の最初の三十日間：何が崩れるのか

第六回ではレポートを扱いました。二日がかりで組み立てるファイルではなく、今この瞬間を開いて見るビューへと変わる過程です。これで、六回にわたって描いてきた全体像がそろいました。スプレッドシートが答えでなくなるのはいつか、実際に会社を動かしているのはどのファイルか、移す前のデータクリーニング、移行の順番、誰が何を見るのか、そして手作りのレポートの終わりです。

残っているのは、そのすべてが報われるかどうかを決める部分、つまり本番稼働の最初の一か月です。そして、こうしたプロジェクトを手がけたことのある人なら誰もが知っていることがあります。移行の多くは構築中には失敗しません。失敗するのは使い始めて最初の数週間です。システムは動き、データはそろい、画面も正しいのに、実際の仕事は静かに古いファイルへと戻っていきます。今回は、なぜそうなるのか、そしてそれを防ぐ計画について取り上げます。

抵抗は頑固さではなく、リスクの計算である

一週目にまず直面するのは、チームのためらいです。よくある間違いは、経営者がそのためらいを変化への抵抗や怠慢と受け止め、圧力で応じることです。たいていは、そのどちらでもありません。

以前はファイルを開いて二分で仕事を終えていた社員が、同じ画面の手順を覚えるのに今は十分かかります。本人の立場から見れば、話には聞いているもののまだ目に見えない利益のために、今日のコストを払っていることになります。しかも本人が上司に責任を負っているのは今日の成果であって、プロジェクトの成功ではありません。このためらいは完全に合理的なのです。

古いファイルの持ち主が、そのファイルを知っていることで社内での立場を築いてきた人である場合、ためらいはさらに強まります。あるファイルについて唯一の頼れる存在だった人は、システムによって自分の役割が不要になることを恐れるかもしれません。その恐れを無視しても消えはせず、表に出なくなるだけです。正面から向き合う方がうまくいきます。その人に、新しい体制の中で自分の担当分野のデータ品質の責任者という明示的な役割を与えれば、ファイルの番人からデータそのものの拠り所へと立場が変わります。

最初の一か月に起こる本当の変化は、仕事が見えるようになることです。データがファイルの中にあった頃は、入力の遅れは目に見えませんでした。システムでは、誰がいつ何を記録したかが記録に残ります。これは一貫して仕事をしている人には安心材料であり、融通の利くやり方に慣れた人には居心地の悪いものです。二週間後に気づかれるより、最初の会議で率直に伝えておく方がよいでしょう。

古いファイルへの静かな逆戻り

最初の一か月で最も危険なことは、騒がしく起こるわけではありません。会議でシステムに反対する人はいないのに、古いファイルのコピーが誰かのパソコンで開いたままになり、その方が速いからとそこに記録し、週末にまとめてシステムに入力するつもりでいます。たいていの場合、入力はされません。

その結果、考えうる最悪の状態が生まれます。信頼できる情報源が一つではなく二つになるのです。プロジェクトの前には、不正確ではあっても全員が拠り所と認める一つのファイルがありました。今は不完全なシステムと不完全なファイルがあり、どちらが新しいのか誰にもわかりません。出発点よりも悪い状況であり、これはERPプロジェクトが失敗する理由と、成功させる方法で取り上げたパターンの一つです。

探せば、兆候は早い段階で現れます。会議で引用された数字がシステムに存在しない、稼働から二週間たってもチームのチャットでファイルが共有されている、社員がデータをエクスポートして外で作業したいと言い、そのまま戻してこない、といったことです。どれについても、本人を責める形で対処してはいけません。問うべきことは一つだけです。システムにはなくて、ファイルが与えていたものは何か。答えは通常、欠けている手順、ない項目、あるいは必要以上に長い手順であり、わかってしまえばどれも数日で直せます。

移行前ではなく、移行後に表面化する抜け

第三回で述べたように、事前にどれだけ丁寧にデータをクリーニングしても、最初の実際の取引でしか見つからない抜けは必ず出てきます。理屈は単純です。ファイルは空欄を許していたので、空のセルは空のまま残り、請求書の発行を妨げるものは何もありませんでした。システムがその項目を求めるのは、後の工程がそれに依存しているからです。

この段階でよく出てくるのは次のようなものです。

• 不完全な取引先の記録。名前だけで登録されている顧客で、税番号も住所も記録された連絡先もなく、それらはすべて必要なときに口頭で確認していたもの。
• 突き合わせても合わない期首残高。顧客や品目の期首の数字が古いファイルの記載と一致せず、その差が最初の取引明細書で表面化する。
• 一度も分類されたことのない状態。保留中の注文、一部入金、処理が終わっていない返品。ファイルでは余白のメモにすぎなかったものが、システムでは定義された状態を必要とする。
• 複数の単位と価格。ケース単位で販売し個数単位で仕入れる品目や、顧客の階層ごとに異なる価格。そのすべてが書き留められず、営業責任者の頭の中にある。
• 裏づけとなるルールのない例外。何年も特別条件で取引している顧客なのに文書がなく、システムでどう定義すればよいのか、誰に承認の権限があるのか誰にもわからない。

これらはどれも、移行が失敗した証拠ではありません。むしろ移行がもたらす最初の本当の利点です。ファイルが隠していたものを、システムが明らかにしたのです。ただし、その対処には規律が必要です。すべての項目を明示された一つのリストに記録し、答えを出す担当者と完了日を決めてください。一件ずつ個別の会話で処理していると、翌月には別の形でまた戻ってきます。

一度きりの研修では足りない

うまくいっていないプロジェクトで最も繰り返されるパターンは、研修が稼働初日の一回のセッションとして行われ、全員が出席し、システム全体を端から端まで説明するというものです。その後、全員が自席に戻ると内容の大半を忘れています。必要になる前に聞いたからです。

うまくいく代わりの方法は、三つの原則に基づいています。

• システムではなく役割を教える。経理担当者に倉庫の画面は要りませんし、営業責任者に権限設定は要りません。各チームは毎日歩く手順を学びます。そのほうが短く、はるかに焦点が絞られます。
• 一週間使ってから繰り返す。本当に効果を発揮するのは二回目のセッションです。そこで出る質問は仮定の話ではなく、日々の業務から生まれた本物の質問だからです。そして、複数のチームで繰り返し出る質問は、どの画面がわかりにくいのかを正確に教えてくれます。
• 文章ではなく画像で記録する。役割ごとに一ページ、手順を順番に並べてスクリーンショットを添え、掲示するか配布します。稼働後の質問の大半は、理解の問題ではなく思い出すための質問です。

また、各チームの中に、まず最初に質問される人が一人必要です。社員はサポートチケットを出す前に同僚に聞くからです。この非公式な役割は、どんな外部のサポート窓口よりも対応時間を短くします。こうしたチェンジマネジメントはスプレッドシートからの移行に限ったものではなく、ERPを成功裏に導入する方法の中で導入フェーズの一部として取り上げました。

Origami の視点

私たちは稼働初日を、プロジェクトの終わりではなく折り返し地点として扱います。システムは動いているだけでは会社に根づきません。根づくのは、その日の仕事を終わらせる最短の道になったときです。古い手順が新しい手順より速いままの一日一日が、プロジェクトに静かに逆らって働く一日なのです。

そのため最初の一か月は、完了日つきの指摘事項を明示したリストで管理し、印象ではなく実際の利用状況を測ります。誰がログインしているか、どの取引が発生した時点で記録されているか、どの画面で人がつまずいているか。これは、私たちのサービスの一環としてカスタムシステムを構築する際に実践していることです。小さなつまずきを最初の週に直せば一時間で済みますが、二か月後に直そうとすればチーム全体の信頼を失うことになるからです。

三十日間の計画

これは書かれたとおりに実行できる計画であり、最も重要な特徴は、どの段階にも明示された終わりがあることです。

• 1〜7日目：期限つきの並行運用。システムと古いファイルの両方に記録しますが、その理由は比較のためだけです。週の終わりに小さなサンプルを取り、二つの数字を比べ、すべての差異を大きさではなく原因ごとに記録します。
• 8日目：古いファイルを読み取り専用にする。これが計画の中で最も重要な一歩です。ファイルは閲覧できる状態のまま、誰も書き込みません。明示された終了日がなければ並行運用はいつまでも続き、楽だという理由で必ず古いファイルの勝ちに終わります。
• 8〜14日目：二回目の研修と抜けの解消。実際に出た質問を扱うチームごとの短いセッションを行い、抜けのリストの上位五項目を解消します。
• 15〜21日目：利用状況を測る。誰が実際にシステムを使っていて誰が使っていないかを確認し、遅れて記録された取引があれば一件ごとに理由を尋ねます。そこからわかるのは個人の規律ではなく、手順がどれだけわかりやすいかを示すシグナルです。
• 22〜30日目：安定化と振り返り。残りの指摘事項を解消し、システムだけで最初の月次レポートを作成し、チームリーダーと三十分ほど話し合って、まだシステムの外で行われていることは何か、それはなぜかを洗い出します。

成功の正直な尺度は、アンケートでのチームの満足度でも、使われている画面の数でもありません。それはただ一つの瞬間です。誰かが、言われたわけでもないのに古いファイルを開かなくなること。その時点で、システムはもはやあなたが管理するプロジェクトではなく、会社の仕事の進め方そのものになっています。

シリーズを締めくくって

七回にわたって、私たちは道のりの全体を歩いてきました。スプレッドシートが限界を超えたことを示す兆候、どのファイルが本当のシステムなのかを教えてくれる棚卸し、データのクリーニング、移行の順番、権限の設定、手作りのレポートを生きたビューに変えること、そして最後に、最初の一か月を乗り切ることです。

覚えておく価値のある結論はこうです。Excelは優れたツールであり、問題はツールではなく、それに背負わせていたものでした。システムへの移行は技術的なアップグレードというより、会社のデータはファイルや個人ではなく会社のものだという決断です。そしてそれは、小さな一歩から始まります。今日あなたの会社を動かしているファイルを開き、誰がいつ更新しているのか、その人が不在だったら何が起こるのかを問いかけてみてください。

参考資料

• サウジデータ・人工知能庁（SDAIA） — 個人データ保護法（PDPL）と、新しいシステムへ移行したデータに対する義務。
• ザカート・税・関税庁（ZATCA） — 電子インボイスの要件と、書類の保存および要求に応じた提出。
• 人的資源・社会開発省 — 従業員の記録とそのデータの保存に関する規定。
• 商務省 — 事業所の商業帳簿と記録に関する規定。
• 中小企業総局（Monsha'at） — 事業所が経営管理やデジタルトランスフォーメーションのツールを導入できるよう支援するプログラム。