クリーンコアの進め方、アドオンを減らす判断を経理の要件から考える

筆者は、クリーンコアは技術の話として情シスに任せると進みにくいと見ている。会計まわりのアドオンには、帳票の並びを変えたい、承認の経路を足したい、取引先に出す書類の様式を守りたい、といった経理と現場の要望から生まれたものが含まれる。そのアドオンをやめて業務を標準に合わせる決定は、要望を出した業務の側にしかできないと筆者は考えている。経理が担うのは、拡張の作り方の選択よりも、標準に合わせて業務を変える範囲を決めることだと考える。

クリーンコアとは

クリーンコアとは、SAP S/4HANAの標準部分（コア）に手を入れず、会社ごとの拡張を標準から切り離しておく考え方である。SAPの学習教材は、クリーンコアを、最新でクラウドに適合したSAP S/4HANA Cloudを実現するための概念であり進め方でもあると説明している。コアを構成する側面として挙げているのは、プロセス、データ、統合、運用、拡張の5つである。

このうち、アドオンの議論に直接かかわるのは拡張である。同じ教材は、クリーンコアの拡張を「拡張をSAPのアプリケーションから厳密に分離し、定義済みで更新に対して安定したインターフェースだけを通じてSAPのビジネスオブジェクトに触れる方法」とまとめている。拡張がなくなるわけではない、とも書いている。

教材が実践の枠組みとして並べている項目は、次の6つである。

• モディフィケーション（標準プログラムの改変）をゼロにする方針を取る
• 標準と重複する拡張と、SAPのオブジェクトの複製をなくす
• リリース済みのAPIだけを使う
• キーユーザー拡張を最大限に使う
• 規模の大きい拡張は、SAP Business Technology Platform（SAP BTP）のサービスで作る
• SAP Integration Suiteを使う

Fit to Standardとの関係

Fit to Standardは、業務を標準の機能に合わせることを出発点に要件を決める進め方である。クリーンコアが「拡張をどこに、どう置くか」の方針だとすれば、Fit to Standardは「そもそも拡張が要るか」を決める手続きに当たる、と筆者は整理している。

順番としては、Fit to Standardが先になる。標準に合わせられる業務が増えれば、置き場所を考える拡張そのものが減る。アドオンの要否を判定する手順は、SAPアドオンの要否をFit-to-Standardで判定する手順と3つの判断基準で扱った。

なぜ今求められるか

理由は2つある。クラウドで更新の進め方が変わったことと、既存のSAP ERPからの移行の時期である。

1つ目について、SAPの教材は従来の進め方をこう振り返っている。SAP ERPの時代には標準の改変や複製による拡張も選べたが、パッチやアップグレードのたびに念入りなテストが要った。それでも成り立っていた理由の1つは、システムが顧客のデータセンターにあり、保守を顧客自身が行っていたことだという。

クラウドでは前提が変わる。同じ教材は、SAP S/4HANA Cloudでは顧客ごとの更新プロジェクトがなく、ソフトウェアの更新は全顧客に同時に適用されると説明している。更新の頻度と進め方は導入形態によって違う。その違いはRISE with SAPとオンプレ・自社運用の違い、S/4HANAのクラウド移行の選び方にまとめている。

2つ目は時期である。SAPは2020年2月に、SAP Business Suite 7の中核アプリケーションのメインストリームメンテナンスを2027年末まで提供し、その後は任意の延長保守を2030年末まで提供すると発表した。同じ発表で、SAP S/4HANAの保守は2040年末まで約束されている。既存のアドオンを新しい環境に持っていくかどうかを、移行の検討の中で決めることになる。

SAPがクリーンコアの利点として最初に挙げているのは、アップグレードのしやすさである。ほかに、新機能を早く取り込めることと総保有コストが挙がっている。

実現の方法

実現の方法は、標準の拡張機能を使うことと、標準の外側で開発することに分かれる。SAPのガイドは、S/4HANAの中で動かす拡張（オンスタック）と、SAP BTPの上で動かす拡張（サイドバイサイド）を、用途に応じて組み合わせるものとしている。

