重大問題

年末になると、その年の総括として、十（重）大ニュースを発表している。
それにちなんで、自分なりの重大ニュースならぬ重大問題をまとめておく。
なお、番号をつけているが順不同である。
1. 地球温暖化問題
　今年のノーベル平和賞も地球温暖化問題への貢献だった。
2. 資源問題
　石油枯渇だけではなく、様々な資源が不足していく。
3. 政治のねじれ
　与党の衆議院と野党の参議院が対立する構図はいつまで続くのか、その間日本の政治は空白となるのか、世界的には小さな問題でも、国内的には大きな関心ごとだ。
　もっと広く政治問題となれば、リーダー不在が最大の問題かもしれない。
4. サブプライムローン問題
　この地雷はいつ爆発するか分からない。
5. 人口問題
　政局化している年金問題も、元をただせば人口バランスの問題だ。少子化、高齢化、それに伴う教育問題、医療問題、
6. 財政問題
　一説によると国の財政問題は既に解決しつつあるとも言われるが、少なくとも福祉に充てる税金は減るだろう。今後は自治体の財政問題が焦点となりそうだ。
7. 教育問題
　PISA順位は低下しつつある。あらゆる対策が焼け石に水のようだ。競争相手がいるのだから、少し努力する程度では追いつかないのだろう。
8. 北朝鮮問題
　核問題と言い換えてもよい。遠くのイランより近くの北朝鮮が日本にとっては問題だろう。
9. 領土問題
　いつまでも「触らぬ神にたたりなし」では済まない。
10. 憲法問題
　当面、改憲されることはなさそうだが、議論しなくてよいわけではない。
これらの問題は非常に大きな問題であり、いずれはこのブログでも取り上げてみたい。所詮、素人だからと何も考えないのが一番よくない。

びん・かん・ペットボトル

自治体によってはびん・かん・ペットボトルを分別することがある。私の住む自治体でもこれらは分別することになっている。
しかし、同じ市内のコンビニのゴミ箱を見ると、入り口こそ２つあるが、中は共通で分別されていない。一般家庭と業者で分別方法が異なるとも思えないので、業者が独自に分別するのだろうと考えていた。しかし、まじめな店では店員が分別するが、大半は混ざったままゴミ回収業者に引き取られるらしい。
それでは、業者が分別して処分するかといえば、おそらくそんなことはない。業者はコストを優先するので、決してリサイクルしようとは思わない。（少なくとも現在の）リサイクルは石油と経費を余計に消費するだけだ。
しかし、びん・かん・ペットボトルの中には十分に資源として活用できるものもある。例えば、アルミ缶だ。今、資源危機が懸念されている。鉄でさえ不足するほどなので、アルミやその他の比較的高価な材料は貴重な資源だ。希少なものには価値がある。
資源としてほとんど無尽蔵のびんと、高価だが適切なリサイクル方法のないペットボトルはあきらめるしかない。リユーズできるびんは理想的な容器に見えるが、重く壊れやすい。中身の重量と容器の重量の比率が小さい。中身が安いと輸送料を賄えない。そのためアルコールぐらいしか用途がない。ペットボトルは石油を資源とするため一見すると貴重な資源だが、それをリサイクルするにはさらに石油を消費する。そのため燃やしたほうがよい。
しかし、適切な施設さえあれば、かんを分別するのはそれほど難しくないだろう。磁石を使ってアルミと鉄を分別する施設は既に存在する。問題は、そのような施設に十分な処理能力があるかどうかと、その施設へ輸送するコストだ。
エネルギーさえ石油以外のものを使えるなら、全部まとめて燃やしてから、その灰の中から必要が元素を抽出したほうが効率がよいかもしれない。ゴミが21世紀の鉱山となる。

クラウド

IT業界では新しい概念が次々と登場する。これらが最初に英語で登場し、適切な日本語訳がないので、カタカナのまま使われる。その結果、元の英語がわからなくなってしまうことがある。
最近では「クラウド」が要注意の言葉だ。
クラウドには、群集を表すcrowdと雲を表すcloudがある。前者は集合知(wisdom of crowd)やクラウドソーシング(Crowdsourcing)として知られる。後者はクラウドコンピューティング(cloud computing)として知られる。両者は似て異なるものだ。これらを正確に区別して使う必要がある。
群集が重要なのはWeb 2.0からも明らかだ。コンピュータだけでは解決できない高度な知的生産を多数の人の知識を駆使して解決することがWeb 2.0の本質の１つでもある。
Cloud computingはGoogle CEO Eric Schmidtの提唱といわれる概念で、計算を雲で表されるインターネットで行うものだ。自分なりの解釈を交えると、単独のサーバではなく実体のとらえにくいサーバ群により処理が行われると考えられる。Googleの検索が代表例だが、P2Pも含まれるだろう。要は「あちら側」ならどこでもよい。
ところで集合知はwisdom of crowdが正しいが、これをもじってBusiness Weekに「Google and the Wisdom of Clouds」という記事が掲載された。これでよけいに混乱する人が増えたのではないかと思う。
実を言えば私もその一人だ。そのため、この記事でこれらを整理したいと考えた。

ITSで自動車業界が滅ぶ？

ITSで自動運転が可能になるかもしれない。ちなみに、ITSは夢の技術ではない。また、必ずしも自動運転を目指すものでもない。よって、これは仮定の話だ。
ITSで自動運転が可能になれば、車は単なる移動手段になる。
そのとき自動車事故や飲酒運転が減り、ばら色の未来が訪れるかのように見える。
しかし、運転する楽しみがなくなる。
人命のためには多少の嗜好は制限されてもしかるべきだと考える人は少なくないだろう。また、基本的には運転が好きでもいつも運転したいとは限らない人も多い。例えば、移動中に急ぎの仕事をしたい人などだ。
しかし、問題はそれ以上に深刻かもしれない。
なぜなら、運転する楽しみがなくなれば、単に走りさえすれば車になるということを意味する。運転しないなら多少の乗り心地は無視できる。誰がタクシーの乗り心地に文句を言うだろう。
そうなると、決め細やかなチューニングが不要となる。今の車は統合型商品だといわれている。これは単に部品を組み合わせるだけでなく細かなすりあわせを必要とするからだ。しかし、チューニングが不要なら部品を組み合わせるだけで作られるモジュール型商品になってしまう。
モジュール型商品はアメリカを始め、中国などの得意分野だ。少なくとも日本企業は太刀打ちできない。
したがって、自動運転という夢の技術を追求すると日本の大きな産業の一つである自動車産業自体が国外に流出せざるをえないということになる。自動車産業を失った日本にどんな産業が残るのだろうか？それまでにロボット産業が育っているだろうか？あまり楽観できない。

トラックの速度

高速道路を走るトラックが制限速度を厳守していることが多くなったように思う。
これは環境問題のためか、あるいはガソリン価格の高騰のためか、いずれにしても結構なことだ。
また、これらの理由から安くて速いトラック輸送は困難になった。ガソリン価格の急騰は企業努力で値段を据え置くことができる状況ではない。それをしたら倒産するしかない。安ければゆっくり輸送するしかない。
おそらくトラック業界は安くて安全に輸送する大手と高いが高速輸送する零細に別れるのだろう。誰でも高付加価値の後者を選択したがるが、それほど需要があるわけではない。
今までは多少の無理も輸送業界が受け入れていたため、顧客は立場を利用して強く出ることもできたろう。しかし、もはや低価格を受け入れる体力が業界にない。そのため多くの業者が転職することになり、その結果生き残った業者は逆に強い立場に立つ。その業者に依頼するしか方法がないので、輸送量は高くなる。
顧客は業者への依頼を安くするため自分自身のビジネスモデルを見直す。本当に時間を短くする必要があるのか考え、高いコストを払ってもその価値がある少数の企業だけが高付加価値の依頼をする。
その結果、全体としてはゆっくり走っても営業できるトラックが増える。

ガラスの便器

以前、トイレの便器が陶器なのは問題ではないかと、問題提起した。
その代案を述べていなかった。
私案としてガラスを提案する。
私は陶器に詳しくないことを告白し、素人考えであることを明白にしたうえで、主張する。
陶器は粘土を焼いたものだ。焼いた粘土が再使用できるのかどうかがよくわからない。再使用できるなら特に問題ないが、決して容易ではないだろう。
それに対してガラスは化学的に安定しており、容易に再利用することもできる。陶器より便器の素材としては理想的だと思う。
それならば、なぜ今便器にガラスが使われていないのか？それが問題だ。
想像だが、強度ではないだろうか？
しかし、強度に問題があっても、それで壊れても再利用可能なら交換すればよいだけだ。逆に、定期的に交換することでリフレッシュするサービスも考えられる。
ところで、調べてみると、松下電工から有機ガラスの便器を用いた全自動掃除トイレが商品化されている。つまり、とっくにガラスの利点は理解されていたわけだ。
それでは、なぜ他のメーカーはガラス製便器を作らないのか？
１つの答えは陶器メーカー出身のため、ガラス生産の技術を持っていないからだろう。だとすれば、ガラスメーカーにとって大きな市場を獲得するチャンスかもしれない。
しかし、便器はガラスだけではなりたたない。台座までガラスにするとさすがに強度がたりないだろう。２つの素材を組み合わせるほうがよいだろう。
もう１つは従来どおりの陶器かもしれない。あるいは木材でもよいだろう。

