SFDCには悪いですが、Force.comの正統な後継者の一番手はGoogle Apps Scriptかもしれない、という思い

先週 Google Apps Script 勉強会 #3に行ってきました。大遅刻で１０分くらいしか参加しませんでしたが。

とりあえず親睦会で気になってたことをちょろちょろお話できてよかったです。GWTを「ぐうぃっと」と読むことを教わりました。ありがとうございます。

さて、勉強会に参加したのとは直接関係があるわけではないのですが、今回あらためて記事にするのは、前回書評したアリエル井上さんの本にもとりあげられていたように、Google Apps ScriptはじつはS(P)aaS Scripting環境の大本命（いやいいすぎか、まあ少なくとも大穴）ではないかという予想にたって、では今現在世の中で名を馳せているだろうところのForce.comについてはいかがなものか、という想起を得たからです。

この記事を読まれる方の中には、Force.comって何よ、という方も多いでしょうので、若干説明しますと、セールスフォース・ドットコムという会社が提供している自社のCRMアプリケーションサービスの基板になっているプラットフォームの事です。昨今のクラウドブームもあり、誤解を恐れずに言えば主にスーツの間で注目されています。

もしForce.comを今までご存じなくて、そしてあなたがGoogle Apps Scriptを知ってとても感動しているのであるのならば、それは少なくともForce.comを見ておく価値はあります。Apps Scriptに感動している人は実際のビジネスでの応用の可能性の大きさについて感動しているのだという前提の上ではありますが、もしApps Scriptをビジネスで使う場合、その応用範囲はいまForce.comがビジネスとしている分野と大きくかぶってくるだろうからです。もちろん現在のForce.comでのビジネスがあなたの想定するビジネスの規模に達しているかどうかは知らないのですが、少なくとも一つの既存のモデルとしてちゃんと認識すべきかとおもいます。

逆に、もしForce.comをあなたの会社が利用しておりそれでビジネスを始め（ようとし）てはいるけれども、彼らがApps Scriptの存在すらもご存じないのだとしたら、大変な危機であると認識したほうがよろしい。なぜなら、おそらくそういう会社は、なんとか流行りものに乗っかって「よしおいらもクラウド始めたぜ」と安心しちゃってる残念な会社である可能性が高いからです。そういう会社はおそらくForce.comだけのビジネスですら危うい、少なくともおれはプロジェクト任せたくない。

…さて、最初に煽り調子で書きましたが、なぜこんなタイトルまでつけて、Apps Scriptをもちあげるのか。そして言っちゃ悪いがわけのわからんForce.comと比較するのか。それは両者に非常に共通するところが多いからです。以下それについて記します。

※ なお、以下では意図的にApps ScriptとSpreadsheetをごちゃまぜにしてます。なぜなら現時点でApps ScriptとSpreadsheetはなかなか切っても切り離せないものになっているからです。

共通点

サーバサイドのロジックが記述可能なマルチテナントのサービスである

これがまず第一の共通点です。Apps Scriptは、Spreadsheetのみならず、Gmail, Google Calendar, Google DocsなどのGoogle Appsが提供するアプリケーションに簡単に接続できる拡張言語です。

Force.comは、Salesforce CRMの基盤であり、基本的に営業管理、マーケティング、サービス＆サポートといったアプリケーションの機能を拡張する用途から生まれたものです。Force.comでは、Apexという言語によってビジネスロジックを記述できます。

マルチテナント性、というのは、特に重要で、それはコストに直結するからです。Apps ScriptもForce.comも共に、無償でのOfferが存在します。それが存在しえるのは、マルチテナントの恩恵によります。非マルチテナントではそれぞれにリソースが占有されてしまいコスト高になりがちで、なかなかサービスの期限なし無償提供というわけには行きません。

しかしながら低レベルのレイヤーで分離できる非マルチテナント型の環境と異なり、サーバロジックをマルチテナント環境でホスティングするには、セキュリティおよび共有リソースの配分の観点からより高度な制御を組み込むことが必要になります。そして、見事なことに、この両者はどうにかしてこれを実現できています。

共にExcelのクラウドへのリプレースを訴求している

Force.comの主力分野は、エンタープライズシステムです。ただ、企業内といっても、どちらかというと基幹系ではなく情報系のフロント・バックオフィスに使われています。つまり、いままでExcelが活躍していた分野です。もっというとNotesが活躍していた分野でもあるのですが、ExcelはわかってもNotesは知らない人がいるだろうので、あえてExcelのみにしぼります。

Excelによるデータ管理の最大の問題点は、情報の分散です。メール添付コピーによるマスターデータの混乱など、すこしでも情報共有の現場に携わった方ならすぐ想像できると思います。

Force.comはこれに対し、RDBMS的なアプローチでの移行を提案しています。これは、移行先がマルチテナントのクラウドになっているという違いはありますが、基本的にはサーバによる一元的かつ整合性を保ったデータ管理をめざす、という意味で伝統的なソフトウェアベンダーが唱えてきたこと同じです。

