スモールビジネスのIT日誌

• (2012-11-22 05:36:53)

スタッフのスケジュール管理にグループウェアは効果的。いろいろ市販されているが、スモールビジネスは結局、単機能しか使わない。単機能で優れた使い勝手がいい(2012/11/22 小平探検隊)

お世話になったMirai'Z

この2年くらいMirai'Zを利用してきた。無料だなんてありがたいサービスだった。

しかし、入会した当時の会社さんはどうも買収されたらしく、このサービスも、いつ突然強制終了されるかわからないリスクを考えて、新しいグループウェアサービスを探している。

Mirai'Zの感想は次の通り。グループウェアの機能一通りをすべて取り込もうとした意欲的なシステムだったが、広範囲に手を広げすぎて、一つ一つの機能がやや中途半端な印象だった。

カスタマイズ性も高くないし、見た目のデザインも今となっては古い。データのバックアップは昔はできたらしいが、今はできない。

最近レスポンスの遅さが目立つのは気のせいだろうか。買収先の会社さんにこのサービスを継続するビジネス上の意味がなくなったかもしれないと空想している。

1アカウントで、カレンダページ1枚あれば充分な現状

当社の場合は特殊かもしれないが、グループウェアに求める機能はメンバー全員のスケジュール表。これさえあればよい。

むしろ、他の機能は邪魔である。

プロジェクト管理や稟議フローなどすべてWeb上に移行することがGoogleの理想で、世界全体が「クラウド」というトレンド名でこの傾向にあるが、ローカルで走るExcelのようなすぐれたソフトウェア体験を知っている人間には「Webベース=機能的退化」の印象は避けがたい。

またセキュリティ上の不安もまだまだ実績待ち。

もちろん「Webベース=他の物理的に離れたメンバーとのシェア化」というメリットは絶大なので、どちらが優れているという話ではない。当社の場合、月ごとのカレンダー1枚ページがあれば今は足りている。

アカウントも1アカウントしか必要ない。個人の特定は各スケジュールにイニシャルを付けるというルールで問題なく機能している。おそらく、メンバー10人までこれで行けると考えている。

Aipo

非常に簡単にインストールができて、機能もシンプルで好きだった。しかし、自社サーバーは負担だ。インターネット上に公開した際はセキュリティ対策も必要で無料のサービスが多数あるなかで、あえてグループウェア用の自社サーバーを運用するメリットは少ない。

しかし、グループウェアを本気で利用し、徹底的にカスタマイズしたいユーザーには本当にありがたい製品だろう。

Aipo＋

Aipoのクラウドバージョン。サンプルIDやデモ画面が準備されていないので、登録するまで機能チェックできない。まずは登録してチェック。第一印象は「色が薄くて文字が見えない」。今時はこういう色合いが好まれるのか。

さまざまな機能が「アプリ」という名で利用可能。意欲的に盛り込まれている・・・Webメール、アドレス帳、スケジュール、タイムカード、タイムライン、ブログ、ユーザー名簿、ワークフロー、伝言メモ、共有ToDo、共有フォルダ、報告書、掲示板、更新情報

もともとAipoを知ったきっかけは「タイムカード」だったが、今は不要なのでこの中で興味があるのは「スケジュール」のみ。これを月のカレンダーとして利用できれば自分の場合、ハッピー。ログイン後のデフォルトトップ画面が「タイムライン」固定という点が自分的にはおしい。

どんな製品でも、機能がありすぎると、それぞれが中途半端になるリスクが難しい。単機能で高い完成度を目指すと潜在マーケットが縮小するし。悩ましい。

サイボウズLive

かんたんに使いたいユーザーにはグッドなチョイス。本日アカウントを取得し使ってみた。「設定項目がほとんとない」が第一印象。設定しなくてもすんなり使えてしまうところが不思議な感じ。それだけこなれた製品なのかな。

