ソーシャルアドレス帳

Posterousに投稿したけど、こっちにまとめとく。自分メモ。

ソーシャルアドレス帳っていうのは、僕の造語（だと思う）なんだけど、ユーザ主導で構築された、世界でひとつの大きなアドレス帳のこと。 

これまでのアドレス帳は、その所有者がメモってたり、あるいはタウンページみたいな電話帳だったわけです。最近では携帯電話の中に収まってたりしますが。でもこんなことしちゃうと、携帯電話買い換えたり、引っ越したり、メールアドレス変えたり、これまた最近だとTwitterやSNSのアカウント名変えたりすると、アドレス帳の情報は明示的に書き換えるまでずっと古いままになってしまうのです。そのため、そういうアドレス帳に記載されている情報に変更があった人が、それを教えたであろう人にお知らせするわけです。ぶっちゃけ、めんどくさい。 

もうひとつ云えば、一度手から離れた情報は、回収できないのです。アドレス帳に載せる情報なんてのは思いっきり個人情報なのに、セキュリティ管理のレベルがまちまちなお友達やご知人たちにそれを渡すのはどうかと思うし、一旦教えてしまったけど、後になって失敗したなぁとか思うこともあるかもしれないでしょう（笑）。 

そこで、ソーシャルアドレス帳です。じゃーん。自分の情報は自分でアップデートして、その情報にアクセスできる人を「設定」すればいい。もちろん、変更した情報は通知したりされたりする必要なんてなく、WebブラウザからとアプリからRESTなAPI経由で突っつけるようにしといて、常に最新の情報が取れるようにしとけばいい。SNSなどのプロフィールも、ここから取ってくればいい。利用者はいちいち複数のサイトのプロフィールを書き換える必要はない。各サイトで記載する情報を変えたい場合は、サイトに応じて出す情報を管理（設定）できるようにしておけばいい。 

そしてさらに、認証基盤としても動作させられるようにしたい。せっかくアイデンティティ情報を握ってるんだから、認証もここでやりたい。まずは普及してるOpen IDから対応させる。将来的には、是非、「事実上の」国民IDとして活用してもらいたいね。小国は国民IDとして採用するところも出てくるかもしれない。 

チャレンジなところは、普及の方法でしょう。現在広く使われている「サイロ」なやり方が競争相手。紙のやつに対してはPCからWebで見てもらうか、あるいは電子書籍版を出せばあとは時間が解決してくれそうだし、iPhoneやAndroidはアプリを作ってうまいこと電話やSNSアプリなどと連携させられれば素敵なんだけど、問題は旧式の携帯電話に入ってるやつでしょう。ネイティブの電話帳アプリしか使えないのも多い。ここは最後に手をつけるという作戦にするなら、もうちょっとスマートフォンが普及して「これいいじゃん」って言ってもらえる時代に出せるように、世の中に出すタイミングを図ることだな。 

僕の読みだと、そろそろ顔出しを初めてもいい頃合い。でなければ、僕が作ろうかな。だって、僕が一番使いたいもん。

マネタイズの話が抜けてたね。利用者は無料が当然でしょう。お金は、まずSNSなどのソーシャル系サービス運営会社からいただきます。彼らにとっては、ユーザを獲得する手段になるはず。

次に、企業向けサービスをやって、そこからもいただきます。ひとつは社員向け。企業からみたら、社員の情報を管理したいと思うはず。そういう企業向けの専用ポータルや専用グループの作成や、LDAPで管理されるような部署や役職の管理、パスワードポリシなんかの機能があれば、たぶん欲しいんじゃないかと思う。

ふたつめは、企業の顧客向け。例えばB2CのEコマースなんかだと、顧客の個人情報を管理するのは、はっきりいってリスク以外の何者でもない。なんだかんだいっても個人情報漏洩は嫌でしょう（笑）。そうは言っても、顧客の個人情報がなければ、商品を送れないし、連絡もできない。だから、ソーシャルアドレス帳から引っ張ってくれば、自社で管理する必要がなくなるというわけです。これもたぶん売れる。

各SNSや企業に個人情報を提供するか否かは、ソーシャルアドレス帳の利用者各々が管理（設定）すればいい。そしてもちろん、Default Deny（設定されていなければ提供しない）が、ネットワーク屋さんのルールですね。

そういえば去年の暮、Haas Schoolの先生に同じ話をしたら、同じようなことを考えている人がいると言ってたな。コンタクトするかどうかは迷うな。敵かな？味方かな？（エキセントリック少年ボウイ）

クラウド事業者と名乗るための最低条件？

2010年9月27日の日経産業新聞３面に、日経BPの北川氏による「クラウド市場、過大評価？」という記事の中で、「クラウドの最低条件である仮想化とプロビジョニングがそろってからクラウド企業を名乗るべきだ」という内容の記述があった。おそらくパブリッククラウドのIaaSまたはPaaS事業者を対象にしたものと思われるが、果たして本当だろうか？

僕の個人的な意見を述べさせて頂くとすると、半分賛成、半分反対だ。例えば、クラウドという言葉を作ったGoogleは、仮想化技術を使っていない。冒頭の文言に従えば、Googleはクラウド企業を名乗るべきではない、というおかしなことになってしまう。

[参考資料] Channel Register "Google abstains from blades, VMware and the rest of the hype"
http://www.channelregister.co.uk/2007/06/25/google_barroso_datacenter/

一方で、日本のIT業界はクラウドというキーワードを非常に広義な意味でとらえ、商売のための言葉、いわゆる「バズワード」にしてしまった感も否めない。未だに「インターネットを介してサービスを提供していればクラウド」などと真面目に語られると、こちらが赤面してしまう。したがって、何でもかんでもクラウドと呼んで欲しくない気持ちもよくわかる。

そこで本稿では、まず米国で一般的なNIST (National Institute of Standards and Technology) によるクラウドの定義を紹介し、次に日本および米国におけるクラウド事業者、特にプラットフォームを提供するサービス事業者について、「クラウドを名乗る条件」という視点から調査、比較した結果をまとめる。

クラウドの定義
まずクラウドの定義についてまとめておく。米国は、NISTの定義が業界標準になったと言ってよいだろう。NISTの定義は、5つの本質的な特徴、3つのサービスモデル、4つのデプロイメントモデルで構成されている。以下にその日本語訳を掲載する。日本語訳はAgile Cat氏のブログを抜粋し、一部を改変して掲載している。

[参考資料] Agile Cat氏ブログ 「とても重要なNISTのクラウド定義：対訳」

http://bit.ly/d0Y2tJ

