2005.07.26 Tuesday

ゴルフ場システム:料金体系と料金マスター

ゴルフ場の料金体系は年々複雑になってきています。
10年ほど前は会員料金とビジター料金、それの平日と土日祝というパターン
だけで済んでいたんですが、それに加え最近はセルフとキャディ付きのどちら
か、割引はどの割引を使うか・・・などなど。

また、ゴルフ場によってはビジター会員という「ビジターなのか、会員なのか
はっきりせぇ(笑)」というものを作り出して、より多くのビジター顧客の囲
い込みを行っている所も多いはずです。
しかし、一般の会員様とは明確に区別せねばならないため、区分はあくまでも
「ビジター」なんですけどね。

しかしもちろん会員になる以上は「特典」が必要になってきます。

「最近は特典がないとなかなかお客さんが来てくれなくって・・・」

とゴルフ場関係者がによくぼやかれることも少なくない昨今、このビジター会
員になればもちろん「特典」は付いてきますし、その多くは「グリーンフィの
値引き」ということで対応しています。つまり、ビジター会員用グリーンフィ
の出来上がりです。

そのようにして料金パターンは次々に増えていき、季節によっての変動も含め
て、ヒドいところになると料金のパターンが100近くになるところもありま
す。「だれか何とかしてくれ〜〜〜!」といった感じです(笑)。

さてこれだけ膨れあがった料金パターンはどのようにして管理しているのでし
ょうか?私どもでは現在、料金(セット品)マスターとして料金パターンをデ
ータ化しています。

料金マスターは料金コードをキーとして、

・料金コード
・料金名称
・親商品(パックなどの商品)
・子商品
・子商品の単価
・子商品の数量
・子商品を印刷する/しない
・子商品の税金区分
・使用不可フラグ(季節によって使用する・しないので)
・曜日(平日、土曜、日祝)
・セルフ or キャディ付き
・朝食/昼食付き

など商品を親子関係として関連づけた情報を持ったデータなのです。
しかしこれを管理(メンテ)するのは実はとても大変ですし、その当日、料金
パターンをお客様一人一人に付けていく、という作業も大変な労力です。

10年ほど前ならそれこそ何も設定しなくても(料金マスターなど無くても)
自動で料金計上ができたものです・・・(とほほ)。

しかし、管理に関してはそれだけの料金パターンがあるのでどうしようもない
ですが、料金付けに関してはより効率よい方法を考えなければなりません。
そのテクニックとして、料金を決めるために事前に登録できる情報はできるだ
け入れておき、プログラム側でその条件に合った最善のデータを引っ張ってく
る、というのが鉄則でしょうね。

事前(予約時か?)に設定しておける情報としては

・会員区分 (会員、ビジター、その他)
・セルフ or キャディ付き
・パック区分
・割引情報

となります。
あと曜日などは自動判断できるので、これらの条件をもとにできるだけ近い料
金を自動で引っ張ってこれれば、例外を除いては(これも良くあるようですが)
自動設定は可能になってくると思います。
2005.07.13 Wednesday

ゴルフ場システム −来場(チェックイン)処理−

現在の私どものシステムでも「タッチパネル&名前での検索」によるチェック
インシステムを行っていますが、これ方式は新システムでも踏襲していく事に
なると思います。

http://www.greensland.com/summary/raijo.html

やはりフロントに立ちながらコンピュータを操作というのはタッチパネルに勝
るものは無いですし、お客様が署名簿に書かれている名前を見ながら名前を検
索していく、と言うのも理にかなっていますよね。

来場処理では名前で検索後、そのお客様の情報を画面に表示してチェックイン
状態にさせます。
その手順は

お客様の名前をタッチ ---> ロッカー番号を入力

これだけです(笑)。

通常は次々と来る人に素早くロッカーキーを渡しつつチェックインを行ってい
かねばならないためこれだけの操作でチェックイン出来るというのはとても合
理的だと思われます。

別のシステムをこの前見てきましたがこの「名寄せによるチェックイン」が出
来ないシステムでした。そしてユーザーはそれを指して

「こんなチェックイン使われへんわ!」

と言ってましたね、確かにその通りです。

