高機能サロン管理システム★さまれぼ！★開発日記

先日‘さまれぼ！’の新バージョンをリリースしましたが、その直前、Windows Vistaで最終確認を行っている最中に問題が発生しました。フローター上のリストボックスの挙動がおかしいのです。ナビシステムがVista上で正常に動作しなかった件は既に記事にしましたが（‘さまれぼ！’ Vista対応 ＆ ‘さまれぼ！’のナビシステム実装変更）、今回もDesktop Windows Manager（DWM）が影響しているような感じです。

フローターとは顧客カルテなどのウィンドウを親とした子ウィンドウで、親ウィンドウの入力を許可したままポップアップしたものを言います。例えば作業工程フローターの場合、親ウィンドウにある作業工程一覧の行をクリックするとポップアップ表示されます。親子とも入力可能なため、フローターで情報編集が行えますし、フローターを表示したまま作業工程一覧をクリックして別の工程表示に表示内容を切り替えることもできます。ディスプレイの制約から一つの画面に表示できる情報には限界がありますが、フローターにより多くの情報表示／編集が行えます。フローターの詳細は、‘さまれぼ！’専用サイトのこちらのページをご覧ください。

それでVistaでの問題です。本来なら顧客カルテの部位現象一覧をクリックするとフローターが表示されてリストボックスから部位現象が選択できるのですが、Vistaではフローター上のリストボックスをクリックしても行が選択されないのです。どうもマウスボタンを離したのが認識されていないようで、ちょうどドラッグしている感じになります。クリック時にボタンを押したまま一呼吸待ってから離すと正常に動作します。この問題はキーボードフォーカスが親ウィンドウにある場合に発生し、フローターにフォーカスがある場合は正常に動作します。
こういったことから、ボタンを押した後のキーボードフォーカス移動に紛れて、ボタンを離したというメッセージが消えてしまったのかもしれないと想像しています。リリース直前にエンジン部分に手を加えるのは避けたかったので実際にメッセージが消えているのか確認はしていませんが。

もしかすると最近の高性能マシンなら問題は発生しないのかもしれませんが、発生すれば問題なので、試行錯誤して何とか対応しました。しかし、DWMにしろProgram Files保護にしろマイクロソフトのやることはどうにも中途半端で、苦労させられます。

過去2回の記事（システム権限機能構想(1)・システム権限機能構想(2)）でシステム権限機能の基本方針は決まったので、いよいよ実装です。既出のように幾つかの問題点がありますが、鍵となるのは「現在のシステム権限のプログラム間で共有する」という点でした。‘さまれぼ！’システムはメインプログラムの他にデータバックアップや顧客抽出などのプログラム群で構成されます。当初は、メインプログラムだけでシステム権限機能をサポートして、タイトルバーに現在のシステム権限を常時表示することを考えていました。しかし、その中途半端さに我慢できず考え続けた結果、独立したシステム権限認証用プログラムを用意することを思い付きました。個々のプログラムで許可が必要な機能を実行しようとした場合、このプログラムに問い合わせて許可されているかどうかを判断する仕組みで、「認証サーバ」とでもいうべきプログラムです。現在のシステム権限表示やシステム権限の変更もこのプログラムで行いますが、このようにシステム権限を一箇所で集中的に管理するというのは何となく美しく感じられます。
しかし、成りすまし（全てに許可を出すプログラムへの置き換え）対策をどうするか、許可されていなかった場合の認証をどうするか（クライアント側は認証終了まで待たなければならない）、プログラム間の通信が複雑になる、といった問題が考えられます。加えて、システム権限を一手に扱うために重いプログラムになってしまい、それが常駐する点が嫌でした。
何とか軽くて強固なプログラムにできないかと考え続けて思い付いたのが、SystemCertifierという小さなプログラムでした。通常は許可機能が最も抑制された状態にして、このプログラムが存在する場合だけシステム権限が働きます。このアイデアによって、システム権限機能は一気に実現に近づきました。

パスワードやシステム権限などの設定をどこに保存するかという問題も結構悩みましたが、SystemCertifierという方式が決まり、データの性質を考えた結果、自然に結論に至りました。

最後に、日常的に素早く入力するためのパスワードをどうするかという問題です。安全面から結構な長さが必要ですが、覚えられないのでは意味がありません。そこで、カタカナをパスワードとして使えるようにしました。これなら座右の銘や思い出の場所や好きな本など、本人しか知らない語句を自由に使えます。また、漢字変換の手間も要らず、変換ミスもありません。
さらに入力用の仮想キーボードについても考えました。お馴染みの「*」表示では入力ミスに気付けず再入力が必要になり、特に長いパスワードでは致命的な欠点と言えます。第三者がチラッと見てもわからなければ良いと考え、入力フィールドを3文字程度に縮めました。元々カタカナは漢字や平仮名に比べて読みにくいため、3文字程度見られても全体を把握することはできないでしょう。
その上、一番重要なパスワードにはヒント表示も行えるようにしました。パスワードを思い出しやすくするという理由に加え、複数の事項を組み合わせて複雑なパスワードにするための工夫です。

こうして、システム権限機能を実装することができました。次回は、システム権限機能を画像付きでご紹介する予定です。

前回システム権限機能構想(1)の続きです。スタッフごとに利用可能な機能やパスワードを設定しておき、条件設定編集などの機能を利用する際にパスワード入力によるスタッフ認証を行う方法では、カルテでの顧客連絡先表示を制限できないという問題がありました。
それを解消するために連想されるのは、Windowsなどでも用いられているログイン方式です。Windowsを利用する際にはパスワードを入力してユーザー認証を行います。これを‘さまれぼ！’に置き換えると、システム実行時にスタッフ認証を行い、そのスタッフに許可された機能だけが利用できるということになります。
ただ、営業中には複数のスタッフが利用するので、このまま適用することはできません。システム起動直後の状態では顧客連絡先表示や条件設定編集などの機能が利用できないようにしておき、必要な場面でスタッフ認証によりログインします。その後はログアウトするまでスタッフに許可された機能を継続利用することができます。こうすると、営業終了後や休日に店長が一人で作業する場合は、何度もスタッフ認証することなく作業を継続できます。

