前のECCで作り込んだアドオンが、移行の見積もりを倍に膨らませた――そんな経験をした会社は少なくない。作り込みが多いほど、移行時に「このアドオンは新環境で動くか」を一つずつ検証しなければならず、そのテスト工数が費用を押し上げる。この二の舞を避けるための合言葉が「クリーンコア」だ。だが言葉だけが先行し、「アドオンを作るな、ということか」と受け取られがちで、それは半分しか合っていない。クリーンコアはアドオン禁止令ではない。守っているのは、次のアップグレードを安く済ませる権利だ。 ここを取り違えると、必要な拡張まで我慢して業務が回らなくなるか、逆に禁を破ってコアを汚し将来の負債を積む。
クリーンコアが本当に守っているもの
クリーンコアを「標準をきれいに保つ美学」と捉えると、なぜそこまでこだわるのかが腑に落ちない。守っている実体は美意識でなく、将来のアップグレード費用だ。
S/4HANA、とりわけクラウド版は、SAPが年に複数回の標準アップデートを届ける前提で設計されている。ここでコアのプログラムやテーブルに直接手を入れていると、更新が来るたびに「その改修が新バージョンで壊れていないか」を確かめる回帰テストが発生する。改修が積み上がるほどテスト範囲は広がり、更新の負担は雪だるま式に増える。やがて「更新すると自社改修が壊れるから、更新を止める」という判断に傾く。更新を止めた瞬間、そのシステムは再び保守期限に追われる旧世代へと逆戻りする。かつてECCで多くの企業が陥った2027年問題は、まさにこの「追従できなくなる」構造の産物だった（SAP ERP 2027年問題とは｜いつ何を決めるべきか、移行の全体像）。
コアに書くか、外側（BTP）に逃がすか
同じ「請求書に自社ルールのチェックを足したい」でも、それをコアの内側に書くか、外側のBTPに置くかで、将来の運命が分かれる。
要点は、拡張を疎結合にする点にある。コアと拡張を、SAPが正式に公開・保証しているAPI（リリース済みインターフェース）でつなぐ。こうしておけば、コアが更新されても、つなぎ目のAPIが維持される限り拡張側は壊れない。逆に、非公開の内部テーブルを直接読みに行くような結合は、たとえ外側に置いても更新で壊れる。「外に置く」だけでなく「公開された作法でつなぐ」までがセットだ。
全部をBTPに、ではない。三段で住み分ける
もっとも、あらゆる拡張をBTPの開発案件にする必要はない。それはそれで過剰投資になる。拡張の重さに応じて三段に住み分けるのが現実的だ。
- 標準設定で足りるか：まず疑うのはここ。項目の出し入れやワークフローの分岐は、多くが標準の設定（カスタマイジング）の範囲で吸収できる。コードを書かずに済むなら最善
- キーユーザー拡張で足りるか：画面項目の追加、簡単なロジック、帳票の調整などは、SAPが用意した「壊れにくい拡張の枠」（キーユーザー拡張）で対応する。更新に耐える形が保証されている
- 開発者拡張（BTP）に出すか：他システム連携や独自アプリ、複雑なロジックなど上二段で収まらないものだけ、BTP側の本格開発に回す。ここも公開APIでコアと疎結合につなぐ
上から順に検討し、収まらないものだけ下へ落とす。この順序自体が、そもそもアドオンをどこまで作るかというFit-to-Standardの判断と地続きだ（SAPアドオン（追加開発）をどこまで作るか｜Fit-to-Standardの判断基準）。
追従し続けられる体質を、資産として持つ
クリーンコアの本質は、機能を我慢することではない。年に複数回来る標準アップデートに、テスト地獄に陥らず追従し続けられる体質を、システムの資産として持つことだ。標準更新に乗り続ける限り、新機能はコストゼロで手に入り、次の保守期限に追われることもない。移行を延命で終わらせず経営管理の高度化に使う設計とも、同じ思想の上にある（S/4HANA移行を「経営管理高度化」の機会に変える）。拡張したいなら、コアの外で、公開された作法で。守るべきコアと、育てるべき外側を分ける――それがクリーンコアという戦略である。
