SOHOの散歩道

気が付いたら最後に記事を投稿して３カ月も経っていた。新規投稿用のリンクもIEの”よく使うサイト”から消えているし、記録しておいたログインパスワードも消えているし、さらには投稿用の管理者ページのデザインまで変わっていた。

最後に書いたのが２月28日、その頃から例年のことながら”年度末の予算で”的な仕事が連発してかなり忙しかった。そしてそれにかまけてしばらく書き込みをしないうち、ついつい後回しにしてしまうことに慣れ、気が付くと３カ月も過ぎていた。良くも悪くも何ごとも”習慣”だと思う。

やはりこのご時世、そんなに儲かるという状況にはならないが、とりあえず何とか仕事は続いている。

現在はSQL ServerとASP.NETの関係。

見積依頼もそれなりに来ているが、相変わらず”まずは顔を出せ”みたいなものが多く、”田舎に住んでいるんじゃダメだな”という対応も少なくない。ただ、目の前にある仕事をキチンとこなすことが最優先！。話しの中には”今すぐやってくれるなら頼んでもいい”というのもあるが、現在の開発がかなり規模が大きいので、あまり時間は取れない。中には”うちの仕事が受けられないのか！”といった人もいたが、負荷や納期を考えずにやみくもにあっちもこっちも請けるのはやはり問題だと思う。

しばらくは、ひたすら１つのシステムを開発する作業が続きそうだが、ぼちぼちと記事投稿をしていこうと思う（とはいえ本当に漠然と毎日が過ぎて行っている状況なので、個人的なトピックは本当に少ない.....）。

マクロのみで作られたAccessのデータベースをカスタマイズする機会があった。

処理としてはやはりマクロでは実現は難しいかもしれないし、自分にとってはむしろマクロの方が難解で複雑でやりづらいので、VBAのプログラムで書いた。

比較的簡単なカスタマイズだったので、コードとしては複雑なことはしておらず、むしろそのアイデア勝負という内容。

ただ、確かに要望の内容はカバーしているとは思うし、その部分だけを見るしかないのだが、データベース全体をみたときにはマクロとモジュールが混在したような状態になってしまうので、今ひとつすっきりとした気持ちになれない。

自分の場合は、基本、絶対にマクロを使うことはない。VBAオンリー。でも、入門書などでもそうだが、どうしても初心者では「まずはマクロで自動化」ということになる。しばらくたってプログラムをマスターして、それを追加していくことになるのだが、ふつうは当然のごとく従来からあるマクロはそのまま残ることになる。

他の人が作ったデータベースとはいえ、マクロがあったらすべてVBAのプログラムに置き換えたくなってしまう。本当はそこまでやってリニューアルしたような感じで納めたいところだが、作業量や受注仕様範囲を考えると、なかなかそこには手を出せない。ましてや、VBAに変更したことによってそこがもし新たなバグにでもなったら困るし....。ある意味、注文外ということで妥協するしかないところだと思う。

e-TAXによる今年の確定申告が終わった。

去年初めて使った際も”便利な”とは思ったが、２回目の今年はさらにそれを実感した。初めて使う際はいろいろなソフトをインストールしたり市役所に行って住基カードを作ったりといろいろ面倒だったが、やはり２度目となると、一連の作業がかなり簡単に済ますことができるとつくづく実感できる。

というのは、特に、去年のデータを引き継ぐことができるという点。名前や住所などはもちろんなのだが、経理上のデータも引き継ぐことができる。

具体的に言うと、たとえば決算書では去年の「期末の残高」を自動的に「今年の期首残高」としてくれる。なので、去年の末の数字を再入力する手間もない。その他、確定申告書では家族の生年月日などから自動的に今年の時点での扶養控除額なども計算される。

また、去年に入力したさまざまな内容が引き継がれ、画面に表示されたその部分だけをめがけて今年の数値に書き換えていけばよいので、作業自体は相当楽だった。


とはいえ、なにぶん最後に操作したのが１年前。

”ICカードリーダーを接続してください”みたいなメッセージが出てそれ通りにやったのだが、エラーが出てしまって困った。結局、その時点では、リーダーはもちろんのこと住民基本台帳カードもセッティングしていないとだめだった。リーダーは接続してカードが載せてない状態にも関わらず「ICカードに問題がある」みたいにメッセージが出てしまうところは戸惑うところ。「カードを載せてません」って言ってくれればよかったのに......。

また、e-TAXのパスワードと住民基本台帳カードのパスワードを混同してしまったのもある。

初めての際はしっかり手順書を読みながら行ったのでそういった細かい点は問題なかったのだが、やはりうる覚えで２回目を楽に済ませようとすると、ちょっとしたところで引っ掛かることもある。年に１度だけの作業だからこそ、やはりマニュアル通りにやることが大切かもしれない。

来年のことを考え、今回はそういった点をしっかりメモしておいた。

仕事柄、いろいろな人が作ったAccessデータベースの中味を見させていただくことが多い。

テーブルの作り方、フォームのデザインイメージ、プログラムのコーディングスタイル、それぞれみんな異なることがよく分かる。さらにはある処理に関するアルゴリズムとか仕組みについて見てみると、やはりみな千差万別なので解析に手間取ることも多いが、”なるほどそういうことか！”と、よく考えてあって感心させられることも多い。

そんな中、よく”見逃されているな”と思う箇所があり、最後まで詰められているかどうかが分かる部分がある。

それがフォームのコントロールのタブオーダー、あるいはメッセージボックスのデフォルトボタン。

たとえば、マウスでいろいろフォーカスを移動させたりボタンを選択したりする分には問題ないのだが、キーボードを中心に次々とデータ入力をしていき、最後に[OK]ボタンを押すような操作性を持ったフォームでは、タブオーダーがきちんと設定されていないととんでもない入力順となってしまったりする。