これなら十分実用的ですが、スタッフの数が多くなると、スタッフごとに許可する機能を設定するのが大変です。そこで、‘さまれぼ！’ではさらに進めてシステム権限という概念を導入しました。利用を許可する機能をスタッフに直接割り当てる代わりにシステム権限に割り当て、スタッフにはこのシステム権限を割り当てるというものです。当初は、スタッフ権限・リーダー権限・店長権限・管理者権限くらいのレベル分けを行い、それぞれの権限で許可された機能を利用でき、上位のレベルが割り当てられたスタッフは下位のレベルで許可された機能を利用できる、というものを考えていました。しかし、サロンによりスタッフ事情は異なります。
そこで、サロンが自由にシステム権限を作成できるようにして、各々で許可する機能も自由に指定できるようにしました。さらにシステム起動直後からスタッフ認証を行うまでの通常運用時に利用できる機能（つまり全スタッフが利用できる機能）も指定できるようにしました。
また、一人のスタッフに複数のシステム権限を割り当てられるようにしました。この場合、スタッフ認証の際にシステム権限を一覧表示して、そこから一つを選ぶことになります。これにより、店にいるスタッフに応じてシステム権限を自由に選べるようになります。例えば、店長が複数のシステム権限を使い分けられるようにしておけば、営業終了後に信頼できるスタッフだけになれば許可機能を増やし、店長だけになればさらに許可機能を増やす、といった使い方ができます。

基本的なアイデアはこれで決まりました。実は一年前には既に決まっていたのですが、実現するためにはどのように実装するかを考えなければなりません。できるだけシンプルにして実装により障害が発生することを避け、修正に要する時間も最小限に抑えたいところです。実装に当っては、次の問題がありました。

• パスワードやシステム権限設定の保存方法
• 実行中システム権限のプログラム間での共有方法
• 実行中システム権限を表示する方法
• 実行中システム権限から通常運用に戻す方法
• 長くて覚えやすいパスワードを入力する方法

システム権限の影響は‘さまれぼ！’全体に及ぶため、修正も広範囲に及びます。また、システム権限設定を保存するためにデータベース変更が必要になるかもしれません。そこで、できるだけ早い対応が望ましいと考えて、今回のバージョンアップで対応することにしました。詳細は次回ご説明します。

‘さまれぼ！’にはスタッフが利用できる機能を制限する仕組みがなく、顧客連絡先の閲覧や条件設定編集などを誰でも行えるようになっていました。スタッフが独立する際に顧客データをこっそり持ち出すという話もありますし、条件設定やフロント設定を興味本位で勝手に変更されても困ります。多くのスタッフを抱えるサロンでは特に必要な機能だとわかっていましたが、納得のいく実現方法が見つからず、最初のバージョンではサポートできませんでした。どういうことかご説明します。

まず、真っ先に思い付くのは制限したい画面をパスワードで保護することでしょう。例えば条件設定編集画面を利用する際にはパスワード入力が必要で、パスワードを知っているスタッフだけが利用できます。しかし、この方法は一つのパスワードを複数のスタッフで使い回すため漏洩しやすいという問題があります。また、フロント設定編集は行えるが条件設定編集は行えないようにしたい場合は、別々のパスワードを利用することになります。そうすると、制限したい画面の数だけパスワードが必要になり、とても覚えられるものではありません。しかも、自分に無関係な文字の羅列であれば尚更です。

そこで思い付くのは、スタッフごとに利用可能な機能を指定して、スタッフごとにパスワードを設定するという方法です。フロント設定編集や条件設定編集などの機能を利用できるかどうかをスタッフごとに指定しておきます。フロント設定編集画面を利用する際にはスタッフごとに異なるパスワードが必要で、そのスタッフに許可された機能かどうかを判断します（スタッフ認証）。そして許可されていれば利用できることになります。これならスタッフが覚えるパスワードは一つで済み、しかもスタッフが想起しやすい文字列を利用できます。

しかし、この方法にも問題があります。顧客連絡先の閲覧を禁止することができないのです。顧客カルテやシェアカルテには住所や電話番号が表示されますが、この表示を制限しようとすれば、顧客カルテやシェアカルテを表示しようとするたびにパスワード入力によるスタッフ認証が必要になります。頻繁に利用するカルテでいちいちパスワード入力を行うことは、とても現実的とは言えません。
これに対する解答は次回にご説明します。

‘さまれぼ！’の顧客抽出にあった欠点を解消しました。
例えば、簡単抽出で「12月に来店のあった顧客」を抽出することはできましたが、その売上が1万円以上の顧客に絞って抽出することはできませんでした。このような機能を持った組込関数を追加するという手段もあったのですが（組込関数の追加は簡単です）、根本的な解決を目指しました。
それは、抽出対象となった来店履歴の売上合計（技術・物販・全体）を抽出結果として保存できるようにする、ということです。加えて、組込変数としても参照できるようにしたので、上記のように組込関数で抽出した後に売上で絞り込むこともできるようになりました。さらに、ＣＳＶ出力を行えば売上トップ10もわかります。

この修正で、「過去１年間で特定スタッフが中心となって作業した来店分の売上金額」など、さらに柔軟な抽出が行えるようになりました。

サロン定休日サポートシリーズの第三弾です。
これまで二度に渡り定休日の指定方法を拡張してきて、もう十分だろうと考えていました。
しかし、「第三月曜火曜水曜連休」というサロンを見つけてしまいました。1000サロンのうちの1サロンなので、たった0.1%です。見なかったことにしようかとも思いましたが、せっかくこれまで対応してきたので徹底的にやることにしました。
「指定曜日から三連休」という指定方法にしようかと考えました。しかし、より汎用性を持たせて「指定曜日の○日後(前)」という指定方法にして、指定曜日の前後6日間を指定できるようにしました。
例えば「第三月曜火曜水曜連休」の場合は、「第三月曜」「第三月曜翌日」「第三月曜翌々日」という指定になります。
もちろんスタッフ休日でもサポートしました。
今回がサロン定休日サポートシリーズ最終回になれば良いのですが。

既報の通り、‘さまれぼ！’には値引入力専用のダイアログがあります。
値引額や値引率をその都度入力して値引を行う際は、次の手順で行います。

1.<追加>ボタンを押す
2.値引項目選択ダイアログで値引項目を選択する
3.値引額や値引率を入力する

これに対し、「予め<値引項目一覧>に値引項目を表示しておけないか」という指摘を受けました。
なるほど、もっともな意見です。
そこで、値引項目条件設定で指定した項目を<値引項目一覧>に表示した状態で値引入力ダイアログを表示することにしました。

これにより、次の手順で値引入力が行えるようになりました。
1.<値引項目一覧>から値引項目を選択する
2.値引額や値引率を入力する

