Fit&Gapの結果、標準では埋まらない業務が十九件残った。ベンダーからアドオン開発の見積りが出てくる。合計2,800万円。会議は、作るか作らないかの議論になる。 作らないなら業務を変える、作るなら金を出す。この二択で決めた案件は、たいてい三年後にもう一度議題に上がる。 バージョンアップの見積りに、作った十九件の改修費が乗ってくるからである。そして二択で議論している間、三つ目の選択肢は一度も比較表に載っていない。

POINT
作る／作らないの二択が粗いことは、ベンダー側の目盛りを見ると分かる。SAPは、拡張がどれだけ「きれい」かを四段階に分けている。 従来の三層モデルから移行した現在の区分では、Level Aが、安定した公開インタフェースを使う拡張 で、ABAP CloudでERPの中に作るか、SAP BTP上に切り離して作るかのいずれかであり、SAPは公式に、Level Aの要件を 「公開され安定したSAPのインタフェース。正式な安定性の契約に裏づけられたもの」 と説明している。Level Bは、SAPの従来型のAPIと技術を使うもの で、SAPはこれを 「よく定義され、文書化され、おおむねアップグレード安定なインタフェース」 とする。Level Cは、内部オブジェクトに依存するもの で、過渡的には許容されうるが長期的には将来性がないと位置づけられる。Level Dは、推奨されないオブジェクトを使うもので、最もリスクが高く技術的負債になる。 そしてSAPは、side-by-sideの拡張を 「コアから独立して動く、スケール可能で疎結合なアプリケーションを作ること」 、on-stackの拡張を 「ERPの中に密に統合された、アップグレード安定な拡張」 と説明している。注目すべきは、この四段階が「作った量」ではなく「何に依存して作ったか」で切られていることである。 同じ機能を実現しても、Level AとLevel Dでは五年後のコストがまったく違う。社内の会議で使われている二択には、この目盛りが一つも入っていない。

落ちている三つ目は、他社製パッケージである

十九件の穴を埋める方法は、実際には三つある。標準機能で運用を変えて吸収する。他社製のパッケージや外部サービスを繋いで埋める。自社で開発する。 このうち二つ目が、比較表から消えやすい。

消える理由ははっきりしている。Fit&Gapの実施主体が、ERPの導入ベンダーだからである。 ベンダーにとって、標準で吸収するか自社で開発を受注するかは自然な二択だが、他社製パッケージを勧める動機はない。連携の責任分界が増え、障害切り分けが面倒になる。悪意ではなく、立場の問題である。

しかし経費精算、請求書受領、電子帳簿保存、債権の入金消込、経営レポーティング、稟議・ワークフロー。この領域は、ERPの外に専用のサービスがある。 そして専用サービス側は、法改正への追随を自社の商品価値として更新し続けている。インボイス制度、電子帳簿保存法、消費税率、社会保険の料率。自社で作れば、この追随を毎回自社の費用で行うことになる。 逆に、原価計算のロジック、価格決定、独自の販売条件、業界固有の受注形態のように、自社の商売そのものを表現している部分は、外部サービスに存在しない。 ここが自社開発の本来の対象である。

三択で並べると、判断の質問が変わる。「作るべきか」ではなく、「この十九件のうち、どれが自社の商売そのもので、どれが世の中の共通業務か」になる。 共通業務に見えるのに自社仕様が入っているものは、その自社仕様のほうを疑う（SAPアドオンの要否をFit-to-Standardで判定する手順と3つの判断基準）。

初期費用で並べた比較表は、自社開発に傾きやすい

三択を並べても、比較の軸が初期費用のままだと結論は動かない。自社開発は、一件あたりの初期費用が最も安く見えるからである。

外部パッケージは、初期費用に加えて年間の利用料が発生する。五年で積むと、見積書の上では自社開発を上回ることが多い。そして自社開発の見積りには、五年分の追随費用が書かれていない。 書かれていない費用は、比較表でゼロとして扱われる。

追随費用が発生する理由は、ERPが止まらないからである。SAPは、SAP S/4HANAについて2040年末までのイノベーション・コミットメントを表明しており、それまで常に少なくとも一つのリリースが保守対象にあるという形をとっている。一方で SAP Business Suite 7の中核アプリケーションの標準保守は2027年末までで、その後は 2028年初から2030年末までの3年間、保守基礎額に2パーセントポイントを上乗せする延長保守が用意されている。つまり、動かし続ける限りバージョンは上がる。上がるたびに、標準側が変わった箇所に自社開発を当て直す作業が発生する。

ここで効いてくるのが、先ほどの四段階である。公開され安定したインタフェースの上に作られたものは、当て直しがほとんど発生しない。内部オブジェクトに依存して作られたものは、標準が変わるたびに壊れる。 同じ「アドオン十九本」でも、その内訳がLevel Aで十九本なのかLevel Cで十九本なのかで、五年後の費用は桁が変わる。比較表に書くべき列は、初期費用ではなく、この依存先である。

そして依存先は、見積書には書かれていない。 書かれていないなら、こちらから聞く。この機能は公開APIの上に作りますか、それとも標準のプログラムを直接触りますか。この一問で、見積書の性格が変わる（クリーンコアの進め方、アドオンを減らす判断を経理の要件から考える）。

