時系列の節目？

年末に近づくとところどころにアップされる「総括」は読んでいて楽しいですね。私も、いいのが書けるといいんですが、ちょっと書くスイッチが入らないです。 blogで随時時系列の記録を残しているからかな。何か残せたか、何をやりかけか、などを考えたりはしますけど、ここでまとめる気がしない。なぜかしら。

今、なにげなく年末に感じることは、年の区切りがあまり大きな変化に思えなくなってきていることですかね。年賀状は書かないし、帰省もしないのでその分のタスクもありません。

年末だろうが平生だろうが時間軸はシームレスなものですから、それをこつこつ過ごすのが気持ちよく感じてきたんだと思います。てことで、私は年末年始とくにいつもと変わりなく、ちょっと長めの連休、くらいのノリです。 それくらいが心地良いんです。

1985年くらいからの、なにがしかの成果物が世に残っていますが、振り返れば5年ごとに大きく流れに変化があります。 2000年代前半5年は、そこそこスリリングで楽しかったですよ。成行に任せるのは好きではないほうなので、後半の5年もまた、振り返れば大きな変化を感じられればいいなと思います。

2005年以降も、いろいろ一緒にやっていきましょう。よろしくお願いします。

足の裏の米粒。

「IT関連の人材」が何かをあえて定義しないにしても、そう呼べる人材が不足しているという感覚は多くの人が持っているようだ。「デキル人いないですかね」「凄腕の人ってどうやって育てるんですか」。あるいは「IT人材の育成ってどうしたらいいですかね」「オープンソースソフトウエア書けるプログラマってどうやって育てるんですかね」と。意見を聞いてくださる方がいることはありがたいが、さてどうしたものだろう。


人材教育？

IT人材育成会社、教育機関は、IT業界で働きたいものの経験がない人間を集め、高額な授業料と引き換えに数年授業を受けさせ、「資格」というシールをペタっと張って人材を「作り」、世に送り出してきた。ところがどうだろう。かつての飛ぶ鳥を落とす勢いも、いまや見る影もない。教材も教師もスタッフもすっかり古びてしまい、卒業生の評判と同期して就職率が激減。特別な成果もミラクルも期待できないため、いまや非常にお寒い位置にいる。


需要の問題？

最近、電車の吊り広告のトピックに、SE、プログラマなどの大失業時代を危惧するものが目に付くようになった。「転職してはいけない。今、あなたはたぶんもらいすぎている」と。なかなか良心的なメッセージだ。雇用促進している会社は、外向けには「不足」といいながら内向きでは「飽和」と言っている。この構造をある程度理解しなければならない。

たとえば、収益を上げている会社がM&Aによる事業拡大というわかりやすい方法をとってくると、拡散の時代から収束の時代への遷移は加速する。そこでは組織の再構築が行われ、バッティングするレイヤーが整理される。もちろん、組織が最適化されると事業は拡大するのでハッピーなわけだ。

そこに「大失業時代」があるとすると、「必要不可欠」ではないレイヤーにもっとも大きな影響があることになる。これまではなんとか仕事のあったのだが、専門性があるわけでもなく、特別伸びるわけでもない、教育会社か企業に「作られた」人材。そのような人たちは「整理」を宣告されると、なぜ自分がそんな目に遭わなきゃいけないのか、さっぱりわからない。また、新たな「シール」を求めて行動する。そして自分を「作ってもらえる」ところを求める。（その新しい「シール」は、「社長」だったりする場合もある）


コミュニケーションスキル？

そんな状況の中、「コミュニケーションスキル」という、IT関連の知識とは関係ないことを教える人たちが現れた。「コーチング」「プレゼンテーションスキル」とかそういうものもこの類だ。IT業界にまともに日本語を話せる人が少なすぎるのは事実なのでありがたい部分もあるが、そうかと言って技術者が修練を怠りつつ口八丁、というのは問題だ。これらは中身あってこそ意味があるものなので、中身の詰まった人間を生産する手段ではない。

突っ込まれるとさっぱりわからない言葉を、さもわかったようにあやつるプレゼンテイターって増えているが、名刺をもらうと「シニアSE」とか書いていたりするから失笑モノだ。言葉遊びで煙に巻くとお金が出てくるほど、ユーザ企業は無知ではなくなってきている。


資格？

「スキルを身につける」という言葉に摩り替えて、ぱっと見てわかる差別化、競争力をわかりやすく身に着けることにエスカレートする。わかりやすい解決策としてもたらされたのが「プロフェッショナル資格」。日本にどれくらいあるんだろう、昔から結構資格マニアっているよね。

しかし、他の業界の「資格」は「免許」の意味合いがあることが多いのに対し、IT業界はそうではない。これを競争力確保という観点では何ももたらさない、むしろ消費者の貯金を食いつぶすだけのものになっていることに早いところ気がつかなければならない。

「試験」にいいところがあるとすると、未知の、特定のテーマに関して十分に勉強する際の習熟チェックに使うという部分だろう。資格試験は、勉強意欲の里程標になってくれるかもしれない。TESTはTESTであってそれ以上でもそれ以下でもない。IT資格、Ph.D、MBA、あるいはどんな資格をとることを目標にしていても、それそのものは自分をその道のプロフェッショナルにしてくれるわけではない。

ある賢い人が言ったんだそうだ。
「資格とかけて足の裏の米粒ととく。
　取るまでは気になってしょうがないが、取っても食えない。」

はっきり言えば私はプロフェッショナル人材を「作る」方法を知らない。もちろん、これまで学校や先生と呼べる人たちから学んでこなかったというわけではない。結局彼らから私が得たものを説明するとすれば、学んだ内容というより、「学び方」ではないかと思う。そこでは自分を習熟者、プロフェッショナルとして「作ってもらう」ことは完結しない。

自分が「そうなる」と決めて前進している人同士が、相互になにがしかの刺激を与えあうのが、成長できるプロフェッショナルコミュニティの姿だと思う。

"As iron sharpens iron, so one man sharpens another. "
- Proverbs 27:17

POPFileの決め手になる「ベイズ理論」って何だ？

スパムを判断するためのメカニズムに迫る

POPFileはいったいどのようにしてこれほどの高い精度でメールを正しく分類できるのだろうか？　その秘密はベイジアンフィルターにある。POPFileはこのベイジアンフィルターという数学理論を採用してメールを解析しているのだ。

