パッケージ導入の鍵を握る「アドオン」と「カスタマイズ」それぞれの違いと留意点を解説！
パッケージシステム(以下「パッケージ」という。)の選定や導入の場面で「BPR」「アドオン」「カスタマイズ」という用語がよく使われます。
それぞれは、パッケージの導入をその組織に最適な形で行うための手法ですが、そこにはメリットもデメリットもあります。
本記事では、その中でも「アドオン」と「カスタマイズ」に着目し、これらふたつの違いと、開発・導入・運用の際の留意点について解説します。
アドオンとカスタマイズ
パッケージを導入する際にFit&Gap（フィット＆ギャップ）という分析を行います。その目的は「パッケージが持つ機能とパッケージに求める機能の適合度を確認すること」です。
そして、適合しない部分(Gap)について「運用で対処する」「BPRを行う」「追加機能開発を行う」という対応策の検討がなされます。
そのうちの三つ目「パッケージシステムの機能だけでは、業務を適切に行うことができないため、追加でプログラム開発を行う」と判断した時に採用される手法が、「アドオン」と「カスタマイズ」です。
※Fit＆Gap（フィット＆ギャップ）について詳しく知りたい方はこちらの記事も併せてご確認ください。
アドオン
アドオンは、必要とされる追加機能のために開発されるもので、パッケージそのものには手を加えず、新たにプログラムを開発するものです。このことから「外付けプログラム」と呼ばれることもあります。
パッケージとアドオンの連携についての技術的方法は様々ですが、代表的なものとして次のようなものがあげられます。
- API連携(パッケージメーカーが外部のプログラムと連携するために仕様を公開する)
- データベーストリガー(データベースに何らかの変更が加えられた場合に自動的にプログラムを起動する)
- 非同期連携(データベースやテーブル、ファイルにデータの追加・更新があるかどうかを決められたインターバルでチェックし、それをトリガーとしてアドオンプログラムを起動する)
また、アドオンプログラムの機能としては、主に次のようなタイプがあります。
- パッケージから受け取ったデータをアドオンの中で処理し、結果を出力する
- パッケージから受け取ったデータをアドオンの中で処理し、結果を別のシステムに引き継ぐ
- パッケージから受け取ったデータをアドオンの中で処理し、パッケージに処理結果のデータを戻す
カスタマイズ
カスタマイズという用語は、広義でアドオンを含む場合もありますし、パッケージの初期設定やパラメータ設定を含む場合もありますが、この記事では、アドオンと対比させるため、「パッケージのソースコードを変更する」という狭義のカスタマイズについて述べています。
カスタマイズはアドオンとは違い「パッケージそのものに手を入れる」手法です。パッケージメーカーが著作権を有しているソースコードに修正を加えることになるため、一般的にはパッケージメーカーのみが行えるものです。
ただ、アドオンとは違い、「機能追加」よりも「機能変更」を目的として行われることが多く、特に、入出力画面や出力帳票のレイアウト変更等がカスタマイズの対象とされることが多くあります。
まれに入力項目の変更や処理ロジックの変更がカスタマイズとして行われることがありますが、あまりにも周辺プロセスへの影響が大きいため、行われるべきではありません。
なお、アドオン、カスタマイズ以外にも、コンフィギュレーション、モディフィケーションというような、よく似た言葉が使われる場面があります。発注側の企業とパッケージメーカーやシステムインテグレーター、開発ベンダによって用語の定義が異なることがありますので、前もって共通理解を持つ必要があります。
開発・導入フェーズでの留意点
ここでは、開発・導入の際の「アドオン」「カスタマイズ」についての留意点を説明します。
最も重要な留意点は「そのアドオン、カスタマイズが本当に必要なものなのかを十分に精査すること」です。
パッケージであれ独自開発のシステムであれ、「盛りだくさんの要求、要件」は導入プロジェクトの成否に大きく影響します。特にパッケージ導入では「nice-to-have」とも表現される「あったらいいな」機能を排除することが成功のポイントになります。
また、そもそも、パッケージは「蓄積された知見をもとに開発されたシステムを利用して、業務を標準化、高度化するためのもの」のはずであり、「その組織が持つ既存の業務の考え方をベースにしたアドオン、カスタマイズ」を優先すべきではありません。
アドオン、カスタマイズを行う前に「パッケージの機能を使いこなす」という考え方が優先されるべきです。
なお、止むを得ずアドオンやカスタマイズを行う際には、パッケージの機能を熟知した技術者が必要となることは当然ですし、独自開発のシステムと同様に、詳細な要件定義をはじめとする設計プロセスは避けて通ることはできません。
技術的な観点としては、アドオン開発にはAPI(API連携の場合)が公開されていることや、データベースの構造(データベーストリガーの場合)が公開されている必要があります。
カスタマイズの場合は、そのパッケージが、そもそもカスタマイズが可能なパッケージかどうかの判断が必要です。
開発期間についても留意しておく必要があります。
アドオンの場合はパッケージの導入と並行して開発することが可能ですが、やはり、導入プロジェクトの期間が長くなることは否めません。アドオンプログラムの実行により生成したデータをパッケージシステムに戻すという連携を行う場合は、複雑な依存関係が発生するため、より一層の開発期間延長を想定すべきです。
また、カスタマイズの場合は、その部分が完成しないとパッケージの導入自体が実施できないため、プロジェクトを進める上でのクリティカルパスになる可能性が高くなります。
これらに加えて、「テストの複雑性」も考慮する必要があります。
アドオンもカスタマイズも単体としての品質確保のためのテストもさることながら、標準機能も含めたパッケージ全体としての品質を担保することを確認できるようテストを実施する必要があります。
アドオンやカスタマイズによるパッケージ全体の品質低下は、データの不整合を招いたり、関連業務や関連システムのプロセスに影響を及ぼしたりすることが懸念されます。
パッケージ導入の失敗事例の多くには、アドオンやカスタマイズによる品質低下が大きく関わっているのです。
運用フェーズでの留意点
ここでは、運用開始後における「アドオン」「カスタマイズ」の留意点を解説します。
多くのパッケージは利用企業のコミュニティからの要求や法律・制度の変更等により、「機能追加、機能変更」のためのバージョンアップが行われます。また、セキュリティ強化や使用するデータベースの機能変更の影響などでもバージョンアップが行われます。
アドオンやカスタマイズを行った場合、これらのバージョンアップへの対応が困難になる場合が多くあります。
特にカスタマイズの場合は、機能変更を行った部分がバージョンアップによってリセットされることになり、バージョンアップ後にも継続してそのカスタマイズ機能を利用する場合には多くの労力がかかります。
また、パッケージのバージョンアップのためには、まず、その体制を整えなければなりません。
アドオン開発を担当した開発ベンダ、カスタマイズを行ったパッケージメーカーがこの体制に加わり、大きなプロジェクトとなります。また、開発・導入時に行ったテストを再度行い、品質を確保する必要があります。
結果として、これらは、運用のコスト増や発注側企業における作業負荷の増大にもつながるのです。
このコスト増や作業負荷を避けるため、「バージョンアップを行わない」という判断がなされるケースがありますが、これは、本来あってはならないことです。
なぜならば、この判断は「塩漬けシステム」を生むことになってしまい、最終的には「陳腐化して使えないシステム」になる可能性が高くなるからです。特に、カスタマイズが多く行われる場合にこの傾向が高くなります。
通常の運用時にも留意点があります。
開発時の留意点でもテストの複雑性について述べましたが、運用開始後にデータの不整合等のトラブルが発生することが皆無だとは言えません。
この時、カスタマイズでは、パッケージそのものの保証外とされることがありますし、保証のため追加の費用が発生する場合もあります。
アドオンの場合は、開発ベンダとパッケージメーカーとの間での責任の所在が不明瞭になることもあるため、十分な事前協議が必要です。
その他の留意点
対応策の優先順位についての留意点
パッケージ利用に際し、「運用で対処」「BPR」「アドオン」「カスタマイズ」の選択の判断は、パッケージがカバーする業務の領域やその広さ、対象業務の重要性や戦略性もポイントとなります。
これは、Fit&Gapの時点で議論されるべきポイントです。
最優先は「運用で対処」「BPR」ですが、事業戦略として業務プロセスの変更が適さずどうしても「アドオン」か「カスタマイズ」を選択せざるを得ない場合、同じ機能が実現できるのであればアドオンを優先して選ぶことを原則とします。
アドオンではどうしても実現できない場合のみ、最終的な案としてカスタマイズをするしかないという判断に至る流れは、組織の共通理解としておくべきポイントです。
クラウドサービスでの留意点
近年、クラウドサービス上のサーバにパッケージを導入して利用するという形態も多くなっています。
アドオン自体がパッケージとは別の環境に導入されたり、開発するアドオンが別の環境上のシステムと連携する必要があったりする場合には、ネットワークを含めた構成管理も重要となってきます。
また、エラーが発生しにくい連携方式や、エラーが発生しても原因の切り分けや復旧が容易にできる構成を検討しなければなりません。
まとめ
本記事では、パッケージの利用に関するアドオンとカスタマイズについて解説するとともに、その留意点について考察しました。
パッケージの利用に際しては、業務もシステムも変更せずに使えるという状況が理想だとは言うものの、実際の導入場面ではGapの存在を避けることはできません。
そのためGapへの対応として、「Fit to Standard」と言われるように、パッケージの標準機能に合わせて、業務の進め方や方法自体を変えることを最優先させるべきであり、それでもGapが残ってしまう場合にはじめて、「アドオンかカスタマイズか」という議論を行うようにすべきです。
また、導入時だけではなく、継続的な運用も視野に入れた検討を行うことが必要です。
その意味でも、パッケージの導入に際してはFit&Gapの時点で要件を精査し、「パッケージに業務を合わせていく」「Gapとなる要件を絞り込む」という姿勢が望まれます。
この記事の編集者
下里 朋子
自治体で情報政策分野を9年間担当した後、IT調達ナビの運営会社である（株）グローバル・パートナーズ・テクノロジーに中途入社。ITコンサルティング業務に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するメディア運営業務にも携わる。