五年後に誰が保守しているかを、列にする

追随コストと並ぶもう一本の列が、保守の担い手である。三択は、五年後に誰が面倒を見ているかがそれぞれ違う。

標準機能で吸収した場合、保守の担い手はSAPである。自社が払っている年間保守料の中に、法改正対応も機能更新も含まれている。 使わなければ払い損になるだけで、追加費用は発生しない（SAPの年間保守料に見合う価値が出ない原因、標準機能の更新に追従できない体制）。

外部パッケージの場合、担い手はそのベンダーである。法改正への追随はベンダーの商品価値そのものなので、自社の工数はかからない。 代わりに、契約が続く限り利用料がかかり、ベンダーが撤退したりサービスを終了したりするリスクを持つ。そして連携部分だけは自社の責任範囲に残る（SAPとサブシステムの数字が合わない原因、販売・購買・経費・給与の連携設計）。

自社開発の場合、担い手は自社である。そして自社とは、実際には特定の一人である。 作った当時の要件を知っている情シスの担当者か、開発を請けたベンダーの特定の技術者。この人が異動するか、そのベンダーとの取引が切れると、そのアドオンは誰も触れないものになる。 使用実績がゼロでも、怖くて消せない状態で残り続ける。

三択を比べる表は、費用の三行ではなく、この担い手の三行を先に書く。 費用の議論は、担い手が決まった後でよい。

十九件を一件ずつ、この二軸に置いてから費用を見る。
自社の商売そのものか 高 →
自社開発の本来の対象
原価計算のロジック、価格決定、独自の販売条件。外に同じものは売っていない。標準や制度の変更に晒されにくいので、作っても追随費用が積み上がりにくい
公開APIの上に作る
自社固有だが制度や標準の変更を受ける領域。作るなら安定インタフェースの上に切り離して作る。内部オブジェクトに触れると、五年以内に作り直しになりやすい
標準機能で吸収する
共通業務で変更も少ない。運用を標準に寄せる。ここを作り込むのが最も損で、保守料を払いながら自社で二重に面倒を見ることになる
他社製パッケージで埋める
経費精算、請求書受領、電子帳簿保存、入金消込。法改正への追随がベンダーの商品価値になっている領域。自社で作ると追随を毎回自費で行う
標準側・制度側の変更に晒される度合い 高 →
右下を自社開発で埋めると、最も高くつきやすい。

会計処理も、三択で違う形になる

もう一つ、比較表から抜ける論点がある。この三択は、費用の総額だけでなく、費用の出方が違う。

自社利用のソフトウェアについて、研究開発費及びソフトウェアの会計処理に関する実務指針は、将来の収益獲得又は費用削減が確実であると認められる場合に無形固定資産として資産計上し、確実であると認められない場合又は確実であるかどうか不明な場合には費用処理するとしている。償却は、利用の実態に応じて最も合理的と考えられる方法によるが、一般的には定額法が合理的とされ、利用可能期間を基礎とする場合の耐用年数は原則5年以内とされている。

税務側の扱いも見ておく必要がある。国税庁の説明によれば、購入したソフトウェアの取得価額は購入の代価に、購入に要した費用の額と、事業の用に供するために直接要した費用の額を加えた金額であり、「導入に当たって必要とされる設定作業および自社の仕様に合わせるために行う付随的な修正作業等の費用の額は、取得価額に算入します」 とされている。耐用年数は、複写して販売するための原本または研究開発用のものが3年、その他のものが5年である。

ここが実務に効く。パラメータ設定や、自社仕様に合わせる小さな修正の費用は、当期の経費にはならない。 「アドオンではなく設定の調整です」という説明で通した工数も、資産に乗って五年間PLに残る。逆に、外部サービスの利用料は多くの場合、期間費用として毎期の損益に出る。

この差は、投資回収の説明の形を変える。自社開発は初年度のキャッシュアウトが大きく、その後五年間、償却費として損益に残る。五年後に使わなくなっても、除却するまで残る。 外部サービスは毎期の費用が続くが、やめれば止まる。やめられるかどうかという性質が、金額の比較と同じくらい効く（ソフトウェアとクラウド利用料の会計処理、資産計上できる範囲は契約の切り方次第）。

ERPの穴埋めを判断するために決める三つのこと

第一に、Fit&Gapで残った項目を、二択から三択の表に並べ直す。 埋め方は、標準機能で運用を変えて吸収する、他社製パッケージや外部サービスで埋める、自社で開発する、の三つである。二つ目が落ちやすいのは、Fit&Gapの実施主体が導入ベンダーであり、他社製品を勧める動機がないからである。判断の質問を「作るべきか」から「この項目は自社の商売そのものか、世の中の共通業務か」に変える。 経費精算、請求書受領、電子帳簿保存、入金消込、ワークフローのように法改正への追随がベンダーの商品価値になっている領域は、自社で作ると追随を毎回自費で行うことになる。

