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

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

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

このメリットは

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

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

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

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

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

１．画面の変更

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

　　内容は・・・

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

２．帳票の変更

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

　　内容は・・・

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

３．データベースの変更

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

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

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

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

システムの導入時、それはおそらく機械（PCやプリンター）のセットアップも
含まれるので、約４～５日前から現場には入ることにしている。
もちろん機械の台数が多かったり、新しいモノのテストをしなければならなか
ったり（ＰＢＸや構内モデムなど）するときはもうちょっと早くから入ってい
ます。

現場に入ってから行うこと言えば

１．機械のセットアップ

　　・ＰＣやプリンターの設置
　　・ＰＣのセットアップ（O/S、ドライバー、ソフトの導入・設定）
　　・プリンターの印字テスト

２．オペレーション指導

　　・ＰＣの使い方やゴルフ場システムの教育

３．最終仕様確認

　　・仕様変更分や不足分を担当者と確認
　　・不足分は随時修正・追加を行う

４．データのコンバート＆セットアップ

　　・会員マスターのコンバート
　　・商品マスターのコンバート＆設定
　　・料金マスターの作成
　　・コードマスターの作成
　　・ハンディキャップデータのコンバート

などですね。
この４～５日というのは全く休む間もなく、それこそ分単位、秒単位でスケジ
ュールを刻んでいかないと「時間が足りなかった」では決してすまされないこ
とが多いのです。

また機械の不良や、思っていたケーブルと違うケーブルじゃないと繋がらない、
なんてことは実は決して珍しいことではないので、有る程度の「覚悟」を決め
てから、出来るだけの準備をして現場に望まなければならないのです。

すべてのハードを自社のほうに送ってもらって、すべてこちらでテストしてか
ら現場へ送る、なんてことをやっていると開梱、梱包、設置だけですんごい手
間がかかってしまい、結局２度手間になるわけだし、そんな沢山の機械を置く
スペースなんかどこに有るん？という悲しい現実もあるのです。

ただ余程のことがない限り「致命的な」トラブルにはならないので、もし何か
有れば近くの○○電気まで買いに行く、なんてことで十分だと思います。

・・・さてこの作業の中で何に一番時間を取られるかわかりますか？

実は商品マスターのコンバート＆設定なのです。

「そんなの事前にデータもらってテストできるでしょう？」
と考えられるかもしれない。もちろんそうなのです、現在のデータはCSVファイ
ルなどで頂いて、こちらのデータフォーマットに変換する、なんて事は確かに
事前に行うことが出来ます。

しかし、、、商品マスターというのは商品コードと商品名が有るだけじゃなく
営業日報や売上日報、はてまた月次帳票を出すための区分や分類を整理して入
力しなければならないし、タッチパネルの出力ページや位置をユーザーの意志
に基づきながら設定して行かねばなりません（これがなかなか決まらない）。

また、パック商品やセット商品の新たな作成も必要になってきますし、それに
伴う消費税やサービス料の計算（消費税込み１万円ぽっきりなんてあるし・・・）
などもしなければならなくなる。

「そんなもんユーザーに入れてもらったら？」

と聞かれることが多い。確かにそれも正しい意見である。でもユーザーに任せ
てちゃんと時間通りに出来たためしが無いのです、とほほ・・・。
「いやぁ、まだなんですわぁ・・・」と言われるとこちらとしてはどうしよう
も無くなるのです。

また「システムを入れ替えるのであれば・・・」と商品を大幅に変える、とい
うことも大いにあり得ること。こうなってしまえば商品の内容や商品単価の決
定すらもいつになるか分からなくなるし、その上「商品名をコンピュータへ入
力して下さい」なんて、ほんといつになるか分からないのです。

先ほど言ったように商品マスターはいろんな帳票のキーになるようなデータな
のです。このデータが無いと「本当のデータでテストすることが出来ない」わ
けなのです。また、ユーザーから見れば「本当のデータを見ないとイメージが
わかない」なんて事をいわれかねないので、商品マスターの早期の設定という
のはテスト・導入を進める上で重要な鍵となるのです。

