SAP移行の現場で、最後まで揉めて、いちばん金を溶かすのが「アドオン（標準にない機能を追加開発すること、いわゆるZプログラム）をどこまで作るか」だ。営業も経理も「今のやり方を変えたくない」と言う。情シスは「標準に寄せたい」と言う。両者を足して2で割ると、移行は終わった瞬間に保守地獄の入り口になる。CFOzine編集部は、この線引きを精神論ではなく、3つの軸を通す決定木で機械的にさばく方法を提示する。判断を属人化させない、それがアドオンを資産にするか負債にするかの分かれ目だ。
なぜ今「作り込み」が経営の負債になるのか
まず時間軸をはっきりさせておく。SAP ERP 6.0の最後の3つの拡張パッケージ（EHP6/7/8）の標準保守は2027年末で切れる。延長保守は保守料に2%上乗せで2030年末まで。それ以前のEHPはすでに2025年末で標準保守が終わっている。一方、移行先のS/4HANAは2040年末まで「常に保守対象のリリースが存在する」とSAPが約束している。つまり多くの日本企業にとって、ここ数年が事実上の移行の山場であり、その移行のたびに過去のアドオンが全部点検対象になる。
ここで効いてくる数字がある。移行プロジェクトでよく引かれる調査では、企業が抱えるカスタムコードのうちS/4HANAへ持ち越されるのはおおむね4割程度とされる。裏を返せば、過去に作り込んだものの半分以上は「使われていない／標準で置き換わった／誰も理由を説明できない」状態で死蔵されている、ということだ。
アドオンが負債である理由は、作るときの開発費ではない。本当のコストは、作った後ずっと続く。バージョンアップのたびに動作確認と改修が要る。標準のバグ修正パッチ（SAPノート）を当てるたびに、自社コードと衝突しないか検証が要る。作った担当者が辞めれば、仕様は誰の頭にも残らない。SAPが推す「クリーンコア」（標準の中核に手を入れず、拡張は外側に逃がす設計思想）が世界的に強調されているのは、まさにこの保守コストを移行のたびに払い続ける構造を断ち切るためだ。
3つの軸で切る ── アドオン判定の決定木
では具体的にどう線を引くか。CFOzine編集部が推すのは、すべてのアドオン要望を次の3つの問いに順番に通す方法だ。順番が大事で、上から落としていく。
第1の問い：その業務は本当に「自社固有」か（業務固有性）
ここでいう固有性とは「他社と違うから競争力になる」業務かどうか、だ。受注の特殊なルール、自社製品ならではの原価の積み方、規制業種ならではの統制──これらは固有性が高い。一方、「請求書の体裁」「承認の回し方」「帳票の見た目」は、たいてい固有ではなく単なる慣れだ。ここを混同すると、ただの惰性を「うちは特殊だから」と正当化してアドオンが膨らむ。固有性が低いなら、それ以上下の問いに進む必要はない。標準に寄せる、で終わりだ。
第2の問い：標準機能で代替できないか（標準代替可能性）
固有性が高いと判定されても、すぐ作ってはいけない。S/4HANAは旧ECCより標準でカバーできる範囲がかなり広がっている。さらに、SAPが用意した「正規の拡張口」を使えば、コードを書かずに足りる場合が多い。代表的なのが、現場の管理者がノーコード／ローコードで項目追加や画面調整をする「キーユーザー拡張（アプリ内拡張）」と、SAP本体には触れず外側のプラットフォーム（SAP BTP）に別アプリとして機能を載せる「サイドバイサイド拡張」だ。この2つで賄えるなら、それは伝統的なアドオン（Zコードを本体に埋め込む作り込み）ではなく、移行を妨げない「行儀のいい拡張」になる。ここを尽くさずにいきなりZプログラムを書くのが、最も多い失敗だ。
第3の問い：作るとして、保守コストに見合うか（保守コスト対効果）
固有性が高く、標準でも正規の拡張口でも無理。ここまで来て初めて、伝統的なアドオンを作る検討に入る。ただし最後の関門として、保守コストを必ず見積もる。年1〜2回のバージョンアップ対応工数、SAPノート適用時の検証、仕様書とテストケースの維持、属人化を防ぐ引き継ぎ。これらを年額に均して、その機能が生む価値と並べる。割に合わなければ、業務側に手作業や運用回避を飲んでもらう。「作らない」という判断を、誰かが責任を持って下す。この最後の覚悟がないと、決定木は形だけになる。
この3軸を1枚の流れ図にして、要望を出す業務部門・作る開発側・止める情シスの三者が同じ紙を見て会話する。判定根拠を1行で記録に残す。これだけで「声の大きい人が勝つ」構造が消える。
「作る」と決めた後 ── 負債化させない置き場所
ここからが移行後を左右する実務の核心だ。同じ機能でも、どこに置くかで将来の保守コストが何倍も変わる。クリーンコアの考え方では、拡張は中核から遠いほど安全とされ、おおまかに次の優先順位で置き場所を選ぶ。
第1優先は、設定（カスタマイジング）で済ませること。これはコードですらないので最も安全だ。第2は、前述のキーユーザー拡張（アプリ内のノーコード拡張）。第3は、SAP BTP上のサイドバイサイド拡張で、本体のバージョンアップから切り離せる。そして最後の手段が、本体に直接コードを埋め込む従来型アドオンだ。同じ「項目を1つ足す」でも、本体改造で実装するのと正規の拡張口を使うのとでは、次の移行時に片方は数時間、もう片方は数日の検証地獄になる。
加えて、決めた基準は移行の瞬間だけでなく、運用に組み込む。新規のアドオン要望が来るたびに同じ決定木を通すルールにし、年1回は既存アドオンの棚卸しをして「もう標準で代替できるようになったもの」「使われていないもの」を退役させる。アドオンは作った瞬間から腐り始める前提で、退役の仕組みまで設計して初めて、移行は一度きりの大手術ではなく、続けられる運用になる。
最後に、CFOの立場で握っておくべき一点を言い切る。アドオンの可否は、突き詰めれば「この作り込みの保守費を、この先10年払い続けるか」という投資判断だ。それは現場の好みで決めていい話ではなく、経営が線を引く話だ。決定木はその線を、誰が見ても同じ場所に引くための道具にすぎない。道具を渡したうえで、「作らない」と言い切る責任だけは、CFOが引き受けるしかない。
- アドオンの真のコストは開発費でなく、移行のたびに払い続ける保守費。持ち越せるカスタムコードは約4割。
- 要望は「①業務固有性→②標準代替可能性→③保守コスト対効果」の決定木に上から通し、根拠を1行で記録する。
- 作る場合も置き場所を「設定→キーユーザー拡張→サイドバイサイド拡張→従来型アドオン」の順で選び、中核から遠ざける。
- 年1回の棚卸しと退役まで設計し、運用に組み込む。「作らない」と言い切る責任はCFOが負う。
