執筆者：堤 史明（Ascend株式会社 代表取締役）
本記事は、Ascend株式会社が発行したホワイトペーパー「ERP刷新ガイド 2027 失敗の構造と成功への処方箋」の内容をもとに、ERPのアドオンをどこまで残し、どう減らすかを解説したものです。
ERPの刷新を進める中で、アドオンをめぐる議論は避けて通れません。現行システムには長年かけて作られたアドオンがあり、新しいシステムでも要件定義が進むにつれて「ここは標準では足りない」という声が上がる。そのたびに、残すのか、作るのか、あきらめてもらうのかを誰かが決めなければなりません。
私は発注側の立場でERP導入・刷新を支援してきましたが、アドオンの議論がこじれるのは、「減らすべきかどうか」を論じているときです。減らすべきであることは、発注側もSIベンダーも分かっています。分かっていないのは、どれを残してよく、どれをどう減らせばよいのかです。アドオンをゼロにすることが目的ではありません。残すアドオンを自社の基準で選び、それぞれについて「なぜあるのか」を説明できる状態にすることが目的です。
本記事では、アドオンの種類と積み上がり方を整理した上で、残してよいアドオンの条件、現行アドオンの棚卸しから種類別の代替手段までの減らし方、そして稼働後に増やさないための運用ルールをまとめます。
ダウンロード資料：「ERP刷新ガイド 2027 失敗の構造と成功への処方箋」のご案内
ERPのアドオンとは何か、どう積み上がっていくのか
ERPのアドオンとは、パッケージの標準機能では対応できない要件を満たすために、標準機能の外側に追加開発するプログラムの総称です。一言でアドオンと言っても中身は幅広く、大きく分けると次のような種類があります。
- 帳票：納品書や請求書、管理資料など、標準の出力では形式が合わないもの
- 連携：EDI、倉庫管理、生産設備、経費精算など、周辺システムとデータをやり取りするためのインターフェース
- データ変換：旧システムからの移行や、コード体系の読み替えのための処理
- 画面・入力補助：標準画面では手間がかかる入力を簡略化する専用画面や一括登録
- 業務ロジック：自社固有の計算や判定、承認フローをパッケージの内部に組み込むもの
この分類が大事なのは、種類によって減らし方も、残したときの影響も違うからです。帳票と連携はパッケージの外側で代替しやすく、業務ロジックはパッケージの内部に手を入れるため、バージョンアップのたびに影響を受けます。「アドオンが○○本」という数だけで議論すると、この違いが見えなくなります。
アドオンが積み上がる経路は2つあります。ひとつは要件定義の中です。現場から出た個別の要求に対して、標準機能で対応できるかどうかを判断する材料が発注側にないと、要求はそのままアドオンの候補になります。本ホワイトペーパーが「現場の個別要求を無秩序に受け入れ、Fit to Standardの原則から逸脱する」と表現しているのが、この経路です。
もうひとつは、前回の導入で作ったアドオンが、棚卸しされないまま次のシステムに持ち越される経路です。刷新の場合、現行システムにはすでに数十本から数百本のアドオンがあり、その一つひとつについて「今も必要か」を確かめる前に、「現行と同じことができること」が要件になってしまう。こちらの経路は、新規の要求よりも気づかれにくく、本数としては大きいことが多いのです。
つまり、アドオンを減らす話は、「これから作るものを減らす」と「すでにあるものを持ち越さない」の2つに分けて考える必要があります。
アドオンを減らす理由は、開発費よりも稼働後にある
アドオンを減らす理由としてまず挙がるのは開発費ですが、発注側が本当に見ておくべきなのは、稼働したあとに続く負担です。開発費は一度で済みますが、稼働後の負担はシステムを使う限り続きます。
ひとつは、バージョンアップとの関係です。パッケージの内部に手を入れたアドオンは、本体が更新されるたびに動作確認と改修が必要になります。ホワイトペーパーが指摘するとおり、アドオン開発費と保守コストが増大し、アップグレードそのものが困難になる。SaaS型のERPであれば、本体の更新は自動で反映されますから、アドオンが多いほど更新のたびに確認作業が発生し、常に最新の環境を使えるというSaaSを選んだ意味が薄れていきます。
もうひとつは、属人化です。アドオンは作った時点では理由も仕様も明確ですが、数年たてば作った担当者は異動し、SIベンダー側の担当も変わります。本ホワイトペーパーが「過剰なカスタマイズによるブラックボックス化」と呼ぶ状態は、アドオンがあることそのものではなく、「なぜあるのか」「何をしているのか」を誰も説明できなくなったときに起きます。次の刷新でこのアドオンを持ち越すかどうかを判断しようとしても、判断材料がない。こうして「とりあえず現行と同じものを」という要件になり、アドオンが次の世代に引き継がれていきます。
さらに、アドオンが多いほどテストの範囲は広がります。標準機能はパッケージ側で品質が担保されていますが、アドオンは自社でテストしなければなりません。導入時だけでなく、バージョンアップのたびに同じテストを繰り返すことになります。
アドオンの量が予算に与える影響については、ERP刷新の予算超過の記事で数字を挙げて整理しています。本記事では費用の話はここまでにして、どう減らすかに進みます。
ERPのアドオンはどこまで必要か：残してよい3つの条件
では、どのアドオンなら残してよいのか。私が発注側を支援するときに使っている条件は3つで、この3つをすべて満たすアドオンだけを残す候補にします。逆に言えば、どれか一つでも満たさないアドオンは、作る前に立ち止まる対象です。
自社では変えられない要件に由来するアドオン
最初の条件は、その要件が自社の意思で変えられるものかどうかです。法令で定められた帳票の形式、取引先が指定するEDIのフォーマット、監査で求められる承認の証跡。こうした要件は、自社の業務を変えても消えません。標準機能で対応できないのであれば、アドオンで対応するのは合理的です。
この条件を最初に置くのは、議論の対象を絞るためです。外部から決められた要件を先に切り出しておけば、残りのアドオン候補はすべて「自社がそうしたいから」の要求だと分かります。ただし、「取引先が求めている」という説明は、実際には「昔からその形式で出している」というだけのこともあります。本当に外部からの要件なのか、契約や文書で確かめることが必要です。
標準機能で目的を果たせず、代替手段も検討済みである
2つ目の条件は、標準機能では業務の目的を果たせないことが確かめられており、かつアドオン以外の手段を検討した記録があることです。ポイントは「現行と同じことができない」ではなく「業務の目的を果たせない」である点です。画面の項目の並びが違う、操作の手順が増える、といった違いは、業務の目的を妨げてはいません。
業務の目的から来たギャップか、現行システムの仕様から来たギャップかを見分ける判断軸については、フィットギャップ分析とFit to Standardの違いの記事で詳しく書いています。ここでは、その判断を経た上で、なお「業務のやり方を変えても標準ではこなせない」「パラメータ設定や外部サービスでも吸収できない」という結論に至ったものだけが、この条件を満たします。検討の記録を残すのは、後で「なぜアドオンにしたのか」を説明するためです。
期限と管理責任者を決めて、例外として管理できる
3つ目の条件は、技術的な話ではなく管理の話です。アドオンは標準からの例外であり、例外には管理が必要です。具体的には、そのアドオンについて、業務側の管理責任者が決まっているか、「次のバージョンアップで標準機能に置き換えられないか見直す」「取引先のフォーマットが変わったら廃止する」といった見直しの条件と時期が決まっているかです。
この条件があると、アドオンの要求の出方が変わります。「この機能が欲しい」という要求に対して「では、誰が管理責任者になり、いつ見直しますか」と返すだけで、本当に必要な要求と、あれば便利という要求が分かれます。管理責任者を引き受ける人がいないアドオンは、稼働後に説明できなくなるアドオンの候補でもあります。
アドオン削減の進め方：棚卸しから代替手段まで
残す条件が決まったら、次は減らす手順です。ここでは刷新プロジェクトを前提に、現行アドオンの棚卸しから、種類別の代替手段の検討までを順に述べます。
現行アドオンの棚卸し：使われていないものを見分ける
最初にやるべきは、現行システムにあるアドオンの一覧を作ることです。必要な項目は、アドオンの名称と種類、利用している部門、最終利用日、作った理由、そして今その理由が生きているかどうか。SIベンダーが持っているプログラムの一覧は、名称と種類までは分かりますが、利用実態と作った理由は発注側が現場に確かめなければ埋まりません。
この作業をすると、いくつかのことが見えてきます。何年も実行されていない帳票、すでに退職した担当者のために作られた専用画面、取引が終わった取引先向けの連携。こうしたアドオンは、議論の余地なく持ち越さない対象です。システムの実行ログが取れるのであれば、最終利用日はログから機械的に出せます。現場へのヒアリングより先に、ログで絞り込む方が早い。
棚卸しを要件定義の前に終えておくことには、もうひとつ意味があります。要件定義の場で「現行と同じものを」という要求が出たとき、「そのアドオンはこの2年間使われていません」と事実で返せることです。議論が意見の対立ではなく、事実の確認になります。
種類ごとに減らし方は違う：帳票・連携・ロジック
残ったアドオンと、新たに要求されたアドオンについて、種類ごとに代替手段を検討します。種類によって、標準に寄せやすさも、外側で代替しやすさも異なります。
| 種類 | 減らし方の考え方 | 典型的な代替手段 |
|---|---|---|
| 帳票 | パッケージの中で作らない。データを外に出して整形する | 標準レポート、BIツール、表計算ソフトへの出力、帳票ツール |
| 連携 | 個別に作らず、標準の接続方式に揃える | 標準API、連携基盤（iPaaS）、周辺システム側の改修 |
| データ変換 | 移行時限りのものとして扱い、稼働後に残さない | 移行ツール、移行前のデータ整備 |
| 画面・入力補助 | 標準画面に手順を合わせる。入力の手間は運用で吸収する | 標準画面＋手順書、一括取込の標準機能、入力用の外部アプリ |
| 業務ロジック | まず業務ルールを見直す。次に設定で対応。それでも必要ならパッケージの外側に | パラメータ設定、外部の拡張基盤、ワークフローツール |
帳票と連携は、アドオンの本数としては多い一方で、パッケージの外側で代替しやすい領域です。帳票はERPの中で作り込まず、データを外に出してBIツールや帳票ツールで整形する。連携は相手システムごとに個別に作らず、標準の接続方式や連携基盤に揃える。この2つだけで、パッケージの内部に手を入れるアドオンはかなり減らせます。
画面と入力補助は、現場の要求がもっとも強く出る領域です。ただしここは、業務の目的ではなく操作の慣れの問題であることがほとんどです。標準画面に手順を合わせ、手順書とトレーニングで吸収するのが基本です。ホワイトペーパーがチェンジマネジメントのテーマとして「システムの動かし方（操作面）を変える」を挙げているのは、この領域のアドオンを作らずに済ませるためです。
業務ロジックは、本数は少なくても影響がもっとも大きい領域です。パッケージの内部に自社固有の計算や判定を組み込むと、バージョンアップのたびに影響を受けます。ここでは「業務ルールを見直す、パラメータ設定で対応する、それでも必要ならパッケージの外側に作る」という順序を守ることが重要です。
コアに手を加えず、外側で補う選択肢を持つ
表の代替手段に共通する考え方が、「ERPの本体（コア）には手を加えず、足りないものは外側で補う」というものです。ホワイトペーパーがFit to Standardの説明で「標準機能でカバーできない業務領域は外部のクラウドサービスを組み合わせて補完する」と書いているのは、この考え方です。ERP製品の側も、本体の外側に拡張を置くための基盤を用意する方向に進んでいます。
この選択肢を持つと、アドオンの議論は「作るか、あきらめるか」の二択ではなくなります。必要な機能は作る。ただしコアの中ではなく外側に作る。そうすれば、本体のバージョンアップと拡張部分の改修を切り離せ、テストの範囲も限定できます。アドオン削減の目的は本数を減らすことではなく、本体を標準のまま保ってアップデートに追従できる状態を作ることですから、外側に置いた拡張は、コアの中のアドオンとは別のものとして数えて構いません。
稼働後にアドオンを増やさないための運用ルール
導入時にアドオンを減らしても、稼働後の改修で増えていけば、数年後には現行システムと同じ状態に戻ります。稼働後に必要なのは、3つのルールです。
ひとつは、要求を受けたときの手順です。現場から「こういう機能が欲しい」と要求が来たら、まず標準機能と運用での代替を検討し、その結果を記録する。導入時に使った「残してよい3つの条件」を、そのまま稼働後の判断基準にします。導入時と稼働後で基準が違うと、導入時に見送った要求が稼働後に復活します。
2つ目は、承認の仕組みです。アドオンの追加を、情報システム部門とSIベンダーの間だけで決めない。業務側の管理責任者が誰になるのか、見直しの時期をいつにするのかを承認の条件にし、一定規模以上は経営層の承認を求めます。承認されたアドオンは、導入時に作った一覧に追記し、理由と管理責任者と見直し時期を残します。この一覧があると、次の刷新のときに棚卸しをゼロから始めずに済みます。
3つ目は、バージョンアップ前の見直しです。パッケージの更新で標準機能が増えれば、導入時には必要だったアドオンが不要になることがあります。バージョンアップはアドオンの動作確認が必要になるタイミングでもありますから、確認の前に「このアドオンはまだ必要か」を一覧で見直す。不要になったものを廃止すれば、確認の対象も減ります。
この3つは、どれも発注側の社内で決めることです。SIベンダーは要求されたアドオンを作る立場であって、作らないように制御する立場ではありません。アドオンを増やさない仕組みは、発注側が持つしかない。基幹システム刷新の進め方の記事で書いたとおり、稼働後の体制をプロジェクトのうちに決めておくことが、ここでも効いてきます。
まとめ：アドオンは減らすより、説明できる状態にする
ERPのアドオンは、帳票・連携・データ変換・画面・業務ロジックと種類があり、種類によって減らし方も残したときの影響も違います。減らす理由は開発費よりも稼働後にあり、バージョンアップへの追従と属人化の回避が、発注側にとっての本当の目的です。
残してよいアドオンは、自社では変えられない要件に由来し、標準機能では業務の目的を果たせず代替手段も検討済みで、かつ期限と管理責任者を決めて例外として管理できるもの。この3つを満たすかどうかを、現行アドオンの棚卸しと種類別の代替手段の検討を通じて確かめ、稼働後も同じ基準で運用する。それが、アドオンを「説明できる状態」に保つということです。
アドオンの本数をゼロに近づけることが成功ではありません。残したアドオンの一つひとつについて、なぜあるのか、誰が見ているのか、いつ見直すのかを発注側が言える。その状態であれば、アドオンは次の刷新の重荷にはなりません。
ダウンロード資料：「ERP刷新ガイド 2027 失敗の構造と成功への処方箋」のご案内
本記事で解説したアドオンの考え方を、Fit to Standardの考え方、過剰なカスタマイズが招く失敗の構造、発注側の体制の組み方まで含めて、ERP刷新の全体像の中で整理した資料です。市場動向、業界調査、第三者検証、チェンジマネジメントなど、これまで発行した資料の内容を1冊にまとめています。現行アドオンの棚卸しにこれから着手する方、SIベンダーからのアドオン提案を判断する立場にある方にお読みいただきたい内容です。
あわせて、標準化とカスタマイズの落としどころを現場の納得という観点から整理した「Fit to Standardは本当に正解か？」もご用意しています。