昨日、BaaSでは何らかのブレークスルーが必要だという話をしました。
そのためには「潰しがきかない」リスクを排除する必要があると。
しかし、それでも爆発的に利用者が増えるかといえば、まだまだ不十分な気がします。
今日はその話をしたいと思います。
#成功のヒントはSaaSにある
クラウドでビジネス的に成功しているのはSaaSとIaaSです。
IaaSは標準化されたOSの世界で多くの人が理解できる一般的な環境を提供し、SaaSはエンドユーザがすぐに使えるパッケージを提供しています。
IaaSはまだしも、特殊な環境であるSaaSが流行るのはなぜでしょうか？
SaaSは「潰しがきかない」環境なのに、広く受け入れられているのは不思議です。
この辺りの話は、APIに標準技術を押し付けるのはやめろで詳しく述べていますが、実はSaaSのこのビジネスモデルこそ見習うべき点があるように思います。
#エンドユーザに直接訴える
私はエンドユーザとの距離がポイントだと思っています。
SaaSがエンドユーザに直接訴える一方で、BaaSやPaaSはどちらかというと開発者やシステム管理者に訴えるものです。その分、エンドユーザとの距離が長くなります。
エンドユーザは、中身はあまり気にせず、便利ですぐに使えるものを好む傾向にありますが、開発者やシステム管理者は潰しがきかないものを避ける傾向にあります。
BaaSも、広く普及させるには、開発者やシステム管理者に訴えるのではなく、エンドユーザに直接訴えるようにしないといけません。
#BaaSの特長を生かして訴求力を引き出す
BaaSの仕組みをくどくど説明したところでお客様の心には響きません。
その点、具体的なパッケージを持っているSalesforceやKintoneなどのSaaSは強いと思います。
訴求力をもつには、完成形のイメージがエンドユーザから見てわかりやすく、具体的なソリューションであるべきです。これらは、いわゆるエンドユーザ・コンピューティングに近いモデルだと思います。
一方で、BaaSはSaaSよりも柔軟性があります。
スクラッチ開発のような柔軟性とSaaSのスピード感を併せ持つのがBaaSです。
SaaSでは制約があってできなかった機能でもBaaSだと実現できたりします。
このBaaSの特長を生かした開発手法の一つにプロトタイピングがあります。
プロトタイピングでは必ずしもエンドユーザ自身が開発するわけではありませんが、エンドユーザの目線でアプローチすることができます。
今年、あるお客様で、vte.cxを使ってプロトタイピングを行いました。
要件をまとめながら、２～３週間かけてモックを作成したのです。
モックとはいえ、実際にデータ入力もできるし、本番と同じように動作します。
実際に動くものを見たお客様は大変な衝撃を受けたようでした。
その後、次のフェーズも受注に至ったのはいうまでもありません。
#BaaSでプロタイピングするメリット
プロトタイピングなら別にわざわざBaaSを使うことはないと思われるかもしれませんが、本番と同じように入力でき、検索できるシステムはそう簡単には作れません。
しかし、vte.cxであればプロトタイピングで本番利用できるシステムをサクっと作ることができます。
というより、要件定義や外部設計を行いながら本番システムを実際に構築していく感じです。
プロトタイプと本番システムの明確な区別はありません。
プロトタイピングしながら、要件定義や外部設計を行なえ、かつ本番システムの実装も進む。
一石三鳥ぐらいの話です。
もちろん、将来的にはスケーラビリティや可用性が要求されるフェーズが来ることも想定しなければなりません。
その場合でも、可搬性の高いvte.cxであれば大丈夫です。
初めはBDB(KVS)で作り、将来的にはそれをRedisやRDBなどに移行することができます。また、オンプレミスを含む様々なプラットフォームで動作させることができます。
#新しい開発手法との組み合わせ
BaaSとエンドユーザ・コンピューティングとの組み合わせは新しい開発手法をもたらします。
例えば、ソニックガーデンさんが提唱する「納品のない受託開発」では、
「１〜２週間の単位で作りたいものを決めて、それが出来上がってきたものを見て、また次に作りたいものを決めていく」というアジャイル的なやり方で開発を進めていきますが、vte.cxを活用することで、このような短いスパンでもエンドユーザに具体的なソリューションを小刻みに示すことができます。
この手法は、特に、スタートアップや新規事業における開発ニーズにマッチすると思います。
以上、述べてきたように、エンドユーザに近い目線でアプローチすることで、BaaS活用のメリットは大きく広がるように思います。
それでは、また明日。