本稿もこのNISTによるクラウドの定義に則って記載するが、ここで注意していただきたいのは、NISTの定義では仮想化をクラウドの必要条件にしておらず、あくまで例として記載している点だ。

●5つの本質的な特徴
１）オンデマンド・セルフサービス
それぞれのサービスプロバイダーとの人的な対話に依存することなく、消費者は必要に応じて自動的かつ一方的に、サーバやネットワーク、ストレージの利用時間といった、コンピューティングの能力をプロビジョニングする。

２）広帯域のネットワークアクセス
このコンピューティング能力は、ネットワーク上で利用でき、また、標準的なメカニズムを介してアクセスできる。それにより、各種のシン／シック クライアントプラットフォーム（モバイルフォン／ラップトップ／ PDA）からの利用が促進される。

３）リソース・プール
プロバイダーがコンピューティングリソースは共有され、マルチテナントモデルを利用する多数の消費者に提供される。そこでは、消費者からの需要にしたがって動的に割当／解消される、物理的あるいは仮想的なリソースを用いられる。一般的に、そこで供給されるリソースの正確な位置を、顧客が制御／知覚することはない。そのため、ロケーションから独立した感覚があるが、より高い抽象レベル（国／州／DC）においてロケーションは特定されるかもしれない。こうしたリソースの例としては、ストレージ／プロセッサ／メモリ／ネットワーク帯域幅／仮想マシンなどが含まれる。

４）迅速な伸縮性
コンピューティング能力のプロビジョニングは、迅速で伸縮性のあるものになる。そして、いくつかのケースでは自動的に、スケールアウトの際に拡大し、また、スケールインの際に縮小する。消費者にとって、このプロビジョニン能力は無限に追加できるものになり、また、従量制で購入できるものとなる。

５）（適切に）測定されたサービス
サービスの種類（ストレージ／プロセッサーバンド幅／アクティブユーザカウント）に適した抽象レベルにおける測定機能を高めることで、クラウドシステムは自動的にリソース利用を制御し、最適化する。こうしたリソースの使用量については、利用されたサービスのプロバイダーと消費者から、透過的にモニター／コントロール／レポートされる。

●3つのサービスモデル
１）SaaS
このコンピューティングの能力は、クラウドインフラストラクチャ上で実行されるプロバイダーのアプリケーションを用いて、消費者に提供される。 そのアプリケーションは、 Web ブラウザ（Web メールなど）といったシンクライアントインターフェイスを介して、各種のクライアントデバイスからアクセスできる。消費者はネットワーク、サーバ、オペレーティングシステム、ストレージや、個別のアプリケーション機能さえも含めて、基礎となるクラウドインフラストラクチャの管理／制御は行わないが、個々のユーザに特定されるアプリケーションコンフィグレーションは例外となる。

２）PaaS
プロバイダーがサポートするプログラム言語とツールで作成したクラウドインフラストラクチャに、消費者が作成もしくは取得したアプリケーションをデプロイすることが、消費者に提供される機能となる。消費者はネットワーク、サーバ、オペレーティングシステム、ストレージなどの、基礎となるクラウドインフラストラクチャの管理／制御は行わないが、デプロイされたアプリケーションを制御し、また、そのホスティング環境をコンフィグレーションすることがある。

３）IaaS
オペレーティングシステムやアプリケーションを含む任意のソフトウェアを、消費者がデプロイ／実行することができる場所で、プロセッサ／ストレージ／ネットワーク／重要なコンピューティングリソースなどをプロビジョニングするための機能が、消費者に対して提供される。消費者は、基礎となるクラウドインフラストラクチャの管理／制御は行わないが、オペレーティングシステム／ストレージ／デプロイされたアプリケーションを制御し、また、選択された（ホスト、ファイアウォールなどの）ネットワークコンポーネントを限定的に制御する。

●4つのデプロイメントモデル
１）プライベートクラウド
このクラウドインフラストラクチャは、特定の組織のために単独で運用される。そして、当該組織あるいはサードパーティーにより管理され、オンプレミスあるいはオフプレミスで運用されるだろう。

２）コミュニティクラウド
このクラウドインフラストラクチャは、いくつかの組織により共有され、また、関心事（ミッション／セキュリティ要件／ポリシー／コンプライアンス）を共有する特定のコミュニティをサポートする。そして、当該組織あるいはサードパーティーにより管理され、オンプレミスあるいはオフプレミスで運用されるだろう。

３）パブリッククラウド
このクラウドインフラストラクチャは、不特定多数の人々や大規模な業界団体などに提供され、対象となるクラウドサービスを販売する組織により所有される。

４）ハイブリッドクラウド
このクラウドインフラストラクチャは、複数のクラウド定義（private／community／public）から、2 つ以上を組み合わせたものとなる。それぞれに固有の実体は保持するが、標準あるいや個別のテクノロジーによりバインドされ、データとアプリケーションのポータビリティ（クラウド間でのロードバランシングのためのクラウドバーストなど）を実現する。

※注：クラウドソフトウェアとは、ステートレス／疎結合／モジュール性／セマンティックインターオペラビリティを重視するサービス指向であることで、そのクラウドパラダイムの先進性を活用するものである。

－＊－＊－＊－＊－＊－＊－＊－＊－＊－＊－＊－＊－＊－＊―

さて、クラウドを定義したところで、本題の「クラウドを名乗る条件」を視点に調査した結果をまとめる。プラットフォーム、すなわちサービス提供モデルの中のIaaSおよびPaaSの事業者についてそれぞれ分けて比較する。よくこれら2つのサービス提供モデルも混同されて「クラウド」と括られることも多いが、抽象化される対象が異なるため、中身は全く別物だ。

IaaS事業者
１）日本国内
日本国内の大手SIerのクラウドを見てみよう。まず、調べていて思うのは、どれも本当に売ってくれるのか、本当に動いているのかがわからない。「資料請求」や「お問い合わせ」のリンクしか見あたらない。なぜ「仮想マシンを作成する」ボタンがないのか？答えは、下表をご覧頂ければ一目瞭然。北川氏の指摘する、自動プロビジョニングの機能がないからだ。NISTの定義に照らし合わせても、オンデマンド・セルフサービス、迅速な伸縮性、測定されたサービスなどのクラウドの本質的な特徴を備えていないことがわかる。このタイプのIaaSは、発注してから利用できるようになるまで、少なくとも数日を要する。そして迅速な伸縮性を備えておらず、到底、クラウドと呼ぶことはできない。なお10月より提供開始を予定している富士通のオンデマンド仮想システムサービスは、本当のクラウドのようである。日立製作所は、IaaSを提供していない。

