Web屋のネタ帳

2週間ほど前に書いたDoCoMoの説明にある「RFCに準拠しています」はウソという記事で指摘していた件。「RFCに準拠しています」の一行が消えている。

やっぱり通信屋さんとしてのモラルというか心意気というかそういうことの少しくらいは残っているということを認識しました。

see also:

• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。 (2007/11)

まず論より証拠である。ブラウザのJavascriptをオフにしよう。インターネットエクスプローラであれば 「ツール」－「インターネットオプション」の「セキュリティ」タブで「レベルのカスタマイズ」ボタンを押して「アクティブスクリプト」のところを「無効にする」にチェック。（下図参照）

そして、

このサイトを見てみましょう

トップだけじゃなく、いろんなところも。 せっかちな方は画像でどうぞ。

そう。検索エンジンがJavascriptを理解しないことを逆手に取った手法のひとつである点は以前紹介したBMWの件と同じである。

ところで、Yahooの「検索エンジンスパムに関する公式な解説ページ」には次のようにある。

以下は、検索エンジンスパムの例です。

• 検索する利用者に見えないテキストを使っているページ

また、最近微妙にリニューアルされているGoogleのWebマスターガイドラインにも次のようにある。

隠しテキストや隠しリンクを使用しない。

検索エンジンでの掲載位置を上げるための不正行為を行わないでください。判断の目安となるのは、ランクを競っている他サイトに対して自分が行った対策を説明する時に、説明しづらい点があるかどうかです。その他の目安としては、ユーザーにとって役立つかどうか、検索エンジンがなくても同じことをするかどうか、などの点を確認することです。

うん。「検索エンジンがなくてもnoscriptタグを使って同じことをするかどうか」聞いてみたいものだ。

まあ、SEOを専門にあれこれ考えている人にとってはこの程度の手口はめずらしくもなんともないんだろうし、かわいいもんだといえばかわいいもんかもしれない。

いざインデックスから削除されたりすると「スパムではない、不正行為をしているつもりはない」とか言ったりするのだろうが、そういう企業には次の記事の言葉をお送りしたい。（全部引用したいくらいだが長いので一部のみ）

企業側の主観でユーザーのためになる／不正行為ではないなど誰も聞いてません。 この大原則を理解せずに、中途半端な知識で主観的に判断していくから検索エンジンに削除される羽目になるのです。
”検索エンジンのルールは検索会社が作成する”という大原則(SEMリサーチ 2006/4)より

なお、 JIN ビジネスニュース : グーグルは傲慢なのか(2006/4)という記事で、

ヤフージャパンの広報は「検索の表示に手を加えることなど一切無い。仮にスパム行為があったとしても同じだ。もちろん、警察が関係する犯罪行為（不正な口座の売買など）は別だが」と話す。

ということが載っていたが、先ほど紹介したYahooの「検索エンジンスパムに関する公式な解説ページ」には次のようにあることをYahooの広報担当者は知らないのかな。

検索エンジンスパムに該当すると判断されたサイトは、データベースから随時削除されます。

see also:
ＢＭＷドイツ本社のサイトがgoogleから消された(2006/2)
サイバーエージェント、Googleの逆鱗に触れてインデックスより削除(2006/3)
なぜやめたんだろう？（noscriptタグでSEO？）(2006/6)

驚いたのが、 戸塚ヨットスクールを支援する会の会長は石原慎太郎＠東京都知事なんだそうな。

引き続きGoogle Maps APIの話題。 Firefoxなどでは問題なくても、インターネットエクスプローラーで見ると「開けません。操作は中断されました」みたいなエラーがでて何も表示されなくなることがある。

HepCat Dev and Test: GoogleマップとIEの「開けません。 操作は中断されました」
侍ズム - インターネットサイトを開けません。操作は中断されました

どうやら解決策として、問題となりそうなJavascriptを全てfunction化してheadタグ内に置いて、 body内からそれを呼び出すようにしたほうがいい、ということらしい。

ただ、筆者があれこれ試していて、簡単な別解を見つけた。 Maps APIを使ったJavascriptコード群を、HTMLの最後のほうに書くのだ。 </body> タグの直前とか。そのあたり。 それで、FirefoxでもIEでも動くようになった。 あんまり美しくないとは思うのだが、まあそんな方法もあるよということで。