この処理で事務所もマスター室にもリアルタイムでチェックイン状態を知らせ
ることが出来ます。またキャディ控え室などにコンピュータを置いておき、キ
ャディさんがチェックイン状態を見ているゴルフ場も有ります。

その他来場画面で行うことは

・プレイヤーのキャンセル
・予約と違う人が来た時の名前変更マーク付け
・会員カードを使った簡易チェックイン
・コンペ番号などでの検索
・プレイヤー詳細の変更(名前、会員区分など)
・プレイヤーに対するメッセージの登録

などを行えればユーザーの希望は網羅出来るのではないでしょうか?


2005.07.13 Wednesday

ゴルフ場システム −予約リスト−

予約台帳は通常前日の夜に最新のものを出力しておき、当日の朝にフロントに
置きながら来場画面の補助として使うことが多いようです。
「補助」というのは

・来場画面で表示しきれない情報を帳票にて確認する
・一覧で全体が見渡せる
・その場ですぐに書き込み(チェックなど)を行える

などが多いようです。

しかし予約リストと言ってもいろんな種類があります。

・予約詳細リスト
・予約一覧表
・予約簡易リスト
・予約組数リスト
・予約五十音順リスト
・予約ロッカー番号順リスト
・予約拡大リスト
・予約状況表

なんでしょうか・・・似た名前ばっかりなのでどの帳票がどんな内容なのかさ
っぱり分かりませんよね(笑)。この名前は当初から私が考えて付けたのです
が、途中から「適当」になってしまいました(こら!)。

この中で先に述べた「予約リスト」と言っているのは主に「簡易リスト」の事
です。ただホテルと併設のゴルフ場などは書き込むスペースを大きくとらない
といけないため「予約詳細リスト」か「予約拡大リスト」などを使っているよ
うです。

ここでユーザーによく言われるのは

「出来るだけ1枚におさめて欲しい!」

ということ。
18ホールのホテル無しゴルフ場ならどんなにその日、組数が多くても、この
条件は死守しなければならないのです(笑)。

では予約リストの中身を検討しましょう。

通常はアウト・インに左右分かれた時間順に出力されます。で、各行の明細は
以下の内容が出力されています。

・予約時間
・コンペ名(予約名)
・コンペコード
・プレイヤー名
・会員番号
・会員区分
・料金番号
・ロッカー番号
・プランコード

などですが、はっきり言ってこれだけ全部は出力不可能です (^^;)
ですので出来るだけユーザーの欲しい情報をチョイスして出力してあげるのが
良いやり方だと思います。


2005.07.01 Friday

ダブルブッキングを防ぐために

予約のデータ更新は時間との戦いなのです。

一カ所で予約の電話を受けている、というゴルフ場に於いては比較的ダブルブ
ッキングなどということは起こらないかと思いますが、複数の場所で、同時に
予約画面を見ながら、リアルタイムで予約を取っていくときにはシステム上で
しっかりとした更新ロジックを考えておかないとダブルブッキングの可能性が
高くなる。

もちろんこれはプログラミングの基礎ともいえる話であるが、案外見過ごされ
ていたりまったく考えられていなかったりするものです。
そこで確認の意味を込めてその方法をまとめておきます。

まず予約関連のテーブルとして以下の3つが有ります。

1.予約テーブル

  予約の基礎となるテーブルで1つの予約に対して1行だけ存在します。
  予約番号を主キーとしており予約名称、代表者、会社名などの情報を持っ
  ています。

2.エントリーテーブル

  予約の日付、コース、時間、ポジションをキーとしており、予約が取られ
  ていく毎にここに予約番号や個人番号が設定されていきます。

3.個人情報テーブル

  予約情報にぶら下がっており、各個人毎の詳細データを保持しています。


この3つのテーブルのうちダブルブッキングの対象となるデータは2のエント
リーテーブルだけですね。
このテーブルの排他制御さえしっかりしていればダブルブッキングは完全に防
ぐことが出来ます。

ではその手順を説明しましょう

このエントリーテーブルはあらかじめ「時間枠テーブルメンテナンス」で1年
分ぐらい作成されているとします(既に有ることが前提)。

