パッケージシステムとは?アドオン・カスタマイズ・パラメータ設定の違いと、安さが逆転する境界線【2026年版】

「提案書にパッケージと書いてあるが、SaaSと何が違うのか。アドオンとカスタマイズは同じものなのか」——システムの入れ替えを任された方から、こうした質問をよく受けます。見積書には「パラメータ設定」「アドオン開発」「カスタマイズ」という行が並び、金額だけが提示されている。言葉の意味が分からないまま、3社の提案を比べなければならない。この状態で意思決定を迫られている担当者は、決して少なくありません。

結論から言うと、パッケージシステムとは、完成した製品を購入し、自社が用意した環境に導入して使うシステムのことです。SaaSのように事業者の環境を借りるのではなく、自社で持ち、自社の判断で更新します。そして導入の成否を決めるのは製品の優劣ではなく、「パラメータ設定・アドオン・カスタマイズ」のどこで作り込みを止めるかです。本体を改変するカスタマイズが増えるほど費用は膨らみ、やがてバージョンアップができなくなり、最終的にスクラッチ開発より高くつきます。

「パッケージは安い」という説明は、標準機能で業務が回るという前提の上に成り立っています。その前提が崩れた瞬間、パッケージは「既製品の価格で買った、改造費のかさむ半オーダー品」に変わります。初期のライセンス費だけを見て決めると、5年後に更新できないシステムが残る。この分かれ道は、契約前の線引きで決まります。

本記事では、パッケージシステムの定義とSaaS・スクラッチとの違い、アドオン・カスタマイズ・パラメータ設定の3区分、カスタマイズが増えるとバージョンアップができなくなる仕組み、Fit&Gapという進め方と導入の流れ、ライセンス費と保守費の構造とサポート終了、パッケージを選ぶべきケースとスクラッチにすべきケース、よくある質問の順に解説します。製品のランキングは載せません。判断に必要なのは、製品名ではなく構造だからです。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。ベトナムの大手IT企業でERPパッケージの導入案件に上流から下流まで関わった時期もあり、「現行の機能をそのまま再現してほしい」という要望が、どのように見積もりを倍近くまで押し上げるかを事業者側から見てきました。この記事を読み終えるころには、手元の提案書のどこを確認すればよいかが分かるはずです。

パッケージシステムとは——完成した製品を買い、自社の環境に入れて使うシステム

パッケージシステムとは、すでに完成した製品として販売されているシステムを購入し、自社が用意した環境に導入して使う仕組みのことです。洋服にたとえれば既製品で、採寸から作るオーダーメイドがスクラッチ開発にあたります。ソフトウェアの提供のされ方そのものを整理したい場合は「ソフトウェアとは」の記事もあわせてご覧ください。ここではまず、発注の判断に直結する3つの論点——定義、SaaSとの違い、4つの作り方の位置づけ——を順に押さえます。

定義: 不特定多数の企業に共通する業務を、あらかじめ作り込んで製品にしたもの

会計、販売管理、在庫管理、勤怠、人事、グループウェア。これらの業務は、業種が違っても手順の骨格がよく似ています。パッケージシステムは、その「多くの企業に共通する部分」をあらかじめ作り込み、製品として繰り返し販売するものです。開発費を多数の導入企業で分け合う構造のため、1社あたりの負担が下がります。

ここで押さえておきたいのは、パッケージは「機能の集合」であると同時に「業務のやり方の提案」でもあるということです。製品には、その分野で標準的とされる業務の流れが組み込まれています。導入するということは、機能を買うだけでなく、その流れを受け入れるかどうかを決めることでもあります。この点を意識しないまま導入を進めると、後述するカスタマイズの膨張につながります。

SaaSとの違いは「借りるか、持つか」——ここが最も混同される

相談の場で最も混同されるのが、パッケージとSaaSの区別です。両者は「自分で作らない」という点では同じですが、システムがどこにあり、誰が管理するかがまったく違います。

パッケージは、購入したソフトウェアを自社のサーバーや自社が契約したクラウド上に導入します。システムは自社の資産として手元にあり、いつ更新するか、どこまで作り込むかを自社で決められます。その代わり、サーバーの用意、OSやデータベースの保守、バックアップ、障害時の一次対応、バージョンアップの実施は自社(または委託先)の責任です。

