パッケージソフトの問題
ところで最近になって、１９９０年代末に導入したパッケージソフトの問題が顕在化してきた。スイッチやルーター、サーバーの監視程度の単純なものならば問題ないが、サービスオーダー管理、故障管理、料金管理などにおいては、サービスの拡大に伴う業務量の増加、運用体制の合理化のための機能追加、サービスの高度化に伴う機能追加に際し、パッケージが元々持っている機能では対応が困難となり、性能の限界も目立つケースが出てきた。機能追加開発部分に殆どパッケージの機能が使えずアドオンになってしまったり、パッケージ製品の開発環境や言語の制約に加えて、そのパッケージを扱えるソフト会社が限られていることなどから、開発期間やコストの問題が顕在化してきたものもある。
また、特に欧米のベンダーではM&Aが繰り返されて、製品のオーナーが変わり、十分な機能アップ・性能アップあるいは最新バージョンのOSやミドルウェアへの追従が遅れたり、英語環境には追従しても日本語環境の追従が遅れるという問題も出てきた。 別のケースでは、初期導入コストは安いように見えたが、需要の増加に従ってほぼリニアにライセンス料金が増加するために、スクラッチで開発するほうが結果的に安くて柔軟と思えるものもあった。２００１年当時に有名だったビリングの製品は、数年で相次いで外され、最新Java技術とフレームワークで置き換えられた。
これだけ問題を書くと誤解されそうであるが、私はパッケージが全然ダメとか嫌いとか言っているわけではない。短期間で新しいサービスを立ち上げるにはパッケージの採用は必須条件であり、我々は現在でもその選択肢を常に持っている。サービスの成否が不明な場合にはパッケージで即スモールスタートすれば、万が一サービスが外れた場合でも最小のダメージで済ますことができるし、グローバルなサービス対応機能を安価に手に入れることもできる。
ただし、サービスが成功して需要が急増した場合には数年でOpSを作り直す、あるいは将来プラットフォーム（ハードウェアやＯＳ）を更改する際にはパッケージ依存のソフトウェア資産の継承ができない可能性があることを前提に計画しておく必要があるということである。すなわち要求条件とＩＴ戦略を明確にした上で、パッケージ採否を含めた開発方針を決めることが重要ということである。
