SaaS の活用が日々盛んになってきている昨今。皆様精力的に SaaS システムを開発されていますでしょうか。
私は最近、子供とScratch3.0でゲームを作ったりしています。
マルチテナントシステムが利用者の個別要件を受け入れるためには
さて、マルチテナントシステムを提供する際の困難な仕事の1つは
- 「うちがこの製品を利用するにはこの機能が必要だ」
- 「ここにこのようなビジネスロジックを入れることができなければ使い物にならないね」
といった個別の要件を「この要件は全顧客に提供すべきだね」と取り入れながら「これを必要とするのは御社だけですね…」と払い除けることです。
しかしながら、そのような要求を声に出すお客様というのはやはりとても重要なお客様であることが多いので無碍にすることはできません。
またそのような要求を持ちつつ、追加開発を要求する予算や権限が無いというお客様も当然多いです。サービスベンダとしては提供するシステムを末永く活用していただくためにはお客様の個別の要求にも応えられる仕組みを備える必要があります。
実現方式
さて、ではそのような顧客の個別要件を受け容れるためにはどのようなやり方があるでしょうか。
ぱっと思いつくのは上記のようなものでしょうか。ざっくり検討していきましょう。
サービスベンダで開発
一番古典的です。サービスベンダが顧客の要求からカスタマイズを開発し、提供するシステムそのものに組み込みます。該当御客のときのみ機能フラグでその機能が動作するようにします。ソースコード中に「// ○○社様向けフラグ」みたいなのが入るわけですね。
これは(正しくハンドリングすれば)お金は大きくいただけますが、システムが抱える依存関係・負債も大きくなります。開発者が辛いだけでなく、システムの健全な成長を妨げる事が多いです。「○○社様向けカスタマイズの機能があるので、これを考慮すると新機能Xが入れられない」というわけです。また、システム本体に手を加えるため多くの会社のカスタマイズ要望に応えきれません。
APIやSDKの提供
現代的です。システムの拡張ポイントとしてREST APIやそれを呼び出す言語用のSDKなどを提供することでシステムをカスタマイズします。これにより、開発がサービスベンダのシステムの主担当チームだけでなく、他部署や他社のSIer、開発力のあるユーザー自身が行うことができるようになります。
これにより、開発者は公開したAPIやSDKをメンテナンスするだけでよくなります。また、個別の開発をスケールさせることができるので多くの顧客の要望に答えることができます。ただし、開発がスケールする代償として個々のカスタマイズの品質のコントロールが困難になり想定を超えた(異常な使い方をする)ユーザーが登場します。適切なリミッターやスロットリングをするだけでなく、カスタマイズ開発者の教育や開発体験の向上などに継続的に取り組んでいく必要があります。
独自DSLやその実行環境の提供
こちらも現代的です。システムそのものに独自のDSLを組み込みユーザー自身がカスタマイズを作成します。「カスタマイズできる」というよりも「もともと自由度の高いメタなシステム」という見え方になるかもしれません。 Salesforce では Apex などが提供されていますし、最近では low-code/no-code(LCNC) development platform と呼ばれるものもこれに当たると考えています。
システム利用者の裾野の広がりに伴って、システム利用者のうち開発力のあるユーザーの割合が無視できない規模になっているという市場の変化によって、ユーザー自身が手軽かつ安全に開発を行えるようにすることでカスタマイズの開発を更にスケールさせるという戦略が取れるようになってきたと言えそうです。
ただし、カスタマイズの自由度は独自DSLやその実行環境が提供する語彙・機能に限定されますし。これは、利用者側に謎な行いをさせないという点ではメリットになりますが、システム開発者は一段メタな機能の開発に携わることになるため機能要件・非機能要件の策定に苦しむことになるでしょう。
どうでしょう
私個人としては以下のような評価をしています。
やってみましょう
サイボウズ株式会社の kintone というサービスをベースに「独自DSLやその実行環境の提供」のプロトタイプを作ってみましょう。
できたプロトタイプが以下です。Chrome 拡張として実装していますので kintone ユーザーの方はお試し可能です。
説明
kintone ではアプリと呼ばれる RDBMS におけるテーブルのようなものを画面から定義することができ、それを用いて日常業務をなんだかいい感じにすすめることができます。詳しいことは こちら(kintoneの公式サイト)。
kintone では「APIやSDKの提供」によってシステムの機能を超えるカスタマイズの要求に応えています。
今回紹介したプロトタイプではBlocklyでラップする形で独自DSLやその実行環境および開発環境を作ってみました。
Blockly
Blockly とは Google が開発したビジュアルプログラミング環境を作成するためのライブラリで、その名の通りブロックを組み立てるようにプログラミングをすることができます。冒頭で出てきたScratch3.0でもそのコアとして採用されていますし、Microsoft Makecodeやプログルを始めとした多くの教育系プログラミングのサービスで利用されています。
Blockly は根本的にはプログラマから見ると AST エディタでしかなく、そこで構築した AST から任意の言語のコードや実行環境の呼び出しをすることでプログラムを実行します。ブロックを積むように AST を構築しているだけと考えると、多くの人が「括弧を並べて AST を構築してるだけの、自由奔放な言語があったような…」と思いを馳せる事があるかもしれませんがそれは別の話。
しかしながら、これから数年後の世代の人間はブロックプログラミングに触れた経験がある状態で社会人になる方が多数になる可能性があるので、システムのビジネスロジック定義にブロックプログラミングを導入するのは悪くない選択かもしれません。
この記事の目的
途中から話がおかしくなってきたことにお気づきかもしれませんが、この記事の目的はせっかく作った Chrome 拡張のユーザーが居ないので宣伝がしたかったということに尽きます。
kintone ユーザーの皆様や、興味を持った開発者の皆様はためしに使ってみてください。kintone アカウントがなくても開発用途であれば開発者ライセンスというものがあります。
それはさておき
マルチテナントシステムの設計やブロックプログラミングの活用などなど、夢があり楽しいことを日々やっていきましょう！