ベイジアンフィルターの基礎となっているベイズ理論(Bayes Theory)は、古く18世紀の牧師であり数学者であったトーマス・ベイズ(Thomas Bayes)という英国人によって考え出された原理だ。
ベイズは、「物事を判断する確率は、その物事の観察者にとっての不確かさである」と説き、神の存在でさえ数学的に示すことができると述べたそうだ。この考え方で物事を推定することをベイズ推定(Bayes Estimation)という。
簡単に言うと、新たなできごとを予測する際には、すでに起きている事実と、観察者自身の経験を考慮に入れることにより、かなり正確に推測できる、という考え方である。実生活では当たり前っちゃー当たり前だが、数学的にやるとなると簡単そうには見えない。

たとえば、あなたに宅配便で小ぎれいな小包が届いたとしよう。それが何かうれしいプレゼントか、そうでないかを予測することだろう。単純に確率を述べるなら、いちかばちか、50パーセントという確率だというのもあながち悪いとはいえない。でも、どこか実際的ではない。
実際には、その小包の大きさ、重さ、差出人、内容に関する記載事項などという観察に基づく「事実」と、過去の「経験」に基づく確率、つまりプレゼントだと思ったらそうでなかったという確率、あるいは期待通りだった確率を考え合わせるからだ。これを考慮に入れてはじめて、実際の結果にかなり近い予測が可能となる。

この考え方で正しい分類を予測するために、POPFileは最初にいくらかユーザーのトレーニングを受けると、それらのメールから学習する。
つまり、添付ファイルやHTMLのタグやコメントを取り除き、残されたヘッダと本文をコーパス（corpus）と呼ばれる単語群に分解する。 そして、分類されるメールの共通点を知るために、出現頻度の高いものを重み付けし、こうしてメールにおける各単語の出現と各バケツに分類された確率を計算できるようにコーパスデータベースを構築する。

新たなメールを受け取ると、POPFileはそのコーパスデータベースに基づいて、「バケツ」への分類に影響を及ぼす単語を抽出し、その単語の有無や出現回数などから計算して、いずれのバケツに分類するかを決定する。
その作業の過程で、POPFileは未知の単語にも遭遇するわけで、それによってセルフトレーニングを行うため、ユーザが間違いを指摘しない限り、自然に精度の高いコーパスデータベースができあがっていく。 間違った分類をしたことを指摘される（つまり手動で再分類される）と、POPFileはそのデータベースを訂正する。これにより、POPFileは「観察者の判断」を学習し、分類精度を上げることができるのだ。

ためしにPOPFile UIの「履歴」メニューから、spamに認定されたメールの「件名」をクリックしてみて欲しい。すると、メールヘッダと本文のあちこちがバケツと同じ色にされて表示されている。
さらに、ページの下のほうから「単語の頻度を表示」「単語の確率を表示」というリンクをたどると、各メールの分類に大きな影響を及ぼした単語が順に表示されており、大変興味深い。

POPFileのデータベースにスパムで使われる単語が十分蓄積されていくにつれ、業者はスパムらしからぬ単語を使ってメールを送らない限り、その判定をすり抜けることは難しくなっていく一方だ。
しかし、そのようなメールでは、スパム業者の目的を達することはできないだろう。スパムのフィルタリングの技術が向上するにつれ、彼らのビジネス上の目的が立ち行かなくなり、ついにはスパムメールという手段をあきらめてくれるようになればよいのだが。

(この文章はiNTERNET Magazine 2004/3, p.105に掲載された文に若干加筆したものです)

オープンソースの責任の所在？

マイクロソフト社のバルマー氏は、自身の講演においてLinuxについてどう考えているかについて示した際「Linuxのアキレス腱は誰も責任を負わないこと」だと述べています。これについて、いくつかのblogで「じゃあMSはどうなんだよ」との指摘を拝見しました。いずれの主張も、なにがしかの事実や現状を観察して出てきたものでしょう。ただ、残念ながらこの講演を直接聞いていないのですが、わたしがバルマー氏に質問できるのなら、ビジネスとしてどの局面において「責任を負う」ことが欠落していることを指摘したいのか、そこを尋ねたいですね。

「ソフトウエアそのものの責任を負う」？

LinuxカーネルにせよUNIXライクに統合されたものにせよ、複数の人間によるプログラムの複合体であることは言うまでもありません。プログラムが企業によるものであれ、個人によるものであれそのコードに対する責任をプログラマが負っていることは事実です。つまりプログラマが企業ハードウエアに対応するデバイスドライバをIBMやNECのような企業が作ってオープンソースとしてコントリビュートしているケースでも、個人が何かのコードをコントリビュートした場合でも、です。

対価は金銭とは限らないのは言うまでもありませんが、とにかくそれに対しその「責任を果たす」ということを、コードを公開し、著作権者を銘記し、フィードバックを集約していくことなどの方法で果たしています。それを怠ると、そのコードは、他人に引き継がれるか、オルタナティブコードの出現などにより淘汰されていきます。つまり、時の経過と共に、より効果的に責任を負う著作者によるコードへと選択されていきます。

別にオープンソースだから責任を果たしやすく、プロプライエタリだと責任を果たしにくいというハナシではありません。無責任なコードが永久的に許容されつづけないことをどう保証するのかについて、プロプライエタリなソフトウエアとオープンソースソフトウエアではアプローチが異なるだけです。（この部分はもう少し話したいことがありますが、今回はここで止めます。）

「ソフトウエアの利用に責任を負う」？

オープンソースソフトウエアによるビジネス実現に対価を得ることは構わないことになっています。プロプライエタリなソフトウエアは有償でライセンスを取得することにより、活用することができます。この局面で、インテグレータはMSのようなプロプライエタリなソフトウエアも、オープンソースソフトウエアも、どちらでも選択することができます。この場合に、MSのような主体者がないオープンソースソフトウエアに関する責任は誰がとるのか、という問題があるでしょうか？ありません。オープンソースインテグレーションの責任においては、シンプルな話、対価に対しその責任があるというのが答えです。

築地で寿司を食べる場合、客はその寿司のクオリティの責任を誰に求めますか？魚自身にですか？漁師ですか？市場関係者ですか？運送業者ですか？違いますね。寿司屋に求めます。なぜか。単純に、客は「寿司屋のサービス」に対価を払っているからです。それがインド洋のまぐろなのか、近海モノなのかなんてのは関心はあるかもしれません。が、責任という観点では、それはどうだっていいんです。「近海モノがおいしいらしい」という理由、あるいは最近見た「あるある大辞典」で知った知識をもとに（ものの例えです）、「近海モノ」を注文することがありますが、それでも「寿司屋のサービス」に対価を支払っているのです。

