WebRTC Meetup Tokyo #21 参加レポート

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

先日参加したWebRTCミートアップの参加レポートです。
https://atnd.org/events/105581

聞く側兼、話す側でした。
このイベント、話す側もしたのは年始に書いた記事で
Twilio以外のコミュニティに顔出ししたいと書いた目標のためです。

18/19の振り返りとこれから

引き続きやっていきたい。 “WebRTC Meetup Tokyo #21 参加レポート” の続きを読む

Vue.jsを使ってTwilio管理コンソールのアカウントを切り替えるChrome拡張機能作った

タイトル長っ。

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

タイトルのとおりです。

Twilioの管理コンソールは下記を指しています。
https://jp.twilio.com/console/

作った拡張機能

こちらからダウンロードできます。
Twilio Account Switcher

ダウンロードすると、使い方を書いたMarkdownを表示します。

Githubはこちら

なんで作ったか

“Vue.jsを使ってTwilio管理コンソールのアカウントを切り替えるChrome拡張機能作った” の続きを読む

Google Apps ScriptとTwilioでブログの死活管理をしてみた

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

先日、僕のブログ読んでください!とお伝えしたところ、
見れないんですけど・・・っていう恥ずかしい事案があったので、
外部サービスを使って、死活管理しました。

利用する外部サービスはGoogle Apps ScriptとTwilioの2つです。
これらサービスを採用した理由は、このブログは個人でレンタルしている
さくらのVPSにWordpressを導入しているため、
サーバの外で管理したかったからです。サーバを触ったことがないときに、
勉強用に借りたサーバでディレクトリ構成がめちゃくちゃなので、
そのうち移行したいです。

“Google Apps ScriptとTwilioでブログの死活管理をしてみた” の続きを読む

Agent Conferenceで実現するモニタリングウィスパリング機能

こんにちは、@24guchiaです。
TwilioのConferenceとTaskRouterについて、以前、下記記事を書きました。

TaskRouterとConferenceを組み合わせる

それに引き続き、Agent Conferenceで
モニタリングとウィスパリングを実装しましたので、
ハマりどころや考え方について、まとめておきます。

“Agent Conferenceで実現するモニタリングウィスパリング機能” の続きを読む

Amazon Connect vs Twilio

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

東京リージョンでの提供が始まったので、
Amazon Connect(以下Connect)とTwilioについて比較してみました。

2019/01/17 TwilioでもOpusが限定で使える旨、
またFlexにて5000時間の無料利用枠ある旨追記しました。

Connectのメリット

03番号が使える

https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/connect-tokyo-region.html

一定以上の規模の企業だと、必ず希望が出る地域番号、
特に03番号を普通に買って使えるのは良いですね。

03番号が出るということは、これからも他のいわゆる0ABJが
利用できるケースが増えてくると考えられます。
住所証明の書類審査もあるようですが、これは許容範囲。
審査の詳細は上記出展URLの下部を参照してください。

0120番号が申請無しで買える

Twilioでも0120番号は買えますが、これには書類審査が必要です。

Connectでは書類審査なしで購入でき、
すぐ使えるのはスピード感があり、非常に良いですね。
しかし、0120番号は貴重で100万番号しかなく、枯渇している状態です。
その0120番号をどうやって確保しているんでしょうね。
いずれ在庫がなくなるのではという懸念があります。

無料利用枠がある

https://aws.amazon.com/jp/connect/pricing/

これ、めちゃくちゃ良いですね。
Twilioは認証に使った一つの番号に対してのみしか発信できませんが、
このドキュメントを見る限りでは、どこに対しても受発信できそうです。

Twilio Flexは5000時間無料枠がありますので、
そちらもご参照ください。

AWSの各種サービスとの連携が容易

https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/what-is-amazon-connect.html#related-services-amazon-connect

AWSのS3で録音ファイルを溜めたり、Lambdaを使えたり、
LexやPollyといった音声に関するサービスとは相性が非常に良さそうです。

CloudWatchとの連携

個人的に一番気になったのが、CloudWatchとの連携です。
上記URLから引用。
Amazon Connect は CloudWatch と統合し、1 秒あたりの総コール数、拒否またはスロットリングされたコール数、同時コール数の割合、失敗/不在着信コール数 (エラー、間違い番号/住所,ビジー/通話中)、および問い合わせフローエラーなど、サポートセンター用のリアルタイム運用メトリクスを提供します。

素晴らしいですね。これ他のCTIだとめっちゃ高いですよ。
席数単位で似たような機能を使うため、
月額1万円超えるようなサービスもあるくらいです。

CloudWatchは従量課金ですが、かなり安くなりそうです。
ClowdWatchには最大二週間分のみ、保存されるとのことなので、
一週間単位などでバッチでどこかに移行させる必要はありそうですが、
それでもこの料金は破格だと思います。

Opusでコーデックしている