モーダルシフトは必要か

日本の運輸は車に大きく依存している。
逆にアメリカのように広い国は鉄道輸送が多い。
車より鉄道の方がCO2排出量は低い。一度建造してしまえば鉄道を使ったほうが省エネになる。
日本の運輸を車から鉄道などに移す必要がある。これをモーダルシフトという。
一般論としてモーダルシフトは必要だろう。
しかし、注意しなければならない点もある。このブログではモーダルシフトの問題点を考えておく。
車の技術は急速に進歩している。産業自体が大きいため潤沢な資金を使って研究・開発ができるからだ。それに比べて鉄道は設備投資の割りに市場が狭いといわざるをえない。日本の鉄道を海外に売ることはできない。新幹線は例外だ。それに対して、車はハイブリッド、燃料電池、EVなどにより低公害化、省エネ化、CO2排出量削減が進行している。
このまま、順調に車の省エネが進行すればモーダルシフトをしなくても同じ効果が得られるかもしれない。例えば、自然エネルギーだけで走行可能な車を実現されれば鉄道を使わないほうがよいことになる。
鉄道には、省エネの利点もあるが、多くの問題点もある。小回りが利かないことが最大の欠点だ。また、新たな路線を開発することも極めて困難だ。その点、船や航空にはない欠点だ。路線開発は金銭だけでなく環境負荷も高い。
これらのことを総合的に考えてモーダルシフトが必要かどうかを論じる必要がある。

カーナビにインターネットラジオを

NTTやauの定額データ通信サービスを使えば、車でインターネットを使うことができる。
そのとき、便利なサービスの１つがインターネットラジオだと思う。
既存のラジオは地方性が強くお気に入りの番組があっても全国どこでも聞くことができるわけではない。しかし、見知らぬ地方局をいちいち選曲するのも面倒だ。運転手が選曲に集中するのは危険だ。
カーナビはりっぱなコンピュータだ。車の中では最大のコンピュータといってもよい。カーナビにインターネットラジオ機能をつけるのは自然な流れだろう。
付け加えるならば、定額データ通信サービスを使えば、渋滞情報をリアルタイムに配信したり、地図データをリアルタイムに更新することもできる。これらはいうまでもなくカーナビで実現されるだろう。だから、ここでは言う必要がありそうなインターネットラジオ機能を付加してほしいと述べておく。
インターネットラジオはライブでなくてもよい。むしろ好きな番組をいつでも聞くことができるということが重要だ。
個人的には子供番組を選曲できるようにして欲しい。長距離ドライブで子供が退屈して困るからだ。特に渋滞に巻き込まれると泣く子もいるだろう。ぜひ欲しい。

逆さに置ける容器

逆さに置けるケチャップが売れているらしい。
同じようにマヨネーズ、蜂蜜も逆さに置けると売れるかもしれない。
逆さに置く容器を作るのは結構難しい。だから、どんな容器でも逆さに固定できる器具を作ればよい。100円ショップで売れるくらいのものができれば便利に使えるのではないだろうか。

PAにコンビニを

関越自動車道 山谷PAにはコンビニがある。24時間開店しているし、必要なものはほとんどすべて揃うので大変便利だ。下手なSAよりコンビニのあるPAの方がよい。
日本中のPAにコンビニができると長距離ドライブも便利になる。
ただし、コンビニにとっては街中ほど集客があるかどうかわからないので、積極的に出店するかどうか定かでない。
成功のポイントは今模索中だろう。無駄な生鮮食品をできるだけ減らす必要があるだろう。一方で、売れ筋の商品ははずせない。
街中とは異なる商品展開やノウハウが必要なはずだ。

学会公認OSS

日本医師会が開発したOSSの診療報酬システムが順調にシェアを獲得している。
これにはいくつかの理由がある。
もちろんOSSだから無料であるという点は非常に大きい。
しかし、独自開発のOSSでは必ずしも、これほど成功はしなかったろう。日本医師会という学会が公認している安心感が大きい。医療の現場では日本医師会の影響は絶大だろうと想像する。
さらに、診療報酬システム自体が特に革新的なものではなく、決められたルールに基づき処理するルーチンワークである点も見逃せない。このようなルーチンワークはOSSの格好の標的となる。そのようなサービスを提供している企業はOSSの脅威にさらされるはずだ。同じような状況がECやグループウェアにも当てはまる。何らかの特色を持たないサービスはOSSによって淘汰される。
ルーチンワークとなった業務はOSSにシフトする。これは正しい進化だ。既存企業はその進化に対応すべくサービスそのものを進化させなければならない。
評価すべきは日本医師会の態度だろう。日本医師会が病院第一の組織である点が幸いした。他の学会では企業が構成員となるのでその企業の営業を圧迫するようなOSSを開発することは難しい。しかし、OSSは確実に病院の経営を助けてくれる。医療会計企業も多いが医師会にとっては関連業界より病院の方が重要である。他の学会に医師会の真似ができるかどうかは疑問だ。
しかし、このブログではかねてから主張しているように日本のサービス業の生産性を上げるためにはルーチンワークを積極的にOSSに移転し、コストを削減するしかない。特に自治体業務をOSSにするべきだ。自治体には学会がないだろうが、政府がいるので開発は可能だ。

情報洪水

普段、なにげに情報洪水という言葉を使うことがある。
（そのような職種は特殊かもしれないが、IT業界では珍しくないだろう。）
しかし、情報洪水という言葉は、奥が深いというべきか、混乱しているというべきか、はっきりしない。
情報洪水には３つの英語がある。
1. Information Pollution
おそらくはオリジナルだろう。しかし日本語に直訳すると情報汚染となる。これを洪水と訳したのはなぜだろう。問題の深刻さを強調する表現だ。
2. Information Overload
上記より新しいが最も一般的な意味だろう。しかし日本語では情報洪水と区別するため情報オーバーロードとカタカナで呼ばれることも多い。
3. Information Flood
日本語そのままの直訳である。それゆえ英語で意味が通じるかわからない。

Zohoはよい

このブログでは、Googleのサービスの２つの問題点を指摘した。
１つはWikiがないこと、もう１つは(HTMLエディタでない)ワープロがないことだ。
しかし、Zohoはそのいずれも実現し、Google同様に無料で利用できる。
しかし、問題がないわけではない。
企業のビジネスモデルの違いで、Zohoのストレージ容量はGoogleより小さい。
例えば、Writerは今でこそ無制限だが、そのうち1GBになるようだ。
サービスに課金するビジネスモデルである以上、無制限のサービスはありえないだろう。
Zohoのシステムはすばらしいが、ビジネスモデルは問題だ。
ただで使えないから問題だというのではなく、サービス課金のモデルではGoogleに対抗できないと思うからだ。

livedoor Blogのプライベートモード

このような機能が欲しかった。Bloggerでも欲しい。
しかし、無料版で登録できるIDの数が20件では少なすぎる。
なぜ、このような機能に注目するかというと、これにより大学等に蓄積されたコンテンツがブログに移転する可能性があると考えているからだ。
少なくとも自分ではそうしたい。
そうしたい理由はブログシステムのメンテナンスをやめたいからだ。
同じ考えの人は少なくないだろう。

ところで、話が変わるが、プライベートモードを持ったBlogはフレパ(SNS)と何が違うのだろう。OpenIDに対応していることだろうか？それならOpenSocialになるとどうなるのか？
今は隆盛を誇るブログだが、変革のときが近づいている。

SEの出世

SEという職業はコンピュータが誕生してから生まれたものだ。
その歴史はまだまだ浅い。
今、団塊世代の退職が始まった。しかし、団塊世代で本当の意味でSEといえる人はほとんどいない。「本当の意味」とは、これが少々あいまいだが、ここではSE教育を受けてきた人という意味にしておく。
実はSE教育を受けてSEになった人は最も高齢でも40才台だろう。おそらくは30才台が大半のはずだ（全体ではなく上限の年齢だ）。
SEの上にはプロジェクトマネージャなど様々な職種がある。しかし、そのような職に転職できるのは、よほど経験値をためたキャラクタだけだというのはゲームも現実も変わらない。
出世の道からはずれたSEは、副収入の道を模索するか、出世とは無縁の創造活動に精を出すのではないだろうか？
その創造活動とはオープンソースソフトウェアのムーブメントだ。
実際には、OSSの開発に参加しているプログラマーは一線級のプログラマーだ。でなければ、あれだけのソースを管理できない。しかし、多くのSEが部分的にでもOSSに関与する時代がこれから来るのではないかと想像する。
それは会社内での出世は概ね40才台で決まるからだ。これから出世以外の道を模索するSEが続出するのではないだろうか？