事業者		日立情報	NTTデータ	富士通	NEC	日本IBM
サービス名称		Business Stage ROD	BizXaaS インフラサービス	オンデマンド仮想システムサービス*1	RIACUBE	マネージドクラウドコンピューティングサービス
北川氏	仮想化	○ VMware	○ VMware	○	○ VMware	○ MCCS
	自動プロビジョニング	×	×	○	×	×
NIST	オンデマンド・セルフサービス	×	×	○	×	×
	広帯域のネットワークアクセス	○	○	○	○	×
	リソース・プール	○	○	○	○	○
	迅速な伸縮性	×	×	○	×	○
	測定されたサービス	×	×	○	×	○

*1: 2010年10月提供開始予定。

一方、レンタルサーバ事業者やホスティング事業者などは、古くからパーティショニング技術を活用して仮想専用サーバ（Virtual Private Server; VPS）を提供してきた。その延長線上で提供されるIaaSサービスもあり、サーバやストレージの大きさによって複数のメニューを数個用意しておいて、ユーザに選ばせる。これらは残念ながら月額課金のものばかりで、即日利用、即日破棄などはできそうにない。例えば、さくらインターネット「VPS」、IDC Frontier「NOAHプラットフォームサービス」、IIJ「GIO コンポーネントサービス」、伊藤忠テクノソリューションズ「TechnoCUVIC」などがある。

そんな中でも、ニフティが提供する「ニフティクラウド」は、正真正銘のIaaS、パブリッククラウドサービスだ。時間単位の課金に対応し、ニフティ法人IDさえ持っていれば、即時利用可能だ。

KDDIの「クラウドサーバサービス」は、IaaSとPaaSの中間に分類できるサービスだ。よく利用されるサーバ（Web 3層、LAMPスタック、その他のミドルウェアやロードバランサなど）が仮想アプライアンスとして既に用意されており、ユーザは専用の管理アプリケーションを使ってドラッグ＆ドロップでシステム構成を自由に変更できる。月額課金ではあるが、自動プロビジョニング機能を備え、オンデマンド・セルフサービスを実現している。

[参考資料]
・日立情報システムズ Business Stage ROD
http://www.server-outsourcing.jp/os/services/resource/

・NTTデータ BizXaaS　インフラサービス

http://www.ps.nttdcloud.jp/service/platform/infra.html

・富士通 オンデマンド仮想システムサービス

http://pr.fujitsu.com/jp/news/2010/09/27.html

http://jp.fujitsu.com/solutions/cloud/paas-iaas/sop.html

・NEC RIARUBE

http://www.nec.co.jp/outsourcing/riacube/index.html

http://www.nec.co.jp/press/ja/0805/2601.html

・日本IBM マネージド・クラウド・コンピューティング・サービス

http://www-935.ibm.com/services/jp/index.wss/offerfamily/so/b1333005

・さくらインターネット VPS

http://vps.sakura.ad.jp/

・IDC Frontier NOAHプラットフォームサービス

http://www.idcf.jp/services/hosting/noah_p/platform.html

・IIJ GIOコンポーネントサービス

http://www.iij.ad.jp/GIO/service/component/

・伊藤忠テクノソリューションズ TechnoCUVIC

http://www.ctc-g.co.jp/solutions/dc/Solution/cloud_02.html

・ニフティ　ニフティクラウド

http://cloud.nifty.com/

・KDDI　クラウドサーバサービス

http://www.kddi.com/business/cloud/

２）米国
次に、米国のIaaS事業者を見てみよう。ここに紹介したIaaS事業者はすべて、自動プロビジョニング機能を備えており、NISTの定義に照らしてもクラウドと呼べるサービスを提供している。

事業者		Amazon Web Service	Rackspace	Terremark	SAVVIS	AT&T	IBM
サービス名称		EC2/S3	Rackspace Cloud	vCloud Express	Symphony VPDC	Cloud Services	Cloud *2
北川氏	仮想化	○ Xen, RHEV	○ VMware	○ VMware	○ VMware, RHEV	○ VMware	○ RHEV
	自動プロビジョニング	○	○	○	○	○	○
NIST	オンデマンド・セルフサービス	○	○	○	○	○	○
	広帯域のネットワークアクセス	○	○	○	○	○	○
	リソース・プール	○	○	○	○	○	○
	迅速な伸縮性	○	○	○	○	○	○
	測定されたサービス	○	○	○	○	○	○

*2: 提供開始日未定。

[参考資料]
・Amazon Web Service EC2/S3

http://aws.amazon.com/jp/ec2/

http://aws.amazon.com/jp/s3/

・Rackspace Rackspace Cloud

http://www.rackspacecloud.com/

・Terremark vCloud Express

http://vcloudexpress.terremark.com/

・SAVVIS Symphony VPDC

http://www.savvisknowscloud.com/

・AT&T Cloud Services

http://www.business.att.com/enterprise/online_campaign/cloud_computing/

・IBM Cloud Computing

http://www.ibm.com/ibm/cloud/

http://www.redhat.com/solutions/cloud/partners/

PaaS事業者
さて、PaaSにおいては、プラットフォーム以下が抽象化されるため、明確に「仮想化」や「自動プロビジョニング」の機能を備えていると謳われていないことが多い。そのため、PaaS事業者の比較においては、「仮想化や自動プロビジョニングの機能を備えていれば当然実現できるであろう尺度」を用いる。それは、ユーザがそのサービスを使うことを決定してから、実際に利用開始できるようになるまでの時間である。

１）日本国内
日本国内でPaaSを提供していると見受けられるのは、富士通、日立製作所の2社だけである。NECはPaaSを提供していない。そして、利用開始までの時間に注目いただきたい。各社とも「ご相談」になっている。

事業者	富士通	日立
サービス名称	SaaSアプリケーションプラットフォームサービス	Harmonious Cloud PaaS
利用開始までの時間	ご相談	ご相談

[参考資料]
・富士通　SaaSアプリケーションプラットフォームサービス

http://fenics.fujitsu.com/outsourcingservice/saas/appli-plat/

・日立製作所　Harmonious Cloud PaaS

http://www.hitachi.co.jp/products/it/harmonious/cloud/solution/paas.html

２）米国
米国でもPaaSを提供している事業者は限られている。高い技術力と優秀なソフトウェアエンジニアを多数抱える企業ばかりである。利用開始までの時間をご覧いただきたい。どこかの事業者で「ご相談」している間に、アプリケーションのデプロイが完了してしまう。一方、最もエンタープライズに普及しているアプリケーションプラットフォーム「JBoss」を抱えるRed Hatは、Microsoftのように自社でPaaSを提供する気配はない。おそらくIaaSを提供するデータセンタ事業者とパートナーを組んで対抗する構えだが、同じ戦略のVMwareに一歩も二歩も出遅れている。

