ISV パートナーとして他社のプラットフォームで製品を開発する
はじめに
筆者は Now Platform(ServiceNow) や Salesforce Platformなどの他社プラットフォーム上で、弊社サービスの連携製品を開発しています。
クラウドに係わるエンジニアの方は、Sierとして各種クラウドサービスの導入に携わるか、AWSやAzure上に自社の製品・サービスを構築し、運用・開発を行っているケースが多いのではないかと思います。
自社のクラウドサービスを他社のSaaS/PaaS上で提供するための製品を開発する、というのは、クラウドサービス開発において縁辺にあると思います。
どのようなことをしているのか
馴染みのない方に向けて補足しますと、基本的に開発した製品は Google Play や App Store、Microsoft Store に似た、SaaS 型アプリケーションのマーケットプレイスで販売されることになります(ServiceNow Store、Salesforce Store (リンク先に弊社の製品が載っています))。マーケットプレイスで販売する以上、リリースするには他と同様プラットフォーム側による審査を通る必要があります。
開発に際しては、各種プラットフォーム上で製品を統合開発環境や開発・テストするためのインスタンス/組織が複数個提供され、製品の公開やサポートバージョンの管理、顧客へのサービス開始に必要な各種サービス(Store Publisher Portal/公開コンソール等)が提供されます。
多くの国産クラウドサービスにおいて連携というとマニュアルやAPIのリファレンスを提供するぐらいが関の山ですが、B2Bの世界でも市場の拡大を狙って海外のクラウドプラットフォーマーはこのような一連のプログラムを提供しているのが一般的なようです。仙道くんが言うように、「全国への道はなかなかに厳しい…」ようです。
我々のお客様は上記マーケットプレイスから利用しているインスタンス/組織にアプリをインストールし、利用を始めます。
海外の巨大なクラウドプラットフォーマーは日本においても当然それなりの販売計画を持っていますし、SaaSの特性上自社サービスの利用シーンは想定しやすいので、新しい市場を狙ってこのような連携製品を提供しようということになります。
具体的にどのように連携するのか
①プラットフォーム側のAPIを主に利用するケース
自社サービス内で他社クラウドサービス上で使うための設定を行い、プラットフォーム側のAPIを呼び出し、自社サービス内でサービスを提供したり、他社サービスからは自社サービスの呼び出しのみを行うケースです。
メリットとしては自社サービス内のため開発に制約がなく、運用時に細かな利用状況を把握することが出来る点です。デメリットは運用のコストが下記に比較して特に大きくなりがちな点です。
②主に他社プラットフォーム上で開発を行い、そこから自社クラウドサービスを利用するケース
利用が前提となる他社クラウドサービス上で稼働するため、AWSコストや運用工数の大部分が不要になることが大きなメリットです。逆に開発上の制約があるため、他社サービスを通した自社サービスの利用状況を把握することには限界(Salesforceはオブジェクトと画面のみ把握できます)があります。
通常プラットフォーム固有の開発スキルを習得する必要がある反面、開発効率は良くなります。標準機能に留まらない開発を前提とすると、だいたいどのプラットフォームも数日～数周間くらいのキャッチアップで、画面開発する場合の開発効率はだいたい３倍程度です。
未知の開発スキルを習得する必要があるため、①を選択する場合が多い印象ですが、プラットフォームから提供される機能や想定される市場規模などの状況に応じて使い分けるべきだと思います。
やってて楽しいか？
こうした海外のプラットフォーマーは、取り扱うSierのエンジニアにとって、文字通りキャリア・事業基盤となっているものですが、自社サービスを作るエンジニアとしてはプラットフォームを提供する側になりたいと思っても、使う側になりたいという人は少ないと思います。
ただISVのエンジニアをしていると、使うのは開発向けサービスに偏りがちで、他のB2Bのクラウドサービスを知る機会はほとんどありません。自社サービスのみならずいろいろなサービスの共通項やアーキテクチャー・仕様の違いを比較して理解することが出来るのが味わい深い点だと思います。
両者はクラウドサービスでありながらステップ実行が可能だったり、運用組織にサポートからの直接操作を受けられたり、無償の開発環境があったりなど、数多くの共通する優れた点があります。ただ今回は両者の違いの方に注目したいと思います。
アーキテクチャーの違い
中小～大企業までをカバーする Salesforceが、マルチテナントであり、基本的に同一のバージョン、同一のデータストレージにアクセスするのに対し、ITSMをメインに、それ故大企業を主な顧客とする ServiceNow がマルチインスタンスアーキテクチャーを採用し、別個のリソースを割り当てることで他のユーザの利用状況に影響を受けることなく、バージョンアップのタイミングも柔軟に運用することが可能となっています。大企業向けのサービスやSIのエンジニアにとっては、あぁ、お客様に言われたんだろうな…と想像できる部分があるのではないでしょうか？
他方 Salesforceのガバナ制限やAPIコール数、ファイルサイズやストレージ上限などの各種の制限の多くは、クラウドの常道であるマルチテナントのサービスを提供するエンジニアにとって、リソースの占有というリスクに対する確認すべき観点だと思います。
サービス・仕様の違い
我々がソースのリポジトリ内で社内の誰が書いたコードなのかを知るかの如く、ServiceNow ではスクリプトの一部のコードの中身や ServiceNow 側の作成者の個人名を目にすることが出来ます。これにはちょっと驚きますが、中々他のB2Bのクラウドサービスには無い文化だと思います。また ServiceNow が、メインとなるアプリケーションナビゲータやURLからサーバーキャッシュのクリア、CSV出力など様々なコマンド入力を可能にしてるのはそのアーキテクチャーもありますが、IT部門がメインユーザであるからでしょう。全体の雰囲気を通して、エンジニアが触っていて楽しいと感じるのはこちらの方かも知れません。
逆にSalesforceでは設定時のUIはエンドユーザーが使うUIからは完全に分離されていたり、トラブル時には許可された範囲でISV側からもお客様の組織での代理操作やデバッグが可能であったりとITリテラシが高くない部門の利用が前提である分、完成度が高いと思える点があります。
終わりに
B2Bのサービスは、基本的には合理的な判断に基づきバージョンアップを重ねるものなので、クラウドサービスも多くの共通する機能を持つ反面、やはり利用するユーザやサービスの業務シナリオによって違いが出てくるものだと感じます。またここでは敢えて取り上げませんでしたが、一見不可解な仕様やバグの対応されやすいタイプにも、各サービスの性格が現れていると感じます。開発者の意図や工夫が見えてくると、面白みが出てきます。
この記事が気に入ったらサポートをしてみませんか？