若い女性に大きく開けた口の中を覗かれて、金属の先っちょで
歯と歯茎の間をグリグリされて

「歯垢がたまってますねぇ・・・」

なんて事言われて、この誇り高きプライドはズタズタになり、
理性も感性も捨て去って「僕をイヌと呼んで下さい！」なんて
言いたくなる気持ちをやっとの思いでとどめていた僕であった。

がしかし、そんな僕に追い打ちをかけるように先生がやってき
て、ウィーンと鳴る機械にスイッチを入れたかと思うと

「バキュームお願いしま～～す」

と叫ぶのであった。
バキューム・・・それは歯を削る機械の先端から出る水を
ノドにたまらないように吸い込んでくれる機械のことである。

しかし僕はこの「バキューム」という言葉に戦慄を憶えるのだ。

削るのは、、、よい。たいして痛くはないし、その機械音だって
しばらくすると「苦痛な音」から心地よい「福音のメロディ」にも
感じられてくるからだ。

しかし、この削る機械から出てくる水だけは堪忍して欲しいのだ。
なぜなら僕は鼻が詰まっていて口からしか息が吸えないのだ。。

といってもいつも詰まっているわけではない。普通に座ってい
るときや、立っているときなどは少し詰まり気味ながらも鼻か
ら息は出来る。
しかし、歯の治療時には１８０度身体は倒され、その時点で９０％
の鼻づまりになるのだが、口をガッと開けて手を突っ込まれた
時点で鼻詰まり度は１００％を越えてしまうのだ。

そんな状態に水がドンドン流し込まれ唯一の空気の通り道である
口が塞がれてしまい、いくら深呼吸していたとしても、とうていまか
ないきれないぐらいの空気を必要とするのだ。

でもバキュームがあるんでしょ？と思われるかもしれませんが
ノドの奥底にたまっている水までは吸い取ることが出来ず、
その水は勇気を出して水を飲み込むことによってはじめて空気が
流れ込んで来るのであった。

しかし、その水を吸い込むタイミングが悪ければ、つまりコンマ１ミリ
の単位で先生が歯の処理をしているときに「うんぐっ！」と飲み込
みを行えば、その手元が狂いその機械の先端が歯茎にぐさっと
刺さるかもしれないのだ！

いやはや、こんな恐怖、普通の人には分からんやろなぁ・・・・

僕ら花粉症族にとって「バキュームお願いします」の言葉は、
死との戦いなのだ。

Ｃ＃ではフォームの継承というのが出来ます。
各アプリケーションフォームにて必ずしなければならないが、それぞれにコー
ディングするのは面倒くさく、効率的でない・・・そんな処理をベースとなる
フォームクラスに記述しておき、アプリケーションではそのベースフォームを
継承することによって余計なコードが不要になり、かつどのアプリケーション
も統一的な動きが実現できるのです。

例えばベースフォームで行われる機能としては、

１．フォームに貼り付いているコンポーネントの初期化

　　TextBoxのLength、ImeMode、Text、Fontなどのプロパティを再設定する

２．Enterキーが押されれば次のフィールドに飛ぶ

　　※Enterキー押下時のビープ音なども消しておきます。

３．ファンクションキーボタンを画面に表示させる

　　やはり業務では「ファンクションキーを使う」というのは必須なんですね
　　入力完了後「いちいちマウスでクリックさせる」なんてユーザーから嵐の
　　ようなクレームが来ますから・・・・

４．ファンクションキーボタンとキーのイベントを同期させる

　　ボタンの処理とキー押下の処理を出来るだけ同じイベントで、という配慮
　　です。つまり「F1」キーが押されたときに「F1ボタン」をクリックされた
　　かのようにイベントを発生させるわけです。

５．エラーメッセージ画面の処理

６．コントロールのインデックス化ルーチン

