Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
電話を切らさない技術 電話自動応答サービスを支える フロントエンド
Search
sagawa / barometrica
November 23, 2024
Technology
2
3.4k
電話を切らさない技術 電話自動応答サービスを支える フロントエンド
2024/11/23
JSConf.jp 2024
https://jsconf.jp/2024/talk/ivry/
こちらで登壇した際の資料です。
sagawa / barometrica
November 23, 2024
Tweet
Share
More Decks by sagawa / barometrica
See All by sagawa / barometrica
RubyKaigi 2025 カスタムスポンサーの裏側:壁編
barometrica
0
40
無理のない旗振りのコツ -ししとうLT #3 -
barometrica
3
330
Other Decks in Technology
See All in Technology
Shadow DOM & Security - Exploring the boundary between light and shadow
masatokinugawa
0
760
AI駆動開発 with MixLeap Study【大阪支部 #3】
lycorptech_jp
PRO
0
270
機械学習を「社会実装」するということ 2025年夏版 / Social Implementation of Machine Learning July 2025 Version
moepy_stats
1
1.4k
私とAWSとの関わりの歩み~意志あるところに道は開けるかも?~
nagisa53
1
130
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
170
Recoil脱却の現状と挑戦
kirik
3
460
Ktor + Google Cloud Tasks/PubSub におけるOTel Messaging計装の実践
sansantech
PRO
1
330
[MIRU2025]Preference Optimization for Multimodal Large Language Models for Image Captioning Tasks
keio_smilab
PRO
0
100
ObsidianをLLM時代のナレッジベースに! クリッピング→Markdown→CLI連携の実践
srvhat09
7
9.7k
経験がないことを言い訳にしない、 AI時代の他領域への染み出し方
parayama0625
0
260
Amazon CloudWatchのメトリクスインターバルについて / Metrics interval matters
ymotongpoo
3
280
マルチモーダル基盤モデルに基づく動画と音の解析技術
lycorptech_jp
PRO
2
260
Featured
See All Featured
Balancing Empowerment & Direction
lara
1
510
Documentation Writing (for coders)
carmenintech
72
4.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Unsuck your backbone
ammeep
671
58k
Transcript
電話を切らさない技術 電話⾃動応答サービスを⽀える フロントエンド JSConf.jp 2024, 2024-11-23 佐川 善彦
⾃⼰紹介 佐川 善彦(さがわ よしひこ) Software Engineer クライミング‧DJ 趣味 2013 メーカーに新卒⼊社、産業機器を設計
2019 SWエンジニアに転向、受託開発 2023 IVRyに⼊社、Frontend主軸に⾃社開発 @barometrica
オフィスに壁とDJ機材、あります!
さて、突然ですが
ブラウザから電話をかけたことがある⼈ ✋
ブラウザから電話をかけたことがある⼈ ✋
今⽇はブラウザ通話を⽀える フロントエンドについてお話します
話すこと アーキテクチャ React / Next.js … 話さないこと PJマネジメント WebRTC …
⽬次 1. IVRy について 2. ブラウザ通話について 3. ブラウザ通話を⽀えるフロントエンド 4. IVRy
のこれから
IVRy について
電話⾃動応答サービス IVRy • ⽉額2,980円から電話の⾃動応答ルールを簡単に作成 • 全ての電話業務を誰でもすぐにAIを使って効率化
IVRyが向き合う課題 電話はいまでも最重要連絡⼿段
IVRyが向き合う課題 電話を当たり前に取れない時代
IVRyが提供するサービス 電話業務を⾃動化‧効率化 ダイヤルプッシュと AI の対話をハイブリッドで設定
IVRyが提供するサービス 様々なサービスを提供していますが …
IVRyが提供するサービス 今⽇はブラウザ通話について話します …
ブラウザ通話について
ブラウザ通話とは ブラウザ上で電話の受発信を可能にするサービス • 電話をかける発信、電話を受ける受信のいずれもブラウザで可能 • インターネット回線を通じて電話をすることができる「IP電話」により 実現されるサービス • 050番号のほか、市外局番(0ABJ番号)でも通話することが可能
IVRy でのシステム構成 Twilio と⾃社サーバを介して受発信
ブラウザ通話のフロー ブラウザで受電する場合
事前接続 受電時の フロー ブラウザ通話のフロー ブラウザで受電する場合
電話のプロダクトとして⼤事なこと 「電話はつながって当たり前」 を提供すること
電話のプロダクトとして⼤事なこと 「電話はつながって当たり前」 を提供すること ブラウザ通話もつながって当然 のはずなのですが‧‧‧ ↓
• 過去の通話履歴の参照など、通話中に画⾯操作したいケースは多い ブラウザ通話の失敗談 失敗談①:画⾯遷移で通話が切れる
ブラウザ通話の失敗談 失敗談②:店舗切り替えで通話が切れる • IVRy は⼀つのアカウントで別の店舗に切り替えることができる • 切替時に店舗情報を⼀度初期化する必要があるが、 このときに通話も切れてしまっていた
電話のプロダクトとして⼤事なこと 「ブラウザ通話もつながって当たり前」 を提供し続けるための⼯夫が必要
ブラウザ通話を⽀えるフロントエンド
ブラウザ通話を⽀えるフロントエンド:アーキテクチャ Next.js:Pages Router + SSG AWS S3 + CloudFront でホスティング‧配信
‧Pages Router ‧SSG ‧ブラウザ通話可能なページは いずれもSPA
ブラウザ−Twilio 間の接続を維持することが重要 ブラウザ通話をつながって当たり前にするには? • うっかり切れてしまうことのないように、構造的に維持したい ◦ → Layout Pattern を利⽤
ブラウザ通話を⽀えるフロントエンド:接続の維持 • 複数ページにまたがる共通コンポーネントを Layout として切り出し • ページごとに Layout 指定 •
同じ Layout の画⾯に遷移する際、 共通コンポーネントを再レンダリングさせない Layout Pattern Header Page1 Header Page2 Header Page3
ブラウザ通話を⽀えるフロントエンド:接続の維持 export function Layout({ children }) { return ( <>
<Header /> <main>{children}</main> </> ) } components/Layout.tsx export function Page1() { return ... } Page.getLayout = function getLayout(page) { return <Layout>{page}</Layout> } pages/page1.tsx Header Page1 Layout Layout Pattern
ブラウザ通話を⽀えるフロントエンド:接続の維持 • Layout に切り出すことでページ操作による通話処理への影響を排除 ◦ 各画⾯の開発時の通話処理への考慮事項も削減 • ブラウザ通話の使⽤可否も Layout の呼び分けで対応可能に
Layout に通話処理を切り出して接続状態を保持 Page1 Page2 Page3 CallConainer ‧通話処理 ‧接続保持 ‧... CallConainer ‧通話処理 ‧接続保持 ‧... CallConainer ‧通話処理 ‧接続保持 ‧...
ブラウザ通話を⽀えるフロントエンド:接続の維持 Page1 pages/page1.tsx components/LayoutForCall.tsx export function LayoutForCall({ children }) {
return ( <CallContainer> {children} </CallContainer> ) } export function HogePage() { return ... } HogePage.getLayout = function getLayout(page) { return <LayoutForCall>{page}</LayoutForCall> } LayoutForCall CallConainer ‧通話処理 ‧接続保持 ‧... Layout に通話処理を切り出して接続状態を保持
• 複雑さの要因 ◦ 外部サービス(Twilio)の SDK が React ⽤に作られていない ◦ 保持すべき状態の数が多い
• 複雑さによるリスク ◦ 何か不具合があった場合の影響範囲の特定が難化 ◦ 開発の属⼈化 ◦ 機能改善の速度低下 ブラウザ通話を⽀えるフロントエンド:メンテナンス 通話ロジックは複雑になりやすい 保守性を担保したい : 凝集性‧結合性を守りたい
ブラウザ通話を⽀えるフロントエンド:メンテナンス features ディレクトリに通話ロジックを集約 • ただディレクトリに集約しただけでは意図しない形で使われる危険性あり ◦ → Linter のカスタムルールで凝集性‧結合性を担保 .
├── src │ ├── features │ │ ├── call │ │ │ ├── index.ts │ │ │ ├── components │ │ │ │ ├── CallContainer │ │ │ │ │ ├── index.ts │ │ │ │ │ ├── hooks.ts
ブラウザ通話を⽀えるフロントエンド:メンテナンス Linter で意図しない外部アクセスを制限 const generateFeatureAccessRules = () => fs .readdirSync(path.join(__dirname,
'src', 'features'), { withFileTypes: true, }) .filter((dirent) => dirent.isDirectory()) .flatMap((dirent) => [ { module: `src/features/${dirent.name}/**/*`, allowReferenceFrom: [], allowSameModule: true, }, { module: `src/features/${dirent.name}/index.[jt]s{,x}`, allowReferenceFrom: [''], }, ]) .eslintrc.js • 指定したコンポーネントのみ利⽤できるようにして保守性担保 export { CallContainer } from './components/CallContainer' export { CallConfirmModal } from './components/CallConfirmModal' ... features/call/index.ts features ディレクトリ直下の index.ts で export したもののみ ディレクトリ外から参照可
IVRy のこれから
• 正式リリースから4年、プロダクト規模も開発陣も拡⼤の⼀途 • エンジニアの数は3年で 2名から34名へ • 導⼊業界は 94/99 業界に拡⼤ =
解決したい課題も拡⼤ ◦ → これから①:フロントエンド基盤改善 ◦ → これから②:新機能開発 IVRy の現状 IVRy は急拡⼤のまっただ中 ※⽇本標準産業分類(令和5年)の中分類99業種をもとに計測
IVRy のこれから • リファクタリング ◦ 歴史的経緯による「割れ窓」を直していきたい ◦ 誰でもフロントエンドを触りやすい環境にしていきたい • ⾃動テスト
◦ ⼈⼒の QA に頼っている状況 ◦ ブラウザ通話の振る舞いも⾃動でテストしていきたい • パフォーマンス ◦ 最近だとウェブフォント最適化とか • アクセシビリティ • デザインシステム • … これから①:フロントエンド基盤改善
IVRy のこれから これから②:新機能開発 通話相⼿ ⼀次受け+保留 転送先 • 例1: 保留転送 ◦
さらに複雑化する通話ロジックを いかにシンプルに保つか? ◦ 保留時のUXはどうあるべきか? • 例2: FAX ◦ 「FAXの当たり前」を ブラウザでどう提供するか? ◦ 当たり前をどう超えていくか? FAX相⼿
まとめ • ブラウザ通話で⼤事なこと ◦ 「つながって当たり前」を提供すること • ブラウザ通話を⽀えるフロントエンド ◦ Layout に通話処理を切り出すことで
画⾯操作の影響なく接続を維持することが可能に ◦ 複雑な通話ロジックを features ディレクトリに集約、 また Linter によるアクセス制御で構造的に保守性を担保 • IVRy のこれから ◦ 急拡⼤に伴い新機能開発‧基盤整備などやっていき!
【宣伝1】エンジニア忘年 LT 会、やります!
【宣伝2】企業ブース、出してます! AI ⾃動応答などぜひご体験ください!! ノベルティーもあります!! 3F 301 Track B
We are Hiring !!! 詳しい採⽤情報はこちら https://www.notion.so/ivry-jp/IVRy-b30395752c 7c4a448f1520576dc55778