事業者	Google	Salesforce.com	VMware & Salesforce.com	Microsoft
サービス名称	Google App Engine	Force.com	VMforce *3	Windows Azure
利用開始までの時間	即時	即時	即時	即時

*3: 2010年秋にデベロッパプレビュー版公開予定。

[参考資料]
・Google Google App Engine
http://code.google.com/intl/ja/appengine/

・Salesforce.com　Force.com

http://www.salesforce.com/platform/

・VMware & Salesforce.com VMforce
http://www.vmforce.com/

・Microsoft　Windows Azure

http://www.microsoft.com/windowsazure/windowsazure/

・Red Hat PaaS
http://www.jboss.com/solutions/PaaS/

まとめ

以上、「クラウドを名乗る条件」という視点から、日本国内および米国のクラウド事業者を調査、比較してきた。こうやって見てみると、IDCやForresterなどが公表している日本のクラウド市場規模の数字は、当てにならない気がしてくる。各事業者が、クラウドというキーワードでごちゃ混ぜにして数字を積み上げている可能性があるからだ。例えば、VMwareを使った顧客IT資産の仮想化統合のSE費やハードウェア費を「プライベートクラウド構築事業」としたり、あるいは従来のASPを「クラウド型サービス」や「SaaS」としたりして、国内クラウド市場規模の数字に組み込んでいるのではないだろうか。そうこうしているうちに、IaaSはともかく、PaaSも米国のサービス事業者にごっそり持って行かれる予感がしてならない。

なんでZIPじゃだめなの？メール添付ファイルの暗号化について

米国でも日本でも、おそらく他の国でも、「社外からメールなどで受信した実行形式のファイルは開いてはならない」という条文を企業のセキュリティポリシとして定めるのはとても一般的だ。ご存じの通り、この条文はウィルス感染予防を目的としている。

日本の企業は特に情報漏洩に過敏で、セキュリティポリシには「Winny使用禁止」「社有PC持ち出し禁止」などが明確に書かれているところも多い。さらに細かくセキュリティポリシの運用規則を定めているところもあり、その中に「メールにファイルを添付するときは、会社指定の暗号化ソフトで暗号化すること」というのがある。というか、僕の知る限りでは、日本の大企業ではそれが常識になっているはずだ。

実際にファイルを暗号化するときには、儀式があるのをご存じだろうか。通常、暗号化ソフトで暗号化されたファイルは、ファイルを受け取った人が復号化するときに手間がかからないように、「自己復号形式」や「自己解凍形式」と呼ばれるWindows実行形式ファイル（拡張子が exe など）になっていることが多い。ただし、前述のとおりウィルス感染予防のために、例えばMicrosofto Outlookのインストール時初期設定では、添付ファイルの拡張子がWindows実行形式の場合に警告を表示してファイルが開けないようになっている。そのため送信者は、自己復号化形式や自己解凍形式のファイルをメールに添付する際に、拡張子を変更（exe → ex_ など）して添付するなどして、受信者に拡張子を元に戻してもらって復号化するのが慣例になっている。

さて、これらを踏まえると、次のようなことが起こる。断っておくが、これから書くことにはものすごく現実味があっても、あくまで例。フィクションだ。決して実際に起こったことではないので、信じないように。そういうこともあるよね〜、あっはっは〜っと笑っていただきたい。

日本の某大企業A社から米国の某スタートアップ企業B社に関係者外秘の技術情報が入ったファイルをメールで送ることになった。A社の担当者がいつものようにファイルを暗号化してメールに添付したところ、いろいろあって、最終的にB社にファイルを送ることができなかった。どういうことか。

第一に、B社のセキュリティポリシに「社外からメールなどで受信した実行形式のファイルは開いてはならない」という条文があった。ちょっと意外かもしれないが、米国では、ことセキュリティポリシに関しては真面目に運用しているようだ。日本では「大企業だから大丈夫だろう」「いつもの取引先」「慣例になっている」など、なおざりになっているのではないか。穿った見方をすれば、日本では現場の判断で臨機応変に対処しなければならないぐらいにセキュリティポリシの運用規則がガチガチに書かれていて、真面目に運用すると業務がまわらないのではないか。まあこれは推測。

第二に、B社にはLinuxとMacしかなかった。最近は安いネットブックがあるから買ってくればいいし、仮想化ソフトを使ってLinuxやMacにWindowsをインストールすることもできる。ということでB社には悪いが、Windowsを用意してもらった。

第三に、英語版WindowsではA社指定の暗号化ソフトの自己復号がうまく機能しなかった。B社に用意してもらったWindowsは当然英語版。まさか日本語版でしか動かないとは。

そしてB社からは「パスワード付ZIPファイルで送ってもらえないか」と提案された。まあ当然だよね。それをなんとA社は拒否。A社のセキュリティポリシの運用規則には「メールにファイルを添付するときは、会社指定の暗号化ソフトで暗号化すること」という条文があるのだが、これが守られないことが多いため、最近この規則がメールシステム上で強制されるようになった。つまり、会社指定の暗号化ソフトで暗号化していないと、メールにファイルを添付しても、A社のメールシステムではじかれてしまって送信できないのだ。ははは。デッドロック。

まあこういうときは、役割上、間に入った人が日本語版Windowsで復号化してあげて、パスワード付ZIPにして送るしかないよね。

ところで、なんでZIPじゃだめなんだろう？正しく使えば、わりと解きにくい暗号化が可能なんだけどなぁ。

「非IT屋」が提供するクラウドサービス

今年2010年4月、Bank of AmericaがSaaSアプリケーションのマーケットプレイスの提供を始めた。Bank of Americaは銀行であり、いわゆる「IT屋」ではない。このような「非IT屋」が提供するSaaSやPaaSについて調べてみたので、3つほど例を紹介する。なお、彼らはこれらのサービスで直接利益を得る気はなく、顧客ロイヤリティ向上のためにサービスを提供しているようだ。