マイカレンダーを開けてスケジュールを記入する際、「詳細に書けるボタン」「簡単に書けるボタン」の2つが並んでいたことに感動した。こういうささやかな「使い勝手」がシステムの勝敗を分ける。

毎日に使うソフトはほんのわずかな一手間が大きな負担になることを知らないシステム開発者が多いなか、ユーザーの負担を減らすちょっとした工夫を感じる。

こんな配慮があるソフトは長く使えば使うほど真価が評価される。

期待できそう。

(現状の不満)平均的なカレンダーの月表示は「1日から月末まで」だが、こちらは先週の(月)または(日)から1ヶ月がデフォルト表示。「今月」ボタンを押せば通常表示になるが、先月と来月のハンパ日も同じ明るさなので「どこからどこまでが今月か」がぱっと見られない。使っているウチに目が慣れるのかな？

今後試すかもしれないサービス

特別なクライアントソフトを入れる必要があると、私のモチベーションはぐっと下がるので、ないことを祈る。まあ、でも サイボウズLive、が今日のところ気に入ったので、当分、試すことはないかもしれない。

・Gridy
・GroupSession
・Thetis
・・・・

• (2012-11-21 10:23:20)

もっと早く・簡単に解決できた問題をむだに放置したミスの記録(2012/11/21 小平探検隊)

案外簡単にやれるのに

数ヶ月前より、クライアントからカートが動かないという問い合わせがちらほらきていた。OSやブラウザの種類を問い合わせるも、詳しくないクライアントが多く、今ひとつはっきりしない。

また自分のPCからはいかなるブラウザも、IEのいかなるバージョンも正常動作するので「調べます」と返答してそのまま数ヶ月放置状態に陥っていた。

滅多に注文のないページだけに影響は大きくないが、企業のサイト運営ではありがちなパターンの縮図だ。

ちょっと知恵を絞れば労力なしに解決できるものもある

一昨日、再度問い合わせがあったので、よくやく重い腰を上げる。自分のPCからは再現性がないので、スタッフに再現性がでるか自宅PCで確認してもらったところ、IE9で発生することが軽く判明した。

なんだ、再現するじゃん！

わずかな手間を惜しみがちな人の性質

これが率直な感想である。わずかこれ程度の手間を私は惜しんで再現テストをしてこなかったという事実を知る。よくあるパターンかもしれない。

「IEのいかなるバージョン」もテストしたつもりでいたが、実際はIE5.5 - IE8までであり、IE9はテストできていない(OSがXPなので)。

自宅のPCはWin7でIE9がインストールされているが、不具合のためこの数ヶ月立ち上がらない状態にある。OSの再インストールしか方法はないようで、こちらもIE9のテストができなかった。

しかもすでに体験済みのトラブル

IE9でトラブルの再現性が確認できることで、すぐに思い浮かぶことが。1年前にも同じトラブルで苦しんでいたような記憶がある。このサイトを検索すると軽くでてきた：

ブラウザシェアの問題、IE9でカート不具合

不具合をムダの放置した体験の記録である。

• (2012-11-17 15:03:32)

---

2012/11/17　「123- 1234」のよぷな郵便番号が取り込めないトラブル。8ケタ以上の文字は破棄される仕様らしい

---

なぜだか不明だが、ケータイの人の郵便番号が「123- 1234」のようにハイフンの後にスペースが入る場合がある。

これを取り込むと「123- 123」と最後の1文字が削除されて「郵便番号」フィールドに格納される。はじめはフィールドサイズが「8」だからと予想したが、サイズを増やしても改善されない。

いろいろ原因を探ったが不明。おそらくotegaruのプログラムでフォーマットチェックがされており、8バイトしか受け付けないのだろう。よって、対策の方法はない。

• (2012-11-17 14:41:46)

レポートで商品名に応じてフッタのテキストボックスにメッセージを入れる

(2013/04/07)

商品明細のエリア(サブフォーム)

フッタに非連結テキストボックスを作成。

そのプロパティ操作で可能。