TwilioのVoiceはPCMUですが、
ConnectはOpusでオーディオコーデックしています。
※ 執筆当時。現在は、 Twilio でも Opus も利用可能です。

IP電話では一般的にPCMUが使用されていますが、
WebRTCのデファクトスタンダードはOpusです。

また、一般的にOpusのほうが後発のコーデックのため、
軽量で品質が良いと言われています。
これがデフォルトで使用できるのは嬉しいですね。

Twilioのメリット

電話以外が取り扱える

Twilio最大のメリットですね。
Twilioといえば電話というイメージがとても強いですが、
電話以外のありとあらゆるコミュニケーションを取り扱うことができます。
最近だとSendGridの買収があったり、LINE通話と連携の話が上がったりと、
いろいろと目を引くニュースがありました。
SMS、メール、LINEやFacebookなどのメッセージングサービスなど、
お客様がコミュニケーションを取るために利用するチャンネルは複数ありますが、
それを一元管理して繋いでくれるのがメリットです。

国内導入事例が豊富

https://twilio.kddi-web.com/case/

いっぱいありますね。
規模としては約500名のコンタクトセンターで使ったり、
機械音声での自動化など大小様々です。
この辺のノウハウを活かしやすいのが嬉しいですね。

コミュニケーションプラットフォームとして、明確な方針を打ち出している

最近のFlexから見るに、Twilioは電話以外のすべてのコミュニケーションパスが
利用できる、コミュニケーションプラットフォームとして進化していくことが明確です。
対して、ConnectはAWSの数あるプロダクトの一つです。
そのため、Twilioのほうが後発のコミュニケーションパスへの
対応速度も速くできることが予測されます。

料金の比較

Connectは下記ページを参照

https://aws.amazon.com/jp/connect/pricing/

Twilioは下記ページを参照

https://twilio.kddi-web.com/price/

注意

料金参照ページの通りに列挙しているだけのため、
Connectは税抜き、Twilioは税込み価格となっていることを予め補足しておきます。

電話番号保有料金

前提として1ヶ月は30日とします。
1USDは2018年12月19日時点の112円としています。

050/03番号の場合

Connect: 3USD (約336円)
Twilio: 108円

0120/0800番号の場合

Connect: 14.4USD (約1617円)
Twilio: 1620円

受電料金

050/03番号の場合

Connect: 0.003USD (約0.34円)
Twilio: 1円

0120/0800番号の場合

Connect: 0.1482USD (約16.65円)
Twilio: 21.6円

架電料金

Connect

0.1USD (約11.2円)

Twilio

固定電話: 5.4円
携帯電話: 16.2円
SIP宛: 0.5円

その他料金
Connect

サービス利用料金 0.018USD/分
24時間30日稼働していると、777.6USD(約87,347円)かかります。
けっこう大きい出費な気がします。

Twilio

Twilio Client使用料金 0.25円/分
Twilio ClientはPC上でWebRTCを用いて、PSTNと通話をするためのライブラリです。
そのため、席数が多いとそれだけ料金がかかります。
例えば、8時間勤務のオペレーターがずっと通話していると仮定すると、
1日あたり120円かかります。
とはいえ、一日中通話をしているわけではないため、実際はもう少し安いです。

で、結局どちらを使うべきか?

私が考えるには、下記の判断基準でよいと考えています。
作ろうとしているものはコールセンターか、コンタクトセンターか?
コールセンターを作ろうとしているのであればConnect、
コンタクトセンターを作ろうとしているのであればTwilio。

電話を使った通話は、
総務省の資料によると減少傾向です。

減少傾向となっている原因はLINEやDiscordなど、
コミュニケーションアプリでWebRTCを用いた通話による
コミュニケーションが増えた割を受け、電話による通話が減っていると考えられます。
そのため、これから一層減少傾向になり得る電話だけに注力するべきなのか?
もう一度問いかけたいところです。

まとめ

Connectは魅力的な機能を持っています。
ただし、どんな技術でも使ってみないとわからないデメリットもあります。
ご利用前には綿密な比較を行って、多角的な評価にて採用してください。

使ってみないとわからないので、
Connectでも簡単なコールセンターデモアプリを作ってみて、
また記事にまとめたいと考えています。

18/19の振り返りとこれから

こんにちは、@24guchiaです。
あけましておめでとうございます。今年もよろしくおねがいします。

2018年の振り返りと2019年の目標です。
2018年中にやりたかったのですが、
年末ゲーム三昧になってしまったので、まとめました。

2018年振り返り

月ごとに振り返り書いてみたけど、いまいちだったので、
とりあえず覚えてることをつらつらと。

リリースした

これ。

とにかく2018年はTwilioを用いた社内向けソフトフォンをリリースして、
死にものぐるいでバグ改修と改善で必死でした。
必ず死ぬと書いて必死でした。

