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

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

まず大前提を整理します。SAP導入は、新しいITツールを導入して便利にするプロジェクトではありません。

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

「使いやすさ」をKPIに設定してはならない

業務部門は必ず不満を口にします。「今の販売管理システムの画面と同じレイアウトにしてほしい」「入力項目が多すぎる。もっと削れないか」

これに「善処します」と答えた瞬間、プロジェクトの破綻が始まります。 SAPの画面は複雑です。入力項目も膨大です。それは企業全体の会計データと整合性を保つための設計であり、現場の入力負荷の軽減は主眼に置かれていません。

必要な回答は次の通りです。 「SAPの標準プロセスに現場の運用を合わせてください。例外は認められません」

心を鬼にするのではなく、前提となる物理法則が異なる世界へ移行した事実を周知徹底します。使いやすさに固執すればアドオン（追加開発）が際限なく膨張し、数千万円単位の追加費用が発生した末に、バージョンアップすらままならない負債が残ります。

成功基準の再定義が必要です。 × 「現場が満足するシステムを作る」 ○ 「現場から不満が出ても、業務を止めずに稼働し続けるシステムを作る」

Fit to Standard戦争：アドオン開発の罠

SAP導入の原則に “Fit to Standard”（業務を標準に合わせる） があります。しかし、これを現場で貫徹できる企業は少数です。日本固有の商習慣が障壁となります。

「請求書は締日ではなく、取引先の検収ベースで出力したい」
「端数処理はこの取引先のみ切り上げにしたい」
「赤伝・黒伝で伝票の修正履歴を残したい」

これらをSAP標準の設定値だけで満たすのは困難です。そこでSIerが囁きます。「アドオンプログラムを個別開発すれば対応可能です（1本数百万円〜）」

ベンダーの「対応可能」は「追加課金」を意味する

アドオン開発は導入ベンダーにとって最大の収益源です。当然、開発を前提とした提案が先行します。

アドオンは一度認めると歯止めが利きません。「あの部署の要望が通ったならこちらも」と現場の要求が連鎖します。アドオンだらけになったSAP環境は、マイナーバージョンアップのたびに膨大な回帰テスト費用を伴い、将来にわたって保守費用を吸い上げ続けます。

対抗策：業務部門へコストと責任を突きつける

アドオン要求を退ける最も確実な手法は、コストの可視化と選択の転嫁です。

「この請求書の宛名調整アドオンを開発すると、初期費用500万円、年間の維持保守費が100万円かかります」「開発を見送った場合、経理担当者が毎月3時間かけて手作業で修正すれば済みます」「500万円の予算があればパート社員を数年雇用できますが、それでもシステム開発を優先しますか？」

その要望に数千万円の投資価値があるのか。数字を突きつけることで、大半の無理な要望は引っ込みます。

ベンダー選定：「御用聞き」を排除せよ

海外本社や親会社の指定ベンダーが存在する場合は選択の余地がありません。しかし、自社でベンダーを選定できる状況にあるなら、「何でも要望を聞いてくれる親切なベンダー」を最優先で排除すべきです。

中小企業のERP導入が頓挫する典型例は、ベンダーが発注側の言う通りに作りすぎることです。業務部門はSAPのアーキテクチャを知りません。素人の要望をそのまま画面へ反映すれば、システムが破綻するのは必然です。

「No」を突きつけられるパートナーの確保

RFP（提案依頼）の段階で次の質問を投げかけます。「当社の現行業務フローの中で、SAPに適合しない部分はどこか。それをどう見直すべきか」

避けるべき回答: 「御社の現在の業務フローを、SAP上で忠実に再現いたします」
信頼できる回答: 「この受発注プロセスは非効率です。SAP標準のフローへ変更しなければ導入は失敗します」

経営陣や現場のやり方に忖度せず、標準化への軌道修正を促せるベンダーを選びます。彼らの存在こそが、後に情シスが社内を説得する際の強力な盾となります。

データ移行という最大の難所

