Seeds of Seeds: 2009/03

2009年3月31日火曜日

Googleが中国で無料の音楽配信を始める

ニュースで、Googleが中国で無料の音楽配信を始めると聞いた。
何でも音楽を検索し、それを無料でダウンロードできるサービスらしい。しかもワーナーなどの有料数十万曲を合法的に無料で配信するという。
おそらく中国国内では法的にも問題ないのだろう。しかし、中国のネットに接続できれば誰でもこのサービスを受けられることになる。
中国のVPNに接続してもよいし、実際に渡航してもよい。ホテルからアクセスすれば区別はできないだろう。
とすれば、これは事実上の無償提供を意味しないだろうか。
日本では著作権団体が頑なに権利を主張しているが、中国はもとより米国を始め著作権価値の見直しが時代に合わせて始まっているように思える。日本が著作者とともに時代から取り残されるかもしれない。著作者はそれでも国内のみから利益が得られるのでよいだろうが、メーカーは輸出できなければ生き残れないだろう。さらにいえば、メーカーは完全に国外に出てしまえば、いくらでも生き残れるが、。売れるものを作れない工場を継続でないために、労働力を吸収してはくれないだろうと言うことだ。著作者の権利を過剰に保護するとワークシェアの効果も無に帰す可能性もある。

GRIDY

GRIDYという無料のグループウェアがある。
SaaS方式と言うだけなら、珍しくもないが、OSSでもないのに完全無料となると珍しい。
無料の理由は同社がプロモーショナル・グリッドと呼ぶ仕組みにあるようだ。これは、遊休資源を集めて、それを必要とする組織に提供する仕組みのようだ。
いよいよグリッドがお金になる時代になってきたと言うことらしい。この傾向は大変望ましいと考えている。NTT西日本でも資源提供者に換金するグリッドを提供しているらしいが、NTT東日本では行っていない。これを歯がゆく感じていた。
しかし、資源を必要とする組織（おそらく研究所や大学）がそれほど大きな資金をもっているとは思えないので、これだけでは不十分だろう。前のクラウドによるグリッドで提案したように無料のクラウドを活用することも考慮する必要がある。また、クラウドの方でもデータセンターを拡充する前にグリッドで対処することを検討するべきだろう。クラウドを運営する企業はいずれも潤沢な資金をもっているので、その一部がグリッドに回るだけでも大きな経済効果がある。
GRIDYの動向に注目したい。それにより将来のクラウドとグリッドが連携する未来が見えてくるかもしれない。

2009年3月30日月曜日

Lモード

Lモードというものを知っているだろうか？
2010年の３月末をもって、Lモードのサービス終了が決まったそうだ。
個人的には、Lモードには結構期待していた。それは見る目がなかったと言うことかもしれない。
Lモード登場時の時代背景は携帯の爆発的な普及に対して固定回線の下降が現象としてはっきりしてきたことにある。当時携帯で出たばかりのiモードの成功にならって、固定電話でLモードが考案された。
基本的な考えは悪くないと今でも思う。普及していれば、PCを使わず、バリアフリーの情報端末となったはずだ。この種の成功例はフランスのminitelだ。しかし、それすら今日の失敗を予見していたとも言える。なぜなら、minitel自体がインターネットの普及に逆らえなかったからだ。ただし、minitelがあまりに便利だった性でフランスのインターネット普及が遅れたという説もあるくらいだ。しかし、どんなに便利だったかよくわからないが、結局はインターネットに負けた。
Lモードはインターネットと携帯の両方に挑んで、完敗したと言える。
まず、PCでインターネットを使う人はLモードを使わない。PCの立ち上げよりLモードの方が早いということは全くないわけではないが、使い勝手に格段の差がある。また、携帯にはiモードがあるので、やはり使わない。つまり、利用者は携帯を持たず、PCを使えない人に限られる。該当者は年配の専業主婦くらいだ。そのような人にとってはLモードすら難しい。というより、Lモードを知ることも、その必要性すら感じなかったろう。
また、Lモードがiモードと同じサービスを提供していたら、少しは違ったかもしれない。しかし、全く異なる会社が運営したため、全く異なるサービスだった。Lモードにはほとんどコンテンツがない。iモード立ち上げ時の教訓が生かされていない。
また、Lモードをサポートした電話機が便利であれば、もう少しましだったかもしれない。例えば、ワイヤレスの子機にVGA画面がついていれば、家庭内PC端末になっていたかもしれない。しかし、親機にしか画面はついていなかった。使い勝手も悪かったと言うことだ。
このように数え上げると成功すべき要因がほとんど見あたらない。楽観的な予測と何とかしなければならないという義務感から始めたサービスと言うことだろう。きっともう少し早くやめたかったというのが担当者の本音だろう。

クラウドを用いたグリッド

グリッドの本質は余剰資源の活用にある。
自前でグリッドのシステムを持つと言うことはあるが、常時活用するシステムとして運用することはまずない。夜間グリッドなど活用していない資源として再活用する。
それでは、もっとも活用されていない資源とは何かというと、もっとも多くの資源を持つデータセンターだ。なぜなら、そのようなデータセンターは資源のすべてを使うようでは、動的変動に対処できない。よって、常に十分な余裕を確保する。それは、とりもなおさず活用されていないと言うことだ。
そこで、必要なときすぐに解放することを条件に余剰資源を活用してもよいだろう。すると、クラウドでグリッドを行うという方式が考えられる。

2009年3月26日木曜日

春分の日