冷暖房費の節約は逆効果？

冷暖房費を節約することで省エネを行うことが一般的になっている。
しかし、いきすぎた冷暖房費節約は逆効果になることがある。
例えば、空調の暖房が寒いと、今度は個別に暖房器具を使うようになる。それでは省エネにならない。
無駄なエネルギーを減らすことは重要だが、税金のように取りやすいところから取るという発想で、節約しやすいところからだけ節約すると、活動できないレベルにまで節約してしまうことがある。
むしろ、必要なエネルギーを確保するためにグリーン発電を行うという方向に転換する必要がある。
必要なエネルギーは使わなくてはいけない。しかし、CO2の発生をなるべく減らすようにエネルギーを増やさなければならない。

無意味の意味

報告書の形式が整っていないことがある。
確かに形式など無意味ともいえる。形式によって内容の価値が増減するわけではない。
しかし、形式など無意味だといえる資格を持つものは、その無意味な形式をきちんと実践しているものだけだ。
形式すら守れない（形式を実現するスキルがない）ものに、それを言う資格はない。
その意味では、無意味なことにも意味がある。
なお、報告書に一定の形式があるのは、それなりの理由がある。たいした理由ではないこともあるが、理由がないわけではない。

ドコモがGoogleと連携した

このブログでは前から携帯とPCの企業連携について考察してきた。
その中でドコモはMicrosoftと連携したらどうかと提案したが、実際にはGoogleと連携した。
これは必ずしも失敗ではないが、Microsoftとの連携の方が実利は大きかったのではないかと思う。
しかし、現時点ではMicrosoftのWindows LiveはWindows PCしか対象としていない。HotmailもRIA化している。携帯を重視していない証拠だろう。しかし、これは動きが鈍いだけでGoogleの後を追うように携帯にシフトすることは間違いないと考える。
Googleを選択したことで、Microsoftとの連携はなくなったと見てよいだろう。
これは、auがGoogleと連携したことを受けて、焦燥感を募らせたドコモが追随したということだろう。追随できたドコモはまだよい、追随できないSBMは相対的にサービスが低下する。
また、gooの存在価値も下がった。

日本企業はサーバを強化せよ

日本企業のサービスがいずれも海外企業に比べて大きく見劣りする点はサービスの利用条件、特にストレージ容量である。
Gmailが5GBを超えようとしているとき、Gooメールは25MB、Yahoo! Japanメールでも1GBだ。これだけで勝負にならないことがわかる。もっとも日本のポータルサイトは世界を見ていないので、競争相手に勝てればよいと考えているかもしれない。しかし、言語の壁はもしかすると以外に低いかもしれない。攻めに行かないなら負けるのを待つだけだ。
このような容量の格差はサーバファームの大きさに由来する。Googleには数百万台のサーバがある。もしも、そのすべてが1TBのHDDを装備すればEBに届くストレージを持っていることになる。
サーバファームの差はストレージだけでなく処理能力にも影響を与える。本来は処理能力こそ必要なものだ。
しかし、サーバファームの大きさはビジネスのスケールに依存する。日本だけでビジネスを展開する発想ではそれほど大きなサーバは必要ない。しかし、それではやがて確実に渡来する黒船を待つだけだ。
すべての企業がサーバファームを持つ必要はない。サーバファームを専業とする企業とそうでない企業に分かれ、専業企業は世界を相手にするべきだ。
ITがグリーンであるためには、利用率を高める必要がある。それには強者に集中する必要がある。その意味でもサーバの自営に固執せず、二極化する必要がある。

Gooはどこへいく

GooはNTTレゾナントが経営するポータルサイトだ。
光ファイバのISPで言えばFlet's、携帯のキャリアで言えばドコモという膨大な客層を持つにもかかわらず、全く振るわない。
基本的なサービスは他に大きく引き離されており、ユニークなサービスといえば「教えてGoo」くらいだ。それも「はてな人力」とどう違うのかといわれれば大差ないとしかいいようがない。
しかし、「gooラボ」には面白そうなサービスがたくさんある。これらがいち早く本格投入されればかなり差別化できるだろう。しかし、差別化はできるだろうが、キラーサービスになるかといえば疑問だ。あれば便利だが、なくても困らないものばかりだからだ。
もともと資本も開発力もある会社なのだが、大企業病なのか行動が遅い。これらのサービスを点から線に、そして面に展開して、新しい次元のサービスを創出するべきだ。そのためには、各サービスの連携を図り、それが困難が原因を追究することだ。また、それらのビジネスモデルも考える必要がある。
NTTの強みはやはり日本最大のキャリアだということだ。それゆえキャリアを無料で解放することに躊躇してしまう。しかし、今後はあらゆる面で定額制が浸透するので、いつかは高次のサービスへ軸足を移す必要がある。
NTTはキャリアとしてほぼ日本のインターネットを支配しているといってもよいのだからもっと強気の戦略を立ててもよいように思う。しかし、その中でポータルで稼ぐというモデルだけは考えにくい。ゆえにgooはお荷物だ。
livedoorはメールをGmailにした。gooもそうすべきだ。そして空いた資源を別のサービスに向けるべきだ。別のサービスとは他者の後追いではない。個人的にはVoIPや電子会議の類だと考えている。
日本は世界一低額かつブロードバンドが普及している国である。ゆえに他国が真似できない高品質サービスを提供できる。例えば、YouTubeとBlogのマッシュアップ、Skypeとの相互接続、テキストではなくビデオや音声を直接処理するソーシャルサービスなどが考えられる。

GoogleとWiki

なぜGoogleはWikiを提供しないのか？
考えてみれば、これは不思議なことだ。なぜなら、今のところGoogleはありとあらゆるサービスに手を伸ばしているからだ。Bloggerでブログを提供したなら、次に無限ともいえるストレージを利用してWikiを始めてもおかしくない。
最近になってGoogleがWikiを始めるというニュースがあった。具体的にはJotspotというWikiホスティングの会社を買収しているらしい。また、KnolというサービスでWikipediaに対抗するらしい。これからGoogleのWikiに注目したい。
話を元に戻すと、なぜGoogleはWikiへの対応が遅れたのかという疑問が残る。買収するのに適切な会社がなかったか、まわせる資金がなかったという単純な理由かもしれない。
しかし、技術的な問題もあるのではないかと考える。Googleはサーチエンジンがメインの会社だ。その中ではPageRankと呼ばれる仕組みを使う。PageRankでは参照関係を解析する必要がある。Wikiのようにあらゆる語をリンクするとPageRankに相当の負荷がかかることが予想される。WikiはPageRankの天敵ともいえる。そのため、最後に回したのではないだろうか？
手遅れにならない程度に遅れて市場に参入できればよいと考えたのだろう。

LivedoorとGoogle

Livedoorは敬遠していたが、どうやら食わず嫌いだったようだ。
LivedoorのメールはGmailそのもので、Googleを多用する自分としては大変好都合だった。
メールというコストの高いサービスをGoogleにアウトソーシングしてしまうところは経営的に正しい判断といえる。

ところで、舌の根が乾かぬうちに、逆のことをいうようだが、結構困ることがある。
それは、livedoorとGoogleのアカウントを同時に使うと混乱することがあるということだ。
いうなれば２つのGoogleアカウントを使うわけだから混乱するのも当然だ。
具体的には、livedoorメールを使っていたら、Bloggerへの投稿ができなくなった。メールを閉じたら投稿できた。

LivedoorとGoogle

Livedoorは敬遠していたが、どうやら食わず嫌いだったようだ。
LivedoorのメールはGmailそのもので、Googleを多用する自分としては大変好都合だった。
メールというコストの高いサービスをGoogleにアウトソーシングしてしまうところは経営的に正しい判断といえる。

Wikiを始めた