クリックが一つ減っただけではなく、わかりやすくなったと思います。
尚、値引項目の入力が確定した後に再度値引入力ダイアログを表示した際には、使われていない値引項目は表示しないようにしてあります。一目で値引項目がわかるようにとの配慮です。

以前、「第一月曜火曜連休」をサポートしたという記事を書きました。「第一月曜翌日」と「第一火曜」とでは日付が異なる場合があるためです。この時は「指定曜日翌日」フラグを追加することで対応しました。
その後、900件以上のサロンホームページをチェックして初めて「第三月曜と前日の日曜連休」という定休日に出逢いました。考えてみれば、「第一月曜翌日」とは逆の「第一月曜前日」があっても不思議ではありません。
というわけで、「指定曜日前日」フラグを追加することにより、サロン定休日とスタッフ休日で対応しました。

操作性や機能の向上などを可能な限り追求して開発を続けてきた‘さまれぼ！’ですが、リリース間近となり、妥協を選択することもあります。

‘さまれぼ！’では店舗昼休みなどの休憩時間を設定でき、チャート上で一目で確認できるようになっています。予約受付を行う際に考慮できるように用意した機能なのですが、その都度休憩開始／終了時刻を指定するのではなく、時間帯条件設定から選ぶようになっています。
例えば、「店舗休憩時間」という名称で時間帯条件設定を用意し、ここで休憩開始／終了時刻「13:00～14:00」を設定しておきます。そしてその時間帯を休憩時間として業務予定に設定します。こうすると、その都度休憩開始／終了時刻を指定するより楽に休憩時間設定が行えます。
問題は、過去の業務履歴にもそのまま時間帯のまま記録されることです。店舗運営方針が変わって「店舗休憩時間」時間帯の休憩開始／終了時刻を「13:30～14:30」に変更すると、過去の休憩時間まで「13:30～14:30」に変わってしまい、実際にどうだったのかがわからなくなります。

スタッフ勤務時間では、実労働時間算出のため、時間帯ではなく休憩開始／終了時刻を記録するようになっているのですが、店舗休憩時間もこれに合わせて修正するか悩みました。データベース変更が必要になり、バグのリスクが高まるためです。

そこで、この修正がどうしても必要なものか考えました。
今まで800以上に及ぶサロンのホームページを見てきましたが、休憩時間のあるサロンは皆無でした（歯医者や動物病院にはありますが）。
また、過去の休憩時間に価値があるのかという点も疑問です。スタッフの休憩時間は給与に直結しますから正確に記録する必要がありますが、サロンの場合は売上が重要だからです。
さらに、スタッフ休憩時間は休憩開始時と終了時に簡単に入力できるようになっていますが、店舗では同様の仕組みを用意していません。予約受付を目的としているためです。

結局、休憩時間の記録が有用なのかどうかわからない状態で、危険を冒してまで修正すべきではないと結論付けました。
その代わり、上記問題があるので時間帯の使い方に注意するようヘルプに手を加え、初期設定で「13時～14時」「13時半～14時半」といった名称の休憩用の時間帯を予め用意することにしました。こうしておけば、問題を回避できるでしょう。
もしも休憩時間を正確に記録したいという要望があれば、その時点でシステム修正を行うことになります。

サロンのホームページを見ていて気付いた「第一月曜火曜連休」を先日サポートしましたが、実はもう一点、気になることがありました。それは、平日と日祝日とで営業時間を変えたり、金曜にナイター営業で営業時間を延長したりと、曜日によって営業時間が変わるサロンが結構多かったことです。
‘さまれぼ！’では一種類の通常営業時間しか設定できませんから、「第一月曜火曜連休」の時と同様、対応したくなりました。

まず考えたのが、曜日ごとに営業時間を予め設定できるようにすることです。しかし、データ設計から根本的に見直す必要があり、リリースが近い時期に行うにはリスクが大きすぎます。

次に考えたのが、簡単に営業予定を設定する手段を用意することです。これならば、データ設計はそのままに、新しくダイアログを作成するだけで済みます。言わば枝葉に当たる部分の修正になりますから、システム全体への影響は軽微です。
通常とは異なる営業を行うそれぞれの日に設定を行う必要がありますが、一か月分をまとめて設定できるようにすればそれほど手間はかからないでしょう。また、休業日がまちまちなサロンに対しても有用です。
こうしてできたのが、このダイアログです。

一ヶ月分の日付一覧で設定対象の日付を選んでから<営業時間設定>ボタンを押すと、営業時間設定か休業設定が行えます。曜日別営業時間設定が簡単に行えるように、特定曜日をまとめて選択できる曜日ボタンも用意しました。過去に設定した営業時間を履歴として保存する機能も付けたので、最短5クリックで曜日別営業時間を設定できます。
将来、曜日別営業時間を正式サポートするかもしれませんが、現状ではこれで十分だと考えています。

サロンのホームページを見ていて、定休日が「毎週月曜・第一月曜火曜連休」のようなものを何度か見かけました。最初は「毎週月曜・第一火曜」のことだろうと気にしていませんでしたが、本当に同じなのかという疑問を持ちました。
それで考えてみたのですが、必ずしも同じ火曜日が休みになるわけではないことがわかりました。第一月曜の翌日が第ニ火曜になるケース、つまり、「1日」が火曜日の月です。「第一火曜」では「1日」が休みですが、「第一月曜火曜連休」では「8日」が休みになります。

気付いてしまった以上、対応せずにはいられません。
指定方法を考えた末、「指定曜日翌日」フラグを追加することにしました。このフラグが立っている場合は、指定された曜日の翌日を休みにします。上記の「第一月曜火曜連休」の場合は、「第一月曜」を指定した上で「指定曜日翌日」フラグを立てることになります。
この方法により、簡単に対応することができました。
同時に、スタッフ勤務時間帯の休日指定でも「指定曜日翌日」フラグをサポートして、スッキリしました。

‘さまれぼ！’でナビ実行中に表示される制御ボタン（<Quit><Focus>）の位置を変更しました。
例えば、受付スタッフ選択の場合はこんな感じでした。

制御ボタンが左上にあるため、タイトルバーの文字が読めません。
そのため、自分が今どういうスタッフを選択しているのかがわからなくなっています。

そこで、このように変えました。

これで、受付スタッフを選択することが視認できるようになりました。
制御ボタン表示位置を決定する処理が少し面倒でしたが（左上隅なら相対座標は(0,0)だが、右上隅ならダイアログ幅と制御ボタン幅を考慮する必要がある）、得られたものは大きいと思います。

