ユーザさんがBeckyを使っている。Beckyには根強い支持者がいて、そういう支持者の人がユーザさんにBeckyを勧めたのだ。

Beckyには自由な開発者が提供した多くのプラグインがある。そういうものをうまく使いこなせば、あるいはいいソフトなのかもしれない。しかし、お客さんは何万件と受信メールをため込んで、検索に時間がかかるという。それが、パソコン好きのヲタクのお客さんではなくて、素人のお客さんなのだ。あのソフトでこうしてこうしてGoogle検索を仕込んだら速く結果が出せます、みたいなことはできない。

で、その貯めこんだメールを移動したり整理したりするのが一苦労だ。そんなの簡単じゃないか、と思われる向きもあるかもしれない。しかし、アカウントは1人1個ではないのだ。しかもユーザさんは、ある時にプロバイダを変えたりしており、フォルダに整理したりもしている。思うほど簡単ではないし、それなりの解決法があったとしても、そこにたどり着いてお客さんにこうしたらいいよ、というまでが大変だ。

自分としては、Beckyの一番悪いと思うところは、すべての処理がリアルタイムだということだ。バックグラウンドで処理をしない。

プログラムでいうと、すべての処理が一つのプロセスの中で行われている。

単体のプログラムに複数のプロセスなりスレッドを立てる処理が難しいということは、私自身いろいろ経験した。MFC、つまりWindowsのC++のプログラムだけれど、C++でプログラムを作るとあれもこれも簡単にできるように見える。しかし、ある処理を途中経過を見せたりストップをさせたりするためには、ロジックの上では二つの別々のプロセスが進行しているようにプログラムをしなければならない。本当は一つのプロセッサーの上で順番に処理をしているんですよ。だけど、プロセス・スレッドを別に立てるというロジックでやらないといけないのだ。

たとえばユーザがクリックしたら別のプロセスがそれを受け取って停止して完了信号を返す。あるいは、処理が一定の進歩をしたら、その処理を起動した別のプロセスに「いまここまですみましたよ」という信号を送る。

こうした処理のわかりやすい例は、たとえばワードの印刷ボタンをクリックしたときの処理だ。印刷ボタンを押すと、画面したに「いま印刷をしていますよ」ということを示すアイコンが動く。その印刷作業が終わらないうちに、あなたは続いて文書にテキストを書き加えたり、続きを見るためにスクロールしたりできる。
もし、ワードの処理が一つのプロセスの中で起こっていたら、クリックして印刷が始まって、印刷が終わって「今終わりました」という信号を送るまで、ワードの画面は一切反応しなくなるはずなのです。コンピュータはただの機械なのだから、「ボタンを押したら、印刷して、修了したら終わったというメッセージを出せ」というプログラムを書いたら、そのプロセスが終了するまでは他のことはできないのだ。

自分でプログラムをやり始めると、実はMicrosoftのOffice製品などは実によくできていると思わざるを得ない。

ところがBeckyではメールを移し始めたが最後、数分間は全く反応しなくなる。

自分は、Beckyにかかわった皆さん方、リムアーツの社員さん方が、どこかの時点で「これではヤバいのではないか」と思わなかったはずがないと思う。なぜ、今までそのままにしておいたのか。いろいろなプラグインとかの整合性が取れないと判断したということはあるだろう。
でも、もし私が開発者だったら、どこかで大ナタを振るってそうしただろうと思う。