本記事の目次 (→シリーズの特集ページ)
何も作れなかった半年間の後、2週間でアプリケーションをリリース
――社名である「co-meeting」は、御社がリリースされたツールの名前でもあるのですよね。
木村:ええ、ディスカッションツールです。ニフティクラウド上で実装しました。現在も提供を続けています。co-meetingに続くプロダクトを検討するに当たっては、顧客インタビューから始めました。co-meetingは自分たちでニーズを考え、プロダクトアウトみたいな感じで作ったので、次はマーケットインでニーズが明確なものを作ろうと。飲食店向けのマーケティングオートメーションツールを作ろうとして、飲食店へインタビューに出かけたりもしましたね。
そして、インタビューをもとにアイデアを出すんですが、でもあまりニーズがないかな、みたいな行ったり来たりの繰り返し。気づいたら、何も作らないまま半年ぐらい経っていたんです。自分たちは作ることが得意なはずなのに、これはおかしいと。自分たちには、プロダクトを作りながらニーズを検証するアプローチのほうがいいんじゃないか。デモの紙芝居をつくるより、実際にプロダクトを作ってリリースしちゃったほうが早いだろうと、そこで気づいたんです。
――なるほど。
木村:それでまず、プロダクトを開発しリリースした上でニーズの検証が可能なプラットフォームを探したんです。インフラの構築や運用のコストがかからず、プロトタイプなりベータ版なりを素早くリリースできることが必要でした。また、弊社のメンバー(当時4名)は前職から法人向けソフトウェアの開発をやってきていて、ちょっとニッチでフロントエンドがリッチなWebアプリケーションを作るのが得意だったので、その強みを活かせることも重要でした。

――それで選ばれたのがSalesforceプラットフォーム。
木村:他に選択肢がなかったんです。検証を含んでいるので、構築・運用に手間がかからないPaaSがよかったのですが、エンタープライズ向けの機能を備えていて、固定のインフラ費が発生しないPaaSはSalesforce[1]以外にありませんでした。
――他のPaaSでは、開発者にかかってくる負担は大きく違うのですか?
木村:PaaSとしてはHerokuなんかが有名ですけど、IaaSに近いので、ある程度は運用監視をすることからは避けられません。IaaSで構築や運用をある程度自動化することもできますが、そもそもその環境を作るのが大変です。弊社は人数が少なくそこまで手が回らないというか、手を回すとアプリケーションを作っている時間がなくなります。
注
[1]: 正確にはセールスフォース・ドットコムが提供するWebアプリケーションプラットフォーム「Force.com」のこと。開発者がサーバーやミドルウェアなどの環境構築を行う必要がなく、ブラウザ上で画面やデータベース、ワークフローなどを定義(あるいはそのソースコードをアップロード)すればアプリケーションが動作するため、インフラの構築・運用の手間がかからない。
まずリリース! その上での仮説検証でノウハウを蓄積
矢野:あと、とにかくアプリケーションをたくさん作ってリリースしたかった、ということもありました。ニーズの当たりがついておらず、これでいけるんだっていうのが自分たちの中でも固まっていなかったので。机上で議論するのではなくて、リリースして検証できる環境を探していったときに、Salesforceしかありませんでした。
木村:仮説検証を机上ではなくリリースした上でやりたかった。しかも、法人向けがやりたかった。ただし、法人向けにはどうしてもコア機能以外に必要な機能があって、そこを個別に作っていると大変。特に大手企業では導入前に運用管理やセキュリティに関するレビューが実施されるので、それを突破するための機能強化も図らないといけない。これに苦労します。
セキュリティだけでなくアクセス権限の管理にも注文が付けられますが、作るのは結構大変でコストもかかるじゃないですか。Salesforceだとそういう部分を突破できるんですよ。プラットフォーム自体に、そうした法人向けの業務アプリケーションに必要な機能が大体そろってるので。コア機能の開発に集中できます。
――最初にSalesforce上でリリースしたものは何だったんですか?
木村:「SalesFollowUp」という、商談をカンバンみたいな感じで並べて表示するというアプリケーションで、無料でリリースしたんです。Salesforceに出す最初のアプリケーションだったんで、「こんなことがうちはできるんだよ」という名刺代わりみたいな感じで。大勢に利用してもらって、ノウハウを蓄積したいという思惑もありました。