‘さまれぼ！’では、ウィンドウ表示位置やリストビューの項目幅など表示に関する情報をレジストリに保存するようになっています。しかし、セキュリティソフトの中にはレジストリを監視して、レジストリへの書き込みの際に確認メッセージを出すものがあります。
そのままにしておくのは鬱陶しいので、‘さまれぼ！’に対してレジストリ監視を行わないようにセキュリティソフトの設定を行う必要があります。ユーザにはセキュリティソフト側に問い合わせてもらえば良いのですが、こちらに問合せが来るかもしれません。
それを避けるためにレジストリの代わりにローカルファイルに保存できるよう修正することにしました。

ここで問題になったのは、メインウィンドウなどです。
実は、‘さまれぼ！’の大部分はVisual C++で開発したのですが、メインウィンドウなどのUI部分ではDelphiを使用しています。そしてメインウィンドウの表示位置などをレジストリに保存するよう、Delphiでコーディングしてあります。
レジストリにもローカルファイルにも保存できるようにするために、VC++とDelphiとで別々にコーディングするのは二度手間なので、VC++モジュールに関数を追加してDelphi側で呼び出すようにしました。
こうして共通化することにより、テストも半分で済み、将来必要になるかもしれない修正にも簡単に対応できます。

ついでに、Delphiプログラム起動時にウィンドウがディスプレイからはみ出さないようにウィンドウ位置を補正する機能も追加しました。ちなみにVC++によるダイアログでは既にサポート済みでした。

ブログ用に作業手順をまとめたりテストを行ったりしている際に、気になった点があれば随時修正しています。
今回も、チャート上での操作で細かな修正を行いました。

作業ボックスをクリックすると、その作業を含む来店情報に属する作業ボックスだけが色付きのまま残り、他の作業ボックスは色抜き表示に変わります（作業ボックスの「強調表示」）。

ところが、来店情報を編集した後にチャートに戻ると、強調表示が解除されていました。
編集内容がわかりやすいように強調表示を維持するように修正しました。

この修正により、新しく技術来店受付を行った後も、受け付けた来店情報に属する作業ボックスが強調表示されるようになりました。

今回もテスト中に不便に感じた点から考えた改良を施しました。
テストで過去の来店履歴をまとめて入力していたのですが、同じ既存客を顧客選択ダイアログで何度もイニシャル抽出しなければならなかったのが面倒でした。
そこで、受付を行った顧客の履歴を保存しておき、顧客選択時に利用することにしました。既存客だけではなく、新規客も保存します。

これだけでは利用する場面があまりないかもしれませんが、顧客カルテ編集時にも利用できるようになっているので便利だと思います。

昨日テストで、フロントウィンドウの日付を現在から数ヶ月前まで何度も変えていました。その時感じたのは、何ヶ月にも渡る日付を行き来するのが面倒だということでした（現在に戻るのは簡単ですが）。
何とかできないかと考えた結果、一度表示した日付を履歴として保存しておくことを思いつきました。
ということで、このように表示した日付の履歴を選択できるようにしました。

顧客カルテ事前登録作業を行っていて気付いたのですが、システム運用開始までに全ての顧客カルテを登録できるとは限りません。運用しながら徐々に登録していくこともあるでしょう。その場合、カルテ未登録の顧客が予約したり来店したりということも当然あるはずです。
‘さまれぼ！’での作業手順を考えてみたのですが、現状では新規客を既存客に転換することはできないため、「顧客カルテ登録」で登録してから受付を行うことになります。これでは、慌しい受付時には追いつきません。

それで対策を考えました。
まず、新規客で一旦受け付けてから既存客に転換することを考えましたが、使い方がわかりにくいと感じました。
そこで、わかりやすく、かつシステムに対する影響ができるだけ限定的になるような方法を考えた結果、顧客選択時に登録できるようにしました。



これは、既存客登録を行った直後の状態で、登録した顧客が自動的に選択されています。
この後<既存客>ボタンを押せば、通常の既存客と全く変わらず受付できます。カルテ登録は通称だけ入力すれば行えますから、新規客として受付をした場合と手間は変わりません。
これが現状におけるのベストの方法だと思います。

運用に先立って行う顧客カルテ事前登録をご紹介しましたが、登録後の修正はともかく、登録作業を顧客カルテダイアログで行うのは少し面倒だと感じました。
事前登録は、他システムでの運用を行っているサロンはもちろん、手書きのカルテで顧客管理を行っているサロンでも必要な機能です。
それで、より手早く登録できる方法はないかと考えてきました。
ウィザード形式で主だった項目を登録する方法も考えましたが、数多くの顧客をまとめて登録するには、やはり不向きです。

そこで定番ですが、CSVファイルからの取り込みをサポートすることにしました。
他システムでCSV出力をサポートしていれば、それを手直しするだけで済みます。一から入力する場合でも、Excelなどの表計算ソフトでコピー・ペーストを駆使すれば、かなり手軽に登録できます。
CSV取込は割りと簡単に作成できそうに思われる向きもあるかもしれませんが、データが適正なものかどうかをチェックする必要があり少し面倒です。
これから作成を始めます。

尚、ウィザード方式についても具体的な実現方法まで考えてあるので、コンピュータに慣れていない人のために将来サポートする計画です。

初期設定プログラムの改修が終わり、「顧客属性拡張設定」が6ページ目で設定できるようになりました。
顧客属性拡張設定を定義している設定ファイルと初期設定左部に表示される説明文を変えるだけで異なる業種にも対応できるだけの汎用性も確保しました。
ただ、「摘要」は他の拡張設定とはちょっと違うのでサポートを見送りました。スタイル・来店動機・毛髪状況に比べると必要性が低いこともサポートを見送った一因です。
次回で設定手順をご紹介する予定です。

初期設定が終わりフロント設定の紹介に移っていましたが、バグに気が付きました。
フロント設定項目の中に設定がないものがあります。

いずれも「XXXX初期表示グループ」なのですが、「ＸＸ商品メニュー初期表示グループ」は設定されているべき項目です。それでソースを確認したところ、バグが見つかりました。
改修後は、次のようになります。

それとは別に改善点も見つかりました。
多様なサロンや業種に対応するため「顧客属性拡張設定」が用意されていることは既報の通りで、理美容業向けにはスタイル・来店動機・備考１・備考２・摘要・毛髪状況が用意されています。
これらは初期設定では設定できません。全サロン共通の項目ではないため、条件設定で行ってもらおうと考えたためです。
しかし、スタイル・来店動機・毛髪状況は理美容サロンにとって必要な項目です。
顧客属性拡張設定を定義している設定ファイルだけに依存するような汎用性を確保するのは難しいのですが、何とか考えてみることにしました。

