こんにちは、@24guchiaです。

弊社では内製していた顧客管理システムの全面刷新を年始に行いました。
私はその中でもTwilioを用いたテレフォニーに関するリニューアルを担当しました。

リニューアルにあたりTwilioをなぜ採用したのかや、
どういう技術構成を組んだか、
リニューアルから3ヶ月経ち、成功と失敗、
これからの未来について考えをまとめていきます。

リニューアルに関して

そもそもなぜリニューアルに踏み切ったか

• データ最適化を進め、機械学習の導入などエンジニアの進化速度の向上
• エンジニアリング組織として、強くしていく
• レガシーシステムで改修に時間がかかり、改善のスピードを上げることが出来ない
• データが見えづらいため、勘に頼った判断が増えていた
• 顧客管理システムのUIUXが悪く、実際に使う営業からのハレーション

他にもいろいろありますが、大きな理由はこの辺ですね。

これ書いてる人は何やったの

先にも書きましたが、Twilioを使用し、
社内の電話システム改修とCRMつなぎ込みを行いました。

インハウスのコンタクトセンターを1人で作りました（ドヤ）

・・・

すいません、実装は1人でやりましたが色んな人の協力あってです。
わざわざこれ書くのも、協力してくれた人への自分なりの感謝の表れです。

Twilioを用いたコンタクトセンターのリニューアルに関して、
知りたい方は読み進めていってください。

なんでTwilioを採用したの

電話機にとらわれない、コミュニケーション手段として利用できる

電話機を使う必要がなくなります。
PCとインターネット回線さえあれば、どこでも働くことができます。
将来的にはWebサイトやアプリからの通話を格安(通信料金のみ負担)で提供もでき、
今まででは考えられないコミュニケーション手段として、使えるためです。

すべての通話ログが残り、検索ができる

ログが残ることで、1人のお客様に対してどれくらいの時間とコストを掛けているか、
放棄呼、到達率といったすべてのログを集めることができます。

ログが残るサービスは多いですが、
それを開かれたAPIで検索できることが強みだと思います。
APIがあるため、必要な情報を集めることができ、
データを基にした判断が可能になります。

架電者・受電者が分かれた形式で録音できる

先の通話ログが残ると似た理由ですが、
話者の音声が左右に分かれることで、営業がどのような内容を話しているか、
音声からテキスト化し、分析するための基盤を作ることが出来ます。

これは他のサービスでは提供されているのは見たことがないです。
メールやメッセージは元々テキストなので、分析しやすいですが、
この特長により音声までも分析の対象にできるため、
よりデータドリブンな判断が可能になります。

オープンなAPIが公開されている

存在しているAPIはすべて下記ドキュメントで公開されています。
https://www.twilio.com/docs/
一部、知ってる人は知っているみたいな隠し情報とかも
あったりしますが、普通に使う分には困らないです。

これは技術選定フェーズではかなり有利で、
他のテレフォニーだとAPIはあるらしいくらいまでしか分からず、
弊社で必要なことがすべて実現できるか不明でした。
その点、Twilioはドキュメントが用意されているので、
要件を洗い出し、このAPIを呼び出すという一覧を作成できたので、
先の特長とあわせて、Twilioで問題ないだろうという判断ができました。

どうやって提供しているの

クライアントはChromeExtensionを採用

社内の顧客管理システムでブラウザをGoogleChromeに限定している、
という前提条件ありきですが、ChromeExtensionを自作し、
社内限定で公開しています。

Extensionにした理由は、顧客管理システムを使う以上、
Chromeは常に開いているだろうという想定と、
別のソフトウェアだと起動し忘れて、
受電できないということを懸念し、
ブラウザ一体型のExtensionにしました。

在席管理はSyncを採用

Twilio.Syncを使用し、Extensionにログインしたら、
在席にし、Syncのdisconnectedイベントで離席、
通話が始まったら通話中と切り替えました。

受電割り振りはTaskRouterを採用

Twilio.TaskRouterを採用し、受電の割り振りをしています。
受電した番号で、顧客管理DBに検索、
担当者が決まっていれば、担当者を優先的に呼び出し、
担当者が離席中であれば、同じチーム、
同じチームも全員離席していれば在席の誰かを呼び出します。

成功と失敗

成功していること