――ユーザーからの反応はいかがでしたか?
木村:SalesFollowUpには、問い合わせといった形でフィードバックをいろいろいただきました。そこでから学べたところは多いですね。結局、Salesforceで最初に有償アプリケーション[2]を提供したのは去年の5月かな。有償のものを出すまでに時間はかかりましたが、やはり、とにかくリリースするメリットは大きいです。
――なるほど。まず無償のアプリケーションから始めてみるのはよさそうですね。
木村:ええ。有償アプリケーションだとセールスフォース・ドットコムへの支払いが発生しますが、ユーザーから代金をいただかない無償アプリケーションなら、アプリケーションベンダからセールスフォース・ドットコムに支払うお金も一切発生しませんし。
注
[2]: 「Cu-hacker for Salesforce」という、Salesforceを利用している企業向けのスケジュール(行動)入力支援アプリケーション。スケジュールや仮予定を一括で登録したり、画面切り替えなしで関連先やメンバーを追加したりできる。
Force.comは「無料」で試せます!
簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。
本記事の目次 ▼ (→シリーズの特集ページ)
AngularJSやReactでフロントエンド開発、MBaaS的にSalesforceを利用
――ところで、Salesforceアプリケーションの開発には、どのようなイメージをお持ちだったんですか?
木村:参入する前は、独自言語のApex[3]とVisualforce[4]でアプリケーションを作らなくてはいけないのが嫌だな、と思っていました。でも、参入を決めた一昨年の8月に調べてみたら……。
――思ったより最近ですね。
木村:最近なんですよ、1年半弱ですね。そう、調べてみたら、意外と流行りというか、シングルページアプリケーション的な作り方もできたんです。SalesforceのAPIかなりそろっていて、それらはREST APIでほぼすべての操作ができる。さらに、フロント側・UI側はAngularJSやReactなどが使えることも分かってきた。それだったら、これまでのノウハウが活かせて参入も大変じゃなさそうだし、つまらなくないのではと。今も、その作り方でやっているんですよ。
感覚的には、SalesforceのAPIをMBaaS(Mobile Backend as a Service)のようにして使っています。ただし、いわゆるMBaaSとは違って、APIはApexを使ってカスタマイズしたり、新規に作成したりできます。標準のAPIでは処理が足りなかったり、逆に無駄な処理が多くなったりするので、そういうところはApexでまとめたAPIを作っています。画面側は全部AngularJSなどで書いています。Visualforce固有の機能はほとんど使っていないですね。