一方Google Apps Script、というよりGoogle Spreadsheetはもっと直截的に、Web上のアプリケーションにそのままExcelを持ってきました。多くの場合、スプレッドシート的なデータ管理が問題というよりは、そもそも最新データの共有が出来ていないのが問題だったりするので、まあこれはこれで一つの解です。

そもそもGoogle Docsはクラウド上での一元的なドキュメント管理サービスを提供していますが、そのなかでもSpreadsheetは、Excel的なUIがそのままWebで再現されていることもあり、ドキュメントの単位でなく行レベル・セルレベルでの更新が可能です。こうなればいわば簡易データベースとしても扱えます。そしてApps Scriptはそうした使い方にさらに拍車をかけるものです。

共にクラウド上でのアプリケーション配布手段を提供している

Excelの簡単なマクロをつんだシート、いくつかVectorとか窓の杜とかにあがってますね。配布のためには、わざわざVectorや窓の杜にアップロードして、ユーザはそれをダウンロードに行かないといけないですが、クラウド上のサービスであればそれはもっとシームレスに行えます。

Google Spreadsheet + Apps Scriptでは、Spreadsheetの中にデータもスクリプトも含めて、公開し、それを各々が自分たちの環境に複製できます。Force.comでは、AppExchangeという仕組みによって、作成したコードおよびデータベース・スキーマ、アプリケーション・メタデータの配布が簡単にできます。前者は「ドキュメントのコピー」というメタファでそれを実現しているのに対し、後者はあくまで「インストール」というメタファで行っているところはやはり出自の違いです。

リード取り込み、決裁ワークフローなどの応用ユースケースが共通している

Force.com、というよりSalesforce CRMの重要な使い方の一つに、Webや電子メールからのリード（＝見込客）取り込み、というものがあります。セミナーやイベントの集客ページなどから、簡単に申込者リストを作ることができます。Salesforce CRM の提供するWeb-to-リードとは、Web上のフォームから入力された情報を元に、自動的にSalesforce内のデータベースに登録する機能です。言っちゃ悪いですがやってることは至極単純です。でもクラウドでそれが動いてるってところに価値があります。みんなそんな単純なシステムのためにシステムのお守りをしたくないものです。

さてGoogle Spreadsheetでは、そのままフォームという機能があります。申し込みページも（単純なものですが）簡単にホストできます。まあ多くの場合これで十分です。そしてApps Scriptによって、フォームから登録した時に自動的にメール返信などのような自動化もお手のものです。Web-to-リードで実用に耐えているのであれば、十分これでも実用に耐えられます。

ワークフローについては、Force.comはなかなか強力です。承認や却下、条件による分岐などのようなワークフローエンジンが備えるべき機能はあらかた備えており、それらは全てワークフローエディタから宣言的に行えるのも魅力です。

Apps Scriptについては、どうでしょうか。宣言的な方法はまだ提供されていませんが、Apps Scriptを使えばワークフローのロジックを組む可能であることは確かです。ワークフローの実現に関していくつかのサンプルも用意されています。そして、ただのワークフローエンジンとは違って重要なことに、Gmailとの緊密なインテグレーションがあります。メール受信などのトリガを利用したフローに対して特別な連携の配慮が要りません。

Google Apps Script（& Google Spreadsheet）の優れた点

さて、これは煽り記事なので、若干Google Apps Script陣営に好意的に書きます。

すぐれたマルチレコード編集のユーザインターフェース

Excelの良い点は、簡単にデータを編集できるというところです。とくに複数件のデータを一括で変更しようとするときなど、CRUDのみを実直に実装したようなWebシステムではなかなか難しいですが、Excel上では簡単にできてしまいます。

よくExcelからWebシステムへの移行案件で「ExcelがそのままWebでできるとおもってる客いるんだよね、ふざけんな」っていうベンダー・SIerの言葉を聞いたことがあります。つまり彼ら曰くどうしても顧客が両システム間のギャップについて承認しないのだそうです。システムの移行に際してあまりにも前のシステムでの経験にとらわれてしまうのは実際どうかとは思いますが、Google Spreadsheetの存在はそのような泣き言をベンダー・SIerに許さない厄介な存在です。今後はなし崩し的に、Excel的、Spreadsheet的なユーザインターフェースが最低条件でもとめられてくる可能性はないとはいえません。ならば「もうSpreadsheetの上でアプリ作っちゃえ」っていうのは、もしかしたら賢明な判断かもですよね。

残念ながらForce.comは、その他大勢のWebアプリケーションと同様に、そのようなレベルでのマルチレコード編集のユーザインターフェースを標準で持っていません。「ある」と強言する人は、ほんとうにそれを同一視していいのかどうかちゃんと心のなかの声に聞いてみてください。

ビジネス・ロジックが汎用言語で書ける