電話という都合上、営業時間外にメンテが必要なときが多々あり、
深夜に一人で会社でメンテパッチリリースしたりしてるときは
気が滅入ったもんですが、今となっては社内でも味方が増え、
社外でも注目され、Webで記事になったりして
良いことも大変なこともいろいろありました。

2018年最終出社日は心からの「無事(?)終わった〜」が声に出ました。
2019年も引き続き、改修などがありますが、
改修は早いところ終わらせて、仕様フリーズして、
分析と業務改善に入りたいと考えています。

登壇などした

3回ほどしました。

内1回は社外のビジネスセミナーで30分という結構大掛かりな登壇で、
毎日業務後に夜中まで資料作って、発表練習してなどをしました。
当時のまとめは下記リンクにて。

セミナーに登壇しての学び

大変でしたが、学ぶところが多く、引き続きやっていきたいです。
2019年は引き続き行うのと、Twilio関連でしか登壇できていないので、
LTなどでTwilio以外の登壇もしたいと考えています。

具体的にはQUICなど、WebRTC関連でTwilioやるには必要ないところまで多少突っ込んで
勉強しているつもりなので、この分野でのLTする機会を伺ってます。
よく聞くアレですが、発表するに当たり、間違ったことを言わないよう
しっかりと再度勉強でき、フィードバックを受けられるのでおすすめだったりします。

英語勉強した(途中でやめた)

具体的にはTOEICとDMM英会話。
勉強の動機はTwilioは英語ドキュメントのほうがまだマシだし、
TwitterとかStackOverflowとかでTwilio社の人が反応くれるのと、
SIGNALに行きたかったから(行けなかったけど)。

TOEICは2ヶ月位勉強して多分大学生のときに500点くらいだったけど、
730点取れたので結果は上々だった。
勉強方法はTOEICの本買って模試をとりあえずすぐにやって、
だいたいの現状把握して、頻出単語と文法の参考書で勉強して、
2週間前くらいに再度模試して弱かったところ重点的に復習しただけ。楽勝。

やめたのはDMM英会話で深夜に知らない人と
ビデオ通話するのがあまりにも苦痛だったので、
この方法は合わないなと思って、そのまま放置している。
2019年は勉強の仕方を改善して、再挑戦したいところ。

走り込んだ

NikeRunClubのログ見ると930キロらしい。
フルマラソン出たら、5時間超えちゃったのでなんだかなあって感じ。
月間100キロ超えたいので、2019年はもうちょい習慣化したい。

走りはじめのきっかけはよく笑われるけど、僕が一番行動変えた本の
SOFTSKILLSに優秀なエンジニアは走るって書いてあったから走ってる。
30を超えて、普通に生活してたら太ったし、
周りの30超えのおじさんと話してると体調悪いとかよく聞くけど、
走り始めたら痩せたし、体調も良いので結構おすすめ。

今は走るとオーバープロネーションで膝がちょい痛くなるので、
12月はほとんど走れなかったので、フォーム変えたり、靴変えたり、
サポーター当てたりいろいろ模索中。
当初の目標(優秀なエンジニア)はそっちのけで、
今はとにかく速く長く走れるようになりたい。

本を結構読んだ

34冊読んだので、月3冊に届きそうな冊数。
小説とか占いの本とかも混じってるけど。
途中で読むのやめた本とかもあるので、読み始めた本はもう少し多いと思う。

これは、リーダーがチーム賞で会社からもらった賞金とポケットマネーを共有Kindleに
金突っ込んでくれてるのも追い風になってて、共有Kindleで2冊実際に読んだのと、
あとちょっと読んでこれはいい本だと思って結局自分で買ってるのもある。

パーッと焼き肉とかに賞金をぶっ込んでたら、継続的な満足感は得られなかったので、
この辺の投資の考え方は参考にしたい。
読書習慣は2019年もこの調子で引き続きやっていきたい。
読んだ本の一覧長くなったので、文末にまとめた。

良かった本

CAREER SKILLS ソフトウェア開発者の完全キャリアガイド

この本書いてあることに影響を受けて、具体的に行動変えてるので、
一番良かったと思う本。

全部で60章あるが、全部読む必要はなく、
自分のキャリアの現状に合った部分だけ読めば良いと思う。
それだけだったら、割とすぐ読めるはず。

TED 驚異のプレゼン 人を惹きつけ、心を動かす9つの法則

一番心動かされた部分を引用。
“好むと好まざるとにかかわらず、今やだれもがセールスマンだ”

終身雇用もないし、会社もいつなくなるかわからない今の社会で生きる僕等は
全員セールスマンだ。会社で言われることをやってるだけだと、評価は良くならないし、
会社がなくなったときに立ち行かなくなる。
具体的に自分が会社にいるとどういう利点があるかを話せる
セールスマンである必要があるので、プレゼンの本だから関係ないと言わずに、
読んでみてほしい本。

日報をちゃんと書き始めた