寿司屋は、その魚のクオリティを確保するために、あらゆる手段を使います。実際に海に出ている漁船を調査したり、市場関係者の特定の目利き人やディーラーに選定をアウトソースしたりと、さまざまな方法をとるわけです。どうするかは寿司屋が決め、寿司屋は素材に対しその対価を支払います。この連鎖の最後は「海」ですが、ここはオープンソースソフトウエアよりもはるかに「責任」の所在が見えない世界です。もっともはるかに安定し、完成しているように思いますが。いずれにしても私たちはそれに依存して生きているのです。神は偉大です。

もちろん、Redhat、TurboLinux、MiracleLinuxのようなディストリビューションベンダーが負うべき範囲は当然存在します。彼らは編集価値により対価を得ていますから、どのソフトウエアを自分たちのディストリビューションに含めるのかに関し、責任があります。自分たちも開発に参加することにより、その責任を果たしやすくなっているのでしょうが、それでも全部を自分たちで作る必要はありません。また、Debianのように、ボランタリで編集価値を生み出しているものもあります。彼らは彼らなりに「対価」が何であるかを知っています。

そこで、インテグレータは、どの方法で「素材」を調達するかを考え、選択します。良くないものは使わなきゃいい。ただ、シェア、評判、情報、あるいは経験など、どの根拠によって選択するにせよ、それが顧客の要件を満たしているものであることを証明する責任があります。それに対して対価を得ているのですから。

問題は、「オープンソースソフトウエアによるシステムの品質に責任を持つのは誰ですか？」と顧客から尋ねられたときに、SIerが「最終的に導入するインテグレータ、つまり私たち」だと明確に答えようとしないことではないでしょうか。最近、あるインテグレータ会社の社長さんと話していて、「この厳然たる事実を誰も明確に述べようとしない」と言っておられました。指をさして、「あいつのせいだ」と言いたい傾向のためです。マイクロソフトの製品がハングアップしてブルースクリーンを出しても、「うちのせいじゃありません、MSのせいです」と。食中毒を起こした客に、「最近の築地は良くなくてねぇ」とか言うのと大差ありません。

市場がないと寿司屋が経営できないのと同様、外部から調達したものをもりあわせてサービスにするという図式は非難の対象ではありません。むしろ、現状のITサービス提供連鎖においてエンドユーザから最大の対価を得る位置にいるインテグレータの目利き力不足で、かつ自分でロクに扱えないものをテキトーに扱って対価を得ているのであれば、それこそ非難されるべきだということです。オープンソースを扱ってなにがしかのサービスあるいは製品を提供する企業が、誰でも扱えるなどのメリットだけを享受し、その品質や性能に関しあまりにも無責任、という状況に問題があるのでしょう。

バルマーさんがこう言ったのであれば良かったのに。「オープンソースで無責任なビジネスをやる会社が多い」と。
ほんとはマイクロソフトさんこそお困りのはずですしね。あ、いや、矛先がそれてラッキーだったのかな？;-p

日経産業新聞記事：「フィッシング詐欺に注意」

8月23日の日経産業新聞7面、「情報技術の死角　安全対策を問う（上）オンライン銀行 - フィッシング詐欺に注意」という記事。少々協力させていただきました。主旨は、ご覧いただけるとわかるとおり、対策方法すべてに言及することにあるのではなく、そのうちのいくつかのわかりやすい指標をもって、特定のサービス分野にフォーカスすることにより、より具体的な対応状況について示すことにあります。

今週も、高木さんと門林さんとWASF関係でテレコンしていたときにもふと出た話。「WEBサイトの特定の危険性に関する具体的な数字情報って出てこないよねぇ。」 自分たちが調べた中で何パーセントが脆弱だった、とかそういう数字は特に出しにくい。

実はWASFの第0回カンファレンスでは、三井物産の新井さんがずばっと数字を出したので、非常に注目されました。その後も、情報セキュリティEXPOなどでわたしがぽろっと数字を出すと、あとで何社の記者に、「あの数字は？」と。それほど出ていない。出しにくいんだけど、出していくことの意味は大きい。そういうことなのでしょう。危険というものは、犯罪被害と同じで、あるかないかなんですけど、なにか数字がないと真剣に考えない。そういうものなのでしょう。

扱いにくい情報をもう一つ。フィッシング対策のように、かなりの程度ソーシャルセキュリティに関係している場合、つまり「マナー違反」「詐称されやすい」などの軽めのルール違反による危険が存在しているものの、それも先刻承知で採用しているものは扱い方が難しい。脆弱性通報機関では、実際問題この種類の取扱は難しいでしょうね。もちろん、策がないわけではないですが。

その点、この記事は大変大胆で、それゆえに大変わかりやすい。提示したいくつかの指標をもとに、金融機関のサイトを調べてくれて、しかも一覧表にしてばっさり斬っています。自分のメイン銀行だけチェックして、「よし」と思うだけでも、これでお腹一杯になられてもナニなんですが、まずはご一読を。(^-^;)

WEBセキュリティの社会的要素と「しつけ」

先日の情報セキュリティEXPOの専門セミナーで、「WEBセキュリティ」のテーマを担当しました。その講演の報道として、日経BPにて「“フィッシング”に利用されないようなサイト作りを」 - テックスタイル岡田氏 という記事が掲載されました。

実は、フィッシングの話に終始したわけではなく、むしろこの話題はWEBのセキュリティの考え方をどのように反映させるか、それによってどんなリスクが軽減できるか、という話の一環で補足的、例証的に取り上げたにすぎません。この機会に、そのあたりを少し説明したいと思います。

前提として、セキュリティは、技術的な要素に加え、社会的な要素があります。ビジネスの観点からすれば、WEBサイトで行なうどんなことも、その企業の社会的な責任が強調されてしかるべきです。ですから、企画段階において、WEBセキュリティは技術の話より先に、社会的な責任のほうを検討しなければなりません。

技術的な要素が、機密性(Confidentiality)、保全性(Integrity)、可用性(Availability)の3つであるのに対し、社会的な要素とは、説明能力(Accountability)、信ぴょう性(Authenticity)、信頼性(Reliability)の3つが挙げられます。

技術的なセキュリティ要素の優先順位は、社会的な要素によって判断され、強弱がつけられることになります。

たとえば、顧客の情報資産がクリティカルな脅威にさらされていることがわかった場合、可用性のためにサイトをそのままにしておくのはよくありません。むしろ可用性は犠牲にし、機密性を守るためにWEBサイトを止める、という判断があることでしょう。これは、信頼性という社会的なセキュリティを守るというミッションによって優先順位が判断されるわけです。

