過ぎたるは及ばざるがごとし

重要な格言と言える。
日本の携帯は世界一の多機能だ。それは誇れるものだろう。しかし、世界でほとんど売れていない。高すぎるのだ。通話料で回収しなければ売れるものではない。そのような商習慣がない世界では通用しない。機能が多すぎて、大した機能がない携帯に勝てないのだ。
日本は世界一ブロードバンドの進んだ国だ。島国で人口密集地が偏っているので、ある程度投資が進めば容易に人口カバー率を上げることができる。日本ではストリーミングを快適に使える。ストリーミングが商売になる国は珍しい。しかし、日本がストリーミングに固執し、またDRMに固執する間に、世界はP2PとDRMフリーへ向かおうとしている。多額の投資を行ったCDNはタダ同然のCDNに負けるかも知れない。世界の最先端を走っているつもりが、反対方向に走っていることがわかり、あわてて向きを変えてももう遅いということになるかもしれない。
インフラは国際競争力を高める。しかし、インフラは世界標準から著しくかい離すると、共通ではなくなる。共通でない基盤は邪魔にしかならない。

オンラインシューズフィッティング

通販で靴を買うのは勇気がいる。
実際に試着したわけではないので、買った後で足に合わないことがわかれば大損だ。
そのような心理的な障壁のため靴の通販には限界がある。
もっと安心して購入できるようにする必要がある。
そこで考えたのが、シューズフィッティングをオンラインで行うというものだ。
シューズフィッティングとは、足の形に合う靴を探すこと、あるいは靴を足の形に合わせることだ。ここでは前者の意味で使う。
例えば、リスクを避けたい消費者は有料でシューズフィッティングを希望する。少なくとも機材の送料と保険料を支払う。
利用者は送られてきた機材で足の形を測定し、オンラインで送信する。あるいは機材とともに返送する。
足型データがオンラインで参照可能となれば靴のデータと照合して、履き心地を計算する。
原理は簡単だが、宅配に適した足型測定機材の開発や、履き心地のアルゴリズムなど詳細に詰める必要がある。そのノウハウが差別化になるだろう。

マクドナルドのコーヒーをコンビニで売れば？

マクドナルドのコーヒーが人気だ。値段の割においしいらしい。
コーヒーで有名なのはスターバックスだ。スターバックスのコーヒーはコンビニでも売られている。
ならばマクドナルドのコーヒーもコンビニで売ればよい。
100円で売ることはできないだろうが、本当においしいなら100円より高くても売れるかもしれない。

Mozilla Prism vs. Google Gears

PrismはWebアプリケーションをデスクトップアプリケーションに変換する。
これによりGoogle Gearsが時代遅れになるというのだが、これは疑問だ。
Google GearsはWebアプリケーションをオフラインで利用できるようにする技術だ。Gearsを使ってもデスクトップアプリケーションにはならない。（オフラインであっても）ブラウザでアクセスする必要がある。
Prismを使うとブラウザの枠組みを超えることができる。その意味ではGearsより新しいかもしれない。
しかし、PrismではWebアプリケーションはオンラインのまま使い続ける必要がある（と思う）。どんなに見かけがりっぱ（ブラウザらしくない）でもオンラインのままでは利用可能な状況に限界がある。
両者は相補的なのであって、対立するものとは思えない。

Client-let

Javaにはサーブレット(servlet)がある。これは小さなサーバ(serv(er)-let)を意味する。
同様にアプレット(applet)もある。これは小さなアプリケーション(app(lication)-let)を意味する。
ここに小さなクライアント(client-let)を加えようという提案だ。
発端はアプレットの遅さにある。
アプレットは有望な技術に思われたが十分に活用されているとはいいがたい。その原因はアプレットの遅さにある。
アプレットが遅いのは毎回起動するからだ。クラスは初回ダウンロードされるが、それ以外はキャッシュされる。問題はJVMの起動時間だ。
この問題はCGIと同じだ。それに対する解答がサーブレットだったはずだ。
CGIは毎回プロセスを起動するので遅い。しかし、サーブレットはあらかじめ起動したプロセスの中でスレッドとして動作するので速い。
同じことをクライアントで行えばよい。
つまり、ブラウザと並行にJVMを起動しておき、アプレットをスレッドとして実行する。このような形態にクライアントレットという名前を付けてみた。
これは誰もが思いつくが、それでも実現していないのには理由がある。１つは実装が容易ではないため、もう１つは安全でないためだ。
単にブラウザと同時にJVMを起動すればよいというわけではない。それではブラウザの起動が遅くなり、全体の使用感が悪化する。しかし、オンデマンドで起動すれば現状と変わらない。すなわち、ブラウザ起動後からJVMを必要とする前の間に、ゆっくりと穏やかにJVMを起動させる必要がある。急激に起動させるとCPUを奪いユーザ経験を悪化させる。したがって、ゆっくり起動させる必要がある。これが結構難しい。
致命的かも知れないのは安全でないことだ。複数のアプレットが同じJVMで稼働するため１つの障害が他を巻き添えにするかもしれない。サンドボックスの実装が困難になる。
この記事は想像で書いているので、実際のブラウザの実装を確認しているわけではない。そのため、すでにここで述べた工夫が取り入れられている可能性もある。それでも遅いのならしかたない。

JRE update 6の問題点

JRE update 6がトラブルを起こしている。
私もトラブルに巻き込まれた。
グループウェアのSecureTicketがJavaで作成されている。それがupdate 5から(未確認情報では4も)正しく動作しなくなった。ハングしてしまう。
最初はSecureTicketが原因だと思ったのだが、どうもJREの側に原因があるらしい。
対策は「Javaコンソールを開く」ことである。
Javaが稼働すると余計のウィンドウが開くようになってしまった。
少々みっともないが背に腹は代えられない。

e-learningは安いか？

NECが教育機関向けe-learningサイトContentsCafeを開設した。
かなり充実した内容なので、これを例にe-learningのコストを計算してみたい。
例えば、半年１学期の場合、6か月コースになる。このとき、あるコースでは受講者１人あたり2640円の経費がかかる。コースによりばらつきはあるがおおむね似た価格となる。
もし非常勤講師を雇えば大雑把に30万くらいの経費はかかるだろう。
すると採算ラインは113人前後となる。
受講者がこれ以下ならe-learningが得だが、これ以上なら人間の方が得だ。
もちろん人間の方が柔軟性に富むという利点があるが、個人差も大きい。よって授業の質を考慮することは水掛け論になるのでしない。
つまり、小人数構成にして人件費をかけるようになると、e-learningにした方が有利だということになる。
逆に、非常勤講師の戦略としては、多人数でe-learningに勝る教育効果をあげる必要があるということだ。そうでなければe-learningに職を奪われることになる。