なんで今さら、って感じですが、これも本の影響です。
走りはじめのきっかけになったSOFTSKILLSの続編、
CAREERSKILLSに書いてあったからです。

ざっくり日報書くメリットを本から引用すると、
日々、どれだけ貢献しているかを証明できる証拠になるということです。
「第43章 人事考課で最高評価を獲得する」というところに書いてあり、
評価周辺の知識ですが、内省だったり、結局1日で何をしたのか、
最高評価を獲得するためには何をしておくかを考えられるので、
やってみるとけっこう良いなと感じています。

営業日分しか残ってないのですが、
営業日以外もまとめたほうが良いかもと感じています。
日報を書く習慣付けするために、一部機械的にやって、
とりあえずその日の日報を書き始められるよう工夫したので、
そのうちまとめます。

2019年目標

分析と業務改善への貢献

とにかくこれですね。
本当は2018年中に着手したかったが、間に合わずでした。

Twilioを用いたソフトフォンに置き換えたのは
電話機をなくすっていう事自体にも価値はありますが、
システムとして改善する手段もなかった
電話でのコミュニケーションをデータとして分析出来るようにし、
業務改善したいっていうのが本来の目的です。
社内データアナリストや機械学習エンジニアと
協力しながら進めていきたいです。

社外での業務

ありがたいことに、社外からTwilio関連で何件か相談をいただいており、
これを実際に業務としてやっていくつもりです。
TwitterでDMもらえれば相談乗りますので、ぜひご連絡ください。

Twilio以外もなにかチョットデキル人になりたい

社内ではTwilioの人とか電話マンとかいろいろと言われていますが、
それ以外の二つ名をつけてもらえるようになりたいですね。
最近だとあれやりたいですね。人体拡張とか体いじるやつ。

速く長く走れる体つくり

とりあえずフルマラソンはサブ4.5くらいは目指したいですね。
最終的にはサブ4を目指したいのですが、
運動強度上げすぎて膝故障しちゃうといろいろと台無しなので、
もう少し近い目標を順に達成していきたい。

長くっていうのは、地理的な距離の長さでもありますが、
自分の人生における長く続けられる趣味っていう意味でもあるので
故障だけは絶対にしないようにしたい。

趣味をもう一つ

今の所、ロードバイクかキャンプやりたいなーと考えてます。
両方共ずぶずぶまで行くと、無限にお金がかかるので、やるならどっちか一つかな。
それ以外にも、何かおすすめの趣味あれば教えてください。

まとめ

2019年もよろしくお願いします。

2018年読んだ本一覧

“18/19の振り返りとこれから” の続きを読む

SmartCommunicationAward2018 参加レポート

こんにちは、@24guchiaです。
写真はセミナー当日に履いていたTwilio靴下ですw

SmartCommunicationAward2018に参加しましたので、参加レポートです。
https://www.smartcommunicationaward.com/

とりあえず、SIGNALは来年以降にお預けになりました?

Twilioの今後のビジョン予測

これからSIGNALあるので(行けないですけど)、
そちらで改めてビジョンについて発表があると思います。
なので、ここでは手短に。

エンタープライズプランの提供、AIに注力すること、
Flexの提供でコンタクトセンターのフレームワークを用意すること。
また、LINEを使えるようになることで、国内のコミュニケーションチャネルの多くを
Twilioで押さえられるようになりました。

これらの理由から、国内の大企業でもTwilioの導入が進んでいくと考えています。

また、実はTwilioは今年から株価が伸び続けています。
1月には25~26USDで推移してましたが、
3月にFlexの発表があった時期には1.5倍以上の40USDで推移しています。
その後もまだまだ伸び続け、現在は90USDに迫ってきています。
https://finance.yahoo.com/quote/TWLO/

ここに来て、世界中の企業でも導入しやすい好条件が用意されたので、
今後も更に伸び続ける可能性がありますね。
SIGNALの発表次第ではまだまだ伸びしろがあると考えています。

その他、SCAで気になったトピック。

強固なセキュリティの提供

エンタープライズプランでは、セキュリティ周りを強固にする
機能がいくつも提供されるようです。

例えば、TwilioのAPIはどのIPを利用するか不明ですが、
IPを4つに固定できるようになります。
また、通話ログの電話番号、SMSのメッセージ内容をマスキングし、
保存することで個人情報の保護を強化する機能も追加されるようです。

今まで、セキュリティやプライバシーを理由に
導入をためらっていた大企業も再検討ができるようになりそうですね。

AI+人によるコンタクトセンター

AIを用いて、チャットボットももちろん、
会話もこなすボットの導入が考えられているようです。
エンジニアとしては、ボットだけで良いんじゃないかと思ったんですが、
佐藤尚之さんの話を聞いて、ボットだけの対応だと、
新規ファンを獲得できないから、Twilioは有人対応にこだわっているのかなと感じました。

Flexが目指すもの