そうすると、セキュリティを守る「技術」の位置付けが明確になってきます。これは、社会的な責任を果たすという目的のもとに、生じ得る難しい問題を極力減らすための道具なのだ、ということです。それをどう操るか、ということは経営的な問題だからです。 社会的な責任からはじめ、そして技術的な手法にブレイクダウンしていくのです。

そこで、例えば、昨今流行の「フィッシング(phishing)」 - なりすましサイトにユーザが「釣られる」被害 - を軽減するためにできることを、どのように整理できるか考えるとしましょう。 下記の例は詳細な点を網羅していませんし、一概に○×はつけられないでしょうが、検討の進め方を示しています。

まずは、「説明責任」。すると、企業が説明を意図的に怠ることにつながる手法（たとえばアドレスバーを隠す、フレーム表示する、など）をどうするか考えられます。「信ぴょう性」を確保するために、紛らわしい、容易に誤用される手法（似たドメインの許容、フレーム表示）を考えます。最後に、「信頼性」を確保するためには、「こういう方法はとらない」ということの明示や、オンライン・オフラインを問わず顧客とのコミュニケーションの中で企業のサービスの姿勢（プライバシ保護、本人確認のポリシー、他の業者によるクッキーの有無など）を示していくことができます。

あらゆる種類の詐欺、詐称はなくならないでしょう。だからこそ、企業としては、ユーザがそれを信じてよいのかどうか判断できるほど、最善を尽くしているかどうかを考えなければなりません。その点で「社会的なセキュリティ」の3要素は、思考ツールとして非常に有用です。起こり得るあらゆる脅威に関して、それに対応する技術を評価するところから始めると泥沼に陥ることがよくあります。セキュリティ手法の検討に疲れ果てると、セキュリティぼろぼろのサイトになってしまいかねません。

そういうときにこそ思い出して欲しいことがあります。つまるところ、セキュリティ問題は特定の手法の善し悪しの問題というより、「しつけ」の問題だということです。「セキュリティは結局、人だ」と言われますが、人のしつけという意味は当然のことながら、ひいては、採用する方策にそれは反映されてきます。レベルが上がってくると、そのガイドラインは「ドレスコード」にも例えられるのでしょうね。

落ち着いて、その企業のあるべき姿勢を原点に、もう少し上の角度から見て整理すると良いのでしょう。企業のWEBサイトは、その企業の「しつけ」について良くも悪くも雄弁に語っているんですね。自戒の意味をこめて、精進したいと思います。

IPO目論見書読書会：「本格的な」オープンソースビジネス？

IPO時の注目：「目論見書」

テンアートニのマザーズへの上場承認が7月1日、発表されました。同社はJava、Linux、RedHatなどというキーワードに関連する会社です。Javaや商用製品ディストリビュータとしての業績と、数年前に合併した喜多さん率いるNothern Lights(ノーザンライツ)ブランドのハードウエアでも知られています。

IPO(株式公開)発表における関心が集まるのは、上場資料、目論見書の「事業リスク」に関する説明の項(英語ではRisk Factor/Prospectus/Form 424)です。この欄は数年前に上場したぷらっとホームの書類にはオープンソースソフトウエアとビジネスの関係について、日本の株式史上初めての解説がありましたし、米国Redhatの「リスクはインターネットがなくなること」など、企業の活動方針の主張として興味深いものがあります。


事業に関する記載

今回、テンアートニの目論見書は「新株式発行並びに株式売出届出目論見書 」の第二部【企業情報】にあります。まず、同書11ページ (PDF内の24ページ)に「3【事業の内容】」、リスクについては同書20ページ (PDF内の33ページ)からの「3【対処すべき課題】」、「4【事業等のリスク】」に記載されています。

同社はまず、「事業の内容」を示す部分で、オープンソースのLinux導入のメリットとして、開発コストを低く抑えることができる、コスト競争力がある、という点のみを挙げています。リスク説明においては、Javaのリスクとして他の技術の台頭の可能性を挙げているのに対し、Linuxに関しては、製品を販売するという観点に特化して記載されています。

そして、事業の課題として３つの要素、すなわちLinux関連の人材確保育成、Linux訴訟問題、Java製品の拡販すなわちパートナーシップの確保について言及しています。

リスクを説明する部分で、訴訟問題の可能性としてSCO問題について「(5)知的財産権について」という節で言及しています。この問題に関しては、レッドハット株式会社(日本法人)とのビジネスパートナー契約、そしてOSDLとの協力による情報収集に務めるとしています。


ひとつの視点「本格的なアプローチ」

パートナー戦略などにもいろいろ突っ込みどころはあるんですが、ここでぐっと視点を絞るとすると、「テンアートニは本格的なLinux企業としてオープンソースによるサービスにどう取り組むのか」という点をみることができます。

大前提として、現在、Linuxは、ボランティアプログラマの集団によってではなく、企業内にいる職業プログラマによって開発されています。それは企業として成果物をオープンソースとして世に出すことにコミットしていることを意味しています。ですから、「開発コストが安い」、というのは、現在のLinuxには当てはまりません。他の主要ソフトウエアに関しても、政府や団体によるスポンサーシップや、開発主体企業が存在し、成果をオープンソースとするスタイルが多くなっています。開発は決して、無料ではありません。総じて、オープンソースソフトウエアそのものを「開発コストが安い」と言うのはナンセンスです。

ユーザへの影響でわかりやすいのは、オープンソースは、その「利用」に関して自由であり、オープンだという点です。オープンソースソフトウエアの特徴が「コスト競争力」ではなく、その「開発プロセス」にあり、それゆえにプロプライエタリなソフトウエアと比べて、ユーザがとるべきリスクが上にも下にも異なるという点があります。

すると、その利用の自由に伴う責任 - リスクも含む - については誰にかかってくるのでしょうか。顧客から対価を得たインテグレータがユーザに対して責任を負うことになります。ユーザはLinuxを買うのではなく、道具としてその機能を買うからです。Linuxを使ってそれを実現することにより、対価が発生しますから、その対価を受け取ったインテグレータはその品質に責任を持たなければなりません。そう、オープンソースインテグレーションの品質に責任を持つべきなのは、そのインテグレータです。

インテグレータの立場でこれをどのように行なうかについては、あえて平たく言いますが、「深さ」があります。これが、トラブルシューティング能力や、新機能、想定以上の規模への体力を図るものとなります。