　　VBから来た人たちからクレームが来そうなのはここ、コントロールにイン
　　デックスが無い、ということでしょう。この問題はこの様なルーチンを作
　　っておくことで簡単に解消できます。

７．画面のハードコピー

　　ユーザーからの要求で多いのが「いまの画面のハードコピーを取りたい」
　　というものですね。なので最初から入れ込んどきましょう。

８．画面ヘッダー部（ロゴ、時間などの表示）をさせる

　　「Greensland.NET」のカッコいいロゴを作ったので上部に常に表示（笑）

などなど

実はまだまだあるのだが説明が長くなるので省略。。

フォームの継承は処理の効率化だけでなく、画面デザインの共通化などでも是
非必要なものです。KCBaseForm.csをよく読んどきましょう（身内へ）。

私はよくゴルフ場の現場の人にこんなコトを言われる。

「それって本社が言うてたんやろ？」

ここで言う「それ」とは現場の人にとっては「とてもめんどくさいコト」と表
現すればいいだろうか。例えば通常の運用には必要のないデータを入力させら
れるとか、本社へデータを送るために余計な作業が必要になるだとか・・・
そしてその発言は「それ」をさせられる羽目になった事への多少の怒りがこも
っていたりするのです。

しかし本社では来場している客層を掴むために

・どんな年齢の人か？
・性別の割合は？
・どんなプランの商品が売れているか？
・どれぐらいの値段なら来場者数は増えるか？
・どの地域からよく来ているか？
・会員さんはどの種別の人がよく来るか？
・会員が何人同伴を連れてきたか？
・ビジターの割合は？
・平日で来場が多い曜日は？
・セルフの来場数は？
・レストランの売れ筋商品は？

ゴルフ場とすればこれぐらいのデータは営業の資料として必要となると思われ
る。本社ではこれらのデータを集計し、分析して新しい商品や営業展開を練っ
たりしたいわけです。

ただ、これらのデータを得るには少なくともこれらのデータを集計出来るだけ
のインプット作業が必要になるわけです。例えば会員さんなら問題ないが、ビ
ジターの年齢を得るにはチェックイン時、もしくは精算時にそれらのデータを
入力せねばならない、とか、どの地域の来場者が多いなどというのも署名簿を
見ながら人数を集計して行かねばならず、これまた現場の負担になるのです。

つまり現場としては「こっちに負担ばかりかけやがって！」なんて発想が出て
くるのである。確かにそれは大いに言えることで実際それらのデータを集計す
るだけして「本当に集客に役立っているのか？」という疑問もあるわけです。

つまり

「集計して、それを眺めて、『う～ん』とうなって、それで終わり・・・」

何てコトになりかねない。
何故なら本社からでは現場のことが見えてないので働いている人たちがどんな
「動き」をしているのか分からないし、、直接お客さんと接するわけではない
のでお客さんがどんなことを「要望」しているのかも知るよしがない。
また、現場ではこれらのデータを入力するだけの人数も揃っていないのが現状
なので本社から「必要！」といわれても「無理！」と答えるしかない悲しい現
実があるのも確かである。

私が常々考えているのは「アイデアはお客さんが運んでくる」と考えています。
作っている我々よりも、使っているお客さんの方が「より使いやすさ」を追求
するだろうし、そのためにあらゆる工夫を凝らそうとするからなのです。

例えば「魅力のあるゴルフ場」を考えた時にまず第一にコース、第二に従業員
の対応の良さ（サービス含む）、第三に美味しい食事が出てくること・・・
ぐらいですかね。まぁ「値段」というのをこの中に入れても良いんですが、ち
ょっと侘びしくなるんで省きました（笑）。

確かに私の立場としては「本社のやりたいこと」はよく分かるし、推進もして
いきたいし、それで集客に結びつくような「手」を打てたらと常々考えている
のですが、現場の負担を見ていると「それよりもねぇ・・・」と思わず現場よ
りに考えてしまうのですね。