以前のエントリで、Google Maps APIと文字コードがらみの問題の簡単な解決策を書いた。

がしかし、ここ最近でGoogle Maps APIがバージョン2になったとたん、 GoogleがJavascriptをShift_JISで返していることが判明！？どーなってんの？＞教えてくわしい人

とりあえず <script src=hogehoge type="text/javascript" charset="Shift_JIS"> で回避。

もしかして、クライアント側がMac OSだとまた挙動が違ったりして！？ こーいうマニュアルから漏れがちな肝心な部分をコロコロ変えないでほしいんですけど。。。

追記：誤報でした

いま試したら、従来どおりutf-8なJavascriptコードが返されるようです。 マボロシを見てしまったようで・・・。失礼しました。

ここ数週間、このブログに対するコメントスパムやトラックバックスパムがまた激しくなってきていた。他のトコでも同様か、もっと前から悩まされっぱなしだよ！という人も多いだろう。そこで最近このブログで実施したいくつかの対策についてつらつらと。といってもたいしたことはやってないけど。（注： MovableType前提）

応急処置としてとりあえずmt-comments.cgiやmt-tb.cgiを、mt-comments.cgi.bakとかそういう名前にリネームしてしまう。あるいはMTの設定で全てのコメントやトラックバックを閉じる。 これで全てのコメントもスパムも一切遮断。ゆっくりできる気持ちと時間とマシンリソースの余裕を確保。なあに。よく考えれば1、2週間くらい止めたってどうってことはない、という気持ちが大事。

そしてスパム対策のプラグイン等を探したりするわけだが、そもそもMT自体をバージョンアップしたほうがよいという結論に達した。MT3.2ではスパム対策がかなり強化されていると聞く。やってみたら実際そうだったし。

MT3.2にバージョンアップしたわけだが、それでも追加でMTBanASCIIというプラグインを入れる。MTのバージョンにあわせて適宜ググってて探して入れましょう。 これは、日本語などのマルチバイト文字を含まないコメントを遮断してくれる。海外から来るコメントスパムはたいてい英数字のみでマルチバイト文字を含まないことを逆手に取ったもの。 以前はこれがかなり効いたのだが、ここ最近はスパムを送る側も進化してしまい、マルチバイト文字を含む形でコメントを送り込んでくるので効き目が薄くなってしまった。が、無いよりはましなので入れる。

次に、スパマーはmt-comments.cgiというURIを決め打ちで来るのだろうという推定で、mt-comments.cgiを例えばmt-komento.cgiなどに書き換えてしまう。mt.cfgないしmt-config.cgiもそれにあわせて書き換える。 これも以前はそこそこ効いたのだが、スパマーの進化により効き目は薄くなりつつあるので、やらないよりましという程度。ちなみにこのブログではもうやってない。MT3.2のスパム対策機能だけで十分っぽいから。

MT3.2にデフォルトでついてくるSpamLookup系のプラグインのうち、キーワードフィルタプラグインにいくつか設定を追加。たとえばバイ○グラの宣伝をしつこく送ってくるスパマーが、URLにかならず http://via.example.com/ を指定してくるのであれば、キーワードフィルタでこんなふうに追記する

/via.example.com/i 10

正規表現的にはあまり厳密じゃないのだが、これはこれで期待通り動くのでまあいいとしよう。 最後のiは大文字小文字を区別しない、の意味。数字の10はスパム判定度最高を示す。

以上、MTの細かい説明とか背景とかは省くが、少なくとも平穏を取り戻せたか否かでいうと取り戻せました。 数ヶ月でまた新手のスパムが来るんだろうけど。

SEOだとかAjaxだとかWeb2.0だとか「何とかAPI」だとか、よくわからないんだけどなんかすごいことが起きそうだと一般ピープルに匂わせることができそうなキーワードが流行っている。でもそれって単なる流行のサイクル。服と同じ。サインカーブを描いてやってきては去ってゆく単なるブームに踊らされるとコトの本質を見失う。

2005年の秋に楽天がTBSを買収しようとしてすったもんだが起きたころ、「要するにショッピングモールというビジネスが寿命に近づいてることに気づいた三木谷社長が焦ったんじゃないか？」という話がまことしやかにささやかれた。詳しい記事はいくつかあるが、一番まとまっていそうな「[R30]: 楽天は本当にAppleに対抗しようと考えたのか？(2005/10)」という記事からいくつかの段落を紹介しながら話を続けたい。