・「商品数の合計」を入れる方法は簡単 → 非連結テキストボックス → プロパティ →

コントロールソース = Sum(IIF([商品名] Like "*商品名の一部*",[数量],0))

・メッセージを入れる方法(間違えやすい) →

= (IIF([商品名] Like "*商品名の一部*","プレゼント対象",0)

※最終レコードにターゲットの文字列が含まれる場合のみメッセージが入る。前レコード読み込んでくれているかもしれないが、判断対象は最終レコードだけになる。

・メッセージを入れる方法(今回の解決策) → 非連結テキストボックス → プロパティ →

コントロールソース

(1)= Sum(IIF([商品名] Like "*商品名の一部*",[数量],0))

(2)非連結テキストボックス → プロパティ → 「書式」プロパティを、たとえば

　　「#"枚 プレゼント対象";;0」

　　「"※母の日キャンペーンプレゼント： "#"個";;0」

クエリで重複データを削除

(2013/04/01)

クエリにてテーブルに含まれるの重複データを削除する方法 →

クエリで新規作成 → 「DM_配信」フィールド1 → SQLビューにて「DISTINCT」を挿入・実行

→ SELECT DISTINCT DM_配信.フィールド1 FROM DM_配信;

重複データが削除された状態で、テーブルに落とす

デザインモードにて → 「クエリ」 → 「テーブル作成」 → 「DM_配信2」

削除用テーブルを用いてテーブルのレコードを削除

(2013/03/10)

サブクエリを使おう。

(1)2つのテーブルを並べ結合クエリでSQLを得る

(2)ターゲットテーブルを削除クエリとしてマウントし、where部に上記のSQLを入れる。このときテーブルは選択クエリで生成されたダイナセットでは動作しないかも(本日やった範囲ではフリーズした)。

クエリからテーブル生成

(2013/03/10)

今更ながら、あれ？という感じ。クエリーのメニューに「選択クエリ」「更新クエリ」「削除クエリ」などと並んで「テーブルを作成」をいう項目がありました。

注文キャンセルを削除クエリで処理

(2013/02/27)

これは以前、DMの削除クエリでやったことがあるのですぐにできると思ったが、忘れていて案外はまった。

キャンセルがあった場合、キャンセル確認のメールを返信する。そのメールデータを元に削除クエリで注文キャンセルを自動化する。

(1)キャンセル確認メールを定型化し、dbに取り込む

(2)クエリ「本日のキャンセル」を作成

(3)「01受信データ」テーブルと「本日のキャンセル」クエリから「本日のキャンセルリレーション」クエリを作成。受注番号で結合する。結合プロパティの向きは「本日のキャンセル」 → 「01受信データ」

(4)上記クエリで、受注番号をリンクするSQLコマンドを得る(サブクエリ)

(5)新規の削除クエリ「本日のキャンセルリレーション削除」を作成。受注番号のフィールドだけ準備する。その抽出条件に上記SQL込まんとを入れる。 → In (SELECT [01受信データ].バッファ01 FROM 本日のキャンセル INNER JOIN 01受信データ ON 本日のキャンセル.バッファ01 = [01受信データ].バッファ01)

AccessでDLookup関数は使わない方が普通？

(2012/02/01)ExcelではDLookup関数はよくお世話になる。しかし、AccessでDLookup関数を使う意味はあるのか？

フォームのリストで支払方法のソートを行う。支払方法名が「クレジット」「コンビニ決済」など固定されているので、希望通りにソートができないので、支払方法名に番号を与え、その番号でソートすることに。番号を振るさい、支払方法名と番号の対比表テーブルを作り、Dlookupで番号の取得を試みる。

しかし、よくよく考えれば「他のテーブルを見に行ってデータを引っ張ってくる」考え方はクエリそのもの。DLookupを使うこと自体、なんかおかしい。DLookupの中身がわからないので今ひとつモヤモヤだが、使う必要はないだろう。

(1)2つのテーブルからクエリリンクでダイナミックの支払い番号を取得 → ただし、テーブルの更新ができなくなる

(2)2つのテーブルからアクションクエリを走らせ、単一テーブルを更新。

フォーム起動時のカーソルの位置や日本語入力の設定

(2012/11/17)フォームを開くと特定のフィールドにカーソルを当てておき、かつ日本語の入力モードも指定しておく → わずかな手間なので今まで手作業だったが、何年もやっていると大きな負担という認識の欠如が、そもそもの問題。

---

あるフォームを開けるといつも使わないフィールドにカーソルがある。タブオーダーで設定できるらしいうが、サブフォームなどあると超えられない。そこでGoToControlメソッド

'フォーカスを検索窓に移動する

Dim ctl As Control

Set ctl = Forms![F_01受信データ]![キーワード]

DoCmd.GoToControl ctl.Name

このフォームを開けるといつも日本語入力が、オフになっており、オンにすると「固定モード」になる。たいしたことでないので、このままできた。しかし、長い年月のこのわずかな作業が大きなムダになっている

フォーマスをターゲットのフィールド(今回の場合、非連結のテキストボックス)に移して、このテキストボックスのプロパティを下記のように設定

・「その他」タブ

・「IME入力モード保持」 はい

・「IME入力モード」 コントロールなし → ひらがな

リンク結合されたクエリテーブルは更新できない？

(2012/01/22)クエリの演算フィールドとテーブルのフィールドを結合したクエリは更新できない？

---

strSQL = "UPDATE 01受信データ INNER JOIN Q_DSK_支払通知 ON [01受信データ].管理番号 = Q_DSK_支払通知.ユーザー使用欄２改 SET [01受信データ].入金 = '1';"

DB.Execute strSQL

Q_DSK_支払通知.ユーザー使用欄２改フィールドが、更新済みデータならできるが、ダイナミックに生成した演算フィールドの場合、エラーとなるようだ。

結合したテーブルの更新は時々、更新できなくなるケースがあるが、ちょっと慣れない。

---

(2011/12/04)削除用テーブルでレコード削除

---

一斉同報メールリストの作成

一斉同報用のメールリストを作成。全顧客リストなら問題ないが、DMの配信を希望されない方々をリストから削除する必要がある。また、ケータイメールとPCメールは分けたい。

削除クエリで楽々？

DM非配信リスト(DM非配信)を作成する。全顧客リスト(DMリスト)からこのリストのメールアドレスを削除する。Accessクエリには「削除クエリ」があるので気楽に作れるかと予想していたが、簡単ではなかった。

新規クエリで、DMリスト＋DM非配信のテーブルをマウントして、削除クエリをクリクリといじってみるが全然わからない。

サブクエリで削除

こんなときはネットにお伺いを立てるにかぎる。「サブクエリ」を作成して削除せよ、という教えを知る。

サブクエリって何だ、という感じ。

選択クエリの抽出条件に「平文」でなく「SQL文」を代入したもののようである。そのSQL文の部分がサブクエリのようだ。

「メインテーブル」と「削除用テーブル」を並べて操作するという基本的な考え方は間違っていないが、実際の削除クエリは「メインテーブル」単体で、サブクエリを元に削除していく。

操作手順

・顧客テーブルを直接操作したくないので、コピーで「DMリスト」テーブルを作成

・新規クエリで、DMリスト＋DM非配信のテーブルをマウント

・DMリストはメールアドレスを選択(SQLパネルにドラッグ)

・2つのテーブルをメールアドレスで結合

・SQLビューでSQL文の確認：

「SELECT DMリスト.メールアドレス FROM DM非配信 INNER JOIN DMリスト ON DM非配信.メールアドレス = DMリスト.メールアドレス;」この部分をコピーしてSQLのコードを入手。ここではコードを入手することが目的なので、このクエリは保存せずクローズ。

※Fromの後が複雑で自分では書けない。Fromの後の理解の仕方： FROM (A INNER JOIN B) ON (結合要素 = 結合要素))