Googleカレンダーを使っているが、これは国際化対応のため、その国の祝日を公開カレンダーで対応している。日本の祝日をカレンダーに表示するには「日本の祝日」という公開カレンダーを「追加」する必要がある。
ところが、この「日本の祝日」には3/20の春分の日が入っていなかった。同じ年の秋分の日が入っているので、単なるバグなのかもしれない。
バグと言うことは、おそらく人手で作業しているということだろう。Googleでもあまり重要でない仕事は人海戦術で遂行されているのだろう。しかし、それでバグを放置したままでは困る。特に、Googleカレンダーは多くの人が利用し、しかも祝日はその国にいる全員に影響を与える。無料のサービスでも、不正確では無視できない影響が及ぶ。最近のクラウド・メールのトラブルを挽回するように、その他のサービスでも信頼性を向上させる必要があるだろう。

2009年3月25日水曜日

透明フォルダ

OSの機能の１つにGUIによるファイル操作がある。このようなGUIベースの機能はカーネルレベルのOSの機能ではないが、今日では否定できないほど日常的になっている。
そのようなファイル操作で不便に感じることがある。それは、ファイルの分類がフォルダだけでは不十分なことだ。
ファイルが多くなりすぎた結果、フォルダだけではうまくファイルを管理できない。タグを付けて検索するのも１つの解だろう。
ここでは、別の解を考える。それは透明フォルダだ。
フォルダに細かく分類すれば、うまく整理できる。しかし、フォルダが多くなりすぎると一覧性が悪くなる。そこで、透明なフォルダを作成し、１つ上の階層からでも閲覧できるようにしたらどうだろう。HTMLのfieldsetのようなものだ。もちろん分類を示すフォルダ名も表示および編集可能とする。
透明属性がある限り、次々入れ子のフォルダも再帰的に表示される。移動は透明なまま、つまりファイルが一覧されたままでなされる。閉じないウインドウといってもよいかもしれない。
このようなものでGUIの操作が混乱なく一貫性を維持できるか検証する必要があるが、あればそれなりに便利だと思う。「それなり」の程度が問題なのだが。

ストレージの２極化

ストレージの進歩を考える。
HDDには普及品のSATAと高性能なSAS(Serial Attached SCSI)がある。SASはサーバなどで使われる。より正確な表現をするならば、インターフェースのみによって価格や性能が異なるわけではない。SAS HDDは回転数も普及品の1.5〜2倍くらい高く、それだけデータの読み書きも速くできる。よって、価格で比較すれば低速大容量のSATAに対して高速小容量のSASという対比になる。
システムを構成するときキャッシュというのは大変有効な方式だ。ストレージでもキャッシュは有効である。キャッシュを仮定すると、HDDではSATAしか残らないかもしれない。なぜならSASは低価格化するSDDにかなわないからだ。
よって、将来は低速大容量のSATAと高速小容量のSDDの組み合わせが一般的になるだろう。さらに遠い将来にはすべてがSDDになり、HDDはテープの役割を果たすようになるだろう。ただし、HDDにテープほどの信頼性があるかどうかは疑問だ。

関数型ファイルシステム

大規模ストレージに巨大ファイルを格納するようになると、簡単にクライアント・サーバ間でファイル転送するわけにはいかなくなる。その結果、クラウドのようにサーバ側で処理することが多くなってくる。このとき、クラウドならなおのことサーバ側で割り当てられる資源は予測できない。つまり、多くの資源を割り当てられ速く計算されるか、少ない資源を割り当てられ遅く計算されるか、あらかじめ知ることはできない。そこで、たとえ少ししか資源が割り当てられない場合でも、処理の遅延を隠蔽することが重要になる。つまり、本当に計算することなく、掲載したつもりで応答してしまう。
このような場合に有効な考えが関数型ファイルシステムだろう。関数型ファイルシステムとは、この記事で使用する造語なので、世間一般的に通用しないかもしれない。しかし、関数型プログラミングとファイルシステムを合わせたものと考えると、容易に理解できるだろう。
関数型プログラミングでは、一般的に副作用がない。その結果、遅延評価（本当に必要とされるまで実際の計算を遅らせること）が可能となる。これをファイルシステムに応用すると、例えば、ファイルoriginalFileをコピーするとき、コピー先はcopied(originalFile)という値にしておく。これはまだ本当にコピーされたわけではなく、アプリケーションがそのファイルを使用するとき、元のファイルoriginalFileから読み込むことを意味する。
このままでもある程度有効なのだが、パイプライン処理を工夫することでさらに効率よくできる。具体的にはパイプラインに対してシークできるとよい。処理によっては変換前後でサイズが変わらないこともある。このような処理はまれだが、より一般的にはあるブロックが別の長さのブロックに変わることがある。ポイントは異なるブロックで情報が独立していることだ。このような場合、ある程度途中のブロックをスキップできる。圧縮のように前後のブロックに依存関係がある場合、このような処理に属さない。

コンビニに紙おむつを

子供を連れて外出するとき、紙おむつを忘れると困ったことになる。
そのようなときこそコンビニに役立って欲しい。
通常、紙おむつをパッケージで買うと20枚以上入って1000円以上する。1枚に換算すると50円を割る。しかし、あえて1枚100円で梱包し、ばら売りする。こうすれば利益率は高まる。場所も少なくて済む。要は急場をしのげればよい。
困ったらコンビニに行けばよいとなれば子供連れの客を集めることができる。コンビニにとっても悪いことではないだろう。
もっとも、このくらいのことはとっくになされているのかもしれない。