かつてネット・ショッピングには、信用できる決済システムと店舗へのトラフィック確保にネックがあると言われていた。楽天はそこに注目し、決済インフラの確立、そして「ネット店舗なら何でも楽天にある」と言わしめるほどの店数を揃え、「ネットショッピングならまず楽天」と消費者に連想させ、お客のトラフィックを確保することに多大な努力をかけた結果、大いに成長した。

残念ながら楽天市場が多大な努力をかけたのは信用できる決済システムではない。っていうか決済については楽天は目新しいことはほとんど何もやってない。楽天市場に限らずECサイトの決済手段のほとんどはいまだにクレジットカード決済と銀行振り込みと代金引換。それって20年以上前からある決済手段で新しくもなんともない。通信販売でモノを買おうとする買い物客が唯一感じることはクレジットカード番号を伝える相手がまともな企業であるかどうかであって、そういう不安の解消手段は「まともな通販会社ですよ」「まともな通販商売やってますよ」という雰囲気をかもしだすことでしかない。楽天市場はそれを地道にやっただけだ。技術的なことでも天才的なことでもない。

また、楽天市場が努力したのは「ネット店舗なら何でも楽天にある」と言わしめるほどの店数を揃えることでも顧客のトラフィックの確保でもない。

楽天市場が全精力を注いだのは自分の店舗の商品データを簡単に更新できる機能の開発と、そういうのを開発しましたから使ってくれと言って回る営業だ。

お客のトラフィックを確保できたのも「ネット店舗なら何でも楽天にある」と言わしめるほどの店数を揃えることができたのもその結果に過ぎない。 技術知識ゼロであっても自分の店舗の商品の画像や説明やメールの本文をコツコツコツコツコツコツコツコツコツコツコツコツコツコツコツコツ書き上げてゆくことに全精力を集中できる環境を店舗に与えることができたからこそ、そのWebページは「自動販売機」ではなく「店舗」となり、顧客の出足は「トラフィック」となり、「商店街の活気と人気（ひとけ）」となったのである。

ということで、

　だが、ネットでの物品購買が当たり前になり、決済インフラの信用性もほとんどボトルネックにならなくなった。またトラフィックはGoogleを初めとする検索エンジンからが中心になり、SEOや検索連動広告を出せば単独でネット上で店を出しても十分トラフィックを確保できるようになった。そうすると、楽天に顧客リストを握られている既存店舗はともかく、新規に出店する業者が楽天の利用を検討する必然性はまったくない。ここが、オークションという「システム」そのもので顧客をロックインしてしまったヤフーと楽天の、大きく異なる点である。

という話には、「フォームとかシーエスエスとかシージーアイとかレンタルサーバーとかエフティーピーとかテルネットとかセッションとかクーロンとかブログとかとかジャバスクリプトとかいうカタカナ単語を知らなくても自分の店舗の商品の画像や説明やメールの本文をいつでも自由に更新できる」という、超ど級に重要な基本機能の良し悪しがショッピングモールあるいはECサイト全般の成否を左右する、という観点がすっぽり抜け落ちている。

「トラフィックは検索エンジンから得られる」って、おいおい。検索エンジンにひっかかる側のモノつまり商品データはだれが書いてるんだ？検索エンジンか？違う。楽天市場か？違う。お店の人がコツコツ書いてるんだ。中には商品のメーカーのWebの内容をそのままコピペしてるだけの店もあるが(笑)、そういう店は大して儲かりもせず長続きもしない。繰り返すが、お店の中の人がコツコツ書いている商品データが全ての源泉なのであり、商品データの書きやすさ更新しやすさが第一の勝負の分かれ目なのである。

たしかに、店舗データの更新編集機能の充実したショッピングモールやレンタルサーバーやその類のソフトウェアは、最近すごく増えた。それこそMovableTypeのプラグインでショッピングカートプラグインなんてのも出てきてるくらいだ。

がしかし、楽天市場やYahooショッピングの出店者の多くにとっては、「MovableType」のようなアルファベットも「プラグイン」といった謎のカタカナも、どうにかして日本語にしていただかないことには「？」マークが頭上に浮かぶだけだ。「なんとかスタイル」や「なんとかモール」ですら理解できるか怪しいというのはあながち言いすぎではない。

