パッケージ製品の活用【デジタルプロフェッショナル学科】

前にブログで書きましたが、
ITの目指すところは自動化であり、
自動化によりコストを削減することを第一の目的としています。
ですが、日本ではシステム導入に多大なコストがかかっているという
本末転倒な状況が前々から続いています。
DX（デジタルトランスフォーメーション）が進んでいない
大きな要因とも言われています。

システムを導入する方法として、大きく、
パッケージ製品を活用する方法と、
独自にシステムを構築する方法（スクラッチ）があります。
パッケージ製品は既製品を汎用的に利用するので、
導入のための初期費用と使用期間中にライセンスの費用がかかるものの、
開発のための費用もかからなければ、長い開発期間も不要です。
コスト面から考えると圧倒的な差があります。
それなのに、日本ではパッケージ製品の導入が
海外と比較しても、うまくいっていません。

システム導入を考えている業務の担当者としては、
なるべく現在やっている業務のやり方を、大きく変更したくない、
という要望があります。
より楽にしたいけれど、業務の仕方は基本的に変えたくない。
マニュアルを作り直したくないし、慣れたやり方のほうが楽です。
「業務にシステムを合わせるか」、
「システムに業務を合わせるか」、
と、問われれば、業務の担当者の多くは前者を求めます。
そうなると、現行の業務と、導入するパッケージ製品の機能を
比べて（フィット＆ギャップ分析と言います）、
合わない機能や不足している機能があれば、
カスタマイズやアドオン（独自の機能を追加開発）を要望することになります。

ただ、その道の先に待っているのは暗い未来です。
パッケージ製品のカスタマイズやアドオンは、
パッケージ製品導入のメリットを磨滅させます。
まず、システム導入の第一の目的である
コスト面でのメリットがなくなります。
開発にはお金がかかります。
お金だけでなく、時間もかかりますし、
プロジェクトに割かれる人的なリソースも
ばかになりません。
その上、カスタマイズやアドオンした箇所が
製品をバージョンアップするときに足を引っ張り続けます。
当然ですがパッケージ製品を開発した会社は
独自にカスタマイズした箇所の動作保証をしてくれません。
また、パッケージ製品は業界のベストプラクティス
（よい業務のやり方）を取り込んで設計されているのに、
その価値も失われてしまいます。
独自性を発揮する必要がある主体業務は別ですが、
その他の付帯業務はパッケージ製品をそのまま利用して、
ベストプラクティスに乗っかったほうが、確実にいいのです。
もし現行業務がパッケージ製品と合わなければ、
業務の方を変えるべきなのです。
システム導入は業務の大きな変更を含意している、という、
海外では当たり前に思われていることが、
日本では常識となっていません。
「システムは業務を助けるためのツール（以上のものではない）」
「現行業務が大事なのだから、業務に合わせてシステムを変えるべきだ」
と、日本では思われています。
この認識がDXの足かせになっています。

今回のブログはパッケージ導入コンサルタントをやっている
知人の思いを勝手に受けて記載しました。
カスタマイズやアドオンは、お客のためにもならないのはわかっているし、
プロジェクトが失敗するリスクも高まるので、知人は嫌なようです。
ただ、お客に「こんな機能もないのか」「他の製品にするぞ」と
言われれば、本来は不要な機能でも、
「カスタマイズすればできます」と回答せざるを得ないし、
自分の会社としても追加の開発があると利益が上がるので、
断り切れないようです。
「何のためなの？」という不幸な開発プロジェクトが、
巷にはあふれているのです。

このテーマではまだまだ伝えたいことがありますが、
長くなってしまったので今回はこの辺にします。