インフラに依存する進化

日本の携帯はガラパゴス的だといわれている。それでもよいという意見もあるし、それではだめだという意見もある。単に感覚的によい悪いを議論しても水掛け論となる。なぜ、だめなのかを示す必要がある。
ここでは、iPhoneと比較して日本の携帯進化の危うさを議論してみる。
日本の携帯には独自の機能が多く取り入れられ、それゆえガラパゴスだといわれる。例えば、ワンセグ、電子マネーなどだ。いずれも国が違えば、そのままでは受け入れられない機能だ。つまり、これらは地域に依存する。より正確に表現すればインフラに依存する。
日本はインフラが整備された恵まれた国だ。そのため、過度にインフラに依存したサービスが取り入れられている。これらは輸出には意味をなさない。もっともワンセグも電子マネーも類似のサービスがある国では簡単なカスタマイズで対応できる。しかし、それとて多くなく、ただでもない。
もうひとつ3Gデータ通信機能も危うい。日本以外では、これほど安く、高速な定額データ通信は普及していない。データ通信を前提としたサービスは、まだ世界的な潮流から見れば時代が早すぎる。
そこで、同じ定額データ通信を前提としたiPhoneと比較してみる。iPhoneは国内のどの携帯よりデータ通信を積極的に利用している。これはiPhoneの魅力でもあり、欠点でもある。PC並みの多機能さがiPhoneの売りであり、そのためにはデータ通信が欠かせない。しかし、通信料の高さ故、単純に通話だけできればよいユーザには決して受け入れられない。ある意味では孤高の差別商品である。しかし、このような商品を欲する人々は先進国だけでなく世界中に幅広くいる。そのような消費者を開拓することで先進国市場だけでは不可能な利益を上げることができる。また、PC(つまりMac)と連携することでPCの需要も喚起しようとしている。一方、日本の携帯はPCとも全く連携していないし、データ通信も閉鎖的だ。日本のモバイルデータ通信の元祖はi-modeだ。i-modeはPCサイトでも代用可能だが、完全には双方に対応できない。そのため、モバイル用とPC用は完全に区別して開発される。i-mode自体は、それ以前に比べるとかなりインターネットに近いものになっているが、それでも差は残っている。今では、その差が新たな問題となってきている。iPhoneの方がはるかに差が小さい。つまり、ガラパゴス的進化のために逆転されてしまった訳だ。このように常に世界標準を採用することこそ勝利への近道である。
iPhoneにはワンセグも電子マネーもない。ワンセグはSBMが外付けオプション品を提供しているが、本体にはない。しかし、その他の機能はほとんどある。例えば、デジカメもGPSもある。付属しているものは、いずれも世界標準である。よって、世界のどこでも勝負できる。
もしiPhoneに電子マネーが導入されるとすれば、Apple Storeが銀行的な業務を可能としたときだろう。Apple Store単独で行う必要はない。Amazonと連携してもよい。
これらもインフラではあるが、１社で対応できる範疇にある。数社が連合したり、国レベルで整備しなければならないインフラでは世界標準がなければ身動きできない。
日本の携帯は世界標準でもない技術に過剰対応している。パワーバランスのわずかな変化で、技術の蓄積が無に帰す。そのようなリスクの中で競争を続けている。このような競争の中ではリスク管理も充分に行うことはできない。リスク管理を行う余裕があれば競争のために資金が使われてしまうだろう。よってハイリスク・ハイリターンの危うい橋を渡っていることになる。

WBC

WBCは２回連続優勝となった。
詳細な経緯は不明だが、WBCは低迷するプロ野球視聴率を受けて、サッカーのワールドカップを見習い設立された大会であると理解している。日韓戦を見る限りは、サッカーと同レベルのナショナリズムが発揮されているようだ。そのうちフーリガンも出てくるだろう。
日本の若手選手にとっては、MLBのスカウトの目に留まるチャンスでもある。次はダルビッシュのメジャー入りが時間の問題となるのだろう。これは必ずしも悪いことではない。インセンティブは重要だ。しかし、世界のベースボールは活性化しても、日本の野球の衰えは防げないかもしれない。プロ野球は完全にマイナーリーグ化するだろう。しかし、マイナーリーグにはそれなりの楽しみ方がある。要は楽しければよいのだ。

新幹線における北海道と九州の違い

新幹線は九州の博多まで達しているが、北海道には達していない。博多に対応するなら札幌だろう。新幹線が札幌まで達すれば、北海道も九州と同じような条件になる。しかし、これは無理かつ無駄だろう。
新幹線で東京から博多まで行く人はほとんどいない。飛行機が怖いか、飛行機のチケットがとれなかったかなど特別な理由がない限り、羽田から飛行機で行く。待ち時間も徐々に短くなり、出発30分前までに到着すれば余裕で間に合う。もっとも車中で仕事をしたい人は、無線LAN目当てに新幹線を選ぶかもしれないが、それだけを理由に選ぶ人はごくまれだろう。いずれにせよ決定的に移動時間が違う。
新幹線で九州に行く人はおそらくほとんど関西圏の人だろう。関西圏から九州までは飛行機を使うまでもない。関西圏は首都圏に続く商圏であり、大きな人口を抱えている。
一方で、北海道は、例え東京から札幌まで新幹線が直通したとしても利用者はほとんどいないに決まっている。なぜなら飛行機で行った方が速くて安いからだ。東京からの客が当てにできなくても九州の場合は関西からの客が当てにできた。しかし、北海道にはどのような代替もない。本来なら東北地方の仙台、盛岡間に関西に匹敵する巨大商圏があればよいのだが、現状も将来もまずありえない。したがって、北海道まで新幹線を延ばす意味は全くない。
新幹線をその名の通り幹線として、副幹線を山形、秋田に延ばしたように青森に延ばせば、一応東北の交通網は整備される。これとて北海道の鉄道整備に比べれば遥かに恵まれている。
九州はアジアと近いという地政学的な利点があるが、北海道にはそれがない。ロシアも首都から離れすぎている。

