BtoB SaaS における技術課題との向き合い方 に行ってきた #BtoBSaaSTechnicalIssues

BtoB SaaS における技術課題との向き合い方に参加しました。オンライン開催。簡単に所感をまとめます。

sansan.connpass.com

所感

全体的に共感するところが多い内容でした。

チームごとに改善活動を持ち回るのはよさそう。ナレッジが組織全体で蓄積できるし。負債解消以上の改善については別チームや役割を設けるのがいいんだろうか。

テナントとユーザーの話は興味深かったです。ブログとか参考資料あとで見てみよう。フィーチャートグルも今のプロジェクトの中で検討してもいいかもしれない。

B2B SaaS だとドッグフーディングしにくいのは確かにありそう。ユーザーの業務をいかに吸い上げるかがポイントかもしれない。

しかし、SQLite のファイルをアップロードして同期を取るのはすごい...。(その発想はなかった)

以下、メモから抜粋。

SmartHR 基本機能の開発と並行してパフォーマンス系タスクを中心とした非機能要件に取り組んできた歴史

  • クロスファンクショナルチーム
  • スクラム (LeSS)
  • 履歴機能
    • 開始日/終了日
    • BiTemporal Data Model
  • モノリス
  • データ急増によるサーバー負荷
    • 初期開発ではパフォーマンスが考慮されていない (N+1とか)
  • 設計や使われ方の変化によるエラー増加
  • 規模が大きい問題は機能開発を止めて修正する
    • タスクフォース
  • 小さい問題の優先度判断が難しい
  • 有志の改善活動が滞りがち
  • スクラムで負債をどう扱うか
  • 改善活動に使う割合を固定する
  • チームごとに交代で改善活動を回す
    • 終わらなかったら次のチームに引き継ぎ
      • 引き継ぎコストは高い
    • チーム全体で学習できる
  • 改善タスクはエンジニアが管理する

BtoB SaaS におけるテナント・ユーザー設計の悩みどころ

  • Row-Level Security
  • テナント/ユーザー
    • 3パターン
    • いくつのテナントに所属できるか
    • テナントに所属しないことがあるか
  • ログイン
    • テナント指定 → ログイン画面表示
    • URL/ドメインにテナントを含める
      • URL直アクセスでテナント指定なしでログイン画面表示できる
  • テナント/SSO
    • 3パターン
    • idp がどう決まるか
      • テナントごと
      • メールアドレスドメインごと
      • ユーザーごと

デスクレスSaaSが向き合う現場DXのための技術課題

  • ホリゾンタルSaaS
    • さまざまな業界で利用される
  • 帳票のカスタマイズ (ノーコードで)
    • 内部データを木構造で表現
    • 大量のテーブルが必要
      • 階層構造を表示するため
      • データの型ごとにテーブルが必要
  • データ増
    • Goルーチンで並行処理
  • オフライン
    • 端末に記録 (SQLite)
    • オンラインになったら同期
      • SQLite ファイルをアップロードして同期

要望と機能開発の狭間を繋ぐ技術

  • 機能開発のトリガー
    • ロードマップ
    • 顧客要望
    • 開発チームからの提案
  • セキュリティチェック
  • 安定したサービス運用
    • 頻繁な機能リリースでワークフローやマニュアルの改訂が間に合わない
    • お客さまは「製品を使いたい」わけではない
  • シンプルでわかりやすいプロダクトであり続けたい
  • 機能フラグ (フィーチャートグル)
    • 分岐が増える
    • コードやサービスを利用してシンプルに
  • 機能フラグの分類
    • release toggles
    • experimental toggles
    • ops toggles (問題があったら蓋閉じ)
    • permission toggles
  • 機能フラグOFFでも機能の存在は見せたい
  • ドッグフーディング
    • 自社の運用以外が想像しづらい
  • カラースキームはカスタマイズ不可
    • 各色のユーザービリティは検証不可能

レジャー施設向けSaaSでの外部システム連携について

  • OTA
    • 商品を連携して他社サイトで販売する
  • 施設運営支援システム
    • 他社の商品マスタを取り込んで自社で販売する
  • 商品連携/販売連携/ステータス連携
  • 商品情報のうちどの情報を取り込むか
    • 連携先との依存を局所化する
  • 同期連携のパフォーマンス問題
  • 非同期連携のリアルタイム性
  • ステータス連携の方向をシンプルに
    • 双方向にするとどちらが正か煩雑になる
  • 連携方式の個別対応を分離したい
    • インタフェースを決めて共通処理と分離する
  • Webhook で個別の連携処理を外に出せそう