なぜ、パッケージソフトの「カスタマイズ」で失敗してしまうのか？：失敗しない「外資系」パッケージソフトとの付き合い方（1/3 ページ）

外資系パッケージソフトの導入で失敗しないための方法を解説する本連載。今回からはソフトウェア選定後、実際に導入を進める上で陥りやすい落とし穴を紹介していく。まずは、失敗例が本当に多い「カスタマイズ」問題を取り上げる。

[吉丸新一郎（日本ヒューレット・パッカード），ITmedia]

パッケージソフトのカスタマイズで失敗した例を挙げると、キリがありません

　「パッケージソフトは、できるだけカスタマイズしないのが導入成功の秘訣」

　読者の皆さんは、こんな言葉を一度は耳にしたことがあると思います。しかし、それでもカスタマイズをして失敗するケースも山ほどあるのが現実です。

　「うちは標準機能が使えればいいんですよ、その道のベストプラクティスが実装されているんでしょう？」「早期に導入する必要があるので、標準機能をメインにしてできるだけカスタマイズしないようにしましょう」

　これらは製品選定のときや、導入プロジェクトの進め方を議論する際によく耳にする言葉です。スクラッチ開発ではなく、パッケージソフトウェアを選んだということは、「実現したい機能が利用できる点を評価した」ということであり、自然かつ正しい考えだと思います。

　ところが、プロジェクトを進めていくと「ここは標準機能ではなくて、〇〇できませんか？」という話が必ずと言っていいほど出てきます。「うちのやり方とは違う」「それだとわれわれが困るからこうしてくれ」など、その理由はさまざまですが、大体は特定の人や部門の視点のみで事象を語っているケースが多いように思います。

失敗事例5：導入時にカスタマイズしすぎて“使い物にならない”

　1つ具体的な例を挙げてみましょう。

　製造業の大手A社ではプライベートクラウド基盤導入プロジェクトが進んでおり、A社の担当者とベンダーB社がクラウドサービスとして実現したいことを議論していました。最初は標準機能をベースに実装する予定だったのですが、話が進むと、カスタマイズしてほしいという依頼が増えていきます。

A社：すみません。こちらの機能ですが、X事業部の部長から「これだと仕事にならない」とクレームが入ってしまって……。カスタマイズでどうにかならないでしょうか？

B社：そうですか……。もちろん、技術的には可能ですが、製品のコンセプトや導入の目的から外れていませんかね？

A社：それは分かっています。ただ、X事業部のクレームで導入プロジェクトそのものが止まってしまいそうでして……、この点だけはどうにかしたいのです。

B社：分かりました。では、この機能については、標準機能からカスタマイズするということで進めることにします。具体的な要件を教えてください。

　さて、このプロジェクトが進んでいくと、一体何が起きるでしょうか？