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

• (2009-10-17 07:26:14)

Eudoraから始めたインターネットメール

-------------------------------

会社で使用していたメールは通信の基盤技術こそTCP/IPベースながら、あるメーカの独自方式。インターネットのような汎用性がない分、逆にメールのクライアントソフトは洗練されていた。

思えば当時はIBM社など世界のそうそうたるコンピュータメーカーが「メール」というアプリケーション分野の独占や寡占を狙っていたのだろう。

しかし、すべての人に公開されるオープンなインターネットがそういう古い時代(当時は最先端メーカー)の巨人達のプレゼンスを衰退させることになるとはよもや空想できなかった。

フリーで手に入るソフトウェアがとにかく次々と出現する様に世界中の若者は急速にコンピュータ界の巨大企業から離れ独自の文化と開花させていったように思う。

私がはじめて使用したインターネットメールのクライアントソフトはEudora。世界的に有名なメールソフト。当時のMacではフリーで使えるメールソフトはこれくらいだったように思う。

当初はコンピュータメーカー製の洗練された独自メールソフトに慣れていたこともあり、Eudoraはおもちゃのようなソフトに見えた。反面、軽快な動作は快適だった。

Eudoraはかわいらしいソフトで現在でも愛用者は少なくない。現在はWindowsにも移植されている。シンプルで操作性がよいのか、玄人好みのようだ。

私の場合、MacからWindowsに乗り換えたことでEudoraとは縁が切れた。

この記事は#2

顧客ビジネス用途メールソフト#12　グループウエア

顧客ビジネス用途メールソフト#11　マイベスト

顧客ビジネス用途メールソフト#10　メールのセキュリティ

顧客ビジネス用途メールソフト#09　強力な検索機能

顧客ビジネス用途メールソフト#08　強いテンプレート機能

顧客ビジネス用途メールソフト#07　テンプレート機能

顧客ビジネス用途メールソフト#06　ビジネスに必要な機能

顧客ビジネス用途メールソフト#05　次の選択基準

顧客ビジネス用途メールソフト#04　綺羅星のフリーソフト

顧客ビジネス用途メールソフト#03　よくできているOE

顧客ビジネス用途メールソフト#02　はじめてのメール

顧客ビジネス用途メールソフト#01　メールソフトの普及

• (2009-10-16 19:04:51)

メールはインターネットの最重要アプリケーション

-------------------------------

インターネットが流行だした頃、「WEBは使わなくなるけど、メールはやっぱり便利！」というおばさんがいた。

妙に印象に残るコトバだったのか長い間、その時の光景を記憶している。当時50代後半だった彼女がメールを使うこともやや驚きだが、見事に使いこないしていたところが、なかなかの「新しもの好き」性格を現していた。

WEB不要という彼女の予言は当たらなかったが、メールの重要性は的中した。

メールは「インターネットはメールに始まり、メールに終わる」くらいインターネットのもっとも重要なアプリケーションに違いない。

これを書いている私もインターネットは「電子メール」から入った。80年代の終わりごろ会社が社内メールを導入した際(外資系で支店間コミュニケーションの必要性から導入が速かった)、あまりの便利さに「社内だけでなく社外の人とこれを使えたら？」という望みをいただいたものである。

数年後、世界は劇的に変わり出す。インターネットが庶民の手の届くサービスとなり誰もがメールアドレスを所有し、メールを使えるようになった。

インターネットの「基本中の基本」、メール。

毎日使うメール。

だからそこメールソフトにはこだわりたい。こだわる価値がある。

そういう熱い思いがある場合の最良の解決策は「自分で作ること」に限るが、残念ながら私にはプログラミングの素養がない。市販やフリーソフトに頼らざるを得ない。

この記事は#1

顧客ビジネス用途メールソフト#12　グループウエア

顧客ビジネス用途メールソフト#11　マイベスト

顧客ビジネス用途メールソフト#10　メールのセキュリティ

顧客ビジネス用途メールソフト#09　強力な検索機能

顧客ビジネス用途メールソフト#08　強いテンプレート機能

顧客ビジネス用途メールソフト#07　テンプレート機能

顧客ビジネス用途メールソフト#06　ビジネスに必要な機能

顧客ビジネス用途メールソフト#05　次の選択基準

顧客ビジネス用途メールソフト#04　綺羅星のフリーソフト

顧客ビジネス用途メールソフト#03　よくできているOE

顧客ビジネス用途メールソフト#02　はじめてのメール

顧客ビジネス用途メールソフト#01　メールソフトの普及

• (2009-10-15 16:43:18)

1日や単位時間当たりにメール送信数制限を設けているホスティングサービス、レンタルサーバの会社は多い。スパム対策なのだろう。

あった方がよい。スパム業者は減る気配もなくインターネット全体で対策を強化した方がよい、と私も賛成派だが、悲しいことに自社の業務に影響も。

