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

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

　購入時には標準機能をベースにプロジェクトのスケジュールが立てられているので、カスタマイズの作業が増えた分、当然納期が当初の予定より遅れることになります。

　作業が増えれば、追加の投資が必要になるか、もともと予定していた作業を削って予算内に収める必要が出てきます。前例のないカスタマイズだと、想定外の不具合が起きる確率も高まるでしょう。不具合が出れば、その調査や改修に時間がかかり、結果スケジュールに影響することになります。

　また、「どこをカスタマイズするか（しないか）」という議論に多くの時間が費やされることも見落としがちなポイントです。それもスケジュールの遅延につながり、結果、「一から開発しなくていいから、やりたいことを早期に実現できる」というパッケージソフトウェア最大の利点が実現できず、まるで“バベルの塔”のようにいつまでたってもシステムが完成しない「地獄」が待っています。

　そして、カスタマイズを重ねた末、ようやくリリースにこぎつけても、ユーザーの「これ使えないじゃん」の一言でお蔵入りしてしまったら目も当てられません。しかし、実際にそういったケースがあるのです。

パッケージソフトウェアのカスタマイズで失敗してしまう理由

自分たちの“都合”でカスタマイズしてはいけない

　使いやすいようにとカスタマイズしたのに、どうしてこんなことになってしまうのか――。それは“誰にとって”使いやすいかという視点が欠けていたためでしょう。

　RFP（提案要請書）は企画担当が作成して、導入は主管部門が担当、実際に運用や利用をするのは別の部門……と各フェーズで関係者が異なるのはよくある話ですが、主管部門が導入の際に自分たちの視点でカスタマイズしてしまうことで、ユーザーの利便性を損ねたり、そもそも考慮されていないといった“抜け”が生じることがあります。

　先に挙げた例なら、「どういったサービスをユーザー（社内顧客）に提供して、会社として効果をもたらせるか」というのが、最も重要な視点なのですが、主管部門の主業務が基盤管理であった場合、ユーザーにとってのクラウドサービスではなく、仮想化基盤の管理を楽にするという視点でカスタマイズを重ねてしまう可能性があります。

　クラウドサービス提供のためのパッケージソフトウェアは、仮想化基盤の管理製品ではありません。そうなると、当然カスタマイズが必要になります。結果、「従来とできることは何も変わらない、むしろ管理対象が増えて運用側も大変」ということで、結局使われず“塩漬け”になってしまうのです。