1. ソースコードは使わない。ディストリビューションのバイナリを使う。


2. makeするときに必要に応じ使う。それでも、大抵コードそのものは見ないし、直さない。


3. 障害があればソースコードまで追いかけ、パッチを提供。新機能が欲しければ開発に参画。

深度1の会社は無数にあります。プリインストールサーバで済む話であれば、インテグレータの必要もないかもしれません。設定さえすれば完結しますので、オープンソースソフトウエアを使うかどうかさえほとんど関係ありません。深度2は、アプリケーションを手がける会社ではやっていることもあります。深度3まで行ってはじめて、「ソースコード」が関係してきます。インテグレータの立場では、この深度3からが「オープンソースソフトウエアを扱う」ことを意味します。深度3以上として、「なにかの開発母体、主体になる」というレベルがありますが、それはインテグレーターのサポートレベルの議論とは別の話にも思えるのでこの論点からははずします。

テンアートニ社の目論見書を見る限りは、生じ得る問題の対応をRedHatとOSDLの陰にひそめるアプローチをとっています。はっきり言えば、明確にされているのは深度2までです。RedHat社との関係次第。しかも日本法人。ティファニーの代理店って、ティファニー以上のものにはならないですよね。米国のRH株価はティファニーに例えるにはオソマツだとは思いますが･･･。いずれにしても芳しくないです。

ただ、実のところ、どうなんでしょう、プロフェッショナルコンサルティングや、ハードウエアの開発事業をするわけですから、深度3が十分あるはずです。それなのに、どのように取り組むのかについては、語るに落ちることを避けたかったのでしょうか、この目論見書では読み取れませんでした。 それでも書きようはあったと思うんですね、、、。ソフトウエア開発能力の維持について、あるいはOSDLでの担当について、など･･･。オープンソースによるサービスはそこがポイントなんだということを、喜多さんはご存知のはずだと思うだけに、やや残念でした。

上場で集めた資本をきっかけに、より「本格的な」オープンソースサービス企業としてのご発展を期待したいと思います。

■テンアートニのIRサイトと目論見書
http://www.10art-ni.co.jp/ir/index.html
http://www.10art-ni.co.jp/ir/pdf/040701mokuromi.pdf

■ぷらっとホーム上場年度のIRサイトと目論見書
http://www.plathome.co.jp/about/ir/release_2000.html
http://www.plathome.co.jp/about/ir/pdf/kari.pdf

ペット空輸HOWTO - ミニチュアダックス、羽田空港より

０．はじめに

本記事は、私がミニチュアダックスの「フック」を羽田から大阪伊丹空港に送ったプロセスでわかったことや個人的な感想も含めてまとめておくことにより、有用な情報を残すことを目的としています。その時点でインターネットを検索して助けになる、まとまった情報はほとんど存在しなかったからです。それで、この記事の引用、複製については私に許可を求めてさえいただければ可能な限り協力する意志があります。誰でも閲覧できるサイトからのリンクは原則として自由です。ただし、本記事をもとに行動するいかなる結果の責任も負いかねますのでご了承ください。


１．ペット空輸？

飛行機での旅行の際にペットを同伴する申込は、通常の荷物預けのカウンターで可能です。しかし、人間は移動しない場合でもペットだけを空輸することができます。ペットの売買などでは良く行なわれていることなのですが、情報が不足しているせいか手続きが煩雑に見え、代行業者のWEBサイトばかりが目に付くのが現状です。しかし、やってみれば非常に簡単で、費用も大してかかりません。


２．予約

ペット空輸を取り扱ってくれる航空会社は2社、日本航空貨物(JAL)(03-5757-3105)と全日空貨物(ANA)(03-5757-5650)です。各々、その取り扱いカウンターの電話番号が公開されていますが、実際にJALのサイトやANA(Air Do)のサイトから発見するのは易しいことではありません。

電話で両社に問い合わせしてみたところ、日本航空のほうではケージは貸してもらえない、当日予約可能、飛行機時間の90分前に手続き完了が条件でした。他方、全日空貨物は、ケージは500円でレンタル可能(要問い合わせ)、原則として前日予約、60分前までに手続き完了、とのことでした。

ケージをどうするか決めかねていたことと、全日空貨物のオペレータの方のほうが親切で丁寧な応対だったので、全日空貨物のほうに依頼することにしました。ただ、当日に送りたかったので「なんとか今日の午後便にのせたい」とお願いしました。いつもOKとは限らないのでしょうが、午前の電話でしたから時間的余裕もありましたし、空きがあったのでしょう、結果はOKでした。その電話で、便を予約し、ケージも確保していただきました。


３．西貨物地区へ

ペット空輸は「国内貨物」の取り扱いとなり、人間が乗降する空港カウンターとは全く別のところに行かなければなりません。羽田空港の「西貨物」と呼ばれる貨物地区のほうに行きます。(地図)

自動車で行く場合は、空港の前を通って357号線のほうに入らないように気をつける必要があります。（私はまさにそうしてしまい、西貨物を道路の向こうに見て口惜しい思いをしました^^;）バスで行く場合には空港の1Fロビーを出たところの13番バス停から出る循環バスで「西貨物」バス停まで行くことになります。タクシーで行っても1メータくらいだと思います。行き先はもちろん、「西貨物地区」。


４．西貨物に入る

他の空港でも同様のようですが、貨物地区に入るには、やや物々しいゲートで入場許可を得なければなりません。入場する人全員の、免許証やパスポートなどの身分証明書が必要です。バスやタクシーで行く方、また車に同乗して行く方はお忘れのないように。ゲートの方に入場者の名前、時間、車のナンバーなど記入するよう求められますが、親切に教えてくださるのでその通りにします。

入場許可証などをビニールケースに入れてくれますので、出場までなくさないように所持して入場します。首からぶらさげるものも入っていますが、特に出して使いませんでした。


５．ペットを預ける/受け取る

ゲートを入るとすぐにANAと書いた国内貨物受付カウンターがあります。比較的小さく簡素な建物に見えますが、他に見間違うものもありませんので安心してそこに入っていきましょう。参考までに、受け取りのカウンターも同じ場所です。「予約していた○○です」と言えば、あとは親切に記入すべき書類や受取人に関する情報の記載、あとは免責証書にサインが求められます。あと、損害保険の加入について尋ねられますが、これは各人の判断によるでしょう。（わたしは不要と答えましたが。）