コンタクトセンター業務はある程度は画一的です。
デモを見てFlexは、どの企業でも使えるコンタクトセンターの
フレームワークを目指していると感じました。

フレームワークが提供されることで、
各コンタクトセンター独自の問題だけにフォーカスして
課題解決の改善が進められますね。

LINE x Twilio

LINEとTwilioが連携しました。
LINEメッセージからTwilio通話、TwilioのIVRからのLINEメッセージへの
シームレスな移行が達成されます。

国内ではLINEを使っている人は7,600万人を超えており、
人口の59.9%をカバーしているとのことです。
※出典 http://ad-center.line.me/mediaguide/
LINE アカウント 2018年10-11月期 媒体資料 より

このLINEユーザ層に対し、個人情報になりうる電話番号を取得せずに、
通話やメッセージが送れるのは非常に魅力的です。
LINEは通話料がネットワーク料金だけのため、
公衆電話回線網を利用した通話より安くできます。
そのため、経費削減も実現できます。
Twilio Clientを利用すれば、同様のことは実現可能ですが、
LINEアプリを利用することで、独自アプリやウェブサイトの
開発・保守せずとも、通話ができるのが良いですね。

DOerJapanについて

プレゼンしましたが、惜しくも優秀賞でした。
SIGNALに行きたく、最優秀賞がほしかったのですが、
事業性などの課題を解決出来ていなかったと反省しています。

Twilioとユーザグループに対する考え方を話してきた

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

先日のTwilio Developer Meetup 2018 Summerで
LTとパネルディスカッションをしてきて、

TwilioとTwilioユーザグループに対する考え方を話したので、まとめと補足です。

https://twiliomeetup.doorkeeper.jp/events/76796

LT登壇したときのスライドはこちら。(公開にあたり少しだけ修正しています)

資料の補足と自分の具体的な行動

モチベーションはその人の内的動機を高めるのが一番良いんですが、
現在ユーザグループたまにしか見てないっていうユーザに
一番わかりやすく話せそうなのが、自分の市場価値が上がるという点でした。

現在のユーザグループは盛り上げたとき、
ユーザにどうメリットがあるか分からない現状です。
僕はユーザグループに関わる内的動機を上げるために、
自分の市場価値が上がるというように考えてます。

オフラインでは今回みたいなイベント出席して知り合いを増やしたり、
登壇する側でLTしたりセミナーで話したりしています。

オンラインではブログをメインでやってます。
ブログは最初から自分が評価される材料として考えてます。

このブログは下記2点をモチベーションに書いてます。

過去の自分が知りたかった情報

Twilioを用いたシステムを今の規模で管理している人が少ないらしく、
ググっただけでは出てこない問題に直面することが多いです。

そのため、過去のある時点の自分が知りたかったことを書くようにしています。
技術的な記事は一度ハマったことと解決方法をセットにしてます。

けっこう技術的な記事でも、感情的な文章が多いのは、
その時ハマった勢いそのまま書いてるからですね。
この辺はその内改善していく予定。

Twilioチョットデキルの証明と自分を売り出す

口ではなんとでも言えるので、

「出来ます!」

って言う人をいきなり額面通り信用する人はいません。
チョットデキルは今やスラングで
むしろ、すごい出来るくらいの意味がありますw

実際にやって来たことをブログに書いておくことで、
僕がTwilioチョットデキルっていうのは、
具体的にどういう問題をどのように解決したか、
どれくらい出来る人なのかを示すために書いてます。

このブログを読んで、本当にちょっとだけ出来るんだなって思われるのも、
もしかしてすごい出来るって思われるのも、自由です。
自分なりの信念やだいたいこれくらいは出来てるっぽいっていう
考えはありますが、人からの評価は強制できません。
評価がされないと、どれだけ技術力があっても市場価値は上がらず、
自分の給料は上がらないので、
評価されやすい情報の提供を引き続きやっていくつもりです。

まとめ

今回はユーザグループを盛り上げたいという趣旨のイベントだと感じたので、
なんでユーザグループに関わると良いか、自分なりの考えをまとめました。

考え方自体は終始、めちゃくちゃ利己的ですが、
オンからもオフからもユーザグループ盛り上げるネタにはなってるんじゃないかと考えてます。

僕は自分の市場価値を上げて給料を上げたいという、外的動機を出発点として、
継続して活動できるよう、内的動機に考え方を変えてます。
今は好き勝手に楽しくやってます。

セミナーに登壇しての学び

先日、下記セミナーにて30分の登壇をしました。
LTは何度かやったことが合ったのですが、
30分枠でかつお客様からお呼びされて登壇は初めてで
いろいろと学んだことがあったのでまとめておきます。

当日のFix版スライドはスライドシェアに上げました。
こちら出来るまでどういう手順で作ったかをまとめました。

スライドの作り方

グッドプラクティス

メッセージマップを作る