1.電話で日にち、コース。時間、組数を確認

2.予約画面にてそれらの時間帯をマークする

3.確定処理にて枠を押さえる

  この時点で既に他のところからマークされた枠を押さえられている可能性
  が有るので、それのチェックをしつつエントリーテーブルに「仮予約」の
  更新をかけていく。

  これをプログラム的に書くと

  (1) トランザクションスタート

  (2) マークされた枠エントリーデータを1件読む

  (3) データに仮予約フラグが立っていればその時点で予約は中断となり、
    トランザクションはキャンセル(Rollback)します。

    ※ここが特に重要です!!

  (4) エントリーデータに仮予約フラグを立てて更新

  (5) (2)から(4) をマークされた分だけ行う

  (6) トランザクションの終了(Commit)

  とこうなります。

  続いて

4.予約名称や代表者などの予約テーブル情報を入力します。

5.もしその場で聞けて入力も可能であれば個人データも入力します。


こう書いたらあまり難しいコトではないのですが上記の(3)のチェックを怠っ
たまま更新をかけてしまうと、完璧なダブルブッキングが発生します(笑)。
これは予約だけに限ったことではありませんが、こういう画面を見ながら人が
入力していく場合には画面の情報と実際のデータが食い違っている場合が多々
ありますので、このロジックは考慮に入れておくべきですね。

2005.07.01 Friday

ゴルフ場システム 予約管理(予約内容)

現在インターネットからの予約、と言う方法もありますが多くのゴルフ場では
「予約はまず電話で」だと思います。
その時にお客様から聞く内容を挙げてみたいと思います。

1.何日にプレイするのか?
2.どのコースからスタートするのか?
3.何時からプレイするのか?
4.何組でプレイするのか?
5.代表者のお名前は?

この5つがもっともコアとなる内容ですね。

この段階で聞けるものならメンバーの名前なども聞くこともありますし、多く
がFAXでメンバーとその組み合わせを送ってもらうのが一般的なようです。
組数だけ決まっていてメンバーはまだ未確定とか、メンバーの名字は知ってい
るが名前や漢字は知らない、など電話の段階では未確定な要素が多いのだと思
います。

そしてFAXにて送ってもらう内容としては

1.プレイヤーの名前
2.組み合わせ

などです。

最も基礎的な予約情報として上記のものが有りますが、その他ゴルフ場の運営
方法やプレイの方法によって次にあげる情報が必要だろうと思われます。

・キャディ 付ける/付けない
・自動カート 使う/使わない
・会社名
・コンペ名称
・コンペ計算 する/しない
・紹介会員
・ハンディキャップ
・予約金 有り/無し
・宿泊 有り/無し
・コンペ会食 有り/無し
・コンペ会食種類
・コンペ会食部屋
・プレイ料金種別(パックなど)
・電話番号
・FAX番号
・備考
・連絡事項
・メールアドレス(できれば)


最低はこれぐらいの情報が必要になってくるでしょう。

しかし現在のゴルフ場システム(Greensland Ver 2.0)ではこれだけのデータ
をすべて入れることが出来るのか?と問われればその答えは残念ながらノーで
す。
最初の設計段階でここまでの情報は要求されなかった、と言うのが最も大きな
要因ですが、要求されないのはつまり「台帳に記入すれば良い」という発想が
あったからに他なりません。

しかし、今度の新システムでは上記の要素はすべて盛り込まねばならないもの
たちばかりです。特にコンペの情報などはレストランが最も欲しいと思われる
情報ですし、連絡事項をこの時点で登録できていれば来場時のサービス向上に
繋げられるハズです。

またメールアドレスを何とか収集できれば、次期集客活動にメール配信システ
ムを使うことが出来る様になります。


2005.06.18 Saturday

手書きの予約台帳を残すか否か?

ことある毎にこの議論が噴出してくるのですが、実際お客さんによっても違う
し、その担当者によっても考え方がそれぞれ。
その議論の的が・・・

「手書きの予約台帳を残すか否か?」

なのです。これは別の言い方をすれば、電話を受けた時点でコンピュータに予
約情報を入れていくのか、それとも予約を受けた時点では入力せずに、台帳を
見て記入していくのか、どっち?ということになるのです。

