本記事の目次 ▼ （→シリーズの特集ページ）
本記事の目次 ▼ 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は「無料」で試せます！簡単なご登録ですぐにさわってみることができます。ご興味のある方はForce.comの下記ページから。
