SaaS企業のプラットフォームチームとして大切にしていること

医療業界向けにサービスを展開するカケハシにおいて、私がプラットフォームチームのテックリードをする中で大切にしていることをできる限りこの記事にぶつける。

生成AIを使わずに執筆してみる。そもそも私が書く記事は以前から「論文チックに構造化しがち」と言われることも多いので、私が手書きしても生成AIっぽさが出てしまうが、これまで以上にメッセージやエゴを強く込めることでそれを払拭できていれば嬉しい。

なお、なるべく端的かつ一般化された読み物にしたいので、今回は具体的な事例やエピソードは省略する。

はじめに

SaaS企業の実態

いつ頃からかは覚えていないが、日本でもコンパウンドスタートアップを謳う企業が相当に増えた。というか、日本のSaaS企業のほとんどがコンパウンドスタートアップを名乗っている気がする。これはただ単にコンパウンドスタートアップという言葉が流行っているというよりも、日本というミドルパワーな国家の企業が課題を解決するビジネスをするならば、深いドメイン知識を活かして同じドメインの中で多様なサービスを提供していくことが生存戦略として定石であるからだ。もっと人口が多ければシングルプロダクトでも十分に戦えるだろうし、もっと人口が少なければ自国に特化せずにグローバルなプロダクト展開を目指したほうがいいからだ。

しかし、コンパウンドスタートアップを自称するSaaS企業の多くは、実態としてはただ単に複数のプロダクトを垂直に立ち上げたまま、顧客体験とデータの両面で十分な相互連携を実現できていない。この問題を放置すると、単に複数の独立した事業を展開していることとなり、メガベンチャーがやっているカンパニー制をより小さな資金力と人員規模で再現しようとするようなものであり、遠くない未来に存続が難しくなるだろう。つまり、コンパウンドスタートアップとして利益を出すためには、複数のプロダクトがシームレスに連携して相互に価値を高め合う必要がある。

これは、例えばUIコンポーネントを揃えることで解決するような問題ではなく、品質要求の多様化・高度化へ横断的に応え、データの相互運用性を高めていく必要がある。

品質要求の多様化・高度化

金融や医療や物流など、多くの分野ではシステムが24時間365日稼働することが当然に求められるようになっている。これまでオンプレミスで稼働しているシステムが多い事業領域でも、クラウドサービスを提供する事業者が増え、可用性に対する当たり前品質が高まっている。

サイバーテロも高度化している。金融庁や厚労省がそれぞれの事業者へ遵守を課しているガイドラインでは、二要素認証や監査ログなどのサポートが必須化されつつある。

そのような中で、コンパウンドスタートアップを謳うにも関わらず、それぞれのプロダクトチームが個別に求められている品質要求を検討し実現しようとするならば、顧客と向き合う時間をいたずらに減らし、プロダクトの進化を停滞させることになるだろう。

データの相互運用性

SaaS is deadという言葉が独り歩きしているが、実態としてはSaaSの役割が大きく変わりつつある。生成AIだろうが他社のSaaSだろうが独自の神マクロ付きExcelだろうが、それらとシームレスに連携できるように、公開されたインタフェースから洗練されたデータモデルを提供することがSaaSとして求められる能力となる。

そのような中で、顧客が求めているのはSaaS企業が提供するプロダクトに蓄積された多様なデータをシームレスに連携して活用できることだ。例えば、プロダクトごとにID体系が異なるような状況で、誰がそんなデータを連結して活用したがるのか。自分が顧客ならそんなプロダクトを今の時代に新規で選定したいか？

読者へ

この記事が、SaaS企業で社内プラットフォームシステムを提供するチームがどのような振る舞いをするべきかを考え、戦略的に行動するためのヒントやきっかけになればうれしい。

プラットフォームチームが存在しない組織で働いている人は、他のプロダクトチームの同僚と一緒に、数年後の自組織の事業のあるべき姿を考えて、そこからプラットフォームとして必要なものを逆算してみてほしい。

プラットフォームチームで働いている人は、チーム内外の同僚と一緒に、自チームが提供するプラットフォームにおいて、あるべき姿、足りているもの、不足しているもの、過剰であるものを分類してみてほしい。

既にプラットフォームがある組織でプロダクトチームとして働いている人は、プラットフォームチームだけではなく他のプロダクトチームとも連携することが大事であることを理解し、まずは雑談でも良いから他チームと対話するきっかけにしてほしい。