僕自身は正直「予約台帳を残す」方でやって欲しいと思っているのですが、単
に希望だけを言っててもダメなので双方のメリットデメリットをあげてみたい
と思います。

1.台帳を残す予約

 ■メリット
 
  ・手書きなので名前などのメモが早い
  ・予約時点ではコンピュータが不要
  ・コンピュータが不要なのでシステムに慣れてない人でも予約可能
  ・コンピュータへの入力を複数人で同時に出来るし、空いてる時間に入力
   を行うことが出来る。


 ■デメリット
 
  ・複数人が同時に予約を受けたときに台帳の取り合いになる
  ・複数の予約場所(本社)などから予約が取れない(台帳がないから)
  ・他の部署から予約情報がリアルに分からない
  ・枠を移動するときやメンバーチェンジなどのが発生したときに大変


2.台帳を残さない予約

 ■メリット

  ・他の部署から予約状況がリアルタイムに分かる。
  ・台帳からの入力が無くなる(ムダな手間がかからない)

 ■デメリット
 
  ・予約を取る作業者のコンピュータスキルが要求される
  ・名前などの入力が「電話をかけながら」出来るとは思えない
  ・キャンセル履歴をきちんと取る必要がある


結論的に言えば「スキルが有れば」台帳を残さないやり方を推奨できるのであ
るが、どうしても全員にそれを要求するのは困難である、と考えています。
例えば新入社員だとか、別の部署の人だとか、支配人だとか(笑)が予約の電
話を受けたときに、コンピュータのみの予約システムで大丈夫か?という疑問
が残るんですね。

そこで最も良い案(折衷案)としては、予約台帳は残さない、その代わり「予
約メモ」と「キャンセルメモ」なるモノを作り、電話対応の時はコンピュータ
を参照しつつ、枠取りはコンピュータ上で行い、細かい内容はそのメモに記入
していく、というのがベストだと思います。

そうすれば、詳細まではコンピュータに入ってないが、いつ、何組の予約があ
るのもリアルタイムで分かるし、別の部署から予約を取ることも出来る。
詳細に関してはまとめて前日にでも入力していけば良い。

・・・と考えているのですが、先日、有るゴルフ場に行ったときに

「前のシステムではリアルタイムにお客さんの名前を入れていて、そちらの方
 が効率が良かった」

と言う意見もあった、そんなシステムと、入力できる人を見てみたい。

2005.06.18 Saturday

ゴルフ場システム 予約管理(予約枠)

予約を語るには、まず予約枠から入る必要が有ります。

まずこの「予約枠」に関するシステム要件をあげてみます。

・8時ぐらいから始まる6分または7分間隔である

  「8時ぐらい」とスタート時間も季節によって変わってきますし、その間
  隔もキャディをつけた時とセルフの時では時間のかかる間隔が大いに違っ
  てきたりします。

・季節などによってこの枠は変更できなければならない

  時間枠は特に季節によって変わってきますので、システム側も時間枠を自
  由に設定できるような機能が必要です。
  
  ※現在は一日ごとに時間枠を設定し、その設定したデータを他の日にコピー
   する、という形を取っています。

・割り込みでこの時間間隔が崩れる場合がある

  緊急で大事なお客様の予約が入ってきた、しかし希望の時間は既に埋まっ
  ている・・・・などの時に例えば9:30と9:37分の間に9:34分という枠を作
  り、割り込みのお客様を入れ込む、という機能は必要になってきます。
  
  ※ただ、同一時間が二つ、と言うのはマズいですからあくまでも違う時間
   で設定します。

・一つの枠には最高4人までだが、予約のグループ(予約単位)としては最高
 4グループ入る可能性がある(個人予約が4つ)

  良くあるのが二人二人のペアが一つの組(4人)でコースをまわる場合、
  予約の単位(予約番号)は別々になります。

・ワンウェイ(スルー)の枠が作れなければならない

  北海道のゴルフ場は必須ですが、それ以外でもある時期だけこの方式で枠
  取りする、なんて事は良くあります。
  この場合、午前中と午後の予約の間に何時間かの「空き」が発生します。