https://www.mindjet.com/blog/2014/05/mindjet-dashboard-series-power-three-presentation-planner/

最初にこのメッセージマップに従って、伝えるヘッドラインは何かと、
それを補足するキーメッセージを3つに分けることで、
ブレがなく、覚えやすいプレゼンにできます。

スライドのデザインを学ぶ

https://qiita.com/mgmg121/items/af8cf164a432941ed5f1

こちら参考にさせてもらいました。

スライドの作り方を学ぶ

https://www.slideshare.net/yutamorishige50/ss-41321443

特に下記のメッセージは普遍的で、押さえておくべきです。

①1スライド1メッセージ
②Kiss(Keep It Short and Simple)の法則
③STOP箇条書き(デフォルト利用して無意味な箇条書きをしない)

私はこれ完全にできませんでしたが、
次回似たような機会があったときの課題にしています。

この辺押さえるだけで、誰でも良いスライドとプレゼン内容が準備できます。
あとは実際に会社の人など人前で発表し、録画した動画を見直し、
フィードバックを受けることで、話すのも問題なくできるようになります。

スライド作成までの経緯

第一版

とりあえず30分話さないとと思って、詰め込みまくったスライドになりました。
この詰め込みまくったスライドは聞かされる方は
とにかく疲れる事がわかりました。

どんなことでも聞くというのは意外と疲れるため、
話の間にちょっとした小ネタや覚えなくてもいいことを話すと、
聞き手にとって良い気晴らしになります。

第二版

第一版は話すことも長かったので、
1スライド1メッセージまで削ぎ落とせませんでしたが、
一般的に覚えやすい3つまでの情報に1スライドあたり絞りました。

また、割とネガティブな言い回しが増えてしまったため、
ポジティブな言い方にリフレーミングし、事実として起きた問題などは、
その問題の解決方法をすぐに提示することで、
完全なネガティブ情報として記憶されないように気をつけました。

例えば、TaskRouterを使い、dequeueすると日本国内だと
音声が遅れやすいのは事実としてあります。
しかし、私のプレゼンを見て、TaskRouterを使ってみようと思った方の環境で、音声が遅れると発生するのはまずいため、
音声通話が遅れないようにする
AgentConferenceを使うよう
解決方法の提示まで話しました。

第三版

2回書き直してやっと伝えたいことが固まりました。
なれてないので、結構かかりましたね。

3回目の書き直し時は社外の友達に内容見てもらい、
分かりづらかった点など挙げてもらい、
文言修正や伝える順番を変更しました。

また、社内のデザイナーにデザインレビューしてもらい、
オブジェクトの配置やフォントカラーの修正をしてもらいました。
オブジェクト再配置はかなりの量になってしまったので、
一部間に合いませんでした。
下記デザインの原則だけでも抑えて、
予め見やすい配置になるように心がけると良いですね。
https://bulan.co/swings/design4principals/

スライドはTwilioのブランドカラーに従うようにしました。
https://www.twilio.com/company/brand

Fix版

上記に修正を行い、最後はデモ動画を随所に貼り付けて終わりです。
デモ動画はQuickPlayerなどで録画可能ですが、
これも意外と時間かかるので、早めに着手しておきましょう。

プレゼン練習について

各スライド毎にカンペを作る

頭が真っ白になったときのカンペをスライド毎に書いていきます。
考えたことを文章にするだけで、思考がまとまるので
本番当日見なくても
よかったりしますが、作っておくといざというとき安心です。

カンペを作る事自体が、プレゼン練習につながるし、
実際に私は当日カンペをほとんど見ずに済みました。

口に出して人前で練習をする

社内の人や友達に見てもらって、口に出して練習しましょう。
慣れてないと意外と長くなったり、変な癖があったりしますので、
とにかく回数を重ねましょう。

プレゼンの仕方を学ぶ

この本読んでみてください。

実際に参考にしたことは下記です。

数値を視覚的にわかりやすく見せる

スライドの主題でもあった、電話レス。
電話機をなくすことがどれだけインパクトがあるかを伝えるため、
電話機の大きさを電話はなぜつながるのかと
携帯電話はなぜつながるのかの
本よりも一回り大きいと伝えることで、
イメージつけやすくしました。


 

数値を意外な方法で伝える

AgentConferenceは250人のグループ通話が可能です。
これだけ言われても、すごそう!くらいにしか思えません。
特にプレゼンをずっと聞かされて疲れてる側の人は、感動もなく忘れるでしょう。

このグループ通話が強みであるのは間違いないので、
250人まで使える貸し会議室と料金比較すると
AgentConferenceなら10分の1で済むということで
安く済ませられると言い換えました。
また、この記事のキャッチ画像にもしているスライドで、
すごい人数だなと再度思わせるように気をつけました。

自分自身の話をする