――なるほど。Salesforce独自の言語やツール・機能ではない、一般的なライブラリやフレームワークなども使えるのですね。BtoBや業務のアプリケーションを素早く作りたいという人は食わず嫌いせず、トライしてみる価値はありそうですね。
木村:そうですね。ただ、面倒くさいところが多いのも事実です(笑)。歴史が長いので、積み重なった豊富な機能があるんですよ。それを理解するのが結構大変。データベース設計などにSalesforceの用語がたくさん出てきますし、アクセス権限などもにSalesforce特有の考え方があったりします。ApexやVisualforceだけ使って開発をするならよいのですが、弊社がやっているようにAngularJSやReactといった外部フレームワークなどを使う開発では、試行錯誤が必要になります。
――それでは、御社でも慣れるまでに時間がかかったのですね。
木村:でも、最初のアプリケーションはすぐに開発できたんですよ。さっき見せたSalesFollowUpは2週間ぐらいかな。
――あれ? あまり苦労されてないじゃないですか……。
注
[3]: Force.comプラットフォーム上で稼働するアプリケーションを記述するための独自言語。強く型付けされたオブジェクト指向プログラミング言語で、処理フローとトランザクションの制御ステートメントを、Force.com APIへのコールと組み合わせて実行できる。
[4]: Salesforceアプリケーションにカスタムユーザーインターフェイルを作成するためのForce.comプラットフォームの機能。
アクセス権限に応じたデータだけを返すSQLが便利!
木村:Force.comのデータベース機能は便利かもしれません。アプリケーションを開発するときには、データを格納するテーブルを定義する必要があります。Force.comではこのテーブルのことを「オブジェクト」というのですが、オブジェクトを定義するといきなり、それにアクセスするためのREST APIが自動生成されるんです。
――たしかに、それは便利ですね。
木村:だから、ほとんどデータベース操作がREST APIでできる。このREST APIにはただのCRUD[6]だけじゃなくて、SOQL(Salesforce Object Query Language)っていうSalesforce独自仕様のSQLを投げられるAPIもあります。SOQLによる問い合わせでは、オブジェクトへのアクセス権限を加味した結果が返ってくるんです。
アクセス権限の設定は、ユーザー側で行えます。これはForce.comが標準で提供している機能で、アプリケーションのユーザーが「この人はこのデータを見られる」「このグループはこのデータを見られる」みたいに設定できて、しかも、その結果がAPIにすぐ反映されます。このあたりはほんと簡単です。
通常、こうした設定をユーザーにやってもらうとしたら、そのための管理画面を作らなきゃいけない。これがまた面倒なんですが、Force.comだとその必要がないので楽勝です。
――各データのアクセス権限はどのようにして設定するのですか? レコード1件1件に設定していくことはできませんよね。
木村:そのレコードをつくったユーザーがどこに所属してるか。レコードをつくった人でアクセス権限が決まる仕組みになっています。
――なるほど。課長が作ったデータ(レコード)は課長以上は見られるけれども、係長以下は見られないとか?
木村:レコードを作った時点で、そういう感じになります。
――それはいいですね。以前はこうした設定をご自分の手で行っていたわけですよね。
木村:ええ、やっていました。手間はかかるし、本当につまらない作業。それをしなくて済むというのは開発者側としても本当に楽ですね。
――オブジェクトを定義するとアクセスAPIが自動生成されるというのは、少しRuby on Railsを彷彿とさせます。
木村:ただ、SOQLというSQLを投げることや、アクセス権限に応じたデータだけが返ってくる点で大きく異なりますね。Ruby on Railsだと単純なCRUD(読み書き)だけじゃないですか。SOQLはすごい便利なんです。あと、INSERT/UPDATE/DELETE文がなく、SELECT文しかありません。データの更新は違う方法でやります。REST APIにデータ更新を行うものがありますし、Apexにも更新メソッドがあります。
AWSも併用〜負荷にまつわる実際のところ
――御社が提供しているアプリケーションは、すべてSalesforceプラットフォーム上で稼働しているのですか?
木村:いえ、弊社が提供しているアプリケーションのうち1つは、SalesforceではなくAWS(Amazon Web Services)で動いています。Salesforceと連携するサービスなんですけど、ECS(EC2 Container Service)上に置いてます。Salesforceで動かないものも当然ながらあるので、適材適所でやっています。
――その1つはどのようなサービスなんですか?
木村:チャットUIでSalesforce上の情報を閲覧したり、Salesforceに情報を書き入れたりする「BotDock」というボットサービスです。このボットは仕様上Node.jsでしか稼働しないので、Salesforce上では動かせません。そのため、AWS上で動かしています。