特に注意しなければいけないのは、テーブルやクエリをベースにフォームを作った場合にはそれなりに設定されているのだが、あとからコントロールを追加配置した場合、その順番が最後になってしまうということ。なので、それがおかしいフォームを見ると、”これはあとから追加したな”とか、”それっきりチェックしてないな”とか分かってしまう。

エンドユーザー（本当にその画面を操作する人）はさまざまなので、マウス操作中心で、そのようなところまで配慮しなくても分からないケースもあるのだが、一方で大量のデータを入力する人にとってはけっこうインタフェース上重要なところなので、仕上げの時点までにはやはり一通りはチェックしておきたいところだ。

なおそれは、自分にとってもふだんから注意しているということであって、完璧を自負しているわけではないので....、念のため。

次のような、フォームのテキストボックスのBeforeUpdate（更新前処理）イベントプロシージャ、入力された「入社日」の値をチェックし、制約条件に違反する場合は入力をキャンセルし（Cancel = True）再入力を促す、というもの。

If Me!入社日 < #1/1/2000# Then
　MsgBox "間違いです！"
　Cancel = True
End If

このコード、Access2003以前や2010ではたぶん何の問題もないのだが、どうやらAccess2007で動かすと妙な動作をするみたいだ。具体的には、きちんと入力チェックは行われるし、Cancel = Trueで確かにそれが受け入れられずに再入力状態（カーソルが次のコントロールに行かない）になるのだが、その直後になぜか「プロパティが見つかりませんでした。」といったメッセージが表示される。

これは、どうやら既知の問題らしく、Access2007のバグということで、次のように書き換えることで対処できる。

If Me!入社日 < #1/1/2000# Then
　MsgBox "間違いです！"
　DoCmd.CancelEvent
End If


ところが、今回それを忘れてAccess2007で問題となる可能性のあるコードを書いてしまったのだが、作っている間、まったくエラーメッセージのようなものは表示されず、うま〜く思った通りに動作してくれる。ある程度作業が進んだところで「そういえばAccess2007にはそういう問題があったな」と思い出した次第。

コードはすごいシンプルだし何の変哲もないのだが、どうして例のメッセージが出なかったのだろうか？、何かコードの書き方とか場所とかが運よくメッセージが出ない状態になっていたのだろうか？。

とはいえ、後々その変なメッセージがバグとなってしまうと困るので、念には念を入れて「Cancel = True」と書いているところをすべてピックアップして正常に動くかどうかあらためてチェック。その結果、すべてがOKだった。「Cancel = True」という書き方で問題は起こらない。メッセージが出る場面と出ない場面がある！、BeforeUpdateの怪しいところ。


それでも、やはり後で問題となると嫌なので、いろいろと条件を変えて試してみた。そして、ひとつの結果が分かった。フォームが「データシートビューのときだけ起こる」ということ。

まったく同じコントロール、まったく同じコード、まったく同じ入力値であっても、単票形式や帳票形式のビューのときでは起こらない。既定のビューでそうなっているときだけでなく、フォームを開いたあとにリボンの操作でビューを変えてみたときもまったくその傾向は変わらない。ビューを切り替えることによって、メッセージが出るのと出ないのとが明確に分かる。

今回そのようなコードを使っているのはすべて単票もしくは帳票のビュー。なので変なメッセージが出なくうまく動いたということになる。
いきなり「”Cancel = True”はダメ」という認識でテストを初めてしまったため、結果としてムダな時間になってしまったが、そのようなことがはっきりしかつ問題はないということが確認できたので、良しとしようと思う。

Accessの受託開発やワンポイントアドバイスについてよくお問い合わせいただくのだが、ソフト開発の金額に対する意識って、会社や担当者個人によってつくづくまちまちだと思う。

「１万円でも高い！びっくり！」といって断られることもあるし、「安すぎないか？ホント大丈夫？」という反応をされることもある。「だいたい相場通りだね、注文するよ」といってくれるお客様もいる。同じ基準で見積りしているんだけど....。

ただ、いろいろ聞くと、世の中、安ければいい、相場通りならいいとも限らないようだ。

どう考えってそんな高い金額は掛からないないだろうと思うシステムであっても、営業マンがうまく立ち回ると、平気で数百万円でポンと契約がとれたりするそうだ。

もちろん根拠ある仕様で根拠ある見積り金額なのだろうが、結局のところそれ自体が問題なのではなく、買う側の受け止め方が重要なのだと思う。

”ソフトウェアなんて！”と思っているところへ数万円を持って行ってもだめだし、他の会社が200万円の見積りだったから150万円なら安いねという会社なら、150万が実質高いとしてもOKとなる。

一方で、100万円が相場だと理解しているところへ100万円を提示すればすんなり行くとは限らない。政治力とかコネとか、調子のこと？を言うとか、いろいろなことが絡んで120万円が通ったりすることもある。

ソフト開発に限ったことではないが、その辺の交渉もしくは駆け引きというのは本当に難しいものだと思う。


ところで、自分の見積りについて言うと、それなりの見積り基準は持っていても、見積り作業には毎回毎回悩まされる。お客様の望むところをどのようにその基準に当てはめるかが最も悩ましいところ。それさえクリアできればあとはExcelが勝手に金額を計算してくれる。

ただ、そのあとの交渉力はやはり弱いと言わざるを得ない。Noという人をYesと言わせる力はまったくない。個人的には、「だいたい相場通りだね」と言ってもらえると一番ホッとするのだが、それがYesに繋がらなければ意味がないし.....。