• ちゃんとログは残る
• 録音もできている
• データ分析の基盤作りができた
• 物理の電話機を一掃できた
• 見えていなかった問題が見えるようになった

だいたい、採用した時に狙っていた通り、
通話ログが着々と溜まっていき、電話機は減らせました。
また、今まで放棄されていた通話などに気づくことが出来、
転送することで放棄が減っているようです。

失敗したこと

一つの失敗だけで一記事できそうです（涙）。
他にもいろいろありますが、とりあえず5つだけ。

Syncの事前の負荷テスト不足で全然動かない【対応済み】

SyncはAPI制限があります。下記URL参照です。
https://www.twilio.com/docs/sync/limits

200人くらいいる営業を同じマップに配置し、
それが更新をしまくるので、SyncがAPI制限に引っかかり、
まったく在席管理が見れないという不具合が起きました。
現在、修正済みですが、在席管理と電話機を
同じExtension上においていたため、電話が動かないということが
頻発し、かなり迷惑をかけました。

API制限に引っかからない形にし、
また、在席管理をExtensionとは別ページに置くことで対応済み。

StackOverflowに質問して、SyncのPMから
返信いただいているので、参照してください。
https://stackoverflow.com/questions/48207330/twilio-sync-map-frequently-cannot-get-300-over-items

データ分析するための分析基盤が必要【未対応】

Twilioはログが残りますが、通話の考え方がユーザから見たときと異なります。

AliceがBobに電話をかけたというケースは、
一般的な電話利用者から見ると、1つの通話ですが、
Twilioの通話ログは下記の通り2つに分かれます。

• AliceからTwilioへの通話
• TwilioからBobへの通話

TaskRouterを使うと通話ログは更に分かれ、
AliceからTwilioへの通話、Twilioから各Workerへの通話が
生成された分だけ通話が分かれます。

どういうことかというと、下記の通りの通話ログが生成されます。

• AliceからTwilioへの通話
• TwilioからWorkerAへの呼び出し(タイムアウトするまで取られない)
  • 通話が切られるか、誰かが対応するまで無限にこの通話ログが生成されます
• TwilioからWorkerXへの呼び出し（対応されて、通話が開始）

TaskRouterで生成された通話ログは通常の管理画面で
追うのはかなり困難なため、データはあるが、分析するための準備が必要な状態です。

現在、未対応。

TaskRouterで受電すると通話が遅れる【対応中】

こちらかなり危険で、日本国内のTwilio開発者では対応手段が限られる、
致命的な問題です。詳しくは以前記事を書いているのでそちら参照。
https://harinoma.info/caution-taskrouter-in-japan/

詳細は記事を読んでもらうとして、問題の概要として、
TaskRouterで生成されたタスクを通常の通話で処理すると、
アメリカのサーバを経由した通話になり、通話が遅れる可能性があります。

日本国内での対応方法はDequeueなどは使わずに、
Conferenceで使用し、regionをjp1にすると
国内での通話が実現できます。
ただし、Conference使用量分、料金が増えます。

こちらConferenceに置き換え作業を現在対応中。
対応のめどが付いたら、別記事作ります。

24時間動く電話にエンジニア（僕）の対応が追いつかない【対応済み】

Twilioを扱えるエンジニアが1人(僕)しかおらず、
それに対して利用者は300人程度で想定していないバグや
使用方法の質問、早朝深夜・土日祝関係なく問題を抱えたまま
動き続けるシステムに僕が心身ともに参ってしまいました。
体重が一時的にけっこう落ちました。

対策として、どう対応するのが正解かケースによりますが、
下記のようなことが言えます。

• 1人でやらない
• テスト（負荷テストや状態遷移テストなど）を複数の観点から事前にしっかりやる
• 利用者への周知のコミュニケーションパスを作っておく

今は部長や間接部門の方に周知をしてもらい、一部運用でカバーをしているため、
安定稼働しつつあり、たくさんの人に協力してもらえているので
ほとんど回復しています。

Extensionが思いの外使いにくい【対応中】

Chromeは開いているけど、Excelなど他のソフトウェアを使ったりすることもあるので、
Chrome上にしか表示できないExtensionでは、解決ができないことが多くあります。

• 自分の在席状態をExtensionのバッジで表示しているが、文字が小さすぎる
• 通知（Notification）の表示領域不足し、修正もできない
• 配布方法が独特

