パッケージの自由度のなさは本当にデメリットなのか？

現場のストレスはピーク

「パッケージは、かゆい所に全然手が届かなくて大変です」

PMOを務める情報システム部のAさんが、ため息交じりにお話しされました。

・今までのエクセルの方が早かった
・今まで出していた帳票が出せない
・今までやっていたチェックができない
・自由にデータ修正ができなくなった
・いちいち申請承認が必要で面倒になった

今まではスクラッチ開発したシステムを使っていました。ところが今回はパッケージシステムを導入します。

システムの動きが全く異なるため、ユーザーはとにかくストレスを感じている様子。Aさんにその不満の矛先が向いているようです。

「それは良かったですね～」

田村は笑顔でお答えしました。

パッケージの最も重要なメリット

今一度、整理したいのですが、パッケージのメリットは何でしょうか？

・低コスト
・短納期

はい、正解です。では、デメリットは何でしょうか？

・システムの自由度／柔軟性がない

はい、ここです。短絡的に考えるとその通りですが、本当にそれはデメリットなのでしょうか？

当社では、以下のように考えています。

パッケージの本当の魅力は、自由度／柔軟性がないこと。

なぜでしょうか？

外部からの大きな制約こそ、最も効果的な「標準化」に繋がるからです。

社内だけで「標準化」を検討してみると分かります。中途半端で小手先の「標準化」しかできません。ユーザーは自分たちでリスクを負わず、安全で、実現容易な変更案しか出してきません。

業務フローで言えば、枝葉の細かい部分だけです。

ところが、パッケージは違います。

業務フローの根幹を変える制約が押し付けられ、強烈なストレスが発生します。当然、ユーザーは猛反発しますが、そこはトップダウンで押し切る必要があります。

そこで初めて、大きな「標準化」に向かうのです。

自ら血を流して、痛みを伴いながら、大きな変革へと向かわざるを得なくなります

良いパッケージには「他社のベストプラクティス」が詰まっています。その黒船に乗って、「標準化」に向かって行くのです。
（ただし、悪いパッケージを選んでしまうと、話が違ってきます。この辺りは次回のコラムで書きます。）

裏を返せば、大幅なカスタマイズやスクラッチ開発を選択するということは、本当の意味での「標準化」を諦めること、とも言えます。

制約も使い方次第

事業戦略として、その事業は独自性が強く、競争力の源泉であれば、スクラッチ開発で作り込むべきでしょう。もっと言えば、内製化して、柔軟性とスピードを確保できる体制を構築すべきです。

一方で、属人化を解消し、業務の「標準化」を目指すのであれば、パッケージの「不自由さ」を利用すべきです。

身内だけだと大きな変革は難しいですが、外圧にさらされることで、大きな変革も可能となります。

貴社のIT部門／情報システム部門は、パッケージの「制約」をうまく活用できていますでしょうか？