Firebaseとは

Firebaseはデータストレージ、ユーザー管理などアプリケーションのバックエンドとして必要となる機能をサービスを提供することで、アプリケーション開発者がクライアントサイドの開発に集中できるようにしてくれるBaaS（Backend as a Service）の一種です。

2014年10月にGoogleに買収され、Google Cloud Platform（GCP）の一員となりました。この買収によりGCPにはPaaS（Platform as a Service）としてGoogle App Engine、IaaS（Infrastracture as a Service）としてGoogle Compute Engine、BaaSとしてFirebaseと、いわゆるXaaS系が一通り揃ったことになります。

Firebaseの特徴

Firebaseはもともとは開発者用APIを持つウェブサイトに埋め込み可能なリアルタイムチャットサービスとして始まりました。

しかし、多くのユーザーがチャットサービスとしてではなく、ゲームなどのアプリケーションでリアルタイムにデータを同期するために使用したため、創業者たちはチャットサービスのリアルタイムメッセージングシステムを切り出して別サービスとしました。これが現在のFirebaseの元となっています。

そのため、Firebaseは数あるBaasの中でも特にチャットアプリのようなリアルタイムにデータを同期する必要があるサービスに適しています。

Firebaseの機能

リアルタイムデータベース

FirebaseのデータベースはスキーマレスないわゆるNoSQLで、特定のアプリケーションに関係するデータ全体がひとつのJSONオブジェクトとして保持される点が大きな特徴です。

これによりデータが階層構造をなすため、それぞれのデータが一意のURLを持つことができます。例えばデータベース全体を指すURLは以下のようになります。

• https://アプリケーションID.firebaseio.com/

特定のデータを示すURLは以下のようになります。

• https://アプリケーションID.firebaseio.com/プロパティのパス

例えばアプリケーション名 my-first-chat-app のデータ全体が以下の様であるとして

