「SAP導入」という名の強制労働：外資・親会社命令で死なないための生存戦略

私はこれまで、幾多の中小企業が「身の丈に合わないERP導入」で焦土と化すのを見てきました。本稿では、不可避なSAP導入という災害に見舞われた時、会社とあなたの精神を守り抜くための、綺麗事抜きの「生存戦略」を記します。

1. マインドセット：これは「システム導入」ではない

まず、最大の勘違いを捨ててください。 SAP導入は、新しいITツールを入れて便利にするプロジェクトではありません。

「自社の業務を、SAPという『世界標準の型』に無理やりねじ込む」プロジェクトです。

「使いやすさ」をKPIにするな

現場は必ずこう言います。「今の販売管理システムの、この画面と同じにしてください」「入力項目が多い。もっと減らせないか」

これに「善処します」と答えた瞬間、プロジェクトは死にます。 SAPの画面は使いにくいです。入力項目は多いです。それは「全体最適（会計との整合性）」のために設計されているからであり、現場の「入力の楽さ」など1ミリも考慮されていません。

あなたの返答はこうでなければなりません。「無理です。SAPに合わせてください。嫌なら辞めてください」

心を鬼にするのではありません。物理法則が違う世界に来たのだと認識させるのです。「使いやすさ」を守ろうとすれば、アドオン（追加開発）が膨れ上がり、数億円の追加コストが発生し、それでも現場は満足せず、最終的に「誰も使わない巨大なゴミ」が完成します。

成功の定義を書き換えてください。 × 「現場が喜ぶシステムを作る」 ○ 「現場が文句を言いながらも、止まらずに稼働するシステムを作る」

2. Fit to Standard戦争：アドオンは「麻薬」

SAP導入の格言に “Fit to Standard”（標準に合わせろ）という言葉があります。しかし、これを守れる日本企業は稀です。なぜか？日本の商習慣が「特殊すぎる」からです。

「請求書は締日ではなく、お客様の検収ベースで出してほしい」
「端数処理はこの得意先だけ切り上げで」
「赤伝・黒伝で修正履歴を残したい」

これらをSAP標準でやろうとすると、設定だけでは不可能です。そこでベンダーが囁きます。「アドオンプログラムを書けば実現できますよ（1本300万円〜）」

ベンダーの「できます」は「課金します」の意味

ベンダーにとって自社は「カモ」です。アドオン開発は彼らにとって一番のドル箱です。だから彼らは安易に「できます（開発すれば）」と言います。

アドオンは麻薬です。 1つ認めると、「あれもできるならこれも」と現場の要求が爆発します。そして、アドオンだらけになったSAPは、バージョンアップのたびに動作検証が必要になり、将来にわたって莫大な維持費（保守費）を請求され続けます。

戦い方：業務部門の「人質」を取る

アドオン要求が来た時の撃退法は一つです。コストの可視化と責任の押し付けです。

「この『請求書の宛名調整機能』を作るのに、開発費500万円、毎年の保守費が100万円かかります」「これを導入しなければ、経理担当者が毎月3時間残業して手書き修正することになります」「500万円あれば、パートさんを5年雇えますが、それでもシステム化しますか？」

「その機能に、家一軒分の価値はあるのか？」と突きつけてください。大抵の現場要求は、コストを見せれば引っ込みます。

3. ベンダー選定：「御用聞き」は敵だと思え

外資系本社の指定ベンダー（Big 4など）がいる場合は諦めてください。しかし、日本側でベンダーを選べる場合、「優しくて何でも聞いてくれるベンダー」は最悪です。

中小企業のSAP導入が失敗する最大の要因は、ベンダーが「客の言う通りに作りすぎる」ことです。客（あなたや社長）はSAPの素人です。素人の言う通りに設計すれば、破綻するのは当たり前です。

選ぶべきは「No」と言えるパートナー

コンペ（提案依頼）の際、こう質問してください。「当社の業務フローで、SAPに合わない部分はどこですか？それをどう変えるべきですか？」

ダメなベンダー：「御社の素晴らしい業務プロセスを、SAP上で完全再現します」良いベンダー：「御社のこのプロセスは無駄です。SAP標準のこのやり方に変えないと、導入は失敗します」

社長に恥をかかせてでも、「今のやり方はおかしい」と指摘できるベンダーを選んでください。それは、後であなたが現場と戦う時の、強力な援軍になります。

4. データ移行という「泥沼」

プロジェクト中盤、最も現場が疲弊し、心を折られるのが「データ移行」です。創業以来20年、秘伝のタレのように継ぎ足してきた既存システムのデータ。蓋を開ければ、そこは ゴミの山です。

住所欄に「様方」が入っている。
電話番号に全角と半角が混在している。
得意先名が「(株)」「㈱」「株式会社」で3重登録されている。
使っていない品目コードが3万件ある。

SAPはデータ型に厳格です。郵便番号にハイフンが無ければエラー。住所が長すぎればエラー。この数万件のエラーリスト（移行ログ）を、誰が修正するのか？

あなたではありません。現場です。

「データクレンジング」の号令をかけろ

プロジェクト初期に、現場に伝えてください。「今のデータは汚すぎて新しい城には持ち込めません。あなたたちの手で、1行ずつ綺麗にしてください」