SaaSは、事業者が運用しているシステムを、利用料を払って使わせてもらう形です。サーバーの面倒を見る必要はなく、機能の更新も事業者が自動的に行います。その代わり、更新の時期は選べず、作り込みは事業者が許した範囲に限られます。クラウド全般の考え方は「クラウドとは」の記事で整理しています。

つまり、パッケージは「持つ」、SaaSは「借りる」。所有と管理責任がセットで動く、と覚えてください。なお、同じ製品名でパッケージ版とクラウド版の両方が提供されている場合もあり、名前だけでは判別できないことが少なくありません。提案を受けたら「サーバーはどちらが用意するか」「バージョンアップは誰が、いつ行うか」の2点を確認すれば、どちらの形かはすぐ分かります。

スクラッチ・ノーコードを含めた4つの作り方の位置づけ

システムを手に入れる方法は、大きく4つに分けられます。それぞれの性質を並べると、パッケージの立ち位置がはっきりします。

スクラッチ開発の分類や費用・保守の考え方は「スクラッチ開発とは」の記事、ノーコードで作れる規模の限界は「ノーコードとは」の記事で詳しく扱っているため、本記事では位置づけの比較に留めます。

パッケージが安く早いとされる理由と、その前提

パッケージが「安い・早い」とされるのは、機能がすでに完成しており、設計と実装の工程を丸ごと省けるからです。導入期間が短く、同じ製品を多くの企業が使っているため不具合が枯れている、という利点もあります。

ただし、この利点はすべて「標準機能をそのまま使う」という前提の上に成り立っています。前提が崩れるほど、パッケージの利点は失われます。では、どこからが「崩れた」状態なのか。その境界を示すのが、次章の3つの区分です。

アドオン・カスタマイズ・パラメータ設定の違い——どこまでが設定で、どこからが改造か

パッケージ導入の見積書には、「パラメータ設定」「アドオン開発」「カスタマイズ」という3つの行が並びます。この3つは、金額の大小だけでなく、導入後にシステムが何年使えるかを決める区分です。ここを読み分けられるかどうかが、発注側にとって最初の分かれ目になります。私自身、ERPパッケージの導入案件に上流から下流まで関わってきましたが、プロジェクトが荒れるときは必ずこの線引きが曖昧なまま進んでいました。

3区分の比較表——何をするか、費用、バージョンアップ耐性、保守責任

3つの違いは「パッケージ本体のプログラムに手を入れるかどうか」で決まります。

この表で最も重要なのは一番下の行です。パラメータ設定を使い切り、それでも足りなければアドオン、それでも業務が成立しない部分だけカスタマイズ。この順番を守れるかどうかで、5年後の姿が変わります。

パラメータ設定: 標準機能の範囲内で設定値を変える——最初にここを使い切る

パラメータ設定とは、製品があらかじめ用意した選択肢の中から、自社に合う値を選ぶ作業です。プログラムは1行も書きません。部門や勘定科目の体系を登録する、消費税の区分を選ぶ、承認の段階数を2段階に設定する、使わない機能を非表示にする、帳票の様式を用意されたものから選ぶ——こうした作業がこれにあたります。

パッケージの良し悪しは、実はこの設定で吸収できる幅の広さで決まります。同じ分野の製品でも、設定だけで対応できる範囲は製品ごとにかなり違います。製品を比べるときは、機能の一覧表を眺めるより、「自社で特殊だと思っている業務が、設定だけで表現できるか」を実機で確認するほうが確実です。

見落とされがちですが、設定を変える権限を誰が持つかも決めておく必要があります。導入後に現場が自由に設定を変えられる状態にすると、数年後には誰も理由を説明できない設定値が残ります。

アドオン: 本体に手を入れず、外側に機能を足す——連携・帳票・画面の追加

アドオンは、パッケージ本体には触れず、その外側に追加のプログラムを作って足す方法です。提供元が公開している接続口(API)や拡張の仕組みを使って、データを受け渡しします。

典型的なのは、基幹パッケージとECサイトの受注データを連携する、自社の取引先が指定する様式の帳票を出力する、パッケージが持たない分析画面を別に作る、といった作り込みです。本体が更新されても、外側のプログラムはそのまま動き続けます。手当てが必要になるのは、接続口の仕様が変わったときだけです。