プロジェクトの中盤で最も現場を疲弊させるのがデータ移行です。創業以来、既存システムに蓄積されてきたマスターデータは例外表記の温床です。

住所欄にビル名や注意書きが混在している
電話番号の全角・半角・ハイフンが不統一
法人格の表記が「(株)」「㈱」「株式会社」で重複している
過去10年間取引のない休眠コードが数万件放置されている

SAPのデータ型チェックは厳格です。桁数超過や不正文字はすべてインポートエラーとして弾かれます。この数万件に及ぶエラーリストを誰が修正するのか。

情シスが肩代わりしてはなりません。業務部門の仕事です。

データクレンジングの号令

プロジェクト初期段階で、現場に明確な役割分担を伝達します。「既存のデータは不整合が多いため、そのまま新システムへ移行できません。各部署で1行ずつ確認・修正してください」

現場からは自動変換の要求が出ます。しかし、ここで安易に変換スクリプトを組んで情シスが引き取ると、本稼働後にデータ不整合による業務停止が発生した際、すべての責任を情シスが背負わされます。「自部門のデータ精度は自部門で担保する」。この原則の死守が稼働後の生存に直結します。

プロジェクト体制：情シスはPMを引き受けるな

体制設計における最重要事項です。中小企業でERPを導入する際、経営陣は「ITのプロジェクトだから情シスがPMを務めろ」と指示しがちです。

この要請は全力で回避しなければなりません。

情シスがプロジェクトマネージャーに就任した瞬間、全社に次の誤解が定着します。「これはIT部門の事業であり、自分たちはサービスを受ける側のユーザーだ」

この構図に陥ると、要件定義の会議に主要メンバーが集まらず、受入テストも形骸化し、稼働当日に現場が混乱してプロジェクトが炎上します。

業務部門のエースをPMに据える

ERP導入の本質は業務プロセスの再設計です。 PMに必要な資質は技術力ではなく、営業部門や経理部門の幹部に指示を通せる社内政治力です。

経営陣へ直談判して合意を取り付けます。「本プロジェクトは会社の業務導線を根底から組み替える事業改革です。IT部門の権限では営業や製造の業務フローを変更できません。事業部門のエースをPMに任命してください。情シスは技術支援と事務局としてバックアップに専念します」

事業部門からPMが立つことで、現場は当事者意識を持たざるを得なくなります。情シスは「現場の伴走者」に徹する。これがプロジェクトを完遂させるための絶対条件です。

本稼働初日の覚悟

どれほど入念にリハーサルを重ねても、稼働初日は混乱を避けられません。システムが稼働しても、人間の操作が追いつかないためです。

現場での問い合わせ対応は情シスが担いますが、対外的な遅延の責任まで一人で背負う必要はありません。稼働直後の業務遅延リスクを事前に経営陣と共有し、対外的な説明責任は経営が引き受ける体制を合意しておきます。

生き残ることで得られるもの

SAP導入プロジェクトは、一人情シスのキャリアにおいて屈指の重圧を伴う試練です。利害関係の衝突、終わらない仕様調整、深夜のデータ検証。精神的な消耗戦であることは否定できません。

しかし、この難局を乗り越えてシステムを軌道に乗せることができたなら、会社の資金とモノの流れを全体視点で把握できる希少な人材へと成長します。

単なる「社内ツールの保守担当」から、ビジネスプロセス全体を俯瞰して語れる真のITリーダーへ。心身の健康を最優先に守りつつ、したたかに立ち回ってください。

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

社内交渉を進める際、個人の意見ではなく公的な指針として説得力を持たせるためのリファレンスです。

経済産業省：システム管理基準
- システム投資において経営陣が果たすべきガバナンス責任を定義。PMを業務部門から登用する根拠として活用できます。
経済産業省：DXレポート
- レガシー刷新に伴う過剰なカスタマイズの弊害と、ユーザー企業自身のオーナーシップの重要性を解説。
IPA：情報システム・モデル取引・契約書
- 外部ベンダーとの責任分界点を明確にし、要件定義の不備による費用膨張を防ぐための指針。

目次