5月23・24日の二日間に渡って開催され、大盛況のうちに幕を閉じた日本マイクロソフトの開発者向けカンファレンス「de:code 2016」。その参加者アンケートの総合点数で、134セッションの中でトップのスコアを獲得したのが、2日目の最終セッションに登壇した澤円氏のセッションだ。

澤氏のセッション、「クラウド心配性な上司を説得するコツを伝授します。本当に信頼できるクラウドの構築/運用とは～マイクロソフト クラウド成長の軌跡～」の概要をレポートする。

▲日本マイクロソフト株式会社　マイクロソフトテクノロジーセンター センター長　澤円氏

クラウド心配性な上司を説得するコツを伝授

プレゼンで重要なのは、伝えたい内容をいかに伝言ゲームのように伝播させていくか。そう常日頃から断言している澤氏。今回伝えたい相手は、クラウド導入に納得してくれない上司である。どう伝えたら説得できるのか、参加者が会社に持ち帰ってそのまま話したくなるような情報とネタが満載のプレゼンスタイルでセッションは行われた。

セッションの構成は大きく「データセンター構築から運用まで」「データセンター構築中」「データセンター運用」の3つのシーンに分けて語られた。

【上司に提言】海外との通信に専用線は高すぎますよね？

Microsoftのデータセンター構築から運用まで一連のオペレーションは、Microsoft Cloud Infrastructure and Operations、略してMCIOと呼ばれる。データセンター構築の情報を漏らさないために、会議室の予約は別の部署の名前を使うなど、情報管理は徹底している。

データセンターの場所選定は、さまざまな条件を要する。まずは電源が確保できること。発電所の近くであり、さらには発電所が停電になったことも考えると二カ所に近いほうが望ましい。液体燃料の確保が必要なので、道路の選定もデータセンター設置の条件となる。

電源ケーブルは二重化するのは当然のこと、アメリカでは米国基地とネットワーク網を共有している。海底ケーブルへも大型投資を行っているという。海底ケーブル最大の敵はサメ。サメがかじっても切れないケーブルを用意しているという小ネタも披露された。

こうしたトピックをもとに、「自分だけの専用ケーブルを引いてるみたいだから、ネットワークも信用できるみたいですよ。うちの会社で海外との通信に専用線は高すぎますよね？自分の国にデータセンターを持っているし、グローバルにクラウドの話をしてくれるはず」と上司に提案するヒントを語る澤氏。

実は、日本にMicrosoftのデータセンターを置くことを決めたのはCEOのサティア・ナデラ氏だという。日本の地下ネットワーク網は世界最強と言われており、マイクロソフト専用線も複数本ある。さらにその徹底されたグローバル標準について、話を進める。

【上司に提言】ここまでの標準化ってできますか？

Microsoftは、Open Compute Projectへの参加をしている。これはFacebookやGoogle、Intel、rackspaceなども参加しているプロジェクトで、サーバーの内部設計がすべて公開されている。

組み立てられたサーバー、ラックは同じ品質・クオリティで世界に出荷され、100カ所以上、40か国以上・22リージョン以上（※現在も増加中）にラックの状態でデータセンターに納品される。徹底的な標準化で大幅なコストダウンを目指し、標準化スタイルを決めたらそれを貫く。データセンターでやることはほぼケーブル接続だけだという。

特徴的なのは、ラックが白であることだ。白にすることで明るくなるので、接続ミスを減らすことができるし、何より光の量が少なくて済む。空調も使わず、空気の流れで調節している。これらはコストカットにもつながる。そして、こうした対応は一切の例外を認めておらず、全世界共通に行われている。

「そうはいっても」とマジックワードを繰り出す上司がいたら、「うち、ここまでの標準化ってできますか？」そう上司に問いかけることを勧める澤氏。ダラダラと妥協を繰り返すことは、コストを増やすだけと指摘した。

【上司に提言】サーバールームのログ取れてます？

さらに徹底したデータセンター運用について説明する澤氏。人はミスする、機械は壊れるを大前提として、人の手を介さない「自動化」を徹底すべきだと語る。

白いラックの上には、むき出しのケーブルが設置されている。なぜなら下（地下）だと手元が見えないから。すべての行動は追跡され、不正がないように手元が見えない状態を作らない。すべてがモニタリングの対象になる。

不正があれば証拠が残るが、逆にやってなかった場合も証明になる。データが守られると同時に社員も守られているという。知っていることで事故が起こることがある。その可能性をMicrosoftは徹底的に排除している。