ゴルフ場とはコンビニなどと違い「商品」自体は限られています。その中でい
かに他ゴルフ場と差別化していくか、魅力的な商品を作れるか、効率的な販促
をしていけるか、それを常に考えているゴルフ場が勝ち残っていくんでしょう
ね。

７万円もした差し歯、いったい何年もっただろうか・・・

逆算して計算してみると７～８年と言ったとこだろうか。
とすれば１年につき約１万円也、となるわけでこれが
安いか高いか不明ですが、こう何回もはずれたりつ
けたりするんだったら保険の利く安いのにしとくべき
だったと反省です。

しかもヤブ医者に７万も払ったという屈辱感付き。

そこで治療方法は決まった。その歯を捨てちゃって
その一つ奥の歯と合体させて頑丈にする、と言う方針
でした。

いままで「飾り」でしかなかったその糸切り歯がこれで
思い切って肉をかみ切ることが出来るようになるわけだ。
こんなに嬉しいことはない。

今までは抜けるのを心配して堅いものは左側の歯に
移動してモグモグしていたわけであるが、合体すると
そんな遠慮は要らなくなるのだ、ばんざ～い！

それからは女性陣が僕の顔の真上からいろんな事を
仕掛けてくる。
ある女性は「型を取りますね」といって粘土みたいなも
のをぐいぐい口の中に入れてくるし、また有る女性は
「ちょっと削りますね」といってはウィ～ンとなる機械で
不要な歯を削って行くし、極めつけは「鏡をもって下さい」
とやって来る女性である。

そして鏡をもって自分の歯を見るように言われる。
でもはっきり言ってこの時の自分の顔ほど情けない
ものはない。

「ほら、こんなとこに歯垢がたまってるんですよ～」

なんて言われるわけだが、こちらは口をあんぐり開けて
いるワケなのでまともに返事も出来ず、その歯垢と
マヌケな顔を見ながら「はい」にならない「んがい」
などと返事をするしかない。

若いねぇちゃんに口の中を見られて、変な顔までさせ
られて、「もうどうにでもしてくれー」という気分になる
のは僕だけだろうか・・・・。

今日、朝の１０時から歯医者に行ってきた。

７年前に入れた差し歯がどうも医者の腕がヘタだったらしく
２～３年ごとにポロリと取れて、その都度さし直してもらいに
いく、その恒例の行事みたいなものである。

ちなみにその時の医者は今の医者ではない。つまり今の
医者はその時の医者の尻ぬぐいをさせられているようなも
のなんだな。

今回のはじめの診察は先々週の金曜日だったか・・・
その歯がポロリと取れてから既に一ヶ月以上も放置された
状態であり、こちらも抜けた状態で（糸切り歯ね）でもさほど
不自由はなく、しいて言えばニコッと笑うと、その抜けた歯が
筒抜けになりマヌケ面に見えてしまい事ぐらいである。

もうこのまま放っとこうか・・・なんて思っていたのであるが
この歳でまだマヌケに見えてしまっても悲しすぎるので、
一念発起してやはり行くことにした。
手にはティッシュに包まれた差し歯を持って・・・・。

そして先々週の金曜日、２年ぶりぐらいでその歯医者を訪ねた。

設備は一新しており、診察台から歯科器具からおねぇちゃ
んたちまで、それはそれは綺麗になっており、歯のレントゲン
写真も横に設置されているパソコンで撮って直ぐに見れるよう
になっていたりしたのだ。すごっ！

先生は一秒も休むことなく４つある診察台を次から次へと
蝶のように飛び回っているのだけは相変わらずで、よく喋り、
よく動き、よく働く、とっても良い先生なのです。

僕はそこでその差し歯をさしだし「また抜けたんですわ・・・」
と報告した。先生もいつものことなので、その歯を受け取って
スポッと空いた穴にそれを差し込んだ。
そしてこう言ったのだ。

「この歯は、もうぐらぐらして使えないですねー」

７万円もした差し歯は、この時命の終焉を告げられたのであった・・・。

