この記事は NTTコミュニケーションズ Advent Calendar 2019の17日目の記事です。
前日は @nyakuo さん の記事 RISC-V (RV32I) を実装してみる でした。
大遅刻で申し訳ないっす…。
はじめに
私はNTTコミュニケーションズで、会いに行けるWebRTCプラットフォーム 「WebRTC Platform SkyWay」の中の人をやっています。
2017年のアドベントカレンダーで、SkyWayのDeveloper Relations（DevRel）活動について考えていること、実践していることという記事を書きました。
SkyWayのDevRel活動について考えていること、実践していること
現在の私の主なミッションは、2017年に記事で書いたDevRelに加えて、SkyWayサポートサイトの運営や、Enterprise Edition契約者向けのプリセールス、ポストセール、テクニカルサポートです。今回は、弊社のアドベントカレンダーの記事ということで、SkyWayのサポートについて考えている事をポエムとして書いていきます。
あくまでポエムなので、記事の内容について問い合わせがある場合は、弊社の営業担当やコンタクトセンターではなく私個人までお願いします。また、この記事の内容は2019.12現在のスナップショットであることもご了承下さい。
Community Editionのサポートポリシー
以下に記載がある通り、Community Editionのサポートは**「FAQ」と「開発者コミュニティ」**です。後述するEnteprise Editionのサポートとは異なり、中の人が直接サポートをすることは原則有りません。
ここでいう開発者コミュニティは、こちらのコミュニティの事をさしており、開発者のみなさんがお互いにノウハウを共有しながら、相互扶助の精神でいい感じにナレッジが貯まる場所に出来たら良いなと考えておりますが…
現実はそうもいかず、「投稿したのに誰からも返信がない」状況が発生していたり、「中の人とコミュニケーションが取れるつもりで書き込んだのに返信がない」とお叱りを受けることもあります。コミュニティを運営する側として、全ての方にとって満足度が高いコミュニティになっていない可能性がある事は認識しています。
満足度をあげるための取り組みとして、コミュニティにナレッジを貯める事で同じような問い合わせを減らすことができるため、すぐに回答できるものは我々の方で回答したり、SkyWayのサーバAPIやSDKのバグが疑われる場合や、影響度合いが広範囲に及びそうな事案が報告された場合は、それの調査や修正をプロダクトバックログとして積み、プロダクトマネージャーと対応を協議しています。
例えば、以前、「room (sfuroom)のmembers, remoteStremsの内容がAPIと異なるのですが、仕様が変わっているのでしょうか？」という問い合わせがあり、一部SDKの不具合が見つかったため、バグ改修を行いました。
とはいえ、Community Editionとして無償提供している関係で、全ての投稿に対してこれらの対応を確実に実施するというのは、申し訳有りませんが約束できません。満足度を高められるように継続して取り組みは続けていきますが、ご理解頂ければ幸いです。
また、質問を投稿される際は、自分が回答できそうな投稿に簡単でも良いので回答して頂けると、大変ありがたいです
Enterprise Editionのサポート内容と契約裏話
Community Editionの次は、Enterprise Editionのサポートのお話です。
上図の通り、Enterprise Editionのサポートはチケットでの問い合わせが基本となります。そして、チケット数に制限はなく投げ放題です（笑
でも、実際にどんなことまで対応してもらえるのか…気になるところですよね？
利用料金が月額10万円からと高額ですし、Community Editionが無料なのに、その階段はどうなの？きっと凄いことをしてくれるんでしょ？とか思っている方もいるかも知れません。
ここで、契約の裏話を少しすると、Enterprise Editionは、実は法人格がなければ契約できません。つまり個人のお客さんは契約すら出来ないプランなのです。弊社の勝手な事情で申し訳有りませんが。ということで、SkyWayはCommunity Editionを設けて、契約できない個人のお客さんに使って頂くというスタンスを取っています。法人のお客さんの中には、Community EditionでPoCを行い、サービス化の際にEnterprise Editionに移行される法人のお客さんもいらっしゃいますので、使い方は、お客さん次第ですけど。
話を戻して、Enterprise Editionを契約するとサポートとしてどんな事をしてもらえるのか？
この記事をご覧いただいている方で、Enterprise Editionの契約経験がある方は少ないと思うので、次の章で、未知の世界をほんの少しだけお伝えしようと思います。
Enterprise Edition契約者の支援の流れ
最初の自己紹介で書いた通り、Enterprise Edition契約者には、私のようなプリセールス、ポストセール、テクニカルサポートを担当するメンバー（AWSで言う所のSolution ArchitectやGoogleで言う所のTechnical Solutions Engineer）が契約前の導入検討フェーズから、開発、サービスリリース後の利用拡大まで伴走する事があります。
中には我々の一切の支援無しで開発されて、サービスローンチされるお客さんもいます。支援のレベルはお客さん毎に異なるので、基本的には案件毎に個別判断となります。ご期待に添えないこともあるので、ご了承下さい。
ここでは我々がお客さんと伴奏する一例をご紹介します。
フルフルでご支援させて頂く場合は、だいたい以下のような支援になることが多いです。もちろん、プリセールスフェーズでご契約の意思決定をして頂けるお客さんに限ります。
それぞれのフェーズでどんな事を行うのか、ざっくりと書いてみます。
プリセールス
SkyWayはトライアルを含めると2013年12月からサービスを提供していますが、トライアル時代はWebRTCの技術的な説明や、どんなことができるのかというデモンストレーションを求められることが多かったです。
最近では、WebRTCの認知も広まってきていて、WebRTCの概要やユースケースについて下調べをしている方が多く、その上で、自分たちの実現したいことがWebRTCで実現可能か、選択する技術として適切か等を聞かれることが多いです。また、Zoom等のSaaSとの違いやSkyWay以外のWebRTCプラットフォームとの違いや特徴などを質問されることもあります。自社サービスを売り込むのはビジネスマンとしては当然なのですが、お客さんのやりたいことがSkyWayで実現できない場合は、私は競合他社のサービスを提案したりすることもあります。合わないのに導入してもらってみんな不幸になるのは避けたいですし。
それから、お客さんによりますが、ネットワークの設計支援も行うことがあります。弊社はもともとネットワーク屋なので、お客さんのネットワークをまるっと構築提供している場合があり、その流れでWebRTCを使う上で必要な帯域設計やネットワーク機器の設計に関してアドバイスを行うこともあります。
テクニカルサポート
これはその名通りで、開発フェーズで発生した技術的な質問に回答したりします。開発を別会社に委託されているお客さんも多く、そういう場合は、直接開発会社のエンジニアの方とやり取りをすることもあります。基本的に、お客さんの設計書やソースコードを見ながらの対応は行いませんが、場合によってはそれに近い支援まで行う時もあります。
また、開発中にSkyWayのAPIやSDKにバグが見つかることも有り、そういう場合はワークアラウンドの提示や不具合修正なんかも適宜実施します。
お客さんのサービスローンチ後も基本的には同じようなテクニカルサポートは続きますが、ローンチ後は、エンドユーザからのクレームに関してSkyWayやWebRTCの観点で対応できるアドバイスを行ったりします。特に、P2Pによるビデオチャットを行うユースケースだと、エンドユーザの端末や通信環境に通話品質が依存することが多く、問い合わせ事案として多いです。詳細は後ほど記載します。
ポストセールス
ここはカスタマーサクセスという言い方が正しいのかもしれませんが、SkyWayを使ったサービスを提供されているお客さんのさらなる成功を目指して支援させて頂くフェーズです。例えば何らかの通話サービスを利用しているところに、SkyWayを使った通話サービスを新規導入し、そちらにマイグレーションしていくような案件だと、マイグレーションにあたって色々な課題が出てくることがあります。その課題の解決支援を通して、利用拡大を目指します。
各フェーズでの支援内容の説明は以上です。ついでに、どのフェーズがどれだけ必要とされているか補足すると、プリセールスは案件のステークホルダーが多い大手企業のお客さんの場合に多いです。内製開発チームを有しているお客さんはテキストベースの問い合わせや1回の打ち合わせで終わったりもします。テクニカルサポートは頻度の大小あれど、ほぼ全てのお客さんにご利用いただいています。ポストセールスはプリセールスより更に頻度は少ないです。
なぜWebRTCはサポートが必要なのか
ここまでSkyWayではこんなサポートをやっていますという話をしてきましたが、読者の中には、WebRTCってAPI叩いて利用する分には簡単なのに、なぜこんなに手厚いサポートが必要なんだっけ？という方もいらっしゃるかもしれません。
WebRTCによるP2P通信は、非常に簡単に実現できてしまいます。ブラウザレベルでAPIに差分があるため、クロスブラウザ対応する面倒臭さや、アップデートへの追従、ネイティブアプリへの対応など考慮すべき事はありますが、それらは普段アプリケーションを書いているプログラマーであれば想定の範囲内だと思いますし、SkyWayのようなマネージドサービスを使えば、ある程度はおまかせできます。
じゃあ何が大変かといえば、エンドユーザの通信環境、端末環境に通話品質が左右されて、場合によってはクレームになってしまうことだと、私は考えています。これはIP電話やSkypeみたいな既存の通話サービスでも起こっていた事で、そのようなサービスの開発をされているエンジニアの方なら別に珍しい話ではないと思います。しかし、WebRTCだと、例えば普段からJavaScriptをゴリゴリ書いているようなフロントエンドエンジニアのみなさんが、こういう問題に直面する事も珍しく有りません。そこが大変なポイントで、サポートでよく寄せられる問い合わせでもあります。
例えば、SkypeからWebRTCへの置き換えで、Skypeより通話品質が下がった…と言われる事があります。Skypeはいわば通話品質のチューニングから含めて全てアプリケーション任せでしたが、WebRTCではその一部が開発者に開放されます。究極的な話、Skypeのクローンが作れちゃう技術なんです。ですので、WebRTCを採用するということは、エンドユーザの利用シーン（実環境）に合わせたチューニングや、問題が発生した際のトラブルシューティング、エンドユーザの期待値コントールなどに向き合う覚悟が必要になります。
WebRTCプラットフォーム事業者は、WebRTCがそういう特徴がある技術であることを踏まえて、そこを解決するためのエコシステムの一部として存在していると考えています。
(余談)黒船来航！？
典型的な日本人的な見出しで完全に余談なんですが、この話だけぶっこませて下さい。
先日のre:inventで、Amazon Kinesis Video StreamsのWebRTC対応がアナウンスされました。その時にツイートしましたが、WebRTCによるP2P通信を行うために必要なAPIやSDKが一通り揃っており、正直なところ第一印象は「ついにきた！黒船きた！」という感じでしたｗ
そして、SkyWayでも利用者が多い、人間対人間のP2Pユースケースに対応してきたことが、個人的には驚きでした。それから、kinesisといいながらも、kinesisと連携部分はSDKにもまだ実装されていないというのも。
個人的に注目なのはC向けのSDKです。
何が凄いかというと、libwebrtcを使わずにフルスクラッチで書かれており、それがApache2で公開されているんですよね。これはすごい。本気度が伝わってきます。これらの状況から予測すると、監視カメラなどのデバイスからWebRTCを使って、映像や音声をKinesisにストリーミングするという使い方が本命なのではと推測しています。
監視カメラなどのデバイスとWebRTCという話でいうと、手前味噌ですが、SkyWayもWebRTC Gatewayを先日正式ラインナップに加えました。
WebRTC Gatewayはその名の通り、WebRTC対応していない既存の様々なデバイスを、WebRTC対応機器と組み合わせて使えるようにするものです。分かりにくいかもしれませんが、例えば、RTSPで映像を転送できる監視カメラを、カメラの改造無しでWebRTC対応させるのが強みです。
SkyWayでも、今年に入ってデバイスxWebRTCの引き合いは増えています。市場的にはKinesisが対応することで選択肢が広がるので良いことだと思う反面、今回話題にしているサポートを含め、WebRTCプラットフォーマーとしては、一層の努力が求められる状況になりました。
Kinesisが対応したP2Pのユースケースについても同じことが言えます。SkyWayのユースケースは先程も記載した通り、人間対人間のユースケースが多いです。このユースケースにおいては、SkyWay含めたプラットフォーム事業者は差別化を図るのが難しいはずです。クライアントがブラウザの場合は、WebRTCのコアな部分は基本的にブラウザ任せになり、後はSDKの使い勝手やstats分析ぐらいでしか差別化が出来ません。そのため、SFU等のサーバサイドで頑張るパターンも多いです。SkyWayでも差別化ポイントを出していきたいと考えていますが、その一つが、Enteprise Edition契約者向けの支援だったりします。
まとめ
この記事ではSkyWayのサポートついて考えていることというタイトルで、
- Community Editionのサポートポリシー
- Enterprise Editionのサポート内容と契約裏話
- Enterprise Edition契約者の支援の流れ
- なぜWebRTCはサポートが必要なのか
という話をしてきました。
まとめると、Community Editionは個人のお客さんを中心に使って頂き、サポートは開発者同士で上手くやってもらいたいと思っていて、Enterprise Editionは、WebRTCを社内のメンバだけで頑張るには辛いなと思っている企業の方々に、その部分をサポートを利用してアウトソースできるというところに、価値を感じてもらえたら良いなと思っています。
最後に、SkyWayみたいなWebRTCプラットフォームの利用を検討しているが、色々あってどれを選べば良いのかよくわからない…という方向けに少しアドバイスです。
WebRTCプラットフォームを国内に開発拠点や販売拠点、代理店があるという基準で選ぶとすれば、SkyWay、Twilio、Agoraが出てくると思います。海外だと、tokboxとかIceLinkとかもあります。それぞれのプラットフォームでサービスとしての方向性や得意不得意な分野が違いますし、今回記事で取り上げたサポートの内容や手厚さが違ったりするはずです。ですので、選定の際は、以下の3点を基準に選ぶことをオススメします。
- 自分たちが使いたい機能が現にある事
- 今後のロードマップを踏まえて、自分たちが使いたい機能が今後も継続的にアップデートされていく事
- 自分たちが欲しいレベルのサポートを提供してくれること
1点目は足切り条件なので言わずもがなですね。2点目はプラットフォームのサービスとしての方向性に関わってくる部分で、例えばP2P通信が利用したい機能なのに、そのプラットフォームがSFUに力を入れているようであれば、将来的にP2P通信機能はメンテナンスされなくなるリスクがあります。3点目はこの記事の主題であるサポートに関してで、是非考慮されたほうが良いかと思います。ご参考までに。
ということで、雑多な記事でしたが、最後までお読み頂き有難うございました。