AWS Startup ブログ
インサイドセールスの課題を解決するクラウドサービス【 Startup Architecture Of The Year 2019 ファイナリストによる寄稿シリーズ 】
皆さんこんにちは、スタートアップマーケティングの石渡です。
AWS Summit Tokyo で開催した Startup Architecture Of The Year 2019 では、7社のファイナリストによる熱いピッチコンテストが繰り広げられました。
このイベントは時間の関係もあり、各社5分という限られた時間でのピッチをお願いしました。当日は私も舞台袖から皆さんのピッチを聞いていましたが、ご登壇頂いた皆様の内容は、知恵と経験の詰まったもので、当日イベントに参加されなかった方にも是非お伝えしたいと思いました。そこで、ファイナリストの皆様に寄稿をお願いして、ここ AWS Startup Blog で、各社のアーキテクチャを熱く語って頂くことにいたしました。
今回は、ソリューションアーキテクト賞を受賞した、株式会社RevCommの 平村さんにご登場頂きます。先日、トロフィーの贈呈も兼ねてRevComm様のオフィスにお邪魔してきましたので、まずはインタビューからご覧下さい。
あらためてソリューションアーキテクト賞の受賞、おめでとうございます。このイベントに応募しようと思ったキッカケなどを教えて下さい。
有り難うございます。弊社では、B Dash camp への参加など、主にビジネス面での露出などを強化していました。(編者註：RevComm様は、B Dash Camp 2019ではグランプリを受賞されています) 。その一方で、技術系のピッチコンテストは限られているということもあって、我々の取り組みを広く世に広めていきたいということで参加しました。
AWS Well-Architected Frameworkについてはご存じでしたか？
はい、RevComm に参画する前に所属していた通信会社にて、AWS Well-Architected Framework の存在を知りました。W-Aの考え方を知るだけでなく、W-Aに基づくシステムレビューも経験したことがありました。そうした経験があったので、RevCommにおいても、Webアプリケーションに留まらず、機械学習やAIを用いた分析システムの設計と実装にもW-Aの考え方を適用して実装していきました。
今回のソリューションアーキテクト賞の受賞についてのご感想はありますか？
正直なところ、ソリューションアーキテクト賞は狙えるかなと思っていました(笑)。W-Aに基づいた設計やレビューを経た改善などを行っているのがその理由ですが、今にしておもえば、手堅すぎたかなという思いもあります。やはりサービスの特性上、安定稼働や低コストなどを重視した設計したというのはあるため、新しいテクノロジーへの挑戦というのは、もう少し取り組んでみたいですね。
挑戦というキーワードが出ましたが、具体的に考えていらっしゃることはありますか？
ゲーム、特にオンラインゲームの技術には注目しています。オンラインゲームのリアルタイム性というのは、音声通信などの通信サービスにも相通じるところがありますので、そこを研究していきたいと思っています。
ビジネスの拡大に併せたシステムの課題などはありますか？
現在既に1,200ユーザーを超えるお客様にご利用いただいており、月間でも100を越える新規のユーザー様にご利用頂いています。そうした拡大基調の中では、システムの拡張性、スケールアップとスケールアウトの両面での拡張性が重要と考えています。拡張性については事前に見込んでいたところもあり、今の所対応できていますが、今後、更なる拡大にも対応できるようにしていきたいと思っています。
受賞に際してのインパクトなどはありましたか？
弊社のお客様が受賞をご存じで、声を掛けて頂いたのにはびっくりしました（笑）。このコンテストを通じて、技術的なところの妥当性や我々の取り組みが評価されたという点でも、今回の参加は非常に大きかったと考えています。
RevCommさんにおける技術選定についてお聞かせ下さい。当初からAWSをお使い頂いていたのですか？
実は創業当初は、AWSや、通信業界で実績のある他クラウド事業者なども含めて技術評価を行いました。様々な検討の結果、AWSを採用したのですが、一つの理由としては、AWSに慣れている人が回りに多かった点があります。そして、今後の技術者確保という観点でも大きいだろうと考えました。
AWSは様々なサービスがあって、選べる自由度が高いのが気に入っています。ただ、自由度が高いゆえに、初めて扱う技術的課題に対していくつものデザインパターンが存在するので、その際にメリットとデメリットを洗い出して、どのようなアーキテクチャで構築するのが最適解なのかを目利きする能力もアーキテクトに求められていると感じています。
RevCommさんで求めているエンジニア像というのがあれば教えて下さい。
弊社が求めているのは、お客様のビジネス課題や立場に応じた形でシステムの設計ができる、イシュー(課題)ドリブンなエンジニアです。その一方で、圧倒的に技術に特化して、例えばアカデミックな現場で注目されている先端的な技術などを貪欲に取り込んで、それを積極的にプロダクトに投入してくれるようなリサーチ力に優れた方にもぜひお会いしたいと思っています。
これからこのコンテストにチャレンジしようという方々にメッセージをお願いします。
このコンテストのように、百戦錬磨の先輩CTOに見て貰う機会というのはなかなか無いことなので、ぜひチャレンジしてみることをお勧めしたいですね。本選後 に行われた審査員の皆さんとの懇親会では、なかなか聞けない話をお伺いできますので、ここも間違いなく参加する魅力です。
インタビューにご協力頂き、有り難うございました。それでは、平村さんによる寄稿文をお楽しみ下さい。
皆さん初めまして。株式会社RevCommでCTOをしている平村です。
株式会社RevCommは、「新たなコミュニケーションの在り方を創造し、世界に変革をもたらす」というミッションを掲げ、AI、Voice、Cloudの技術を活用して世の中のコミュニケーションの生産性を高めるクラウドサービスの開発を行っています。
音声のコミュニケーションには、会議から商談、講演のようなものまであらゆる形態のコミュニケーションが存在します。この中で第一弾のプロダクトとしてどのような製品開発に取り組むかについてマーケットリサーチした結果、現場に課題がある、サービスを購入してもらえるお客様がいる、技術的に難しすぎず簡単すぎない、という3つの理由で、話し方のアドバイス機能を持ったインサイドセールス（内勤営業）向けのIP電話を開発することとなりました。
この製品の企画構想は2017年10月頃行われ、その後すぐに10月〜12月の約3ヶ月間で実際に動作するMVP（Minimum Viable Product：必要最小限の機能を実装したプロトタイプ）を構築しました。翌年1月から3ヶ月間のトライアル導入の後に、クローズドベータ版、アルファ版をリリース、そして2018年の10月に正式リリースし、2019年8月現在、1,200ユーザを超えるお客様にご利用いただき、累計180万件以上の営業電話がMiiTelを用いて行われています。
本サービスをCRM製品（Salesforce.com）に組み込んで通話している画面は以下となります。
話し方の解析結果として、話速や沈黙回数、抑揚の強弱などが、このような画面で表示され、営業成績の良い担当者はどのような話し方をしているのかを定量的、定性的に分析することができます。
RevCommにおけるチームづくり
2017年10月にMiiTelのMVPの開発がスタートしました。当時は、まだエンジニアが2名といった状況で、うち1名は家庭の事情により滋賀からのリモートワーク、もう1名は私で当時はまだ正式に社員として参画しておらず、夜間や週末などプライベートの時間を使って開発を行うといった状況でした。
このような状況でスムーズに開発を進めるため、プロジェクト初期の段階からマイクロサービスアーキテクチャを導入しました。大方針のみを決め、できる限りサブシステムは疎結合に設計し、各サービスの連携箇所はREST APIのような標準的な方法でデータの受け渡しができるように設計する思想です。そして、距離的、時間的に離れた状況でも限られた時間を最大限に活用し、高速な開発ができるような体制を目指して開発を進めました。
現在では、エンジニアが10名を超える体制となりましたが、現在でもその方針は変えずに、5つのマイクロサービスに分かれて開発を進めています。各マイクロサービスでは、システムアーキテクチャや開発言語、扱うフレームワークやライブラリを各チームリードが自ら決定できる裁量を持つことで、高速かつ柔軟なシステム開発を実現しています。
SLAを考慮したサービスの最適設計
技術選定において工夫した点では、本サービスの特徴的な点として、各マイクロサービスによってSLAが大きく異なることです。
例えば、音声通信を担うPBXサーバは、お客様が取引先との通話中にシステムが瞬間的にでも停止すると取引先からのイメージダウンにつながってしまいます。このようなミッションクリティカルなシステムはあえてマネージドサービスを使わず、LinuxのOSレイヤーでのチューニングが行えるEC2を用いて高可用性を実現しています。
Webアプリケーションの運用基盤の設計には、いくつかのベストプラクティスがありますが、我々はDockerコンテナを使ってAuto Scalingを容易にするFargateをアプリケーションの実行環境に選定し、CodeDeployを用いたBlue-Green Deploymentの仕組みを採用しました。これにより、デプロイのプロセスやスケールアップの対応を効率化するとともに、マネージドサービスの活用によってセキュリティの強化にも対応することができ、エンジニアが本来注力すべきタスクに集中できる環境ができました。
最後に音声認識クラスタについてです。MVPを用いたテスト導入フェーズにて、お客様の活用状況をヒアリングしたところ、当初の想定とは異なりリアルタイム性に関するニーズはそれほど高くないことがわかりました。また、音声認識や自然言語処理、音響解析を行うには、高性能なサーバが複数台必要です。このような状況を踏まえて、スポットインスタンスを用いたクラスタを構築し、ニアリアルタイムで各種分析結果が反映できる環境とし、コストの最適化と高いパフォーマンスを両立する事ができました。
得られた効果
AWS社がWell Architectedとして定義している、ソリューション構築において考慮すべきポイントには、運用性、セキュリティ、パフォーマンス、信頼性、コスト最適化の5種類があります。この全てを満たすことはなかなか難しいと考えているのですが、今回は各マイクロサービスに求められるSLAを考慮して適材適所で最適化を図り、全体で最適なアーキテクチャを構築できたと考えています。
例えば、運用性においては、マイクロサービスを組織として導入することで詳細についてディスカッションをする必要がなくなり、ミーティングは週に1回といった程度です。コスト最適化の面では、スポットインスタンスの活用により、70%以上のコスト節約に成功しました。
今回、Startup Architecture of the Yearにおいてソリューションアーキテクト賞を受賞でき、我々の取り組みが審査員の皆さまに高く評価されたことを嬉しく思っています。今後も新しい取り組みを積極的に進め、お客様に新しいコミュニケーション体験を提供できるクラウドサービスの提供を進めていきたいと考えています。
平村さん、お忙しいところ、記事をご執筆頂き、有り難うございました。
【関連情報】