著作権と自称「パッケージ」
「納入物の著作権の帰属」で、カスタムシステムは「たとえ一部であっても、そのままでは使えない」と書きましたが、モデル契約書ではパッケージ化のような、より積極的な使い方を想定しています。しかし、純然たる汎用モジュールのようなものを除けば、これにはベンダにとっても大きな危険が潜んでいます。
ベンダが同業他社向けに開発したシステムを「パッケージ」と称して安易に売り込み、ユーザも「機能が目に見える低廉なシステム」としてこれを受け入れた結果、開発が破綻する事例が後を絶ちません。理由は簡単です。こうしたシステムの開発では、カスタマイズがとどまるところなく続くからです。元が他社向けのカスタムシステムなのですから、当然と言えば当然です。ユーザが「パッケージ」を見て「これはいい」と言っても、頭の中にあるのは、自社向けにカスタマイズされた似ても似つかぬシステムです。ところが、その「パッケージ」の素晴らしさに自信を持っているベンダは、もう百里の途の九十九里まで来ていると思いがちです。結果、同床異夢の悲劇が生じます。
業務についてもシステムについても標準化を徹底し、拡張性を十分考慮した本来のパッケージですら、カスタマイズを入れた途端、カスタマイズが新たなカスタマイズを呼び、システムの安定性は大きく損なわれます（パラメータ設定するものは別にして）。元がカスタムシステムのパッケージでこれをやろうものなら、間違いなく稼働前に「サボテン化」します。
仕様のズレに伴う工数のズレも深刻です。全体で100のボリュームのあるシステムがあるとします。これをカスタムメイドでやる場合、工数は100、ズレがシステム全体の2割出たとすればズレは20、工数は2割増です。ところが、同じことが工数20のカスタマイズで起こるとすると、ズレの総量は同じく20であっても、工数倍増ということになります。システムの規模に比べて見込み工数が少ないが故の「レバレッジ効果」です。
そうだからといって、パッケージ化そのものが否定されるわけではありません。初めから複数の企業に使われることを想定して標準化や拡張性に十分配慮しておく、費用負担や秘密保持についてもきちんと考慮しておく、これらのことをユーザを交えて事前にやっておくことです。これは、ベンダとユーザとの共同事業に他なりません。要するに、この問題は、再利用などという後づけの問題では済まないのです。著作権の帰属は前提問題に過ぎないのです。