2009年3月23日月曜日

IE8

IE8を仮想マシンにインストールしてみた。
いつもFirefoxを使っているので速くなったという気はしないが、IE7よりは速いのかもしれない。
しかし、表示の速さとは別に、操作がもたつく感じがした。
考えてみれば当然のことかもしれないが、速さを追求するにはバッチ型がよい。つまり対話性を犠牲にして複数の処理をまとめて処理する。その結果、機械的な応答速度は改善される。例えば、ページを要求してから、そのページが完全に表示できるまでの時間は確実に短くなる。Microsoftが提案するIE8のベンチマークも、そのような趣旨に基づいている。
しかし、人間はページのダウンロード中にも作業をしている。その作業が思う通りに進まないとストレスを感じる。例えば、ダウンロード中は、メニューなども残ったまま表示が凍結される。思わずフリーズしたのかと思う。
このような問題点は、IE8だけでなくコンパイル型JavaScriptを採用するすべてのブラウザで顕著になるだろう。これがユーザのためになるかは疑問だ。コンパイルが悪いのではなく、もう一工夫必要だ。
例えば、かつて巨大なイメージをダウンロードするのに時間がかかった頃、インターレースGIF/JPENなどが活用された。現在では、イメージをインターレース化する必要はなくなったが、ページをインターレース化する必要は残っているようだ。抜本的な改良には、タグに優先度属性を付け、優先度順に読み込むようにする。あるいは優先度を自動的に解析するアルゴリズムを考える。これらにより広告などの本質的でない情報を後回しにして、重要な情報だけでも即座に閲覧できるようになれば、ユーザビリティは向上する。IE9では、このような方向を模索するべきだろう。
ただし、これには業界の反対もあるかもしれない。なぜならインターネット業界は広告収入にたよっているからだ。Microsoft, GoogleのIE, Chromeは広告を表示できなければ会社の方針に反する。広告という不要なものを表示する制約下では、その制約にない自由なブラウザに決して勝てない。すなわちブラウザの改良はビジネスモデルの改良にもつながる。

着陸に失敗した貨物機の報道と消火

本日、７時前広州発成田行Fedexの貨物便が強風のため着陸に失敗、炎上した。その様子が朝のTVで繰り返し報道された。
この事故で２つほど気になることがある。事故自体ではないが、事故の報道の仕方と消火方法だ。
報道については、いつも通り横並びでくどいほど繰り返された。ある意味では必要なのだろうが、もう少し有益の情報が欲しい。例えば、この事故の影響で遅延する便があるのか、ないのかなどだ。これから成田に行こうとしている乗客にとってはとても関心が高い情報だろう。
また、消火方法にも疑問を持った。素人なので無意味な心配をしているのかもしれない。具体的には、消火活動と風向きの関係だ。風向きに対して直角に放水しているようだった。しかし、そのためにほとんどの消化剤が風に流され、火災部分にあたらずにいた。わざと当てないものなのかもしれない。そうでないなら、風向きを全く考慮せずに消火活動をしているとしか思えない。素人考えでは、風上から放水すれば少ない力と量で効率的な消火ができたように思える。

Yahooは7-11となるか

コンビニ7-11は米発祥のビジネスモデルだったが、それを成功させたのは日本のイトーヨーカドーだった。ビジネスモデルをきめ細かく微調整する技は日本のお家芸かもしれない。
米Yahooは瀕死の状態にある。逆に日本のYahooは大成功をおさめている。とはいってもYahoo単独での勝利ではない。PCだけでなく携帯も含めてようやく得た勝利であり、しかもまだ確定していない。
PCではMicrosoft, Googleが熾烈な競争をする中で、Yahoo自体はその競争から一歩遅れている。しかもMicrosoftもGoogleも携帯市場を確実に狙っている。Yahooの市場は徐々に消えつつある。
日本のYahooが検討しているのは、検索以外のサービスを充実させたことだ。特に娯楽の段階まで達していることが大きな利点だ。このようなサービスはインフラが整備されないと難しい。インフラ整備はMicrosoft, Googleにとっても価値がある。インフラが整備され次第、攻勢を強めてくるだろう。特にGoogleにはYouTubeがある。
日本でYahooが生き残っているのは、PC時代にISPとして、携帯時代にキャリアとして、それぞれ顧客を囲い込み、その顧客に対してYahooを全面にサービスを展開したためだ。同じ戦略を世界中にはとれないだろう。
現Yahooの勝利はlocalizationの勝利ともいえる。これはinternationalizationの対極にある。

フラット化した時代故の金融恐慌