現場は抵抗します。「忙しい」「自動でやってくれ」。しかし、ここで妥協して「変換プログラム」を書くと、本稼働後に必ずデータ不整合で事故が起きます。「自分たちのデータは自分たちが責任を持つ」。この原則を崩すと、稼働後のデータ修正対応で情シスが忙殺され、過労死ラインを超えます。

5. プロジェクト体制：「情シス」はPMをやるな

最後に、最も重要な体制の話です。中小企業でSAPを入れる時、社長は「おい情シス、お前がプロジェクトマネージャー（PM）な」と言います。

全力で逃げてください。

情シス（IT部門）がPMをやると、全社はこう思います。「これはITのプロジェクトだ。俺たち業務部門はお客様だ」

こうなると、要件定義には誰も来ず、テストも適当にやられ、稼働当日に「使い方が分からない」と大騒ぎになります。

「業務部門のエース」をPMに据えろ

SAP導入は業務改革です。 PMに必要なのはIT知識ではなく、「営業部長や経理部長に命令できる政治力」です。

社長に直談判してください。「このプロジェクトは会社の血管を取り替える手術です。私では営業部のやり方を変えられません。次期社長候補の〇〇さんをPMにしてください。私は技術面で彼を支えます」

業務部門からPMが出れば、現場は「自分たちのプロジェクト」と認識せざるを得ません。情シスはあくまで「事務局」兼「技術顧問」に徹する。これが成功（というか生存）の絶対条件です。

6. Xデー（稼働日）の覚悟

どんなに準備しても、稼働初日は地獄です。システムは動いても、人間が動かないからです。

「注文の入れ方が分からない」「ログインできない」「伝票が出ないから、トラックが出発できない！」

怒号が飛び交います。しかし、慌ててはいけません。これは「産みの苦しみ」です。

「謝罪部隊」を用意する

事前に社長と握っておきましょう。「稼働後1週間は、物流が止まる可能性があります。その時は社長、取引先への謝罪をお願いします」

現場でのトラブルシュートは情シスがやりますが、対外的な火消しは経営の仕事です。ここを握っておかないと、全ての責任を情シスが負わされます。

結論：生き残れば、あなたは最強になる

SAP導入プロジェクトは、中小企業の情シスが経験しうるキャリアの中で、最も過酷な試練です。理不尽な要求、終わらない会議、罵声、深夜残業。多くの情シスが、この期間にメンタルを病み、退職します。

しかし、もしあなたがこれを乗り越え、無事に（あるいは多少の傷を負って）システムを稼働させられたなら。あなたは「会社の業務の全て（カネとモノの流れ）」を誰よりも深く理解した人材になります。

それはもはや「パソコンの大先生」ではありません。経営視点で会社を俯瞰できる、真のCIO（最高情報責任者）候補です。

地獄の先には、確かに景色が変わる瞬間があります。その日まで、まずは心と体を守り、したたかに立ち回ってください。健闘を祈ります。

参考資料（公的機関のリソース）

理不尽なプロジェクトを進める際、個人の意見としてではなく「公的な基準」として主張を通すための「武器」です。

経済産業省：システム管理基準
- システム監査の判断基準となる文書。「経営陣がプロジェクトに関与すべき責任」が明記されています。PMを業務部門から出すよう説得する際の根拠になります。
経済産業省：DXレポート（デジタル産業の創出に向けた研究会）
- いわゆる「2025年の崖」レポート。レガシーシステム刷新の難しさや、ユーザー企業が自らオーナーシップを持つ重要性が説かれています。
IPA：情報システム・モデル取引・契約書
- ベンダーとの契約で不利にならないためのモデル契約書。要件定義が未完了のまま開発に入ることのリスクなどが解説されています。

AIに相談するためのプロンプト（テンプレート）

泥沼化するプロジェクトの中で、現状を客観視し、次の一手を打つための「プロジェクト健全性診断」プロンプトです。

あなたは百戦錬磨のERP導入コンサルタント（PMO）です。
現在進行中のSAP導入プロジェクトにおいて、以下の問題が発生しています。
この状況がプロジェクト全体に与えるリスク（遅延、品質、予算）を分析し、私が取るべき具体的なアクション（誰に、何を、どう言うべきか）をアドバイスしてください。

# プロジェクト状況
*   フェーズ: [例:要件定義 / 統合テスト / 受入テスト]
*   稼働予定: [例: 3ヶ月後]
*   現在の課題: [例: 営業部が「現行のこの機能がないと仕事にならない」と言い張り、アドオン開発を強く要求している]
*   ベンダーの反応: [例: 「追加費用を払えば作ります」と言っており、止める気がない]
*   経営層の態度: [例: 「現場が言うなら仕方ないか」と日和っている]

# 出力してほしい内容
1.  **リスク診断 **: このままその要求を飲むと、稼働時や保守フェーズでどのような地獄が待っているか。
2.  **キラーフレーズ **: 現場や経営層を黙らせるための、論理的かつ冷徹な説得文句。
3.  **代替案 **: アドオンを作らずに、運用運用（BPR）で回避するためのアイデア。

目次