標準の拡張機能を使う

S/4HANAの中で動かす拡張には、キーユーザー拡張と開発者拡張がある。

キーユーザー拡張は、プログラムの内部を知らない業務側の担当者でも使える道具である。道具として教材が挙げるのは、画面の調整、カスタム項目、カスタムロジック、カスタムのビジネスオブジェクト、カスタムのCDSビュー、分析クエリ、KPI、帳票と電子メールの様式の8つで、どの導入形態でも使え、クリーンコアの進め方と整合すると説明されている。

開発者拡張は、ABAP Cloudという開発モデルで、S/4HANAの中に独自のプログラムを書く方法である。S/4HANAの中に置く拡張の特徴として、ガイドは、標準のデータと独自のデータを同時に更新して整合を保つ必要があること、大量のデータを複雑な条件で読むことなどを挙げる。

外側で開発する

SAP BTPの上で動かす拡張は、APIとイベントでS/4HANAから切り離せる。ガイドが挙げる特徴は、S/4HANAの利用者アカウントを持たない社外の利用者向けであること、切り離せる独立したアプリや業務の手順であること、標準のデータと同時に更新する必要がないこと、などである。

拡張を4段階で評価する

SAPは2025年8月に、従来の3階層のモデルを改め、拡張をAからDの4段階で評価する考え方（クリーンコアレベル）を示した。SAPの教材は、当初のクリーンコアが「クリーンか、そうでないか」の二者択一と受け取られがちだったこと、既存のカスタムコードをすべて捨てることを顧客に期待するのは現実的でないことを、見直しの背景として書いている。

教材によれば、1つの拡張は、その中で使っている技術のうち最も低いレベルで評価される。また、SAP S/4HANA Cloud Private Editionでは、できるだけ高いレベルで拡張することが勧められている。

難しいと言われる理由

クリーンコアが難しいと言われる理由を、筆者は4つに分けて見ている。

1つ目は、既存のアドオンの量である。長く使ったシステムほど、作った理由を説明できる人が社内に残っていないアドオンが増えやすいと筆者は見ている。理由が分からないものは、やめる決定がしにくい。

2つ目は、リリース済みのAPIでは届かない要件があることである。SAPの教材も、レベルAはSAP S/4HANA Cloud Private Editionの全範囲を覆ってはいないと書いている。すべてをレベルAにそろえる前提では、計画を立てにくい。

3つ目は、決める人が定まらないことである。アドオンをやめて業務を標準に合わせるには、帳票を受け取る側や承認する側の同意が要る。情シスは技術的な代案を出せるが、業務を変える決定はできない。

4つ目は、外側に置いても費用は残ることである。SAP BTP上の拡張にも、開発と運用の費用がかかる。拡張を減らす判断と、置き場所を変える判断は、別々に行う。

経理の要件で考える

会計まわりのアドオンは、大きく3つの出どころに分けられる。帳票、仕訳と承認、日本固有の要件である。

帳票

帳票の要望は、「誰が、どの判断に使うか」で仕分ける。社内で数字を確かめるための一覧表は、標準のレポートと分析の機能で出し、並びや見た目は見る側が合わせる。項目の出し入れや様式の調整は、キーユーザー拡張の分析クエリと帳票の様式の道具で足りるかを、プログラムを書く前に確かめる。

それでも足りず、拡張として作る候補になるのは、取引先に渡す書類のうち相手との取り決めで様式が決まっているものや、複数のシステムのデータを合わせて作る資料である。誰も判断に使っていない帳票は、作り直さずに廃止する。帳票の要件を絞る手順は、SAPの帳票・レポート要件を絞る手順、標準で出す・作る・廃止するの3分類で扱った。

仕訳と承認

仕訳を自動で起こす処理や、伝票の承認の経路を足すアドオンは、標準のデータを直接書き換える作りになっていることがある。SAPのテーブルへの直接の書き込みは先の表でレベルDに当たり、移行のときに最初に見直す対象になる。