フラット化はグローバリゼーションであり、均一化を意味する。多少の役割分担はあるにしても、スキームをまねできればコスト競争に陥る。
今回の金融恐慌も世界中に波及した一因はフラット化にある。例えるなら天然の防波堤を均一化してしまったためだ。多様性こそ天然の防波堤だ。しかし、それがフラット化により一様となり防波堤の役割を果たさなくなった。
しかし、かといってフラット化を否定することも難しい。フラット化を否定し、多様性を重視しようと口で言うのは容易だが、世の中がフラット化したのには理由がある。その理由を無視することはできない。その理由とは経済効率だ。フラット化した方が経済的に効率が良い。つまり、フラット化した方が経済競争に勝つ。
したがって、多様化を強制すると、強制された方は競争に不利な条件を押し付けられることになる。フラット化は利益につながるが、多様化は利益の保護にしかならない。
企業は利益を保護するために保険を支払っている。しかし、保険会社が補償できる額には限界がある。今回の恐慌も限度を超えたために発生した。
両者はトレードオフの関係にある。積極的な戦略ではフラット化を重視し、消極的な戦略では多様化を重視する。近視眼的な評価では前者の方が圧倒的に有利だ。後者が評価を受けるのは非周期的に発生するバブル崩壊のときでしかない。投資側にそれでよしとする甲斐性が求められる。

iPhone用電子辞書

iPhone OS 3.0でコピーができるようになる。それを知る前に考えたことなので、論旨が矛盾するかもしれない。それでも役立ちそうなので、一応提案してみる。
iPhoneではGoogle翻訳を使えるが、通信料が発生する。通常は固定費だが、海外では従量でしかも高い。翻訳は海外でこそ必要なので、Google翻訳は使えない。
そこで、iPhoneに辞書ソフトが欲しい。すでにあるかもしれないが、電子辞書並みのコストパフォーマンスが欲しい。
電子辞書は１台で十役以上果たす。紙の辞書を既に凌駕してしまっている。これ以上便利になると試験で使えなくなりそうだ。あまり便利なのも困り者なのだが、一般的には便利な程よい。
iPhoneでも同じようなことがしたい。そうすれば辞書メーカー（出版社）は一定のプラトッフォームでコンテンツの充実に注力すればよい。
iPhoneで電子辞書を作る場合、フルキーの電子辞書より入力が難しいことを考慮して、UIを作成する必要がある。独自の仮想キーボードが必要だろう。

iPhone用ストラップ

携帯にストラップは必需品だ。個人的には、なぜかはわからない。しかし、ストラップだけでも大きな市場となっていることは確かなので、必需品と考えている人が多いということだろう。
しかし、iPhoneにはストラップを付けられる場所が全くない。そのため、iPhoneストラップの市場が全く形成していない。
おそらくAppleはストラップが大きな市場であることに気づいていないのだろう。ストラップもまたガラパゴス的進化の産物なのかもしれない。おそらくそう言い切ってよいだろう。しかし、全く無視するのも惜しい。
SBMからAppleへストラップ市場を考慮するように提案したらどうだろう。

デジタルリビングギャラリー

バンダイからデジタルリビングギャラリーという商品が出た。
これはいわゆるデジタルフォトフレームの一種だが、絵画鑑賞に特化している点に特徴がある。
バンダイは子供から大人へと市場を拡大しつつある。同社は以前グランドピアノのおもちゃを出し、かなりヒットしていたようだ。これも同じ路線上にある。
デジタルフォトフレームにはコンテンツがなかった。ユーザ自身が撮影した記念写真が唯一のコンテンツだった。それに有名絵画のコンテンツを組み合わせたところがうまいやりかただ。
バンダイといえば、アニメなどのコンテンツを豊富に持っている。今後は、有名絵画からアニメにシフトすれば、利益率も大きくなる。

2009年3月15日日曜日

Hotmail障害の余波

「Gmail障害の余波」でGoogleサービスの信頼性が相対的に低下する恐れがあると述べたが、今度はHotmailでも障害が起きた。その結果、Googleサービスの相対的な信頼性低下はなくなったとみてよい。
しかし、クラウドそのものに対する信頼性が全体的に低下してきたといえるだろう。クラウドに取り込もうとしている矢先に、疑念が先行するようでは困る。

UBitMenuの日本語版が欲しい

UBitMenuがあるということをMOONGIFTで知った。
これはOffice 2007に2003のメニューを加えるものだ。
今でも2007のリボンから2003のメニューを探せずに困っているので、大変ありがたい。
2003の基本的な機能しか使っていない人は2007に移行するのも簡単だと思うが、中途半端に2003を使いこなし、しかも2007を中途半端にしか理解していない者には有効だ。私のような人は少なくないだろう。
しかし、UBitMenuには致命的な問題点がある。それは日本語メニューがないことだ。中国語やハングルまであるのに日本語がない。オープンソースコミュニティにおける日本の位置は、その程度なのだろうか？
Officeのメニューの翻訳は決して難しくない。単に機能と対応させればよいだけだ。おそらく上記サイトで紹介されたので、遠くない日に誰かが日本語の対応表を製作者に送るだろう。そうすればすぐにでも日本語化されるだろう。
同じ方法でExcelやPowerPointにも2003メニューを提供してほしい。
しばらく様子を見て誰もやらないようなら、やってみてもよいかもしれない。

2009年3月13日金曜日

携帯対決：文字入力はWindows Mobileの勝ち