・新規クエリで、DMリストをマウント

・メールアドレスを選択(SQLパネルにドラッグ)

・抽出条件に先のコードを下記のように代入：

IN(SELECT DMリスト.メールアドレス FROM q_DM非配信 INNER JOIN DMリスト ON DM非配信.メールアドレス = DMリスト.メールアドレス)

※「IN()」で囲むこと。SQLビューの最後の「;」は不要。

※IN演算子はおまじない。

・このクエリを「削除クエリ」にして実行すると、DMリストから削除すべきものがあったり消えた。

※「削除クエリ」は5万件のデータも目も止まらぬ速さ、バックアップを取らずに実行すると、呆然とすることになる。

ケータイメールの抽出

PCと同じメールを同報するわけにはいかないので、このあとケータイメールを抽出する。

「Like "*docomo.ne.jp" Or Like "*ezweb.ne.jp" Or Like "*softbank.ne.jp" Or Like "*vodafone.ne.jp" Or Like "*pdx.ne.jp" Or Like "*ido.ne.jp" Or Like "*willcom.com" Or Like "*mopera"」

Excelの最大行数は65,536行

・PCメールリスト、ケータイメールリスト、それぞれ生成される。リストのエクスポートではまる。エクスポートはExcel形式で行ったが、操作の手間を惜しんでExcel4形式で出力すると16,000件程度しか吐き出せない。