レンタルサーバーだのドメインだのデータベースだのジャバスクリプトだのムーバブルタイプだのブログだのプラグインだのアールエスエスだの、そんな目新しいカタカナ知らなくても店の商品やサービスの良さをお客に伝えるという基本作業を手伝ってくれるモノを一発でくれ！あ、お値段安めでよろしく！というのが真の需要であり、それに答えているのがショッピングモールであり、逆にそれに一発で答えることも初期費用運用費用合わせて低価格で提供することもできていないのが個々の技術や製品群やそれを作る技術屋さんたちなのである。

通販で商売したいと言う店舗の人に向かってエイジャックスとかエーピーアイとかトラックバックとかソーシャルネットワークとかわけのわからない単語を連呼する時点で負けだし、ソフトは提供するけどサーバーは他のレンタル業者さん使ってね（あるいはその逆）みたいにサービスを区切ってしまっている時点でも負け。店舗の側の人ももっと技術について勉強すべきというのはそうなのだが人間は怠惰であるという現実は現実である。そもそも店舗の人の本分は商品とか顧客とか在庫とかいわゆる小売業用語で言うところのマーチャンダイジングであってコンピュータ技術ではない。

したがってインターネット上のECサイトあるいはショッピングモールをとりまくいまの状況が近い将来そう簡単にひっくり返るとは思えない。

いや、ナウでヤングなレンタルサーバーとか言ってなかなかいい味だしてるあそこならそのへんわかってる感じがする。（謎）

See Also:

• いまＥＣサイトがなすべきこと（続 リコメンデーションの現実）
• 楽天vs店舗 外部リンク禁止を巡って裁判沙汰が進行中
• サラ金の利用者とショッピングモールの出店者の共通項

以下の記事を読んで、そういえばと思い出した。

• 404 Blog Not Found:たとえ最後に生き残ったのがJavascriptだとしても
• 最後に生き残るのは{{br}}JavaScriptかもな

たしかに、JavaScriptはWebブラウザ上つまりクライアントサイドで動くもの、というのが今の一般的な認識だ。 しかし、かつて Server Side JavaScript という技術は実在し、しかもけっこう活躍していた。

むかーしむかし。今は無いに等しきNetscape社が、ダイナミックなWebページを作り出すためのスクリプト言語を開発していた。一方ちょうどその時期にSun Microsystems社内ではJavaというまったく別な言語を開発していた。両社の技術者の間で「その名前、かっこいいね、いただいていい？」「うん、いいよ」という会話があったのかどうかは知らないが、とにかくNetscape社のスクリプト言語はJavaScriptと名づけられた。こうして「JavaとJavaScriptは兄弟」といったふうな誤解が以後（今でも）広まることになる。似ているのは実際には名前とプログラムの書き方だけで、技術的な中身はまったく違うのに。

初期のJavaScriptはブラウザに搭載されクライアントサイドで動いていたが、それは開発元のNetscape社のメインな製品がブラウザだったから当然の流れとしてそうなっただけで、JavaScript自体はクライアントサイドに限定フォーカスされていたわけではなかった（らしい）。Netscape社はブラウザだけでなくWebサーバー製品の自社開発にも着手し、iPlanetというブランドで売り出した。当然、iPlanet WebサーバーはサーバーサイドでJavaScriptが動くようになっていた。

サーバーサイドJavaScript実行エンジンはiPlanetシリーズだけに搭載されていたわけではない。コトの経緯はよく知らないが、ソフトウェアベンダーのいくつかにもライセンス供与されていたようだ。当時は今で言うJAVA/JSPのようなWebサイト向きのアプリケーション技術が少なかったせいもあるのだろう。そのうちのひとつが、BroadVision（社名と製品名同じ）だ。ルールベース型と呼ばれる方式のリコメンデーションエンジンがウリの、今で言うアプリケーションサーバの走りである。BroadVision上ではサーバー側アプリケーションをJavaScriptで書くようになっていた。