iPhoneとWindows Mobile携帯のどちらを買うか悩む人は少なくないだろう。
iPhoneを選んだものの、文字入力に関しては後悔している。明らかにWindows Mobileの方が文字入力は格段に便利で、早い。
Windows Mobile携帯にはフルキーボードがついている機種もある。しかし、物理的なキーボードがなくても、仮想的なキーボードでさえiPhoneより速く入力できる。ペンの使用が決定的な差となっている。
ペンを使えば細かいポインティングができる。小さなキーでも間違えずに入力できる。iPhoneでもペンを使えるが標準ではない。収納もできないので不便だ。また、Windows Mobileの仮想キーボードは単純だからか、応答が早い。かな漢字変換に時間がかかってもがまんできるが、ローマ字変換に時間がかかるのはがまんできない。iPhoneのIMは賢すぎるのかもしれない。
これだけでiPhoneのすべてが否定される訳ではない。これは短所の１つにすぎない。もっと多くの短所もあるし、それ以上に多くの長所もある。

成功が約束されているWindows 7

Vistaの不振を払拭するために、Windows 7が時期を早めて投入される。
Vistaの失敗で、いまだにXPが現役を続けている。Windowsにしては軽いので、ネットブックにも適しているのは事実だ。しかし、その機能はもはや見劣りする。
Windows 7は待ちに待った本命だ。しかし、実際には本命というほどの機能があるわけではない。不必要な機能を取捨選択できるが、それによって特に軽くなったり、早くなったりする訳でもなさそうだ。あくまでもVistaよりましというところだろう。
それでもVistaによって低迷したOS需要を7は喚起できるだろう。したがって、過去最大の販売実績は確約されている。しかし、それを成功といってよいものか。あえていうなら消極的な成功だろう。
マーケットは先を読むという。おそらくWindows 7の成功は織り込み済みだろう。しかし、Windows 7の評判が芳しくなければ、過去最高の収益を上げても株価は下がるかもしれない。

プライベートクラウド

プライベートクラウドは組織内で完結するクラウドで、GoogleやAmazonのような本来のクラウドをパブリッククラウドという。
パブリッククラウドの利点は明らかだ。組織外の遊休資源を安く利用することで、提供者と利用者がWin-Win関係を構築できる。
しかし、プライベートクラウドの利点は明らかでない。プライベートクラウドを進めるベンダーは自社製品を売り込みたいだけだ。自社製品にクラウドで必須とさせる仮想化機能を付加し、資源活用の効率化を実現してはいるものの、単にHWが眠っているだけにすぎない。省エネにはなる。しかし、製造時のエネルギーは回収できない。利用料は確かに安くなるかもしれない。しかし、製品価格など契約次第だ。付加価値だといわれれば下がるはずもない。従来製品よりよいことは間違いないが、それだけのことだ。企業内システムにイノベーションをもたらすことはできない。
ただし、プライベートをパブリックへの通過点ととらえるなら無意味ではない。自社システムを一気にパブリッククラウドに移行することは難しい。特にレガシーをかかえた大企業であるほど難しい。そのため最低限のプライベートクラウドに移行した後、パブリックへ移行するという段階的な移行が考えられる。システムの結合を緩める一案としては悪くない。

と、ここまで書いて見直すと、自分の本意が伝わっていないことが明らかだ。この記事を見ると、プライベートクラウドにも意味がない訳ではないと聞こえる。そうなのだが、本当にいいたかったことは、プライベートクラウドにはその程度の意味しかないということだ。
段階的な移行は現実的に思えるかもしれない。しかし、よく考える必要がある。大規模なシステムのリプレースは早くても５年単位だろう。プライベートクラウドで５年待つということは、その５年を無駄にするかもしれないということだ。５年後がパブリッククラウドだとわかっているなら、時間を無駄にすることはない。
段階的移行というより試作と言い換えるべきかもしれない。プライベートクラウドは試作には適している。
もう１つの大きな利点は、サービスレベルをコントロールできることだ。サービスプロバイダーならば自身のサービスレベルを保証することが求められる。しかし、パブリッククラウドでは難しい。
しかし、このようなサービスレベルは事業継続性などの点からも重要と考えられているが、身の丈にあったレベルにするべきだ。おそらくごく一部の企業を除いて現在のサービスレベルは高すぎる。障害などあって当たり前と考えた方がよい。もちろんその対応に人件費をかけたのでは元も子もない。

2009年3月6日金曜日

WindowsでiSCSI

訳あってWindowsでiSCSIを使うことになった。
本格的に使う前のテストのようなものだ。
そこで、WindowsでiSCSIをテストする簡単な方法をまとめておく。この内容は、既に他のブログなどでも紹介されている方法なので、詳細は原文に譲るとして、それらで話題にされていなかった些細なポイントを補足しておく。
まず、iSCSIだが、SCSIをネットワークに拡張したものだ。USBの普及でSCSIは廃れているが、今でも重要な規格なのだ。このiSCSIでは、ドライブ側をターゲット、PC側をイニシエータと呼ぶ。
イニシエータはMicrosoftが提供している。Microsoft iSCSI Software Initiatorという。Microsoftのダウンロードセンターから無料でダウンロードできる。インストールも簡単だ。
ターゲットは、SRCHACK.ORGの記事で紹介していたStarWindを使うことができる。StarWindには無料のバージョンがある。無料版では最大容量が2GBに制限されるが、テスト用なら十分だ。本格的に使うなら有料版を買うしかないが、結構高い。
無料版をダンロードした後、インストールするが、そのままではまだ使えない。ダウンロード時に登録したメールアドレスにライセンス(Free version Key)のリンクが送られてくるので、これをダウンロードする。次に、StarWindを起動して、Help-Registrationを行う。ダウンロードしたファイルを選択すればよい。
次にイメージファイルデバイスを作成する。Device-Add Deviceを選択し、Image File deviceを作成する。容量は2GBに制限される。RAM deviceやVirtual DVD deviceなども作れる。
ターゲットが用意できたら、イニシエータを起動する。「iSCSI Initiatorのプロッパティ」画面で、Tagertsタブを選び、先ほど作成したターゲットを選択してから、Log Onを行う。これでConnectedになればよい。
作成したイメージファイルデバイスはフォーマットしていないので、「コンピュータの管理」-「ディスクの管理」でフォーマットする。常時使用するならドライブ文字を割り当てる。
これでマイコンピュータにiSCSIドライブが表示される。