SaaS企業のプラットフォームシステム

認証基盤に求められること

プラットフォームチームとしてあるべき姿を考えるために、まずはプラットフォームシステムとして求められることを考えよう。

SaaS企業のプラットフォームチームは、多くの場合において認証基盤の統一から始まる。複数のプロダクトを導入した顧客にとって、一番最初に課題を感じる領域だからだ。それに、エンタープライズへの展開を目指すのであれば、パスワードの最低条件の厳格化や監査ログの記録が求められるだろうし、顧客のID基盤とのSSOが顧客のコーポレートIT組織にとって必須であることが多い。

認証基盤統一の功罪

しかし、実は複数のプロダクトが同じ認証基盤へ接続するということは、大きな価値とリスクを同時にもたらすことになる。

まず、認証基盤を統一することで得られる価値は、何よりもそのユーザーに関するメタデータを全てのプロダクトへ提供できるインタフェースを構築できることだ。そのユーザーの情報だけではなく、ユーザーが所属する店舗やグループや組織、さらにそれらに関連するライセンスや権限情報も全てのプロダクトへ提供することができる。今はそこまで作り込むことができなくても、将来的にそれぞれのプロダクトが独自に顧客のグループや権限を管理する必要をなくすための、とても大事な一歩になる。

一方で、これは裏返せば、誤った設計が全てのプロダクトへ不可逆的に伝搬させてしまうリスクも持っている。例えば、恒久的に一意であり汎用的なフォーマットのユーザーIDを提供できれば、将来的にプロダクト間のデータ連携も容易だろう。しかし、ユーザーIDとしてメールアドレスを採用している場合、メールアドレス変更機能が実装された時に各プロダクトのユーザーIDをリアルタイムに更新できなければ容易に障害となるだろう。また、ユーザーIDの体系が世代によってブレてしまうと、それぞれのプロダクトチームがそれに合わせて複雑なバリデーションや条件分岐を実装しなければならなくなる。

一度でも社内へ公開されたデータとその振る舞いは、その瞬間にプロダクトチームが依存しうるものになる。「プラットフォームチームが新しい完璧なID体系を構築したから、プロダクトチームの皆さんは今から1週間以内に移行してください」なんてことができるなら別にこのリスクを気にしなくてもよいが、プロダクトチームにはプロダクトチームのロードマップがあり、予算があり、人員計画があるから、そんな簡単に話は運ばないことに注意すべきだ。

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

十分にユーザー数が多いAPIにおいては、契約で何を約束しているかは問題ではなく、すべての観測可能な振る舞いは誰かしらによって依存される

ハイラムの法則

顧客ID基盤に求められること

認証基盤が統一された後、これを軸足に顧客ID基盤を展開できる。

これまで各プロダクトが独自に持っていた組織・店舗・グループなどの情報を、統一的かつ一元的に管理できれば、先述のデータ相互運用性を大きく向上できる。認証基盤と接続すれば、それぞれのプロダクトへユーザーがログインする時に、様々な関連データをプロダクトへ提供可能となる。

そして、ある程度普及してきたら、それぞれのプロダクトが顧客ID基盤からのデータ提供を望むだろう。あるプロダクトはAPI連携を要望し、あるプロダクトはイベント駆動を望み、あるプロダクトはデータ基盤で連携することを望むかもしれない。

さらに、顧客のシステムやデータ基盤ともうまく連携できれば、あらゆるプロダクトのデータ活用のハブとして顧客ID基盤はそれそのものが価値を生み出すことになるだろう。プラットフォームチームがコストセンターとして捉えられていた時代から脱却できると思えば、なかなか夢のある話ではないだろうか？

顧客ID基盤が注意するべきこと

ここで、顧客ID基盤を提供する上で注意するべきことを考える。既に認証基盤の功罪でも述べたように、ここで公開するインタフェースは一度利用が開始されれば半永久的に後方互換性が求められ、抜本的なデータモデルの変更はきっと不可能になるだろう。

先ほども少し述べたが、プロダクトチームが求める連携手段は多様だ。外的要因によって予算やロードマップが変化しやすいプラットフォームチームにおいて、これらの要求にすべて応えることは難しい。

ここで、「まずは提供できるインタフェースから開発・運用し、段階的に裾野を広げていこう」と思うかもしれない。それはプロダクト開発なら非常に正しい考え方だ。