さまれぼ！,サロン管理システム,サロン運営サポート,サロン経営,店舗経営,従業員管理,勤怠管理,顧客管理,ヘアサロン,理容,美容,理美容,エステサロン,エステティックサロン,ネイルサロン,フェイシャルサロン,ペットサロン,歯科医院,歯医者

サロン管理システム‘さまれぼ！’の顧客抽出部のテストを始める前に、一昨日は組込抽出条件の説明文、昨日からは組込変数の説明文を書いています。
バグを出さないよう常に集中が必要なプログラミングと違って割と気を抜きがちなのですが、細かい説明のためにソースを見直したりして、結構、改善点やバグが見つかります。
こういうところも気を抜かずに集中しなければならないと改めて感じました。

‘さまれぼ！’顧客抽出処理ＤＭ発行部の印刷レイアウト機能が完成しました。これで、顧客抽出処理の全機能のサポートが終わりました。
用紙ごと・抽出条件ごとに印刷レイアウトを設定できますが、標準のレイアウトが用意されているのでわざわざ設定しなくても使えます。
顧客データと連動した組込印刷項目のフォントや位置指定ができるほか、決まった文字列や画像を特定の位置に印刷できます。
これから顧客抽出処理全体に対して幾つか手を加えたい箇所があるので修正を施し、組込抽出条件などの機能説明を加えれば、テスト工程に入ります。

‘さまれぼ！’顧客抽出処理ＤＭ発行部のメール送信機能が完成しました。これで残りは、印刷レイアウト機能だけになりました。

SMTP認証や「POP before SMTP」などをサポートしたので、SMTPやPOP3の接続設定を行うダイアログの作成に結構時間がかかりました。
また、送信時にエラーが発生した場合の表示方法をどうするかという点も悩みました。当初は素直に送信後に一覧表示しようかと考えましたが、一覧を閉じた後で見直すことができません。そこで記録用のファイルを用意して、ＤＭ発行ダイアログ右部に顧客情報表示と共に表示することにしました。

現状のままでも十分使えるものになったと考えていますが、将来は不着メール処理やSSL/TLSによる通信の暗号化をサポートしたいと考えています。

メール送信時の認証でパスワードを入力するために、パスワード入力用の仮想キーボードを作成しました。

横から他人に見られてもわからないように入力文字を「*」で表示するのですが、これはエディットコントロールに「ES_PASSWORD」を付けるだけです。入力しやすいようにアルファベットの大文字と小文字も並べてレイアウトしました。
面倒だったのは、サポートしていなかった記号も追加しなければならなかったこと。
今まではよく使う記号だけをサポートしていましたが、キーボードに合わせてパスワードを変えてもらうわけにはいきませんから全てのASCII文字が必要になります。それで記号を追加したのですが、せっかくなので他のキーボードでも使えるようにしました。
これに伴い全体的にキーボードレイアウトの見直しを行ったため、テストが簡単なようにレイアウト確認用のプログラムも作成しました。

余談ですが、仮想キーボードのボタンは実はボタンコントロールではありません。枠なども含めて全て自力で描画していて、ボタンが押された時には枠の盛り上がりを反転させたりもしています。
とにかくボタンの数が多いのでリソースを節約したいという目的があったのですが、将来的には丸いボタンなどもサポートして、ユーザが自由に選べるようにしたいということもありました。
将来のバージョンアップでデザイン面を見直したいと考えていますが、この時にでも是非サポートしたいと考えています。

さまれぼ！,サロン管理システム,サロン運営サポート,ヘアサロン,理容,美容,理美容,エステサロン,エステティックサロン,ネイルサロン,フェイシャルサロン,ペットサロン,歯科医院,歯医者

‘さまれぼ！’顧客抽出処理ＤＭ発行部の本体はほぼ出来上がり、残りはメール送信と印刷レイアウト機能だけとなりました。印刷レイアウト機能とは、抽出時に生成された文面（最終文章）の印刷位置を指定するものです。予め設定したものがあり通常使う必要のないものなので、グラフィカルなものではなく用紙の左上隅からの距離を0.1mm単位で指定するものを考えています。

ＤＭ発行部で悩んだのが、数万件の抽出結果の扱いです。現実にはもっと絞り込んでからＤＭ発行を行うはずですが、システム上は扱えるようにする必要があります。一番簡単なのは件数を制限してしまうことですが、私の流儀に合いません。
顧客抽出メインでは1000件ずつのページに分けて一覧表示するようにしましたが、ＤＭ発行部でも同様のページ管理を行うのは二度手間な感じがします。
そこで思いついたのが顧客抽出メインで表示中のページに対してＤＭ発行を行うという方法です。これなら、プログラミング上もすっきりしますし、使い勝手も悪くないはずです。
その結果、顧客抽出メイン下部は次のように変わりました。

一覧表示には結構時間がかかるので、環境によって１ページの件数を変えられるようにしました。上記画像では「100件」ですが、一応「100件」から「3000件」まで選べるようになっています。
抽出結果が「3,008件」なのに「31ページ」ではなく「30ページ」になっているのは、端数が100件未満の場合は最終ページに詰め込むようにしているためです。その結果、30ページ目には「108件」を表示するようになっています。8件だけ残してＤＭ発行するのは面倒だという考えからです。

テスト抽出時にはＤＭ発行できませんが、この時もＤＭの文面を確認できるように「代表最終文章を表示する」ボタンを付けました。これをチェックすると、顧客抽出メインで文面を確認できるようになります。

こういった開発状況ですが、今日はメール送信機能の作成に入ります。

さまれぼ！,サロン管理システム,サロン運営サポート,ヘアサロン,理容,美容,理美容,エステサロン,エステティックサロン,ネイルサロン,フェイシャルサロン,ペットサロン,歯科医院,歯医者

顧客抽出プログラムのＤＭ発行部を作り始めました。
印刷時のイメージを画面上で確認できるようにして、ハガキやA4用紙への印刷や、メール送信をサポートする予定です。

さまれぼ！,サロン管理システム,サロン運営サポート,ヘアサロン,理容,美容,理美容,エステサロン,エステティックサロン,ネイルサロン,フェイシャルサロン,ペットサロン,歯科医院,歯医者

