導入したのに使われない

並行稼働を「3か月」で決めると、旧システムは止まりません

公開 2026年9月1日

新システムの稼働に合わせて、旧システムは「3か月だけ並行稼働」と決まります。この決定に反対する人はいません。

3か月後に来るのは、停止の連絡ではなく延長の相談です。

移行が終わっていないからではありません。止める条件を、最初に誰も書いていないからです。

「3か月」は期間であって、条件ではない

並行稼働の計画に書いてあるのは、たいてい日付だけです。何が起きたら止めるのかは書かれていません。

だから3か月後の会議で、判断材料が出てきません。「まだ不安なので、もう少し」に反論できないのは当然で、不安が根拠のないものかどうかを測る設計になっていないからです。

延長は、一度通ると二度目が通ります。半年も経つと、旧システムは「止めるもの」ではなく「あるもの」に変わります。議題から静かに消えます。

困るのは、旧システムが残っていること自体ではありません。同じ案件が2か所にあり、どちらが正なのかを誰も宣言していないことです。月末に数字が合わない。合わせるために、両方を見て突き合わせる人が生まれる。その人の工数は、二重入力よりも高くつきます。

現場が旧システムに戻るのは、抵抗ではなく、両方が許可されているから

HubSpot Japanの「日本の営業に関する意識・実態調査2026」（2026年2月27日公表、調査委託先マクロミル、実施2025年10月30〜31日、売り手n=1,545、従業員51〜5,000名。CRMを販売する企業の自社調査です）に、この構造がそのまま出ている数字があります。

生成AIについて、会社の後押しが「使ってよい」という許可だけの場合、週1回以上使う人は47.2%でした。研修や勉強会まで実施すると56.9%。業務プロセスへの組み込み、つまりCRM連携や共有プロンプトの整備まで進めると74.8%です。

これは生成AIの調査であって、システム移行の調査ではありません。ただ、許可と研修では半分強までしか動かず、業務に組み込んで初めて7割を超えるという段差は、並行稼働の現場で見えるものとよく重なります。

並行稼働とは、定義上「新しい方を使ってよい」という状態です。期限付きで、許可の段階に留まる設計になっています。

ハンモックの調査（2021年9〜10月、n=305、従業員300名以上の経営者・役員が対象。ベンダーの自社調査で、時期も古いため傾向として読んでください）では、SFAが使われない理由の1位は「使いこなすのに時間がかかる」52.3%でした。旧システムなら3分で終わる更新が、新システムでは15分かかる。稼働直後は、ほぼ必ずこの状態を通ります。

つまり並行稼働は、新システムがいちばん使いにくい時期に、旧システムを使う選択肢を公式に用意している状態です。現場は怠けているのではなく、合理的に選んでいます。

止める順番は、システムではなく「その数字を使う会議」から決める

やり方は単純で、期間の代わりに出口条件を1つ書きます。

「月次の営業会議の資料が、新システムのレポートだけで作れる状態になったら止める」。日付ではなく、状態で書いてください。

そのうえで、会議のほうを先に変えます。資料の作り方を新システムのレポートに固定し、旧システムから作った表は受け付けない。この瞬間に、新システムは許可された選択肢から、業務の前提に変わります。

次が停止の順序です。旧システムは、削除ではなく書き込み停止から入ります。読み取りは残す。安心のために残しておきたいのは履歴であって、更新機能ではありません。この2つを分けると、止める判断が一段軽くなります。

最後に、参照が止まったのを確認してから閉じます。アクセスログで月あたりの参照回数を数え、ゼロが2か月続いたところでデータを書き出す。ここまで来れば、停止は判断ではなく事務手続きです。

稼働日にいきなり全部止める案も検討する価値はあります。実際、旧システムが単純な台帳なら通ります。ただし旧システムにしかない項目が1つでも業務に効いていると、その日に業務が止まります。並行稼働そのものが悪いのではありません。終わり方を書かずに始めることが問題です。

並行稼働は期間ではなく出口条件で終わらせてください。旧システムを止める日は、その数字を新しい経路からしか作れない会議を1つ作った日に決まります。

よくあるつまずき

延長するかどうかを、期限当日の会議で議論する。 その場では情緒で決まります。冷静に出口条件を書けるのは、並行稼働を始める前だけです
旧システムにしかない項目を、移行の終盤に見つける。 並行稼働が終わらない原因の多くはこれです。開始前に旧システムの項目を1つずつ「新システムのどこに入るか」で仕分けてください。入らない項目が業務に効いているなら、移行漏れではなく設計の宿題です
「使わないでください」と通達すれば使われなくなると考える。 使える状態を残したままの禁止は、守る人と守らない人を作るだけです。止めるのは通達ではなく設定です