WindowsにSkyDriveのマウントを

Windows LiveではSkyDriveを便利に使っている。25GBという容量はネットブックのSSDより大きいくらいだ。しかし、ブラウザ経由で利用するのはかなり不便だ。
ブラウザ経由でも利用できるのはよいとして、SjyDriveそのものをネットワークドライブとしてマウントする機能が欲しい。
Gmail driveなど似たようなものは既に存在する。GmailがドライブになるならSkyDriveがならないはずはない。SkyDriveをドライブにするのは、Microsoft自身の役割だろう。最優先の課題の１つだと思う。

2009年3月5日木曜日

AndroidアプリをDesktop Linuxへ

Androidが普及すれば様々なアプリケーションも登場するだろう。また、アプリケーションだけでなく携帯ならではのIMも発達するだろう。
そのような成果をDesktop Linuxにも反映して欲しいものだ。少なくともマルチタッチ対応インターフェースなどは必須になるだろう。
ネットブックの台頭とさらなる小型化が進行すれば、携帯ともPCとも判別できない領域が現れるだろう。そのときPC Linuxを普及するには、それにふさわしい機能とアプリが必要だ。PC LinuxでAndroidアプリを動かすこともできなければならない。

SSDで変わるバス

バスはCPUと周辺デバイスを接続する最重要経路だ。PCにとっての背骨ともいえるだろう。
もっとも重要なデバイスはメモリであり、その仕様DDR3-2133では、最大転送速度は17GB/sになる。メモリは特別扱いされるため、その他のデバイスとはバスを共有しない。
一般的なバスはPCI(あるいはPCIe)だ。PCIe 1.1 x 32なら8GB/sまで可能となる。
いま、SSDの大容量化・高速化が進行している。Z driveは容量1TB、転送速度700MB/sだという。
このくらいでは、まだPCIeの帯域を使い切ることはないが、バスは複数のデバイスで共有されるので実用上の上限にかなり近づいている。さらに、デバイスの性能が向上するとバスがボトルネックになる。特にグラフィックアクセラレータと共有するならなおのことだ。
SSDをそのままメモリに使うことはないだろうが、SSDがPCIeの１つを占めることは間違いない。

Shear

たまには温故知新もよいだろう。新しいアイデアではないが、古いアイデアをまとめておくことも重要だ。そこで、サーベイも記事に加える。

Shear[1]は、RAIDを特徴パラメータ（ディスク数、パターンサイズ、チャンクサイズ、冗長度、レイアウトなど）を自動的に推定するソフトウェアツールである。SW/HW両RAIDに対して有効に働く。Shearでは、RAIDに対して読み書き行い、その応答を統計的に分析することで、RAID構成を推定する。例えば、パターンサイズP（RAIDディスクの使われ方が等しく繰り返される大きさ）を推定するには、pを変化させながらp間隔にデータを読み書きする。pがPと等しいとき同じディスクにアクセスが集中するため応答が極端に遅くなる。よって応答を解析すればパターンサイズを推定できる。

[1] Timothy E. Denehy, John Bent, Florentina I. Popovici, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau: Deconstructing Storage Array, ASPLOS'04, pp.59-pp.71, 2004

2009年3月4日水曜日

研究のシステム化

publish or punish
確かに研究成果を死蔵しても意味がない。研究成果は広く万人の知るところとならなければ、人類全体の知財とならない。
もっと目先のこととして研究成果は特許を経て経済に直結する。となれば、競争力を維持するために秘密にすることもある。
しかし、これはむしろ例外だろう。一般的には知識を得るだけでなく、それを発信することも必要だ。
しかし、研究者は必ずしも最善の伝道者ではない。伝道者には表現力が最も重要な資質だろう。研究能力と表現力を兼ねることは重要と考えられているが、いざ実践しようとすれば難しい。
そのような無理な要求を課すより現実的な解決手段を模索すべきだろう。それが研究の分業であり、システム化だ。
研究もマネジメントできる。それはよく知られていることだ。しかし、マネジメントが中途半端であることも確かだ。
研究の方向性を大局的に判断する人はいるが、トップダウンで指示することもほとんどない。どちらかといえばボトムアップであがってきたテーマに難癖付けるだけだ。それなら最初から指示してやればよい。もちろん、できるならだが。
発表してない研究はないも同然だ。研究が終われば発表の準備に入る。しかし、発表の準備は意外と手間がかかる。研究と発表を分担できるだけで能率は上がる。研究者は発表者にだけきちんと伝えればよい。発表者はインタビュアを兼ねて、一般聴衆の立場から質問を想定する。このような役職にふさわしいのは編集者だ。編集者はゼネラリストでなければならない。ただし、スペシャリストに準じるほどその分野に精通していなければならない。このような人材は少なくないが、あまり活用されていない。
研究を突き詰めるほど分野は狭くなる。こうなると分野外のことがわからないいわゆる専門馬鹿になりかねない。それもまた分業が必要な理由だ。最先端は狭くなって当然だ。専門馬鹿でしか到達できない境地がある。しかし、専門馬鹿だけでは到達できない領域も存在する。スペシャリストとゼネラリストは互いに協力しなければならない。
ゼネラリストはスペシャリストを結びつける。ゼネラリストにしか解けない問題もある。ゼネラリストがスペシャリストを道具のように使う以上、十分なスペシャリストが存在する環境下でなければ能力を発揮できない。
次の課題はスペシャリストの育成だ。多くの技術者は学生時代ゼネラリストで、企業で研修することでスペシャリストになり、やがて管理職で再びゼネラリストになる。入口と出口がゼネラリストだから内部でスペシャリストを育成するしかない。OJTよりプロジェクトがよいだろう。