この週末（土日含めて）は完全にPHPに支配されてました。
おかげでメルマガの発行予定がすっ飛びました。。。

C言語に似ているので言語的に違和感は全くないのですが
やはりコンパイル出来ない、のは辛い。
サーバーに転送し、実行かけたらやっと「Parse error」とで
てきてその場所も発見しにくい。

ソースを変更しそのままコンパイル、という作業になれきって
いる身としてはとってもツラい。。

あと変数が勝手に生成される、というのも辛いです。
へたなタイプミスがあっても「新しい変数」として生成され何も
いわずに動いてくれるもんだから、それが間違いなのか、あっ
ているのか分からず、ものすごい神経を使いますな・・・。

でも一番辛いのはHTTPというプロトコルにのっけて処理をする
という「本当は無謀な行為」においてプログラムせねばならない
こと。それとユーザーインターフェイスが「苦と労したほど素晴ら
しくない」、つまり貧弱であること。

なんでこんなに苦労してんのに、こんな貧相なインターフェイス
しかできへんねや・・・ってかんじですか。

ブラウザーなんかじゃなく、どのパソコンにも入っていて、もっと
使いやすいもの出てこないかなぁ・・・。

作ってみるか？？？

息子のしょんべんの音を聞いてて驚くことがある。

その勢いのすざましさ、にである。

我慢して我慢して、「うっ」と叫びつつ便所に走り込み
ズボンをザッとおろしたかと思うと「ドバッ！」という感じで
しょんべんが飛び出すのだ。

そう言えば僕の父親がしょんべんをするときの音は
とっても緩やかで、「いつになったら終わるのだ」と
子供心におもったほど「細く」そして「長い」ものであった。

その「父親の音」に僕も少し近づいてきているのでは
ないか、と息子の音を聞いてて思うわけです。

まさに僕の身体は健康体そのものだけれど、老化の
足音がひたひたと忍び寄ってきている、、なんてことを
少しずつ実感してしまうのでした。

でも、どうやったら勢いよく出るのかいろいろチャレンジ
してみよう・・・・

ふと今日僕が作っているメルマガ「ゴルフ場システムのつくり方」
の登録者人数をを見に行ったら、５０人を達成しました。 （＾ｏ＾）

こんなニッチなメルマガを「読もう」と思われた方、あなたエラい！
ま、最初の４～５人は身内のもの達を無理矢理に読者へと
入信させましたが、一度ウィークリーまぐまぐに載ってからグッ
と増えましたね・・・・ってまだ５０人ですけどね。。。

これからも地道に一週間に一回のペースで出していこうとは思う
のですがなんせこのごろ忙しい。。。
ＰＨＰの仕事がちょっこっと入ってきたりして、その仕様変更やら
追加やら、なんやらで急に忙しくなってしまったんですよね。。。

でもお金にあまりならないのが何と言っても残念！

でも良いノウハウの蓄積になります。

現在いまだに心が揺れております。
その主な原因は C#.NET での画面描画の遅さ、になんです。

・本当に .NET で開発して良いものなんだろうか？

・Longhorn が現れてきたら本当に速くなるのだろうか？

・もしかしてLonghorn 上で今までのWin32APIを使ったアプリケーションのほ
　うが速いのではないか？

・・・などなど。

現在私の主な開発言語は Delphi と C++ です。どちらもWin32APIで動いてくれ
ていますがとってもとっても軽快な動きで、使ってても気持ちいいぐらいなん
ですね。ところが C# で開発したアプリケーション達はまるで Visual Basic
の動きを彷彿させてくれるような描画速度で、「あぁ、あのVBと同じか・・・」
と思うとプライドが著しく萎えてしまうのです。

また、「もしDelphiでパッケージを開発したなら・・・」という幻想が頭をよ
ぎり、今までの資産や開発効率の良さ、未知なバグに苦しまれることもなく開
発を進めていけるのに、などと思わない日はありません。