●Bank of Americaの「MyBusiness Center Solutions Store」
Bank of Americaは、今年2010年4月から「MyBusiness Center Solutions Store」と呼ばれるSaaSアプリケーションのマーケットプレイスを提供している。中身はSugerCRM、Google Apps、WordPress、Microsoft Hosted Exchangeなどの他社SaaSアプリの再販サイトで、直販に比べて特別な値引きなどはない。またこのマーケットプレイスを経由して他社SaaSと顧客との取引が成立したとしても、いわゆるアフィリエイト中間マージンなどを取らないため、Bank of Americaには金銭的な利益は全くない。ただしBank of Americaの顧客であれば各SaaSベンダと個別に契約をしなくても、ショッピングカートに入れて支払いを済ませれば、Bank of AmericaのオンラインバンキングのIDとパスワードを使って様々なSaaSアプリを利用することができる。顧客が便利になるため、Bank of Americaの顧客であることのロイヤリティが高まる、というわけだ。このアイデアはコンサルティング会社THINKstrategiesの提案で、システムはTHINKstrategiesのシステム開発パートナーRenovatrix SolutionsによってEtelosのPaaSを使って構築されたもの。なお、EtelosはSaaSアプリケーション開発のためのプラットフォームを提供するPaaSを開発・販売する中堅のソフトウェア開発の会社だ。
もともと2000年からBank of Americaは顧客向けに、会計管理のWebサービス（支払、融資、電信送金、購買など）を提供していた。これは当時スタートアップだったWeb系ソフト開発会社のAribaが構築したものだ。なおAribaは現在、企業向けSaaSアプリケーションプロバイダとして事業展開している。

[参考]
Bank of America Corporation - MyBusiness Center Solutions Store
http://www.mybusinesssolutionsstore.com/

THINKstrategies, LLC
http://www.thinkstrategies.com/

Etelos, Inc.
http://www.etelos.com/

Ariba, Inc.
http://www.ariba.com/

●米国公認会計士協会の「AICPA Store」
American Institute of Certified Public Accountants (AICPA; 米国公認会計士協会)は、現在約35万人の公認会計士が所属する巨大な組織だ。2009年4月、AICPAとその子会社CPA2Bizおよびオンライン会計アプリ開発のIntacctは、中小企業のための会計業務のパフォーマンス改善にクラウドコンピューティングを取り入れようと、公認会計士に特化したオンデマンド会計管理アプリおよび財務管理アプリの共同開発を行うことを発表した。AICPAはIntacctを推奨する会計アプリケーションプロバイダに指定し、同時にCPA2BizをIntacctの推奨販売店に指定。完成したSaaSアプリケーションは、「AICPA Store」と呼ばれるCPA2Bizの運営するWebマーケットプレイスで販売される。AICPAの会員になっている公認会計士は、AICPA Storeを通してIntacctの提供するSaaSアプリを会員特価で購入することができる。AICPAとCPA2Bizは販売中間マージンは受け取らず、このサービスによって直接利益を出すことは考えていない。公認会計士がAICPA会員であることのロイヤリティの向上が目的だ。一方Intacctも、AICPAおよびCPA2Bizの会計ベストプラクティスに関するノウハウを学ぶこと、および「AICPA公認アプリ」というお墨付きをもらうことを目的としている。

[参考]
AICPA - AICPA Store
http://www.cpa2biz.com/

Intacct, Inc.
http://www.intacct.com/

●FedExの「FedEx Web Services」
FedExは主にEコマースサイトの開発者向けに、無料で「FedEx Web Services」と呼ばれるPaaSを提供している。配送伝票の発行、トラッキング、送料計算、住所の実在確認、返品集荷手配、オンラインプリントなど、FedExのデータセンタでホスティングされているシステムの様々な機能が利用でき、公開されたWebサービスAPIを介して自由に自社開発のEコマースサイトなどに組み込むことができる。通常、中小企業のマーケティング部門が自社のEコマースサイトを立ち上げたところで、商品の配送は従来のままの仕組みを使うケースは多い。しかし受注、配送手配、到達確認や返品処理など、意外と煩雑な業務がそのまま残ってしまうことになる。顧客はFedEx Web Servicesを使えば、ほとんど追加投資をすることなく、それらの面倒な処理をほぼ自動でかたづけることが可能になる。FedExとしても既にあるものを公開しただけであり、ほとんど追加投資をすることなく顧客ロイヤリティを向上させ、競合のUSPSやUPSとの競争力を高めることができるのだ。なお、このFedEx Web Servicesを含め、FedExのシステムはほぼ全てが自社開発である。

[参考]
FedEx, Inc. - FedEx Web Service
http://www.fedex.com/us/webservices/index.html

ラーメン屋とクラウドコンピューティング

日本にはラーメンという優れた食文化があります。日本で最初にラーメンを食べたのは水戸黄門だ、とか、ラーメンの起源は明治時代に横浜や神戸の中華街で出てきた南京そばにある、とか諸説ありますが、いずれにせよ、最初のラーメンの麺は自家製で、手延べや手打ちだったそうです。そのうち繁盛してきて手打ちでは対応できなくなり、均一な麺の生産と効率化を求めて製麺機が登場しました。収益＝単価×客数。ラーメンひとすじで勝負するなら、単価は期待できませんので、客数を増やすしかありません。

さて、日本のIT業界を見てみると、ネットベンチャー、ソフトウェア開発、システムインテグレータ（SIer）など様々な業種業態がありますが、「収益＝単価×客数」でいえば「単価」が大きく「客数」が少ない商売が多かったのではないでしょうか。先日は内閣官房国家戦略室が、国民IDシステムの開発コストは6100億円、と発表していました。このようなプロジェクトが進められることになれば、入札を経てどこかの大手ITゼネコンがシステム開発を受注し、下請け、孫請け、又孫請け、などを含めて何千億円というシステム開発を、何年もかけてシコシコとやっていくことになります。その後、そのシステムの保守という名目で、年間何百億円がシステム運用を受託した会社に流れることになります。これまで、こうやってやってきたのです。まるで超高級フレンチレストラン、というよりオーダーメイドスーツやビスポークシューズの仕立屋さんでしょうか。

一方、クラウドコンピューティングの商売は、「単価」が小さく、「客数」が多い商売です。クラウドコンピューティングで供給されるサービスでは、まるで電気料金や携帯電話料金のように、サービスやリソースを使用した時間・回数・量に対していくら、という商売をやっています。例えば、今日現在、Amazon Web Service EC2のNorth VirginiaデータセンタにあるWindowsの一番小さい仮想マシンを1時間利用すると、$0.12かかります。日本円にして、約10円です。1万人が同時に使ったとしても、1時間でたったの10万円です。これって本当に儲かっているのでしょうか？ ある試算によると、Amazon Web Service EC2は、1時間に$25,000（約212万円）以上の売上があるとのこと。数字の信憑性はともかく、Amazon Web Service EC2というのは、「単価」がめちゃくちゃ小さくて、「客数」がとてつもなく多い商売だということはわかっていただけると思います。