AccessやExcelはエラーメッセージを出さない。Excelが「容量オーバーです」のようなエラーがでればわかりやすいが、なんかおかしい、としばらく悩んでいた。今回は偶然、気が付いたがうっかり見落としやすい。

また、Excel2003形式でも65536件に制限されており、それ以上の顧客リストがあるとExcelでの操作ができない。

テキスト形式でエクスポートしよう。

• (2012-11-10 08:51:41)

数あるブログサービスの中で、JUGEMが一番気に入っている。JUGEMの利点と欠点(2012/11/10)

○利点：Googleの評価が高い(?)

体験的にそう感じている。

○利点：広告をほとんど非表示にできる

ロリポップと契約するとJUGEMが無料で付いてくる。無料ブログにありがちな下品な広告が少ない。設定によってほとんど非表示にできる。

×欠点：全記事のリスト表示ができない

「最新の記事5件」などの独自タグはあるが、全記事リスト表示用の独自タグはない。

年月によるアーカイブシステムがあるので不要という発想らしい。アーカイブってブログに必須のようについているが、私には無用。それよりリスト表示が欲しい。

×欠点：固定ページが作成できない

個別の最新記事がトップページとなる。記事を書き続けないといつまでも同じ記事がサイトのトップになっている。トップページはやはりウエルカムページやイメージページ、案内ページにしたいもの。しかし、JUGEMではこれができない。

【対策1】
JUGEMでは時系列に最新の記事がトップページにくるので、トップにしたいページを未来にしておけばできると予想したが、JUGEMの場合、それは未来投稿予約になるだけで表示されない。

新しい記事を投稿する度に、トップにしたいページの日時を毎回操作するしかない。

【対策2】
独自タグ「toponly」を使う。これはページ固定という発想ではなく、トップページに固定文字列やページ内容を埋め込むというもの。独立したページのように見せかけることができないわけではないが、ムリがある。

＜!-- BEGIN entry --＞の前に下記のような感じで打ち込む

＜!-- BEGIN toponly --＞
{toponly_dmy}
トップページの本文上に追加される
それだけ
＜!-- END toponly --＞

【対策3】
あきらめる。他のWebサイトに記事リストを作成し、すぐに飛べるようするなどしかない。たとえば、サイトのトップバナーはクリックするとそのブログのトップページにくるが、これを他のサイトのリストページに向けるなど。

たとえば、



の{blog_name}の部分を固定文字列に変えて、他にサイトに＜a href=を張っておくなど。