ただ Delphi の未来、C# の未来を考えればその答えはもう見えているようです。
たとえ、ここ２，３年は Delphiの圧勝だとしてもその後は徐々に C# は進化し
ていき確実に Delphi を追い抜く日が来ることでしょう。

あ、ちなみに C++.NET で同じように開発・比較してみましたがやはり同じでし
た。画面描画の遅さはその言語特性ではなく（少しはあるかもしれませんが）
ベースの部分、つまり「.NET Framework」自体が遅いことが分かりました。

こうなったらMicrosoft社に頑張ってもらわないといけませんが、もしかして
「.NET Framework 2.0」になったら速くなるのかもしくは「Visual Studio 2005」
になったら速くなるのか、はてまた「Longhorn」が出ないと速くならないのか
もしかして「Longhorn」が出てもダメなのか・・・・

なかなか悩みは尽きませんです・・・。

ゴルフ場システムは「パッケージ」といえども「カスタマイズ可能」となって
います。なぜならカスタマイズをしないと「売れない」からです。
もちろん、現在のシステムでもゴルフ場を運営していく上では、ほぼ十分な機
能を備えてはいます、でも・・・

前回の話で分かってもらえたと思うが、本番に向けて我々がしなければならな
いのは新設ゴルフ場の場合は「教育」が基本であとはデータセットアップなど
を含めた「設定」に時間をほぼ費やします。

ところが既存のゴルフ場の場合「現在のシステムはどうなっているか？」とい
うところから始まります。

「固定費の売上はどのようにしてあげているのか？」
「セルフ・キャディフィーの計上はどうしているか？」
「コンペ計算にはどんな種類があるのか、特殊な計算方法はあるのか？」

など、Ｑ＆Ａをあらかじめ作ってから、お客さんとの打ち合わせに望んでいる
のですが、こちらが想定する範囲外の答えがいっぱい返ってくることもある
し、そこから尾ひれがついて「えっ、こんなコトも」「うわっ、そんなことも」
なんて事は実際「ざら」にあるのものなんです。

そんな条件も飲み込み、そして現在出力されている帳票や画面の中で何が必要
で何が必要でないか、それを明確にしなければならない。
そしてそこには私たちの「私見」は一切含めてはならない、のです。
もちろん、こちらの既存のもので賄えるならそれは「こうしたらいいよ」とは
いいますが、私たちのシステムにはない機能をこちらが「勝手に不要と判断す
る」と、とっても痛い目に遭うのは間違いないですね (^^;)。

過去の経験で「現金集計表」という帳票を「こんなん要らんやろぅ」との勝手
な自分だけの判断で作らなかったことがある。もちろん、こちらのシステムで
は別の見方が出来る帳票が有ったからであるが、この判断が間違いのものと。

いざ本番開始の時に「現金集計表は？」とお客さんに聞かれ、「あぁ、あれは
無いです、その代わりにこれを・・・」と持っていったものの「こんなんじゃ
ダメです」と軽くあしらわれ、何度説明しても聞く耳を持ってもらえず、挙げ
句の果てには

「こんなシステム使いもんにならない」

なんて事を言われてしまいました。
僕ら技術者のもっとも聞きたくない言葉それは・・・「使い物にならない」

私はそそくさと作りました、同じものを、しかも２時間で・・・・。

その時思ったのは２時間で作れるんだったら、最初からへんに選別せずに作っ
た方が早い、ということでした。
ユーザーさんとの折衝に苦労して激烈な言葉を浴びるより、速やかに動いた方
がよっぽど楽なんですな・・・。

閑話休題

で、私の経験では現状の分析にはだいたい多くて２日ぐらいかけます。それは
ゴルフ場に行ってお客さんと打ち合わせや調べものをしている日数です。
そこでいろいろな資料（印刷物や画面のハードコピー）を持ち帰り、こちらな
りに整理して何度か電話で担当者と打ち合わせを行ったりします。
そして以下の項目にまとめることにしています。

１．新規のプログラム一覧
２．修正プログラム一覧
３．データ移行するファイル一覧