ケージを確保していたものの、こちらでプラスチック製のハンドキャリーを持参していたため、それで送ることにしました。借りたケージよりも小さく、重量も軽いので非常に安くつきました。そう、送料は、ケージの大きさと、総重量に依存します。ケージを借りても5000円程度なのですが、持参のもので計量したところ、子犬の重量をあわせても4キロ程度だったため2000円もかかりませんでした。

またたく間にネットに入れられましたが、持って行く前に「もういいですか？」と一言尋ねてくださったのはなかなか好感が持てました。「よろしくお願いします」というやいなや、さっと持っていかれました。こういう手順はさっさと進むほうがこちらも心境的に助かります。


６．ゲートを出る

ゲートは、入場のときにもらった入場許可証を返却するとするっと出場させてくれます。あとは、飛行機にゆだねるのみです。受け取ったよ、と行き先の空港で待つ受取人からの連絡を待つだけです。


７．付加情報

ペットの空輸は比較的リスクの低い、ペットへの負担の軽い輸送方法のようです。実際、車酔いする犬でも嘔吐物がなかったくらいでした。空輸直前に水を与えておくことは勧められますが、えさを与えることは避けたほうが賢明でしょう。いずれにしても、空模様というのは予測不可能なことが多いですから。

この記事に関連することで、何か質問があったら遠慮なく私まで知らせてください。また、この記事がお役に立ったなら、それも知らせてくださるとうれしいです。

レイ・チャールズ逝去 - Ray Charles died.

今朝5時過ぎに時事通信からの速報が、「米国を代表する歌手の一人、レイ・チャールズ氏が死去」とのメッセージを配信してきた。（少し詳しく書いているワシントンポスト誌にリンクしておく）肝臓を患っていたとのこと、73才だそうだ。肝臓か ... さもありなん、という感じか。

レイについては音楽的な「偉人」。次の新曲を期待している、とかそういうミュージシャンではないから、音楽界が何か大きなものを失ったかといわれると、そうではないように思う。彼の作品 ? プライベートでは2回の離婚、12人の子供がいるそうだが ? 彼の音楽から影響を受けた、R&B、SoulミュージックのDNAを引き継いだミュージシャンは増えることはあっても減ることはないだろう。

いや、「Ray Charlesが聞けなくなる」というのがあるとすれば、彼の死去以外の要因だろうね。最たるものは輸入CDの規制だとか、、、。

万人のスピリットに訴えかけてくる彼の歌の価値は、童謡とか唱歌の類、あるいは「みんなの歌」の世界に入ってくるものではないかな。Rayが自分の歌をこれからどうしたかったかは私には知る由もないが、先人が受け継いでもらいたい何かを残す気持ちに国境はないだろうよ。なんにせよ、人が作ったすばらしいものを賞賛する機会を制限するのは、価値の認識不足か、あるいはある種のひがみにしか見えない。

私はレイ・チャールズに「影響を受けました」というほど詳しくないが、このニュースを聞いて、Ray版のSomething's wrongを聴いたり、Blues Brothersに出演していた元気なRay Charlesを見たくなったり。大したことは思いつかないにしても、何かを成し遂げる、何かを残す、何かを発見するということについて少し考えることにしよう。

六本木PIT INN閉店かよ！

先週なにげなく注文したFourplayのアルバムをiTunesにさくっとインポートし終わった頃に、衝撃的なニュースが飛び込んできた。六本木交差点からドンキホーテの方向に歩いていったところ先にある老舗のライブハウス、六本木ピットインが、ビルのオーナー会社の経営破たんがきっかけで、閉店するんだそうな。通い詰めたことこそないが、その影響を色濃く受けてきた私としては、なんともショック。

「カシオペアやスクエアなど数多くの人気グループを輩出。坂本龍一さんらによるＹＭＯ結成の舞台ともなった」と、日経の記事。どのグループも、とてもとても影響を受けた。このライブハウスがなくなったからどう、ということではないんだが、日本のミュージシャンの品質向上に貢献してきたこれらのグループの出発地点は重要文化財とは認めたいくらいだ。例えば、レコード会社なりがそういう「文化財」の保護団体になったりしないかな。

そういえば、数年前に福岡BLUENOTEが閉店した後、オーナーが変わって復活したよね。ニューヨークのアポロシアターやボトムラインが閉店するというと、ニューヨーカーたちはどうするだろう？日本でのフュージョンブームは見る影もなく、むしろスイートベイジルやBLUENOTEのような少しハイクラスなJazz用の箱に入ったオツな宝物になってしまっているのだが、、、。

それにしてもなんとかならないものなんだろうか。
とりあえず、7月末までに足を運んでみよう。

Let's research:セキュアなWEBサイト

3月にプレスリリースしたとおり、WEB Application Security Forumというフォーラムを立ち上げました。発起人としての意図や意向については、おおよそプレカンファレンスの報道のとおりです。「情報を安全に扱う」ということがビジネスの発展に直接関係することを認識してくれた企業がたくさんスポンサーになってくださっています。WEBセキュリティに関する情報は、非常に独占しにくい種類のものですから、支援の気概は敬意に値します。

さて、日経BPイベントのサイトでも大々的に告知しているとおり、第一回のカンファレンスを5月25日火曜に開催します。ビジネスストラテジの観点、設計思想の観点、技術実装の観点、はたまたセキュリティを踏まえた契約や価格交渉の観点まで扱われるのは他に例を見ないのではないかと思います。1日でできることには限界がありますが、ここまで突っ込めると参画しがいがあるというものです。

