名古屋の時間貸しレンタルオフィス、レンタル自習室の＠Ｓｐａceアットスペースの店長＆管理人の中井です。
さて、アットスペースのレジシステムはaccessプログラムで設計開発されています。
設計開発、と言いましても
設計書を作成したのは初期開発のみ。
後の改訂作業は全てプロトタイピングで改訂設計書無しでいきなり改訂作業から始まります。
かつて、汎用コンピュータで構造化設計を志向したＳＥとは思えない有様です。
でも、設計/開発/レビュー/テスト/本稼働の各フェーズを全て一人でやる今では断然、楽で効率的。
開発＆テスト環境と本番環境は同一、
だから、本稼働中に少し手直し等あたりまえ。
機能追加、機能改訂を繰り返し、
今ではこのレジプログラムは多機能化となりました。
・顧客管理システム
・売上管理システム
・予約管理システム→メール自動送信
・月極め指定席管理システム→web予約の指定席連動
accessはDBがあり、画面設計実装でき、ジャーナルプリンター帳票設計実装もでき、
おまけに、メール送信やwebのhtmlファイル編集と送信もできる。
なんと、万能なツールでありましょうか。
「顧客管理システム」としては
会員データベースと、その会員の売上明細データベース明細をjoinさせることによって簡単なＦＳＰ「フリークエント・ショッパーズ・プログラム」が実現できます。
個別にSQL文を作成すれば、いろんな分析情報を抜き出す事ができます。
大きなコンピュータや高級なデータベースエンジンが無くても出来るんです。
すごいコストパフォーマンス！
「売上管理システム」としては
レジ操作を全て、メニュー画面とフォーム設計、帳票設計で実装しています。
主なロジック部分は、access vbaでコーディングしています。
vbaコーディングは、幅広い機能を作りこむ事ができます。
それにvbに似ていて扱いやすい。
最近はコーデイングが膨らみ多機能になったために不便な点が出てきました。
それは、
フォームの入力項目チェックやイベント単位に検証ロジックを安易に追加したりすると、
他のフォームに組み込んだvbaロジックが「型エラー」で停止する事があります。
例えば、検証ロジック中で、定義時の初期化を行います。
■ 定数１ = ""
このコードを加えたら、他のロジックでisnullできいていたりすると型エラーに陥りました。
この場合は、
■ 定数１ = NULL
と修正し事なきを得ました。
昔のように、構造化プログラミング手法で検証ロジックもサブルーチン関数化して同一プログラミングで作っていれば問題は出なかったのでしょう。
でも、改訂追加を繰り返す中で検証ロジックを変えていったので一貫性が無くなっています。
コーディングステップ数が増え、機能が多くなった分だけ
修正した場合のテスト検証が面倒になりつつあります。
さて、今後の改訂方針はどうしたら良いものか？
迷う所であります。
そうだ！昔読んだ本でオブジェクト指向コーディングという手法が有る事を思い出しました。
クラスとか使うんですよね。
HTMLのCSSでは使いますが、ＶＢＡでは使った事が無い。
ＶＢのコーディングの時も実際に使う所まで行きませんでした・・・
直ぐに使って、コーディングを整理するとはいかないようです。
でも、現在の改訂設計書無しでプロトタイピング手法は、もう辞められません。
思いつきで、直ぐに修正、直ぐに本番使用。
このスピード感がトテモ心地よいのであります。
余談ですが、チョッとした修正を施したために
このレジシステムを本番稼動中にエラーメッセージを出して止まった時に話です。
この場合、目の前にお客様がいらっしゃいますので直ぐに何とかしなければなりません。
原因は何か？
対応はどうするのか？
代替策は有るのか？
この事を瞬時に頭の中で考えます。
この時、頭の中にアドレナリンが分泌されるのを感じます。
不謹慎ですが、この緊張感がたまらない・・・
なぜだろうかと、思い返すと
昔、ＳＥだった時に客先トラブルで幾度となく経験した極限の状態を思い出します。
当時は地獄のように感じていました。
今考えると自分の持てる力、知識、経験を短時間の間に総動員して答えを導き出す。
このような状態は、スポーツで例えると全力疾走で運動場を走り回っているような感覚です。
走り終わったときのそう快感が心地よさを誘うのでしょうか？
理由はわかりません。
さて、これからのレジシステム改訂はオブジェクト指向を取り入れるべくインターネットで事例を検索して勉強していこうと思います。