SaaS連携のパターンを分類して特徴をまとめてみた

自分達がやってることを整理するため、SaaS同士の連携にはどんなパターンがあるのかをまとめてみました。

以下、考えられる連携パターンを3つあげて特徴を記載し、それぞれ必要な業務知識、必要な製品知識、提供価値の切り口で難易度や価値を評価しています。

業界を俯瞰して作成したわけではなく、あくまで自社の視点で分類したものではありますが、他SaaSの視点で見た場合でもある程度当てはまる部分があるんじゃないかなと思ってます。

1. 情報や操作のショートカットを目的とするもの

ユーザーが頻繁にアクセスするSaaSから、他SaaSの情報を呼び出したり、他SaaSへの操作のショートカットを提供する連携です。

情報のショートカット連携には、コラボフローのサイボウズガルーン連携のようにポータルに情報を出すものや、LINEWORKSのBOTで申請書の到着を通知するといったものがあります。

また、操作のショートカットは、勤怠系のシステムでポータルのボタンを押すだけで「出勤」「退勤」を登録するようなものや、コラボフローのLINEWORKS連携のように、ボットに依頼するとコラボフローの申請書を探してくれる、といったものが挙げられます。

・必要な業務知識 
このタイプの連携は提案やサポートに業務知識を必要としませんので、取り扱いは比較的容易です。

・必要な製品知識
業務知識が必要ないとしても、相手製品に対する知識はそれなりに必要なので、むやみやたらに連携を増やすとセールスやサポートが困ります。

・提供価値
連携することで仕事を劇的に改善するというタイプでは無いので、他の連携パターンと比べると、提供価値は弱めかなと思います。

・その他の注意事項
ポータルに新着情報を表示するといった「交通量の多い場所」での連携を行った場合、朝に全社員が一斉にログインするなどで裏側のSaaSもアクセス集中の影響を受けることかあります。

2. 相互の拡張性UPを目的とするもの

kintoneのようなノーコード系のSaaSは、ユーザーによってセールス支援に使われていたり、出荷処理に使っていたり、契約に使われてたりとその利用シーンは様々です。

そのため、ノーコード系SaaSには様々な連携パターンがあり得ますが、この「相互の拡張性UP」はノーコードSaaS同士ならではのパターンかと思います。

例えばコラボフローとkintoneの連携では、双方がノーコードツール的なSaaSでありながら、コラボフローは「フロー」寄りの処理に強く、kintoneはデータを「ストック」する役割に強みを持つという特徴を持っています。

その特徴を理解した上で、お互いの強みを活かし短所を補いながら、一体となってノーコードでの独自業務を作り上げていくのが、この相互の拡張性をUPするパターンの連携です。

・必要な業務知識
対応可能な業務が多岐に渡るので、提案者には単なる業務知識にとどまらない業務ヒアリング能力が必要とされます。ある程度パターン化が進んで共有可能なノウハウが溜まれば少しは楽になりますが、それでもそう簡単なものにはならない難しさがあります。

・必要な製品知識
このタイプでは自社製品だけでなく、連携先の製品についてもしっかり知識を持っておかないとまともな提案はできません。考えなしに連携を増やしても効果は薄いと思われます。

・提供価値
この系統の連携がうまく進むと、ユーザー独自の業務にツールが溶け込み「仕事そのもの」になっていくので、うまくはまれば非常に高い価値を生み出します。

3. 別業務へのつながりを目的とするもの

会計とかセールスとか利用部門がイメージできるような「業務」にフォーカスしたSaaSとの連携です。PCAやfreeeなら会計、クラウドサインやAgreeのような電子契約サービスなら法務、SanSanなら営業といった感じですね。

この連携の特徴は「ここからはうちの範囲じゃないからボール渡します」って感じになるところで、業務をうまくパターン化できれば比較的楽にWinWinの関係が生みだせます。

・必要な業務知識
業務系では固有の業務知識が必要とされるので、連携がテンプレ化されている場合でも意外に提案難易度は高いです。会計知識とか法務知識とか、お客さんとさわりの話をするだけでも、そこそこの勉強量が必要だったりします。

・必要な製品知識
連携時はまるっとボールを渡す感じなので、ある程度の業務知識さえあれば、相手製品の細かい機能までを知ってる必要は無いと思います。

・提供価値
うまく業務をテンプレ化できれば、ユーザーへの提供価値も高く非常に良い連携であると言えます。ただ先に書いたように業務知識のハードルがあるので、自社で対応するだけでなく、対象業務に強い現場支援パートナーと組めればなお良しです。

・その他の注意事項
ボールを渡す際に相手が必要とする情報（会計なら科目コードとか）をしっかり揃えておくなど「連携機能の作り込み」に大きなパワーが必要とされる場合があります。

まとめ

あくまで自社から見た視点ではありますが、SaaSの連携パターンをまとめる事で、連携拡充の際に考慮すべき事を関係者に共有しやすくなったのはメリットかなと思います。

このまとめを見ていても分かりますが、SaaSベンダーが連携サービスを増やしていくにはかなりのエネルギーが必要となります。

あるラインを越えて連携を拡大していくためには、この課題にベンダー単体で立ち向かうのではなく、多くのパートナーさんから支援を得られるエコシステムを整備し、パートナーさんと共に課題にあたっていくのが重要になるということを改めて感じました。