Twilioはいかにして社内で独自の会議プラットフォームを構築したのか

Twilio（トゥイリオ）は毎年恒例となっている顧客企業向けカンファレンスの開催を5月に予定していたが、今年予定されていた他のライブイベントと同様、新型コロナウイルス感染症の影響による打撃を受けて中止を余儀なくされた。そのため、同イベントをオンラインで仕切り直す方法を考えることになった。支援を求めるベンダーを探すRFPプロセスを開始したが、結局自社のAPIが使えるという結論に至り、プラットフォームを独自に構築することにした。

かなり大胆な方法ではあったが、トゥイリオが直面していた大きな課題には、顧客が特定のAPIエキスパートとじかに会って話ができるという会場での体験をいかに再現できるかという点があった。社内で何度も慎重に検討した結果、自社のコミュニケーションAPI製品がこうした体験を実現するよう設計されていることに気付いた。

独自の方法でやることに決めると、長いプロセスが始まった。必須の機能を把握し、社内での合意を得て、開発とテストのサイクルを構築し、そして自社製品での限界にぶつかったときに支援してくれるサードパーティーのパートナーを探した。

こうしたすべての取り組みは、今週の水曜日と木曜日、トゥイリオが毎年恒例のSignal Conference（シグナルカンファレンス）をオンラインで開催するときにクライマックスを迎える。このプロジェクトがどのようにうまく進展したのか、トゥイリオのエクスペリエンス担当ディレクター、In-Young Chang（インユン・チャン）氏に聞いた。

チャン氏によれば、バーチャルでやると決めたら、プロジェクト担当者（そしてバーチャル会議を開催するすべての人）にとっての最大の課題は、じかに会えるカンファレンスで自然に生じる人とのつながりをいかに再現するかということだった。

トゥイリオは最初のステップとして、提案依頼書を複数のイベントソフトウェアベンダーに提出した。チャン氏が言うには、問題となったのは大部分を完全にバーチャルで行うプラットフォームを設計したことがなかったことだ。せいぜい存在したのは混成のアプローチで、バーチャルで参加する人もいた一方、ほとんどの人は直接参加した。

「大手テクノロジー企業の多くが利用していた数多くのベンダーと会ったが、どのベンダーにも一長一短があり、当社の必要すべてを満たすベンダーはなかった。（じかにカンファレンスに参加する場合のように）当社のお客様が製品エキスパートとつながるようにできるものはなかった」、とチャン氏はTechCrunchに語った。

トゥイリオは提案を精査して数社のベンダーに絞り込んだが、イベントソフトウェアベンダーからの提案に完全に満足することはできなかった。そして、あることに気付いた。

「完全なカスタム注文にも3か月で対応できるベンダーを探すか、それとも（自分たちでやるか）。自分たちで行うというのが、トゥイリオのあり方だ。それで、プラットフォームも自社で構築できると考えた。このようにしてカンファレンスを全面的にソフトウェアベースにしてからは、可能性が無限に広がったので、今度はどうやって優先順位付けをするかが難題となった」、とチャン氏は言った。

このすべてがあっという間に進展した。チームは5月にベンダーと会議を行い、6月までには自社で構築することに決めた。使用するイベントソフトウェアを設計するプロセスを開始した。その際、自社のコミュニケーション機能を真っ先に活用した。

まず、社内のさまざまな関係者と話し合い、カスタムプラットフォームに必須の機能を把握する必要があった。バージョン1.0のプラットフォームに対する関係者の期待事項をうまく取りまとめることは、プラットフォームを完成しようとする際に直面した課題の1つだった、とチャン氏は語った。

「3か月しかなかったので、すべてを完璧にできるとは考えていなかった。いくらかの優先順位付けと妥協はあったが、自社のAPIで必ずできると感じていた」。

チームは社内のさまざまなグループとの話し合いを始め、それぞれにとっての必須機能を確認した。対面のやり取りを再現したいというニーズは把握していた。さらに加えて、リードの集客や議題の作成といったカンファレンスでの通常アクティビティや、直接参加かバーチャル参加かに関わらずカンファレンスで行えるようなことについてのニーズも挙げられた。