「ワン トゥ ワン」とか「レコメンデーション」とか「スティッキーなサイト」とかいう単語が流行ったいわゆるネットバブルの時期に、名だたる企業が競ってBroadVisionを導入した。日本ではJAL（日本航空）やNECの121ware.comなど。ヒューレットパッカード社の直販サイトも最近までBroadVisionを使っていたようだ。 カリフォルニア州公式サイトは今もBroadVisionを使っている。なお、レコメンデーションの現実と幻については過去の記事へどうぞ。

Javaはクライアントサイドの「アプレット」として登場したが「重いんだよ！」の一言で総スカンを食らってしまい、現在のようなサーバーサイド用言語として認められるまでのしばらくの間、苦渋をなめる事になった。一方JavaScriptはクライアント側はもちろんサーバーサイドでもうまくいきそうな気配があったのに、結局クライアントサイドでしか生き残ることができなかった。Netscapeという開発元自体が遭遇してしまったネットバブルの荒波とブラウザ戦争の副作用だったといえばそうなのかもしれない。しかもAjax技術の中核として認められる最近まで「Javascriptは最も誤解された言語」だった。

とにかく、Netscapeの凋落とともにサーバーサイドJavaScript実行環境は表舞台から遠ざかってゆき、代わってJavaが躍進した。iPlanetシリーズはSunに買収されてSun Java System Webサーバーとなり同社のWeb層を担う製品のひとつに過ぎなくなった。Broadvisionも今のバージョンではJavaScriptではなくJavaをベースとしており、内部エンジンとしてWebLogicやJBossに頼るようになっている。

とはいえ、世の中に古くからあるいろいろなサイトでURLが「****.jsp」とあるもののうち、もしかしたら、そのいくつかは「Java Server Pages」ではなくいまだに「Java Script Pages」なのかもしれないのだ。いや、冗談抜きで。

さて、この記事のタイトルは「かつて実在した」と、あえて過去形にしたが、実際のところは今でも実在する。

Kazuho@Cybozu Labs: 今日から始める Server-side JavaScript

IIS以外にも、Sun Java System Web serverという名前のかつてのiPlanetだが、Server Side JavascriptがSun Java Active Server Pagesと技術名称を変えて、、、なんかややこしいが、とにかくまだサーバーサイドJavaScriptが使えるようだ。そのうちオープンソースのサーバーサイドJavascript実行環境なんてのが出現しても不思議ではない。mod_php4みたいな感じでmod_javascriptとかありそうだ。

Ajax技術は便利だ。その中核をなすJavaScriptでサーバー側の処理も書けたらもっと便利で手間が省けるだろう。 Web2.0の世界において、サーバーサイドJavaScriptの復活はあるのか？ それは市場のみぞ知る。

キータッチを見ていて気がついた。

IME（漢字変換モード）をオンにするとき、

• 比較的若い人：「半角／全角 漢字」キーを押す
• 比較的若くない人：Altキーを押しながら「半角／全角 漢字」キーを押す

昔のクセが抜けない筆者は若くないほうの操作．．．

10メートルほど距離があったのだがそれでも余裕で響くイビキ。 ツカツカと近づいてそいつのイスにケリいれて「イビキかいて寝るなら外で寝ろや」と言ってやる・・・のをぐっとこらえて黙って手をあげて係の人に「なんとかして」的なジェスチャーをして済ませた僕ってオトナ。

NTTドコモのこのページがいつからこのように書かれているのかは知らないが、こういうウソは本当にやめてほしい。

ご注意
＜アドレスに使用できる文字など＞
※RFCに準拠しています。

• （途中省略）
• 「.」（ピリオド）をアドレス内で連続使用したり、アドレスの最後に設定すると、一部のプロバイダとメールを送受信できない場合があります。

メールアドレス変更 | お知らせ | NTTドコモ(2006/4)より

ついでなので問題箇所の画像も乗せておく。

上の文章において「アドレスの最後」というのは@（アットマーク）の直前のことであると解釈するとすれば（って断らなくても普通そう読めると思うが）、これはウソである。

メールアドレスにおいて、@（アットマーク）の直前にピリオドを使うことは、RFCにおいて許されません。

にもかかわらず、この説明がRFCに準拠しているかのような誤解をまねく注意書きがされており、 さらにうがった見方をすれば、そういうメールアドレスを使ったメールを送受信できない「一部のプロバイダ」のほうがおかしいとさえ読める。

Web屋として声を大にして言おう。ふざけんな。