費用は発生しますが、範囲が切り分けられているぶん見積もりが読みやすく、後から別の会社に引き継ぐこともできます。作り込みが避けられないなら、まずアドオンで実現できないかを検討してください。

カスタマイズ: 本体のプログラムを改変する——見積書で最も注意して読む行

カスタマイズは、パッケージ本体のプログラムを書き換える方法です。標準の画面に自社独自の入力項目を足す、標準の在庫引当ロジックを自社のルールに変える、といった作業が該当します。業務にぴったり合わせられる一方、製品の内部に手を入れているため、提供元が出す更新と正面から衝突します。

見積書に「カスタマイズ」の行があったら、金額よりも先に、何件の改変が予定されているか、その改変が次のバージョンアップでどう扱われるかを質問してください。「対応します」ではなく「その作業は誰が、いくらで、いつ行うか」まで確認する。この一手間を惜しむことが、後の塩漬けの始まりになります。

カスタマイズが増えるとバージョンアップができなくなる仕組みと、費用が逆転する構造

「カスタマイズできる製品を選んだので安心です」という言葉を、導入前の担当者からよく聞きます。しかし、できることと、してよいことは別です。本体を改変したパッケージは、提供元が出す更新を素直に受け取れなくなり、数年のうちに更新そのものが止まります。ここでは、止まるまでに何が起きるのかを段階で示し、そのうえで「パッケージは安い」という前提がどこで逆転するのかを計算の型で示します。

更新のたびに再適用と再テストが必要になる——止まるまでの4段階

パッケージの更新プログラムは、標準の本体を前提に作られています。本体を書き換えていると、更新を当てた瞬間に改変が消えるか、動かなくなります。そのため、更新のたびに改変箇所を作り直し、影響範囲を試験し直す作業が発生します。

段階4まで来ると、改修は「調べること」から始まります。この状態になったシステムをどう作り替えるかは「レガシーシステム刷新 外注」の記事で扱っていますが、本記事の主題は、そこへ至る入口を塞ぐことです。

公的資料が指摘するレガシー化の要因——カスタマイズ箇所の増加と現行踏襲

これは個社の失敗談ではなく、国の資料が構造として指摘している問題です。経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室が2025年5月28日に公表した「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート」は、レガシーシステムに陥る技術面の要因の一つとして、システムの肥大化・複雑化を挙げ、「カスタマイズ箇所が増え」て人手で運用を補う状態になることを指摘しています(2026年9月20日確認)。

同レポートでは、調査結果として次の点も示されています。ユーザー企業の61%がレガシーシステムを保有していること。モダン化の障壁として「既存システムが複雑でモダン化が技術的に困難」と「現行機能保証や、機能踏襲の制約が大きい」が上位2項目に挙がり、それぞれ31%、24%であること(n=59)。そして、現行システムにカスタマイズを施している企業は、移行先のシステムでもカスタマイズを施す割合が高いこと(n=333)。

最後の1点は重く受け止める必要があります。入れ替えを機に標準へ寄せるつもりでも、現行機能をそのまま再現したいという力学が働き、新しいパッケージでも同じ道をたどる企業が多いということです。同レポートには、現行と同じ機能・操作性を移行後にも求めた結果、カスタマイズが多くなって導入・運用のコストが高騰した、という趣旨の事例も記載されています。

「パッケージは安い」が逆転する計算——初期費ではなく5年総額で比べる

費用は、要素に分解すると見通しが立ちます。パッケージの5年総額は、次の足し算です。

• ライセンス費(初期)+ 導入支援費 + 作り込み費(設定・アドオン・カスタマイズ)
• + 年額の保守費 × 5年
• + バージョンアップ費 × 実施回数
• + 改変箇所の再適用・再テスト費 × 実施回数
• + サーバーやクラウドの費用 × 5年

スクラッチ開発の5年総額は、開発費 + 保守費×5年 + サーバー費×5年が基本です。パッケージ側には、スクラッチにはない「バージョンアップ費」と「再適用費」の2項目があり、これは改変の量に比例して増えます。つまり、作り込みが一定量を超えると総額が逆転します。初期のライセンス費が安く見えても、逆転は起こり得る、というのが実情です。なお、業務システム全般の費用相場は「業務システム開発 外注 費用」の記事で扱っています。

