Experts.jp日本に、もっとエキスパートを。mBaaSという言葉をご存知でしょうか。Service」の略(mBaaSは、さらにモバイルアプリに特化したもの)で、サーバサイド(バックエンド)のコードをほとんど書かなくてもアプリを開発できるようにするサービスです。2013年にFacebookが買収したParseが特に有名です(以下、「mBaaS」で用語を統一します)。mBaaSは主にモバイルアプリの開発に利用され、Webエンジニアにとっては少し馴染みの薄い技術ではあるのですが、これからのアプリケーションアーキテクチャを考える上では外せないトピックだと考え、有識者の方々にお集まりいただき、「仮想パネルディスカッション」を実施しました。mBaaSを作っている人と使っている人が入り乱れ、愚痴(?)からIoTに至るまで、mBaaSに関するトピックが尽きることなく話し合われました。ƒまずは自己紹介から白石:本日はこれほど多くの「mBaaSを作る人」「mBaaSを使う人」に集まってもらい、光栄の至りです。皆さん、自己紹介からお願いします。私はKiiという会社で、mBaaSを作っています。井上:日本マイクロソフトのエバンジェリスト・井上大輔です。Azureが持つmBaaSサービスを担当しています。私はどちらかというと、「作る」でも「使う」でもなく、mBaaSを「売る」立場ですが...ここにいていいんでしょうか(笑)。白石:多様性があっていいと思います(笑)。引き続き、物江さんから時計回りで自己紹介をお願いします。物江:私も同じく日本マイクロソフトのエバンジェリスト・物江修です。Azureの担当でもありまして、今回は井上を引っ張り出してきました。のびすけ:LIGの菅原のびすけです。mBaaSをいろいろ試した中で、MilkcocoaというmBaaSに惚れ込んでLIGブログで取り上げたりしていたら、エバンジェリストに任命されました。槌野:アピアリーズというmBaaSを開発している槌野雅敏です。本日は、今後mBaaSはどうあるべきかってところを皆さんと議論したいと思っております。田中:ノハナという会社でエンジニアをやっている田中和紀と申します。Parseをかなりハードに使っているので、そうした知見を共有できればと思っています。mBaaSのよいところ白石:では手始めに、mBaaSを「使う」立場であるのびすけさんと田中さんに、「なぜmBaaSを使おうと思ったのか?」をお聞きしたいのですが、よろしいですか?のびすけ:プロトタイピングやハッカソンなど、時間が限られている中で裏側の部分を全く考えずに作り始められるのがすごくいいと思っています。キャンペーン等での実案件でも使いました。開発のスピード重視で一過性のものを作るのにmBaaSはすごく役に立ちますね。田中:私が携わっているノハナというサービスは、mixiのイノベーションセンターという新規事業開発プログラムから生まれたものです。そのプログラムは、非常に短期間で成果を上げることが求められるものだったので、mBaaSを採用することにしました。「とにかく開発の立ち上げがとにかく早い」というのが利点と言えそうですね。mBaaSの利点について、今度は作っている側の方にも聞いてみたいです。井上さん、いかがですか?製品を「売る」立場として、セールストークに期待しつつ(笑)。井上:って言っても、私もともとサーバサイドのエンジニアなので、バックエンドに関しては「自分で作ればいいじゃん」と思うこともよくありまして...(笑)。いえ、作るのが爆速になるのはすごくメリット大きいと思います。マイクロソフトの場合だと、mBaaSサービスを2つ持ってまして。モバイルサービスとモバイルエンゲージメントです。モバイルサービスは一般的なmBaaSサービス。モバイルエンゲージメントは、いわばプッシュ通知に特化したSaaSのようなものでして、プッシュ通知の開封率とか、エラーが返ってないか調べたりとか、ターゲットを絞って送るとか、いろいろと面倒な部分をまるごとサポートしてくれます。いうサービスは、確かにすごく便利ですね。mBaaSの悩ましいところ白石:では逆に、mBaaSの悩ましいところや、改善すべきところとかはありますか?田中:Parseに限って言うと、安定性には少し問題がありますね。弊社のサービスは、月末にリクエストが集中するのですが、そこでトラブルが多発するのが困りものです。うち(ノハナ)がハードに使いすぎて、サービス設計者の意図を超えちゃってる部分もあるとは思うんですけど。今でも、ノハナの8割くらいはParse.com上で動いています。8,000万枚の画像、1億件以上のレコードを扱っているといった感じで、多分日本で一番使っている会社じゃないでしょうか。あと、サポートのレベルとかもあまり高くない。Facebookに買収されて、安定性やサポートレベルが上がるかと期待したのですが、今のところはそうなってないです。白石:さすが、使いたおしているだけあって、辛口ですね(笑)。ちなみに、パフォーマンスとかはどうなんでしょう?田中:Parseは、データセンターがアメリカの西海岸にしかないんです。今後はシンガポールに作るらしいんですが。すごく遅延します(笑)。ハナはフォトブックのサービスなんで、画像のアップロードが頻繁に発生するんですが、遅い遅い。日本でサーバ立てて一旦そこにキャッシュするようにして、そこからParseにアップロードするようにしてます。して一部機能から日本にサーバを立てていって、そのうちParseから脱却して自社のインフラに移行しようと図っています。白石:苦労してますね...。田中:とはいえ、感覚的には、運用や設計のエンジニア3人分くらいの働きはしてくれると思っています。仮に今また新しくサービスを作れと言われたら、またParse使うと思いますよ。スピードを持って、商用のモバイルアプリを出すには最高なので。3人分雇えるくらいの利益が出てきたので、切り替えようかと思っているってところですね。白石:その移行って、うまくいきそうですか?田中:いくと思っています。今でも常に、Mongoからデータをダンプして、解析とか集計用にデータをインポートするということを行っているので。数ヶ月はかかりそうですけどね。槌野:サービスを作っている立場からしても、今のmBaaSはまだまだ進化の途上だと思います。プッシュのサービスとか、便利な点はあるのですが。私も元々サーバサイドのエンジニアなので、バックエンドの自由度が低いのはデメリットに思えてしまいますね。物江:ロジックのほとんどがクライアント側で実装されるのなら、バックエンドって認証やデータ保存がメインになって、今のBaaSでも十分なのかな...なんて思ってしまうんですが、違うんでしょうか?槌野:ところがそうでもないんですよ。実際のお問い合わせでも、例えばトランザクション制御とか複雑な検索クエリとか、今のmBaaSができることを超えたものをお望みの方もたくさんいらっしゃるのが現状です。白石:トランザクションや複雑な検索といったお話が出ましたが、そういったユースケースにはやはり対応しづらいんでしょうか?槌野:これはmBaaSというよりは、NoSQLデータベースの問題ですけどね。RDBの感覚で設計してしまい、クエリ量の増加やトランザクションの問題に直面するというケースはよくあります。田中:そうそう、コツが必要ですよね。そもそもデータベースを正規化しちゃいけないんです。白石:そういうデータベースを設計する際って、どういうふうに進めるんですか?まず正規化してから崩す?田中:そうですね、僕らも最初は正規化して作ってましたけど、それをどんどん崩していった感じです。すると一番いいのは、モバイルアプリのコードをひたすら書いていって、結果的にできたDBを使うといった感じかもしれません。サーバサイドから設計しない。モバイルからリクエストを投げると、勝手にテーブルやカラムになっていくので、それを使うのが結果的に一番きれいになる...かもしれません。キモチワルイですけどね(笑)。石塚:そういう進め方、実際にありますね。iOSとAndroidは基本的に開発者が別々なので、それぞれがコードを書いていった結果、最終的にデータ構造が食い違っちゃったなんてこともあります(笑)。サーバサイドの設計なしで始めるので、そういうことが起きるんですよね。決まってればそれに合わせるんですけど。白石:ちなみに、mBaaSのデータストアってMongoDBがよく使われているイメージがありますが、この中でMongoDB以外のデータベース使っている製品ってあるんでしょうか?石塚:Kiiは独自でキーバリューストアを作ってますね。APIの裏側を全部差し替え可能にしてあって、サービスの特性に応じてストレージを切り替えられるようにしてあります。柔軟なのはいいんですが、Techieにやりすぎな面もありますね(笑)。井上:NoSQLの話で盛り上がってる中、肩身が狭いんですが(笑)、AzureのmBaaSで使われるのはRDB(PaaS版のSQLServer)なんです。DocumentDBってサービスもあってそちらはNoSQLなんですが、デフォルトではありません。白石:実際mBaaS使うと、開発の流れとかは変わるんでしょうか?のびすけ:データベース設計より先に、UI設計からいけますね。開発の入り方は変わると思います。キャンペーンとかの小さな短期的な仕事だから、ゆるい設計で進められるのですが。長期的になると、先にDB設計をしっかりやらないと後々大変なことになります。田中:そうですね、長期的なサービスだと、まずDB設計はするでしょうね。僕だったら一旦設計した後、そこでリクエスト回数をどうやって減らそうかな、とか考える。通信が一番パフォーマンスに影響するので。正規化を崩すとか、キャッシュ戦略を考えたり。Codeとかあるんですが、そういうのは極力使わないようにする。スケールしなくなるので。あと問題なのはSDKの完成度ですね。Parseはあまり完成度が高くなくて...メインスレッドで通信しちゃったりするので...。白石:ほんと、使い倒した方ならではのノウハウというか、バッドノウハウというか、愚痴というか、たまってますね(笑)。白石:では、せっかくこれだけの方々にお集まりいただいたのですから、読者がサービスを比較する手助けになるように、それぞれのサービスの利点や特徴を教えていただけますか?じゃあまずKiiの石塚さんから。石塚:そうですね、まずKiiは、サポートはなかなかのものだと思いますよ。日本語はもちろん、中国語や英語もいけますし。機能的な点では、今のところmBaaSのサービスはどれも似たり寄ったりかな、と思っています。白石:ありがとうございます。次、マイクロソフトの井上さん。井上:え、いやー...いいところって言っても、そんなに...。一同:えー!(爆笑)井上:というのは冗談で、まずマイクロソフトはデータセンターが世界19カ所にあるんですよ。日本にも、東と西の2カ所ある。1カ所あたり60万台くらいとか持ってます。AWSの2倍とかそんなレベル。スケールのレベルがぜんぜん違うと思います。あと、サポートって分野に関しては、マイクロソフトはかなり手厚いです。マイクロソフトのサポートって、社内でもかなり厳しく評価される立場なんで。Azureが持ついろんなサービスと連携できるのも強みですね。mBaaSとPaaSとか、管理用のサービスとか。のびすけ:僕は開発スピードが重視されるキャンペーンの受託制作とかで使うことが前提なのですが、とにかくさくっと作り始められるかどうかを重視しています。サンプルやチュートリアルを少し触って、すぐに動かせるっていうのが大事。いう点では、Milkcocoaはすごくいいです。その他のサービスは、多機能なのはいいんですが、僕の立場からするとそこまでの機能はいらないかな、と。槌野:アピアリーズは、受託開発とセットでできますよ、というのを割とウリにはしてますね。親会社であるPCPhase社のリソースを活用できるのが売りです。田中:Parseですが、まあ、最初の方に出たサービスですよね。...特徴って、なんかあるのかな?(笑)。白石:一時期は、「Parseを使っておけばとりあえず間違いない」みたいな雰囲気ありましたよね。槌野:今でもそれはありますよね。Parseの成功を見て、追いつけ追い越せでやっている。今は各社のサービスが似たり寄ったりになってる部分もあると思います。これから物江:じゃあ、今後はどうなっていくんでしょう?開発者が自由度の高いバックエンドを開発できるようになっていくのか、それともブラックボックス化がより進んで、必要な物を組み合わせてサービスを作っていけるようになるとか、どんな方向にいくのでしょうか?槌野:どちらにチャレンジする企業もあって、開発者がどちらを選んだかという結果によって、段々淘汰されていく...って流れじゃないかと思いますね。石塚:私は今後もっとサービスの高レベルな部分、例えば分析とかですね、そういうニーズを満たすという方向にいくんじゃないかと思っています。のびすけ:IoTの流れとかもありそうですよね。Web制作する側からすると、デバイスのセンサーデータを取ってくる部分はブラックボックスでもよくて、そこをBaaSが担ってくれる...という未来が考えられるかなと。白石:相性はすごく良さそうですよね。Parseも、先日のF8カンファレンスでIoT対応を発表しましたね。石塚:実はKiiも、去年の10月からIoT対応機能は載せてるんですよね。井上:あ、実はAzureも去年IoT対応してまして...。白石:あれ、実は結構IoT対応してるサービスっていっぱいあるんですね(笑)。Parse遅かった、みたいな?石塚:そうなんですよ。BaaS”とか”IoTプラットフォーム”とかが毎週出てくるといった状態。ものすごくレッドオーシャン化しているんです。白石:そんなことになってたんですね、知らなかった...!田中:「mBaaSのこれから」っていう話で言うと、モバイルやIoTの分野に挑戦するベンチャーが後を絶たない昨今、mBaaSの重要性は今後も高まると思いますね。Android両対応が必要な上に、Web開発より工数がかかります。次にリソースのフォーカスに関する問題。モバイルアプリはUI/UXが優れていることが第一。必然的にフロントエンド側にリソースを重点的に投下していく必要があります。アプリのエンジニアは常に不足している状態ですので、これまでWebのエンジニアだった人にも、アプリ開発を担当してもらう必要があります。した理由からエンジニアをサーバ開発に回すことが難しくなっているというのが実際で、今後もmBaaSは重要な位置付けになると考えています。話は尽きませんが、ひとまずここまでとさせていただきます。