昨日の思い付きを実現するため、顧客抽出プログラムの組込抽出条件「来店予測勧誘」を修正しています。
とりあえず抽出処理のコーディングが終わって実現できることが確定したので、技術品類型条件設定を編集する部分の修正に入りました。
この部分が完成すれば、実際に「来店予測勧誘」を動かせるようになります。

さまれぼ！,サロン管理システム,サロン運営サポート,ヘアサロン,理容,美容,理美容,エステサロン,エステティックサロン,ネイルサロン,フェイシャルサロン,ペットサロン,歯科医院,歯医者

サロン管理システム‘さまれぼ！’の顧客抽出プログラムには組込抽出条件が用意されていて、自サロンに合った簡単な設定を行うだけで高度な抽出処理が行えます。その中に「来店予測勧誘」があることは以前の記事に書きましたが、来店予測の算出方法を変えようかと考えています。
「来店予測勧誘」では、過去の来店履歴から作業類型ごとに施術周期日数を算出し、それに基づいて来店日を予測しています。しかし、当初は技術品類型ごとに周期を算出するつもりでした。月別の来店回数など来店に関する集計に技術品類型を用いているためですが、技術品類型が他の要素も含んでいる場合に対応できません。
例えば、パーマには通常カットも含まれるため、カットの周期を算出するためにはパーマも考慮しなければなりません。ところが、技術品類型では他の技術品類型との関連が把握できません。作業類型であればこのようなケースにも対応できるため、作業類型を使うことにしました。
この時点ではこれで十分だったのですが、システム本体でＤＭ発行履歴を扱う修正を始めてから、ＤＭ発行の効果を来店という形で把握できないかと考え始めました。それには、技術品類型に基づきＤＭ発行を行う必要があります。
そこで思い付いたのは、ある技術品類型が他の技術品類型を含んでいる場合に、それらの技術品類型を「含有技術品類型」として指定することです。
何とかこれで実現できそうなのですが、作業類型に基づく「来店予測勧誘」が無駄になってしまいます。顧客抽出プログラムだけではなくシステム本体にもかなり手を加えて、それなりに時間も費やしました。
ということで「施術予測勧誘」として残すことにしました。サロンによっては、こちらの方がより正確な周期が算出できるかもしれません。

前回の続きです。

既報のように、外部データ取込処理で、「'admin'によってロックされているので更新できない」というエラーが発生しました。
テスト用の100件程度のレコードを取り込む際にも発生していたのですが、レコード追加・更新前に100msの待ち時間を入れるようにしてから発生しなくなりました。
ところが、8000件近くのレコードを取り込んでみたところ、必ず発生するようになりました。待ち時間を500msにしてもダメで、早ければ300～400件、遅くても1000件程度で発生します。発生するのは、来店履歴テーブル追加時がほとんどで、たまに来店履歴詳細テーブル追加時でも起こりました。
ODBCドライバが返すエラーコードは一定ではなく、その上定義されているものではないため、エラーコードからロックされているというエラーかどうかを判別することはできません。

とりあえずSQLExecDirect()でエラーが発生したら再試行するようにしてみたのですが、再施行時もエラーになり改善されませんでした。再試行前に5秒間（長い！）の待ち時間を入れ、SQLCancelとセットでそれを10回繰り返すようにしてもダメなので、おそらく、一度発生してしまうと回復できないのでしょう。
テーブルが更新可能かをチェックするAPIか、エラーをリセットするAPIがないか調べたのですが、見つかりませんでした。
エラー発生後に、一旦SQLFreeHandleやSQLDisconnectでリソースを解放してからSQLConnect等で再接続するようにしてもみましたが、解消されません。

ODBCドライバ設定で「排他」をチェックすると、完全に処理が終わるまで制御が移らないのではないかと考えましたが、「既に使用されているので、使用できない」というエラーが出て、全く使いものになりません。

この時点で、一つのファイルに複数のテーブルが格納されていることが原因ではないかと思いつきました。来店履歴関係の三つのテーブル（来店履歴・履歴詳細・ＤＭ履歴）を一つのファイルに格納していますが、ドライバが各テーブルに順次アクセスするのではなく、テーブルごとに独立してアクセスしているのではないかと考えました。履歴詳細はレコードが大きいため更新に時間がかかり、履歴詳細を更新している最中に来店履歴を更新しようとしてエラーになるのではないかという仮説です。
そこで来店履歴関係の三つのテーブルを独立したファイルにしてみたところ、8000件が問題なく取り込めるようになりました。

マイクロソフトが開発したものをこれ以上突き詰めても意味がないので、とりあえず、これで良しとしましたが、今後問題があればきちんと取り込めた箇所から継続して処理するレジューム機能をサポートする必要があるでしょう。

抽出結果をCSVファイルに出力する機能を作成し始めたのですが、データベースアクセスの排他制御がどうなっているかが気になりました。
‘さまれぼ！’ではODBCドライバ経由でデータベースファイルにアクセスしています。そしてとりあえず手元にAccessがあるのでそのドライバを使っています。このドライバは元々Windowsに含まれているので、改めて導入する必要はありません。
顧客抽出プログラムはメインプログラムとは独立していて、メインプログラム使用中に顧客抽出するような使い方も想定しています。
顧客抽出プログラム開発に先立って、一方は読み書き、他方は読み込みを連続して行うプログラムを用意して、同時に動かしてみました。この時は特に問題なく動作したのですが、完全に問題がないとは言い切れません。
というのは、過去に「'admin'によってロックされているので更新できない」というエラーが発生したことがあるからです。
もう一年以上も前のことですが、別システムのデータを取り込む処理を作成していて、それを実行している最中に発生しました。単一のプログラムしかデータベースにアクセスしていないにもかかわらず「ロックされている」と出るのは不思議でした。
いろいろ試行錯誤してとりあえずエラーは出なくなりましたが、次回はその経過について取り上げようと思います。

さまれぼ！,サロン管理システム,サロン運営サポート,ヘアサロン,理容,美容,理美容,エステサロン,エステティックサロン,ネイルサロン,フェイシャルサロン,ペットサロン,歯科医院,歯医者

とりあえず、ＣＳＶ出力部の作成に移ることにしたのですが、それに先立って組込抽出条件を動かしてみることにしました。
幾つかエラーが発生しましたが、大部分は簡単な修正で片付きました。
これは想定内でしたが、「紹介御礼」で予想外の少し大きな問題がありました。指定期間中の新規客紹介先の一覧をＤＭ文書中に記述する箇所があるのですが、紹介先一覧を取得する処理で躓きました。
抽出処理全体で顧客マスタを選択して、その選択結果に基づいて順次読み出しているのですが、紹介先一覧を取得しようとすればその時点で選択がキャンセルされ、それ以降順次読み込むことができなくなります。
その対処には少し悩みましたが、結局、Variシステムのエンジン部に新しい機能を組み込むことで対応しました。

