カスタマイズ・・・これはパッケージを売る者にとっては諸刃の刃となるもの
でしょう。
たとえば「弥生会計」などのように各ユーザーのためにカスタマイズなどしな
いパッケージで有ればいわば「この機能だけで使え」的な感じで売ることも出
来るし、その分、自ずと値段も下がることになる。

しかしゴルフ場のシステムなどは基本的には「カスタマイズ前提」のシステム
がほとんどであり、ユーザー側もカスタマイズを当たり前として考えている。
よって、「カスタマイズ料金」なるものを請求できるし、あらかじめパッケー
ジ料金の中に含めておいてもさほど値高感はないわけです。

さて、システム的にはこのカスタマイズを前提にしているゆえ、各ゴルフ場毎
にフォルダーを分けて（もちろんソースも）切り分けを行う方法がありますが
今回の「Greensland.NET」では各ゴルフ場毎にフォルダー分けをしないで一つ
のソースを複数ユーザーに対応させる方法を取ろうと思っています。

このメリットは

・バグがあったときに複数のソースをさわらなくても良い。
・大幅な仕様改訂（消費税、ハンディキャップ）が有ったときに、各ゴルフ場
　毎に同じ変更を加えなくても良い。
・バージョン管理が一元化できる。
・バージョンアップを既存のお客様に適用できる。

などがある。逆にデメリットは

・ソースに条件が増えてきて、いびつなロジックになる。
・オプションが増えてきて、管理しづらくなる。
・あるお客さんには不要なバージョンアップが適用される可能性がある。

などです。ただ私の経験上、メリットのほうが大きいので、なんとかソース一
元化方式でいきたいと思います。

ではカスタマイズによってどんなシステム変更が行われるのだろうか？

１．画面の変更

　　例えば最近はキャディの数を減らして、セルフでプレーを行うゴルフ場が
　　多い。いままでは「キャディが前提」で作られていたシステムにセルフの
　　お客様と分かるようにセルフ区分を設けて欲しい、などがある。

　　内容は・・・

　　・表示・入力項目の追加
　　・表示・入力項目の長さの変更
　　・表示・入力項目の非表示（この項目を出さないで、と言われる）
　　・新たな画面の追加

２．帳票の変更

　　例えば「うちは料金パターンが多いから、『来場者一覧』に料金コードと
　　金額を出して欲しい」なんていう要求もありました。

　　内容は・・・

　　・印刷項目の追加
　　・印刷項目の長さの変更
　　・印刷項目の非表示（この項目を出さないで、と言われる）
　　・新たな帳票の追加

３．データベースの変更

　　上記変更にともないデータベースに新たに項目を追加したり、データ項目
　　のサイズを変更したりしなければならない。

これ以外にバッチファイルの変更なども含まれます。

実際にプログラム上はどのようにその違いを吸収すればよいのでしょうか？

長くなりましたので、それは次回にとっておきます（笑）。