ところで、儲かっているラーメン屋というのは、コモディティの原料で商品を完成させています。コモディティというのは、「十分に市場に浸透していて安定供給され、安価に入手できるもの」をいいます。そこらへんのスーパーとか量販店で売っているような、ごくフツーの材料を安価に仕入れて、神業で加工し、すばらしいラーメンに仕上げて、お客様の満足を得るのです。逆に「超高級ドコドコ産の肉」やら「入手困難なんたら珍味入りの麺」なんていうのを使っていると、安定した仕入れが難しかったり、加工が難しかったりと、客数を増やすことができずに儲けることは極端に難しくなります。

じゃあ、クラウドコンピューティングの原料ってなんでしょう？僕がまず思いつくのは、インターネットです。インターネットというのは、すごいおおざっぱに言うと、ネットワーク機器によってつながれたたくさんのデータセンタと膨大な数のPCの集まりです。データセンタの外には変電装置、冷却装置などがあって、データセンタの中には空調、電源制御、バッテリーなんかの基本設備とラックが並んでいます。最近では、コンテナ型のデータセンタもありますが、具はだいたい同じです。さらにラックの中には、サーバ、ネットワーク機器（スイッチ、ルータ、ファイアウォール、UTPケーブル、光ケーブル）、ストレージなんかが収まっている。他にもちろんソフトウェアも必要でしょう。そういうのを想像します。今まではこれらのものは、そのへんの量販店で売っているものではなかったと思います。でもこれからは、こんなのが具になるんじゃないかと思っています。




まあさすがに全部画面がついててもアレなんで、形としてはこんなのかもしれません。




学生時代を思い出しますね！

そんなことを言っても、客数はせいぜい60億人ぐらいが限界じゃないか、という人もいるかも知れません。クラウドコンピューティングの客は、人だけじゃないんです。一番大きな客は、たぶんセンサーだと思います。この分野は、センサーネットワーク（Sensor Network）やモノのインターネット（Internet of Things; IoT）などと呼ばれています。中国の无锡（WuXi）という街では、センサーネットワークというキーワードで集まった企業集団が、着々と研究を進めているそうです。

もしご興味があれば。
http://www.nacsa.com/archives/files/wuxi_event_20100526.pdf

あーやばい、一風堂のラーメンが食べたい。白丸バリカタで。

最近のGoogleの動きとGoogle I/O

最近のGoogleの動きとGoogle I/Oに関してまとめておく。

●Googleも企業BIを狙っている
GoogleのベータサービスであるLabsに、MapReduceホスティング的サービス「BigQuery」が登場。これまでデータウェアハウスがやってきた分野をHadoopディベロパがかっさらおうとしている最中、MapReduceの本家がそのホスティングサービスを開始すると言っているように聞こえる。ユーザはGoogle Storage for Developers経由で巨大なデータを転送し、SQLライクな命令でBigQueryに処理を委託できる。

http://googlecode.blogspot.com/2010/05/bigquery-and-prediction-api-get-more.html

またGoogle App Engine上でMapReduceを実現するオープンソースプロジェクト「appengine-mapreduce」も動き出した。前述のBigQueryは中身が隠蔽されているため、MapReduceで処理しているかどうかは不明だが、appengine-mapreduceはMapReduceのオープンソース版と言っていい。

http://code.google.com/p/appengine-mapreduce/

現在はPythonのみ、しかもMapperの試験実装だけが公開されているが、今後はJava版の開発も行っていく模様だ。

●Google I/O 2010でのいくつかの重要な発表
2010年5月19日から2日間、Googleによるディベロパ向けの年次イベント「Google I/O」がMoscone Center (San Francisco, CA)で開催され、5,000人以上のディベロパが参加した。「I/O」はディベロパがコーディングをするときに最初に考えるものである入出力を表すと同時に、Webやコラボレーションを使ったオープンな中でのイノベーション（Innovation in the Open）という願いがこめられているとのこと。参加には$2,000以上必要だが、チケットはほぼ即日完売の人気ぶり。今年はキーノートの様子がYouTubeでリアルタイム中継されており、Twitterでは視聴者が秒刻みでキーノートの様子を逐次アップしていく様子を見ることができた。リアルタイム中継の視聴者の数は24,000人であった。キーノートの様子はそのままYouTubeにオンデマンドストリーミングとしてアップロードされており、現在も観ることができる。

http://code.google.com/intl/ja-JP/events/io/2010/

・HTML5向けWebアプリケーション開発が本格始動

(Internet Explorer以外がHTML5をサポートしているグラフを示しながら)すべてのモダンなブラウザがHTML5をサポートしていると言い放って観衆から拍手喝采を受けると、今後はHTML5がWebを支える重要な技術でありGoogleはディベロパが簡単にHTML5の技術の恩恵を受けられるようにAPI開発を行っていく、と本腰でHTML5をやっていく姿勢を示した。
・ビデオコーデック「VP8」のオープンソース化
今年Googleはビデオコーデック技術の会社であるOn2 Technologiesを$2Bで買収しているが、Googleはその「VP8」と呼ばれるビデオコーデックをオープンソースにすることを発表した。そしてオープンソースの音声フォーマットOgg Vorbisと合わせてオープンで高品質なWebメディアを開発するプロジェクト「WebM」を立ち上げることを発表した。

WebMプロジェクトには、Mozilla、Adobe、Opera、Skypeなどのソフト系ベンダだけでなく、AMD、ARM、NVIDIA、Qualcommなどのチップ系ベンダなど38社が参画している。なお、YouTubeにアップされているこのキーノートのビデオも、早速WebMを使って制作されていた。つまり、Adobe Flashで既にWebMをサポートしていることがわかる。また既存のYouTube動画のURL末尾に「&webm=1」を追加すると、実験的ではあるが、WebM版の動画リストが表示されるようになっている。もちろん再生するには「モダンなブラウザ」が必須である。


・Chrome Web Store
Webアプリが増えるに従い、ユーザが目的のアプリケーションを見つけるのが難しくなってきた。またディベロパはアプリを配布する環境を整え、マネタイズの方法を考え効果的に宣伝し、ユーザからのフィードバックを得る、というのは簡単ではない状況にある。そこでGoogleはWebアプリのマーケットプレイスを開発中であることを発表。いってみれば、Google版のApp Exchangeであり、iTunes App Storeである。面白いのは、C++などのネイティブコードで書かれたアプリも扱えること。つまりWebブラウザで高速に動作する3Dゲームを楽しむこともできる。日本語を含む40以上の言語を対象に開発を進めており、2010年の秋ごろに公開を予定している。

・VMwareとの協業によるJavaアプリのクラウドポーティング
なんとVMwareのPaul Maritzが登場。そしてGoogleとVMwareがJavaアプリのクラウドポーティングに関する協業について発表。


