ERPのアドオンとは|カスタマイズとの違い、費用と保守で後悔しないための判断基準

製品選定・費用公開日:
監修大手コンサルティングファーム出身/基幹システム刷新・業務改革の実務経験を持つ専門家
ERPのアドオンとは|カスタマイズとの違い、費用と保守で後悔しないための判断基準

ERPのアドオンとは、製品の標準機能にない機能を標準とは別に追加で開発することです。カスタマイズは、狭い意味では標準そのものに手を入れることを指し、バージョンアップのたびに影響が出やすくなります。アドオンで後悔しないための判断基準は、「その業務が自社の強みか」「標準機能・設定・運用の変更で代わりが利かないか」「5年分の保守と改修の費用を払う価値があるか」の3つです。この記事では、アドオンとカスタマイズの違い、費用の内訳、作るかどうかの判定表を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。

この記事でわかること
  • ERPのアドオンとカスタマイズ・設定・外付け開発の違い
  • アドオンが増える理由と、公的資料・調査が示すアドオンの影響
  • アドオンの費用の内訳と、5年で見たときの保守・改修の費用の例
  • アドオンにするかを決める5つの問いと、アドオン以外の5つの代替手段
  • アドオンを作るときに守る10のルール(チェックリスト)

ERPのアドオンとは:標準機能の外に足す追加開発

ERPのアドオンとは、パッケージやクラウドERPの標準機能で足りない部分を、標準のプログラムとは別に作って追加する開発のことです。英語のadd-on(付け足すもの)が語源です。基幹システムの導入では、次のようなものがアドオンとして作られることが多くあります。

  • 独自帳票:取引先指定の納品書、自社独自の様式の請求書、経営会議用の集計表
  • 独自画面:受注をまとめて登録する画面、現場向けの簡単な実績入力画面
  • 独自の計算・判定:特殊な単価計算、在庫の引当の独自ルール、与信の判定
  • 連携:EC・EDI・銀行・既存の生産設備など、外部のシステムとのデータのやり取り
  • データの加工:旧システムからの移行用のプログラム、定期的なデータの集計・出力

アドオンそのものは悪いものではありません。問題は、作るかどうかの判断なしに、要望の数だけ作ってしまうことです。アドオンは作った瞬間から、保守とバージョンアップの対応が必要な「自社だけのプログラム」になります。

アドオンとカスタマイズの違い

アドオンとカスタマイズは、同じ意味で使われることがあります。ベンダーや製品によって言葉の使い方が違い、「カスタマイズ」が設定の変更を指すことも、プログラムの改変を指すこともあります。打ち合わせでは、言葉ではなく標準のプログラムに手を入れるかどうかで区別するのが確実です。

やり方何をするか標準への影響バージョンアップのとき
設定(パラメータ)製品が用意した設定項目で、締め日・税区分・承認の流れなどを決めるなし原則そのまま引き継がれる
アドオン(追加開発)標準とは別のプログラムとして、画面・帳票・処理を足す標準は変えないが、標準のデータや部品を使う使っている部品が変わると動作確認・改修が要る
外付け(周辺での開発)ERPの外の基盤やツールで作り、決められた接続口(API)でつなぐなし(接続口のみ)接続口が維持されれば影響は小さい
モディフィケーション(改変)標準のプログラムやデータの構造そのものを書き換える大きい改変部分の作り直しが必要になりやすい

この区別を、製品の提供元自身が示している例があります。SAPは「クリーンコア」という考え方の白書で、拡張のやり方を4つのレベルに分けています。公開され安定性が約束された接続口だけを使う拡張を最も望ましい「レベルA」とし、SAPの標準のオブジェクトの改変、標準のテーブルへの直接の書き込みなどを「レベルD(推奨しない)」として、最もリスクが高く、優先して直すべきものと位置づけています。その間には、文書化され、更新をまたいでもおおむね安定しているクラシックなAPIを使う「レベルB」と、SAP内部のオブジェクトに依存する「レベルC」があり、レベルCには更新前に影響を確認するための変更履歴(チェンジログ)が提供されるとしています。標準と拡張を切り離しておくほど、バージョンアップが安定するという考え方です。

見積書や提案書に「カスタマイズ一式」と書かれていたら、中身が設定・追加・改変のどれなのかを1行ずつ確認します。同じ「カスタマイズ」でも、設定の作業なら稼働後の費用はほとんど増えませんが、改変なら稼働後の保守とバージョンアップの費用が増えます。表の4つの区分で、見積もりの各行に印をつけてもらうと、あとから費用が膨らむ箇所が見えます。