私が現場で見てきた膨らみ方——現行機能の再現要望がアドオンの山になる

私は2018年からホーチミンで約100社の開発体制を支援し、ベトナムの大手IT企業でERPパッケージの導入案件にも関わってきました。そこで繰り返し見てきたのは、要件定義の場で現場部門が一つずつ「今のやり方と同じにしてほしい」と挙げ、それが数十件の追加開発になり、初期見積もりの倍近くまで膨らんでいく光景です。

一つひとつの要望は、どれももっともなものでした。問題は、要望を受け取る側に「これは設定で吸収できるのか、外側で足せるのか、本体を触らないと無理なのか」を判断して差し戻す役割が置かれていなかったことです。ではその役割は、どの工程で、誰が担うのか。次章のFit&Gapが、その答えにあたります。

Fit&Gapという進め方と導入の流れ——業務をパッケージに合わせるという判断

パッケージ導入には、スクラッチ開発にはない固有の工程があります。Fit&Gap(フィット&ギャップ)分析です。ゼロから作る場合は「何を作るか」を決めますが、パッケージの場合は「製品の標準機能と自社の業務が、どこまで一致しているか」を先に測り、一致しない部分をどう扱うかを決めます。この工程の質が、前章で見た作り込みの量を左右します。

Fit&Gapとは——標準機能と自社業務の差分を洗い出し、Gapを4つに振り分ける

Fit&Gapは、自社の業務手順を一つずつ製品の標準機能に当て、合うもの(Fit)と合わないもの(Gap)に仕分ける作業です。重要なのは仕分けそのものではなく、Gapをどう処理するかの判断にあります。Gapの処理には4つの選択肢があり、上から順に検討します。

1. 業務のほうを変えて、標準機能に合わせる——追加費用が発生せず、バージョンアップにも影響しない。最も安く、最も長持ちする
2. パラメータ設定で吸収する——標準の範囲内なので、更新に耐える
3. アドオンとして外側に作る——費用は発生するが、本体を汚さない
4. 本体をカスタマイズする——業務上どうしても外せない要件に限る

前章で述べたとおり、4に寄るほど将来の費用と制約が増えます。経済産業省の総括レポート(2025年5月28日)も、Fit&Gap分析の結果、大きなギャップがある業務については、業務の複雑さや特殊性に応じて最小限のカスタマイズで済むアプローチを検討すべきだとしています。あわせて、経営資源の制約が大きい中堅・中小企業については、オーダーメイドのスクラッチ開発を避け、パッケージやSaaSを原則とすべきだ、という方針も示されています(2026年9月20日確認)。

Fit&Gapで見落とされがちなのが、Gapの件数ではなく「どの業務のGapか」です。件数が少なくても、それが受注から出荷までの主流の処理にあるなら、本体改変が避けにくくなります。逆に件数が多くても、月末の集計や帳票の様式といった周辺のものなら、アドオンで十分に対応できます。件数だけを見て「Fit率90%だから大丈夫」と判断するのは失敗のもとです。

導入の流れ7ステップ

Fit&Gapを含めた導入全体の流れは、次のとおりです。製品選定より先に、目的と対象業務の整理を置くのが要点です。

ステップ4を飛ばして5へ進むプロジェクトが、最も高くつきます。振り分けの判断を先送りしたまま開発に入ると、要望はすべて「追加開発」として処理されるためです。

業務をパッケージに合わせるという判断——現場の反発をほどく順番

Gapの処理で最も安く、最も長持ちするのは「業務のほうを変える」選択です。しかし、これは技術の問題ではなく合意の問題であり、現場の反発が最大の障壁になります。

先の総括レポートも、現場に標準化の検討を丸投げすると現行踏襲の問題が残るため、情報システムと事業を統括する双方の経営層が検討プロセスに関与することが重要だと述べています。つまり、「業務を変えるかどうか」は現場に判断させてはいけない、ということです。

実務では、次の順番で進めると反発が小さくなります。第一に、プロジェクトの開始前に「標準機能に寄せることを原則とし、例外は経営層が判断する」と全社に宣言する。第二に、Fit&Gapの場では現場に要望をすべて出してもらい、その場で却下しない。第三に、出そろった要望を4つの選択肢に振り分け、費用と将来の制約を添えて経営層が決める。第四に、決定の理由を現場に戻す。