チームは社内のさまざまな関係者と話し合うにつれて、何を構築すべきかを見極めていった。その後、優先度に関するドキュメントを作成し、Signal（シグナル）のリーダーシップチームとそれを見直した。「激しいやり取りや多少の議論はあったが、ほんの数か月しかなかったので全員が本当に信頼し合っていた」、とチャン氏は語った。

チームは自分たちが会社の必要を満たすプラットフォームを構築できると信じていたが、チーム内には開発者が10人しかいなかったので、3か月でやり遂げるのは大きな挑戦となった。

最優先事項の1つは、顧客がトゥイリオの適切なスタッフにつながることができるようにすることだったので、その問題に対応すべくTwilio Flex（トゥイリオフレックス）という自社の顧客サービスプラットフォームを使用することにした。フレックスは、音声通話、メッセージング、ビデオ、チャットを1つに組み合わたインターフェイスだ。カンファレンスは純粋なカスタマーサービスの問題ではなかったが、チームは、そのプラットフォームを利用してリクエストを適切な専門知識を持つスタッフに送ることで、ブースに赴いて特定のスキルを持つトゥイリオの従業員にたずねるという体験を再現できると考えた。

「トゥイリオフレックスのTaskrouter（タスクルーター）を使うと、スキルに基づく独自の特徴を担当者に割り当てることができる。たとえば、ビデオエキスパートには、ビデオエキスパートというタグを付けることができる。ビデオに関する質問があれば、その質問を直接ビデオエキスパートにルーティングできる」、とチャン氏は説明した。

トゥイリオはSignal Concierge（シグナルコンシェルジュ）というコンパニオンボットも開発した。これはカンファレンス環境で同社のカスタマーサービスのアプローチを応用することで、オンライン上で参加者一人ひとりをガイドして必要なものを見つけられるようサポートするというものだ。

「シグナルコンシェルジュがカンファレンスの案内役となる。次にどのセッションに行ったら良いかたずねる場合、あるいは（エキスパートと話したい場合）、1か所で質問の答えが得られ、そこでサポートを受けることもできる」、とチャン氏は言った。

トゥイリオは自社ツールで対応できなかった分野について、サードパーティーに支援を求めた。「Klik（クリック）とのパートナーシップを継続することによって、会議のデータとバッジプラットフォームはすべてAPI経由で利用できた。また、トゥイリオのSIパートナーであるPerficient（パ―フィシエント）を採用し、限られた時間の中で社内チームを強化して、トゥイリオフレックスのカスタマイズを迅速に実装できるようにもした。さらにPlexus（プレクサス）からは、オープンソースのビデオプレーヤーで使用できるストリーミング機能が提供された」、とチャン氏は語った。

9月には構築したものをテストし、シグナルコンシェルジュがリクエストを正しくルーティングすること、すべてのカスタマイズ要素が機能していることを確認した。トゥイリオは水曜日の朝にバーチャルの扉を開いて、どれほどうまくやり遂げられたか見ることになる。

チャン氏はチームがやり遂げたことを誇りに思うと述べているが、これは最初の通過点に過ぎず、今後のバージョンには今回構築する時間がなかった機能が追加されることも認め、こう述べる。

「これはバージョン1のプラットフォームであり、当社が必要とするプラットフォームとまさしく同等のものではないが、コンテンツの範囲の定義付けから実際のプラットフォーム構築までを3か月以内で実施できたことを本当に誇りに思う」。

関連記事：Twilioが現場作業員向けの無料の1対1動画ツールキットと新しいIoTプラットフォームを発表

カテゴリー：ネットサービス

タグ：Twilio　リモートワーク

[原文へ]

（翻訳：Dragonfly）

• Original:https://jp.techcrunch.com/2020/10/09/2020-09-29-how-twilio-built-its-own-conference-platform/
• Source:TechCrunch Japan
• Author:Ron Miller

Amazonベストセラー