SpringSourceの持つJavaフレームワークSpringをバックエンドにして、Google Web Toolkit(GWT)のリッチなUIとつなげ、Javaアプリの開発を容易にした。つまりvCloudにSpringフレームワークを乗せただけでなく、なんとGoogle App EngineにもSpringフレームワークを乗せてしまったのだ。




デモではわずか200キーストロークだけで経費精算レポートシステムを構築、時間にすると解説も入れてわずか2分。信じられない方は是非YouTubeをご覧いただきたい（デモは1:30:00頃）。もちろん、開発したアプリはクリックひとつでGoogle App Engineにデプロイ可能。またGWT 2.1 Widget Libraryを使うとそのままiPhone/iPadやAndroidなどのモバイルでも同じWebアプリケーションが利用できる。次のデモでは、さきほど2分で構築した経費精算レポートシステムを使って、Nexus Oneから3Gネットワーク経由で夕食接待費の精算申請を入力し（左側）、上司がそれをWiFi経由のiPadで承認してみせた（右側）。

・ビジネス向けGoogle App Engine
ビジネス向けのGoogle App Engineを発表。これは通常のGoogle App Engineにビジネス向けの機能を追加したものだが、注目すべきはSQLデータベースの提供だろう。これまではGoogle App Engine上のアプリがデータを永続化するには、BigTableと呼ばれる列指向DBMSに特殊なAPIを通してアクセスする必要があり、これまでのRDBMSを前提に構築されたアプリを乗せるのは容易ではなかった。SQLがサポートされることで、一番大きな敷居が取り除かれることは確実だろう。事実、会場にいるディベロパからは拍手が起こった。
気になる料金は、ユーザあたり$8/月とリーズナブル。１つのアプリケーションで最大$1,000/月まで課金し、それ以上は使い放題になる。SNSなどの非業務系アプリから試してみてはいかがだろう。顧客に提案する際のインフラの選択肢のひとつとしても使えるだろう。

まっさらな会社が新しい社内システムを作る場合にはとても魅力的だが、既存のシステムを持つ会社がこれに移行するには、移行期間に並行運用が可能となるような仕組み（認証基盤、データのツナギなど）が提供されなければならない。もちろん、明日あたり、これらの機能が実装されたGoogle Appsが前述のChrome Web Storeにアップされているのかもしれない。

・Android 2.2
1人の独裁者、1つの企業、1つのデバイス、1つのキャリアからもたらされるのは1つの選択肢しかない、こんな未来はいらない、とバッサリ。明らかにAppleを指して言っている。一方GoogleのAndroidは21のハードウェア企業にOEM提供し、世界　48カ国の59のキャリアで動作する。

そのAndroidの新バージョンである2.2（コードネーム"Froyo"）が発表された。パフォーマンス向上、企業向けの機能強化、アプリケーションのクラウドバックアップ、クラウドからのPUSH型メッセージングAPI、Webアプリケーションからのカメラ/GPSなどのデバイスへのアクセス方法の提供、音声検索など。メッセージングAPIはちょっと面白い。PCからクラウド経由でAndroidデバイスにメッセージを送信できる。例えばPC上のGoogleマップで検索したナビゲーション情報を送ると、AndroidデバイスではGoogleマップが自動的に開かれナビゲーション情報を表示する。



・Google TV
Webとテレビを融合するソフトウェアプラットフォーム「Google TV」を発表。Android 2.1ベースでChromeブラウザとFlashがついている。そのため、モバイルで観ていたYouTubeの動画をTVに送信して家族でシェアして観たり、Android Marketからアプリをダウンロードして走らせたり、Flashゲームを楽しんだりできる。デモではドラマのクローズドキャプション（字幕）をGoogle Translateを使ってリアルタイム翻訳して表示させていた。Google TVを使う方法は次の3つ。Sonyから発売予定のGoogle TV対応テレビ、Logitechから発売予定のセットボックス、サテライトボックス。いずれも2010年秋に発売を予定している。

アメリカの名刺と肩書き

このあいだ、年度末の名刺整理をしていたところ、アメリカに来てからいただいた名刺が公私合わせて300枚になっていることに気づきました。昨年の5月にアメリカに来たことを考えると、1日に1人、新しい人に会っている計算になります。凄いように聞こえて、実は半分はエキスポなどのイベント事で交換したものなんですけどね。そこで、名刺を並べていて気づいたのですが、どうもアメリカの名刺のほうが日本の名刺よりもひとまわり小さく作られているようです。こちらで買ったクリアケースに日本の名刺だけがうまく収まりません。もっとも、最近は丸いものや言葉では表現できないものなど、デザインが凝っている名刺がありますので、クリアケースに収めようとすること自体がいいアイデアではなかったようです。


さてこのアメリカの名刺、日本と違うのはは大きさだけではないようです。僕の手元にある日本の名刺は、アメリカにある日系企業の駐在員や、日本から出張でいらした方の名刺などですが、明らかに文字数が違います。半分ぐらいは片面が日本語になっている名刺なので、「日本語訳」を見ることができます。どうも部署名や肩書きが長いため、文字数が多く見えるようです。そこから想像するに、これは翻訳の問題だけではなくて、おそらくこれは日米の企業文化や組織構造の違いにも関係がありそうです。気がつくところを挙げてみます。


1) 部署名が長い
アメリカの名刺は、部署名は1行、長くても単語6〜7個が普通のようです。5人未満のスタートアップ企業でも、数万人規模の大企業でも同じです。日本の会社は大きい会社になるほど部署名が長くなりますので、日本語にしてみるとこんなもんかと思うのですが、アメリカのものと比べると奇妙なぐらいに部署名が長いです。それだけで複雑で動きが重い印象を感じます。しかも、ひどいのはそのままエキサイト翻訳に突っ込んだんじゃないかという残念な名刺もあります。


2) 職種が曖昧
アメリカでは、特に名刺の上では、職種を明確に記載することがほとんどです。後で連絡をする時、誰に連絡をすべきかをすぐに判断できるようになっています。例えば「○×ソフトのセキュリティ機能について仕様を訊きたい」と思ったら、Product SalesやProgramming StaffやDatacenter Architectではなくて、Software Architectにメールを送ればいいのです。一方、日本の名刺は、部署名とは正反対にシンプルです。Engineer、Manager、Director、Salesなど。これは日本の組織構造を想像しながら部署名と合わせて類推できないと、実際に何をしている人かを当てるのは難しいでしょう。


3) 役職（職位）もおかしい
前述の職種にもつながるのですが、アメリカは日本の企業のように縦の深さがないので、組織構造のツリーを翻訳するときにうまく対応づけられないのかもしれません。例えば、Managerが設計をすることがあるとアメリカ人が知ったら驚くと思います。それから、肩書きがないのがあったりします。きっと日本でいう「担当」なんでしょうが、肩書きがない人＝ポジションが与えられていない人です。


