amptalkが月間10万件の商談解析SaaSを生み出すまでのアーキテクチャ変遷

by Keita Suzuki

Slide 1

Slide 1 text

amptalkが月間10万件の商談解析SaaSを生み出すまでのアーキテクチャ変遷 AWS Startup Community Conference 2022 amptalk CTO 鈴木啓太 1

Slide 2

Slide 2 text

自己紹介 2 鈴木啓太 / Keita Suzuki amptalk 株式会社 - CTO @leonis_sk 好きな AWS サービス AWS CloudFormation アジャイル開発による内製開発の促進オンラインストア開発 (Frontend/Backend/Cloud) → 現職

Slide 3

Slide 3 text

3  オンライン商談・電話自動書き起こし解析ツールアンプトーク

Slide 4

Slide 4 text

サービス紹介 4 Slack Salesforce/ HubSpot Zoom Meetings Dialpad/ Zoom Phone 録画・録音データを自動で転送書き起こし・解析結果を SlackやSFAに出力

Slide 5

Slide 5 text

商談解析機能 5 書き起こし機能コメント機能話者分離機能トピック解析

Slide 6

Slide 6 text

開発にとっても嬉しい機能 6 お客様からの FB や機能要望を直接確認することができる社内 LT 会のアーカイブ

Slide 7

Slide 7 text

今日話したいこと 7 会社も資金も無い状態からプロダクト作りを開始現在は月間 10 万件の商談を解析するまでに成長アーキテクチャの変遷を振り返りながら、各事業のフェーズでどのような課題が発生し、どのような設計判断をしてきたかご紹介 ● これから事業作り・プロダクト作りを始めたい方 ● 事業作り・プロダクト作りを始めたばかりの方 ● その他 AWS でプロダクト作りをしている方一例として参考になれば

Slide 8

Slide 8 text

立ち上げ期 8

Slide 9

Slide 9 text

CEOとの出会い・プロトタイピング 9 ２人でプロトタイプ作りを開始最初のプロダクトは実商談解析ではなく、営業のトレーニング（ロールプレイ）を支援するもの 1. 営業が課題に従って音声を録音 2. マネージャーが評価 3. 高評価順に録音を聞くことができる

Slide 10

Slide 10 text

アーキテクチャ 10

Slide 11

Slide 11 text

設計判断 11 ● デプロイ・テストの自動化 ○ どうせ最初から最後まで必要なので深く考えずに初めから自動化事業仮説が正しいのかどうか、全く見えていない状態 ● とにかく早く動くものを ○ 「使い慣れていて早く作れる」ことを最優先に技術を選定 ● 認証（Cognito）などマネージドサービスは使い倒す資金（会社）なし ● 様々な無料枠が用意されている AWS は強い味方 ● 冗長化・スケーリングは度外視時間リソースなし

Slide 12

Slide 12 text

開発プロセス 12 プロダクトバックログとにかく早く動くものを → 最小単位の１機能ができるごとに即リリースログイン機能もなしで FB をもらいにいくことも ● 未成熟すぎて実運用で使ってもらえない ● Paying Customer でないと、口当たりの良いことを言ってもらえるだけになってしまいがち ● 誘導尋問になりがち ● 現場にとっては工数が増えるだけで嬉しくないプロダクトだと分かった ● ただのレコーダーとして利用している方も仮説検証を細かく繰り返すことが大切とはいえ、一番根本を間違えている状態で進み続けても未来がない

Slide 13

Slide 13 text

ピボット後（資金調達前） 13

Slide 14

Slide 14 text

ピボット 14 方向転換 ● 現場の営業にとっては練習の工数が増える面倒なプロダクト ○ オンライン商談を解析してフィードバックに繋げればよいのでは？ ○ → それまでのプロダクトを捨てる決断事業への自信 ● プロダクトファーストなチーム ● 前回の失敗 ● 1,000 人のヒアリングに基づく仮説

Slide 15

Slide 15 text

アーキテクチャ 15

Slide 16

Slide 16 text

設計判断 16 以前と比べ、事業拡大のビジョンが見えてきた状態 ● 将来的なスケールを見据えつつ、初期費用を抑えるためのサーバレスな構成（Lambda / DynamoDB） ● デプロイ・テストに加えて、アラート検知の仕組みも自動化 ● 解析処理やジョブは SQS で疎結合に ● インフラはすべて CloudFormation で作成 ○ 手作業撲滅 ○ 環境を一時的に増やしたい場合に非常に楽 ● シングル AWS アカウントに、複数の環境を作成していた商談の自動解析 ● 書き起こしは Amazon Transcribe など既存サービスを検討 ○ コスト・精度の面で断念 → 自前で作成