残っていた組込抽出条件のＤＭ文書の下書きが終わりました。
「来店予測勧誘」が難しかったのですが、後は簡単でした。
次は実際に顧客抽出プログラムを使ってＤＭ文書を仕上げるのですが、それに先立って組込変数指定を作成を始めます。ここでは組込変数の選択肢やサンプルを指定します。

今日も朝から‘さまれぼ！’開発です。
昨日に引き続き、組込抽出条件のＤＭ文書を作成しています。
「紹介御礼」と「次回勧誘」の文面の下書きを作成し終わったところです。
「紹介御礼」の場合、次のようになります（レイアウトの関係で、必要以上に分を分割しています）。

　　メッセージ
　　　　共通文章単位.宛名
　　　　固有文章単位.本文
　　　　共通文章単位.差出人
　　固有文章単位.本文
　　　　"いつも当サロンをお引き立ていただきまして、"
　　　　"厚く御礼申し上げます。"
　　　　"また、この度は"
　　　　顧客属性.紹介客名一覧
　　　　"をご紹介賜りましてありがとうございました。"
　　　　"つきましては、"
　　　　顧客属性.顧客苗字
　　　　"のメンバーカードに"
　　　　固有拡張変数.ポイント数
　　　　"ポイントを加算させていただきますので、"
　　　　"また近いうちに是非、当店へお立ち寄りください。"
　　　　"スタッフ一同、心からお待ち申し上げます。"

「共通文章単位.宛名」と「共通文章単位.差出人」は複数のＤＭ文書で使われる文章単位です。「顧客属性.紹介客名一覧」と「顧客属性.顧客苗字」は組込変数で、顧客に応じて変わります。

このＤＭ文書は比較的単純な事例で、「次回勧誘」はもっと複雑になります。さらに部位現象の予想や他店で施術した内容をお勧めする文章をサポートするために、新たな組込変数をサポートする必要がありました。

複数のＤＭ文書で使われる拡張変数や文章単位の共通化を行ったため、昨日作成した分にも手を加えました。今後も修正する可能性があるため、全ての下書きが完成してからシステムに組み込むことになります。
今回は複数のＤＭ文書をまとめて作成するので下書きを使いましたが、通常は顧客抽出プログラム上で全ての作業を行います。いずれ、その手順もご紹介する予定です。

今日は組込抽出条件のＤＭ文書を作成しました。
ＤＭ文書は、抽出条件に一致して抽出された顧客に対して送るＤＭの文面を定義したものです。顧客属性や来店情報に応じて自由に文面を変えることができます。
単に文章を考えるだけでは済まなくて、文面を実現するために新たに組込変数を追加する必要もあり、今日は新規来店御礼と既存来店御礼だけサポートできました。

昨日は、一昨日修正した提供商品単位変更の動作確認から始めたのですが、その過程で幸運にもバグが見つかったので、その改修も行いました。

その後、これまでの作業で気になっていた抽出結果表示の高速化に取り組みました。
まず、プログラム起動時に前回の抽出結果を自動的に読み込むようにしていた点を見直しました。いつでも作業を中断できるようにという配慮でしたが、ボタンによりユーザの意思で読み込むように変えました。
次に、数万件の抽出結果を扱えるように1000件ずつのページに分割して表示するようにしているのですが、表示に時間がかかるので一回表示したページはキャッシュするようにして、二度目以降の表示を高速化しました。
さらに、顧客に関する情報は抽出結果を表示する際に顧客マスタから読み込むようにしていましたが、抽出結果ファイル内にそれらの情報も格納するようにしました。それにより、半分以下の時間で表示できるようになりました。

このように、動作確認を行っている最中もさまざまなアイデアが沸いてくるので時間を取られますが、どんどん良い製品に仕上がっています。

昨日は、まずデータベースへの項目追加を条件設定機能に反映しました。
具体的には、一回分しか来店がない顧客に対しても来店予測できるように、作業類型条件設定に「標準施術周期」を追加しました。まだ一度しか来店していない顧客を繋ぎとめるためには必要な機能です。
同時に、来店予測時点にどの部位にどのような現象が起こっているかをＤＭ文面に記述できるようにするため、部位現象条件設定に「連結作業類型」を追加しました。これにより、「えりあし（部位）のはね（現象）が気になる頃」といった記述が可能になります。

次に組込抽出条件を見直して、来店履歴に関する多種の情報をＤＭに記載できるように修正を行いました。初回来店履歴や直近来店履歴の情報をＤＭ文面から参照可能な来店情報として割り当てる機能です。

その後、顧客抽出中に抽出比率を表示するようにしました。
処理顧客数に対する抽出顧客数の割合をリアルタイムで表示するもので、予め予想していた比率との差が大きくなった場合に抽出処理を中断し、抽出条件を変更後に再度抽出を行うことを想定しています。

それが済むと、ふと思いつきシステム本体の修正を行うことにしました。
提供商品数の単位は、複数の購買品をまとめることもあるために「品」で固定化していたのですが、提供商品と購買品とが一対一の関係にある場合は、購買品の単位（「本」「個」など）を使うべきだろうと思いつきました。
とりあえず修正して一箇所で修正確認をしましたが、今日は残りの箇所での動作確認になります。

前々回の記事で「６月から強力な目玉機能サロン管理システム‘さまれぼ！’に組み込む作業を行っている」と書きましたが、実は「顧客抽出」機能のことです。こう言うと大した機能じゃないと思われるかもしれませんが、実際はこれ単独でも製品として販売できるレベルのものです。この点については、今後説明を進めていくうちにご理解いただけると思います。
この顧客抽出機能の開発を始めてから２ヶ月近く経ちますが、予定では来月中に一通り完成することになっています。
ブログタイトルに「開発日記」とあることですし、これについては、随時、開発状況をご報告することにしました。
というわけで、今回は「顧客抽出」がどういったものかをご説明します。