・予約されていた時間を移動できなければならない

  有る時間に既に予約されており、その後大きなコンペが入ってきたので、
  どうしてもその枠を動かさねばならない(もちろんお客さんの承認を取っ
  て)時があります。その場合「枠の移動」という操作が必要になってきま
  す。

  ※1つの予約枠の中に複数の予約番号が存在しますので「枠を丸ごと移動」
   ではなく、この枠の、この予約番号の人たちを移動する、といった感じ
   になるでしょうね。

・インターネットなどからの予約枠が必要

  最近増えてきたのがインターネットからユーザー自身が予約する、と言う
  もの(GORA楽天など)。これはリアルタイムに予約データを読み書きする
  ものではないので、あらかじめ「インターネット枠」なるモノを用意して
  おいて、その枠内でなら自由に予約を取れるようにしておく必要がある。

・調整枠なども必要

  ゴルフ経験のある人、無い人とではそのまわる速度に大きな差が現れてき
  ます。おっかけそれは時間間隔に影響が出てきて9:40分スタートの人が時
  がきてもスタートできない、と言う状況になってしまいます。
  そんな時のために「予約できない枠」つまり調整枠を設けて時間の遅れを
  吸収出来るようにするわけです。

・早朝、薄暮の予約枠が必要

  夏になると日没が遅くなりますので、夕方に来てハーフだけまわる、なん
  て事も出来るようになります。
  よって、予約システム側も夕方3時ぐらいからの予約が取れるようにして
  おかなければなりません。

・キャンセル待ちも必要

  どうしても予約が取れないとき、そしてそのお客さんが、その日じゃない
  と回れないという時、キャンセル待ちにその方の情報を入れておく必要が
  あります。


以上予約枠に関してこれだけの要件があり、システム側ではこの要件を満たせ
ていけるような予約システムを作り上げていく必要が有るんですね。。
結構大変なんです、はい。


2005.06.10 Friday

カスタマイズに耐えるシステム(オプション)

カスタマイズ、というか各ユーザーによって細かい追加要望が出ることが良く
あります。
例えば、
「クラブを宅急便で送り、それが届いているかどうか、という状況が知りたい」
など現場にいないと決して気付かない情報がとても重要だったりします。

これもあるゴルフ場でのみ言われたことなのですが、別のゴルフ場ではそんな
情報は「コンピュータ内の情報としては要らない」または「コンピュータに入
力するのは嫌」ということもあり得るはずです。

そういう場合プログラムサイドではその情報を「オプション」という扱いにし
て、このオプションをつけておくと「宅急便区分」が表示(入力)され、つけ
てないと画面に出てこない、というようにするのが望ましいでしょう。


ではオプションはどうやってプログラムに与えるのでしょうか?

1.プログラムのコマンド引数として与える。

  「YYD_0010.exe -T -K」 などの様にプログラムを起動する際に渡してあげ
  ます。そして C# のプログラムでは

  public static void Main(string[] args)
  
  の argsのなかにこの引数が渡されプログラム内で

  if (args[0]=="-T") PrmTakkyuBinFlg = true;

  などとしてオプションを変数に格納して、以後その変数を参照することに
  よって宅急便区分を見せる・見せないの判断をするのです。
  
  checkTakkyubin.Visible = PrmTakkyuBinFlg;

2.iniファイルにオプションを定義する

  実は .NET の世界では iniファイルの存在は抹消されました。
  つまりGetPrivateProfileString, WritePrivateProfileStringなどのiniフ
  ァイルへアクセスするための関数なりクラスが無くなったのです。
  (アンマネージコードとしてGetPrivateProfileStringは使えます)

  その代わり .NET では「動的プロパティ」という概念が加わりました。
  
  http://ukamen.hp.infoseek.co.jp/Programming1/DynamicProperty/index.htm

  でもテキストエディターで簡単に編集できて分かりやすいiniファイルはや
  はり管理側としても、プログラム側としても使いやすいものです。
  ですので「Greensland.NET」もiniファイルをオプション用のファイルとし
  て使い続けることにします。

  例えば先ほどの「宅急便区分」を定義するとしたら
  
  [System]
  TakkyuBinFlag=1
  
  などと定義しておき

  IniTakkyuBinFlg = (Ini.GetString("System","TakkyuBInFlag")=="1")

  で変数に格納することが出来ます。

  また使用するときは

  checkTakkyubin.Visible = IniTakkyuBinFlg;  の様にします。