要望を最初から抑え込むと、現場は「聞いてもらえなかった」と受け取り、稼働後に使われないシステムが残ります。出させたうえで、判断の場所を移す。ここを設計せずにパッケージを入れると、どれだけ良い製品を選んでも作り込みが膨らみます。

費用の構造とパッケージの寿命——ライセンス費、保守費、バージョンアップ費、サポート終了

パッケージの費用は「買い切り」と説明されることがありますが、実際に買い切りなのは最初のライセンスだけです。更新を受け取り続けるには年額の支払いが要り、版が上がれば別の支払いが発生し、製品には終わりの日が決められています。ここでは費用項目を分解したうえで、公式に価格と期日を確認できた製品を例に、構造がどう見えるかを示します。なお、本記事は製品の優劣を比べるものではなく、順位付けや推奨は行いません。

費用項目の一覧——初期費用に含まれないもの

見積書に載る金額は、たいてい上から4つ目までです。5つ目以降は、契約後に効いてきます。

公式価格で見る実例——ライセンス費、年額の保守費、バージョンアップ費の関係

金額の関係を具体的に示すため、提供元が価格を公開している製品を1つだけ取り上げます。サイボウズのパッケージ版Garoonは、公式の価格ページで次のように公開されています(いずれも税別・2026年9月20日確認)。50ユーザーまでの新規基本ライセンスが600,000円、1年間の継続サービスライセンスが120,000円、次の版へ上げるバージョンアップライセンスが420,000円。新規購入時は初年度のサービスライセンスが無償とされています。

この3つの数字を並べると、構造が見えます。年額の保守費はライセンス費のおよそ2割、版を上げる費用はライセンス費のおよそ7割です。仮に5年間使い、その間に1度バージョンアップしたとすると、600,000円 + 120,000円×4年 + 420,000円 = 1,500,000円。ここにサーバー費と運用の手間が乗ります。

同社はクラウド版の案内ページで、パッケージ版利用者向けに月額利用料900円/1ユーザーと記載しています(2026年9月20日確認)。50ユーザーなら年540,000円、5年で2,700,000円です。単純な金額だけを見ればパッケージ版のほうが小さく見えますが、パッケージ版にはサーバーの用意と運用、バージョンアップ作業の手間が加わり、さらに次に述べる寿命の問題があります。この比較は「どちらが得か」ではなく、比べるべき項目が違うことを示すために挙げています。

当社は自社の単価を公開しています。情報の非対称性を解消することが発注側への誠実さだと考えているからで、パッケージを選ぶときも、価格を公開している製品のほうが総額を組み立てやすい、というのは同じ理屈です。

パッケージには販売終了日とサポート終了日がある——確認できた2つの実例

パッケージは永遠に使えるものではありません。提供元は販売終了日とサポート終了日を定めており、多くは公式サイトで公表されています。

先ほどのパッケージ版Garoonは、公式の案内ページで販売終了日を2031年10月31日、サポート終了日を2033年1月31日としています(2026年9月20日確認)。2027年10月から順次ライセンスの販売を終了するとも記載されています。つまり、いま新規に導入しても、使い続けられる期間はあらかじめ区切られています。

大規模な基幹系でも事情は同じです。SAPは公式のサポートサイトで、SAP Business Suite 7の中核アプリケーションのメインストリーム保守を2027年末までとし、その後の延長保守を2028年初めから2030年末までの3年間、全サポート提供の保守基準額に2%を上乗せする形で提供するとしています。あわせて、SAP S/4HANAについては2040年末までのイノベーションコミットメントを表明しています(2026年9月20日確認)。

ここから読み取るべきことは1つです。パッケージを選ぶときは、機能と価格に加えて「この製品はいつまで保守が提供されるか」を必ず確認する。そして、サポート終了の数年前から移行の検討を始める。サポートが切れてから動き出すと、選択肢が減り、費用は上がります。移行そのものの進め方は「レガシーシステム刷新 外注」の記事に譲りますが、では自社の場合、そもそもパッケージを選ぶべきなのか。次章で判断の条件を整理します。