2009年3月3日火曜日

RPGで歴史を学ぶ

学びにゲームを利用することはよくある。楽しみながら学んだ方が身につくからだ。
ゲームといえばRPGが中心だろう。
RPGといえば無意味な経験値稼ぎなど批判も多いが、純粋にストーリーを楽しめば、大変考えられた作品が多い。もっとも経験値稼ぎのような多少の労苦もストーリーの理解にはかかせないスパイスとも言える。
RPGは、その名の通り、その役になりきって追体験する遊びと言える。よって、歴史の追体験にはもってこいだ。
そこで、いっそのことファンタジーの要素を廃して、史実に忠実な歴史を追体験するゲームを作れば、楽しく学べるのではないだろうか。ゲーム的な要素がないと単なる勉強になると思う人もいるかもしれないが、ゲームでなくても漫画や小説は楽しい。ゲームのような自由度がなくても十分に楽しめるコンテンツはできる。
歴史の主人公になって、その立場から見た世界を追体験し、なぜそのような歴史的決断がなされたかを理解することは十分楽しいことだと思う。

車のセールス

自動車産業は影響力が大きい。その復興は日本経済にとっても重要だ。そこで少しだけ助力したい。
自動車産業を復活させるには車を売るしかない。インサイトのように売れる車を作ることが最も重要だ。
しかし、どのような車が売れるのかわからないことが本質的な問題だ。そのような場合は、誰が車を欲しがるかを考えればよい。
例えば、高齢層と若年層を比較すると、高齢層の方が人口も財産も多い。よって、高齢者向きの車を作った方がよく売れる。また、都会と地方では、地方の方が必要とされる。都会では、公共交通機関が発達しているため、車に乗る必要がない。今の時代では、環境意識の高まりもあり、車に乗る必要のない人は車を買わなくなっている。昔は車で通う必要もない場所へも車で通っていたと言うことだろう。
このように考えると、高齢者と地方の若年層をターゲットにするという一般的な戦略が成り立つだろう。なお、高齢層と若年層の中間層に対しては従来通りでよいように思える。
また、同じ高齢者でも都会と地方ではニーズが異なる。道幅、駐車場など道路環境が異なる。また、ショッピングセンターなど購買法も異なる。地方なら比較的遠くの大規模ショッピングセンターに週1回買い出しに行くというパターンが考えられるが、その場合小さな車では不十分なこともある。
また、既に飽和している市場で新たな市場を開拓するなら、一家に一台から一人に一台、一人に複数台（用途ごとに一台）へと発展させる必要がある。これはかつてPCがたどった道だ。その場合、自動車の小型化、低価格化は避けられない。タタのナノはそのままでは通用しないかもしれないが、やはり時代に即した車を開発することが重要だ。

2009年3月2日月曜日

Gmail障害の余波

最近Gmailがサービスを停止したことは、その利用者ならよく知っていることだろう。
個人的な事情だが、この時期、Gmailが大規模な障害を起こしたことは痛手だった。
というのは、Google AppsやWindows Liveか、いずれかのサービスを全面的に採用しようと検討していた矢先だったので、Googleへの信頼感が大幅に低下してしまったからだ。
個人的には、この程度の障害はどのクラウドでも起きえると考えているので、それによってGoogleの評価を下げることはないのだが、一般的にはマイナスとしてとらえられる。
サービス内容ではGoogle Appsの方がよい点が多いと思っていただけに残念だ。

ブログによる意見表明と議論

ブログを用いて個人が意見を容易に表明できるようになってきた。
政府の政策を批判したり、また賛成したりすることができる。このような意見を集計できれば世論調査が瞬時に済む。このようなブログ民主主義という形態も将来は可能になるのかもしれない。もっともSFに近い話ではある。
話を戻すと、現在のブログはまだ意見表明に留まっているという言い方もできる。意見を収集して集計するシステムはできるかもしれないが、そのような集計された意見は民意かもしれないが、つじつまのあった論理的な結論とは言い難い。もっとも集団知が常に遍在するなら民意は常に論理的結論と一致する。しかし、これもまた夢物語だ。
つまり、表明された意見を互いに戦わせて、競争させ、その中から勝者を選び出す必要がある。議論のコロシアムといえるかもしれない。ブログが連携し合って、そのような議論の場が生成されるとおもしろい。しかし、一歩間違えると荒らしとなるので、議論のために専用の砂場が欲しいところだ。つまり、自動的に意見を集めて、砂場を作ってしまうようなシステムが考えられる。
議論にはブログよりむしろ掲示板が適しているかもしれない。しかし、掲示板では参加者が自分の意見をまとめる前に、他人の意見を読み、他人の考えに左右されてしまう。もちろん意見を定めるには根拠も必要であり、その調査段階で先駆者の意見の影響を受けることはあるだろう。結局、その人次第ではある。

登録: 投稿 (Atom)