2009年10月8日に行われた日本Javaユーザー会によるクロスコミュニティカンファレンス2009 Fallで講演した「クラウドを超えた先の企業システム像」の資料です。資料はSildeShareのページから[↓Get File]を押すとダウンロードできます。
今回は「僕自身が、クラウドのどこを見て、何を感じて、企業システムに対して何を考えたか」というのを忠実にトレースしてみました。なのでクラウドや企業システムそのものについて結論めいたことは言って無くて、ITアーキテクトとしての態度はどうあるべきか、みたいな話で終わっています。
軽く内容を。
クラウドで僕が注目したのは3つ。規模の経済性、超大規模、オープンなプラットフォーム。
規模の経済性。ニコラス・G・カーが書いた「クラウド化する世界」の話。電気のユーティリティビジネスが成功した理由は規模の経済性。巨大な中央発電所は技術がなければ作れませんが、経済合理性があったからこそ推進されました。価格が安いこともありますが、資産（BS）が経費（PL）になるというのも大きい。同じようなことがITCサービスに対しても起こりうる。
超大規模。Twitterは2009年9月23日に4,294,967,295（32bit符号無し整数型の最大値）を超えて成長中。秒間350-380ポスト。数千万人といわれるユーザーに配ることを考えると、その桁違いの処理を裁く必要があるはずです。ICTサービスで規模の経済性を実現したければ、超大規模データセンターにコンピューティングリソースを集中して、どれだけ多くの人に同じものを届けられるかというのが重要になります。
オープンなプラットフォーム。「同じモノを届ける」と書きましたが、ICTサービスは電力と違ってユーティリティ性が低いです。電気は使う側でカタチを決められますが、サービスはサーバでカタチが規定されます。そこに多様性を持ち込むのがオープンなプラットフォームです。Amazon のコミュニティAMI、Force.comのApp Exchange、FacebookのPlatformなどなど。
プラットフォームが多様性を受け入れることで単一性/同一性の意味が拡大され、サービスのスケール性を維持することができます。しかも、オープンであることが重要です。ユーザーの試行錯誤が次の成長を生みだします。昔のエンドユーザーコンピューティングは自分のPCに閉じていました。しかし、クラウドではサーバにおいて共有できる。だから、優れたユーザーの成果物が、周りのユーザーでも利用できる。これってエンドツーエンドユーザーコンピューティングと呼べるのではないでしょうか。ここら辺はWeb 2.0の続きですね。
こうしたクラウドの特性を存分に活かしたのが、ご存じエコポイントの事例です。ここら辺は記事でどうぞ。
・「エコポイント」の情報システムがわずか３週間で完成した理由
・「エコポイント」の申し込み画面はクラウド上に。開発期間わずか1カ月？ － Blog on Publickey
では、クラウドを支える技術特性はなにか。
スケールアップよりもスケールアウト。スケールアップは物理限界がありますが、スケールアウトであれば限界をなくすことができます。
CAP定理ではConsistency（データの整合性）よりPartition（ネットワークの分断 ）。スケールアウトを実践するためにはPartitionは外せません。Availability（システムの可用性）がなくては意味がありませんから、Consistency（データの整合性）を捨てるしかない。
ACID特性よりもBASE特性。厳密なトランザクション管理は不可能なので、"基本的には"可用（Basically Available）で、"ソフトに"状態管理（Soft-State）をやって、"最終的には"一貫性を保つ（Eventual Consistency）という考え方をします。
一方で企業システムの課題はヘテロジニアスであること。これは技術の話だけではなくて、規模の大小、標準か固有か、垂直的か水平的か、信頼/安定志向かスピード/変化志向かなどなど様々なパラメタがあります。
ところが企業としては"企業システム総体"として価値を創出したい。バラバラなシステムでは困ります。そこで統合をしようとしますが、場当たり的に統合しようとすると複雑さを生み、変化に適応できなくなります。昔は標準フレームワークなんかを導入しようとしていましたが、企業システムの中に標準的なシステムなんて何個もないわけで意味がなかった（繰り返し現れる部分を見抜いた企業では成功しています）。しかも、「カナヅチを持つ者はなんでも釘に見えてしまう」ので、小さなシステムでも標準フレームワークを採用しようとしてコスト高になるとか本末転倒です。
そうではなくて"企業システム総体"としての標準化が望まれす。パリの街並みは高さが揃っていてキレイです。これは景観規制法があるから。個々の建物のオーナーに「こういう家を作れ」という設計図を渡しても満足なんかできない。だから重視して欲しいポイントだけ規制をかける。目に見えるカタチを与えるのではなく、直接的にはカタチに現れないような標準を作る事で全体的な整合性を取る。これがアーキテクチャの視点です。
では、クラウドから何を学ぶべきか。
まず、大事なのは銀の弾丸は存在しないということ。クラウドの性質がすべての状況に合うわけではありません。ですが、企業システムに適用できる部分もあります。エコポイントの事例はうまくいきすぎですが、似たような視点でみれるシステムは必ずあります。
これは企業システムの常識を見直すきっかけになると思っています。価格面もそうですが「その処理って厳密にACIDが必要なの？」とか「そこまで一貫性維持が必要なの？」とか企業システムで常識的に考えられてきた基準を見直すための良い鏡となるはずです。
また、企業システムといえばSOAですが、SOAはクラウドとは違う背景から生まれています。クラウドはサービスの水平スケールを目指し、SOAはサービスの疎統合を目指します。ですが技術的には仮想化のように同じものを利用することが出来ます。昨今、プライベートクラウドという言葉がありますが、あれなんかはSOA視点でクラウド技術を利用しようという流れだと思っています。「Web2.0 から Enterprise2.0」と同じかなと。
僕がクラウドを超えた先の課題として考えているのは、システム統合パターンの整理、コンテナ型アーキテクチャの導入、インターフェースによる分業です。
システム統合パターンの整理とは「システムをどう作るか」ではなくて「システムの関係がどうあるべきか」ということです。クラウドもシステムの1要素に過ぎないわけで、それを活用するためにはシステム同士の関係についてパターンを深めていく必要があります。Enterprise Integration Patternsなんかもまとめられていますが、もう少しレイヤーをあげてまとめられるはず。おそらく優れたOSSフレームワークもできてくると思います。
コンテナ型アーキテクチャの導入とは、SNSにあるようなオープンなプラットフォームを導入し、エンドツーエンドユーザーコンピューティングを実現していこうというもの。SNSでは人と人をつなぐことが基本的な機能として提供されおり、その間のコミュニケーション形式がプラグインとして開発できます。企業システムでも、同じように基本的な機能を基盤として提供し、その上の処理をプラグインとして開発することは可能なはずです。Eclipseで出来ていることをサーバアプリでやればいいのです。
そしてインターフェースによる分業です。僕は機能とユーザーインタラクションの分離が重要と考えています。分業をしなければ全体的な生産性向上ができません。これは産業の基本です。分業ができれば道具を専門的に特化していけます。つまり、全体としては複数の道具を使っていていも、個々のシチュエーションでは1つの最適な道具を使うということです。マルチパラダイムは、そもそも分業できる状況を創り出さない限りは成功しません。これも技術の話ではないのです。
講演後にジャスミンソフトの贄さんとお話させていただいた時に話題になりましたが、こういうのがアジャイルをアーキテクチャから支えることだと思います。アジャイル性を維持するためにはプロジェクトマネジメントや純粋な開発技術（TDD、言語など）だけではなくて、アーキテクチャも変化する必要があります。
ちなみにSpringで言えば、システム統合パターンはSpring Integration、コンテナ型アーキテクチャはSpring Dynamic Module、インターフェースによる分業はSpring RooとGRailsをあげることができます。Springの次世代プロダクトが僕の考えていることに符合するのは偶然ではありません。世の中、そういう流れになっていると言うことです。
ようやくまとめ。
ハイプに乗っているものは見て触るべきです。特にクラウドは安くできる（僕もGAEで開発、EC2でホスティング、Force.comで開発は自習しています）。けど、流されてはいけない。そのためには全体性やカタチのないものを考える必要があります。表面に現れている具体的な技術や表現から一段上の抽象的なものを捉えて、そのレベルを具体的に考える。クラウドの技術をそのまま使う必要はありません。クラウドの技術特性がどこから生まれているのか。そのエッセンスを企業システムで利用できないのか？というように考えるのです。
また、ユーザー視点が重要ですね。技術がいかに優れていても、それがユーザーのニーズにマッチするカタチになっていなくては意味がありません。クラウドの規模の経済は、その点を良く表しています。クラウドサービスが企業システムに受け入れられるとすれば、それは技術ではなくて経済なのです。
ずらーっと並べてみましたが自分自身の振り返りとしても良かったと思います。技術の話をしているようで、技術の話をしてない。あるいは、その逆。これがアーキテクトの視点だと思います。
さて、もう資料見ればバレバラですがプレゼンテーションZen厨です！写真を選ぶのが楽しすぎ。ただ、量が多くなってしまったので、プレゼンテーションZen的には失格かと思います...。
自分としてナイスな写真は以下です！
・22ページのスケールアウトは、フラクタルな画像を組み合わせて雲を描いたもの
・31ページの赤坂と34ページのパリの対比は、直接は目に見えない基準によって全体整合がとれることをしめしている
・32ページの岩壁。ペルーのクスコにあるインカ帝国時代に作られた壁の中で最も複雑な14個の角を持つ石。当時、どういう理由でこれができたかは分かりませんが...
・38ページでプライベートクラウドをしめす「天井に空が描かれたショッピングセンター」