見直しの順番は、標準の設定で表せるかを先に確かめ、次に、リリース済みの拡張ポイントを使う拡張で受けられるかを見る。承認の段数や金額の区分は、現行の経路をそのまま再現する前に、職務権限の定めに照らして段数を減らせないかを経理と現場で検討する。

日本固有の要件

適格請求書（インボイス）や電子帳簿保存法への対応を「日本固有だから作るしかない」と扱うと、標準で満たせる範囲を確かめる前に開発が決まる。筆者は、先に2つを分けることを勧める。法令が求めていることと、現行の帳票の見た目を守りたいという要望である。前者は標準の機能と設定で満たせるかを、導入する版のSAPの公式資料で確かめる。後者は、帳票の要望として上の仕分けに戻す。仕分けの進め方は、SAPで日本固有の要件をどこまで作り込むか、インボイスと電子帳簿の落とし所にまとめた。

会計まわりの要件と対応方法を、設例として表にした。対応方法は、標準、設定、外側の拡張、廃止の4つに分けている。キーユーザー拡張で足りるものは、プログラムを書かずに済むので設定に含めた。ここでいう外側の拡張は、標準から切り離して置く拡張を指し、S/4HANAの中の開発者拡張とSAP BTP上の拡張の両方を含む。どちらに置くかは、次の節のSTEP 4で決める。

残すアドオンと捨てるアドオンの決め方

既存のアドオンは、次の順に判定する。

STEP 1は、事実で決められる。使用実績から削除の対象を選ぶ手順は、移行時にSAPアドオンを何本捨てられるか、使用実績から削除対象を選ぶ手順で扱った。

STEP 2とSTEP 3が、経理と現場の仕事である。「標準で足りるか」は、機能の有無に加えて、標準の画面と帳票で業務を進めることを使う側が受け入れるかどうかで決まる。「やめられない理由」は、法令、取引先との契約、競争上の違いの3つに限り、「これまでそうしてきた」は理由に数えない。

STEP 4で、残すと決めたアドオンの置き場所を選ぶ。標準のデータと同時に更新する処理はS/4HANAの中に、切り離せる処理はSAP BTPの上に置く。一度にレベルAへそろえられないものは、速やかな是正が勧められているレベルDから先に手当てする。

残したアドオンは、更新のたびに確かめる対象になる。確認の項目を資産として持つ方法は、S/4HANAのアップグレード対応を毎回ゼロから始めない、経理の回帰テストの資産化で扱った。標準に寄せて浮いた費用と時間を経営管理の高度化に使う考え方は、S/4HANA移行は保守切れ対応で終わらせず、経営管理を高度化する機会にできるにまとめている。

よくある質問

クリーンコアとFit to Standardの違いは

Fit to Standardは、業務を標準の機能に合わせることを出発点に、拡張が要るかどうかを決める進め方である。クリーンコアは、標準部分に手を入れず、要ると決めた拡張を標準から切り離して置く方針である。前者で拡張の数を減らし、後者で残った拡張の置き方を決める、という関係になる。

アドオンは全部なくすのか

なくさない。SAPの教材も、拡張がなくなるわけではないと明記している。求められているのは、標準のプログラムを改変しないことと、更新に対して安定した接続点で拡張をつなぐことである。法令や契約で必要な処理は、置き方を選んだうえで残す。

BTPとは

SAP Business Technology Platformの略で、SAPが提供するクラウドの基盤である。S/4HANAの外側で動くアプリケーションの開発と実行、業務の自動化、利用者の作業画面をまとめる機能などのサービスがある。クリーンコアでは、S/4HANAから切り離せる拡張を置く場所として使う。

既存の会社でもできるか

できる。SAPが2025年に示したAからDの4段階の評価は、既存のカスタムコードをすべて捨てることを顧客に期待するのは現実的でない、という認識を背景にしている。現状のアドオンを段階ごとに分け、リスクの最も高いレベルDから手当てしていく進め方が取れる。