まあ、表示系はもっとちゃんとテストしとけよっていう話ですが、
配布方法が一番の困りどころです。

配布は下記順番で行います。

• Extension更新パッケージを管理画面でアップロード
• 最大1時間以内に更新パッケージがStore上に公開される
• 公開されたパッケージを各利用者が手動アップロードか自動アップロード

これの何が問題かというと、クライアントとサーバの両方を修正する時、
サーバの更新は一瞬ですが、クライアントの更新タイミングは不明です。
そのため、サーバ上のみ最新で、クライアントが古いままなどが発生し、
サバクラでバージョン不一致が発生してしまうことがあげられます。

また、最新のクライアントで不具合が発生した場合でも、
すぐにバージョンダウンして再公開などできないため、
同手順を踏み、アップロードする必要があり、
最大1時間程度は電話が使えないということが起こり得ます。

対応として、夜中に1人でアップロードして、翌朝更新するよう依頼する
という方法で現在はしのぎ、できるだけサバクラ同時に修正が必要なことは
実施しないようにしています。

これらの理由につき、Extensionを捨てて、Electronでアプリ化を進めています。
これの作業にはなんと、僕以外の優秀なフリーランスの方が着手してくれています。

Electronでは上記問題は解決できそうですが、
また別の問題も起きると思います。
同じ失敗をしないよう事前テストとして、
ExtensionとElectronを併用する期間を設ける予定です。

これからの展望

通話音声に関するデータ基盤を作り、データドリブンな組織、
とかっこよく今どきな言葉を並べていますが、
この3ヶ月は書いた通り、泥臭く地道な修正を続けていました。
また、更に3ヶ月かもっと長い期間、同様な地道な作業が続くと思います。

短期的には影が薄くなりたい

この泥臭い作業が終わったあと、声大きめに
あれやこれやの指示出していた僕はひっそりと仕事をしたいです。
最近あの電話おじさん見ないね？と言われるようになりたい。

これは僕がコミュ障とか人が嫌いとかそういうことではなく、
電話機が持っている機能を安定して提供できている状態で、
利用者がわざわざエンジニアに話す必要がない状態だからです。

世にある安定しているインフラは、インフラを支える技術者が当然いますが、
僕らは普段意識することはあまりないです。

普通に使える。
まずは、そういう状態を目指します。

中期的にはコンタクトセンターとして最適な組織に変えたい

顧客からの問い合わせに最適最速な経路で、担当者に繋がる組織。
放棄呼や待ち時間を圧倒的に少なくしたい。

最適な担当者につなげるというのは、システムだけではできず、
どういった電話がどの時間帯に誰宛にかかってくるのかといった分析と
組織としてどう対応するのかの方針を定める必要があると思ってます。

その部分の分析をした上で、システムに組み込み測定を繰り返す事ができる、
SMARTなコンタクトセンターにしていきたい。
数値として洗い出せば、効率的な働き方の提案につながり、
長時間労働のうち、本当は必要のない勤務時間を減らせるようになると思います。

長期的にはコミュニケーション全般を最適化していきたい

はい、Twilioのミッションですね。
プロダクトとしては、Twilio.Channlesが近いです。
https://twilio.kddi-web.com/blog/developer/entry000316.html

また、TaskRouterは実は通話以外のタスク生成と割り振りが可能です。
そのため、受電を最優先タスクとして割り振りし、
それ以外のチャットツールやメールなどは優先度を少し下げて、
割り振るといった器用なことが出来ます。

この辺、まとめた概念がTwilio.Flexだと思っています。
以前の記事参照。
https://harinoma.info/what-is-great-twilio-flex/

すべてTwilioで完結するべきか微妙なので、
最適な部分に最適な技術で対応していきたいです。

最後に、通話ログがあり、テキスト化ができるため、
テキストマイニングに従った最適な通話シナリオの作成、
リアルタイム文字起こしやリアルタイム感情分析など
技術的におもしろそうなことも待ち構えています。

まとめ

Twilioに携わるようになり、はや一年が経ちました。
最初はホコリまみれのボロい電話機を渡され、
これをなんとかしてくれと言われた時、
弊社でのキャリアが終わったとも思ったものです。

かなり尖ったスキルセットにはなりましたが、
調べても分からないことを解決していくのは
エンジニアとして自信が付きました。
なんでも出来る、でも必要なことだけやるように
これから精進していきます。