「顧客抽出」は、大きく「抽出部」と「出力部」に分かれます。「抽出部」で抽出条件に合致する顧客を抽出し、「出力部」で抽出された顧客に対してＤＭ発行を行ったり、顧客情報をＣＳＶファイルに出力したりします。
このうち、「抽出条件」が特徴的で、顧客の属性に応じて自由に抽出条件設定が行えるのはもちろんのこと、顧客属性に応じて文面を変えたＤＭを生成することができます。よく使う抽出条件があらかじめ組み込まれているので、使い始めでも十分性能を発揮できますし、ユーザが自由に抽出条件を作成することもできます。
ちょっとした簡易言語といった感じで説明が難しいのですが、抽出条件がどのような構成になっているかを以下にまとめ、今回は終わります。次回からは、その日開発した内容を中心にして、気が向けば機能の説明を加えるつもりです。

抽出条件
    分岐式（分岐因子の集合体）
        分岐因子（分岐基準＆比較演算子＆比較対象値）
            分岐基準（組込変数｜拡張変数｜分岐式 |
                          組込関数呼出）
            比較対象値（定数｜組込変数｜分岐式）
    拡張変数
    組込関数呼出
    ＤＭ文書（最終文章の集合体）
        最終文章（文章単位）
            文章単位（結合文｜条件文）
                結合文（結合文要素の集合体）
                    結合文要素（定数｜組込変数｜拡張変数
                                      文章単位｜色指定）
                振分文（分岐基準＆選択肢一覧）
                    分岐基準（組込変数｜拡張変数｜分岐式）
                    選択肢一覧（選択肢の集合体）
                        選択肢（分岐値(定数)＆結合文）

サロン管理システム,サロン運営サポート,ヘアサロン,理容,美容,理美容,エステサロン,エステティックサロン,ネイルサロン,フェイシャルサロン,ペットサロン,歯科医院,歯医者

サロン管理システム‘さまれぼ！’の特長である「ナビシステム」の実装方法を根本から見直しました。ウィンドウを半透明にするWS_EX_LAYEREDを試してみようと考えたためです。
ナビ実行中は半透明ウィンドウ（「ガイドウィンドウ」）で対象ウィンドウ全体を覆い、マウスクリックを許可するボタンやリストボックスなどのコントロール類（「入力許可領域」）をだけを透過表示しています。
WS_EX_LAYEREDで入力許可領域だけを部分的に透明にできるかどうかわかりませんでしたが、とりあえずお試しプログラムを作ってみました。その結果、思いのほか簡単に実現できてしまいました。
入力許可領域のマウスクリックがガイドウィンドウではなく直接コントロール類に伝わる点が予想外で結構大きな修正が必要でしたが、ソースから不要な箇所を削除していく作業が中心だったので、ソースがシンプルでわかりやすくなりました。

Vistaでも動作確認を行いましたが、Desktop Windows Manager（DWM）が有効な状態できちんと動作しました。ただ、対象ウィンドウが表示される直前にガイドウィンドウの入力許可領域を一旦なくそうと考えたのですが、対象ウィンドウのコントロール類がほとんど表示されなくなるという問題が判明したため諦めました。DWMの実装が甘いのではないかと思います。
とはいえ、XPよりVistaの方が表示が高速で、XPでは気になったガイドウィンドウ更新時のチラツキがほとんど感じられません。

表示速度の関係で従来は対象ウィンドウだけをガイドウィンドウで覆っていたのですが、速度が改善されたのでディスプレイ全体を覆えるようになりました。

対象ウィンドウだけを覆うという制限から仮想キーボードやメッセージボックスを表示する際はガイドウィンドウを消去していました。仮想キーボードは入力許可領域であるボタンやエディットボックスだけでできているので覆う意味がなく、メッセージボックスではメッセージ自体に意味があるので覆い隠すことが適当ではないためです。
ディスプレイ全体を覆うようにしたことで、ガイドウィンドウを表示したまま仮想キーボードやメッセージボックスを丸ごと入力許可領域にできるようになりました。しかし技術的には面倒で、特にメッセージボックスはウィンドウの表示位置やサイズが前もってわからないので苦労しましたが、何とか解決できました。
こうしてナビシステム開発当初に思い描いていた姿を実現でき、最初のバージョンから満足できるものを提供できるようになりました。

仮想キーボードの話が出たので、今回は技術的な話を少し。
サロン管理システム‘さまれぼ！’の仮想キーボードは、基本的にSendInput APIによってキー入力を模倣することで実現しています。例えば、「あ」を入力する場合は「a」を模倣します。ただしこれはIMEをローマ字入力モードで使っている場合の話で、かな入力モードで行っている場合には当てはまらず、「a」を模倣すると「ち」になります。
そのため、一時的にIMEの入力モードをローマ字入力に切り替える必要がありますが、それを実現するはずのImmSetConversionStatus APIは、必ずしも期待通りの動作を行いません。例えば、標準装備のMicrosoft IMEにしても、95や97では動作しますが、98や2000では動作しません。この程度のこと、なぜきちんと動作するよう実装しないのかマイクロソフトのやることは理解できませんが、そうも言ってられません。
それで考えたのが、ローマ字キー（Alt+ひらがな）を模倣することです。
これで「ほぼ」期待通りの動作をするようになりました。「ほぼ」というのは、たまに切り替わらないことがあるためです（原因不明）。切り替わらない場合のためにローマ字キーを模倣するためのボタンを仮想キーボードに追加したのですが、スマートな方法ではありません。
どうしようか考えながら他の部分の開発を進めていましたが、ある時、全く違う発想が浮かびました。結構大きな修正が必要でしたが、現在では全く誤動作することなく仮想キーボードを使えるようになりました。
ついでに言えば、ImmGetConversionStatus APIも入力モードに関しては期待通りの動作を行いません。「a」を模倣した結果で判別するという方法も考えましたが、一瞬でも表示されてしまうため不細工です。
結局、ありきたりですが、どちらのモードで使用しているかを利用者に予め指定しておいてもらうようにしました。

サロン管理システム‘さまれぼ！’の開発は、ずっとWindows XP上で行ってきました。
正式リリースまでにはWindows Vistaに対応する必要があると考えていましたが、サービスパックが出てから行うのが効率的です。
しかし、どうしても気になる点があり我慢できなくなったので一通り動作させてみました。
気になっていたのはDesktop Windows Manager（DWM）によりナビシステムのガイドウィンドウの表示に問題があるのではないかという点なのですが、残念ながら悪い予想が当りました。
さらにクリック検知にも予想外の問題がありました。
いろいろ試行錯誤しましたが根本的な解決には至らず、ナビ実行中だけ一時的にDWMを無効にすることでとりあえず正常に動作させることができました。
将来的にはきちんと対応する必要があるとは思いますが、現状ではこれで良しとします。
サービスパックが出てからシステム全体の最終的な動作確認を行う予定です。