これらの項目をすべて洗い出し、工数を計算した後に行うのが

４．スケジュールの作成

です。
と言っても本番は既に決まっているはずなので、そこからの逆算でスケジュー
ルを埋めていくことになるのです。

久しぶりに目医者に行ってきました。

６年前ぐらいに一度行って、それきり行ってなかったところ。
最近子供もそこに通っていると言うことで僕もそれに便乗して
診察してもらいに行くことにした。

どうも４日ほど前から目がゴロゴロとして異物感があり、
ずっと目の赤みが取れなかった。
前々日に鏡で目のしたをペロッとめくってみると出来物が
生まれていた＞なんだこりゃ！

そして前日によしっ、と思い、手を良く洗ってその出来物を
グイグイ押していたら中から芯のようなものが出てきて
その出来物は消滅したのであった。
でも翌日（今日ね）鏡で目をみたら、未だに充血がとれない。

なので、今日、目医者に行ってきたわけだ。

目医者に着いてまずは目の検査と証して眼圧と視力検査と
あともう一つは、何の検査だろうか、、、なんか穴を覗きながら
「中の家をみていて下さい」なんて言われましたな。
何の検査やろうか・・・・。
ほんで、なんでこんな検査せにゃならんのやろか？

わしゃ「目が赤い」と言っただけやで・・・・

別の目医者に行ったときもそうやったけど、何故この検査をするのか
をはっきりさせて欲しいよねぇ、じゃないとムダな検査をされてるという
疑心暗鬼に陥るわなぁ、、、じっさい大いに疑っとるが・・・・

で、それが終わって実際の診察がはじまったやけども、
わたしてっきり忘れておりました

この先生がとっても嫌な先生だったこと・・・。

もう６年も来てないので忘れますわな、しかも前回来たときも
たった一回しか来てなかったと思います。

実はこの先生、女医さんなんですが「とっても偉そう」なんです！
すごく上方から物言われている気分になり、とても気分が
悪くなるんですな、これが。
まぁ上方と言っても椅子に座るのと机に座るのとの差ぐらいで
はないですよ・・・まぁ例えるなら椅子に座るのとその頭の上に
に立たれて喋られるぐらいの違いは有りますな。

ま、「先生」と名が付くんですから「まいどおおきにぃ！」なんて
へりくだってくれなくても良いんですが、せめてもちっと愛想良く
「にこっ！」と笑って話してくれないかなぁ、と、まぁそう思うわけです。

この眼科がすいているのがまさにそれを証明しています。

目薬を２つ（オフテクター＆フルオメソロン）をもらって３５００円也。
高いなぁ・・・・。

昨日の朝「西日本新聞です」と我が家の電話ではなく
会社の方に電話があった。

会社の電話番号は仕事の電話しか入ってこないので
とってもめずらしいことなのです。
と言っちゃえばあんまし仕事してないように聞こえますが、
ほぼ仕事の電話というのは携帯に入ってくるわけなのですよ、これが。

で、電話の主が言うことには「広告を載せて下さい」ということらしいのです。
以下その対応

「西日本新聞ってご存じでしょうか？」
「う～ん、あんまし、知らないですねぇ・・」
「でしょうねぇ、有名どころでは中日新聞とか神戸新聞みたいな感じで、
その地方では結構知名度が高く販売部数も高い新聞なんです！」
「あぁ、なるほどぉぉ」
「で、その地方というのが北九州市を中心とする九州全般なんです！」
「九州ですかぁ、関西だったら良いんですけどねぇ」
「いやぁ、九州も捨てたもんじゃないです・・・・・」

と、それからいかに九州、特に福岡県が重要な場所か、そして西日本
新聞の影響が大きいか、と言うことを熱弁をふるって語ってくれましたよ。

「でいつもなら？？万円なんですか今回は？万５千円で提供させて
頂くんですが・・・」
「う～ん、なるほどねぇ・・・・」
「い、いや、私の特権で？万円ぽっきりにさせて頂きます！いかがでしょう」
「まぁ、そこまで言うのなら、分かりました！」

