親として情けない限りである。
2009年7月14日
あっぱれ!マイク
親として情けない限りである。
2009年7月12日
日本型クラウドの可能性(4)
2009年7月8日
日本型クラウドの可能性(3)
ちょっと、言い訳をしておこう。
もう10年以上前の話である。半導体メーカーのお客様をIBMの半導体工場であるニューヨーク州イーストフィッシュキルへお連れしたときの話。
この工場は、最先端の8インチ・ウェハーを世界に先駆けて稼動させたところでもある。その後、このノウハウは、日本の野洲工場に移転され、日本でも8インチのラインが動き始めていた。
私たちが訪問すると日本からの出向社員が、工場を案内してくれた。当時、この工場には、彼を含め野洲工場から派遣された多くの日本人のエンジニアが働いていた。彼らの目的は、歩留まり率の向上だった。
いち早く8インチ・ラインを立ち上げたのは、米国であったが、歩留まりが上がらないことに手を焼いていた。そんな米国に続いて立ち上げた日本の野洲工場は、米国で開発された最新の半導体製造技術をベースにしつつも、日本独自の工程管理のノウハウを組み込んで、本家をしのぐ歩留まりや生産性を実現していたのである。
そこを見込まれて、本家の支援にやってきていたのだ。
また、こんなこともあった。
IBMを卒業の後、ある外資系の半導体製造装置メーカーのマーケティングと営業を手伝ったときのこと。このメーカーの製品は、欧米のエンジニアが設計し、中国と香港で製造していた。
中国・深センにある工場に行って驚いたのは、ずらりと並ぶ最新鋭の生産設備。アマダのマシニング・センター、イスラエル製のプラスチック成型機械・・・どれもコンピューター化され、工作精度はきわめて高い。
あるとき、この工場に部品を納めている日本企業のエンジニアに話を聞く機会があった。彼によると、この工場は、通常より一桁高い公差で部品を納めるように求めているらしい。そのため、コスト的に相当きついとのこと。
当然出来上がってくる製品の精度は高いものと期待されるが、意外にも普通なのである。仕様の上では、世界最高であっても、実用性能は、それほどでもなかった。
こんな装置を輸入して、日本のお客様にお納めするのだが、これを日本のエンジニアが、出荷前に徹底的に整備、調整すると、実におどろろくべき性能を発揮する。
欧米の優れた設計思想とユニークなアイデアの数々。部品や加工精度の高さ。実に素性がいい。これを正しくくみ上げ、調整すれば、そのポテンシャルを最高に引き出すことができるのは、当然といえるかもしれない。
「どうすれば、そんな性能が出るのか?」と開発や製造の人間が、聞きにくるほどであった。
ユニークなアイデア、それにチャレンジし、リスクを犯してでも試してみようという行動力は、欧米諸国の伝統といえるかもしれない。一方、いいと思ったなら一意専心に改良を重ね、完成度を高め、百花斉放のこどく、その本領を発揮させることに、日本人は長けているように思う。
さて、話を「メインフレーム」に戻すが、「メインフレーム」は、確かに欧米の優れた着想と思想に支えられた製品であり、外国で作られた製品である。しかし、その能力は、機械本来の性能だけではなく、高度な運用管理能力無くして、最高のパフォーマンスを引き出すことがてきないのは言うまでも無い。
あるコールセンターのコンサルタントから聞いた話だが、「日本の顧客ほど、応対の品質にうるさい客はいない」そうだ。当然、コールセンターもお客様の満足度を高めるために、徹底した工夫と教育を怠らない。そんな積み上げが、世界でも最高の応対品質を実現しているという。
このような顧客の高い要求に応えなければならないという、強迫観念にも似たプレッシャーは、チャレンジを避け、ユニークなことを排除するというネガティブな一面はある。しかし、その一方で、徹底して品質や完成度を高めなければならないという、モチベーションを生み出していることは確かだろう。
「メインフレーム」は、IBM、「NGN」も使われている機器の多くは、CISCOなどの外国製品も多いと聞く。その意味では、純粋な国産ととはいえない。しかし、そんなことはあまり意味が無い。
私が、日本型クラウドと申し上げているのは、単に機械のことではない。高い品質を求め、徹底して運用の品質や完成度を高めたサービスを提供することに、日本人は、執拗なまでにこだわるところがあるからだ。これは、家電製品同様、世界でも十分に受け入れられるのではないかと思っている。
2009年7月6日
日本型クラウドの可能性(2)
まず、ひとつは、PCサーバーの信頼性。昔に比べて、PCサーバーの信頼性は、高まったとはいえ、銀行の勘定系に使えるレベルには無い。だから、可用性を高めるためには、冗長度を高めなければならない。しかし、冗長度を高めれば高めるほど、今度は、運用管理が複雑となり、システム全体を見たときの信頼性は、再び低下する。
PCサーバーの魅力は、取得金額(TCA:Total Cost of Acquisition)が安いことにあるが、それは同時に信頼性もその金額に見合うものという現実をうけいれることでもある。それでは困るということで、冗長度を高めれば、今度は、TCO負担が増大する。結局は、どこかでこの両者に折り合いをつけなければならない。
二つ目は、ミドルウェアの組み合わせ。たとえば、クラウド環境を構築する上で欠かせないのが、仮想化だ。これには、サーバーの仮想化やストレージの仮想化がある。また、分散ファイル管理機能も必要だ。さらには、負荷配分のための機能も必要になる。このように、クラウド環境を実現するためには、さまざまなミドルウェアが介在する。
これらミドルウェアを単体で取り出せば、夫々に責任の所在も明確であるだろうし、各社完成度を高めるための努力は行われている。しかし、いったいそれらシステムの組合わせについては、誰が責任をもってくれるのであろうか。
結局は、運用事業者の責任となるのだが、彼らにも、全体の信頼性を保証できる根拠が無い。従って、ユーザーにクレームされれば、「ネットワークの障害です」、「相性の問題です」、「仕様なので仕方がありません」という言い訳で、乗り切るしかない。
最後は、ネットワークの信頼性だ。いうまでも無く、インターネットにQOSを求めることには無理がある。セキュリティ上の課題も存在する。従って、たとえデータセンター・システムの可用性を高めたとしても、ネットワークが、ボトルネックとなることは、さけられない。
PCサーバー、ミドルウェア、ネットワークが、夫々に持つ信頼性と可用性についての限界。それらが、組み合わさることで、さらにシステム全体として、信頼性と可用性は、低下せざるを得ない。というか、そもそも、だれが保証してくれるのかという、責任の所在、つまり、トータル・クオリティ・マネージメントが、できない状況の下で、提供されているのが、現在のクラウド・コンピューティング(厳密に申し上げれば、パブリック・クラウド)の現実だ。
このような現実であっても、99.9%や99.95%を保証するというわけであるから、これは相当の努力であり、技術力だと思うべきかも知れない。しかし、ユーザーにとっては、彼らがどのような努力をしていようとも、結果として、求める可用性が提供されなければ、基幹系、勘定系ではつかえない。
そこでであるが、品質や信頼性に、過剰なまでに神経質な我が国民気質が、このクラウドに新しい可能性を提供してくれるのではないかと密かに期待している。「高信頼性クラウド・コンピューティング・サービス」という切り口だ。ノーダウン、QOS、低コストのクラウド・サービスである。
どうやって、これを実現するかといえば、「メインフレーム」と「NGN」の組合わせだ。
何をいまさら、メインフレームと言われるかもしれないが、メインフレームは、ここ数年劇的に進化している。自分が、元IBMの営業だからというわけではない。最近、改めてメインフレームを勉強しなおし、それを実感した。
残念ながら、メインフレームにまともに開発投資し続けているメーカーは、IBMだけである。その予算は、年間1000億円を超えるという。その集大成が、System/z。
たとえば、一台のPCサーバーに仮想化ミドルを導入し、いったい何台の仮想マシンを動かすことができるだろうか。まず、10台を動かすことは無理だろう。現実的な運用を考えれば、数台がいいところだ。しかし、メインフレームならば、比較的小規模なモデルであっても、簡単に数十台、規模が大きくなれば、数百台、数千台は問題なく稼動する。
これは、単にプロセッサー能力の問題ではない。基本機能として持っている高度な負荷管理機能、入出力の負担を専門で請け負うプロセッサーであるチャネルの存在。ハードウェア・レベルで仮想化を実現するLPARなどなど。昔から、高価なメインフレームというシステム資源を、できるだけ多くのユーザーに同時に使ってもらうための研究開発の蓄積が、今大いに生かされている。
限られたシステム資源をできるだけ多くのユーザーにサービス・レベルを保証しながら、しかもノンストップで利用させる技術。これに、半導体やストレージの価格性能比の向上が組み合わさって、「高価なメインフレーム」の汚名を返上しつつあるようだ。
「ソリューション営業塾」で、メインフレームについて話したときの資料を以下に掲載する。