しかし、プラットフォームシステムの開発ではそうもいかない。ソフトウェアは人間より圧倒的に変化に対して柔軟性に乏しい。一度でもあるAPIやデータへの依存が生じた場合、そのインタフェースを廃止するコストは、そのインタフェースを公開するコストよりもずっと高くつく。

ところで、顧客ID基盤を提供する上で、実はもう一つ注意を払うべきリスクがある。

可用性とパフォーマンスの問題を後回しにできるか

認証基盤も顧客ID基盤も、プロダクトチームにとっては必要不可欠なシステムであり、単一障害点であるとも言える。

結果として、これらの基盤は、顧客がプロダクトへ要求する可用性とパフォーマンスを背負うことになる。

一般的なプロダクト開発においては、品質要求について「問題が生じたら対策しよう」という方策を採用しやすい。可用性やパフォーマンスが顧客の要求を満たさない場合、一時的なスケールアウトや流量制限、機能縮小によって止血し、恒久的な対策を並行して進めることができるだろう。

しかし、プラットフォームシステムの開発はその限りではない。特定のプロダクトのワークロードが大きく変化した場合、その影響はプラットフォームを通じて他のすべてのプロダクトへ波及してしまう。全プロダクトのトラフィックを予測したキャパシティプランニングはとても大変だし、月日の経過によって変化してしまう。場当たり的なスケールアウトは顧客の信頼を損なうことになるので、「とりあえず最悪ケースを想定して大量にインスタンスを積んでおく」という結果につながるだろう。

さらに、プロダクトへ提供しているインタフェース次第では、そうした場当たり的な対応すら困難な場合がある。

例えば、イベント駆動を採用している顧客ID基盤があるとして、イベント配信を実現するための設計に根本的な問題があるとしよう。その基盤ではAWS EventBridgeを採用していたが、秒間で発行できるイベント数において引き上げ不可能なクオータにぶつかってしまったとする。

この場合、「来週からGraphQL APIを提供するので、来月までに切り替えてください」とすることもできないし、お金を払ってどうにかすることもできないし、これまで配信していたイベントの設計を抜本的に見直すとしてもプロダクト側が対応しなければ意味がない。顧客ID基盤への書き込み操作について流量制限しようにも、プロダクトごとにクォータを管理する仕組みを構築しなければ、組織全体へ与えるビジネス影響をコントロールできなくなってしまう。

コラム: IDaaSを採用するべきか

2020年代前半頃は、「自分たちで認証基盤を作らずにIDaaSを契約して運用するべきだ」という考えが一般的だった。SaaSを展開するスタートアップにおいては認証基盤はコストセンターであり、自分たちで内製してセキュリティリスクを背負うことはあまりにも不合理だと思われていたと思うし、当時は私もそのように考えていた。IDaaSはログイン画面やOAuth/OIDC/FAPIサポートを提供するだけでなく、その裏側にあるユーザー情報・組織情報・認証情報などをすべてマネージドに管理してくれるサービスであり、認証の専門家を抱えなくても高い品質で認証を実現できるものだ。

しかし、その後はAuthleteやOry Hydraのような、OpenID Connectの複雑なロジックの解決だけを肩代わりし、ユーザーや組織の情報、またパスワードやパスキーなどの認証情報は自分たちで管理する選択肢が増えてきた。また、IDaaSから非IDaaSへ乗り換える企業も増えている。

これは、単にIDaaSの料金体系が成長した各SaaS企業のニーズに合わなくなっているだけではない。

顧客がデータの相互運用性をSaaS企業へ求めるようになったため、これまでIDaaSが管理してきた様々なデータを、各SaaS企業のデータ基盤やID基盤と高度に連携させる必要が生まれているのだ。

さらに、レガシーかつガラパゴス化した顧客のIT環境・商慣習の上で、高度化するサイバーテロへ備える体制を成立させるためには、グローバルなIDaaS企業が提供する選択肢がフィットしないことが少なくない。日本では工場や医療や金融などの領域で閉鎖的なネットワーク構成に置かれた共用端末を採用しているケースが多い。そもそもGoogleアカウントやMicrosoftアカウントを持っていないユーザーや、メールアドレスを持たないユーザーも想定しなければならない。共用端末を前提とした環境にあって、ブラウザの拡張機能として利用するパスワードマネージャーを導入したり、OSやブラウザが提供するパスキーを前提としたサービスを提供したりできるだろうか。