Slide 17

Slide 17 text

資金調達後 17

Slide 18

Slide 18 text

正式ローンチに向けて 18 ● $100,000 のクレジット付与 ○ コストを切り詰める必要がなくなった ● サポートも手厚いので、やらない理由はない ● 期限があるので、いつどれだけ申請するかは重要 AWS Activate 3rd party 連携 ● Zoom / Salesforce などの外部連携

Slide 19

Slide 19 text

アーキテクチャ 19

Slide 20

Slide 20 text

設計判断 20 セキュリティファースト ● 連携先のセキュリティ審査、セキュリティチェックシート対応 ○ 認証認可の仕組み改善、WAF・GuardDuty の導入などセキュリティ周りの徹底的な見直し ○ ISMS の取得 ● ユーザが増える前から継続して意識すべき RDS ● RDS Proxy が GA ○ 結合・検索・強い一貫性が必要なデータ → RDS ○ それ以外（個人設定など）→ DynamoDB AWS Activate クレジット ● うっかり高課金されたら...の恐怖が和らぎ、実験しやすくなる

Slide 21

Slide 21 text

正式ローンチ 21

Slide 22

Slide 22 text

正式ローンチ後 22 開発組織の拡大 ● エンジニアの数が増え、権限の委譲・精緻化が必要にアクセス数の急激な増加 ● リソースの使用状況やサービスクォータにより一層気を配ることが必要クレジット ● AWS Activate クレジットの終了後を見据えたコストの分析と最適化 → （元々課題ではあったが）AWS シングルアカウント運用が辛くなってくる

Slide 23

Slide 23 text

それまでのシングルアカウント運用 23 開発環境レビュー環境商用環境開発環境商用環境メインプロダクトウェブサイト機械学習

Slide 24

Slide 24 text

シングルアカウント運用の辛さ 24 権限管理 ● 管理アカウント保持者がボトルネックになっていく ○ アカウント作成・権限付与 ● IAM ポリシー設計が非常に複雑に ○ 名前やタグでリソースの限定をしないといけない ○ ちょっとした実験でも、IAM 設計が必要 ○ 常に商用リソースへのアクセスを気にしなければいけない

Slide 25

Slide 25 text

シングルアカウント運用の辛さ 25 リソースの競合 ● サービスクォータなどはアカウント内共通 ○ 検証環境での実験が商用に影響を与えてしまう危険性 ○ 商用デプロイ時にクォータ超過で失敗コスト切り分け ● タグ付けを適切に行わないと、細かいコスト分析ができない ● 「EC2 - その他」などでまとめられると辛い

Slide 26

Slide 26 text

マルチアカウント構成 26

Slide 27

Slide 27 text

マルチアカウントへの移行 27 AWS Control Tower ● まずはこれを利用することを考えるべき ○ AWS SSO (AWS Identity Center) やセキュリティ・ガバナンスの下地をよしなに作成してくれる商用稼働しているアカウントからの移行 ● 最も大事な商用リソースのみを元のアカウントに残し、それ以外を剥がしていく ○ 極力商用のデータ移行を発生させない ○ 複数の商用ワークロードが発生する前にやる！ ● CloudFormation を最大限に活用する

Slide 28

Slide 28 text

移行後 28 シンプルな権限設計と権限委譲 ● 開発環境の管理者権限を付与する、などシンプルな運用と権限委譲が可能 ● 実験したければアカウントを作成・不要になったら削除リソースの物理的分割 ● 商用への影響を与えない安心感わかりやすいコスト分析 ● 一括請求 ● マネジメントアカウントで、アカウント毎のコストが簡単に確認可能

Slide 29

Slide 29 text

これから 29

Slide 30

Slide 30 text

やっていきたいこと 30 さらなる組織拡大に向けて ● より柔軟かつ堅牢な権限設計 ● 学習用の AWS アカウントを安全に払い出す仕組みコスト最適化 ● AWS Activate クレジット終了 ML Ops ● SageMaker の活用を進めている

Slide 31

Slide 31 text

まとめ 31 事業仮説に自信が持てるまでは、とにかく早く動くものを数多くのマネージドサービスが無料枠とともに用意されている AWS は強い味方方向性が見えてきた時点でスケールを見据えた設計にセキュリティは早くから意識するに越したことはないマルチアカウント化は最初からやるべきだったテストやデプロイなどは永遠に必要な作業なので、はじめから自動化しておく We are hiring! （Frontend/Backend/AWS 全方面で採用中）私たちと一緒に「人と人が向き合う時間が最大化される世界」を作りませんか？ Meety amptalk 採用ページ @leonis_sk