データセンターで働く人は情報を見る術を持っていない。サーバーの電源や物理層だけチェックしている。鍵の管理は別組織だ。壊れていたらラックごと交換する。

ハードディスクもデータセンターから生きて出ることはない。役目を終えたハードディスクは4つに分割されて、それぞれ別の国で処理される。時間と手間がかかることで、犯罪者もあきらめる。犯罪の余地を作らないのだ。

ここでの上司への質問は「誰が触ったかわからない状態ってこわくないですか？うち、サーバールームの出入りって全部ログ取れてましたっけ？」。顧客データと社員を守るため、という大義名分に反論できる上司はなかなかいないだろう。

【上司に提言】「日本の法律」に対応できるそうですよ

最近Microsoftが変わりだしたのは、CEOのサティア・ナデラ氏によるところが大きいというのはよく聞く話だ。だが、社長のBrad Smith氏が弁護士だということを知る人は少ないのではないだろうか。彼が大切だと考えているのは、セキュリティ・プライバシー・透明性・法令順守。これはMicrosoftが法を順守する会社であるということを意味すると、澤氏は言う。

さらにCOOのKevin Turner氏によるMicrosoftのコミットメントを披露。上司に「日本の法律にちゃんと対応できるそうですよ」と言える要素を紹介した。

【上司に提言】あの人たちやりすぎです

最後に澤氏は、海底に設置するデータセンター「Project Natick」を紹介。究極の水冷化とセキュリティを実現する取り組みでありつつも、「あの人たちやりすぎです」と自虐ツッコミで会場の笑いをとった。

人々を成長させるためのモバイルファースト、クラウドファーストに徹底的にコミットして世の中をよく変える。「未来を一緒に」つくるために、今できることを伝える努力を最大限やっていきたいと宣言し、セッションを終えた。

澤氏のセッションはMicrosoftの動画チャンネルchannel9で公開されている。澤氏のde:codeでのプレゼンを見たいという方はこちらからどうぞ！

• クラウド心配性な上司を説得するコツを伝授します ～本当に信頼できるクラウドの構築/運用とは？ マイクロソフト クラウド成長の軌跡～【動画公開中】

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、エンタープライズ・アーキテクチャについて取り上げます。