第二に、比較の軸を初期費用から、依存先と追随コストに移す。 SAPは拡張のきれいさを四段階に分けており、公開され安定したインタフェースに正式な安定性の契約が裏づけられたLevel A、文書化された従来型のAPIでおおむねアップグレード安定なLevel B、内部オブジェクトに依存し過渡的には許容されうるが長期的には将来性のないLevel C、推奨されないオブジェクトを使う最もリスクの高いLevel Dという区分である。同じアドオン十九本でも、Level Aで十九本かLevel Cで十九本かで五年後の費用は桁が変わる。 そしてERPは止まらない。SAP S/4HANAには2040年末までのイノベーション・コミットメントがあり、SAP Business Suite 7の中核アプリケーションの標準保守は2027年末まで、その後2028年初から2030年末まで保守基礎額に2パーセントポイントを上乗せした延長保守が置かれている。見積書に依存先が書かれていないなら、公開APIの上に作るのか標準のプログラムを直接触るのかを、発注前に一問で確認する。

第三に、保守の担い手を先に決め、費用の出方まで含めて比較する。 標準で吸収すればSAPが担い手で、追加費用は発生しない。外部パッケージならベンダーが担い手で、法改正の追随は自社工数を使わない代わりに利用料と撤退リスクを負い、連携部分だけが自社に残る。自社開発なら担い手は自社であり、実際には作った当時を知る特定の一人である。その人が異動すれば、使用実績がゼロでも消せないアドオンになる。 会計上、自社利用のソフトウェアは将来の収益獲得又は費用削減が確実であると認められる場合に資産計上し、償却は一般に定額法で耐用年数は原則5年以内とされる。税務上は、購入の代価に事業の用に供するために直接要した費用を加えたものが取得価額となり、導入にあたって必要とされる設定作業および自社の仕様に合わせるために行う付随的な修正作業等の費用も取得価額に算入される。 耐用年数は自社利用で5年。作った分は、五年間PLに残る。やめられるかどうかという性質が、総額の比較と同じくらい効く。

設例

売上高1,240億円の食品卸で、SAP ERP 6.0からS/4HANAへの移行を検討していた。Fit&Gapの結果、標準では埋まらない項目が四十一件残り、ベンダーからの追加開発見積りは合計8,900万円。役員会に上がった資料は、四十一件を「開発する」「業務を変更する」の二列で仕分けたものだった。 CFOがこれを差し戻したのは、費用の大きさより、五年後の姿が書かれていないことが理由だった。差し戻したうえで、三つの列を足すよう指示している。誰が保守するか、公開されたインタフェースの上に作るのか、そして会計上どう処理されるか。書き直してみて、四十一件の性格が三つに割れた。 第一に、経費精算の承認ルート、請求書の受領と電子保存、入金の消込ルール、稟議のワークフローで、合計十四件。これらは外部の専用サービスに同等の機能があり、いずれも法改正への追随がそのサービス側の商品価値になっている領域だった。 第二に、リベートの計算、得意先ごとの建値、賞味期限に応じた出荷可否の判定で、合計九件。これは同社の商売そのもので、外に同じものは売っていない。 第三に、残る十八件は、既存システムの画面や帳票の見た目に合わせるための項目だった。この十八件のうち十一件は、実際には旧システムの制約から生まれた運用で、業務上の必然がなかった。 ベンダーへの確認も行っている。四十一件のうち、公開された安定インタフェースの上に実装できるものが何件で、標準のプログラムを直接触る必要があるものが何件か。回答は、直接触る必要があるものが七件だった。この七件が、後の議論の中心になっている。 着地はこうなった。十四件は外部サービスで埋め、九件は公開インタフェースの上に切り離して自社で作り、十八件のうち十一件は運用側を変えて取り下げ、残る七件のうち五件は標準機能の使い方を変えて吸収、二件だけが標準を直接触る実装として残った。この二件については、次回のバージョンアップ時に再テストが必要な箇所として、稼働前から回帰テストの対象一覧に登録している。 費用は、初期の開発費が8,900万円から3,100万円に下がり、代わりに外部サービスの年間利用料が年1,480万円増えている。五年の総額で見れば、当初案とほぼ同水準である。 CFOがこの案を通した理由は総額ではなかった。十四件分の法改正対応が、今後は自社の工数から外れること。そして三年後のバージョンアップで当て直しが必要な箇所が、四十一件から二件になったこと。 経理部長が付け加えた一言が残っている。前回の移行で作ったアドオンのうち、何本が今も使われているかを誰も答えられなかった。今回は、答えられる本数まで減らした。

※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。

まとめ

ERPの機能不足の穴埋めは、作るか作らないかの二択より、標準機能・他社製パッケージ・自社開発の三択で比べる。比べる軸は初期費用より、何に依存して作るか、五年後に誰が保守しているか、そして費用がPLにどう残るかである。

次のFit&Gapの結果が出たら、項目ごとに「自社の商売そのものか」「制度や標準の変更に晒されるか」の二軸に置いてから、費用の議論に入りたい。自社開発を選ぶ項目は、公開APIの上に作るのか標準のプログラムを直接触るのかを発注前に確かめ、直接触るものは稼働前から回帰テストの対象一覧に載せておく。

関連記事