Twilio Flexは何がすばらしいのか

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

つい先日、Enterprise ConnectTwilio Flexというサービスのローンチが発表されました。
Flexは何がすばらしいのか、私の考えを記事にします。

CPaaSという概念の提唱

CPaaSは下記頭文字を取った概念です。

Communications Platform as a Service (CPaaS)

Flex自体はTwilioが今まで持っていた機能の集合体でしかないと、
私は思っています。

しかし、Twilioを知らない人にとってはTwilioで何がどこまで
できるかが分からないと思います。
コンタクトセンターが持っている機能を全てクラウドに寄せることができますが、
ひとつひとつコンタクトセンターが持っている機能を概念として理解し、
プログラミングやTwilioの持っている機能に落としこむには、
それなりの習熟が必要です。

これらひとかたまりの機能をFlexという名前を付けたこと自体で、
人に話すことが出来、理解することができます。
このこと自体が、私は素晴らしいと考えています。

Twilioが目指している未来を表している

先に上げているCCaaSはContactCenter as a Serviceの略です。
CallCenterではなく、ContactCenterです。
コールセンターとコンタクトセンター、
似ているようですが、異なります。

コールセンターは電話だけをコミュニケーションの手段と考えています。
対して、コンタクトセンターは電話以外も含めた、
すべてのコミュニケーションを対象としています。

この考え方自体はChannelsという機能でも、最初から提示していました。
Twilioが目指しているのは、コミュニケーションすべてのプラットフォーム化
であると私は考えています。

Twilioが電話だけを対象にずっとサービスを続けるようであれば、
見限られることも考えられますが、全てのコミュニケーションをプラットフォーム化する
という考え方は他のどのサービスでも体現していません。

この企業哲学こそが、Twilioを使っていきたいと考えられる理由の一つです。

UI の提供

開発者向けの機能の一つですが、共通で使えるようなUIが提供されることで
開発者はTwilioの機能開発に集中できます。
Twilio開発者は日本国内では少ないため、
やらなくてもいい作業が減り、
本来やるべき仕事に集中できることは非常に大きなメリットです。

すぐにFlexを導入するか

私の考えですが、すぐに導入は難しいと思います。
最初に述べておりますが、FlexはTwilioが持っている機能の集合体です。
そのため、 一つ一つの機能はちゃんと習熟する必要があります。

特にTaskRouterは難易度が高いです。
ACDの考え方を理解し、
導入を考えてる組織のコンタクトセンターの文化を理解し、
TaskRouter自体の機能を理解する必要があります。

また、ドラスティックな変更になるため、
いきなり全ての機能を導入し、コンタクトセンターを一新するというのは、
上司や現場などから、反発を受ける可能性があります。
やれることからひとつずつやって行くのが良いかと思います。
そもそも現時点では、プレビュー版の為いつ導入できるか不明です。

Twilio自体の導入について

Flexが現時点でプレビューのため、
逆に今は少しずつ導入するチャンスであるとも言えます。
Flex、及びTwilioが目指す哲学に同意できるのであれば、
今のうちから準備を進めて導入を進めるのはどうでしょうか。

まとめ

以前、弊社にAPACのマネージャーが訪問してきたことあります。
その際質問された、コミュニケーションの未来はどうなると思いますか?
という質問が記憶に残っています。

その時の私は、開発者としての視点しか持っておらず、明確な答えが出すことが出来ませんでした。
この質問を受けた時から、コミュニケーションの未来について考えるようにしています。
今考えると、私もAPACのマネージャーに対し、同じ質問を返すべきでした。
しかし、その質問はする必要がなく、
Flex自体がTwilioの考えるコミュニケーションの未来だと思っています。

TaskRouterを日本国内で使う場合の注意点

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

日本国内でTaskRouterを受電で使う場合、通話音声が遅れる可能性があります。今まで、TaskRouterを使いましょうみたいなことを書いていたので、
その反省と皆様への注意を兼ねて記事にします。

原因

受電が遅れるということですが、原因はTaskRouter自体の仕組みにあります。TaskRouterはTask割り振りをして、米国サーバーでキューが作成されます。
そのままdequeueをすると、
米国サーバーで作成されたキューを介して通話が始まります。
そのため、日本国内のピア同士の通話であっても
米国サーバーを経由することになるため、
音声の遅れが発生します。

対応方法

dequeueを使うのではなくConferenceを使いましょう
Conferenceの作成方法はドキュメント見てもらおうとして、
Conference作成時、リージョンの指定ができます。
このリージョンをjp1に設定することによって、日本国内での通話が実現できます。

まとめ

1月にリニューアルしてから、通話が遅れることがあるとよく言われていました。
アルファー版で発生していなかったので、なんでだろうと悩んでいましたが、
原因がわかればなんということはないです(遠い目)。

現在、 通常のCallからConferenceに置き換える作業しています。
これはなかなかに骨が折れますので、
これから日本国内で導入を考えているTwilioデベロッパーの皆様、
予めConferenceでの実装をお勧めします。

Conferenceへの置き換え苦労話は今度、まとめます。
とりあえず言えることは、単純な置換では絶対に動かないし、
1対1が前提の通話に対し、複数人が通話する前提のConferenceでは
そもそも考え方が異なります。
この辺はかなり苦労しています。