BtoB SaaS における技術課題との向き合い方に参加しました。オンライン開催。簡単に所感をまとめます。
所感
全体的に共感するところが多い内容でした。
チームごとに改善活動を持ち回るのはよさそう。ナレッジが組織全体で蓄積できるし。負債解消以上の改善については別チームや役割を設けるのがいいんだろうか。
テナントとユーザーの話は興味深かったです。ブログとか参考資料あとで見てみよう。フィーチャートグルも今のプロジェクトの中で検討してもいいかもしれない。
B2B SaaS だとドッグフーディングしにくいのは確かにありそう。ユーザーの業務をいかに吸い上げるかがポイントかもしれない。
しかし、SQLite のファイルをアップロードして同期を取るのはすごい...。(その発想はなかった)
以下、メモから抜粋。
SmartHR 基本機能の開発と並行してパフォーマンス系タスクを中心とした非機能要件に取り組んできた歴史
- クロスファンクショナルチーム
- スクラム (LeSS)
- 履歴機能
- 開始日/終了日
- BiTemporal Data Model
- モノリス
- データ急増によるサーバー負荷
- 初期開発ではパフォーマンスが考慮されていない (N+1とか)
- 設計や使われ方の変化によるエラー増加
- 規模が大きい問題は機能開発を止めて修正する
- タスクフォース
- 小さい問題の優先度判断が難しい
- 有志の改善活動が滞りがち
- スクラムで負債をどう扱うか
- バックログ
- 機能開発との比較は難しい
- 改善活動に使う割合を固定する
- チームごとに交代で改善活動を回す
- 終わらなかったら次のチームに引き継ぎ
- 引き継ぎコストは高い
- チーム全体で学習できる
- 終わらなかったら次のチームに引き継ぎ
- 改善タスクはエンジニアが管理する
BtoB SaaS におけるテナント・ユーザー設計の悩みどころ
- Row-Level Security
- テナント/ユーザー
- 3パターン
- いくつのテナントに所属できるか
- テナントに所属しないことがあるか
- GitHub organization とか
- ログイン
- テナント指定 → ログイン画面表示
- URL/ドメインにテナントを含める
- URL直アクセスでテナント指定なしでログイン画面表示できる
- テナント/SSO
- 3パターン
- idp がどう決まるか
- テナントごと
- メールアドレスドメインごと
- ユーザーごと
デスクレスSaaSが向き合う現場DXのための技術課題
- ホリゾンタルSaaS
- さまざまな業界で利用される
- 帳票のカスタマイズ (ノーコードで)
- 内部データを木構造で表現
- 大量のテーブルが必要
- 階層構造を表示するため
- データの型ごとにテーブルが必要
- データ増
- Goルーチンで並行処理
- オフライン
要望と機能開発の狭間を繋ぐ技術
- 機能開発のトリガー
- ロードマップ
- 顧客要望
- 開発チームからの提案
- セキュリティチェック
- 安定したサービス運用
- 頻繁な機能リリースでワークフローやマニュアルの改訂が間に合わない
- お客さまは「製品を使いたい」わけではない
- シンプルでわかりやすいプロダクトであり続けたい
- 機能フラグ (フィーチャートグル)
- 分岐が増える
- コードやサービスを利用してシンプルに
- 機能フラグの分類
- release toggles
- experimental toggles
- ops toggles (問題があったら蓋閉じ)
- permission toggles
- 機能フラグOFFでも機能の存在は見せたい
- ドッグフーディング
- 自社の運用以外が想像しづらい
- カラースキームはカスタマイズ不可
- 各色のユーザービリティは検証不可能
レジャー施設向けSaaSでの外部システム連携について
- OTA
- 商品を連携して他社サイトで販売する
- 施設運営支援システム
- 他社の商品マスタを取り込んで自社で販売する
- 商品連携/販売連携/ステータス連携
- 商品情報のうちどの情報を取り込むか
- 連携先との依存を局所化する
- 同期連携のパフォーマンス問題
- 非同期連携のリアルタイム性
- ステータス連携の方向をシンプルに
- 双方向にするとどちらが正か煩雑になる
- 連携方式の個別対応を分離したい
- インタフェースを決めて共通処理と分離する
- Webhook で個別の連携処理を外に出せそう