Wikiをしようと思ったが、PukiWikiなどを使うとわざわざサーバを用意しなければならない。
コンテンツを保護する必要があるときにはやむをえないが、そうでなければ面倒だ。
無料のポータルサイトでWikiができるところを探していたら、Livedoor Wikiがあった。他のポータルはまだWikiに対応していないようだ。Blogの次はWikiだと考えているらしい。何かと世間を騒がすところだが、この辺はさすがというべきだろう。
ポストBlogがWikiになるかどうかは多分に疑問がある。すでにミニブログへ移行する流れがあり、Wikiは知識を再編集するために（Wikipediaなどで）使われているが、編集には注意を要するので、ブログに飽きた人が手をつけるとは思えない。手をつけてもすぎに離れていくだろう。
しかし、個人的にはWikiを使うことができるので助かる。もっとも何に使うかはこれから考えていく。

マウスパッド座布団

子供のいすが木製でよくすべる。
いかにも食べづらそうだった。
座布団を買ったがゴムが付いていないものだった。紐で固定するものだったが、ぴったり固定はできない。
座りにくそうだったので、マウスパッドを使ってみた。
するとすべりがピタリと止まり具合がよい。

AtomとRSS

フィードのないWebは考えられなくなってきた。
フィードにはRSSとAtomがある。
RSSは先発であり、広く普及もしているが、その歴史は混乱そのものだ。特定の個人の意見が強く影響するため、将来性にも疑問がある。その点、Atomは理にかなった策定プロセスで仕様を決定している。
BloggerはAtom専用だが、FeedBurnerでRSSに変換できる。逆に、RSSをAtomに変換することもできる。
いずれか一方でよいのならAtomを選択したほうがよいだろう。Bloggerの選択は理にかなっている。

ミニブログの意義

ブログからミニブログにブームが移っている。
ブログはそれなりにまとまった内容を掲載するので記事を書くのが大変だ。それに対してミニブログでは短いコメントを掲載するだけでよい。手間を考えれば自然とミニブログへ移行するのはうなずける。
このブログもどちらかといえばミニブログに近い。よくできたブログでは複数ページにまたがる記事を執筆しているが、Bloggerには元々そのような機能はない。したがって、Blogger自体がミニブログ的な性格を持っていたともいえる。
ミニブログには、Twitterに代表されるフロー型とTumblrのようなストック型があるそうだ。前者についてはまだ結論を得ていないが、後者に関してはあまり必要性を感じない。大は小を兼ねるし、手間もさほど変わらない。むしろ本格的なブログの方が便利な機能が充実している分だけ楽をできる。

Java版XAMPPが欲しい（オールインワンApache）

XAMPPはapache friendだ。Apacheの友人を自称する以上、Apacheのすべてのプロジェクトを手軽に使えるようにすることを目指すべきだろう。
今のXAMPPにおけるTomcatの扱いはアドオンであり、つまりは付け足しだ。そのためコントロールパネルで制御することができない。
元々XAMPPはPHPをLAMPから発したものなので、Javaを重視していない。というより一切無視していたといってもよい。しかし、Java版XAMPPはPHP版XAMPPに勝るとも劣らないニーズがある。
これからのXAMPPはJava版も配布して欲しいと思う。
さもなければ他のプロジェクトでオールインワンApacheを作らないものだろうか？

Greasemonkeyのエディタを設定する

これはメモです。
Greasemonkeyをインストールしたが、編集ボタンをいくら押しても何も起動しない。
どうやらエディタの設定がおかしいらしい。
どうすれば直るのかと困っていたら、about:configでgreasemonkey.editorの値を変更すればよいことが分かった。

Ajaxのワープロ

Ajaxのワープロが欲しい。
理由は、文書をサーバに保存でき、どこでも仕事ができるからだ。もちろん、オンラインならばだが。
Googleドキュメントは、ここでいうAjaxワープロではない。Ajaxだが、ワープロではない。
Googleドキュメントの「文書」は明らかにWordを意識しているが、決定的な違いがある。それは紙のサイズを意識してレイアウトすることができるかどうかだ。
ワープロの定義は人により異なるだろう。ある人は文字を装飾できればワープロだという。それならばWYSIWYGのHTMLエディタもワープロだ。私は、紙の用紙サイズに合わせたレイアウト機能があって初めてワープロだと思う。
その意味では、Google文書では他形式にエクスポートしない限り明確なページレイアウトはできない。また、「HTMLを編集」メニューがある。つまり、Google文書はWYSIWYGのHTMLエディタにすぎない。
Google文書がWordの脅威になると本気で思っている人がいたら、実際にGoogle文書を使っていないか、何か勘違いしているかのどちらかだろう。
したがって、Ajaxの本当のワープロが欲しい。

GoogleのCSS

GoogleのページをFirefoxで読むと、エラーコンソールに多くの警告が表示される。
標準でないCSSをだいぶ使っているようだ。
おそらくはIEのためだろうが、非標準のCSSを使うのは感心できない。
Firefoxで表現できないわけではないが、表現が変わるとプログラムも変わるため、多くのブラウザに対応するのは実際上困難だ。おそらくブラウザ依存の処理はしていないのだろう。
今は非標準を無視するため問題とならないが、非標準をエラーとして扱うと何もできなくなってしまう。
このあたりがクライアントサイドの弱さだ。

マウスにHDD

ちょっと思いついたことを書く。
USBマウスにHDDを入れることはできないだろうか？
HDDといってもSSDだ。
SDメモリスロットを持つマウスくらいならありそうだ。
（調べたらソニーマーケティングから製品だ出ていた。）
しかし、SSDとなるとUSBよりeSATAがよく、マウスとはインターフェースが異なる。
紛らわしいのが10GB以上のUSBメモリをシリコンディスクと称する会社があることだ。
SSDなら100GBを超えるものも珍しくない。10GBでは少なすぎる。
USBでSSDを行ってもよいかもしれない。
（実際インテルはUSB対応SSDを製造しているが、容量は10GB程度）
SSDは小さいのでどこに装備してもかまわない。
マウスやディスプレイに入れるのもありえるだろう。
それによってデザインも多少変わってくるかもしれない。

ThunderbirdをFirefoxのプラグインに

Gmailを使っているとThunderbirdの出る幕がない。
しかし、オフラインでは役に立つ。
GmailはFirefoxで見るので、ThunderbirdがFirefoxのプラグインになれば１つで済む。
共通要素がないわけではない。例えば、HTMLメールを表示するエンジンにGeckoを使う。
ありえない話ではないだろう。

GPCに欲しい機能

アクセス制御ができるとうれしい。
他のページをインクルードしたい。いちいちiframeを書きたくない。
サイドバー以外のレイアウト（例えばトップタブなど）が欲しい。
フリーの素材集があるとうれしい。
コピーしたページの名前を変えたい。コピーしたファイルに「2」というポストフィックスが付くだけというのは気に入らない。
モバイルページを作成したい。PCページと兼用できるとうれしい。
ページ内検索フォームを設置したい。
フォルダを作りたい。

Page Creatorでホームページを作成した

Google Page Creator(GPC)はWYSIWYG（Googleドキュメントで文書を作成するよう）でホームページを作成するサービスだ。
テンプレートが決まっているので、あまり自由度はないが、その代わり手軽にホームページを作成できる。サーバを用意しなくてもよいので、その意味でも楽だ。
必要ならHTML編集もできるので、かなり高度な使い方もできる。
共通のフッターをiframeで読み込むこともできた。
ガジェットも貼り付けることができる。カレンダーを貼り付ければ予定表を公開することもできる。
その他、GPCで面倒なことはドキュメントで作成し、それをリンクすればよい。
かなり使えそうな手ごたえを感じた。

Googleのデザインが変わった

このブログでは、かねてよりGoogleのサービスで横のつながり（リンク）がないことを指摘していた。
最近になってiGoogleのデザインが変わり、Gmailのようになった。
これでGoogleの各ツールを自由に切り替えて使えるようになる。
少し便利になった。
次のステップとして、ツールが増えてくると整理が大変になる。
おそらくトップバー・ガジェットが開発されるだろう。
サイドバー・ガジェットはOSレベルで急速に普及しつつある。
ブラウザのツールバーは勘弁して欲しい。
そうなれば残るのは各ページのトップに表示するトップバーしかない。
GreaseMonkeyと連携すれば、各ページにトップバーを表示することも難しくない。

Gmailと連絡先

Gmailを使っているとメールアドレスがたまっていく。Outlookではアドレス帳として住所や電話番号と統合管理される。そのデータを共有アドレス帳にするアイデアを以前の記事で述べた。最近ではプロフィールを積極的に発信する人もいるので、本人の同意があれば公開してもよいだろう。共有アドレス帳はソーシャルホワイトページになるだろう。
ここではGmailの方を議論したい。
Gmailの連絡先に住所などを加えてアドレス帳にするのが先決だ。

My Firefox