こういうやり方はマイクロソフトだけでカンベンしてくれ。

「1999年ごろにｉモードを突貫工事で立ち上げたときにRFCを読まずに作っちゃったからこうなっちゃったんだ、ゴメン」という話はまあ許そう。だがそれで正しいというウソを流布するってのはどうなのよ？

試してないけど（※）、もしかして今現在でも「ｉメニュー」のメールアドレス変更画面は、@の直前にピリオドを置くような設定をユーザーに許してしまっているのか？ もしそうだとすれば、もうそういう風に設定しちゃったユーザーはしょうがないとして、今後そういうアドレス設定が増えないように、設定画面を仕様変更すべきなんじゃないのか？ それすらしないどころか逆に今の仕様は正しいという誤った情報を流すってのはどうなのよ？

ちなみに、sendmailに代わってメールサーバの標準になりつつあるpostfixでは、@の直前にピリオドを置くようなメールアドレスはデフォルトではじいてしまうのでご注意。 （sendmailもそうだったっけ？） MicrosoftのExchangeサーバーなども同様（下記参照）。

参考：

• RFCを読まなかった携帯キャリアの罪(2004/10)
• hxxk.jp - RFC によるメールアドレスの local-part におけるピリオドの取り扱いについての考察(2004/10)
• @ の直前にピリオドがあるなどの RFC に準拠していないアドレスを含むメッセージを送受信できない (Microsoft 2005/2) ←MSにしてはめずらしく自社製品がちゃんとRFCに準拠した動作をするようになっているの図

この話は前にも書いたんだけど、つい最近ドコモの上のような説明書きをたまたま見かけて改めて腹が立った。 こんなのがいっぱいあるからケータイ対応って頭痛くなるんだよなあ。
see also:
ケータイのブラウザの進化が先か？Web屋の尽力が先か？

追記：
※確認してみた。iモードのメールアドレス設定画面では、今現在でも、@の直前に「.」（ピリオド）を使ったアドレスで設定できてしまう。
ドコモの説明から「RFCに準拠しています」が削除

see also:

• みんなで渡れば怖くないの罪 － au by KDDI メールアドレスにRFC違反を故意に許すの巻(2006/6)
• ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。 (2007/11)

またいつのまにかバブル状態になっている。今度のキーワードはSNS（ソーシャルネットワーキングサービス）というものらしい。

むかーーーし、「マルチメディア」とかいうキーワードが突然現れ、結局なんだかわからないまま消え去った。その後また「インターネット」というキーワードが1995年前後に突然現れ、「インターネットを使えば世界中に情報発信ができるんですよ！」とかいううれしいんだかどうでもいいんだかわからない売り文句にのった人々のバブルは2000年過ぎにはじけておわった。

実際のところ、インターネットを使って世界中に情報発信ができてうれしいなやりたいな、と思う人はごくごくごく少数であって、多くの人にとっては世界中なんてどうでもよくて、むしろ自分の友達やせいぜい友達の友達とったごく近い範囲の人との控えめでクローズドな情報の受発信手段こそが多くの人にとって欲しいものだった。それがSNS登場の理由なのだろう。

そう考えると、まやかしのマーケティングキーワードの変遷のようにも見えるマルチメディア→インターネット→SNSという流れは、一応、消費者の本当の需要と言うものに徐々に近づいていっている結果だとも考えられる。それはたぶん良いことであり、流れとして自然かつ必然だ。

しかしその単に自然で必然な流れにすぎないことに過度に期待しすぎる現象それをバブルという。歴史は繰り返す。

「脳」。医学は進歩しているが、唯一、未解明な部分が非常に多い分野。それゆえ、くだらない科学者によるミスリードが多い。ゲーム脳もそのひとつだ。

ゲーム脳：高次脳機能障害3年半　早期教育検証を－ゲーム (MSN毎日インタラクティブ 2006/4) という記事を見かけた。

教授が言うように、前頭前野のα波、β波の増減データから前頭葉が働かなくなったとは言えない。そもそも脳波を測定した機器にも問題がある。脳科学者の久保田競氏（京都大名誉教授）は「彼がやらなければならないのは、自分の作った脳波計で正しく脳波が取れていることを、脳波の関係学会で発表することです。それすらやっていませんね」と手厳しい。