{
  "messages" : {
    "-K5kPGFquoTbqHYQqBRS" : {
      "body" : "message",
      "name" : "name"
    },
    "-K5kPUqfBfdj4bAa1fyv" : {
      "body" : "message2",
      "name" : "name2"
    },
    "-K5kR-lwtG4I5w9T36Xq" : {
      "body" : "message3",
      "name" : "name3"
    }
}

最初のメッセージ（messages/-K5kPGFquoTbqHYQqBRS）の内容だけを確認したいのであれば、次のURLをブラウザで表示すればいいということになります。

• https://my-first-chat-app.firebaseio.com/messages/-K5kPGFquoTbqHYQqBRS

特定データの表示

認証

Firebaseを使用すると非常に簡単にユーザー認証をアプリケーションに組み込むことができます。組み込みの認証機構としては、メールアドレスとパスワードを使用した認証、OAuthを使用した認証（Facebook, Twitter, GitHub, Google）、匿名ログインがあり、加えてJSON Web Tokens (JWTs)を使用して既存の任意の認証システムと連携することも容易です。

ホスティング

HTML、CSS、JS、画像などの静的なアセットは、Firebaseコマンドラインツールを使用して自身のドメイン上（アプリケーションID.firebaseapp.com）、もしくは有料プランであれば独自ドメイン上に簡単にデプロイすることができます。

さらにデプロイの履歴は管理画面で見ることができ、問題があった場合には以前のバージョンにロールバックすることも可能です。

コマンドラインツール

Firebaseのホスティングサービスを利用するにはFirebaseコマンドラインツールを使用する必要があります。node.jsとnpmがインストールされていればコマンドツールは以下のコマンドで簡単にインストールできます。

$ npm install -g firebase-tools

firebaseコマンドで利用可能なサブコマンドは、以下のとおりです。

firebase init

プロジェクトディレクトリを初期化します。ホスティングサービスに必要なすべての設定は当コマンドによりプロジェクトディレクトリルートに作成されるfirebase.jsonファイルに含まれます

firebase deploy

現在のプロジェクトをサーバーにデプロイします

firebase disable:hosting

ホスティングを無効にし、アクセスに対し”Site Not Found”ページを表示するようにします

firebase login

コマンドラインツールをログインします

firebase logout

コマンドラインツールをログアウトします

firebase list

現在ログイン中のユーザーが利用可能なFirebaseアプリの一覧を表示します

APIとSDK

FirebaseデータベースにはREST APIがあり、さらにそのAPIを利用する各種環境用のクライアントライブラリが標準で用意されています。

• Web（JavaScript）
• iOS（Objective C）
• Android（Java）

なお、これらの標準クライアントライブラリを使用するとFirebaseはオフラインでの動作が保証されます。つまりネットワーク接続がない場合でも、Firebaseデータベースの読み書きの対象を一旦ローカルのキャッシュとすることで、アプリケーションは正常に動作します。その後、接続が復活した時に内容がサーバーと同期されます。

また、標準ライブラリに加えて、REST APIを使用する非公式なライブラリとして以下の様なものもあります。これ以外にもいろいろとありますので、サーバーサイドで自分の好きな言語を利用したい場合はGitHubなどで検索してみるといいでしょう。

• Python-Firebase（Python）
• Firebase-Php（PHP）
• Firebase-Ruby（Ruby）
• BigBertha（Ruby）
• Rest-Firebase（Ruby）

なお、標準クライアントライブラリを使用した場合はオフラインでの動作が保証されますが、非公式ライブラリを使用した場合はその限りではありません。

サンプルアプリケーション

Firebaseを使用した基本的なアプリケーション開発の流れを確認するために簡単なチャットアプリケーションを作成してみましょう。先に紹介したとおりFirebaseクライアントライブラリは環境に応じて複数ありますが、今回はJavaScript版クライアントライブラリを使用してWebアプリケーションを作成します。

サンプルチャット

Firebaseアプリケーション作成

まずはじめに、今回のサンプルから使用するデータベースを用意するため、ウェブコンソールからFirebaseアプリケーションを作成します。http://firebase.com/ を開き、画面右上のログインボタンをクリックしてログインしてください。

アカウントを新たに作成しても構いませんし、GoogleアカウントやGitHubアカウントを使用してログインすることもできます。

Firebaseログイン後

ログイン後、左下の入力エリアにアプリ名とアプリURLを入力して、アプリを作成します。今回は以下の様な設定を使用するものとします。

Firebaseアプリ新規作成

サーバーサイドで行う作業は以上です。これだけでNoSQLデータベースが作成され、クライアントアプリから自由に利用できるようになりました。

サンプルアプリケーションの初期化

サンプルアプリケーションは最終的にFirebaseホスティングサービスを利用するため、まずfirebase initコマンドを実行してプロジェクトディレクトリを初期化します。

% firebase init

? What Firebase do you want to use? my-first-chat-app
? What directory should be the public root? public
✔  Public directory public has been created
Firebase initialized, configuration written to firebase.json

初期化にあたって

1. アプリ名
2. デプロイするファイルを配置するディレクトリ

を聞かれるので、アプリ名は先程作成したものを、ディレクトリ名はデフォルトのpublicを設定してください。

ウェブアプリケーション作成

それではここから実際に冒頭のサンプルアプリケーションを作成していくこととします。といっても必要となるのはHTMLファイルが一つだけ、それも非常に小さなものですので先に全体を見てしまいましょう。

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <title>Firebaseサンプル1</title>
  </head>
  <body>
    <div>
      <input id="name" placeholder="名前" />
      <input id="message" placeholder="メッセージ" />
      <button id="send">投稿</button>
    </div>
    <ul id="messages">
    </ul>

    <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-alpha1/jquery.min.js"></script>
    <script src="https://cdn.firebase.com/js/client/2.3.2/firebase.js"></script>
    <script>
      // データベースの参照を準備
      var firebaseRef = new Firebase("https://my-first-chat-app.firebaseio.com/"); // ... 1
      var messagesRef = firebaseRef.child('messages'); // ... 2

      // 既存メッセージを表示
      messagesRef.on('child_added', function(snapshot) { // ... 3
        var msg = snapshot.val();
        $('<li>').text(msg.name + ': ' + msg.body).prependTo('#messages');
      });

      $('#send').click(function() {
        // 新規メッセージを投稿
        messagesRef.push({ // ... 4
          name: $('#name').val(),
          body: $('#message').val()
        });
      });
    </script>
  </body>
</html>

今回のサンプルアプリケーションのコードはこれだけ、コメントや空行を除けばJavaScript部分はたったの12行です。このコードをローカルに保存し、ブラウザで開いてみてください。HTMLを含めて全体でも40行弱のコードですが、複数ブラウザで開いて、一方でメッセージを入力すればその内容はリアルタイムに他方に反映され、（かろうじて）チャットとして利用できます。

コードの詳細については次回以降に譲りますが、簡単に説明すると、行われている処理は以下のとおりです。

1. アプリケーションURLを引数としてFirebaseオブジェクトをインスタンス化し、前節で作成したFirebaseデータベースに接続するためのオブジェクトを生成します。
2. Firebaseデータベースのmessagesオブジェクトへの参照を取得します。この参照への操作はサーバー上のFirebaseデータベースに保存されることになります。
3. messagesオブジェクトに子ノードが追加された場合のコールバック関数を登録します。今回はコールバック関数内でメッセージの内容をli要素としてul要素に追加しています。なお、onメソッドで登録されたコールバック関数はHTMLの初回読み込み時にも実行されるため、初回読み込み時用の処理を特別に記述する必要はありません。
4. messagesオブジェクトに子ノードを追加します。

オフライン対応の確認

さて、ここで一つ面白い実験をしてみましょう。複数のブラウザでサンプルアプリを開き、使用しているコンピューターのネットワークをOFFにしてください。

そのまま一方の画面でメッセージをいくつか入力すると、メッセージを入力した画面では新しいメッセージがリストに追加されますが、他方の画面にはメッセージが追加されません。

その状態でコンピューターのネットワークをONにするとどうでしょう。少し経って他方の画面にもメッセージが表示されるのが確認できるはずです。

ネットワークが正常

実はFirebaseデータベースの読み書きはいったんローカルDBを経由して行われています。そのためネットワーク接続が不通の場合もローカル側の処理は正常に完了し、ネットワークが回復すると自動的にデータがサーバーと同期されるのです。

ネットワーク異常発生

ネットワーク復旧

これによりアプリケーション開発者はネットワークの状態を一切意識することなくリアルタイムアプリケーションを作成することができます。

リアルタイムに状態を同期する必要がある場合、この機能だけでもFirebaseを採用する価値があるのではないかと私は思うのですが、みなさんはいかがでしょうか？

データベースの内容確認

サンプルアプリにメッセージをいくつか書き込んだらダッシュボードでデータベースがどうなっているか、内容を確認してみましょう。https://アプリケーションID.firebaseio.com/ にアクセスしてみてください。

データベース確認

ちゃんと登録されています。

ちなみにこのダッシュボードから値を変更することもでき、その場合ももちろんクライアント側のイベントハンドラが発火され、ブラウザ側の表示はリアルタイムに変更されます。

デプロイ

最後に、今回のアプリケーションをFirebaseにデプロイして実際に利用できるようにします。firebase initコマンドを実行したディレクトリでfirebase deployコマンドを実行してください。

% firebase deploy

=== Deploying to 'my-first-chat-app'...

i  deploying hosting
i  preparing public directory for upload...
✔  1 files uploaded successfully

✔  Deploy complete!

URL: https://my-first-chat-app.firebaseapp.com/
Dashboard: https://my-first-chat-app.firebaseio.com/

Visit the URL above or run firebase open

では、ブラウザで https://my-first-chat-app.firebaseapp.com/ を開いてみましょう。開発時と同じデータベースを参照しているので先ほど入力したメッセージがここでも表示されています。

ちなみにアプリのドメインは firebaseapp.com で、ダッシュボードのドメインは firebaseio.com です。うっかり打ち間違えないように気をつけましょう。

まとめ

いかがでしょう。Firebaseを使用すれば非常に簡単にリアルタイムアプリケーションが作成できるということが分かっていただけたのではないでしょうか。

今回はFirebaseの全体的な機能の概要を説明しました。次回はもう少し複雑なアプリケーションを作りながら、Firebaseのそれぞれの機能をより詳細に掘り下げていきたいと思います。お楽しみに。

BaaS / mBaaSという言葉をご存知でしょうか。この単語は「Backend as a Service」の略（mBaaSは、さらにモバイルアプリに特化したもの）で、サーバサイド（バックエンド）のコードをほとんど書かなくてもアプリを開発できるようにするサービスです。2013年にFacebookが買収したParseが特に有名です（以下、「mBaaS」で用語を統一します）。

mBaaSは主にモバイルアプリの開発に利用され、Webエンジニアにとっては少し馴染みの薄い技術ではあるのですが、これからのアプリケーションアーキテクチャを考える上では外せないトピックだと考え、有識者の方々にお集まりいただき、「仮想パネルディスカッション」を実施しました。mBaaSを作っている人と使っている人が入り乱れ、愚痴（？）からIoTに至るまで、mBaaSに関するトピックが尽きることなく話し合われました。

今、そしてこれからのアプリケーション開発を知りたい人必見の内容です！ ƒ

まずは自己紹介から

白石：本日はこれほど多くの「mBaaSを作る人」「mBaaSを使う人」に集まってもらい、光栄の至りです。まずは皆さん、自己紹介からお願いします。

石塚：石塚進です。
私はKiiという会社で、mBaaSを作っています。

井上：日本マイクロソフトのエバンジェリスト・井上大輔です。Microsoft Azureが持つmBaaSサービスを担当しています。私はどちらかというと、「作る」でも「使う」でもなく、mBaaSを「売る」立場ですが…ここにいていいんでしょうか（笑）。

白石：多様性があっていいと思います（笑）。では引き続き、物江さんから時計回りで自己紹介をお願いします。

物江：私も同じく日本マイクロソフトのエバンジェリスト・物江修です。普段はHTML5やJavaScriptといったフロントエンド技術を担当することが多いのですが、Microsoft Azureの担当でもありまして、今回は井上を引っ張り出してきました。

のびすけ：LIGの菅原のびすけです。mBaaSをいろいろ試した中で、MilkcocoaというmBaaSに惚れ込んでLIGブログで取り上げたりしていたら、エバンジェリストに任命されました。

槌野：アピアリーズというmBaaSを開発している槌野雅敏です。本日は、今後mBaaSはどうあるべきかってところを皆さんと議論したいと思っております。

田中：ノハナという会社でエンジニアをやっている田中和紀と申します。Parseをかなりハードに使っているので、そうした知見を共有できればと思っています。

BaaS / 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開発の実際

白石：トランザクションや複雑な検索といったお話が出ましたが、そういったユースケースにはやはり対応しづらいんでしょうか？

槌野:これはmBaaSというよりは、NoSQLデータベースの問題ですけどね。RDBの感覚で設計してしまい、クエリ量の増加やトランザクションの問題に直面するというケースはよくあります。

田中:そうそう、コツが必要ですよね。まず、そもそもデータベースを正規化しちゃいけないんです。

白石：そういうデータベースを設計する際って、どういうふうに進めるんですか？
まず正規化してから崩す？

田中:そうですね、僕らも最初は正規化して作ってましたけど、それをどんどん崩していった感じです。でももしかすると一番いいのは、モバイルアプリのコードをひたすら書いていって、結果的にできたDBを使うといった感じかもしれません。
サーバサイドから設計しない。モバイルからリクエストを投げると、勝手にテーブルやカラムになっていくので、それを使うのが結果的に一番きれいになる…かもしれません。キモチワルイですけどね(笑)。

石塚：そういう進め方、実際にありますね。ただ、iOSとAndroidは基本的に開発者が別々なので、それぞれがコードを書いていった結果、最終的にデータ構造が食い違っちゃったなんてこともあります（笑）。
サーバサイドの設計なしで始めるので、そういうことが起きるんですよね。もともと決まってればそれに合わせるんですけど。

白石：ちなみに、mBaaSのデータストアってMongoDBがよく使われているイメージがありますが、この中でMongoDB以外のデータベース使っている製品ってあるんでしょうか？

石塚：Kiiは独自でキーバリューストアを作ってますね。APIの裏側を全部差し替え可能にしてあって、サービスの特性に応じてストレージを切り替えられるようにしてあります。柔軟なのはいいんですが、Techieにやりすぎな面もありますね（笑）。

井上：NoSQLの話で盛り上がってる中、肩身が狭いんですが（笑）、AzureのmBaaSで使われるのはRDB（PaaS版のSQLServer）なんです。DocumentDBってサービスもあってそちらはNoSQLなんですが、デフォルトではありません。

白石：
実際mBaaS使うと、開発の流れとかは変わるんでしょうか？

のびすけ:データベース設計より先に、UI設計からいけますね。開発の入り方は変わると思います。まあ、キャンペーンとかの小さな短期的な仕事だから、ゆるい設計で進められるのですが。長期的になると、先にDB設計をしっかりやらないと後々大変なことになります。

田中:そうですね、長期的なサービスだと、まずDB設計はするでしょうね。で、僕だったら一旦設計した後、そこでリクエスト回数をどうやって減らそうかな、とか考える。通信が一番パフォーマンスに影響するので。 正規化を崩すとか、キャッシュ戦略を考えたり。
で、各mBaaSにafterなんちゃらとか、なにかした後に何かする機能とか、Cloud Codeとかあるんですが、そういうのは極力使わないようにする。スケールしなくなるので。あと問題なのはSDKの完成度ですね。Parseはあまり完成度が高くなくて…メインスレッドで通信しちゃったりするので…。

白石：ほんと、使い倒した方ならではのノウハウというか、バッドノウハウというか、愚痴というか、たまってますね（笑）。

個々のmBaaSサービスの特徴

白石：では、せっかくこれだけの方々にお集まりいただいたのですから、読者がサービスを比較する手助けになるように、それぞれのサービスの利点や特徴を教えていただけますか？じゃあまずKiiの石塚さんから。

石塚：そうですね、まずKiiは、サポートはなかなかのものだと思いますよ。日本語はもちろん、中国語や英語もいけますし。機能的な点では、今のところmBaaSのサービスはどれも似たり寄ったりかな、と思っています。

白石：ありがとうございます。
では次、マイクロソフトの井上さん。

井上：
え、いやー…いいところって言っても、そんなに…。

一同:えー！（爆笑）

井上：というのは冗談で、まずマイクロソフトはデータセンターが世界19カ所にあるんですよ。日本にも、東と西の2カ所ある。そして、1カ所あたり60万台くらいとか持ってます。AWSの2倍とかそんなレベル。
なので、スケールのレベルがぜんぜん違うと思います。あと、サポートって分野に関しては、マイクロソフトはかなり手厚いです。マイクロソフトのサポートって、社内でもかなり厳しく評価される立場なんで。Azureが持ついろんなサービスと連携できるのも強みですね。mBaaSとPaaSとか、管理用のサービスとか。

のびすけ:僕は開発スピードが重視されるキャンペーンの受託制作とかで使うことが前提なのですが、とにかくさくっと作り始められるかどうかを重視しています。サンプルやチュートリアルを少し触って、すぐに動かせるっていうのが大事。
そういう点では、Milkcocoaはすごくいいです。その他のサービスは、多機能なのはいいんですが、僕の立場からするとそこまでの機能はいらないかな、と。

槌野:アピアリーズは、受託開発とセットでできますよ、というのを割とウリにはしてますね。
親会社であるPCPhase社のリソースを活用できるのが売りです。

田中:Parseですが、まあ、最初の方に出たサービスですよね。
…特徴って、なんかあるのかな？（笑）。

白石：一時期は、「Parseを使っておけばとりあえず間違いない」みたいな雰囲気ありましたよね。

槌野:今でもそれはありますよね。Parseの成功を見て、追いつけ追い越せでやっている。だから、今は各社のサービスが似たり寄ったりになってる部分もあると思います。

mBaaS のこれから

物江：じゃあ、今後はどうなっていくんでしょう？開発者が自由度の高いバックエンドを開発できるようになっていくのか、それともブラックボックス化がより進んで、必要な物を組み合わせてサービスを作っていけるようになるとか、どんな方向にいくのでしょうか？

槌野:どちらにチャレンジする企業もあって、開発者がどちらを選んだかという結果によって、段々淘汰されていく…って流れじゃないかと思いますね。

石塚：私は今後もっとサービスの高レベルな部分、例えば分析とかですね、そういうニーズを満たすという方向にいくんじゃないかと思っています。

のびすけ:IoTの流れとかもありそうですよね。Web制作する側からすると、デバイスのセンサーデータを取ってくる部分はブラックボックスでもよくて、そこをBaaSが担ってくれる…という未来が考えられるかなと。

白石：相性はすごく良さそうですよね。
Parseも、先日のF8カンファレンスでIoT対応を発表しましたね。

石塚：
実はKiiも、去年の10月からIoT対応機能は載せてるんですよね。

井上：
あ、実はAzureも去年IoT対応してまして…。

白石：あれ、実は結構IoT対応してるサービスっていっぱいあるんですね（笑）。
むしろParse遅かった、みたいな？

石塚：そうなんですよ。なので実はアメリカの方では、mBaaSって単語の”m”を落として、”IoT BaaS”とか”IoTプラットフォーム”とかが毎週出てくるといった状態。ものすごくレッドオーシャン化しているんです。

白石：そんなことになってたんですね、知らなかった…！

田中:「mBaaSのこれから」っていう話で言うと、モバイルやIoTの分野に挑戦するベンチャーが後を絶たない昨今、mBaaSの重要性は今後も高まると思いますね。まず単純に工数の問題。アプリ開発はiOS, Android両対応が必要な上に、Web開発より工数がかかります。
次にリソースのフォーカスに関する問題。モバイルアプリはUI/UXが優れていることが第一。なので、必然的にフロントエンド側にリソースを重点的に投下していく必要があります。
最後に人材の問題。アプリのエンジニアは常に不足している状態ですので、これまでWebのエンジニアだった人にも、アプリ開発を担当してもらう必要があります。
こうした理由からエンジニアをサーバ開発に回すことが難しくなっているというのが実際で、今後もmBaaSは重要な位置付けになると考えています。散々Parseをdisったあとなので、説得力あるかはわかりませんけどね (笑)。

—— と、話は尽きませんが、ひとまずここまでとさせていただきます。 本記事で、BaaS / mBaaSという分野の現状と可能性が読者の皆様に伝われば幸いです！