HTML5・モバイル・IoT・ウェアラブルなどビジネス環境が激変する中、エンタープライズ・アーキテクチャはどういう課題を抱えていて、どうあるべきなのか。今回は、JJUG (日本Javaユーザーグループ）でご活躍中のお二人に話を伺うことにしました。

アーキテクチャを主軸に第一線で活躍しているグロースエクスパートナーズ株式会社 執行役員の鈴木雄介さんと、「流しのアーキテクト」を自称する株式会社アーキテクタス 代表取締役の細川努さんを交えて、エンタープライズ開発出身の白石俊平編集長がさまざまなトピックスをぶつけていきます。

XML Webサービスは今どうなったのか

白石：とりあえず、昔話から軽く聞いてみたいですね。まずは、エンタープライズ内のシステム間連携でよく話題に上がる、SOAPとRESTについての現状について、どうお考えでしょうか？

鈴木：SOAPは下火だと思われがちですが、私の知る限り、今でもよく利用されています。RESTとJSONの組み合わせも当然よく使われているんですが、（SOAPは）WSDLで型定義ができるので、それなりにかたいシステム間連携だったりすると、WSDLがあるほうがコードの自動生成もできるし、非常に楽なのでよく使われています。

　　 ▲グロースエクスパートナーズ株式会社 執行役員 鈴木雄介さん

細川：とはいえ、SOAPの上位レイヤで規定されているWS-ReliabilityだとかWS-Securityなどの様々なプロトコルは、あまり使われていない印象です。

白石：では、システム間連携などではプレーンなSOAPがよく使われているということですね。

鈴木：まあSOAPもRESTも用意する、というパターンが多いんじゃないでしょうか。オブジェクトモデルは同じで、それをSOAPでもJSONでも表現できるように設計しておくというパターンは、比較的多いような気がします。

細川：あと僕が気になるのは、スケーラビリティなんですよね。SOAPだとちょっと気になるのはやっぱりシリアライズ・デシリアライズの処理が重いし、トラフィックも増大するじゃないですか。そういった意味だとやっぱりREST + JSONのほうにもメリットがありますね。本来だったら使い分けみたいなところが重要なんですけど、いまだにSOAP一択という開発現場も多い。

　　　▲株式会社アーキテクタス 代表取締役 細川努さん

白石：どっちかに寄せちゃったほうが考えることが少なくて、楽ってこともあるかもしれないですね。

鈴木：一長一短…というとつまらない話になってしまいますが（笑）、実際のところそういう結論になっちゃいますね。HTML5が盛り上がっている現在、JavaScriptと相性が良いJSONにはすごく価値がある。一方で例えば、日付型をどう扱うんだとか、型定義やコードの自動生成がしづらいというJSONには苦手な分野もあるのですが、SOAPはそういう部分に強い。「SOAPはXMLだからダメ・ダサい」ということは、実際のシステム開発には全く当てはまらないと思いますよ。

エンタープライズアーキテクチャパターンは今も有効か

白石：アーキテクチャという点では、マーティン・ファウラーのエンタープライズ アプリケーションアーキテクチャパターンが昔は王道だったかとと思うんですが、それは今も有効なんでしょうか？

鈴木：あれは普遍的なものなので、時代が変わったからといって使えなくなってしまうようなものではありません。ただ、昔と比べると今はWeb API主導型のアプリケーションが主流になりつつありますね。クライアントのマルチデバイス化は当然エンタープライズでも相当重要なので、「サーバー側はAPIを提供するだけ」というスタイルに移行しつつあるのは、Webでもエンタープライズでもまったく変わらないと思います。

白石：具体的には、JAX-RSを利用するとか？

鈴木：JAX-RSもありますし、JSON用のバインディングAPIもJava EE 7で標準化されたので、何の違和感もなく使えますね。

細川：エンタープライズ アプリケーションアーキテクチャパターンは非常に洗練されていたのですが、実際のエンタープライズ・アプリケーションはもっと泥臭いです（笑）。 例えばマーティン・ファウラーの提唱するモデルだと、プレゼンテーションレイヤからデータレイヤまでが3、4層ぐらいなんですが、実際はビジネスロジックだけで3層以上に分けたりとか、ビジネスロジックとプレゼンテーションの間にいろいろ挟んだりとか、端から端まで数えると下手したら10層ぐらいあるものも実際のプロジェクトでは山ほどありました。

白石：僕もそういうプロジェクトをやったことがあります。なんか別のメソッドを呼び出してるだけのメソッドが大量にあったり（笑）。

細川：そうそう。なので、どちらかというとほんとに綺麗なレイヤリングはできてなかったというのが現実ですね。最近、６〜７年以前につくられた数十万ステップくらいのシステムをいくつか実際に解析してみたんですけど、結構面白い結果が出たんですよ。サーバーサイドJava（JavaEE）としては最新ではなく、まだJ2EEと呼ばれていた頃のシステムです。どのシステムも、一番複雑度が高いのはビューとデータアクセス（永続化）、アーキテクチャ共通系のモジュールです。ビジネスロジックの部分は量は膨大なんですけど、複雑度自体は比較的シンプルなんです。

何が言いたいかというと、古い世代のサーバーサイドJavaは、ビューとアーキテクチャ制御に作り込みが必要で、そこのところが本当に大変だった。例えば、ビューのところのバリデーションなんかは、かなり作り込みが必要で、簡単な画面作るのも相当手間がかかってたんですよね。結局は、かつてのJava EE（J2EE）って、エンタープライズ系プログラマーが本来集中すべき業務上のロジックにあんまり集中できていなくて、もっと簡単にできるはずのところに手間がかかっていたのが現実だったんじゃなかったかなと。

白石：ほんとにそうですよね。オブジェクトの変換とか、別のメソッド呼び出すだけとか、ファサード作ってそこに一生懸命集めるだけとかやっていて、なにやってるんだろうこれは…とか思っていました。

細川：以前はそうでしたね。そのレガシーなところが今はみんなの足を引っ張ってる（笑）。現在は、それがどれだけ良くなってるか、というところですよね。

白石：今の流れをまとめると、ビューの複雑なところっていうのが、だんだんクライアント側に寄ってきていて、ようはHTML5でリッチクライアント化されてきて、サーバー側はAPIを提供しているだけになっていると。

鈴木：大きくはそうです。ただ、エンタープライズシステムの場合、とにかくシステム間連携が多くて、1つの企業の中でいろんなシステムがあって、ほとんどのシステムが関連付いているのが当然になっています。そうするとクライアント側からするといろんなシステムにいちいちログインして使うのは面倒くさいので、どうやってシンプルに使うのかというのが今の大きなテーマになっていると思います。サーバー間で連携したり、クライアント側でアグリゲーションしたりというのが今の課題としてあって、エンタープライズの場合は、そこがシンプルにならないので、それがひとつの前提になっています。

白石：なるほど。そのシステム間連携がさきほどおっしゃっていたようにXMLベースだったり、RESTだったりという感じですね。

鈴木：はい。企業って、いろんなユーザーといろんなシステムがあるので、いわゆる一般コンシューマー向けのECサイトのようなシステムもあれば、例えば人事システムみたいなものもありますよね。人事システムだと、人事部だけが使うのでユーザーが10人しかいなかったり、でも社員数10万人を支える人事システムっていうと相当でかいっていうものだとか。じゃあその2つが同じアーキテクチャで、同じ作り方でいいんですかっていうと全然そうじゃないですよね。

企業の中のさまざまなシステムの中で、HTML5に合うものもすごく増えてますし、HTMLの可能性が広がったことでやれることもすごく増えましたが、一方でそれが銀の弾丸ではないです。ここはRESTでつくったらいいよねとか、ここはWSDLがちゃんとあってSOAPでやったほうがいいよねっていうのがある。そこは全体の中での選択してやっていけばよいことです。エンタープライズの人って古めかしい人印象があるかもしれないですけど、新しいことも古いこともやらきゃいけないので、そういう意味ではちゃんとまともにやっている人は、それを両方うまくバランスよくやっていますね。

エンタープライズとモバイル

白石：最近のエンタープライズ業界に疎くて、初心者的な質問で申し訳無いのですが、モバイルをエンタープライズで使うというのはもうかなり普通に行われていることなんでしょうか。

鈴木：そうですね。モバイル、タブレット、PC、専用の機器とか、何を何に使うといいよねっていうユースケースはちゃんと考えなきゃいけないですが、モバイルはものすごく重要なツールとして使われています。

白石：エンタープライズでモバイルといえば結構HTML5が使われているという話を聞くのですが、実際そうなんですか？コンシューマ向けだと、ネイティブアプリが全盛です。

鈴木：そもそもモバイルという文脈で求められる操作性とか機能が、エンタープライズの場合はそんなにネイティブでやらなくてもいいようなものが多いので、HTML5がフィットしてるんじゃないかと思います。例えば、ゲームはネイティブアプリがいいといわれますが、別にあそこまでビジュアル的なものとか、細やかな操作性はあんまり求められることはないと。

なので、HTML5でやるっていうのは多いんじゃないでしょうか。Webアプリであれば、リリースも楽ですしね。去年ぐらいまでは写真とか音声とかでいろいろやろうとすると、まだまだHTML5では制約が多いということでネイティブアプリという選択もありましたが、そうした制約もブラウザが進化してきてだんだん問題にならなくなってきています。

白石：なるほど。ちなみに、そうしたHTML5で書かれた業務アプリは、ハイブリッドアプリとしてインストールする形が多いのか、それともWebサイトとしてURLでアクセスする形で作るんでしょうか。

鈴木：それは両方あります。どちらにも利点があるので。

クラウドがアーキテクチャに与えた影響は？

白石：これも初心者的な質問で恐縮です。クラウドがエンタープライズのアーキテクチャに与えた影響はありますか。

鈴木：もちろんあります。クラウドができたことで一番大きかったのは、PaaSという概念ができたことですね。あるニーズに特化したものっていうのは共有化されたものが使われるべきだっていう概念がはっきりしたのはPaaSのおかげです。例えばAWSのラインナップを見て貰うとわかるんですが、CDNありますねだとか、ロードバランサありますねだとか、ストレージ、サーバーノード、認証認可とか、メールの配信サービスとか、ああいうものはPaaSとしてみんなが共有して使うべきだという概念ができた。

なので、そういうプラットフォームを用意してその上にアプリケーションを作って、アプリケーションはUIを含めてそれだけに特化して、なるべくプラットフォームの機能をうまくつかってやっていくていうアイデアは、今のエンタープライズでも浸透している考え方だと思います。

細川：開発者視点でいうと、開発者ができる領域が増えてきましたね。従来だと、サーバ構築とソフトウェア開発は別々のものでしたが、プログラマーがだんだんとクラウドを前提にして、環境を構築するようになってきた。そうすると、同時にパフォーマンスだとかセキュリティだとかをエンジニアが自分で考えなきゃいけない時代になってきていて、Webエンジニアだとかエンタープライズエンジニアとかの区別はなくなってきている。そういう意味では、フルスタックで両方できなきゃまずいんじゃないでしょうか。

鈴木：もうそれはエンタープライズでも間違いなくそうですね。

細川：もうひとつの特徴としては、昔は大規模＝エンタープライズということが多かったんですが、今ではコンシューマー向けとかゲームだとか、そっちのほうがより大規模なんですよね。それを実現しているのがやっぱりクラウドなのかと思っています。そういった意味でも、これからはWebエンジニアこそ大規模を得意にならなきゃいけないんじゃないかと。サーバーとクライアントのメッセージの単位なんかもパフォーマンスに大きく影響するので、そういったところも、かなりノウハウを積まないといけなくなってきています。

エンタープライズ・アーキテクチャの未来像

白石：IoTとかウェアラブルとかを見据えて、今後どういうふうにエンタープライズ・アーキテクチャが変わっていくべきか、ご意見はありますか？

鈴木：IoTを真剣にやろうとすると、先ほど細川さんが言っていた大規模っていうのがエンタープライズに戻ってくるんですよね。対応するデバイスの数が、今まではユーザーが数万人ですんだのが、億になるかもしれない。例えば、すべてのダンボール箱にチップがついたらどうなるんだろうっていう世界を考える。そうすると日本で流通しているダンボール箱は何箱あるんだとか、ものすごいクライアントの数になってしまう。そうなってくると、エンタープライズがまた大規模な性能を頑張らないといけなりますね。

例えば、わかりやすい例でB2Bのケースを考えると、トラックをトレースする仕組みを作ることになったとします。じゃあ全国にあるトラックを全台管理しますとなったときに、全部で何台あるのか。1台のトラックにセンサーがいくつついているのかということになると、センサーが車輪それぞれにあって、それぞれのタイヤのすり減り方を計測して、運転手が寝てるんじゃないかというのを監視するセンサーがあって、速度・加速度をとるセンサーがあって…というようにトラックにすごい数のセンサーがある。

そして、トラックを1万台管理します、データを500msごとに取るとすなると、ものすごい数になる。つまり、B2BでIoT、ウェアラブルというのはB2Cのスケーラビリティをエンタープライズでもう1回頑張らないといけないということになる。今、Webの人が大規模で頑張っているテクノロジーセット、例えば大量のストリームを処理しながらイベントドリブンでやるっていうのは昔からエンタープライズにあって、それがWeb側ですごく実用化されて使われていたのが、またエンタープライズに戻ってくる。そういう流れが未来にはやってくるんじゃないかなと考えています。

白石：なるほど。ちなみに、もう実際にIoTの案件とか発生しているんでしょうか。

鈴木：相談はかなり増えてきてますね。まだ実証実験ぐらいが多いという感覚ですが。今は車がうまくいっていて、ホンダの事例がわかりやすいです。日本中の車のブレーキの発生情報を集めてるんですけど、それを解析すると事故が発生しやすい曲がり角がわかるんですよね。みんながたくさんブレーキを踏んでいる曲がり角がどこかっていうのを提供しているんですよ。そしたらそれを元に道路の信号とか標識とかを改善するってことをやっています。

まとめ

白石：本日は、エンタープライズ・アーキテクチャについて様々なご意見をいただき、誠にありがとうございました。最後に、読者に向けて一言お願いします。

鈴木：自分たちの生活を考えると、やっぱりエンタープライズ業界の会社が自分達の生活を支えてるわけじゃないですか。それがより便利になったり、役立つようになったり、世の中が進化するっていうのはとても大事なことだと思うんですよ。なので、それが実現されるためにはどうしたらいいのかっていうときに、エンタープライズとかWebとかそういう区切りはどうでもよくて、どうやれば本当に価値がでるのか、そういうのを考えるのが面白い。

ただ、社会基盤として変えてはいけないところもエンタープライズにはどうしてもあるので、それをどのように変えずに、より新しいことにトライしながら今あるものの価値をより高めるのかというところが大事ですね。なので「エンタープライズwww」という風潮はよろしくないと思います（笑）。

細川：2点あって、ひとつは、今までのエンタープライズ開発は、ユーザーの言われたものを作るという風潮が多かったんですが、今後はユーザーと一緒につくるっていうのは大事になってくるんじゃないかと考えています。そういう意味ではエンタープライズ業界もWeb業界と同じようにUXとか、よりユーザーが求めるものは何かというところを柔軟に対応してかなきゃいけない。エンタープライズもWebに学ばなきゃいけないということ。

もうひとつは、今後、変化がたくさんあって、それに対応するためにエンタープライズ側、Web側が両方対応しないと対応できないんじゃないかなと思う。これらの技術の変化に対応できるようにフルスタック、両方できるようなエンジニアが増えてくると心強いんじゃないでしょうか。