10年を超えた「SmartHR」の課金基盤が抱えていた3つの課題
「SmartHR」は2015年のサービス開始から10年以上が経過した、人事・労務・情シス業務の効率化を担うSaaSだ。テナントはプランやオプションを選択して契約し、登録人数×単価で課金される。こうした課金情報を管理しているのが、サブスクリプション管理SaaSの「Zuora」だ。SmartHRの基本機能は内製のサブスクリプション管理アプリを通じてZuoraとやり取りし、各機能へのアクセス可否を判定している。
このアーキテクチャにはPull型の設計が採用されていた。SmartHR基本機能がプラン・オプション情報を必要とするたびにAPIを叩き、Zuoraから取得する仕組みだ。都度APIを叩くとパフォーマンスが悪化するため、21日間と長めのキャッシュを設けて対応していた。
しかしこの設計には3つの課題があった。1つ目はキャッシュ更新の煩雑さだ。契約情報が変更されるたびにキャッシュを手動で更新しなければならず、運用の煩雑さを招いていた。2つ目は、柔軟な契約形態の提供が難しいこと。テナント単位でプランオプションを管理する構造では、同一テナント内の雇用形態ごとにプランを変えるといった要望に応えられなかった。3つ目は技術的負債の蓄積だ。10年以上にわたり改修が継ぎ足されてきた課金基盤は、新規開発の足を引っ張るリスクがあった。
これらの課題を解決するため、Push型への移行プロジェクトが立ち上がった。新アーキテクチャではZuora側の契約情報が変更されると自動でサブスクリプション管理アプリを経由してSmartHR基本機能に連携され、DBに保存された情報を使ってアクセス判定を行う。
リードとは「道を作り、車を走らせる」存在
このプロジェクトのリードを担った由利氏は、SmartHRにおけるリードの役割を2つに整理する。ひとつは「プロジェクトの不確実性を減らすこと」、もうひとつは「プロジェクト完了に向かってチームが走れる状態を作ること」だ。由利氏はそれぞれを「道を作る」「道に車を走らせる」と例える。本セッションでは主に前者、つまりプロジェクトの不確実性を減らすための取り組みとして、4つのTipsが紹介された。
【Tips1】他チームとの調整：認識のズレを埋めることが最優先
課金基盤のアーキテクチャ移行は、2つのチームが関わる複雑なプロジェクトだ。SmartHR基本機能と内製のサブスクリプション管理アプリを担当するのは由利氏の所属する課金基盤チームだが、Zuoraを担当しているのは契約・請求管理を担当する別チームだ。後者はいわゆるビジネスサイドのチームであり、両チームの間にはコミュニケーションの機会が少なく、文化的な違いもあった。
この体制が招いたのが、移行計画をめぐる大きな認識のズレだった。由利氏のチームは「ある日以降、機械的に切り替えられる」「日付もある程度自由に決められる」と考えていた。しかし契約・請求管理チームに確認してみると、請求書や見積書への影響を考えると特定日での一括切り替えは難しく、契約更新のタイミングで徐々に移行する必要があることがわかった。さらに、四半期末の運用変更はセールスやCSにも大きく影響するというフィードバックも得た。
話し合うほど、両チームが気にしているポイントの違いが明確になった。課金基盤チームはシステム的な移行の安全性を重視していたのに対し、契約・請求管理チームは運用が今まで通り回るかを重視していた。「考えていたことにかなりズレがあったので焦りましたが、まずはこのズレを埋めることを最優先にしました」と由利氏は振り返る。
解決策はシンプルだが効果的だった。週次で定例会議をセットし、プロジェクト専用のSlackチャンネルを作成してコミュニケーションの総量を増やした。また、移行計画をタイムラインで図示し、双方のタスクの順序と作業日程を表形式でまとめることで、「いつ何をどの順番でやるか」を両チームが見える形に落とし込んだ。
結果として、請求書への影響を最小限に抑えつつ、新規テナントと既存テナントの区別なく徐々に移行する方針に合意できた。「他部門と協力してプロジェクトを遂行するためには、互いの考えていることを同期させることが重要です」と由利氏は語る。
