こちらのB/43を運営しているスマートバンク / SmartBankさんのB/43プラスを担当されたエンジニアの方々のTechTalkに参加してきました！
最初に
SmartBankさん！TechTalkありがとうございました！！ Fintech領域に触れるのが初めてだったので難しいところ多かったですが。 皆さんの雰囲気良くて楽しかったです！
お題目
- サブスクリプションサービスをつくる時にエンジニアが考えること
- クレジットカード発行システムの裏側
- ユーザー自由度の高い機能のためのテーブル継承戦略
- サブスクリプション機能制御の設計における勘所
- B/43プラスを作るエンジニア/PM/リサーチャー協業の裏側
- Q&A
サブスクリプションサービスをつくる時にエンジニアが考えること
学び
つくるものを決めるためには
- ユーザーに理解しやすい一般的な使用を探る
- とりうる状態の遷移を洗い出す
- ライフサイクルが重要
- 状態を減らすことで複雑性を軽減
- 状態遷移図を書き、要件による最小・最大の複雑性を比較
どうつくるか
- 登場人物（エンティティ、イベント、リソース）を整理する
- 参考になるドキュメントを参照し、リソースからデータ構造を整理
- 永続化をするデータを取捨選択
- 要件が満たせるかテーブル設計、ER図を確認
- 上のイメトレをした後にコードを一気に書く
つくったものの検証
- 日付・時刻に関するテスト
- 有効期限を短縮したり状態を更新したりするツールを利用
- App Store sandbox, Stripe Billing test clockを参考にした。
- 有効期限を短縮したり状態を更新したりするツールを利用
- 状態遷移テスト
- 状態遷移図から状態遷移表に整理していく
- 状態遷移表からテストケースを書き起こす
- 課金テストは中盤と後半で二回実施
クレジットカード発行システムの裏側
学び
- カード情報を扱うにはPCI DSSを取得する必要がある
- PCI DSSのスコープを小さくするためにシステムを切り出している
- PCI DSSを適用しているサーバーには直接リクエストが飛ばせない
- PCI DSSにより、本番ではログ（ファイル）が一切参照できないのでデバッグが少し大変
難しかったところ
- PCI DSS
- 生成鍵まわり
- HSM
ユーザー自由度の高い機能のためのテーブル継承戦略
学び
単一テーブル継承
- 一つのテーブルにプリセットもカスタムも入れる
- 単一テーブルなので横断クエリが書きやすい
- NULL 制約がかけられず、カラム数の肥大化が懸念される
- migration 時の影響範囲が大きい
具象クラス継承
- 全てのサブクラスをテーブルに分ける
- 既存テーブルとの migration 処理が大変
クラステーブル継承
- 継承フィールドのみをスーバークラステーブルが持つ
- 固有フィールドはサブクラステーブルに
- NOT NULL 制約問題の解消
- 表現するのに実装力がいる。
- Ruby では delegated_type を利用した
- CTI ならではのイマイチなところ
- カスタムカテゴリー登録日時を優先第一ソート、プリセットカテゴリの order を第 二ソートとして取得しなければならない
理解しきれていないところ
- テーブル継承パターン
- 単一テーブル継承
- 具象クラス継承
- クラステーブル継承
サブスクリプション機能制御の設計における勘所
学び
サブスクリプションの機能制御は大きく２パターン
- サーバー側で機能制御の処理が完結するパターン
- クライアントで制御が必要なパターン
- 明細に画像を追加できる機能などは導線を断つことで表現している
B/43プラスにおける機能制御の設計
- テーブル設計
- プランごとに使用可能な機能の範囲を定義
- 機能の使用に必要なプランをマスタ管理
- プランごとに使用可能な機能の範囲を定義
- アプリケーションロジック
- B/43 プラスを利用可能な範囲は B/43 カードが起点
- ロジックを段階的に分けて判定している
- API 設計
- クライアント側の状態管理設計
難しかったところ
- DI コンテナのインスタンスのスコープ管理
- 頭の中でイメージできなかった。
Why, What, How をつくる部分
- ユーザーアンケートとインタビューを行って機能に価値があるのか確認していた
- 企画からリリースまでのスパンは１年、開発は 8~9 ヶ月
- PRD に対してエンジニアが価値を出すには
- 仕様としての一般調査した内容をプレゼンする
- 仕様決定した際のリファレンスをログに残す
- What に対する取り組み方
- 機能の中にはファーストリリースに含めないようにしたものも発生した
- 実装プランを提案することで、MVP に対する議論を促した
- 機能の背景と価値がきちんと整理されていたので MVP の議論がしやすかった
- 機能の背景と価値を共通認識がもてるように整理することが重要
- PM として判断しやすかった点
- MVP に含めるに際してオプションをエンジニアから提案してくれたので判断しやすか った。
B/43プラスチームへの印象
- エンジニアとPM、UXリサーチャー + ユーザーで強く協力し合いながら仕事しているように感じた。
- なにを、なぜ、どうやっての部分（PRD）
- 開発だけでなく様々な業務に幅広く身を乗り出すエンジニアの方々ばかり
最後に
B/43プラスチームのTechTalkに参加して純粋に知見が広がったうえに 知見が広がったおかげで自分が理解できていないところがポロポロと出てきました。
TechTalkを開催してくださりありがとうございました！