メール送信数制限は以前はあまり関係なかった。特にダイレクトメールやメルマガなどを不特定多数の見込み顧客に配信する行為はもちろん、既存の当社顧客に対してさえも発行しない当社には完全に無縁・無関係の制限だった。

しかし、顧客数が数万人を超え一日の受注量がそれなりになってくると個別の通信でさえ、抵触する可能性が出てきた。

一昨日、商品発送通知からお支払確認通知とまとまった数量のメールを配信した。偶然、数種類のまとまった数量のメールが同じ日の同じ時刻に集中。全メール配信の最後の方でメールエラーが発生。原因不明で調べていくと、メールサーバのリジェクトメッセージから送信数量制限による規制と考えられた。実際翌日には回復したので送信数制限規制だったと考えられる。

今更ながらホスティングサービス会社にはメール配送制限があることを思い出した。レンタルサーバーやホスティング会社はどこでもメール配送制限を行っているものか調べ直してみると、案外前向きに公開しているところが少ないことに気づく。

「メールアカウント制作数：無制限」ならどこのレンタルサーバーでも見つけられるが、「メール配送制限」の条件や内容はそうとう深く探してもでてこないところばかりだった。

あるホスティング会社は「メール配送制限の具体的な値は非公開」。

またある会社さんは問い合わせに対して「特に明確な制限は設けていないが、問題と判断される場合は制限します」とかなり含みのある返答が来た。

どちらの会社さんもビジネス向けホスティングサービスに注力されているので、制限内容を明文化すれば、ビジネス向けや法人顧客の集客に影響がでるし、かといって「無制限」ではスパム業者に悪用されるしシステムに負荷が及ぶ。

煮え切らない態度が見える。しかし、まじめなビジネスをやっている限り柔軟に対応してくれそうな雰囲気ではある。

ホスティングを「専用サーバ」や「VPS」に移行すればこの制限はなくなると思うが、root権限は当社にはまだ荷が重い。

メールの配送配信制限は一例であってこの問題は企業の成長とビジネスの拡大に伴うシステムの「スケーラビリティ」の問題のように思う。

目先「共用サーバ」をやめて「専用サーバ」に移行すればよいのだが、メールに限らずビジネスの拡大に伴い、様々な制限やリソース不足が今後でてくることを暗示しているように感じられる。現状のリソースとリスクを把握し、現実的で長期的な「スケーラビリティ」の設計を行う必要性を知らせてくれた。

マネー投資では「リスク分散」の重要性が言われるが、ビジネスではリスク分散だけでなく、新しいシステムや新しい環境、新しい基盤、新しい商材への「移行性」と一定の秩序と方式で規模を拡大させことができる「スケーラビリティ」の見通しが大切ではないかと反省した。

• (2009-10-15 16:19:27)

半角カナの問題や原因不明で落ちる問題、さらに動作スピードへの不満から、他社製ソフトへのリプレイスを検討してみた。

現在受注ソフトで使用している部分はフロントエンドの受注データ取込のみであり、あとはすべてACCESS・VBAでリプレイスしている。

ならば受注データ取込だけをやってくるソフトでもいいのではないか？と思えてくる。たとえば、市販ソフトもちらほらネット内で発見できる。

その中から一社の試用版をダウンロード。試用してみた。スピードには満足だったが、少々問題があった。プレインテーブルにデータを落とす分は問題ないが、現行受注ソフトの賢い点は下記テーブルに分けて重複もしくは個別収納してくれる点。

受注データ

明細データ

顧客データ

しかも顧客データはリピーターか新規顧客かを判断するロジックが組み込まれており、リピーターの場合は古いレコードを上書きしてくれる機能がある。

試用したソフトもテーブル・サブテーブルと分ければ上記個別テーブルへの格納も可能な気がしているが、リピーター・新規顧客判断のロジックは私には無理である。

リプレイスはそう簡単にはいかない。

• (2009-10-15 16:09:20)

ごくまれに取込時にエラーを起こし受注アプリケーションが落ちることがある。

これが発生すると、仮に100件の取込でも1件起きるだけですべての取込が不可能になる。

はじめはどの受注データで落ちているか特定すらできなかったが、何度かトラブルを体験しているうちに、エラー元となっているデータの当たりは付けられるようになった。

しかし、原因がまだよくわからない。おそらくデータベースのテーブルフィールドのプロパティ違反ではないかと思われる。

たとえば規定文字数を超えるとか、データの型違いなど。

昨日携帯電話のメールアドレスで落ちた。"a...bc...z"@ezweb.ne.jpといった感じのアドレスだった。

再現テストや原因を特定するためのテストは時間不足で行っていないが、この原因を特定できたところで、他にも多数あり終わりではない。

まれにしか発生していない事実を考えれば、あれこれ考えるより、今はとにかくこの不具合を仲良く付き合っていくしかない。