今までの僕の経験からみると、アメリカの肩書きは次のようになっているようです。

社長	President、Chief Executive Officer
役員クラス	Chief xxx Officer、Executive Vice President、Senior Vice President
本部長クラス	Vice President
部長クラス	General Manager、 Senior Account Executive
課長クラス	Sales Director、Account Director、Chief Software Architect、 Chief Network Architect、Chief Consultant
主任クラス	Administrative Supervisor、Sales Manager、Account Manager、Product Manager、Software Architect、Network Architect、Enterprise Architect、Senior Consultant
担当クラス	Product Sales、Solution Sales、Sales Engineer、Software Engineer、Network Engineer、IT Consultant
新人	Assistant Engineer、Sales Assistant、Assistant Manager、Administrative Assistant、Staff

そこで提案です。英語の名刺（裏面）は、直訳はやめて、英語圏の文化に合わせて印刷してはどうでしょう？例えば、こんな感じです。

[変更前]

Taro Nippon Manager 1st Section Security Software Development Group Software Development Office Research & Development Division

↓
[変更後]

Taro Nippon Chief Software Architect R&D Security Software Group

もちろん僕は日本以外ではアメリカの企業しか見たことがありませんので、ヨーロッパはまた違うのかもしれません。もしそうであっても、ヨーロッパの取引先が多い方はその文化に合わせて別の名刺を作れば良いと思うのです。この話はうちの会社の名刺も該当しますが、日本から出張して来る他社の方の名刺も同じようになっていますので、もしかしたら名刺屋さんがそういう提案をしているのかもしれませんし、それともどこかに暗黙の規格があって、みんなそれに従っているだけなのかもしれません。まあいろいろ事情があるにせよ、名刺を渡したのにも関わらず「あなたは会社で何をやってるのですか？」と訊かれるのはおかしいと思いませんか？

"Never Eat Alone (独りで食べるな)"という、ビジネスの格言があるそうです。これは「食事は大事なコミュニケーションツールなのに、食事する回数は一生で限られている。独りで食事をすると人脈を作る大切な機会を失ってしまう。」ということを言っています。もちろん僕はエンジニアですから外回りばかりやってるわけにはいきませんが、せめて週に1度は新しい人に出会ってランチに誘いたいと思っています。そのときには、できればわかりやすい名刺を渡したいですね（笑）。来年度は"Never Eat Alone"でがんばります。

日本唯一のツルハシ屋が廃業

シリコンバレーとは全く関係ないですが（苦笑）。

日本で唯一ツルハシを作っていた鍛冶屋、外川産業が廃業することになったそうです。

http://www.mmjp.or.jp/soto/soto/Haigyou.html

直接の原因は不況下の業績悪化や需要の低下ではなく、姫路市による姫路駅周辺区画整理のために追い出されることになったが、移転先が見つからなかったためとのこと。外川産業はツルハシだけではなく、鉄道工事器具や自衛隊が使うバールなども製造していました。これからは日本の鉄道と自衛隊も、日本なら100円均一でも投げ売りしそうな某国製造の「安かろう悪かろう」的なToolを使って仕事をすることになります。

それでも、当社の今までの得意先にご迷惑をおかけするに当たり、中国本土で数社協力工場を探しましたが、残念ながら製造能力、規模、価格は十二分に満足するのですが、どうしても当社の希望する形状、製品には程遠く困難を極めております。残された時間はなく、とりあえず製造して輸入はしてまいりましたがこのままでは、従来の「やま外」マークを刻印して当社の製品として販売する自信が無く苦慮しているところです。

昨今、高品質というのは、日本の中であっても、商売文句にならなくなっているのではないかと感じています。確かに「こだわり」というのは、度を過ぎるとビジネスになりません。しかしグローバルで勝負をすることと、こだわりを捨てることとは同義ではないと思うのです。

効果的な会議を効率よく行うための6つの法則

自分用メモ。Business Weekの記事より。

http://www.businessweek.com/smallbiz/content/sep2006/sb20060927_259688.htm

■効果的な会議を効率よく行うための6つの法則

1. しっかりしたアジェンダを作成する

2. 議事録係を割り当てる

　（しかもその議事録を常にプロジェクターで投影する）

3. 会議を小分け（5〜10分）にする

4. オフィスアワーを作る

5. 「政治」ではなくデータで判断する

6. 時間を守る

　（これもでかくプロジェクターで常時投影する）

86円台

これはやばいね。デフレから抜けられんぞ。

講談社の漫画雑誌「モーニング・ツー」がWebに漫画を公開して売り上げアップしたらしい

シリコンバレーとは全く関係ないのですが、気になったので。

講談社は、月刊漫画雑誌「モーニング・ツー」の10月22日発売号を前号の51％引き・190円で販売する。浮いた宣伝費を読者に還元するという。

http://www.itmedia.co.jp/news/articles/0910/21/news054.html

講談社が某漫画雑誌のコンテンツを無料でWebに公開して、紙媒体の雑誌も継続して販売。ただし紙媒体の雑誌には特典（紙媒体にしかない情報や付録など）をつけたそうです。そうしたら売り上げがアップしたとのこと。

最後の「売り上げがアップした」ところは物珍しさなどの特別な顧客心理もからんでいるのであんまり興味はないのですが、前半部分は僕の視点から見ると結構おもしろい話で、アナログな世界をWebサービス化するやり方の実演に見えます。通常、雑誌の顧客（＝読者）は雑誌の中に書かれている情報に対する対価としてお金を払っています。特に漫画雑誌のように、その媒体に対するこだわりが薄いと考えられるような場合には、もしかしたら何らかの差別化要因が見つけられれば、うまく商売ができるかもしれない、ということを言っています。

僕は日本にいた頃、毎週欠かさず集英社の少年ジャンプを買って読んでいました。でもこちらに来てからは、(1)入荷が1週間遅い、(2)高価である、(3)入手できる書店まで行くのが億劫である、などが理由で、全く読んでいません。もしインターネットを経由して、日本と同じ値段で少年ジャンプが読めるのであれば、紙媒体の雑誌と同じ金額なら払ってもいいと思っています。出版社もインターネットを使って商売ができるようになるといいですね。

さて一方で、先日、北米毎日新聞（発行部数＝約7,500部）が休刊を発表しました。インターネットやフリーペーパーの普及による購買読者減少などが理由とのことです。最近はGoogle Newsにマッシュアップされた日本の各新聞社の記事などがあり、地理的な不便もなく無料で閲覧できるようになりました。

こういう、ITとは違う分野からITの技術革新が生まれるのかもしれません。