導入が荒れるのは、失敗だからではなく、本物だからです
変革プロジェクトの中で、導入フェーズはしばしば誤解されます。
プロジェクトの外から見ると、導入とは「設計どおりにシステムを入れること」に見えます。
画面を作る。設定を入れる。連携する。教育する。リリースする。
そのような順番で、比較的きれいに進むものだと思われがちです。
ですが、実際の導入はもっと泥臭いです。
そして多くの場合、導入が荒れるのは失敗の兆候ではなく、変革が本当に現場に触れ始めた兆候です。
なぜ荒れるのでしょうか。
理由は単純です。
設計図は未来の型を描きますが、導入はその型に現在の会社を押し込む作業だからです。
会社には、これまでの歴史があります。
例外があります。
顧客ごとの事情があります。
部門ごとの暗黙知があります。
マスタの揺れがあります。
古い運用の名残があります。
人によって違う理解があります。
つまり、設計図の世界には最初から存在しない“現実の凹凸”が、導入の瞬間に一斉に噴き出します。
このとき、多くの人は「設計が悪かったのではないか」と考えます。
たしかにそういう場合もあります。
ですが、もっと多いのは、設計そのものよりも、会社の中に残っていた未整理のものが導入で初めて可視化されるケースです。
顧客コードが部門ごとに違う。
案件番号の採番ルールが支店ごとに違う。
古い帳票運用が廃止されたはずなのに、実は現場で生きている。
SaaSは入っているが、最後の確認は人が紙でやっている。
社内ルールは共有フォルダにあるが、最新版がどれか誰も断言できない。
こうしたことは、平時には何とか回ります。
人が間に入って、経験で補い、例外対応で吸収しているからです。
ですが導入では、それができなくなります。
だから、会社は初めて自分たちの曖昧さと向き合わされます。
特に、API連携や生成AIを含む導入では、この問題がより強く出ます。
SaaS単体の導入であれば、最悪、その部門の中だけで何とかすることもできます。
しかし、APIでシステム間をつなぎ、生成AIで問い合わせや文書作成や検索を横断化しようとすると、部門ごとの曖昧さは許されません。
マスタは揃っている必要があります。
用語の意味は一致している必要があります。
ルールの最新版が分かる必要があります。
つまり導入とは、システム設定作業であると同時に、会社の曖昧さを剥がす作業でもあります。
ここで重要なのが、例外処理の扱いです。
多くの会社では、導入の場面で「この例外も残したい」「この顧客だけは特別」「この承認だけは外せない」という話が次々に出てきます。
どれも、理由を聞けば理解できます。
だからこそ危ないです。
理解できる例外を全部救い始めると、設計図はすぐに現行再現へ戻ります。
すると、導入は一見“現場に優しい”ようでいて、結果的には何も減らないまま終わります。
この意味で、導入の勝負どころは、機能を足すことではありません。
どの例外を残し、どの例外を切るかを決めることです。
ここで誤解してはいけないのは、例外を切ることと、現場を無視することは違うという点です。
現場には本当に残すべき例外があります。
法令上必要なもの。
契約上必須のもの。
安全や品質に直結するもの。
それらを標準化の名のもとに乱暴に潰せば、導入は壊れます。
ですが同時に、「昔からそうしている」「特定の人が慣れている」「一部顧客がうるさいから」のような理由で残っている例外もあります。
この二つを区別しないまま“現場事情”でまとめてしまうと、改革は前に進みません。
だから導入では、現場の声を聞くことと、現場のすべてを保存することを分けて考える必要があります。
もう一つ重要なのが、教育の意味です。
導入プロジェクトで教育というと、使い方を教えることだと考えられがちです。
画面の操作方法、入力手順、エラー対応。もちろんそれも必要です。
ですが、本当に難しいのは、なぜこのやり方に変わるのかを理解してもらうことです。
操作方法だけを教えても、人は元のやり方に戻ります。
特に今回のように、SaaS標準に寄せ、APIでつなぎ、生成AIで中間作業を減らす改革では、旧来の“人がつなぐ”感覚そのものを手放してもらわなければなりません。
そのためには、使い方の教育だけでは足りません。
何をやめるのか。
なぜその例外を切るのか。
なぜその承認をなくすのか。
なぜその問い合わせはAIで一次対応するのか。
そこまで含めて初めて教育になります。
ナレッジの問題も同じです。
生成AIを入れると、会社の中にある知識が一気に可視化されます。
それは便利ですが、同時に危険でもあります。
古いルールが残っていれば、AIはそれを拾います。
更新漏れがあれば、もっともらしく間違えます。
属人的な暗黙知が整理されていなければ、AIは“知らない”のではなく、“不完全な答え”を返します。
だからAI導入は、単なる機能追加ではありません。
会社のナレッジを掃除し、言葉を揃え、古い運用を本当に殺す作業でもあります。
ここを甘く見ると、AIは便利な助手ではなく、古い混乱を増幅する装置になります。
導入フェーズで、プロジェクト責任者がよく間違えることがあります。
それは、「全部をきれいにしてから流そう」と思ってしまうことです。
気持ちはよく分かります。
マスタを揃えたい。
例外を整理したい。
全員に納得してもらいたい。
完璧にしてから始めたい。
ですが現実には、そういうプロジェクトほど長引きます。
なぜなら、会社の複雑さは“事前に全部片づけられるもの”ではないからです。
多くの場合、標準を先に流し、そこで見えてきた例外を改めて選別する方が前に進みます。
つまり導入の現場では、完璧さよりも、標準を先に通して戻れない流れを作ることが重要です。
この考え方は、従来の丁寧なプロジェクト運営とは少し違います。
従来は、要件を固め、例外を確認し、できるだけ摩擦を減らしてから導入することが良い進め方とされてきました。
ですが、SaaS標準＋API＋生成AIを前提にした改革では、そこまで全部を救っていたら設計思想が死にます。
だから必要なのは、何を今日流すのか、何を今日は捨てるのかを切り分ける勇気です。
この切り分けがあるからこそ、会社は少しずつでも新しい型へ乗り換えられます。
そして、導入が始まると、小さな成功が持つ意味も変わります。
請求データが人手なしで会計へ流れた。
営業が採算をリアルタイムに見られた。
問い合わせ一次対応の件数が減った。
こうした成果は、見た目には地味です。
ですが本質的には、会社の中で人が配線だった部分が、一枚ずつ剥がれていることを意味します。
ここに導入の面白さがあります。
大きなシステム刷新ではなくても、小さな流れの変化が会社の骨格を変え始めます。
ただし、ここで終わりではありません。
導入できたことと、定着したことは違います。
試験的に通ったことと、日常の業務として根づくことも違います。
むしろ本当の勝負は、その先にあります。
人は元のやり方に戻ろうとします。
Excelに戻ります。
ベテランに口頭確認をしに行きます。
AIの答えを見ながら、結局自分で資料を書き直します。
ここを越えなければ、導入はイベントで終わります。
次の章で扱う定着フェーズは、この“戻ろうとする力”との戦いでもあります。
導入が荒れるのは、変革が本物だからです。
もし何も荒れないなら、それはまだ会社の深いところに触れていない可能性があります。
マスタが揺れ、例外が噴き出し、教育が足りず、感情が動く。
それは面倒ですが、会社が本当に変わるときには避けられません。
大切なのは、その混乱に負けて現行再現へ戻ることではなく、設計思想を持ったまま、どこまで標準を通し切るかです。
会社は、導入された瞬間には変わりません。
少し流れが変わり、人の手でつないでいたものが一つずつ不要になり、その変化が戻らなくなったときに初めて変わり始めます。
導入とは、その最初の流れを通す作業です。
だからこそ、きれいである必要はありません。
必要なのは、会社が少しでも前の型に戻れなくなることです。