はじめまして、元Milkcocoaの開発者で、今はフロントエンドを中心にフリーランスのサービス開発おじさんをやっているのオチアイショウゴ（@_sgtn）です。ちなみに僕は炎上せしめられたCTOとは別の人です。いろいろありましたが、それぞれ求道者のようにもくもくやってますし、会社もこんな感じなのでめでたい限りです。
さて、Parse.com、終了してしまいましたね。Parse.comは、BaaS界のドンであり、BaaS至上最速でFacebookに売却をキメたヤツでしたよね。”なにができるか”が非常にわかりやすく、使いやすいサービスでした。
今回のParse.com終了騒動によって、Web界隈では賛否両論がごった返しています。
僕は、これはこれで良かったと思ってます。業界全体が適正な評価に戻りつつ、もう流れが一周したころに本当に便利な「バックエンドの抽象化」がおこなわれていくんだろうな、と。
僕自身はもともと国産BaaSの「Milkcocoa」を開発している株式会社Technical Rockstars（2016年2月4日に株式会社ウフルへ譲渡）に所属していたこともあり、中の人としてある程度業界や市場の流れを見てきました。今回は、いろいろと思うところを、「BaaSの中の人」と「BaaSユーザー」の間の視点からなるべく公平に書いていきたいと思います。
▼目次
- BaaSは本当に大丈夫なのか
- これからのサービス開発はどうなっていくのか
- BaaSで実際にできたサービス「Wowoo」
- 何故サービス開発にBaaSを選んだのか
BaaSは本当に大丈夫なのか（弱点）
まずは何より誤解を晴らしてしまいましょう。「Parse.com潰れたけど大丈夫？ BaaSって儲かってないの？ BaaSは本当に大丈夫なの？」という声に対して、私の所見を書いていきます。
ちょっとネガティブな意見が続きますが、「下げて上げる」ってヤツですので、後から褒めます。関係各位、お気を悪くなさらず。
商売の基本である「仕入れ」は確かに高い
ぱっと見渡した感じだと、AWS等のクラウドサーバー上で稼働しているケースがほとんどです。各社工夫して安いサーバーで運営したり、リソース利用効率を上げたりはしていると思いますが、基本的にフリーミアムモデルですから、利益率はかなり低い形になってしまい、損益分岐点を超えるまでもなかなかに時間がかかります。
この背景から察するに、 GoogleやFacebookに買収されたBaaSサービスは、まず人件費が上がります。超一級人材が投入されますから。そして、フリーミアムモデルなので超高額なサーバー代がかかっています。ウン十〜ウン百万円は余裕で毎月かかると思います。従って、完全に赤字部門と化しても不思議ではありません。
市場のパイが現状小さい
これは潜在市場と顕在市場の話になるのですが、「現存する全てのBaaSベンダーを支えられるほどの利益は、現状の市場からは供給されていない」という話になります。理想的にはバックエンド技術はどんどん抽象化されて、フロントエンド技術も次々にツールに置き換えられて、サービス開発はあっという間にコモディティ化するはずなんです。技術的文脈から見れば、そうであってしかるべきだし、そうあって欲しかった。その未来での「ツルハシ」にはお金が流れてきてほしかったわけです。
ですが、現実はどうもそうじゃないらしい。未だに多くのケースでPHPやRailsを使用した開発のほうが優勢で、一部の玄人がさらに楽をする道具としての利用法が多いです。ここにレイトマジョリティとのキャズムが存在しており、「Parse.com × Facebook」のタッグといえども、突き抜けることはできなかったという形になってしまっているようです。
現状、IoT開発者でWebと繋がったハードウェアを量産する段階にある人は少ないと思われます。その中でBaaSを利用する判断をする人も少ない。その一方で、Webサービスやアプリに関しても、BaaSでそこそこ大きくなったら設計力ある人が自前のサーバーへ載せ替えを始める流れは現状まだまだ避けられないでしょう。
収入源である「育ったサービス」が逃げていく構造と、収入にならない「伸びてないサービス」が積算する構造が前述の仕入れの高さと相まって、Parse.comやGo Instantの閉鎖が招かれたのではないかと思えます。
ペネトレーションを完了するも、市場の伸びの恩恵に預かれなかった
今度は市場の伸びの話です。マーケットペネトレーションという概念があります。市場のシェアを完全に奪い切ることですね。
Parse.comは業界ナンバーワンの座を得ました。さあいよいよ市場の伸びがそのまま自社の成長となるボーナスタイムかと思いきや、前述の理由でボーナスタイムは短かったのではという読みが出てきます。「タイミングじゃなかった」ということかもしれません。市場が伸びないということは、投資したお金の利回りは低いでしょうし、成長を前提に組んだ事業計画や組織構造はじわじわと運営を苦しめます。
こうやって事後的に分析するとまるで評論家のようで自分でも嫌気がさしてきますが、今回は評論家に徹しましょう。さあここで「なぜ今のタイミングでは伸びなかったの？」という疑問が湧いてきます。
これを私は「使い方が分からない＋まだ付加価値に見合うほどには便利ではない＋安定性が不安」というユーザー心理が「キャズムの向こう側のユーザー」の反応としてあったのでは、と考えています。
- ※「使い方が分からない」について
各プラットフォームで使い勝手は微妙に異なります。それぞれのノウハウがWebに溜まっていき、コミュニティが別々に分かれてしまいます。全てのプラットフォームで共通で使いまわせる情報の蓄積は少ないため、未だに「Webサービスを作る」という用途に関しては敷居が高く感じてしまう状況なのだと思います。
もちろん、熟達した開発者からしてみれば、「どれもそれぞれ機能の違うデータストレージじゃん」という話なのですが、おそらく、市場の反応からしてそれは少数派なのかもしれません。
特に、相対的に割合が多いであろうリレーショナルデータベースでのテーブル設計を主におこなうタイプのサービス開発に慣れているユーザーにとって「BaaSは”いわゆるNoSQL”」ですし、WebSocketをバリバリに使った開発スタイルは、HTTPのレイテンシを気にしてうんぬんするスタイルと勝手が違うので、BaaSは「ものすごい付加価値がついているのは事実」であると同時に「暗黙の予備知識」が膨大に隠れているのかもなと思います。
暗黙の予備知識が付加価値を減じてしまわないようにする鍵としては、サーバーレスアーキテクチャのフレームワークであるfluct内にAuth0やNetlify、Milkcocoa-nodeのようなモジュールが統合されていると、有料バックエンドとシームレスにつながっているフレームワーク同士で相性が良いのかなと思います。そういう意味で、Webサービス開発で本当に使いやすくなるタイミングは、「文化の流動性の低さ」を考えるともう少し後なのかなと思えます。
BaaSはデータベースだけを見ればNoSQLみたいなものですし、頻繁に処理の早い通信をおこなってクライアント側でデータ処理をするという特性上、データ構造がとっちらかったり、非同期地獄に陥ったりしやすい傾向があるのも、割とBaaSを触り初めてぶつかる問題です。何かクライアントサイドのフレームワークを使うか、しっかり自分でクラス設計をする必要が出てくるので、この辺りも補助線が必要とされているなあと感じます。
また、Parseサービス終了に対する雑感で言及されたように「課金面のユーザビリティ」も今後注目です。他に実装すべき機能が多いであろう中で贅沢かもしれませんが、突然バズった際にオートスケールできないというのは開発者にとって少し辛い。HerokuもフリーミアムのPaaSですが、こちらは課金移行のスムーズさのあまり、いつお金が発生したかわからない程度に鮮やかな課金体験（恐ろしい）だったの、そういった作り込みで改善されていくところなのだと思います。
安定性に不安がある
これは「技術的に安定しているか」ではなく「サービス運営が安定しているのか」という点で発せられることが多いのかなと思います。
当時、Parse.comはFacebookが運営母体になり、FirebaseはGoogleが運営母体になりました。これによって技術的にもサーバー代的にも安定すると思っていましたし、そう思いたかったのですが、Parse.comは終了してしまいました。
この現象の予兆はGoInstantがSalesForceに買収されたあとしばらくしてサービス終了した事案が、今にして思えば象徴的だったなと思います。Acqui-hiringといいますか、結果としてチームの技術力を吸収する形になる事例が多いのは、やはり初期のFirebaseの作られ方を見た感じ、技術的課題はある程度お金（サービス）で解決して、最速で駆け抜けてしまおうという姿勢からも感じられるように思います。
BaaSは技術的に安定か否かも重要ですが、それよりも「採算性が安定か否か」というのもポイントになるように思えます。無料分でけっこういろいろできてしまう上に、課金ハードルが高い状態はのちのち改善可能だとして、サーバーリソースをどれだけ効率的に使っているか、どれだけ人員が少なくて済む組織構造にしているかが、これからくるマクロ的な経済状況の悪化に対しても強さを発揮するのだろうなと思います。
結果としてParse.comから学べるのは、大きな会社に買収されても、その会社のインフラに移行するの結構な痛みが伴い、特に自動化している部分が多くあるのであれば、それを再実装するあたりなどが足かせとなり、固定費は高いままだったりするのかなといったことです。
かなり長いネガティブな評論になってしまいましたが、ここからは現状分析からくる今後の話です。
これからのサービス開発はどうなっていくか
まず、「サクッと作るフェーズ」と「しっかり作るフェーズ」が分かれる傾向が出てくるのかなと思います。BaaSは玄人を中心に、その事業ドメインにあった最適な設計を探るための道具として使われているのが今だと思うのですが、これがサーバーレスアーキテクチャと統合されてスケールするサービスでも継続的に使われていくのかなと想像しています。BaaSという名前自体は使われなくなっているとは思いますが。
それが既存のBaaSベンダーから出てくるかAWS等の巨人から出てくるかはわかりませんが、自前でサーバーを立てる気も起きないくらいの圧倒的な利便性を備えた技術スタックが出てきて、フロントエンドやアプリのエンジニアが喜んで使うような感じになればいいなと思います。個人的にはNetrifyとAuth0とMilkcocoaがfluctのモジュールとして利用されるサーバーレスな流れに乗ってくるとかなりキテるなって思います。
BaaSで実際にできたサービス「Wowoo」
実は、今回私が記事を書いている主な理由は「Wowoo」というサービスをMilkcocoaを使用して作ったことにあります。おそらくMilkcocoaで個人製作したサービスの中では結構しっかりしているほうだと思われるのですが、Wowooの開発過程でBaaSを用いたサービス開発の未来がちょいちょいチラ見えしたので共有させていただければなーという話だったわけです。ちなみに、アイキャッチにも使用した緑色の犬がマスコットキャラクターの「わうわう」です。
わうわうが着ているTシャツは、実際に配布もされているMilkcocoaのTシャツです。さて、今回はWowoo自体の紹介はそこそこに本題に集中してもらいたいので、Wowooの説明はサクッと済ませてしまいますね。以下FAQです。
Q1. 「Wowoo」では何ができるの？
A1. 付箋をデジタル化して、会議の時間を短縮します。
↓以下のボタンからお試しできます。
- /wowoo_create [板の名前]
/wowoo_search [検索文字列]
というコマンドを指定したSlackチームにインストールできます。バグってたらすぐ直しますのでお教えいただければ……（他力本願）
Q2. そんなサービス他にもあったじゃん
正直なところ、どれも便利に使えた試しがありませんでした。そのため、Slackで議論が始まりかけたときにスッと使える体験だけを考えて「Wowoo」を作りました。チャットでも現実でもファシリテーター不在な不毛な議論はしたくないという “強い負の想い”から生まれています。ソフトウェアがファシリテーターの代わりになるデザイン、人が自ずとファシリテーションをしたくなるデザインを心がけました。
Q3. どこを目指してるの？
初めはギークな組織が一切の議論をしなくて良くなるツールを目指しています。のちのち蓄積したデータの検索性能を上げて、slack botを介して人間が連想したり思い出したりする感じをチームでもできるようにしたいなと思ってます。
FAQはここまで。
アーキテクチャ
| ホスティングサーバー | Netlify |
|---|---|
| Slack用APIサーバー | Amazon API Gateway / AWS Lambda（これらを統合したフレームワークであるfluctはJSONインターフェースしか扱えないので、SlackAPIのから飛んで来るリクエストのフォーマットx-www-from-urlencodedと合わなかったため断念） |
| データストレージ | Milkcocoa（同時接続数100/約1500円） |
| ドメイン | NameCheap（$32/1年） |
| フロントエンド | jQuery（でどこまでいけるか試したかった/ver.2はElectron+React+Flumpt） |
| ソースコード管理 | Bitbucket |
何故サービス開発にBaaS「Milkcocoa」を選んだのか
僕自身がもともと「Milkcocoa」の開発をやっていたこともあり、内情を知っていました。しっかりインフラを作りこんでいることや、収益状況からゴキブリ並みの生命力で続けていくことを覚悟しているのだなという感じを受けたので、任せて安心だなという判断をしました。
Parse.comはhttpベースなこともあり、SPA的なサービスを作るつもりだったので選択肢から除外しました。FirebaseとPubNubも触ってみたものの、SDKの関数群の使い勝手がよくないので使うのをやめました。
Milkcocoaを使うにあたって、当時「サービスがちゃんと継続されるのか？」という不安があったのでMilkPubFireという「FirebaseとPubNubのSDKでMilkcocoaSDKのインターフェースを模したもの」を作ってみたりしましたが、今のところそれを使う機会もなく安定して動いているようです。
ほかにも、やはり自分のサービスに価値があるとわかるまではなるべくサーバー代を払いたくなかったという乞食マインドがあったり、同時接続数10人などというのは開発初期のサービスで定常的に使用することはないだろうという考えがあったり、なるべく少ない人数で開発するために、フロントエンドだけにフォーカスして、バックエンドは全てサービスに任せたいという判断で選んだ面もあります。
楽だったこと
NetlifyがLet’s encryptを利用してFreeSSLを提供してくれていますし、git pushでproduction buildできますし、最高でした。独自CDNも提供しているのでレンダリングも早いし、cacheを一瞬でpurgeしてしまう謎技術のお陰でキャッシュ関係のバグも少ないです（1回purgeされてなかったので問い合わせたら東京リージョンだけバグってたゴメンとのことで1日で修正してくれました）。
Slackとの連携部は全部Lambdaで済みました。今後のbot開発もLambda-botというnpmモジュールでいけそうです。月の無料分がだいぶ大きいので、全然お金がかからず完全にフリーライダーです。ごめんなさい、出世払いということで！
DBはMilkcocoaのnode版をLambda内で使うのがディ・モールト・ヨカッタです。PubSubもついているので「フルマネージド永続化Redis」みたいな使い勝手とでも言いましょうか。クライアントサイドよりもサーバーサイドで使ったほうが便利かもしれない。すごいぞMilkcocoa。
また、NoSQL的なデータ構造の強みと言いますか、不要な機能のデータはバッサリとデータストアごと捨て去っても罪悪感がないです（チーム開発的にはお行儀は悪いですが……）。思い立った機能を「テーブル設計が崩れて、モデルやコントローラーに変更が波及する」などと恐れずに、もりもりデータストアを作っては捨てて、機能の必要性や実現可能性を確かめることができたのは、粒の大きな実装に時間をかけて誰も使わないような状況にならずに良かったなと思います。
さらに、基本的にソケット通信なのでレイテンシも気にせずバッシバシDBに問い合わせて必要なデータをクライアント側で捌けるので、DBのパフォーマンスチューニング的な側面も無視できたのでよかったです。あとは、Auth0のおかげでSNSログインの実装が不要で、Auth0Lockというライブラリを使用すればログインモーダルもオシャレなので大変よかったです。
大変だったこと
jQueryで作るとどうしてもDOMに状態を持たせたくなる心持ちになるので、初めからReactにしておくべきだったなあと案の定後悔しました。辛い。Milkcocoaのon関数等非常に便利なのですが、容易に非同期地獄になりやすいのでPromise使ったりクラス設計しっかり目に頑張ったり、JS力問われる感じでした。
CassandraをDBにしたデータ設計ですが、連想配列だけでデータ整合性を担保するようなイメージなので、何も考えないでやると結構辛かったです。今後はLambdaの処理の中になるべくプリミティブなデータ処理（after_saveとかとか）を詰め込んでいきたいです。このへんはちょっとまだまだ研究中な面が否めませんね。
※細かい操作感を統一するためにCSS設計を頑張ったのですが、これはあんまりBaaS関係ないので割愛
さて、BaaSを使ってサービスを作るということの輪郭がボンヤリと見えてきたかと思います。こうやって徐々に徐々に水滴が岩を穿つように、抽象化されたバックエンドでサービスを作るのが当たり前な未来への下地ができていくことを願っています。
まとめ
今回の記事をまとめると、以下のようになります。
- BaaSは超便利
- BaaSはハードウェアに使うときとアプリに使うときと、それを複雑にするときでクセが違ってくる
- BaaSは使い方が簡単なように見えてもインフラサービスなので、上位サービスの障害でサービスが動かなくなるリスクをしっかり認識しよう
- クライアントサイドから頻繁にストレージを扱う部分でクセを感じることがあるかもしれないが、でっかい連想配列だと思ってまずは神経質にならずにバシバシ保存していこう
- とことん安く済ませたいなら、LambdaとBaaSとNetlifyの組み合わせがかなり便利
- Fluctフレームワークの今後の進化に期待したい
- BaaSという名前は単時点的なものなので、より本質的な概念を探していこう
- バックエンドの抽象化とプロトタイピング文化を一緒に育てていこう
情報の信頼性について怪しい箇所がありましたら、私のtwitterまでご連絡いただけましたら、調査した後に記事に反映したいと思います。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