Firefoxには便利なアドオンがある。しかし、パソコンを買い替えるとアドオンを再インストールする必要がある。これは結構面倒だ。
そのような場合、個人のアドオン情報を管理してくれるサービスがあると助かる。このようなサービスをMy Firefoxと表現した。
このようなサービスはFirefox以外のブラウザでも必要だ。しかし、他のブラウザは企業が開発しているので大規模なサポートサイトを準備することも比較的容易だ。
しかし、オープンソースのFirefoxは利益がでないため、サポートサイトの運営が難しいだろう。
するとアドオン情報をエクスポートする機能を用意し、それをUSBメモリにバックアップしておくことになる。

パソコンの買い替え

パソコンを買い替えたときデータを引っ越すのが大変だ。引っ越し作業は概ね以下のように行われる。
(1)インストール
新しいパソコンのセットアップを行う。これはやむを得ない。
(2)通常データのコピー
ここで通常データとはMy Documentなどに保存されるデータをさす。言い換えるとユーザから隠ぺいされていないデータである。それに対してアプリケーションが独自に管理するため、その保存場所が明らかでないデータを特別なデータと呼ぶことにする。
特に最近はHDD容量が大きいのでこの処理に長い時間がかかる。そこで日ごろからバックアップの意味も含めて外部HDDにコピーしておくとよい。変更分だけコピーするフリーウェアもある。
(3)フリーウェアのインストール
フリーウェアを矛盾なくインストールする必要がある。フリーウェアは数も多く、日本語化パッチを別途適用するなど手間がかかるものもある。Linuxではアプリケーションのインストールは自動で行えるが、Windowsではそうはいかない。Winows用レポジトリが必要だ。しかも商用ソフトも管理できるものが望ましい。USBメモリにインストールしておけばよいポータブルなソフトもあり、それらは全部通常データとみなせる。
(4)特別なデータのコピー
アドレス帳、メール、パスワードなど特別なデータを移す必要がある。これらはアプリケーション自体がデータの保存場所をMy Documentにするなどの改善が必要だ。
まとめると、これからのアプリケーションはポータブルであるべきだ。

SimpleDBにProxyを

Amazon Web ServiceにSimpleDBが加わった。
いつかは出るだろうと思っていたが、とうとう出た。
基本的なプラットフォームができたので、いよいよアプリケーションに乗り込むことができるようになる。
まだ、詳しくは調べていないが、他のサービスと同様なら信頼性は確保されているのだろう。
そうなれば欲しい機能はProxyだ。
他にリダイレクトしたり、他からリダイレクトされたりして、他のシステムと連携を図る。
（なければ）ぜひ、実現して欲しい。

Firefoxのお気に入りアドオン

Googleノートブック
Greasemonkey
Gmail Space
GMarks
del.icio.us (Complete)
Google Gears

Googleノートブックをアイデアプロセッサに

Googleノートブックは結構便利だ。
しかし、もう少し工夫があるともっと便利になる。
いまは単なるメモでポストイットのようなものだ。
そうやってスクラップしたメモを集めて整理できるとよい。
そのためにはアイデアプロセッサになるとよい。
基本的なアイデアプロセッサはWordのアウトラインで十分だ。
アウトライン機能を持つメモ帳ができればよい。

シンクライアントは誰のためのソリューションか

シンクライアントの宣伝が増えてきた。
内部統制のために必要という理由が多いが、内部統制はシンクライアントだけで解決できる問題ではない。また、シンクライアントでなくても解決できる。
邪推かもしれないが、日本のパソコンメーカーが生き残るには付加価値の高い企業向けパソコン、すなわちシンクライアントを売るしかないと考えたのではないだろうか。
実は、シンクライアントはユーザ企業のソリューションではなく、メーカーのソリューションなのかも知れない。
コンシューマ市場でパソコンが一家に一台普及し、飽和しつつある。家庭には日中、専業主婦しかいない。だから一台以上パソコンを買うのは無駄だ。一台を使い分けたほうがよい。一方、ビジネス市場では一人一台まで普及する見込みがある。
考えてみればもったいない話だが、一人が家庭と職場で別のパソコンを使うわけだ。それぞれの利益代表者はそう思わないだろうが、一方が使われている時間に他方は使われないのだから、これはりっぱに二重投資だ。世界の資源の無駄遣いだ。
閑話休題、家庭にもシンクライアントが普及するかもしれない。シンクライアントがパソコンより安ければ、朝夕家族が集まったときに一台のパソコンでは足りなくなる。少なくとも端末が足りなくなる。高いパソコンを買うより安いパソコンかあるいはシンクライアントを買うのは理にかなっている。

LMSの問題点～ロールを超えて

e-learningのためにLMS(Learning Management System)を使うことがある。
最近はだいぶ改善されてきたようだが、昔のLMSは使い物にならなかった。
なぜかといえば、教師は学生画面を見ることができず、学生に指導できないからだ。
なんのためのLMSなのかわからなかった。
これはWebアプリケーション全体の教訓となる。
マルチユーザのCMSでは、ユーザのロールでビューが異なる。そのため相手のトラブルを解決できない。マルチロールとするか、相手の画面を確認できる機能が絶対不可欠だ。

SOAPからRESTへ、しかし

Webサービスの主流がSOAPからRESTへ移りつつある。
実際には、当の昔にRESTが主流になっていた。
今後、ますますRESTへ流れていくだろう。
しかし、RESTには問題が多い。
標準がないので、場当たり的な方法が多い。
例えば、PUT、DELETEなどは一般的にサポートされないのでGET、POSTだけで実現する。かどうかもはっきりしない。
RESTツールが標準を作るだろう。それを待つのがよいかもしれない。
どのRESTが生き残るだろうか。

AtomからRSSへの変換