パッケージを選ぶべきケース・スクラッチにすべきケースと、入れた後に必要になる開発——当社が担う範囲と担わない範囲

ここまでの整理を、自社の判断に落とします。判断の軸は「標準機能で業務が回るか」の一点です。回るならパッケージが最も安く、最も長持ちします。回らないなら、無理に合わせるのではなく、作り方を変えるほうが結果的に安く済みます。そして、どちらを選んでも「パッケージの外側の開発」は必ず残ります。最後に、その領域で当社が何を担い、何を担わないのかを率直に書きます。

パッケージを選ぶべき5つの条件

次の条件に多く当てはまるなら、パッケージが向いています。

スクラッチ(または外側での作り込み)に切り替えるべき4つの条件

逆に、次に当てはまるなら、パッケージ本体を改造して合わせるより、別の作り方を検討してください。

スクラッチ開発の分類や費用・保守の考え方は「スクラッチ開発とは」の記事、社内でどこまで持つかという論点は「システム内製化」の記事を参照してください。ここで言いたいのは、パッケージとスクラッチは対立する選択肢ではなく、業務ごとに使い分けるものだということです。

パッケージを入れた後に必ず出てくる開発——連携、データ移行、外側の作り込み

パッケージを入れれば開発が終わる、ということはまずありません。稼働後に必ず出てくるのは、次のような仕事です。

• 他システムとの連携(ECの受注、倉庫、会計、勤怠、名刺・顧客管理などとのデータの受け渡し)
• 既存システムからのデータ移行と、移行後のデータ整備
• 取引先が指定する様式の帳票や、パッケージが持たない分析画面
• 顧客・取引先が直接使うWebサイトやアプリ(パッケージの外側に置く)
• サポート終了に伴う次の製品への移行、または自社開発への切り替え

これらは、パッケージ本体のカスタマイズとは別の仕事です。本体に手を入れずに外側で作れば、バージョンアップの足枷になりません。前章までの話を実装に落とすと、要するに「本体は素のまま保ち、足りないものは外側に作る」という方針になります。

当社の位置づけ——大手パッケージのカスタマイズは担わない。担うのは外側の開発と移行

先に、担わない範囲をはっきり書きます。当社は、SAPやMicrosoft Dynamicsといった大手ERPパッケージの本体カスタマイズを主業にしていません。製品固有の認定資格や、製品の販売代理も持っていません。この領域は、その製品の導入を専門にするベンダーに依頼するのが確実です。当社の中にERPパッケージの導入案件を経験したメンバーはいますが、会社としての体制はそこに置いていない、というのが率直なところです。

当社が担うのは、パッケージの外側です。他システムとの連携、独自の帳票や分析画面、顧客が直接触るWebサイトやアプリの開発、そしてパッケージから自社開発へ移行する場合の新システム構築と継続開発。実績としては、介護記録SaaS「CareViewer」を日本語対応のブリッジSE1名とフルスタック2名で継続開発し、従来の半分以下のコストで週次の優先順位判断を回している案件や、Stripeを使った決済アプリ(二要素認証、ウォレット、PDF出力)を新規開発から週次保守まで担当した案件があります。

体制は、日本人PM/BrSEをフロントに置くパターンAと、エンジニアのみのパターンBの2つ。1名から契約でき、開始は最短2週間、増員は約1週間、縮小と交代は1か月単位です。2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、協力会社を経由する仲介マージンがありません。単価は公開しており、実務3年目安で1,500USD(約22.5万円/1USD=150円換算目安)、5年で2,000USD、10年以上・ブリッジSEで3,000USD。日本人PMフロント+2〜3人月なら月額約80万円からが目安です。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

品質は、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点で担保しています。もし相談をいただいた内容が「大手パッケージ本体のカスタマイズ」であれば、当社では受けられない旨を最初にお伝えします。そのほうが、お互いの時間を無駄にしないからです。

【FAQ】パッケージシステムに関するよくある質問

パッケージの検討で、相談の場で繰り返し聞かれる質問を5つにまとめました。社内説明の材料としてもお使いください。

Q1. パッケージとSaaSは、結局どちらが良いのですか?