わたしの枠は、「LAMP環境で構築するセキュアWebアプリケーション概論」となっています。サブタイトルがカットされてしまっているので内容が見えにくいと思いますが、オープンソース関連であること、構築技術の話であること、連続モノであることが連想してもらえれば幸いです。今回は第一回として「ユーザIDによるログイン」をセキュリティ的にブラッシュアップする話の予定です。60分なので、いつものマクラはほどほどに、いきなり本題に入ります(w

資料収集などを行なっていて気がついたことは、情報が散乱だけでなく、非常に概念的な話でブレイクダウンしにくいもの、その逆でスクリプトまで書いているのに実に不十分かついいかげんなものなどが見受けられるということです。たとえば、OWASPが最近公開したペネトレーションテストチェックリストは興味深いんですが、実装までブレイクダウンするには遠すぎます。またDevShedのCreating a Secure PHP Login Script という記事は、突っ込みが浅すぎてSecureではありません。日本語で提供されている、わかりやすい資料は存在していないようにさえ見えます。

セキュリティに関しては、どこまでやれば十分なのかというハナシがついてまわりますが、いずれにしてもセキュリティを強化するにしても緩和するにしても、知ってて行なうのとそうでないのとでは全くリスクテイクのアプローチが異なります。いずれ、WEBセキュリティに関する情報を統合したサイトを作りたいと思っていますので、協力してくださる方(個人、スポンサー)はぜひ一報ください。

これまでは、とかく「岡田氏(okdt)の話はあちこちで聞けるからいいや」といわれがちだったのですが、浅く広くならともかく、深く掘り下げるとなるとそうはいかない。そこにきて、連続して情報発信を行なっていける本フォーラムでは、深めの内容で体系的にやっていこうと思っています。そう、体系だった連続モノは（コンサルティング業は別にして）このような連続でのスピーチが可能なところでしかできません。そういう観点では、ロングスパンでは、Internet Weekも今後その色をもっと強めたいと思っています。

p.s.
招待券をゲットしたので、OSBR会員、TechStyle Newsletter購読者に、各々提供したいと思います。この機会にご登録をどうぞ。
また、「行くからokdtの招待ということで割り引いて/宣伝するから招待して！」という方がおられれば、ご一報くだされ。

p.s.2
情報セキュリティEXPO(2004/7)でも新ネタ披露です。やっぱＷＡＳは専用サイトつくんなきゃダメだな。

ドラスティックな改善。

IBM dW:「カーネル比較: 2.4と2.6でのWeb処理」
その昔某社ですれ違ったvery cuteなKeita君のblogより。

WEB処理を例に、Linuxカーネル2.4系と2.6系を比較し、どれほど向上したかについてまとめた簡潔なレポートだ。2.6のポテンシャルを示すために、ハイパースレッディングへの対応などの新しいフィーチャーについて要所要所よくまとめている。Linuxではイマイチといわれていたスレッド周りに関しても、Native POSIX Thread Library (NPTL)の採用による改善状況に言及している。

で、「同じシステムで同じ作業負荷の場合、Apacheサーバーのシステム利用効率は2.6.0-test5カーネルを使った場合の方が、2.4.18カーネルを使った場合よりも高く、６倍のWebページ数を処理しています。」と。６倍の向上だって？！なんとも大胆にさらっと言いましたね、、、。そんな改善は、怖くてそう簡単に口にできないなあ。他のビジネスマターなら、実態調査に掘り返されるような数字じゃないのさ。

そんなドラスティックな改善を気持ちよく受け入れられるのは、きっとオープンソースだけだ。

# とりあえず、セールスデータのレビューをしよう。

Message from "Jerry Weinberg"

ワインバーグ先生ことGerald M. Weinberg氏から日本の愛読者にメッセージをいただきました。

okdt: My most favorite is the Orange Juice Test(オレンジジューステスト), I have tried so many oppotunity to make my business. Due to your special "law", my office is getting very unique to deal with the professional consulting of the open source software security with my high motivated staff.

So I would like to say thank you very much.

Jerry: And I will pass on your thanks to the people who taught me the Orange Juice Test. I, too, have used it to have a profound effect on my business.

okdt: Last year, I made the free maling list for your book lovers, called "Weinbergers" as the follow: (sorry, in Japanese) http://www.freeml.com/...

Jerry: I am honored. I looked at the site, and it is very well laid out.
Unfortunately, Japanese is not one of the languages I can read.

okdt: Would you kindly give me a message for the mailing list members and your book readers in Japan?

Jerry: I would be happy to.
- - - - - - - - - - - - - - - - - - - - - - - - - - -
I am honored and humbled to know of my many readers in Japan. I owe a great debt of gratitude to Professor Izumi Kimura and my other translators. I'm sure the books are much better in Japanese than in English.

If I were to give advice to a young professional starting out in the world, I could do no better than quote three Japanese proverbs:

We learn little from victory, much from defeat.

So, do not think in terms of Win or Lose, because you cannot always win.
Think instead of Learn, for Win or Lose, you can always learn.

Even a thief takes ten years to learn his trade.

There is no quick road to success. Be prepared to persist through some hard times, and you will outlast your competitors who burn themselves out with too quick a start.

If you believe everything you read, better not read.

Take my books, and the books of others, as if they were tempting meals.
Taste everything, but swallow only what tastes right to you.

Once again, thank you for reading my books. Teachers open the door. You enter by yourself.

Very best regards,

Jerry

One who has attained mastery of an art reveals it in their every action. -- Samurai Maxim
- - - - - - - - - - - - - - - - - - - - - - - - - - -

コメントなどは皆さんのblogでどうぞ。

「どこでもGoogleボタン」案。

本業以外のコラムを書く手段としてblogを使ってきて、書くに書けないことが続くことがこうもつらいものかと感じる今日この頃でしたが、ようやく春の予感を風が運んできてくれているようです。とはいえ、このサイトは不思議と着々とアクセスを伸ばしており、何も更新しない月にアクセスが落ちない怪現象にやや複雑な気分を感じています。

ちょっとアクセスを調べてみると、googlebotがものすごい勢いで飛来してきています。春の予感で飛来するものといえば「花粉」ですが、まあそれに近いものがありますね。サイトは、いろいろなキーワード検索で続々とアクセスされている模様なので、キーワードに見合う内容を書いていかねばと。そういえば、ここ数日の仕事で使っているAd words（検索結果に対する広告）のアクセスも突発的に急増しており、もしかしてgooglebotのマッチポンプではないかと疑っているんですが、皆さんのところではどうですか？

とまあこのようにGoogleに振り回されているところ、Wiredの記事で面白い特集を見つけました。The Complete Guide to Googlemania!と題されており、GoogleにまつわるR&Dビジネス、期待、競合などについて結構なボリュームを割いて扱われており、読み応えがありました。なかでも、12ページの記事、"How Would You Redo the Google Interface?"に注目。ここでは、4人のデザイナがGoogleのRedo案を挙げています。

特に、最後の案は最高。WWWの世界からとびでて、あちこちにGoogleボタンがあればいいのに！というアイデアです。バーカウンターで語らう男女の横に "I Feel Lucky" なんて、結構おもしろいかも。ポイントは、正解を出してくれそうなボタンではないところです。ご存知のとおり、GoogleのFEEL LUCKYはだいたいあたっていることは期待できますが、時に大変なサプライズがあります。現に、このサイトは奇妙なキーワードで検索結果のトップですから。

適度にはずさず、それでいてサプライズもある。くつろぐときには特に必要かもです。そういうintelligence & companionのあるトピックサプライヤーになりたいものだなー、なんて。

Perl俳句コンテスト−Haiku Contest

英語で俳句(Haiku)というのは、初耳ではなかったが、あまりゆっくり見たことがなかった。英語でHaikuを書く方法をガイドしているサイトを調べてみると、about.comのHow To Write a Haiku Poemや、PIZZAZ!... HAIKU POEMSなどのページを見つけることができる。それらの説明によると、Haikuは、自然に観察できるなにかの話題について、5、7、5音節の3文構成でなくてはならず、インスピレーションというよりも考え抜くことが必要だという。なんか、本格的だなあ。

後者のサイトにはHaiku contest in Brasilなどのリンクがあったので、どれどれと、検索してみると、ドイツ語やその他の言語でもhaikuコンテストが開催されているようだ。中には5,7,5のリズムに縛られないものもあるが、この短くリズミカルなshort poemに魅力を感じる人々が日本語に限らず、世界に広がっているのが良くわかった。これまで開催されてきたHaikuコンテスト、なかでも技術系の入賞作品の中には、ため息が出そうなほど秀逸なものもあるようなので、ぜひ探してみられると良いだろう。（Google:haiku contest）

2004年1月21日発、カナダのActiveState社のアナウンスによると、同社はPerl言語で書かれた「Haiku」のコンテストを開催するという。このPerl Haiku Contestの御題は、「Why I love Perl」となっている。部門は２つあり、ひとつは英語のHaikuなのだが、もうひとつはプログラミング言語Perlのプログラムで書くという部門があるから驚きだ。5,7,5の音節にどうやって当てはめるんだろう？！しかも実行させることができるなんて。

自然言語とプログラミング言語の違いは大きい。自然言語同様、ひとたび努力してプログラミング言語をきっちり習得すると、他の言語を習得するのは意外とたやすいものなのだが、自然言語とプログラミング言語の距離は縮まりにくい。しかし、いろんな意味で、その距離を狭めることを志している人もいる。今回のコンテストに、プログラミング言語が人の意思を書き綴るのにどれほど進歩したのかを垣間見ることができるのでは、と、大変楽しみにしている。

Enter the contest now at: 応募してみますか？

(2/15)入賞結果発表が出ました！：Winner!

THE LAST SAMURAI−ラスト・サムライ

先日、ファインディング・ニモを観たというショートダイアリをここに書いたが、おそらくこのページの読者である某嬢のサイトでは、ほとんど似たパターンで、こう書いてあった。

> さて、今日は、ファイディング・ニモを見た。
> 大いに期待を裏切られた。。

それはそれですごく興味深いと思ったので今度またゆっくり話を聞こう！ とはいえ、同じパターンだと読者が面白くないだろうと思うので、今回は「どこをどう感じたか」を少々書くとしよう。

昨日、有楽町マリオン９F、ピカデリー１の最終枠で観た。公開前から観たいと目をつけていたので、仕事のきりのいいところで「えいっ」という感じで出かけた。レディスデーだったせいだろう、とんでもない人数の行列だった。その割には難なく座れたのでさして問題なかったが。

予告編を観る段階で思い出されるのが、ピカデリーの木曜ペア割。木曜なら3000円で二人分チケット＋各々にポップコーン＋ドリンクがコミ。ポップコーンなどはつい買っちゃうから、結局水曜のレディスデーより安くあがる。さらにカップルじゃなくてもいい。そうかといって野郎同士では映画は観ないだろうけど…。

さて、本題の「ラスト侍」については、涙が出ないほど深く感じいった。キャスト、演技共にバランスがとれている。最初、竹やぶからざざーっとやってくるシーンは背筋がぞくっとするほどかっこいい。こういう映像テクは特撮モノに毒された目のリフレッシュになる。

外国のサムライ映画にありがちなクサさがなかったし、さしてしつこくもなかった。存在を不必要に感じさせないサウンドトラックもなかなかのモノだ。映画としては大変よくできたストーリーだった。このストーリー、原作はあるのかな？時代考証的にはおかしな部分があるので、原作はないのかもね。

侍、しぶいぜ。

p.s.
視聴には、全国どこからでもネットで借りられる、DVDレンタル「ぽすれん」が便利。

(add your comments!!)

箱根駅伝最新オフィシャルサイトへの導線

Okdt BLOG過去記事「箱根駅伝のパワー」 (January 03, 2002 )に書いたとおり、正月恒例、箱根駅伝には注目している。WEBサイトを探した。あれ、Googleでは、第79回、第78回のものが検索結果として表示され、今回、つまり第80回のサイトは出てこない。しばらく気がつかなかったが、表示されたURLの79と書かれているところを80に直すと今年のサイトがでてきた。まだアドレスバーに手を入れなければならないのか。

2004年箱根駅伝第80回オフィシャルサイト
http://www.ntv.co.jp/hakone80/index.html

これで、80ってあるね。2005年はきっとこう。

2005年箱根駅伝第81回オフィシャルサイト
http://www.ntv.co.jp/hakone81/index.html

これで将来はどうなるかわかるね。

でもまてよ、親父ならどうするだろう。Googleなんて知らないよな。

そこで、Yahoo!で検索してみた。お〜。さすがにYahoo!の検索結果ではでかでかと太字で掲載されており、今年のもの、過去のものへときちんと誘導されていた。とぉっても親切。

http://dailynews.yahoo.co.jp/fc/sports/hakone_ekiden/
※ 追記(2007/1/3) リンク先を変更しました。

ネットユーザの属性と検索エンジンには相関関係がある。たとえば、Googleを利用する人間はネットでモノの値段を調べるが、結局最初に見たサイトではほとんど買わない、ともいわれる。それで、Yahoo!からは率直かつ明快な回答、answer, solutionに誘導し、Googleからは詳細、difference, detailに誘導するのが効果的だ。

Googleで今年のがちゃんと出ないのにはちょっと首をかしげたが、よく考えてみると、箱根駅伝についてGoogleで調べるユーザ層には箱根駅伝オフィシャルサイトではなく、ファンサイト、出場校サイトなど、言及のあるサイトを示せれば目的は達成されるというわけか。そもそもオフィシャルサイトなんて見ない、ということだろうか(笑 NTVさん、このSEOアプローチ、わざとだったらアリ。わざとでなかったらマヌケ。

明日の昼には大手町に出かけてリアル箱根駅伝を見よう。検索エンジンなんてどうでもいい、フィジカルな世界を楽しまなくっちゃね。ちょっとまてよ、読売新聞社前ゴールってどこだっけ。そっか、オフィシャルサイトみればいいんだ。('-' )