さて、ではシステムではどちらのオプション定義を使えばよいのでしょうか?

基準を設けるとしたら

・コマンドラインオプション ... そのプログラムだけで使うオプション

  例) -K? ... 領収書に金種を印刷するか 0:しない 1:する

・ini ファイルオプション  ... 複数プログラムで使用するオプション

  例) SH_TAX=5      ... 消費税率(%)

と考えれば良いでしょう。


2005.06.10 Friday

ゴルフ場システム システムの導入(ユーザー教育)

導入時には「エンドユーザーの教育」を何日かに渡って行います。通常はエン
トリー(予約係)に始まりフロントやマスター室などを経て、事務所での締め
処理などを行う人たち(おそらくフロントの人)が教育の締めになります。

わたしがこの教育において切に願うことは「全員参加して欲しい」と言うこと
と「営業時間外に時間を確保して欲しい」という2点です。

・全員参加して欲しい

  あるゴルフ場ではフロントの責任者だけが一人で説明を聞く、ということ
  が有りました。その責任者はシステムも良く理解しているし、コンピュー
  タにも弱くはない人でしたのでこちらの教育もホントに楽に済みました。
  そしてその人が退社した、と聞いたのは退社した2ヶ月後のこと。
  一見システムは何事もなく動いているかのようでしたが、現場の声を聞い
  てみるとシステムを理解してない人がなんと多いことか・・・
  
  その担当者は確かに優秀でしたが、その人から教えられた人たちは、無条
  件に担当者の意見を正として受け容れることしかできず、出来ること、出
  来ないことがただ一人の担当者の考えに左右されてしまっていたのでした。
  またそれは「伝言ゲーム」のように、伝えられるたびにどこかで変化して
  しまったり、欠けてしまったり、そんな状態になっていたのです。

  そんな状態でこちらに聞こえてくるのが「このシステムは難しい」とか、
  逆に「こんなことも出来ないのか?」とかの不満ばかり・・・

  最初から、わたしの説明を受けてさえいればシステムの考え方、処理のバ
  リエーション、イレギュラーの対応、応用処理などが分かってもらえたん
  じゃないかと、思っています。


・営業時間外に時間を確保して欲しい

  営業時間内に「教育」をすると途中で割り込みが入って抜けられてしまう
  ことが多いです。もちろん営業時間外に教育をするとなると残業代の問題
  や早く帰りたい人などもいるので難しいこともあります。
  
  しかし、「全員参加」をして欲しいのと「割り込みが入って中断」しない
  ことを実現するにはやはり営業時間外に時間を確保してもらうのがベスト
  だと思います。
  
  ただこちらから「営業時間外じゃないと教育しないぞ!」なんて言えるわ
  けないんで(笑)、極力担当者を説得しつつ時間外に持っていく努力をす
  べきですね。

私たち開発者が導入時に行う指導というのは、担当者からの引き継ぎなどと比
べて、その中身は濃く、深く、とても有意義なものです。出産後最初に出る母
乳(初乳)のようなもので、これを聞くのと、聞かないのとではシステムへの
取組み、考え方が大いに違ってくる、と考えています。

2005.05.30 Monday

カスタマイズに耐えるシステム(1)

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

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

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

このメリットは

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

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

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

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

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

1.画面の変更

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

  内容は・・・

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


2.帳票の変更

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

  内容は・・・

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


3.データベースの変更

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

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

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

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

Calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< October 2019 >>
**
会社概要
profilephoto
大阪のソフトウェア開発会社です。 主に物流関係やゴルフ場のソフトを作っています。 http://www.kabel.jp
Facebookページ
Selected Entries
Categories
Archives
Recent Comment
Recent Trackback
Links
Profile
Search this site.
Others
Mobile
qrcode
Powered by
30days Album
無料ブログ作成サービス JUGEM