Force.comでは、ロジックの記述にApexという”独自”言語を使います（きっとこのことを書いた時点でこの記事の読者は半減しますが、書かなければいけません）。Apexを紹介する際によく言われる「ApexはJavaによく似た文法です」というステートメントがあるのですが、Javaが往時のCOBOLと比肩されるような近年ではむしろネガキャンになる可能性すらあります*1。実際のところ、このメッセージは、ともすればJava陣営からも突き出しを食らう可能性のある、百害あって一利あるかどうか微妙な表現です。最近ではもっとぶっちゃけて「Javaにくらべて生産性５倍」と言ってますから、別にもう敵対しようがどうしようが構わないのかもしれません。岡本くんいわく「DSLとしてみてやれば優秀」らしいので、それはそうかなとも思います。

さて、Apps ScriptとはつまりJavaScriptです。汎用言語であるので、言語レベルの素養はわざわざ勉強しなくても他から得ることができます。しかもほかのサーバ言語がケースバイケースで選ばれるのに対し、JavaScriptはほぼWeb開発者には必須の知識です。

なおJavaScriptをコンパイラによる型チェックができないことを理由にエンタープライズ向きでない、とする意見もあるかもしれません。僕個人としてはその意見自体にも若干疑問はあるのですが、そもそもSpreadsheetに型があるわけでもないので、ある意味それで構わない、むしろこの環境で厳密な型づけを行うのはオーバースペックだとも言えなくもないような気がします。

ドラッグ＆ドロップでのUIエディタ

Apps ScriptのGUI Builderとは、ついこの前のGoogle I/Oで発表された、まるでVisual BasicのようにアプリケーションのユーザインターフェースがGUIで構築できる、という機能です。

http://code.google.com/intl/ja/googleapps/appsscript/guide_gui_builder.html

オンラインでのWebブラウザ上でのドラッグ＆ドロップベースのユーザインタフェース構築については、結構昔から様々なプロダクトで取り組まれていたものであるため、新規性という意味ではそれほどではないかもしれません。しかし確実に有用です。可能性を広げます。

Force.comにもおそらく近日中に同等のものが持ち込まれる可能性はありますし、本家以外でよければ3rd Partyもいろいろ取り組んでいるのは知ってます。ですが、本記事執筆の時点でベータとしてもリリースできていないことは確かなので、Apps Script陣営の利点としてとりあげます。

コンテナによるOAuth接続のサポート

これは、APIがOAuth対応してるかどうかということではなく、コンシューマ側としてのOAuth接続のことについて述べています。Apps Scriptのこれは本当にすばらしいのでわざわざ取り上げてしまいましたが、いまいち伝わらなそうなので別記事にします。私見では、アプリケーション・プラットフォームとはこういうモノを言うのだと思います。

Force.com ApexからでもコンシューマとしてOAuth接続はできますし、よってTwitterとかに接続もできます。でも他のサーバでやるのと変わらないです、言ってみれば及第です。Apps Scriptのそれは違います。（今のところではありますが）首席級です。

Force.comの優れた点

一応公平性を装うために、Force.comにのみ○がつくところも上げます。ですが、あくまでApps Script側の人に紹介するという観点のみです。このほかにもいいとこあるのは知ってたような気がしますけど、めんどくさくなったのでやめますごめんなさい。聞きたかったら直接聞いてください。

行レベル、カラムレベルでのアクセス制御

僕の知る限り、最大のSpreadsheetの弱点は、アクセス制御単位がドキュメント（スプレッドシート）レベルである、ということだと思います。Excelの延長として使う分には構いませんが、データベースとして扱おうとすると無理が出ることもあります。無理するとロジックが肥大化する原因になります。

Force.comは行（レコード）レベルでのアクセス制御はもちろん、カラムレベルでR/Wアクセス制御できます。データベースにエンドユーザレベルでのセキュリティが組み込まれており、アクセス制御設定はロールベースで宣言的で、変更は容易です。アプリケーションロジックがThinであっても安全である理由です。

最後に

お気づきの方も居らっしゃったかもしれませんが、この記事のタイトルは IBMには悪いですが、Notesの正統な後継者の一番手はsalesforceかもしれない、という思い — ありえるえりあからいただいていますことを、とりあえず言明しておきます。

なお、誤解してほしくないのは、べつに「Force.comはオワコン」といってるわけじゃない、てことです。ただ以前と比べて明らかにWebの進化は早いし、辛抱強く粘っているレガシーを駆逐し追い落とそうとやっきになってる最中に、後ろからやってきた新参者がするっと開拓した道を通って行く、というシナリオは十分あり得るわけです。そうしたとき、カスタマーサクセスこそが第一であると教えられてきた人間が、ほんとうにその教え通り正しい決断を下せるのか。それには常に周囲の動きを客観的かつ冷静な目でみつめて、謙虚に勉強していくしかないと思うわけですよ、実際。

*1:嘘ですごめんなさい