プレゼン最後に人材募集中の宣伝をさせてもらいました。
その際に弊社に入社するといろいろな経験が積めるという点は、
普通のWebエンジニアの私でも、
コールセンターを実装できた
というように自分自身の話をしました。

この点はプレゼン練習のフィードバックでも色んな人に突っ込まれたので、
良い悪いに関わらず、記憶に残りやすかったようです。

まとめ

とにかく最初に作ったスライドはネガティブな感じになってしまったけど、
フィードバックを受けることで徐々に良くなっていきました。

当日はスライドの調整も終わってたし、
プレゼン練習も何度もやっておいたので、そこまで緊張することなく、
話すことができました。

私は普段は話すのも苦手ですが、
練習すれば誰でも一定レベルまでは到達できると感じました。

TaskRouterとConferenceを組み合わせる

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

以前の記事で、日本国内でTaskRouterを使う場合、
Conferenceを使いましょうとの結論を付け、
実際に
運用をはじめたので、TaskRouterとConferenceを組み合わせる方法について書きます。

この記事を読むとTaskRouterを使わない場合でも、Conferenceを使って、
通話のモニタリング機能を拡張できるようにしておくか、
それとも通常のDialで済ませるかの判断基準になると思います。

日本国内でTaskRouterを使う場合、Conferenceを使う理由って?

端的に言うと、TaskRouterで割り振った受電の通話音声が
必ず遅れやすい環境での通話を強いられます。
詳細は過去記事を参照してください。
https://harinoma.info/caution-taskrouter-in-japan/

TaskRouterのみの影響ということは受電だけ直せばよいか?

これはケースバイケースですが、基本的には架電もConferenceに置き換えたほうが良いです。
理由はConferenceとDialが混合するため、コードが読みづらくなり、
拡張性や保守性が下がります。
また、保留を提供している場合、受電と架電で処理を分ける必要があります。
日本国内でTaskRouterを使う場合、
Conferenceでの受電架電の機能提供は
セットで必須になると思います。

TaskRouterは使いたいけど、Conferenceは使いたくない場合は?

下記選択肢から選んでください。

  1. 受電は通話が遅れるものとして受け入れる

  2. 一旦受けて、必ず即時折り返す

  3. TaskRouterの日本サーバができるのを待つ

3以外はあんまり現実的な選択肢はないですね。ただ、3はいつになるか不明です。今日時点(2018年5月27日)では、諦めてConferenceを使いましょう。

そもそもConferenceとは

250人まで同時通話できる機能です。Dialは1対1の通話に対し、250人まで同時に話せますグループ通話機能を作ったりするのが一般的なユースケースです。

AgentConferenceとは

Conferenceの拡張機能です。Conferenceとの決定的な違いは、
coachプロパティにより、
話した音声を特定の相手に届けられる点です。

この機能は何に使うかというと、新人営業と顧客の通話を先輩営業が聞きながら、話し相手には聞かれずに、先輩が新人に口頭で直接指示を出すといった場合に使います。
リアルタイムで指示が出せ、さらにソフトフォンを使えるため、
場所を問わず、コーチングが出来ます。
声が荒ぶっても、話し相手には音声が聞こえないので、
近くの新人をコーチングする場合でも、この機能を使うと安全です。

一般的なビジネスフォンでもウィスパリングやら、
モニタリングやら
といった名称で提供されていることもあります。

Conferenceのハマりどころ

概念が違う

先にも書いた通り、Dialは1対1の通話に対し、Conferenceは1人以上250人までの通話という点が違います。
二人以上ではなく、1人以上のため、
普通の通話では考えなくても良いことを考える必要があります。

誰かが通話を終了した時、Conferenceを終了させるかどうか考える必要がある

Conferenceは1人以上でも、通話が可能です
そのため、二人で話していて、相手が電話を切っても、
残された方は自動で電話が切れません。

例えば、endConferenceOnExitというプロパティがあり、
このプロパティをtrueにすることで、
このプロパティがtrueの人が通話を終了したら、
自動でConferenceを終わらせる機能があります。

じゃあ、これを一律でtrueにすればよいかというと、基本的にはダメです。
その理由は保留があるからです。
保留する場合、その人はConference上の通話を終了するため、
このプロパティがtrueだとConferenceが終了してしまいます。

一律ではなく、顧客の通話のみ、このプロパティをtrueにします。
また、このプロパティがfalseの側が通話を終了した場合、
API経由で必ずConferenceを終了させましょう。
終了させないと、通話相手は自動で電話が切れないので、
気付かずずっと通話状態になっているとクレームにつながります。

Twilio ClientでConferenceSidが取れない

ConferenceSidは通話を終了させたり、
参加者に対して更新処理をかけるのに必要な情報です。

先に挙げたように、必ずAPI経由でConferenceを終了させる必要がありますが、ClientにはなぜかConferenceSidを受け渡されません。
じゃあ、CallSidから参照しようという手も無理です。
CallSidからConferenceに関する情報は取れません。