MicrosoftのDynamics 365 Business Centralも、開発者向けの公式資料で、拡張用のオブジェクトを使ってテーブル・画面・帳票に項目や処理を足す仕組みを説明しています。製品によって仕組みの名前は違いますが、「標準は触らず、決められた方法で足す」方向は共通しています。

アドオンが増える理由と、増えたときに起きること

アドオンが増えすぎることの影響は、公的な資料でも指摘されています。経済産業省の「DXレポート」(2018年)は、既存のシステムが過剰なカスタマイズなどにより複雑化・ブラックボックス化していると指摘し、その要因としてソフトウェアのアドオン・カスタマイズの積み重ねを挙げました。

利用者の満足度との関係を示す調査もあります。JUAS(日本情報システム・ユーザー協会)の「ソフトウェアメトリックス調査2019年版」は、パッケージを使った開発について、カスタマイズが多いと顧客満足度が下がる傾向を示しています。同調査で集計されたプロジェクトでは、カスタマイズが「全く無し」が11件、「計画より少なかった」が10件、「計画より多かった」が17件で、計画より増えてしまったプロジェクトが最も多い結果でした。

では、なぜアドオンは計画より増えるのか。導入の現場でよく見る理由は次の4つです。

  • 「今と同じことができること」が前提になっている:現行システムの帳票や画面を1つずつ再現しようとすると、標準と違う部分がすべてアドオンになります。
  • 例外処理を全部システムで受けようとする:年に数回しか起きない処理まで自動化しようとすると、アドオンの数が一気に増えます。
  • 判断する人がいない:部門の要望を断る、または運用で対応すると決める人がいないと、要望はそのままアドオンの一覧に載ります。
  • アドオンの費用が見えていない:開発費だけを見て、保守やバージョンアップの費用を見ていないと、「1本数十万円なら作っておこう」となりがちです。

アドオンが増えると、稼働後に3つのことが起きます。保守の費用が毎年増える。バージョンアップのたびに動作確認と改修が要り、更新を先送りしがちになる。作った会社以外では直せなくなり、ベンダーを変えにくくなる。3つ目の問題はベンダーロックインとはで詳しく解説しています。

すでにアドオンが多い会社の棚卸しのしかた

今の基幹システムにアドオンが多い会社は、刷新の前に棚卸しをすると、次のシステムで作るアドオンを大きく減らせます。進め方は次の4段階です。

  1. 一覧を作る
    保守を担っている会社から、アドオンの一覧(帳票・画面・処理・連携の別)を出してもらいます。一覧がない場合は、メニューと帳票の出力記録から洗い出します。
  2. 使われているかを確かめる
    直近1年の利用記録(帳票の出力回数、画面の起動回数)を確認します。記録が取れない場合は、各部署に「この帳票がなくなると困るか」を聞きます。
  3. 目的を書く
    残すものについて、誰が・何のために使っているかを1行で書きます。目的が書けないものは、廃止の候補です。
  4. 5つの問いにかける
    目的が書けたものを、次の章の5つの問いにかけ、新しいシステムで「標準・設定・運用・外付け・アドオン」のどれで実現するかを決めます。

アドオンの費用は「作る費用」より「持ち続ける費用」

アドオンの費用は、開発費だけではありません。稼働後に払い続ける費用を含めると、次の費目に分かれます。

費目中身発生するタイミング見積もりで確認すること
設計・開発仕様の決定、プログラムの作成導入時1本ごとの金額と、仕様が変わったときの扱い
テストアドオン単体と、標準機能と組み合わせたテスト導入時発注側のテストの工数も含めて見る
保守不具合の修正、問い合わせへの対応、軽微な変更毎年標準の保守とは別契約か。年額の算出方法
バージョンアップ対応製品の更新時の動作確認と改修製品の更新のたびどの契約に含まれるか。クラウドなら更新の頻度
法令・制度対応税制や帳票の様式の変更への対応制度の変更時標準機能は提供元が対応しても、アドオンは自社負担
次の刷新時の移行次の基幹システムへの作り直し、または廃止次の刷新時設計書が残っているか。作り直しの前提で考える

見落とされやすいのが、法令・制度対応です。たとえば請求書の様式は、標準の帳票なら提供元が制度の変更に合わせて更新しますが、独自に作った請求書のアドオンは自社の費用で直すことになります。