プラットフォームチームのあるべき姿

ゴールから逆算して小さくつくる

プラットフォームチームは、プロダクトチームよりも長期目線でビジネス戦略やプロダクト戦略や技術戦略を考え、そこから逆算して今この瞬間にできることを考えなければならない。

これまで散々述べてきたように、プラットフォームというものはほとんどの場合において後方互換性を担保しなければならない。場当たり的な拡張が許されないから、最終的なプラットフォームシステムの理想状態を常に頭の片隅に浮かべておきつつも、その予測が外れても問題がないようにI/Fの追加・変更は小さくしておきたい。

もちろん、それぞれのプロダクトの戦略はそのプロダクトのリードが一番詳しいだろうし、外的要因によって市場環境はすぐ変化してしまうから、プラットフォームチームという立場から完璧な未来予想をすることは不可能だろう。しかし、どのような未来がありえて、その未来による影響範囲はどれほどであるか、その未来の発生確率はどれほどか、見積もっておくことが重要だ。

例えば顧客ID基盤ひとつとっても、「この業界で最も大規模な顧客企業の従業員数・店舗数はどれくらいか」が分かれば、テナントを分離する時のテナントあたりの最大のデータ量を見積もることができる。今は難しくても、将来的にそのデータ量を捌くことが理論的・原理的に可能かどうかは気にしておくべきだろう。

変更の可逆性を大切にする

人間は柔軟なエージェントシステムであり、UI/UXの変化へ自律的に順応できる。もちろん、例えばみどりの窓口で駅員さんが高速に操作する業務システムのUIを突然に変えてしまったら、凄まじい顧客影響を生むことになるだろうが、それでも最終的には順応してしまうのが人間だ。

しかし、プロダクトはあくまでプラットフォームシステムの機能・品質が後方互換性を持っていることを前提としている。ID体系であれ、データモデルであれ、連携プロトコルであれ、一度公開されたインタフェースは簡単に変えられない。

だから、可逆的な変更はすぐにやってしまえばいいし、不可逆な変更にはなるべく慎重になるべきだ。手を動かしてトライアンドエラーをすることは大事だが、そのインタフェースは半永久的に公開されるものか、その設計は今後数年間に渡って変更し難いものなのか、慎重に考えて進もう。

ステークホルダーと対話し続けよう

ほとんどのプロダクトチームは、普段はプラットフォームチームのことを意識しない。というか、その方がプラットフォームとして望ましい状況だろう。

ただし、プロダクトチームがプラットフォームチームへ何かリクエストしたくなった時、ほとんどの場合はもう十分な時間が残っていないものだ。「リリースまであと1か月ですが、何とかしてください」という状況では、ゴールから逆算してつくるどころではないだろうし、大体の場合はそういう時に実質的に解消不可能なほど巨大な技術的課題が生まれるものだ。

だから、今はプロダクトチームから求められていなくても、積極的にプラットフォームチームからプロダクトチームと会話しよう。

そして、実はプロダクトチームだけがステークホルダーではない。カスタマーサクセスやセールスのように顧客の課題を最先端で診ているチーム、契約管理や請求管理など重要なデータを管理しているチームなど、プラットフォームチームが関心を払うべきステークホルダーは多岐にわたる。すべてのステークホルダーと密接に連携し続けることは難しいから、それぞれのチームと自分たちの関連度を評価し、関連度が高いチームから優先的にコミュニケーションを図ろう。いきなり定例ミーティングを設定してもどうせうまくいかないから、まずは「あなたたちのチームは私たちにとって重要です！どんな課題を抱えているのかぜひ知りたいです」というメッセージと共に1on1を申し込んでもいいだろう。相手の立場に立って課題をヒアリングすることから始めよう。思わぬ発見があるかもしれないから。

おわりに

一緒にカケハシのプラットフォームを作りませんか。日本の医療の現場が直面している状況はそれなりにシビアですが、私はカケハシと一緒に少しでも日本の医療をマシにするつもりです。プロダクトチームは今困っている患者や薬剤師の課題に日々向き合ってくれていますが、プラットフォームという立場だからこそできる中長期的な取り組みがあります。この記事でもわかるように私たちが向き合っている課題は決して簡単ではありませんが、だからこその面白さがあります。ぜひ一緒に頑張りましょう。

【認証・権限基盤】バックエンドエンジニア - 株式会社カケハシ