と言うことでおそらく１２日の企業特集に企画広告としてオフィスカベルが
登場してくると思いますので西日本新聞を買いましょう・・・・。

ってドコで買ったらよいのやら (-_-)

P.S.
このおかげでホテルシステムのホームページを少しリニューアルする気になりました。
ちょっとだけカッコ良くなったので見に来て下さいませ！！

プロムナードホテルシステム

「新規のゴルフ場だったらみんな素人だから大変でしょう？」

こんな質問を受けたことがある。ゴルフ場も新しく、社員も全員新入社員、運
用も何もかも決まっていない状態での「システムの導入」である。

・・・と言っても経験者が全くのゼロっていうところは少ないので、何人かは
「過去にゴルフ場で働いていた」なんて人もいる。そういう人がイニシアチブ
を取ってくれて運用のやりかた、そしてシステムとの関わり方をまとめてもら
えるととても嬉しいのだが、現実は違う事が多々ある。

システムに詳しい人は運用を知らないし、逆に運用に詳しいことはシステムの
ことには全く疎いことが多い。
なので、実際に打ち合わせに行くと新しいゴルフ場ではシステム面よりも運用
面を聞かれることが多々ある。

たとえば

「予約台帳はどんなのが良いですかね？」
「電話を受けるときは何と何を聞けばよいですか？」
「レストランなどで現金精算出来るようにしたほうがいいかな？」

などなど、これはまだ運用が決まってないために出てくる質問であり、私たち
のほうもある程度出てくる質問に関しては答えられるだけの経験は積んでいる
のでこれぐらいは何でもないことであり、むしろ、私たちが主導権を握って、
こちらのフォーマットに合わせてもらえるのでむしろ好都合といえる。

ただ、いままでコンピュータもさわった事がない、という人もいるのでマウス
のクリックから教えなければならないのが、ちょっと辛かったりするが、それ
はすぐ慣れてもらえるし、案外こちらのシステムにもスムーズに溶け込んでも
らえたりするので「新規」というのは案外楽なのだ。

問題は既存のゴルフ場である。
「既存」なのでコンピュータシステムも「既存」のものが当然入っている。
そして「既存の予約台帳」「既存の営業日報」「既存のクラブ確認票」「既存
の計算書」と既存のオンパレードが続き、そしてもちろん既存の人たちがいる。

そこには既存のコンピュータシステムをベースにした人の流れがあり、その流
れが不合理であろうが何であろうが「既存のパワー」を発揮して私たちが導入
しようとしている新しいシステムの流れを阻止する、と言うことがしばしばあ
るのだ。

人間「慣れ」というのはまことに恐ろしく、あるゴルフ場ではすべて手書きの
伝票を最後にフロントで人間が電卓を使って猛スピードで精算する、という運
用になっていて、そのスピードたるやコンピュータで精算する速度をも凌ぐ
・・・らしい。

ソフト屋を戦慄させるフロントマンと言える。

話は脱線したが、人間の慣れに対する順応性は素晴らしいものだが、逆にその
慣れが新しいものへの抵抗になる、という経験を数知れずしてきた。
それは本番開始してからの「ブーイング」として私たち現場に立ち会っている
ものたちの耳に飛び込んでくる。

なので既存のゴルフ場において気をつける必要があるのは、「完全にシステム
を置き換える」のではなく「既存のものを出来るだけ取り入れつつ置き換える」
というのが肝心だと思うのです。
少しでも「必要」と思われるものに関しては作ってしまえ、というわけだ。
これは一時的な「ブーイング」を避けるためだけではなく、システムの包容力
を大きくするための「手段」だと考えれば何て事はない問題なのです。

でもその分、新しい帳票などを作らねばならなかったり、既にあるものに手を
加える必要が多々出てくるのもこれまた事実。
なので既存のゴルフ場のほうが約２倍ぐらい大変なんですね。。。