SAPが動き出して一年。運用保守費は下がるどころか、消費税率の端数処理を一つ直すだけで数十万円の見積もりが返ってくる。改修を頼むたびに業務要件を一から説明し直し、テスト仕様まで相手任せ。稼働後の運用費が固定費のように居座り、小さな変更すら外注の列に並ぶ――多くの会社が移行の翌年に直面する景色だ。ここで「じゃあ内製化しよう」と全部を自前に引き取ると、今度は誰も手を入れられないシステムを抱え込むことになる。丸投げの逆は、全部内製することではない。 運用費が高止まりする真因は作業の量でなく、業務を技術に翻訳する仕事を毎回ベンダーに渡していることにある。
なぜ運用費は高止まりするのか
原因を「ベンダーが高い」に求めると、相見積もりの話になって終わる。だが本丸はそこではない。小さな変更に大きな金額がつくのは、その変更の意味を毎回ゼロから外部に説明しているからだ。「この費用は当月に寄せたい」「この帳票にこの列を足したい」――業務側の意図を、ベンダーが技術の言葉（どのテーブル、どの設定、どのアドオンに触るか）へ翻訳し、影響範囲を調べ、見積もり、テスト仕様を起こす。この翻訳と調査こそが工数の大半で、実際に手を動かす時間はその一部でしかない。
つまり高止まりの正体は、業務と技術のあいだの翻訳を、丸ごと社外に置いていることだ。翻訳を外に出す限り、変更が小さくても往復のコストは縮まない。ここを社内に取り戻さない内製化は、たいてい「詳しい人を一人採る」で止まり、その人が辞めた瞬間に元へ戻る。
内製で押さえるのは「手」でなく「判断と切り分け」
運用の仕事を、性質でいったん三つに割る。この三層のうち、社内が担うべきは上の二つで、いちばん下は外に残してよい。
- 意思決定：どの変更を、いつ、なぜやるか。業務影響と優先度、他の締め作業との兼ね合いを判断する。事業を知らないと決められないので、外には出せない
- 一次切り分け：不具合や問合せを受けたとき、原因が業務運用か・標準設定か・アドオンかを最初に見立てる。ログとカスタマイズの当たりをつける。ここを社内が持てるかで、外注に流す量が桁で変わる
- 実装：ABAP改修やインフラ作業など、専門性が高く発生頻度の低い作業。これは外に残してよい。無理に抱えると遊休スキルを内部で維持することになり、かえって高くつく
多くの会社が「実装＝手を動かす部分」を内製化のゴールに置いて挫折する。逆だ。頻度が低く専門性の高い実装こそ外注が合理的で、頻度が高く業務知識が要る一次切り分けと意思決定こそ、内に置く価値がある。
内製化は「一気に」でなく「順番に」寄せる
では何から手をつけるか。全社一斉に内製化を宣言しても、知識も体制も追いつかない。順序で寄せる。
順序の要点は、二段目の「一次切り分け」を早く立てることだ。ここが社内にあると、外注へ渡すときの依頼が「調べてほしい」から「ここを直してほしい」に変わる。調査を含む丸投げと、原因を特定した上での実装依頼では、見積もりの前提がまるで違う。どこまで標準に寄せ、どこからアドオンかの線引きは移行時に決まっているはずで、その判断が運用の切り分け精度に直結する（SAPアドオンの要否をFit-to-Standardで判定する手順と3つの判断基準）。
属人依存に振り替えない
内製化の落とし穴は、ベンダー依存を「社内の特定一人への依存」に付け替えて終わることだ。それでは依存先が変わっただけで、その人が抜ければ同じ場所に戻る。防ぐには、設定台帳と変更履歴を検索できる場所に正本一つで持ち、キーユーザーを最低二人に複線化しておく。移行を延命でなく経営管理の高度化に変える設計を描いていたなら（S/4HANA移行を「経営管理高度化」の機会に変える）、その果実を守り続ける局面が、まさにこの運用フェーズにあたる。標準帳票をExcelに落として終わらせないための一手とも地続きだ（SAP移行後もExcelと標準帳票に頼り、データを活かせない原因と最初の一手）。
運用費が下がらないのは、ベンダーが高いからでも社内が非力だからでもない。業務と技術のあいだの翻訳を、丸ごと外に置いているからだ。その翻訳を内に戻す――内製化とは、突き詰めればこの一点である。