　理系的な側面から追及しなくても、論理的な破綻（はたん）は随所に見られる。「議論のウソ」（小笠原喜康著、講談社）が分かりやすく指摘しているので、興味のある方は参考にしてほしい。

教授と言うのはもちろんこの人のこと。

See Also: ゲーム脳とか森昭雄とかは自分で調べて自分で判断しましょう

今日はまとまってない話なのでそのつもりで聞き流していただきたく。

mixiがここまで延びた理由のひとつが、早くから携帯電話対応していたことにあることは誰の目にも明らかだろう。「最近もうケータイからしかmixi使ってないんだよねー」という人は、mixi 300万のユーザーのうちの過半数とまではいかなくともそれに近い割合になっている気がする。

こうした状況から考えても、こと日本での消費者向けのWebサイト開発となると、携帯電話対応はもう必須と認めざるを得ない。（サイトの性質にもよるのではとか言う話はとりあえずおいといて）

しかしながら、WebサイトをつくるWeb屋（＝Webシステム屋、Webデザイン屋）の立場から言うと、頭が痛いの一言である。

なにしろWebサイトの携帯電話対応は面倒な作業だ。初めから携帯向けサイトオンリーで設計、構築されているならいざしらず、既に運用状態にあるPC用のサイトの携帯電話対応版をつくるということは、設計、構築（テスト）、運用という全ての面においてもう一度やりなおすこととほぼ同義だ。

PC用のサイトでさえ、ＯＳとブラウザとバージョンの組み合わせ次第で発生してしまうヘンテコな問題に対処しなければならない。IE6のCSSレンダリング機能のバグは数年もほったらかしだし、JavaScriptの挙動の違いに悩まされることもしばしばだ。 そこへもってきてケータイも対応せよときたら、３キャリア対応という大きな問題が待ち構えているのはもちろんのこと、数多くの機種の微妙な違いにもいちいち対応していかなければならない。

話がそれるが、某携帯キャリアのある機種のブラウザが、formのselectボックスにおいて、 <option value="1">男性</option> という選択肢において最終的に「1」ではなく「男性」という値をPOSTしてしまうということを知ったときにそのケータイを全力で叩き壊したくなった覚えがある。

話を戻そう。まあ、3キャリア対応しなければならないとは言ってもドコモが提唱するC-HTMLで書いてしまえば実はドコモ以外のキャリアでも読めちゃうからそれでいいんじゃない？という話もある。

たしかに、静的コンテンツが主体のサイトならC-HTMLで書き直すだけでなんとかなる可能性が高いのでそれほどの苦労でもない。しかし、会員認証機能だとかショッピングカート的な機能がある場合には携帯電話対応はほんと面倒だ。セッション管理の方法ひとつとってもPCとは違う方法を考えなければならない。セキュリティ耐性もからめると複雑な問題をはらむ。

もちろん、PC向けのコンテンツをケータイ向けに変換できる製品などもあるが、複雑な機能にまで全て対処できるとは思えない。また、それを買ってでもやるほどの価値が携帯サイトにあるのかという問題もある。 あるPC向けサイトが広告出稿で利潤を得ているとして、では携帯サイトに対する広告出稿料はPCのそれと比べてどうなんだろう？携帯端末向けサイトを構築するコストに見合うだけのインカムがケータイサイトにみこめるだろうか？判断のしどころだ。

そうこうしている間に携帯電話はどんどん進化し、ＰＣ用のブラウザと同等の機能を持つブラウザ＝いわゆるフルブラウザ＝が登場した。

携帯フルブラウザ3種を比較する(ITmediaモバイル 2005.3)
フルブラウザ(Wikipedia)

もしも、多くの携帯電話のブラウザがこうしたフルブラウザになれば、Webサイト開発側の悩みの多くが解決される。パケット定額制の浸透も後押ししてくれるだろう。

携帯電話のブラウザのフルブラウザ化を待つのが先か、３キャリア対応設計をコツコツ地道にやるのが先か。現状では地道な手段のほうをとらざるを得ないとは思うが、状況が変わるのにそれほど時間のかからないこの業界のことだ。悩みどころでもある。

see also:
Japan.internet.com デイリーリサーチ - フルブラウザ利用者は約16％、その6割がプリセットのフルブラウザ(2006/5)