次の表は、アドオンの量によって5年の費用がどう変わるかを示した例です。

項目案1:アドオン3本(帳票のみ)案2:アドオン15本(帳票・画面・計算)
設計・開発・テスト240万円1,500万円
保守(年)24万円×5年=120万円150万円×5年=750万円
バージョンアップ対応(5年で2回)20万円×2回=40万円200万円×2回=400万円
制度対応(5年で1回)30万円150万円
5年合計430万円2,800万円

※説明用の例です。金額は計算の仕組みを示すための架空の数字で、実際の相場を示すものではありません。保守の年額は、開発費に一定の率を掛けて決める契約もあれば、月額の固定や作業時間に応じた精算の契約もあります。

案2では、開発・テストの1,500万円に対して、稼働後の5年で1,300万円がかかっています。この例では、どちらの案も5年の総額が開発・テスト費の2倍近くになっています。アドオンを判断するときは、開発費だけでなく、稼働後に同じくらいの額がかかり得る前提で、作る価値があるかを考えるのが安全です。費用全体の考え方はERP・基幹システムの費用、見積もりのそろえ方はERPの比較ポイントで解説しています。

アドオンにするかどうかの判断基準

アドオンにするかは、要望ごとに次の5つの問いで判断します。上から順に答え、どこかで「代わりの手段がある」となれば、アドオンにしません。

問い「はい」の場合「いいえ」の場合
1. その業務は、他社との違い(強み)を生んでいるか次の問いへ。アドオンの候補になる標準に業務を合わせる方向で検討する
2. 標準機能の設定で実現できないか設定で対応(アドオンにしない)次の問いへ
3. 運用の変更(手順・帳票の使い方)で済まないか運用で対応(アドオンにしない)次の問いへ
4. ERPの外(帳票ツール・周辺サービス・ローコード)で作れないか外付けで対応次の問いへ
5. 5年の保守・改修の費用を払っても、効果が上回るかアドオンとして作る作らない。稼働後に再検討する

1つ目の問いが最も大事です。取引先ごとの細かい請求書の様式や、社内向けの集計表の形は、多くの場合「強み」ではありません。一方、自社独自の在庫の引当ルールで短納期を実現している、独自の見積もりの計算で受注率を上げている、といった業務は、標準に合わせると強みを失うおそれがあります。標準に合わせる考え方はFit to Standardとは、ギャップの埋め方の全体像はフィットアンドギャップ分析とはで解説しています。

5つの問いに答えるのは、要望を出した部署ではなく、あらかじめ決めた判断者です。要望を出した部署は、どうしても「必要」と答えがちだからです。中小企業なら、PM(プロジェクトの責任者)と業務領域ごとの判断者で週1回の判定の場を持ち、一定額を超えるアドオンや部門をまたぐアドオンは、経営層の会議(ステアリングコミッティ)で判断する形が回しやすい方法です。判定の結果は、「作る/外付け/運用/設定/やらない」の5区分でアドオンの台帳に残します。体制の作り方はPMOとはで解説しています。

アドオン以外の5つの代替手段

  1. 標準機能に業務を合わせる
    標準の業務の流れに、自社の手順を寄せます。最も費用がかからず、バージョンアップの影響も受けません。現場の抵抗が出やすいため、経営が方針として示す必要があります。
  2. 設定で対応する
    締め日、承認の流れ、帳票の項目の表示・非表示など、製品の設定項目で対応できる範囲を、導入するパートナーに確認します。「アドオンが必要」と言われた箇所も、設定で近い形にできないかを聞き直す価値があります。
  3. 運用を変える
    年に数回しか起きない例外処理は、手作業の手順書で対応します。システムで受けるより、運用で受けるほうが総費用は小さくなることが多くあります。
  4. 帳票ツールや周辺サービスで補う
    独自帳票は、ERPのデータを帳票ツールで出力する方法があります。集計表は、データを取り出して分析ツールで作る方法もあります。ERPの本体に手を入れずに済みます。
  5. ERPの外で作り、接続口でつなぐ
    現場向けの入力画面や独自の計算は、ローコードの基盤などERPの外で作り、公開された接続口(API)で連携します。向き不向きはローコード・kintoneで基幹システムは作れるかで整理しています。

具体例:アドオンにするもの・しないもの

同じ「アドオンの要望」でも、判断は分かれます。従業員110名の機械部品の卸売業を想定した2つの例です。