――AWSにしたのはアクセスが多く負荷耐性が問題になるから、というわけではなく?
木村:違いますね。Node.jsが使えるという条件面からです。当初はHeroku[5]上で動かすことも検討したんです。でも当時、Herokuには東京リージョンがなく、満足なレスポンスを出せなかったんです。最近できましたけど。あとは価格面とか、そういうところで。
――Force.com上でのアプリケーションは大量アクセスがあるとその負荷に耐えきれないことがあると聞いたことがありますが、実際に問題になったことはありますか?
木村:そういった話は私も聞いたことがあるんですけど、今のところ、弊社で提供しているアプリケーションは、Force.comで耐えられないほど大きな負荷に直面したことがないんですよ。そもそも、弊社が提供しているアプリケーションは、各社個別にサーバーが立てられている中で使用される感じなので、そんなに負荷かからないんです。アプリケーションを利用するのはユーザー企業の人だけですし。
――ああ確かに。不特定多数の人が使うわけではないですもんね。
木村:弊社ではカレンダーアプリを主力プロダクトとして提供しているんですけど、あれだって例えば100人のユーザーがいて、毎朝8時に皆で開いたとしても、100アクセスしか同時に来ないわけです。大したことないじゃないですか。業務アプリってユーザーが制限されるので、負荷は大してかからないです。
矢野:それに、弊社が運用するサーバーにアクセスが来るわけじゃないですから。弊社は何もしません。アクセスとか負荷とかはSalesforceさんがさばいてくれます。
注
[5]: 米Salesforceが2010年に買収したPaaSクラウド。JavaおよびJVM上で動作する言語、RubyとRails、Node.js、Pythonなどを使ってアプリケーションを開発できる。
Force.comは「無料」で試せます!
簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。
本記事の目次 ▼ (→シリーズの特集ページ)
SaaSだからエンジニアがお客様に近いところで仕事ができる
――とはいえ、Salesforceでやっていかれるということは、Salesforceにユーザーさんが一定数いるって踏まないと、実際にアプリケーションを展開できませんよね。
木村:もちろんです。Salesforceにはすでにユーザーさんが大勢いることは分かっていました。実際のところ、そこも期待してSalesforceに参入したっていうのはありますね。あと、Salesforceだったら、セールスフォース・ドットコムの営業さんが売ってくれるかもなっていう期待感も持っていました。
――期待どおりでしたか?
木村:ええ、結構紹介してくれます。
――それってないですよね、他のプラットフォームベンダでは。
木村:ないですね。あと、Salesforceに限らず日本国内ではあまり盛り上がっていませんが、アプリケーションのマーケットプレイス(AppExchange)からはリード(見込み客の情報)が結構取れますし、そこから営業をかけたりすることもできます。マーケットプレイスには、公開しているデモやムービーを見た人の情報が得られる仕組みがあるんですよ、メールアドレスとか会社名とか。だから、その後に営業を行ったりできるんですね。無償のアプリケーションをリリースするといいというのは、マーケットプレイスに乗せておくとリードが取れるからでもあるんです。
矢野:また、SalesforceのようなSaaSでアプリケーションを提供すると、エンジニアがお客様に近いところで仕事ができます。現場の声が聞けるんです。一方で、オンプレミス型だと、ソフトウェアを開発しているエンジニアとお客様がすごく遠くなってしまうんです。

――SaaSだと現場の声が聞けるというのは?
矢野:この場合のお客様とは、IT部門の方ではなく、実際に弊社が提供しているアプリケーションを利用しているエンドユーザーさんです。SasSの場合、こうしたお客様とは直接ソフトウェアでつながっているんです。例えば、弊社のアプリケーションだと画面上にサポート用のチャットがあって、Salesforceさん経由でログインされていれば、弊社に直接お客様の声が入ってきます。
――エンドユーザーの声を直接聞けるというのはいいですね。コミュニケーションが取れると、トラブルも少なそうな気がします。
木村:トラブルが大きくなりにくいっていう感じですかね。
矢野:セールスフォース・ドットコムとお客様とは、信頼関係ができている感じがします。Salesforceには「代理ログイン」という機能があります。代理ログインは、サポートするベンダやセールスフォース・ドットコムが、お客様の管理者アカウントを一時的にサポート用に借りて、ログインできるという機能なんです。それでお客様の環境を直接操作してサポートする。もっと抵抗あるものかと思っていたんですが、大半のお客様はOKしてくれるんです。あれには驚きました。
――まるで、出入りの業者さんが勝手口から入ってきて作業しているという。
木村:ええ、そんな感じです。
矢野:それに、現地へ出向かなくて済むことは大きいです。作業するのに現地に行かなくてはならないと、数名しかメンバーの以内弊社では対応できないので。
――クラウドのメリットは、スモールスタートやスケールアウトだけではないんですね。人的リソースの限界を解決してくれる面もある。
矢野:現地にいかず、代理ログインを許容していただくには、お客様側の理解が、というよりは相当な信頼関係が必要で、それがSalesforceとお客様との間ではできている。これはすごいことで、業界全体でできているとはいえません。
――最後に、皆さんが起業したかった理由は何だったのですか? IT業界に対して、もっとこう変わればいいのにと訴えたいものがあったとか。
矢野:我々はソフトウェアプロダクトが好きですし、自分たちのソフトウェアが作りたい。意外とそこに尽きるかもしれません。
――純粋に、自分たちでソフトウェアプロダクトを作りたかった。
矢野:はい。自分たちで会社を立ち上げれば、ある程度自分たちでコントロールできるんで。そもそも、今回のような「とりあえずリリースして、リリースした上で検証しましょう」って、そんなプロセスを組織内で通せるとは思えないですしね。
――なるほど。本日は開発者にとってSalesforceプラットフォームは何が魅力なのか、具体的な話をお聞きすることができました。ありがとうございました。
Force.comは「無料」で試せます!
簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。