良し悪しではなく、持つか借りるかの違いです。自社の判断でバージョンを管理したい、社内の他システムと密に連携させたい、データを自社の環境に置く要件があるならパッケージ。サーバーの運用を持ちたくない、常に最新の状態で使いたいならSaaSが向きます。判断に迷うときは、「サーバーの障害対応とバージョンアップ作業を、自社の誰が担うか」を先に決めてください。担い手がいなければ、パッケージは選ばないほうが無難です。

Q2. カスタマイズはどこまで許容してよいですか?

件数ではなく、場所で判断してください。受注から出荷、請求といった主流の処理に本体改変が入ると、バージョンアップのたびに広い範囲の再テストが必要になります。周辺の帳票や分析なら、アドオンとして外側に作れば本体を汚しません。社内の原則としては、「本体改変は経営層の承認事項にする」「改変1件ごとに、次のバージョンアップでの扱いと費用を見積書に書かせる」の2つを決めておくと歯止めになります。

Q3. パッケージは本当にスクラッチより安いのですか?

標準機能で業務が回るなら安く済みます。回らない場合は逆転し得ます。比べるべきは初期のライセンス費ではなく、5年総額です。ライセンス費、導入支援費、作り込み費、データ移行費、年額の保守費、バージョンアップ費、改変箇所の再適用費、サーバー費を足し合わせて、スクラッチの開発費+保守費+サーバー費と並べてください。パッケージ側にだけある「バージョンアップ費」と「再適用費」が、逆転を生む項目です。

Q4. サポートが終了したパッケージは、そのまま使い続けられないのですか?

技術的には動き続けますが、更新プログラムが提供されなくなるため、脆弱性が見つかっても修正されません。法令や制度の改正にも追従されず、土台となるOSやデータベースのサポート期限とも噛み合わなくなります。公表されているサポート終了日から逆算し、規模にもよりますが2〜3年前には移行の検討を始めてください。切れてから動くと、選択肢が減って費用が上がります。

Q5. 業務をパッケージに合わせると現場が反発します。どうすればよいですか?

要望を抑え込むのではなく、判断の場所を移してください。Fit&Gapの場では要望をすべて出してもらい、その場では却下しない。出そろった要望を「業務を変える/設定で吸収する/外側に作る/本体を改変する」の4つに振り分け、費用と将来の制約を添えて経営層が決める。決定の理由は必ず現場に戻す。プロジェクト開始前に「標準に寄せることを原則とし、例外は経営層が判断する」と宣言しておくことが、最も効く準備。

まとめ: パッケージは安いから選ぶのではなく、標準機能で業務が回るから選ぶ

パッケージシステムとは、完成した製品を購入し、自社が用意した環境に導入して使うシステムです。事業者の環境を借りるSaaSとは、所有と管理責任の所在が違います。そして導入の成否を決めるのは製品の優劣ではなく、作り込みをどこで止めるかです。パラメータ設定で吸収し、足りなければアドオンとして外側に作り、本体のカスタマイズは最後の手段にする。この順番を守れるかどうかが、5年後に更新できるシステムを残せるかを分けます。

本体を改変すると、提供元の更新のたびに再適用と再テストが必要になり、やがて更新そのものが止まります。経済産業省が2025年5月28日に公表した総括レポートも、カスタマイズ箇所の増加と現行踏襲へのこだわりをレガシー化の要因として挙げています。費用も同じ構造です。比べるべきは初期のライセンス費ではなく、保守費、バージョンアップ費、再適用費、サーバー費まで含めた5年総額。パッケージには販売終了日とサポート終了日が定められており、寿命は最初から決まっています。だからこそ、Fit&Gapで洗い出したGapを4つに振り分け、「業務のほうを変える」判断を経営層が下す場をつくってください。

自社の業務が標準機能で回るならパッケージ、業務そのものが競争力の源泉ならスクラッチや外側での作り込み。判断の材料はスクラッチ開発とは、5年総額を組み立てる際の相場感は業務システム開発を外注する費用もあわせてご覧ください。なお当社は、大手パッケージ本体のカスタマイズは担っていません。担うのは、連携・帳票・顧客向けの仕組みといったパッケージの外側の開発と、パッケージから自社開発へ移行する場合の構築と継続開発です。現在の体制と要件をお聞かせいただければ、外側の開発として切り出せるかどうかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。