例1:取引先指定の納品書・請求書(12社分)
NG現行システムで取引先ごとに作っていた12種類の納品書・請求書を、すべてERPのアドオン帳票として作り直す。12本分の開発費に加え、様式の変更や制度の変更のたびに12本を直すことになる。
OKまず12社に、標準の様式で受け取れるかを営業から確認した。8社は標準の様式で了承。残る4社は、取引先のEDIや指定のWeb入力で対応する2社と、帳票ツールで出力する2社に分けた。ERPの本体には帳票のアドオンを作らなかった。

取引先指定の様式は「強み」ではなく慣習であることが多い要望です。相手に確認すると、思ったより標準で済みます。※説明用の例です。

例2:短納期を支える在庫の引当ルール
NGアドオンを減らす方針だからと、独自の引当ルール(重要顧客の注文に、入荷予定の在庫を優先して割り当てる)をやめて標準の先着順の引当にする。重要顧客への即日出荷の比率が下がり、営業から不満が出る。
OK引当ルールは自社の短納期の強みを支えていると判断し、アドオンとして作ることにした。ただし標準のプログラムは改変せず、標準の引当の結果を受け取って並べ替える外付けの処理として設計した。仕様書・テスト手順を残し、バージョンアップ時の確認範囲を最小にした。

強みに直結する業務は、アドオンにする価値があります。そのかわり、標準を改変しない作り方を選びます。※説明用の例です。

コンサルタントの現場メモ:この一言が出たら危ない
  • 「今の帳票は全部そのまま出せるようにしてください」――帳票の再現は、アドオンが増える最大の入口です。帳票は1枚ずつ「誰が・何に使っているか」を確認すると、使われていないものが見つかることがよくあります。
  • 「アドオン1本なら大した金額ではないので」――1本ずつの判断が積み上がって15本、20本になります。アドオンは1本ずつではなく、一覧で合計の保守費を見て判断します。
  • 「標準を少し直せば早いですよ」――標準のプログラムの改変は、開発は早くても、バージョンアップのたびに作り直しの対象になります。改変ではなく、追加か外付けで作れないかを必ず確認します。

アドオンを作るときに守る10のルール

判断の結果、アドオンを作ることになったら、次のルールで作ります。目的は、稼働後に保守できる状態と、次の刷新で困らない状態を残すことです。

  • 標準のプログラム・データの構造を改変しない(追加か外付けで作る)
  • 製品が公開している接続口(API)や拡張の仕組みだけを使う
  • アドオンの一覧(台帳)を作り、番号・目的・依頼した部署・判断者を記録する
  • 1本ごとに、作る理由(5つの問いの答え)を台帳に残す
  • 仕様書・設計書・テスト手順を、納品物として契約で定める
  • プログラム(ソースコード)の利用権・改変権が自社に残る契約にする
  • 保守の範囲・年額・対応時間を、標準の保守とは別に確認する
  • バージョンアップ時の動作確認と改修を、どの契約で誰が行うか決めておく
  • 稼働後1年で使われていないアドオンを見直し、廃止できるものは廃止する
  • 新しいアドオンの要望は、変更要求として一覧で管理し、費用を見て判断する

このうち、台帳と設計書の2つは、稼働後に効いてきます。担当者が異動しても、なぜそのアドオンがあるかがわかり、要らなくなったものを安心して廃止できます。台帳がないと、誰も使っていないアドオンの保守費を払い続けることになります。

台帳はExcelで十分です。1本につき1行で、少なくとも次の列を持たせます。

  • 番号と名称:AD-012「得意先別売上推移表」のように、設計書・テスト手順と同じ番号でひもづける
  • 区分:帳票・画面・計算・連携・データ加工のどれか。作り方(追加か外付けか)
  • 目的と利用者:誰が、どの業務で、どのくらいの頻度で使うか
  • 判断の記録:5つの問いの答え、判断者、判断した日
  • 費用:開発費、保守の年額、直近のバージョンアップ対応の費用
  • 依存先:使っている標準の画面・データ・接続口。バージョンアップ時の確認範囲になる
  • 見直し日:次に利用状況を確認する日と、廃止の可否

※番号や名称は説明用の例です。

契約と保守で後悔しないために

アドオンの後悔の多くは、稼働後の契約の範囲で起きます。「アドオンの不具合は保守の範囲だと思っていた」「バージョンアップ時の改修は別料金だった」というずれです。

