パッケージ開発とは｜ビジネスサイドのための IT 用語集

 パッケージ開発とは会計、販売管理、人事給与などの業務向けに市販されているソフトウェア製品を導入し、自社の業務に適合させてシステムを構築する開発の形です。

製品の標準機能で対応できる部分は開発せず、不足する部分だけを追加で開発します。

自社向けに設計から開発するスクラッチ開発と対になる語です。

ERP（Enterprise Resource Planning）もこの形で導入することが多い製品です。

ERPは会計、販売、生産などの基幹業務を1つの製品で一元管理する仕組みです。
ソフトウェア会社が販売用の製品そのものを開発することを、同じ語で指す場合もあります。

日本標準産業分類のパッケージソフトウェア業はこちらの意味で、製品を開発する側の事業を指します。

提案書や求人で目にしたときは、製品を導入する話か、製品を開発する話かを文脈で判別します。
 パッケージ製品を自社の業務に適合させる3つの手段IPA（情報処理推進機構）のシステム再構築を成功に導くユーザガイドは、パッケージ製品の利用形態を次のように分類しています。
設定: 製品のパラメータを定義する程度で、製品をほぼそのまま利用する
カスタマイズ: 製品が提供する開発言語やAPI（Application Programming Interface）を使用して、自社独自の処理を作り込む
アドオン: 独自に開発した機能や別の製品を、製品の外付けとして追加する
製品本体のソースコードを改変する方法もありますが、ガイドは推奨していません。

稼働後の機能の追加や改修のたびに、製品本体の品質保証を自社で担うことになるためです。
カスタマイズとアドオンの呼び分けは製品や会社によって異なり、追加開発全般をアドオンと呼ぶこともあります。

そのため発注側は見積もりの段階で手段ごとの内訳の提示を求めます。
 Fit&Gap分析と製品に適合しない要件の扱い導入の前に、現行の業務の要件と製品の標準機能を比較し、適合する部分をFit、適合しない部分をGapとして整理します。

Fitは英語で適合、Gapは隔たりを意味し、この作業をFit&Gap分析と呼びます。

設定で実現できる要件はFitに該当します。

IPAのガイドはGapに該当する要件の扱いを次の4つに分類しています。
4つのうち原則とするのは業務を製品に適合させることです。

この原則を導入の最後まで維持できないと、追加開発の分だけ稼働後を含めた費用の総額が増加します。

同じガイドに掲載されている会計パッケージの事例がその例です。

独自の帳票だけを追加開発する方針だったのに、テストの段階で現場から画面の操作も現行どおりにするよう要望がありました。

要望に応じて追加開発が増加し、期待したコストの削減は実現しませんでした。
ガイドは追加開発が大規模な場合にパッケージを利用しない判断も必要だとしています。

当初の方針を変更するほどの追加開発は、経営層を含めて決定するよう勧めています。
 効果とコスト 効果標準機能の部分は開発しなくてよいので、導入の期間と初期費用を削減できる
保守契約の範囲で、法令改正への対応や機能の追加を製品のバージョンアップで反映できる
他社で稼働している業務の進め方を、製品の標準として採用できる
 コストとリスクコストとリスクは導入時だけでなく稼働後にも発生します。
保守料は利用する限り毎年発生し、サブスクリプション型ではライセンス料も毎年かかる
カスタマイズとアドオンは製品のバージョンアップのたびに改修と再テストが必要になる
作り込みが多いほどそれを理解して改修できる要員を社内か外部で継続的に確保する必要がある
製品の保守期限が到来すると自社の計画とは無関係に新版への移行が必要になる
業務の進め方を変更する場合、現場の教育と定着に時間がかかる
 作り込みの費用の実績JUAS（日本情報システム・ユーザー協会）のソフトウェアメトリックス調査2020は、作り込みの費用が導入費用の半分近くを占め、稼働後にさらに増大する傾向を示しています。

ただし集計の件数が少ないため、数字は目安です。

新規導入の案件では導入費用の約46%をカスタマイズの費用が占めました。

稼働後5年間の保守と追加導入を含めた費用は、製品本体の部分が導入時の約1.5倍であるのに対し、カスタマイズの部分は約2.6倍になります。
 製品の標準に業務を適合させる範囲会計、人事給与のように会社による違いが少ない業務は、製品の標準に業務を適合させる
要件の大半、目安として8〜9割以上を設定と業務の変更で実現できるなら、パッケージを採用する利点がある
追加開発の費用が製品本体と導入の費用を上回る見込みなら、同じ範囲をスクラッチ開発で構築する場合とも5年間の総額で比較する
業務そのものが他社との差別化の源泉で、標準に適合させると競争力が低下する場合は、その部分だけ本体の外で開発する
設定の範囲だけで利用する小規模な導入や、アドオンが少数の帳票や外部へのデータ連携に限られる導入では、バージョンアップの追従の負担は軽微で、ここまでの検討は不要です。
業務を製品の標準に適合させることを原則にし、適合させられない業務だけを本体の外で開発すれば、バージョンアップのたびの改修を小規模にできます。

追加開発の要望は1件ごとに、利用期間全体で発生する改修の費用を開発会社に見積もってもらいます。

発注側は導入時の費用でなく、その総額で採否を決定します。