それほどよいものなら、私たちのサービスやフレームワークがもっと流行っててもいいだろうと思われるに違いありません。
でも、流行ってないからといって短絡的にダメなものと決めつけてもいけません。

今日は、流行っていない原因とそれを解決できるかもしれない案について話をしたいと思います。

#「潰しが利かない」ジレンマ

特にBaaSについていえることですが、流行らない理由を一言でいうなら、「潰しが利かない」ということになるかと思います。

多くの開発者は、よくわからないBaaSのようなサービスや流行っていないフレームワークを使うよりはスクラッチで開発した方がいいと思うでしょう。私もそう思います。
なぜなら、情報量が多くて流行っているものであれば安心して使えるかもしれませんが、よくわからないものを採用してしまって、もしハマったら大変苦労するからです。流行っているから使い、流行っていなければ使わないというのは、鶏卵のように思いますが、現実はそんな感じです。

あるいは、短い開発期間しかないので習得に時間を割く余裕がないとか、採用した後で技術が古くなりメンテされない状態になったときに負の遺産化するのではないかとか、心配したらきりがありません。私たち自身、短納期が理由で、ある大規模プロジェクトでReactやAngluarなどのフレームワーク採用を見送りました。（この話は後日詳しく説明したいと思います。）

#可用性の低さも流行らない原因の一つ

「潰しが利かない」リスクには、いざというときでも問題なく業務を継続できるといった可用性も含まれます。

ついこの間、私たちのAWS（東京リージョン）のサービスがダウンしました。sshすらできません。インスタンスを作り直してもダメです。
問い合わせ先もなく、しばらく途方に暮れていました。
万事休すかと思いましたが、別のリージョンにインスタンスを立てることで復旧できました。

Google App Engineでも肝をつぶす瞬間がありました。ある日突然認証が通らなくなったのです。
それは、ClientLoginを廃し、すべてOAuth2に対応するための措置だったのですが、昨日まで使えていたサービスが突然使えなくなるのはとてもビックリします。(単に事前告知を忘れていたからですが・・）

こんな経験をすると、クラウドはもう怖くて使えないなと思ってしまいます。

世の中のBaaSやPaaSは、そこそこ流行っているものもありますが、多くは私たちと同じジレンマに陥っているような気がします。つまり、楽を手に入れるかわりに潰しが利かなくなるというジレンマです。
BaaSやPaaSがいまいち盛り上がらないのは、独自のルールに則る必要があって、気がつけば負の遺産化に陥りやすいこともあるかと思います。可用性の問題もしかりです。去年はこのジレンマをベンダーロックインという表現で説明しましたが、「潰しが利かない」リスクといった方がしっくりきます。

私たちのサービスも、ある程度の拡大は可能だとしても、「潰しが利かない」リスクが厳然として存在するかぎり、爆発的に普及することはないだろうとも思っています。これは、世の中のBaaSやPaasの今の状況を見れば明らかです。

#開発者自身が参加すれば話は変わる

一方で、開発者自身がプロジェクトに入るという条件であれば、意外とすんなり採用をＯＫしてくれることもわかっています。潰しがきいて安心だからです。

なので、私たちがセリングするときは、サービスやフレームワークを売りこむというよりは、ソリューションを提案したり、案件そのものを請け負って、内部でサービスやフレームワークを利用するといった感じになっています。

しかし、それでは、プロジェクトにジョインするか私たち自身が開発を請け負うかのどちらかの方法でしか広められないことになってしまいます。

ドックフーディングという意味ではいいのですが、このやり方ではスケールしないので、何らかのブレークスルーが必要です。
広く普及させるためには、「潰しが利かない」リスクをどう払しょくするかが鍵だと思っています。

#可搬性とインターオペラビリティでブレークスルー

元々、Google App Engineから生まれたvte.cx/ReflexWorksですが、いまでは様々なプラットフォーム上で動作するようになっています。
例えば、BaaSで動作する同一の業務アプリケーションをオンプレミスでも動作させることができます。
まずはBaaS(vte.cx)でプロトタイプを開発し、運用後に可用性などが重要になった段階でオンプレミスに移行するといったことが容易に可能なのです。

高い可搬性を実現できているのは、業務アプリケーションが基本的に疎結合であることが大きいと思います。
また、データストアに、BDBやGoogle Datastore、RedisなどのKVSの他、RDBなどを採用できますが、下位のレイヤーをアプリケーションから隠蔽しているため、どのプラットフォームでもAPIのインターオペラビリティが確保されています。

このように、vte.cx/ReflexWorksアプリケーションであれば、BaaSからオンプレミスまでカバーでき、ベンダーロックインや「潰しが利かない」リスクを排除できます。

vte.cx/ReflexWorksは、今はまだ採用のデメリットの方がメリットよりも大きいと感じてる人の方が多いとは思いますが、実績も豊富になって情報量が増えてくればおのずと多くの人が使ってくれるようになると信じてはいます。
もとより短納期の開発が可能になり、高い生産性と高い品質をもたらします。
そして潰しが利きます。
そんな良いものを拒む理由はありません。

それでは、また明日。