また、System/zは、ネイティブで、Linuxが稼動する。もちろん、複数の仮想マシンの上で多重に稼動するのである。IBMの資料によれば、40万人で3900台のLinuxサーバーを使っているのだが、これを30台のメインフレームに集約しようというプロジェクトが進んでいるそうだ。これによって、TCOは、90%削減される。
メインフレームは、ハードウェアからOS、ミドルウェアまで、すべてIBM一社が、その組合わせに責任を持っている。全体の責任の所在が明らかであり、全体で相互の稼動を保証し、最適化されている。
そもそも、メインフレームは、その設計思想上、ノンストップである。故障しても稼働中に修理し、復旧できるように作られている。PCサーバーでよく行われる「リブート」などという、ごまかし操作はありえない。そのプラットフォーム上で動くLinuxシステムの可用性もまた、同じレベルが保証される。
ひとつのシステムあたりの多重度が高まれば、システムの運用管理負担も低減し、信頼性も高まる。その結果、ユーザーあたりのTCOも低下する。
System/z同様に、IBM/i(旧AS/400)も同様の思想の上に作られている。ネイティブOSに加え、Linuxも動くし、Windowsも、同時多重で稼動する。これであれば、比較的規模の小さな事業者でもサービス環境を構築可能であろう。
さらに、わが国が誇る高信頼性のIPネットワークであるNGNサービスを組合せば、AmazonやGoogleとは、異なる「高信頼性クラウド・コンピューティング・サービス」を実現できるのではないだろうか。
別に、IBM製品を売り込みたいわけでもなければ、NTTさんの回し者ではない。あくまで、客観的な視点で考えてみた結果だ。
この両者の組合わせは、クラウドの弱点を克服し、しかも日本人の感性にも符合するのではないか。
日本発世界に向けたクラウド・サービスのひとつの可能性として、考えてみてもいいのではないかと思う。
2009年7月3日
日本型クラウドの可能性(1)
クラウドが、ビジネスになるのかという議論は、もはや意味がないと思う。Google、Amazonを見れば分かるとおり、すでに立派にビジネスとして成り立っている。
SaaS(Software as a Service)型クラウドの代表であるGoogle Appsは、GmailやDocsなど、パーソナル・プライベート・ツール(PPT)のクラウド化をターゲットとしている。これは、Microsoftのビジネスと完全にかぶっている。では、どちらが、お得なのか。
私が主催している「ソリューション営業塾」で、クラウド・コンピューティングの講義を行ったとき、Googleの有償サービスである、Google Apps Premier EditionとMicrosoft Office Enterprise 2007を比較した資料である。
これを見ると、Google Appsの年間コストは、Microsoft Officeの1/2であることがわかる。ただし、MS Officeの場合は、これ以外にも導入やアップデート、トラブル(MS OfficeかPCかどちらが原因かわからない場合も含めて)対応しなければならないので、さらにコストがかかることになる。
同一機能ではないので、単純に比較することもにも無理はある。しかし、日本ほど、見た目やブランドにこだわらない米国では、ユーザーがどんどん増えているらしい。
Amazonのクラウドは、システムのインフラを提供し、アプリケーションは、どうぞご自由にお作りくださいというビジネス・モデルだ。IaaS(Infrastructure as a Service)型クラウドといわれるものである。表現を変えれば、データセンターのデスクトップ化、つまり、個人でも、中小企業でも、設備の導入や運用管理を伴わず、データセンター・リソースを必要なだけ従量課金でお使いくださいというものだ。
例えば、いままでなら、ウエブ・ビジネスをはじめようとすれば、自分のところに置くか、データセンターに預けるかは別にして、相応のシステムを所有しなければならなかった。当然、システム構築にもコストがかかる。それがなくなる。そのため、中小企業でも、少ない投資リスクでウエブ・ビジネスをはじめられるようになった。
やはり、「ソリューション営業塾」で使った資料であるが、オンプレミス型(自身でシステムを所有し、運用管理するシステム利用形態)とクラウド型でのシステム開発形態の違いを整理したものである。
Amazonのクラウドサービスは、このような中小企業の需要に支えられて、これまた急激にユーザー数を伸ばしているらしい。
ただ、これらクラウド・サービスも、稼働率という点では、まだまだたよりない。Googleは、Google Appsの稼働率を99.9%としている。これは、年間でおよそ8時間停止することを意味している。ただし、メンテナンスなど、事前に計画され、通知されるシステム・ダウンについては、含まれていない。
また、Amazonは、その中核となるサービスEC2の稼動率を99.95%としている。これとて、年間4時間の停止である。
これに加えて、パブリックなネットワークを利用するとなると、その稼働率や信頼性も考慮しなければならないので、実質的な稼働率は、もっと低下すると考えるべきだろう。
一般的に、大手銀行などの場合は、稼働率は限りなく100%である。具体的には、99.9999%の保証が求められる。これは、年間30秒程度の計算になる。
ここまでの稼働率は、ともかくとしても、小数点以下一桁や二桁程度では、基幹業務で使うには、心もとない。しかし、PPTやエンターティメント系のウエブ・アプリケーションであれば、問題ないレベルといえるかもしれない。
稼働率については、両者とも重要な課題として取り組んでいるようなので、このあたりは、いずれ改善されるだろう。しかし、そんな先のことを考えなくても、使える業務領域は、いくらでもあるように思う。
また、そもそも、中小企業であれば、基幹系とて、99.9%の稼働率さえ維持できていないところも少なくない。そんな現実を考えれば、「基幹系でも使えるところがある」と考えていいのではないだろうか。
しかし、これは、GoogleやAmazonだからできることであって、わが国で同じ様なサービスを提供できるのだろうかと考えると、簡単なことではない。
では、どうすればいいのだろうか?次回、その点について、もう少し掘り下げてみようと思う。
■ ソリューション営業プロフェッショナル養成講座 ■
どうすれば、新しいビジネスを立ち上げられるのだろうかを、考えてみませんか?
7月10日(木)、11日(金) 東京・茅場町
7月16日(木)、17日(金) 沖縄・ITOP
-------------------------------------------------------
こんな仕事をしています。
よろしければ、弊社ホームページをごらんください。
-------------------------------------------------------