これはメモとして残しておく。
AtomをRSSに変換するにはFeedBurner(http://www.feedburner.com/)を使う。
BloggerのようにAtomしか対応していないブログには必要だ。

TeXが生き残る道

TeXはワープロの普及に伴い衰退してきた。
まだ、一部の学術分野ではかろうじて生き残っているが、その分野でもワープロは徐々に進出しつつある。
やがてTeXは役目を終えてなくなるのかもしれない。
しかし、TeXが便利に使える分野もある。
それは自動定型文書作成だ。特に差し込み印刷はWordよりずっと簡単に行える。
サーバサイドの文書処理にはもってこいだ。
サーバサイドでTeXを使うにはJavaに移植するのがよいだろう。
もう誰かやっているのだろうか？

逆geocoding.jp

geocoding.jpは日本の住所から緯度経度座標を求めるWebサービスだ。
マッシュアップに利用できる。
しかし、地図上で使う場合、ある地点の住所を知りたいこともある。
緯度経度座標から住所を求めるサービスがないものだろうか？

tar.gzよりgz.tarがよい

ろくなアーカイバがない。
いままでアーカイバで悩むことはなかったが、最近アーカイバに悩むことが多くなった。
まず、zipは定番だが、ファイルの容量に限りがある。GBサイズのファイルをアーカイブ使用とするとまるで役に立たない。
そこでtar+gzipを使う。
これはWindowsで擬似フォルダとして使えないので、あまりうれしくないが、アーカイブできないよりましだ。
tarとgzipは独立したツールだ。tarした後にgzipをかけるので全体が圧縮される。tarがgzipがパイプでデータを渡すのでサイズに上限がない。
しかし、全体を圧縮するためランダムアクセスが難しい。というより不可能だ。
そこで、gzipしたファイルをtarしたほうがよいのではないかと考えた。
ブロックのフラグメントがなくなることで領域を節約する効果だけで十分だと思う。
tarにインデックスを付加すればランダムアクセスが可能だ。
そのときの拡張子はgzipしてからtarするのでgz.tarになるのだろうか？
ちょっと意味合いが違うのでtgzの逆のgztがよいだろう。

GMarksがよい

ブックマークの管理に悩んでいた。
ブラウザに依存したくないし、マシンを変えるたびに移すのも面倒だ。
共有ブックマークがよいのだが、ブラウザのブックマークの方が手軽だ。
そこでFirefoxプラグインのGMarksを使ってみた。
かなりよいので推奨したい。
まず日本語に対応している。これは助かる。
次にGoogleブックマークと連動する。これは悪くないが、よくもない。というのは（誤解しているかも知れないが）Googleブックマーク自体が共有ブックマークの中でも最低に近い機能しかないからだ。個人的にはdel.icio.usの方が好きだ。しかし、共有ブックマークには違いないので我慢して使っている。
なお、GMarksだけを使うようにブックマークメニューを隠すこともできる。

YahooグループとGoogleグループ

Googleグループはよく使うので知っていたが、Yahoo! Japanにもグループがある。
似たようなものなので違いをまとめておく。
Yahooグループのブリーフケースは容量が20MBしかない。よって、グループで共有するのはちょっと厳しい。あくまでも数人程度の仲間でグループを作るのがよいだろう。
しかし、カレンダーを共有したり、投票ができたりするのは面白い。
もっとも、メンバーが数人ならメールだけでも十分投票できるのだが。

ブログに数式エディタを

ブログで数式を使いたい人は多くないかもしれない。
私はその少数派の一人だ。
ぜひ数式を使えるようにして欲しいと思う。
というのも、ブログで勉強するというスタイルがこれから流行ると考えているので、数学の勉強ができるようにするべきだと思うのだ。

P2PとRSS

P2Pが注目される理由は様々だが、真っ当な理由の一つは、サーバの負荷をクライアントに移転するためだ。
性能的にはクライアントもサーバも大きく変わらない。むしろゲーム用PCなどはサーバより演算性能がよいかもしれない。余談だが現在のゲーム用PCはGPU偏重でCPUはあまり生かしていない。
このP2Pの考えは企業などで進行するシンクライアントの導入とは逆になる。いま、クラウドなどサーバ側に移転する動きとP2Pなどクライアント側に移転する動きが競い合っている。
その流れの中でRSSをとらえると、P2Pと同様の発想があるように思える。
従来のサーチエンジンが直接文書を集めるのに対して、更新情報だけをRSSとして収集する。あるいはRSSをチャンネルとして収集する。
このような場合、更新の有無はユーザが直接チェックする必要がある。その意味で、P2Pと同じくユーザないしクライアント主導である。
一般的にP2Pはトラフィックを増やす。これはサーバの負荷を減らす代償として受け入れられているが、近い将来ネットワークが過負荷となればP2P方式には逆風が吹くだろう。というのも、いまはバルブ期のIT過剰投資に支えられているが、やがて需要が供給を上回る可能性がある。価格をコントロールできるので、キャリアにとってはそのような状況のほうが望ましい。ユーザにとっては逆だ。
したがって、ユーザが賢い消費者であるためにはP2Pを共有するサービスを生む出す必要がある。P2Pでいえばハブであり、RSSでいえば共有アグリゲーションだ。このようなサービスが今後増える必要がある。

軽量アプレット

Java Appletの存在意義は、もはやほとんどなくなっている。
AppletよりFlashの方が簡単で、Ajaxの方が手軽だからだ。
しかし、FlashもAjaxも使えないモバイル分野では未だに現役だ。
特にゲームが盛んだ。
しかし、やがてモバイルでもFlashやAjaxが使えるようになるとAppletは退場せざるを得ない。
そこで、Appletを復活させる方法を考える。
そのためには軽量でなければならない。
AppletはJVMを起動するため遅い。つまり起動の速いJVMを開発する必要がある。
起動を早くするには不必要なロードを極力減らすことだ。

Webサービスでメールを再構築

メールは非常に問題のあるコミュニケーション方法だ。
特にセキュリティが深刻だ。
メールを含むレガシープロトコルをWebサービスで再構築する必要があるだろう。

大量ファイルの転送

GUIを持つFTPクライアントを便利に使っている。
特に気に入っているのはFileZillaだ。FFFTPは転送を失敗することが多いので使わなくなった。
FileZillaで気になるのは、大量のファイルを転送するときだ。
大量ファイルの転送はFileZillaの得意の１つだが、それでも不十分だと思う。
FileZillaは、ディレクトリを巡回して、転送ファイルのキューを作成し、キュー先頭から２つずつ順番に転送する。
このとき巡回に非常に長い時間がかかる。また、転送ファイルを切り替えるときにも時間がかかる。
SSHが使えれば、リモートにログインして、zipし、そのファイルを転送してから、手元で解凍した方が断然早い。
そこで、FileZillaにディレクトリをzipして転送する機能があればよいのにと思う。
純粋なFTPコマンドだけでは無理なので外部コマンドを使用する。
また、FileZillaサーバとの組み合わせのときに機能するだけでも個人的には助かる。

Googleカレンダーで休日を表示

Googleカレンダーで休日を表示できないと思っていた。
しかし、調べたらすぐに休日を表示できることが分かった。
まったくカレンダーを使いこなしていなかったわけだ。
いままで休日がないのでカレンダーの使用を躊躇していたのだが、これで安心してカレンダーを使うことができる。
後は、PDAと同期する方法を調べる必要がある。
現在使用しているPDAはWindows MobileなのでOutlook経由の同期になるだろう。
PDA ⇔ Outlook ⇔ Googleカレンダー
少々面倒だが、やむをえない。
ところで、Googleカレンダーの休日にクリスマスという日本では一般的に休日ではない日まで含まれているのはどうだろう。間違って休んでしまいそうだ。
基本的に、Googleカレンダーでは職場の休日などを別のカレンダーで管理し、複数のカレンダーを重ね合わせて予定をチェックする。Googleカレンダーを使いこなすには、まず必要なだけのカレンダーを作るところから始める必要がある。

WebメールでIMAPする意味

GmailにIMAP機能が追加された。
POP3と同じ設定でIMAPを選択するだけでよい。
Webメールのよさは（オンラインでさえあれば）どこでも同じようにメールを読み書きできることだ。
それはIMAPも同じだ。
よって、WebメールであればわざわざIMAPなどする必要もない、と考えていたが、いざIMAPを使うととても便利だ。
なぜなら、いままでHDDに保存していたメールをもう一度Gmailにアップロードし、整理することができるからだ。
POP3ではアップロードできない。IMAPの価値はアップロードにあると思う。

WebメールでIMAPする意味

GmailにIMAP機能が追加された。
POP3と同じ設定でIMAPを選択するだけでよい。
Webメールのよさは（オンラインでさえあれば）どこでも同じようにメールを読み書きできることだ。
それはIMAPも同じだ。
よって、WebメールでIMAPをする意味はないと思っていた。
しかし、GmailのIMAPを使ってそれが間違いであることが分かった。
IMAPを使えば、クライアントとサーバの間で自由にメールを仕訳できる。例えば、２つのWebメール間でクライアントを介してメールを移動させることができる。この方法を応用すればGmailのストレージを使って、分散したメールを整理することができるのだ。
つまり、IMAPはメールを整理するプロトコルだということだ。
私は10年分のメールをGmailに整理した。10年というのは長いようだが、重要なメールはそれほど多くない。昔は重要でないメールをいちいち消していた。そのため以外に少ないメールしか残っていなかった。
今となっては10年前のメールに大した意味はないが、ライフログの一環として保存している。

PS3グリッドはゲーム中に

PS3のありあまる計算パワーをグリッドに使おうという動きがある。
Folding@homeなどだ。
しかし、これは現実的でない。
PS3は電力をひどく浪費する。自分がゲームするためなら電気代を払う気になるが、他人のために電気代を払う奇特な人は多くない。寛容さを期待するには電気代が無視できない。
したがって、ゲーム中にプロセッサを１つグリッド用に当てはめるなどの方法が必要だ。ゲーム中にできるグリッドこそPS3にふさわしい。
大作RPGで数時間プレイするなら、グリッドに大きく貢献できるだろう。

GspaceよりYspace

GspaceはGmailをストレージとして使うFirefoxプラグインだ。
Gmailの容量が増えつつあるので、結構便利に使える。
ただし、ファイルのサイズに制限があるので、ビデオなどは適さない。
その制限を許容するなら、Gmailより容量の大きな（無制限な）Yahoo mailがねらい目だ。
GspaceならぬYspaceができれば、便利かもしれない。
個人的にはメールのスペースをファイルで少なくしなくないので、ファイルはYspaceに置くだろう。

テキスト透かし

セキュリティ技術に電子透かしがある。
通常はイメージなどに使われるが、テキストに使えれば用途は広がる。
テキストには空白文字がある。スペースやタブだ。
これらを使って透かし情報を挿入できる。
例えば、タブは８文字ごとにインデントする。（プログラムなどでは４文字のこともある）
タブ前の文字位置により０～６文字の空白を挿入できる。
T個のタブの前にSi(i=1..T)個の空白を挿入できるとすると、ΠSiの情報を表現できる。
MD5などを挿入するにはかなりの文書量が必要かもしれない。
しかし、可能ではある。

TomcatをWebサーバと軽量コンテナに分ければ

Tomcatは多機能なサーブレットコンテナだ。
しかし、サーブレットコンテナは本来スループットを重視した軽量設計が望ましい。
これは多機能と矛盾する。
そこで、TomcatのWebサーバ機能を独立させ、軽量コンテナと密結合したらどうかと思う。
Webサーバ部分はApacheを目指す。
そうすればJavaによる一貫した処理が可能になる。
もっともスループットでApacheに勝てるとは限らない。しかし、近づければ用途は広がる。

EUCのマッシュアップ

EUCは個人のスキルに依存する。そのスキルを持った個人が別の部署に移動すればEUCは失われる。
EUCの成果を共有する必要がある。
EUCが共有されない原因は２つある。１つは個人に依存すること、もう１つはクライアントに依存することである。
前者についてはすでに述べた。後者について説明する。
EUCは個人のクライアント上で行われる。成果は共有されるが、EUCの過程は個人のクライアントに置かれ、共有されない。
EUCの成果物にプログラムが付属し、そのプログラムを共有できても、メンテナンスや拡張ができない。
そこでEUCの過程を含めて共有することで、全員に成果を伝達する。個人のスキルやクライアントの機能も過程の一部だ。
そのためにはサーバ上でマッシュアップするEUCでなければならない。マッシュアップでは、その方法がわかりやすく視覚化される。また、そのようなマッシュアップでなければならない。視覚化すなわち見える化は体験共有の第一歩だ。

テキスト文化対決

テキスト文化にはエディタ文化とワープロ文化がある。
歴史的にはエディタ文化の方が古いが、ワープロ文化の方が日常的だ。
ワープロはWYSIWYGを原則とする。つまり、我々が日常的に用いている書き方で書けばよい。
それに対してエディタ文化はワープロ以前のCUIから育まれた文化である。よって歴史は古いが、人よりコンピュータの都合に合わせている。
エディタ文化はroffやTeXにさかのぼる。
これらでは、段落を空行でわけ、一文で改行することもある。
このようなテキスト文化は今日でもメールやブログに生きている。しかし、正式な文書で使えない書き方であることは自明だ。
しかし、このようなテキスト文化が異質であることを疑いもせず、正式文書に使う人も少なくない。特にパソコンメールに慣れた人に多い。携帯メールでは逆に改行しない人が多いのではないだろうか。

コンビニで現像を

最近デジタルコンビニを自称する写真屋が多くなった。
しかし、コンビニというもののちっとも便利でない。
朝始まらず、夜には閉まっている。
そこで、朝依頼し、夜受け取るニーズに答えてくれるコンビニがほしい。
本当のコンビニができればよいが、デジタルコンビニが進化してくれてもよい。
別の方法ではオンラインで注文し、郵送してくれるサービスがあってもよい。

リユーズ切符はいかが

最近、電車の切符を買わなくなった。Suicaのおかげだ。
しかし、Suicaにも欠点はある。そこでクレジットカードで補充できるPASMOが注目された。
しかし、本来はクレジットカードで切符１枚から購入できるべきだ。高額な新幹線の切符だけでなく山手線の切符も買えるべきだ。外国人観光客や地方から上京した人などSuicaを持たない人あるいは持ちたくない人のことも考える必要がある。
しかし、普通の切符は使い捨てなのでもったいない。
もちろん普通の切符も回収されリサイクルされるだろう。しかし、リサイクルは結構高い。
台湾の地下鉄？はテレフォンカード式の切符で何度もリユーズされる。行き先は電子的にチェックできればよいので、リサイクルしなければならない印刷を止めればよい。大きさもテレフォンカードサイズでよいが、機器の変更が大きいなら切符サイズにしてもよい。
どうしても行き先を表示したければ磁気的に表示するカードもある。

OpenAccessとOpenLog

分散認証をつかさどるOpenIDが話題だ。
しかし、認証(authentication)に続いて認可(authorization)と監視(audit)が必要だ。
このオープンサービスが重要になる。それらをOpenAccessとOpenLogと名付けてみた。
OpenAccessは認可をつかさどる。(ID,URL)を管理し、不正なアクセスを禁止する。ただし、あくまでアドバイスに過ぎないのでプログラムで対応する必要がある。別の方法はURLを実URL（秘密URL）と仮想URL（公開URL）に分け、内部でリダイレクトする方法だ。後者ではアドバイスでなく完全に制御できる。しかし、負荷が大きいので推奨できない。少なくともオープンサービスにはならないだろう。さらに経路や状況を加味してもよい。
OpenLogはログを管理する。ログの種類などをIDで示し、(ID,log)を管理する。logは大量のデータとなるので、一括アップロード／ダウンロードは考えにくい。時間を指定して部分的にアクセスできるようにする。

ケーキになったアイス

ハーゲンダッツドルチェにモンブランが出た。
まるでケーキのようなアイスだ。
というより元々ドルチェシリーズはケーキなどのいわゆるスイーツを模倣している。
しかし、アイスにデコレーションやスポンジまで入れてしまうとは。
もうケーキといってもかまわないだろう。
これはアイスのイノベーションだろう。
新しい領域を開拓したといえる。もはや既存のアイスは敵ではない。
また、アイスであることの利点をうまく利用していることも注目だ。
一般にケーキは賞味期限が短い。しかし、アイスは長い。というより賞味期限がない。
つまり賞味期限のないケーキが誕生したことになる。これは大きなインパクトだ。

Apacheはa patchではない

Apacheはa patchの意味だという都市伝説？がある。
しかし、Apacheの作者は違うという。本人が違うというのだから違うのだろう。
しかし、この誤解はなくならない。
それは、どんなに本人が主張しようとそれを信用できないからだ。
アメリカでは人種差別が社会問題となっている。社会的地位のある人が人種差別的発言をすれば大きな問題となる。
a patchが偏見かどうかははっきりしないが、偏見と受け取られる可能性もある。
よって、本人は真実がどうであれ否定するしかない。
このように、この問題は永遠に解決されない謎となった。

RIAとThin

RIA(Rich Internet Application)とThin clientのことだ。
両方とも流行りだ。
しかし、RIAは複雑で重く、Thinは単純で軽い。
両者の方向は逆だ。
両方とも追及するのは矛盾だ。
両者は目的が違う。
RIAはクライアントのパワーをユーザ経験に振り向ける。それはサーバの負荷をクライアントに移すために使われる。
Thinはサーバのパワーをデータ保護に振り向ける。Thinはクライアントを信用しない。
もしThinでRIAを実行すると両方実現されるが、サーバの負荷は最も高くなる。Thinの目的は達成できてもRIAの目的は達成できない。
RIAとThinを両立するにはネットブート型がよい。

なぜオープンサービスか

OSSはよくも悪くもソフトだ。ハードと組み合わせなければ意味がない。
ハードにはクライアントとサーバがある。
クライアントで使われるOSSはそのままでよい。
サーバのOSSはユーザから見えない。OSSでサーバ構築コストを下げることができる。しかし、OSSだけでは差別化できない。
多くのOSSサイトが乱立する中で生き残るのは価値あるサービスを提供するものだけだ。
ユーザにとっての価値はサービスの質と価格で決まる。価格が小さいほど価値は高い。無料のサービスにはなかなか勝てない。オープンサービスは公開されたサービスであり、無料で提供されることが多い。よって強い競争力を持つ。
オープンサービスが有料でも、それに負荷価値を加えることができれば、高い料金を要求できる。
そこでオープンサービスを組み合わせて新たなサービスを構築するマッシュアップが重要になる。
オープンサービスの普及には以下のオープンサービスが必要だ。
・ストレージサービス
・認証サービス
・許可サービス
・マッシュアップサービス
これらのうちストレージとマッシュアップは無料のオープンサービスが登場している。しかし、ストレージサービスの容量は決して十分ではない。

Social Address Book

前の記事でグループウェアについて考察し、その本質がグループ管理だと述べた。
それを実現する１つの方法が共有アドレス帳(Social Address Book)だ。
アドレス情報は個人情報なのでこれを共有する発想は従来なかっただろう。
しかし、特定のグループ（例えば企業など）ではメンバーの個人情報を共有するコンセンサスが存在する。要はそのグループの外部に漏洩しなければよいだけだ。（もっともそれは極めて困難なことだ。）
メンバーがいちいち作成しなくても主なサブグループが登録されているアドレス帳があれば、ポータルサイトだけでグループウェアの用を足す。
この場合、管理者がサブグループ情報を投稿し、皆がそれを更新する手続きを踏む。
それに対して、Socialというからにはボトムアップのアプローチがあってもよい。その場合、名前の付け方に個人差があることが問題となる。よって、含まれるメンバーによってグループを比較し、グループの同一性を検証し、同一化を推奨する機能が必要だ。
この程度の機能があれば共有アドレス帳として十分使えるだろう。

グループウェアとは

実はグループウェアとは何かと改めて問われるとうまく解答できない。
グループのコミュニケーションを円滑にするツール一式だというところまでは了解している。
しかし、その先で、具体的にどのようなツールから構成されるのかといえば、グループウェアによって違うとしかいいようがない。
それではミニマムセットは何かと問われれば、メッセージ（メール）とスケジュールだろう。これにファイル共有が高い率で加わるかもしれない。
しかし、これらのツールはもはやどこのポータルサイトでも無料でサポートされている。
昔は無料のポータルでは容量の制限が厳しかった。しかし、Googleの登場により他のポータルもほぼ無制限に容量を拡張し始めた。その結果、グループウェアの基本機能は無料で実現できることになった。
そのような今日、改めてグループウェアの本質を考える。
するとグループウェアがサポートするのはあくまでクローズドグループであることが重要だと思う。
一般的なポータルでは公開か非公開のいずれかであり、グループを特定することが難しい。可能ではあるがファイルごとにアカウントを列挙する方法でグループを形成するのは現実的でない。その意味ではグループウェアの本質はグループを管理することに他ならない。
よって、メッセージやスケジュール、ファイル共有には既存のポータルサイトをそのまま利用し、グループ管理部分に特化した製品が登場してもおかしくない。このような製品はマッシュアップで比較的容易に実現できるだろう。これが次の時代のグループウェアではないかと考える。
例えば、一般的なメールだけでグループウェアと同じことはできない。なぜなら、送信者の証明が困難だからだ。それを気にしなければグループウェアと主張することもできるが、それを真に受けてくれるお人よしばかりではない。
現実のグループウェアは、その問題をインターネットメールとは別にイントラネットメールを使うことで解決している。イントラネットメールは実のところ送受信者をグループとした掲示板にすぎない。それはメールに比べて極めて効率よいが、かなり異質な利用感を与える。
メールで送信者を特定するにはPKIが不可欠だ。しかし、ほとんど利用者がいない。しかし、ポータルサイト自身がPKIを提供すれば、容易にPKIを普及させることができる。
後はグループ名をユーザ間で要求できるアドレス帳の機能があれば、最低限のグループウェアが無料のプラットフォーム上で実現する。
現在グループウェアは様々な模索をしているが、本質的な部分の改善ではないように思える。例えば、Ajaxを使ってOfficeのようにすることは確かに重要だが、実装の問題だ。また、SaaSになることも必然であろうが、特に大きな変化ではない。この程度の変化では、ここで提案した無料のグループウェアに太刀打ちできないだろう。
よって、誰が本質的なサービスをいち早く立ち上げ、サポートや広告などで利益を上げるビジネスモデルを展開するかが問題だ。

暖房は電気へ

この冬の暖房費は高騰しそうだ。
灯油は1700円を超えている。数年前は1000円を切っていたのだから、値上がり率は尋常ではない。
ガソリンが1.5倍になるとき、灯油が2倍になるのは、税金の割合が一定であるためだろう。どちらも同じだけ値上がりしているが、税金の低いほうが値上がり率が高いのだと思う。
いずれにせよ灯油が安い暖房として知られた時代は終わった。今後も灯油が安くなる可能性はきわめて低い。
するとガスに流れるより電気に流れるだろう。
今後の暖房は電気が主流になる。それはCO2の面から見ても正しいと思う。
なぜなら今でこそ発電は火力発電が多いが、電気は必ずしも火力でなければ発電できないわけではないからだ。実際、電気代はほとんど値上がりしていない。
今後、グリーン電力が増えれば、石油価格に影響されずに暖房できるだろう。

HDDのグリーンコスト

HDDを容量価格比で評価することが一般的だが、これはグリーンではない。
500GBのHDD2台より1TBのHDD1台の方が消費電力が小さいのでグリーンだ。動作時の消費電力だけでなく製造時のCO2も削減できる。
今後は、HDDを容量／価格／消費電力で評価すべきだろう。
かつて、このブログでは消費電力を二乗したらと提案した。HDDでもそのほうが良いかも知れない。

Firefoxのバグ？

Firefoxを使っているが、トラブルに会った。
Gmailでファイルを添付するとき、参照ボタンを使う。
ある場所でネットワークドライブを参照したのを最後に、別の場所に移動して参照しようとすると、どうやら存在しないネットワークドライブにアクセスし、「応答なし」になってしまう。
しかも、これが再起動しても解消されない。ということは、これを解消するにはどうしても再度ネットワークドライブにアクセスするしかないようだ。もし、そのネットワークドライブが２度と利用できないとき、どうすればよいのだろう。再インストールまでしなければならないのだろうか？
これはWindows版Firefoxのバグだと思うが、Windowsの仕様なのかも知れない。

メールにOpenIDを

メールのセキュリティは深刻な問題だ。
にもかかわらず誰も解決できていない。
SMTPに認証を取り入れるだけでは問題を解決できない。なぜなら不正なサイトで認証を済ませればよいからだ。
そこで、SMTPの認証にOpenIDを取り入れることを提案する。
OpenIDで安全な分散認証が可能かどうかは正直分からない。無理かもしれない。しかし、今より多少ましになるだろう。そして問題の部分がメールから認証に集約されるだけでだいぶ対処法が変わるだろう。

日本PCメーカーの再編

日本メーカーの再編が進んでいる。
ソニーが半導体事業を東芝に売却した。おそらく日本の半導体は東芝に集約されるのだろう。
また、パソコンも東芝が飛びぬけている。ただし、海外での話しだ。国内では他のメーカーも検討しているが、日本という狭い市場で競争しても高が知れている。しかし、システムインテグレーターとしての東芝はいまひとつだ。というのも、東芝はノートPCのみで、デスクトップやシンクライアントなどを扱っていない。扱っているのかもしれないがシェアはほとんどないだろう。原子力からパソコンまで幅広く供給しているにもかかわらず横方向の連携がなく、相乗採用いわゆるシナジー効果が得られていない。
システムインテグレータとしてはNTTデータ、富士通、NEC、日立、IBMなど優れた企業がある。これらの企業が自社製PCに固執せず、他社製PCでソリューションを提供できればよい。しかし、このうち富士通、NECは自社製PCを販売しなければならない都合上、ソリューションのコストを下げられないだろう。これは真綿で首を絞めるように効いてくる。
この２社も内部的には中国で製造しているだろうから、コストが際立って高いわけではないだろう。しかし、専業他社には及ばない。よって、２社をソリューション部門と製造部門に分けて合併してしまうのがよいように思える。
もっとも素人の判断なので実際にどうなるかはプロの当事者が決めることだ。

高速連写カメラ

ミルククラウンや銃弾の撮影などに使われる高速連写カメラをデジタル化するのが次のデジカメの課題だ。
CASIOの試作機は600万画素静止画を最大60枚/秒で連写できる。
もっとがんばってミリ秒を切って欲しいところだ。

携帯ビデオとYouTubeを連動させたら

携帯ビデオは６割の人がほとんど使わないそうだ。
それでビデオ機能をなくせばよいかといえば、それでは話が終わってしまう。現実問題としてビデオ機能を削除してコスト削減できるなら、それでもよいだろう。しかし、カメラは同じなのでソフトだけの問題だとしたら、わざわざなくすまでもない。
そこで、YouTubeと連動させたり、ビデオアルバムサイトと連動させるなどのアイデアを出すべきだと思う。

Open Serviceの時代

これからのキーワードはOpen Serviceだと思う。
OSS(Open Source Software)は認知された。しかし、必ずしもOSSである必要はない。OSSの重要さはソフト自身でなくサービスとして料金を得ることが可能だというビジネスモデルを確立したことだろう。
また、OSSだけではクライアントユーザにはメリットがあるが、ビジネス事業者にメリットは少ない。OSSを実行するには資源が必要だ。OSSに資源を割り当て、サービスとして公開することでより多くの人がメリットを享受できる。
これがOpen Serviceだ。Open Serviceは必ずしもOSSである必要はない。Gmailなどは典型的なOpen Serviceだといえる。
Open Serviceが成り立つには資源としてクラウドが必要だ。これは徐々に普及しつつある。
Open Serviceが無料になるかどうかはわからない。むしろ有料で始まるだろう。しかし、有料サービスは利用者が限定される。広告収入モデルなどを併用するべきだろう。Open Serviceのビジネスモデルはまだない。

Googleのサーバは日本のサーバより多い？

Googleのサーバは100万台だという。
これは日本の１年間のサーバ出荷量60万台を上回る。
こちろん日本全体のサーバ台数をGoogle１社で上回るはずはない。
しかし、今のペースだとやがて日本全体とGoogleが同じ台数のサーバを持つことになるかもしれない。
これを危惧する声は大きい。
それはもっともなことだ。しかし、危惧すべきはデータセンター関連産業であり、ユーザは必ずしもその限りではない。
ユーザにとっては最も安いサービスを選択するだけの話だ。Googleだろうが、日本メーカーであろうが関係ない。両者が切磋琢磨してくれればそれでよい。
問題はGoogleの一人勝ちになると価格が高騰する可能性があるということだ。
私は以前から国家プロジェクトをするならスパコンよりデータセンターだと主張して来た。今後ますます企業戦略では太刀打ちできなくなり、国家戦略が必要になるだろう。