IPA(情報処理推進機構)の「情報システム・モデル取引・契約書(第二版)」(2020年公開)は、民法改正に直接関係しない見直しの論点として、システム開発における複数契約の関係や、再構築への対応を挙げています。基幹システムの導入では、製品のライセンス・サブスクリプション、導入作業、アドオン開発、保守が別々の契約になることが多く、どの契約がどこまでを受け持つかを整理しておく必要があります。

契約の前に、少なくとも次の3点を確認します。1つ目は、アドオンの不具合が、開発の契約の不適合として直してもらえる期間と、その後の保守契約での扱い。2つ目は、製品のバージョンアップでアドオンが動かなくなったときの、原因の切り分けと改修の費用の負担。3つ目は、保守を別の会社に移すときに、設計書とソースコードを引き渡してもらえるか。この3点が曖昧なまま契約すると、稼働後に交渉する立場が弱くなります。

見積書の段階での確認の仕方はシステム開発の見積もりの見方でも紹介しています。

よくある質問

アドオンはゼロにすべきですか?

ゼロにする必要はありません。自社の強みを支える業務や、標準機能・運用の変更・外付けで代わりが利かない業務は、アドオンにする価値があります。大切なのは、1本ずつ作る理由を説明できることと、標準を改変しない作り方を選ぶことです。

クラウドERPでもアドオンは作れますか?

多くのクラウドERPは、製品が用意した拡張の仕組みや接続口(API)を通じて機能を足せます。一方で、標準のプログラムそのものを改変することは、通常はできないか、推奨されていません。クラウドの更新は提供元の予定で行われるため、拡張の仕組みに沿って作ることが前提になります。

アドオンの保守費はどのくらいかかりますか?

契約の形によって違います。開発費に一定の率を掛けて年額を決める形、月額の固定、作業時間に応じた精算などがあります。金額の目安を比べるより、保守の範囲(不具合の修正、問い合わせ、バージョンアップ時の確認・改修)が含まれるかを、見積もりの段階で確認してください。

すでにアドオンが多い基幹システムを使っています。次の刷新でどうすればよいですか?

まず今のアドオンの一覧を作り、それぞれが今も使われているか、誰が何のために使っているかを確認します。使われていないもの、標準や運用で代われるものを外し、残すものだけを次のシステムでの作り方(追加・外付け)で検討します。棚卸しをすると、使われていないアドオンや、新しい製品の標準機能で代われるアドオンが見つかることがよくあります。

アドオンとプラグインやアプリの違いは何ですか?

プラグインやアプリ(製品のマーケットプレイスで提供される拡張機能)は、提供元やほかの会社が作った拡張を、契約して使うものです。自社のために一から作るアドオンと違い、保守や更新への対応はその拡張の提供元が担うのが一般的です。ただし、提供が終了するリスクや、利用料が別にかかる点は確認が必要です。

アドオンの量で5年総費用がどう変わるかを試算できるワークブックを無料で配布しています

SAP・Salesforce・フルスクラッチなど作り方ごとに、初期費用だけでなくアドオンの保守やバージョンアップ対応まで含めた5年総費用を試算できる資料です。アドオンを作るかどうかの判断材料にお使いください。

資料をダウンロードする(無料)

まとめ

ERPのアドオンとは、標準機能にない機能を標準とは別に追加開発することで、標準そのものを書き換えるカスタマイズ(改変)とは、バージョンアップへの影響が大きく違います。アドオンの費用は作る費用より持ち続ける費用が重く、5年で見ると開発費に近い額が稼働後にかかることもあります。要望ごとに「強みか」「設定・運用・外付けで代われないか」「5年の費用に見合うか」を問い、作るなら標準を改変しない形で、台帳と設計書を残してください。

自社の要望のうち、どれをアドオンにし、どれを標準に合わせるべきか判断に迷う方は、無料診断で現状の業務と刷新の方針から整理します。

お役立ち資料(無料・18ページ)
5年総費用で比べる 基幹システムの作り方 試算ワークブック

費目一覧10と、記入して使う試算シート

資料をダウンロードする
この記事の執筆・編集:基幹システム構築支援 編集部(株式会社Digital&)

中小企業の基幹システムの構想策定から導入・定着までを支援する「基幹システム構築支援」の編集部です。記事は、大手コンサルティングファーム出身/基幹システム刷新・業務改革の実務経験を持つ専門家の監修のもと、実務で得た知見と公的な資料をもとに作成しています。