解決方法としては、架電と受電で異なる方法を用いました。

架電の場合

ConferenceにStatusCallbackイベントが設定できるので、
イベント時にSyncでClientに通知しました。

かなりトリッキーな方法で一刻も早く別の方法で直したいのですが、
現時点ではこういう方法以外は見つけられませんでした。

受電の場合

TaskRouterを使う場合、TaskSidがConferenceのFriendlyNameに設定されるため、
Taskを受領する際、FriendlyNameで検索することで
ConferenceSidが取得できます。
TaskSidはTwilioが付与する一意なIDなので、1件のみ取れます。

一個余計なAPIを投げる必要があり、余計なコストだと考えています。
まあ、架電に比べたらかなりマシです。

この解決方法の問題点

Syncにしても、API経由にしても、時差があります。
Webページなら気にならない誤差ですが、電話ではけっこう致命的な時差です。

一番の問題として、ConferenceSid取得前に電話を切ろうとすると
Conferenceを終了させるAPIに失敗します。
そのため、この方法で解決する場合、ConferenceSidが取得できているか、
できていない場合、再度時間を置いてAPIを呼び出すよう待つ必要があります。

架電時、架電先がビジー応答返却すると、Conferenceが重複した

なんだそれ、という感じですが架電時の処理を下記の通りに組むと重複します。

  1. Twilioの番号と架電先の番号の通話をConferenceに参加させるAPIを実行する

  2. 1で作られたConferenceにdialするTwimlを返却する

これは普通に待受状態の電話機に通話する場合は問題ありません。
問題が発生するのは、ビジー応答を返却する電話機の場合のみです。
ちなみにビジー応答は、通話中かつ留守電設定がない電話機の場合、
ビジー応答が返却されるようです(観測範囲内)。

なぜ重複するかというと、1でConferenceに入る前に、
ビジー応答が返却され、通話中の参加者がConferenceからいなくなり
1のAPIで作成されたConferenceが即時終了します。
そして、2ではすでに終了したConferenceに架電しようとしますが、
存在していないため、同名の別のConferenceが作成され、そこに1人で参加します。

これにはけっこうハマりました。
Conferenceは1人以上で成立するという仕様のため、
電話を切る必要があるが、上でも挙げている通り、
ConfereceSidがClientに渡されない。
さらに重複したConferenceにはStatusCalllbackのイベントを設定できず、ConfereceSidをSyncで渡すという実装をしていたので、
電話を切るために行った対策がすべて通用しませんでした。

これの対策は1と2の間で少し待ち、
1で生成されたConferenceが生きているか確認したり、
StatusCallbackで対策したりと方法があります。
私は1秒待ち、Conferenceのstatusを確認する方法で対応するつもりです。

StatusCallbackの数が普通の通話より増える

イベントの数が増えます。https://www.twilio.com/docs/voice/twiml/conference#attributes-statusCallbackEvent

サーバへのアクセスが増えるので、注意してください。
うちのサーバはちょいちょい限界を迎えてます。

ConferenceSidが渡されないために、必要以上にStatusCallback設定しています。

まとめ

ちょっとこれは理不尽では?

理不尽だと感じる理由は下記の通り。

  1. TaskRouterはGAなのに、日本国内では通話に遅延が発生しやすいまま放置されている

  2. 1のアナウンスが私のブログにしか情報がない(観測範囲内)

  3. ConferenceSidをClientに受け渡す方法がなく、かなりトリッキーな実装を強いられる

これからTaskRouterを受電で使う場合はよく考えて採用してください。TaskRouterと同様の仕組みは時間かかりますが、作れると思います。
受電はTaskRouterを使うとTwilioで完結し、良いと思うのですが、
いかんせん日本国内での使用には問題が多いです。

AgentConferenceも実装しづらいなぁという感じなので、
急いで導入する必要はあまりないかもしれません。
下記記事によると、通常のコールからシームレスにConferenceに変更できる機能が実装予定らしいので、モニタリング・ウィスパリングしたい場合でも、
それまで待ったほうが無難かと思います。
https://www.twilio.com/blog/2017/12/agent-conference-generally-available.html

モニタリングの下地ができたのはよしとよう

1ヶ月の実装とテスト2週間ほど(バグがめっちゃ出た)かけ、
とりあえずConferenceが導入できました。

モニタリング・ウィスパリングは元から要望が合ったのですが、
どうにもリリースに間に合わず、置いておいた要望です。
ウィスパリングのアドバイス機能はバグが発生すると、
即クレームに繋がるので、まずはモニタリングで聞くだけの機能を提供し、
その後、ウィスパリングを導入する予定です。
また、リアルタイムでの通話一覧機能を実装し、
どの通話を聞くか、アドバイスするかを選択できるようにする予定です。

これらの機能が実装でき次第、
記事を上げていく予定ですので
それまで乞うご期待。