Voicy Tech Blog

Voicy公式Techブログ

VUIをプロトタイピングする方法

はじめまして!1月からVoicyに正式ジョインしたUXデザイナーの京谷(通称:きょーちゃん)です。

Voicyに入ってから、VUI(Voice User Interface)のデザインを専門として活動しています。 VUIについては弊社エンジニアのぱんでぃーが過去の記事で説明していたのでそちらも合わせて読んでみてくださいね。

voicetech.hatenablog.com

さて、Google HomeAmazon Echoに代表されるスマートスピーカー、音声チャットボットの台頭により音声を扱う場面が増えたUXデザイナーの方がたくさんいらっしゃるのではないでしょうか。

今回は音声体験を”プロトタイピング”して検証する方法について取り上げてみたいと思います。 プロトタイピングとは製品やサービスを開発するときに、実際に動くモデルを早期に作って、それを使った体験がイケてるのかそうでないかをテストする手法のことです。 つまり、音声をユーザーの行為や画面UIに合わせて発音させることによって、その音声体験がイケてるか否かを確かめてみよう!という内容です。

【目次】

1.なぜプロトタイピングが重要なのか?

みなさんは「あたたかい音」とか「かっこいい音」と言われてどんな音をイメージしますか?また「ほっとする声」「元気がでる声」と言われて具体的な声をイメージできるでしょうか?

私は・・・曖昧にしかイメージできません!それはズバリ ”聞いてみないとわからない” からです!!

VUIデザイナーがこんな風に言い切ってしまって良いのか・・・?

でも音声は視覚情報よりも個人の記憶と強く紐づいており、客観的に判断するのが難しいのです。

しかし、これまでのUXデザインと同じようにユーザーのコンテクストをきちんと把握して、 プロトタイピングを回せればVUIのデザインはできます!!

プロトタイピングは、プロジェクトメンバーが個々に持つ曖昧な音声のイメージを具現化するのになくてはならないフェーズです。

2.GUIのプロトタイピングとの違いは?

もちろんGUIにおいてもプロトタイピングは重要ですよね。 しかしGUIとVUIでは、検証するポイントに違いがあります。

GUI

視覚情報を使った図形的なやりとりであること

  • あらかじめ複数の関連情報を提示しておくことができるので、ユーザーは自身が行ったインプットに対してどんなアウトプットが返ってくるかある程度予測できる

◆VUI

音声を使った対話的なやりとりであること

  • 事前情報がなく、ユーザーの発話を起点にサービスとのインタラクションがスタートするので、どんなアプトプットが返ってくるか結果をみて初めてわかる

GUIに比べてVUIでは事前にユーザーに与えられる情報(ヒント)が圧倒的に少ないということが言えます。暗闇の中、手探りで正解の操作を探しだすようなものです。 VUIを単体で扱う場合には、まず前提としてユーザーが常に何をすべきか不安な状態であることを前提に考える必要があるでしょう。

また、音声はその特性としてダイレクトにユーザーの感情に働きかけます。 VUIでは正しく操作を行えるかだけではなく、「気持ち良い」などポジティブな感情になれるかを注意深く検証する必要があります。

3.VUIを検証する効果的なプロトタイピングの方法

私がこれまで実践してきた方法のうち、効果的なものは3つありました。

1)アクティングアウト

f:id:voice-tech:20180123082641j:plain
アクティングアウト

概要:サービス役の人との対話を擬似的にデバイスとの対話に見立てて、VUIを体験する。

用意するもの:台本

  1. サービス役と、ユーザー役の2人で行います。
  2. 台本にはユーザーが発話する台詞と、それにサービスがどう対応するかを記載しておき、実行します。
  3. ユーザー役は自分の発話に対するサービスの反応をどのように感じたかをメモしていきます。
  4. 第三者がこれを観察し、客観的に見て不自然な点がないかを確認するのも良いです。
  5. この方法ではぜひ、サービス役にいくつかキャラクターを割り当てて比較検証するのがおすすめです。

使いどころ:スマートスピーカーや音声チャットボット等音声の対話を詳細に設計するとき。

2)ペーパープロトタイピング+SE

f:id:voice-tech:20180123082646j:plain
SE

概要:ユーザーの操作に合わせて他の機器から音を出すことで擬似的にVUIを体験する。

用意するもの:音声データ、サンプラー(アプリ)、ユーザーの操作シナリオ、GUIのプロトタイピングツール

  1. サンプラーアプリにあらかじめ音声データを取り込んでおく
  2. ユーザーのタスクをシナリオにまとめておく
  3. 操作をするユーザー役と音声を再生するSE役の2人で行う
  4. ユーザー役はシナリオにそってGUIを操作し、その操作に合わせてSE役はサンプラーから音を出す
  5. ユーザー役は何人かに体験してもらい、操作後に簡単なインタビューを実施して感想をまとめる

使いどころ:GUIと合わせて音声を扱うとき。複数の音声の候補があってどれを採用するか迷っているとき。

おすすめサンプラーアプリ サンプラーアプリ”KLANG(クラング)”|Sound &iPhone・iPad App“M-TANK”

サンプラーとは、複数の音声データを読み込んでボタンなどのシンプルなインタフェースで再生できるデバイスのこと

3)ビデオプロトタイピング

f:id:voice-tech:20180123082650j:plain
ビデオプロトタイプ

概要:ビデオ映像を撮影して編集で音声を追加することでVUIを体験する。

用意するもの:ビデオカメラ、ユーザーシナリオを再現するセット(画面のみの検証で良い場合はiOSビデオキャプチャ機能が便利です)

  1. ユーザーシナリオに沿ったシーンを無音で撮影する
  2. あとでムービーに音入れをする
  3. ムービーを見ながら開発メンバーでディスカッションを行う

使いどころ:1)や2)を客観的に観察したいとき。シーンが決まっていて、音声が全く決まっていないとき

最後に・・・

ここまで、VUIのプロトタイピング方法について紹介してきました。これらはVUIの大きな方向性を決めるのに有効な手段です。

しかし、神は細部に宿ることをお忘れなく!

音質や発音タイミングによって、ユーザーに与える印象はぐっと変わります。 最後の磨き上げが肝心です。

Voicyでも先日、VUIプロトタイピングの手法を用いてユーザーテストを行いました。 近日中にリリースされる新しい機能を検証したのですよ・・・!!お楽しみに♪

突撃!隣のスマホ画面

こんにちは、新年二発目は私あかよがお送りいたします。

さてVoicyでは新年より”アプリ勉強会”という新しい取り組みを始めました。
この勉強会は、世の中のアプリについての知見を高め合おう!という目的で有志が集まり(なんだかんだ全員参加してます笑)

  • どのようなシーンに刺さるのか
  • サービスのすごいところ
  • Voicyで活かせるところ

などの視点で一人一つづつアプリを紹介し、紹介したアプリの優れた機能を抽象化し、どのようにVoicyでの体験へ生かせるのかをディスカッションを行なっています。

前回の勉強会で紹介されたアプリを一部ご紹介すると

HashPhotos

HashPhotos

HashPhotos

  • beyondf
  • 写真/ビデオ
  • 無料

  • このサービスがVoicyで活かせるところ
    HashPhotosの『画像に自分で考えるタグを自由にいくつも付けられることで、大量の画像データから必要なデータをすぐに検索することができる体験』をVoicyに生かすと、『リスナーから自由にタグを付けられるようにすることで、大量の配信の中から自分の好きな配信を簡単に見つけられるようにすれば、よりリスナーが過去の放送を聞くようになり、アプリ滞在時間の向上に繋がるのではないか?』

relive

Relive Running & Cycling

Relive Running & Cycling

  • Relive B.V.
  • Health & Fitness
  • Free

  • Voicyで活かせるところ
    reliveの『日常で行う動作を簡単にかっこよく可視化することで、SNSに投稿したくなる体験 』をVoicyに生かすと、 『いくつかの放送をハイライトして振り返り放送を自動生成しBGMをつけてかっこよく演出したものをアーカイブすることで、SNSへの投稿を促進できるようになるのではないか?』

などのように、他にも様々なアプリが紹介されました!
まだまだ始めたばかりではありますが、この勉強会を通しVoicyをより良いサービスへ進化させて行きたいと思います。

突撃!隣のスマホ画面

それでは、そんな取り組みを行なっているVoicyの社員のスマホの中身は一体どうなっているのでしょうか?
しっかりアプリを研究してるみなさんのスマホ画面はさぞ素晴らしいのでしょうね!
ということで、社員へ以下のアンケートをとってみました!

  • 一番使っているアプリ
  • おすすめしたいアプリ&理由

それでは、トップ画面と私の感想を併せてご紹介します。 ぜひこちらのメンバー紹介と併せて読んでみてくださいね。

voicetech.hatenablog.com

社長ことオガケンさん

エンジニア他己紹介では登場しませんでしたが、今回はVoicyの社長の緒方さんにも登場していただきました!

f:id:voice-tech:20180116212201p:plain

ゆーじさん

f:id:voice-tech:20180115183640j:plain

  • 一番使っているアプリ

  • おすすめしたいアプリ

    写真で一言ボケて(bokete)

    写真で一言ボケて(bokete)

    • Roadie,inc.
    • エンターテインメント
    • 無料
    理由:こんなに短時間の暇つぶしに適したアプリはない

  • 感想
    勉強会ではシュールなアプリ(aDanza)を楽しそうに進めてくださる姿が印象的ですが今回のおすすめもだいぶシュールでしたね。
    スマホトップをみると、開発している人だ…ということをなんだかひしひしと感じてしまいましたが面白みはあんまりありませんでした…(小並)
    スマホのトップの面白さと技術は比例しない、そう感じた瞬間です。

ぱんでぃ

f:id:voice-tech:20180115172850p:plain

  • 一番使っているアプリ

    Launch Center Pro

    Launch Center Pro

    • Contrast
    • 仕事効率化
    • ¥600

  • おすすめしたいアプリ

Sleipnir Mobile

Sleipnir Mobile

  • Fenrir Inc.
  • ユーティリティ
  • 無料

理由:
◆操作高速化
LaunchCenterとAirLaunch、Sleipnir(のタブ管理、ジェスチャーが便利)

理由:現在のパケット通信量と上限までの割合が 、以下の画像のようにどれくらいかひと目で分かる f:id:voice-tech:20180115173843p:plain

  • 感想
    第一印象、AB型っぽい
    使うアプリはランチャーで管理してるのでトップにあるアプリは飾りらしいです
    Voicyはアイコンがオシャレじゃないので入ってないと言っていて失礼だな!と思いましたが、
    アイコンがダサいだけでアンインストールされることもあると聞くので、アイコン大事なんだな…と思いました。
    ぱんでぃさんの紹介するアプリはなかなか私が触らないようなものばかりなので聞くと面白いです。

きょーちゃんさん

f:id:voice-tech:20180115174607p:plain

  • 一番使っているアプリ

Feedly - Get Smarter

Feedly - Get Smarter

  • DevHD
  • ニュース
  • 無料

お仕事のための情報あつめのアプリです。隙間時間にざーっと眺めて気になる記事やデザインをクリップしておくだけで、いざヒントが欲しくなったときの大事な情報源になります。

  • おすすめしたいアプリ

My日記

My日記

  • AnySense Inc.
  • ライフスタイル
  • 無料
理由:
ちょーシンプルな日記アプリなのですが、SNSとは違う自分だけの日記です。
最近日記は投稿してみんなで共有するのが当たり前になっちゃってますが、寝る前に1日を振り返って自分だけの日記をつけるのもなかなかいいですよ、落ち着きます。

  • 感想
    本人のイメージと打って変わってとんでもないトップ画でした。人は見かけによりませんね。
    あと七画面に一体何が埋まっているんだ…と不安にならざるを得ません…。
    紹介してくれるアプリはすごく為になるので、きっとインストール速度に整理が追いついて居ないんだ……と言い聞かせました。
    Gmailの通知に関しては、きょーさん曰く「Gmailは3つのアカウントを行ったり来たりするので、メルマガ系用の捨てアカウントのためにこうなっちゃってます(言い訳させて!)」だそうです。
    捨て垢の連携を解除してあげようと思います。

みのり

f:id:voice-tech:20180115180428j:plain

  • 一番使っているアプリ

    Instagram

    Instagram

  • おすすめしたいアプリ

    Waaaaay!(うぇーい!)

    Waaaaay!(うぇーい!)

    • Houchimin LLC.
    • ナビゲーション
    • 無料
    理由:これのおかげで方向音痴な私が道に迷わなくなった

  • 感想
    でた!色分け画面だ!!こじはるを隠したくない所にこだわりを感じました。
    めちゃくちゃ使いづらそうって言ったら慣れればどうにかなると言われました。オシャレは我慢ですね。
    私も方向音痴なので、waaaaaaaaaaaaaayをインストールしてみたいと思います。

あかよ

f:id:voice-tech:20180115184906p:plain

  • 一番使っているアプリ

    Netflix

    Netflix

    • Netflix, Inc.
    • エンターテインメント
    • 無料

  • おすすめしたいアプリ

HashPhotos

HashPhotos

  • beyondf
  • 写真/ビデオ
  • 無料

理由:
膨大なソシャゲのスクショを整理したくて色々調べた結果ありつきました。 自分でタグを作れるので細かいタグ付け管理ができるのがすごい便利。自動で類似画像を検索してくれる機能も素晴らしい。

  • 感想
    我ながら面白みがなくてもう少し頑張りが必要だと思いました…
    通知は貯めたくない派

最後に

スマホ画面を見てみて、為になったというよりかは性格が出るなということを強く思いました。
前回の自己紹介からだいぶイメージが崩れてしまった人もいるかもしれませんが、逆に素の部分も知ることができてよかったかもしれませんね!

そんなこんなで個性豊かなエンジニアが集うVoicyの個性豊かな一人になりたいあなた!ぜひ一度オフィスに遊びに来てくださいね。個性豊かな仲間たちがお迎えいたします。

www.wantedly.com

Voicyが創る未来 〜Voice UIとその先へ〜

皆様、あけましておめでとうございます!

新年1発目のブログはわたくしエンジニアのぱんでぃーが担当させて頂きます。 本年もVoicyをどうぞよろしくお願いいたします!

f:id:voice-tech:20180109192308j:plain

さて、皆様の2017年はどのような年になりましたでしょうか? Voicyはと言いますと、

といった具合に様々な変化があった年となりました。 詳しくは弊社CTOの窪田が投稿した前回のエントリーを是非、ご覧ください!

voicetech.hatenablog.com

そして、いよいよ2018年に入ったわけですが 本エントリーは、昨年の各種スマートスピーカーの日本上陸で一気に注目度が増したVoice UIについて紹介していきたいと思います!(音声UI、VUIとも記載されますが、本エントリーでは以下、VUIと表記いたします)

VUIとは

音声のユーザーインターフェースと聞くと難しく感じてしまうかもしれませんが、その概念は歴史としては古く、数十年前から注目されていました。身近でイメージしやすいサービスですと、iOSが提供しているSiriや電話の自動音声ダイヤルなんかもVUIの一つです。(音声ダイヤルはこちらからのレスポンスはナンバーを押す形式になるので、完全なVUIとは言えませんが。) 要は音声を使ったコミュニケーション、もっと言うとリアルの会話に近い、声を使った対話型アプリケーションということですね。

今はまだ馴染みが深いとは言い難いVUIですが、今後の日本でもスマートスピーカースマートハウスウェアラブルバイスが普及するにつれて、VUIを意識したプロダクト設計が重要になってくることは間違いありません。『2018年に技術とのインタラクションの30%がVUIになるだろう』というガートナーの予測も、アメリカのようなVUIが先行している国では現実のものとなっていくでしょう。

blogs.adobe.com

VUIと従来のUIとの違い

ではこれまでの一般的なアプリケーションと比較して、VUIのデザイン設計を行っていく上ではどういった点に気をつけていく必要があるのでしょうか?

まず最も大きな違いが、スクリーンが無いことによる情報量やコンテキストの差です。 下記のようにデバイスが変わることで、UIに求められるものも変化していきます。

  • デスクトップアプリ:スクリーンを増やすこともでき、複数のアプリを並列で使うことも可能。
  • モバイルアプリ:並列で動作できるが、スクリーンが小さいためコンテキストは基本的には1つだけ。コンテンツ自体はデスクトップアプリと同じでも問題無いケースが多い。
  • ウェアラブルアプリ:モバイルアプリよりもさらに視覚情報が少なくなるため、通知のようなちょっとした機能でもコンテンツを限定して見せ方を工夫する必要がある
  • スマートスピーカーアプリ:基本的には視覚情報が無く、音声の入力・出力を直列で交互に行う必要があるため、一連のやり取りにかかる時間が長くなる傾向にある。

特に最後のスマートスピーカーにおいては、現状では対話型のUIが主流となっているためユーザーが求めた結果を得るためのステップ数をいかに減らすかが重要になってきます。(電話の自動音声ダイヤルでイライラした経験を思い出して頂くと、その重要性が実感できるのではないでしょうか!)

その他にも、

  • GUIで言うところの入力フォームなどがないため、ユーザーの入力がフォーマットされず表現にバラツキが発生しやすい点
  • Webブラウザの『戻るボタン』といったものが無いため、アプリ側でナビゲーションを工夫しなければならない点

なども注意が必要です。

それでは実際にVUIを実現するためのアプリ開発プラットフォームを例に挙げて、VUIの作り方を見ていきましょう。

VUIの開発プラットフォーム

スマートスピーカーの市場シェアとしては2017年Q3にはトップのAlexaが67%、次いでGoogle Homeが25%になると予測されているため、いずれかの開発用プラットフォームを利用すれば良いでしょう。

robotstart.info

お手軽に試すのであれば、Web上の知見が多く、審査も通りやすいAlexa Skillsが良いかもしれません。 ただ、本エントリーでは比較的新しい開発用プラットフォームであるActions on Googleを例に挙げていきたいと思います。

Actions on Google

まず、簡単にActions on Googleについて説明します。 Google Homeの内部では、Google Assistantというサービスが音声認識を含め、全体のコントロールを行っています。そして、Actions on GoogleはそのGoogle Assistant用のアプリケーションを作成するためのプラットフォームとなります。Actions on Google上で作成された独自のサービスはGoogleの審査が通ればGoogle Assistantに追加されるので、実際にユーザーが保有しているGoogle HomeGoogle Asistant搭載のスマートフォンから利用可能となります。

Actions on Google上でのアプリ開発にはDialogflowという対話型インターフェースを作成するためのサービスが使われており、下記のような機能を提供しています。

  • 自然言語特有の表記の揺れや業界用語、方言などをAIに学習させることで、対話内のパラメータを適切に抽出(ユーザー定義の辞書も利用可能)
  • 多言語対応
  • 発言内容の履歴や呼び出し回数などのAnalytics用のデータを管理
  • Google Assistantだけでなく、Amazon Alexa, Facebook Messenger、Slackなどの各種サービスとの連携
  • Webhookを利用した外部のWebAPIとの連携

また、大きな特徴として、各プログラミング言語用のSDKを提供しているのですが、GUIアプリ開発コンソールが用意されているため非Developerでも簡単にVUIを開発することができます。細かい用語の説明は割愛しますが、ざっくりとした役割としては、

  1. Google Assistantが音声認識
  2. 認識されたユーザの発言内容をDialogflowで自然言語処理を行い、アプリがレスポンスを行うために必要なパラメータを抽出
  3. 抽出されたパラメータ毎に対応するレスポンスをアプリ開発者がひとつひとつ定義することで、入力と出力のマッピングを行う

といった感じです。

f:id:voice-tech:20180109184816p:plain

引用元(スクリーンショットhttps://www.youtube.com/watch?v=HNfE0uaKcfY

ちなみに、Actions on Googleの公式ドキュメントはVUIのデザインガイドやベストプラクティスなども紹介されているので、Alexa Skillsなど他のプラットフォーム用のVUIをデザインする際にも非常に参考になるでしょう。 https://developers.google.com/actions/design/principles

Voicyでの未来予想図・・・

最後に、『もしもVoicyのコンテンツを使ってVUIアプリを作成したら・・・』という、遠くない未来の話をしてみたいと思います。先程、概要を紹介したActions on Google上でアプリを作成すると下記のようなサービスが提供できます。

f:id:voice-tech:20180109205817j:plain

流れとしては非常に簡単に見えますが、実際に下記のような処理が内部で行われています。

  1. ユーザの発言からDialogflowがパラメータ(図の赤字で表記した『疲れてる』『笑える』『良い』など)を抽出
  2. Webhookを利用し、抽出したパラメータを含めた状態でVoicyが提供するするWebAPIにリクエストを送信
  3. Voicy内部のレコメンデーションロジックにより、オススメのチャンネルを選び出しWebAPIがレスポンスを送信
  4. アプリ開発者が定義したスピーカーからの返答文言に、受け取ったオススメチャンネルの情報を埋め込み、ユーザーへ返答
  5. 以下、ユーザーの望む結果となるまで繰り返し

上述した通り、アプリ開発者が行う作業としてはユーザーからの発言のパターンとそれに対する回答のパターンをユーザストーリーの分だけ登録することのみです。ただ、情報量が少ないVUIでは、与えられたパラメータ情報だけでユーザーにとって最適なコンテンツを提供することには限界があります。

そこでその時々でのユーザーのコンテキストをいかにして理解するかということが今後は重要になっていくと考えられます。具体的には、曜日や時間帯(休日?通勤中?就寝前?)や場所(自宅内?車の中?国内?海外?)などのユーザー入力ではないデータを含めてレコメンデーションを行うことで情報量の少なさを補っていく必要があります。

当然、従来のようなユーザーのデモグラフィック情報やビヘイビア情報、サービスの視聴履歴などのデータも使うべきですが、将来的にはユーザの声のトーンや顔色、一緒にいる人の人数といったようなセンサーデータも最適なコンテンツを提供するために活用することが当たり前になっていくでしょう。

Voicyでは音声プラットフォームとして、『ユーザーの気持ちや状況に合わせた好きな声やトークが集まってくるような世界』を創るため、日々、開発に勤しんでいます!『こんなステキな未来を一緒に創りたい!!』というアナタ!!是非、一度オフィスに遊びに来てください。運が良ければ、ホンモノのパーソナリティに会えるかも・・・!?

www.wantedly.com

2017年 Voicy開発総決算!

こんにちは!Voicy CTOの窪田です。

現在は2017年12月30日なのですが、オフィスは休みを取って実家に帰っている人も多く、外を歩いても人がまばらで、すっかり年末だなぁと思いながら書いております。

さて、この一年はみなさまにとってどんな年だったでしょうか?
今回のエントリーではこの1年間にVoicyのエンジニアがやってきたことを振り返ってみたいと思います。

3月2日 iPhoneアプリリニューアル

再生、録音アプリ共にユーザーからいただいたフィードバックから出てきた課題を解決するために、アプリの見直しを行いました。

f:id:voice-tech:20171230211558p:plain

画像は再生アプリのみですが、機能的なポイントとしては以下の通りです

  • タブを追加して好きなチャンネルを探しやすく
  • チャンネルにタグ付けを追加して内容を事前にわかりやすく
  • チャンネルの横スライドにドットをつけて現在地がわかるように
  • ドットの部分でもスライド可能に

タブ分けやタグ付けに伴ってDB構造から大きく見直しが必要だったこともあり、デザイン・開発共に大きな作業でしたが、リリースしてから半年もしないうちにこういった変更の決断と実行ができるスピード感はベンチャーならではだなぁと思います。

3月15日 ロゴ・ホームページリニューアル&Twitter Playerカード実装

さきほどのアプリリニューアルでも一足先に変わっていたのですが、Voicyのロゴを一新しました。それに伴ってVoicyのコーポレートサイトを全て作り直してます。

f:id:voice-tech:20171230211715p:plain

また、チャンネル紹介ページではTwitterシェアした際にTwitter上で再生できるPlayカードという機能もつけました。詳しくは以下のエントリーに詳しくまとめてありますので、ぜひご覧ください!

Twitterがしゃべる!?Playerカードの作成方法

5月14日 タイムライン機能リリース

さきほどのコーポレートサイトにある個別のチャンネルページに、Voicyで配信している内容をTwitterのタイムラインのように埋め込める機能を作りました。

f:id:voice-tech:20171230211735p:plain

ここでは初めてAngularを採用しています。そしてサーバーサイドも同じく初めてのGoで作っています。実はこの次に出てくるWEB版Voicyの開発でAngularとGoを予定していたため、比較的小さな開発のタイムライン機能で先行導入してみたという裏事情があるのですが、結果的にはどちらも採用してよかったと思っています。

7月18日 WEB版Voicyリリース

今年のVoicyで最も大きなリリースがこちらです。

https://voicy.jp/

プロジェクト自体は春ごろから動いていましたが、開発期間は約1.5ヶ月という短期間で作り上げました。技術としてはタイムラインでも使用していたAngularとGoで、詳しくは以下のエントリーをお読みください。

Go1.8とAngular4をプロダクションで使ってみた!Voicy WEB版の開発裏話
VoicyがGoLangとEchoを採択した理由。

これまでiPhoneでしか聴けなかったVoicyが、WEB版のリリースによりPCやAndroidでも聴いていただけるようになりました。おかげさまでユーザー数も増え、より多くの人に声を届けることができるようになったのは本当に嬉しく思います。

10月2日 Android版リリース

要望の多かったAndroid版をやっとリリースできました!

開発が始まる少し前にAndroid開発の公式言語としてKotlinが採用されたばかりでしたので、Voicyでは早速Kotlinを使って開発を行いました。当初の予定に比べると結構遅れてしまったのですが、技術的には新しいことへのチャレンジもできたので、エンジニアとしては満足しています。

まだiPhoneに比べると機能が少ない部分も正直あるのですが、今後も改善をしていきますのでよろしくお願いいたします!

10月5日 Google Homeに対応

Androidリリースの3日後には、このGoole Home対応を発表させていただきました。

音声のサービスVoicyとしては念願のスマートスピーカー発売です。

f:id:voice-tech:20171230211749p:plain

こちらはGoogleの発表資料なのですが、名だたる大手企業様の中、唯一ベンチャーのVoicyが並ばせていただけてとても嬉しく思います。Voicyからは公式ITビジネスニュースを提供していますが、他にもこの中にある毎日新聞スポニチも実はVoicyで配信をさせていただいております。

配信フローとしては

Google Home -> API Gateway
 -> Lambda -> ElasticBeanstalk(WEB版で作成したGoのサーバーに機能追加)

とフルAWSな構成となっています。

11月8日 Amazon Echo(Alexa)に対応

Google Homeに引き続き、Amazon Echoも日本で発売が開始されました。もちろんVoicyも発売初日からスキルを提供させていただいております。

f:id:voice-tech:20171230211811p:plain

こちらはAmazonの発表資料になります。

Google Homeでは公式ITビジネスニュースを提供していましたが、AlexaではVoicy公式総合ニュースを提供しております。また、上記の画像には入っていませんが、株式会社アルクのスキルの1つである「英語で泣けるちょっといい話」もVoicyで配信をさせていただいております。

配信フローは

Alexa -> Lambda
 -> ElasticBeanstalk(WEB版で作成したGoのサーバーに機能追加)

となっており、Google Homeに比べるとAPI Gatewayがありません。これはAlexaが直接Lambdaを呼び出すことができるためで、そこはさすがどちらもAmazonなだけのことはありますね。注意点としては、まだAlexaが日本リージョンのLambda呼び出しに対応していないため、北米等のリージョンでLambdaを作成する必要があるという点です。

まとめ

現在Voicyはフルコミットエンジニア2名と、手伝ってくれているエンジニア数名で作っているのですが、こうして振り返ってみると、少人数ながら結構作れているのではないかなと我ながら思っております。

開発とは直接関係がなかったのでここには載せませんでしたが、ユーザーを招いたイベントを今年3回行なっており、年明けの1月にもまた予定しています。もちろんエンジニアも全員参加です。しっかり開発しながらも、直接ユーザーと関わることのできる環境というのはなかなかないと思いますので、興味のあるエンジニアの方がいらしたら、ぜひ一度話を聞きに来てください!

www.wantedly.com

これからもVoicyは止まることなくどんどん開発していきます。すでに動いているプロジェクトもいくつかあります。人の持つ声の魅力を届けるためにこれからも成長し続けていきますので、2018年もどうぞよろしくお願いいたします!

Voicyのシステムについて & エンジニアメンバー他己紹介

こんにちは! 歌って踊れるエンジニア、Voicy1年目、社会人1年目の みのりです。

9月からVoicyで働いているのですが、 もはやここは職場なのかというくらい楽しく働かせていただいています。 (もちろんやる時はやる!という雰囲気ですよ!)
なんというか、よく代表の緒方さんもいうのですが部活のような雰囲気です。

私は大学時代化学を専攻していたので「エンジニア」という仕事を考えたことは就職活動をするまで一度たりともなかったのですが、 いろんな経緯で現在はVoicyでエンジニアをしています。

さて今回は、私がVoicyに入って初めて行った仕事、
「Voicyのシステムはどのようになっているかを調査してプレゼンする」

について、このブログを読んだみなさんにも少し紹介できればと思い執筆してみました!

【Voicyのサービス紹介】

まず、Voicyのサービスはこのようになっています。 f:id:voice-tech:20171226120223p:plain

Voicyを聞くことができる端末は、iOSAndroid、Web、スマートスピーカー。 配信者が自分の音声を録音するための「録音アプリ」は現在iOSのみに対応しています。 誰でも配信を聞くことができる「配信アプリ」はiOSAndroid、から出ており、またWebサイトから配信を聞くこともできます。 スマートスピーカーは現在、Voicy公式ニュースと公式ITニュースのみ聞くことができます。

インフラは全てAWSを使用しています。


【Voicyのシステム全体像はどうなっているの?】

以下の画像をご覧ください。 f:id:voice-tech:20171226145528p:plain (ここからはスマートスピーカーについては省略させていただきます)


Voicyのサーバーはアプリ用サーバとWeb用サーバに分かれています。 言語はアプリサーバがJava、WebサーバはGoです。 f:id:voice-tech:20171226145544p:plain

《ある日の会話》

初心者のみのり<どうしてこんなに言語が分かれているんですか、、?どうやって勉強すればいいのでしょう?)

ゆうじさん<オブジェクト指向がわかってれば言語が違ってもちょっと勉強すればすぐ書けるようになる!)

ゆうじさん<僕もGoはついこのあいだの4月にHello,Worldから始めたばかり)

初心者のみのり<………_:(´ཀ`」 ∠):m )

というようにVoicyの皆さんは常に学ぶことを忘れないので、新しいシステムにもどんどんチャレンジしていける素晴らしい環境です!
私も初めは戸惑いましたが皆さんわからないことがあれば親切に教えてくれますし、理解したら自分で手を動かしてみよう!とチャレンジさせてくださいます。
また、こちらの天才エンジニアゆうじさんは後ほど詳しくご紹介します!

次に、初めて出てきたワード「記事クローラ」について
Voicyでは、毎日新聞スポニチなど、多数有名メディアと提携しています。
なので、Voicyで配信する際にこれらの有名メディアの記事を使って簡単にネタを探すことができ、記事読みができるのですね。

そのそれぞれのWebサイトからVoicyの録音アプリに記事をクロールしてくるクローラは、Javaで書かれています。
(クローラとは:インターネット上のあらゆるWebサイトの情報を取得して、検索用データベース・インデックスを作成する自動巡回プログラムのこと)

そして、記事データがデータベースに登録され録音するアプリから記事を参照することができます。

このあと、録音する際のデータの動きとAWSでどの機能を使用しているのか、を詳しく説明したのですが、 ブログにすると長くなってしまう&ネットに流出できない! ので気になる方はこちらのページの「話を聞きに行きたい」をクリック!
[URL]https://www.wantedly.com/companies/voicy/projects



さて、ここからは私、みのりによる

勝手にVoicyエンジニアメンバー紹介コーナーです。

完全に私の主観でお送り致します。 とにかくみなさん面白くて優しい方達ばかりなので主観でも許してくれると信じています。

CTO 窪田雄司さん

f:id:voice-tech:20171226123232j:plain Voicyの全てのシステムを作った方。
なのに、初心者丸出しの質問をしても全く嫌な顔をせず教えてくれる優しさの塊で出来ているような神。
こう見えて毎回ライブに行くほどのモノノフで、一番の推しはかなこだそう。
また、38歳ながらにそうは見えない若者言葉の使い。
そのせいかとても接しやすい。(そのせいだけじゃない)
ゆうじさんの最近はまってるワード:文末に「き」をつける
例)「よき」、「ありがたき」

毎週木曜日は夜中の3時半まで新宿のゴールデン街に通い詰める飲み好き。
今度一緒に飲みに行きましょう。

ぱんでぃ(濱田恭匡)さん

f:id:voice-tech:20171226123229j:plain (Voicyの男性メンバーは写真を撮る時の基本姿勢が腕組みです)
楽天からVoicyに11月から転職してきた、自称リスクジャンキー。 確かに、ぱんでぃさんが初めてVoicyに面接に来たのが月曜、もう一度面接を受けに来たのがその次の日の火曜、オフィスで働き始めたのが水曜。 こんな行動力のある人っているんですね。
まだ会って1ヶ月半で5歳下の私にいじられても怒らない心の持ち主。いわゆるいじられキャラなのでしょう。笑

ぱんでぃさんが11月からVoicyにジョインしてくれたおかげで笑いのたえない職場になっています。素晴らしき。

きょう(京谷美穂)さん

f:id:voice-tech:20171226123225j:plain スピードとクオリティとキュートさと優しさ、全てを兼ね備える最強で最高なデザイナー。
なんと先日12月22日にVoicyに正式ジョインされました!

代表の緒方さんときょうさんが話をしているといろんなアイデアが次々浮かんで来るので、 きょうさんのおかげでVoicyの新しい事業が次々生まれています。

常にきょうさんは楽しそうに仕事をしていらっしゃるので、新卒1年目の私からすると社会で働く女性ってこんなにイキイキしてるんだな〜、
私も社会人何年目になってもずっとお仕事を楽しんでいられるようにいたい!と希望と目標にしている人です(^^)

あとお酒が大好きらしいので今度飲みに行きましょう。

あかよ(前回ブログ書いた人)

f:id:voice-tech:20171226123221j:plain 私と新卒の同期です。
ひょんなきっかけで、同じタイミングで私とVoicyにやって来ました。
ゴリゴリの情報学部卒なので、新入社員研修の際はたくさんあかよに質問して教えてもらったおかげで研修のプログラムを終えることができました。
言うなれば恩人。
とりあえずググってもわからないことがあればあかよに聞いています。
現在Voicyのアプリの不具合の修正はこの子がほぼ行なっています。
あと、いつも昼ご飯に家で作った鍋持ってきてる。レベル高い。


と、このようにVoicyに入社すればこんな素晴らしい方たちとお仕事ができますよ!

話を聞いてみたい方はこちらから↓

エンジニア率80%!20代の間にベンチャー創業期で挑戦したいエンジニア募集 - 株式会社Voicyのモバイルエンジニア中途の求人 - Wantedly

一緒にオフィス鍋しましょう!

[Swift4]文字列とFontAwesomeを同じUILabelに表示する

こんにちは。
Voicyエンジニア一年目の実は美人エンジニアだったらしいあかよです。

今回はiPhoneアプリ開発中に文字列とFontAwesomeを同じUILabelに表示する方法で少し手こずったため、まとめておきたいと思います。

作りたいもの

f:id:voice-tech:20171218215848j:plain

今回は上の画像にあるようなlabelを作成します。

NSAttributedStringでの実装

let nameAttr: [NSAttributedStringKey : Any] = [
   .font : UIFont(name: "Arial-BoldMT", size: 20)!
]
let name = NSAttributedString(string: "Voicy太郎", attributes: nameAttr)
  • FontAwesomeアイコン部分のフォント指定
    (色:orange フォント: FontAwesome)

FontAwesomeはコード上では以下を参考にUnicodeで指定する http://fontawesome.io/cheatsheet/

let iconAttr: [NSAttributedStringKey : Any] = [
   .foregroundColor : UIColor.orange,
   .font : UIFont(name: "FontAwesome", size: 20)!
]
let icon = NSAttributedString(string: " \u{f058}", attributes: iconAttr)
  • 文字列とFontAwesomeアイコンの合体
let nameAttributeString = NSMutableAttributedString()
nameAttributeString.append(name)
nameAttributeString.append(icon)

NSAttributedStringでの実装方法は以上になります。

  • これらをまとめると以下のようにできます
let fontSize = label.font.pointSize
        
// 文字列部分のフォント指定 
let nameAttr: [NSAttributedStringKey : Any] = [
    .font : UIFont(name: "Arial-BoldMT", size: fontSize)!
]
let name = NSAttributedString(string: "Voicy太郎", attributes: nameAttr)

// FontAwesomeアイコン部分のフォント指定
let iconAttr: [NSAttributedStringKey : Any] = [
    .foregroundColor : UIColor.orange,
    .font : UIFont(name: "FontAwesome", size: fontSize)!
]
let icon = NSAttributedString(string: " \u{f058}", attributes: iconAttr)
        
// 文字列とFontAwesomeアイコンの合体
let nameAttributeString = NSMutableAttributedString()
nameAttributeString.append(name)
nameAttributeString.append(icon)
label.attributedText = nameAttributeString

まとめ

今回は同じlabel内で複数のフォントと色を指定するのみでしたが、NSAttributeStringで指定できる属性は他にもあるのでまだまだいろいろな用途に使えそうですね。

Voicyでは現在エンジニア募集中です!
まずは話を聞いてみるだけでも大歓迎ですので、是非一度オフィスに遊びに来てください! (オフィス鍋もやってるよ) https://www.wantedly.com/companies/voicy/projects

(参考)
Font Awesome を Xcode で使用する - xykのブログ
UILabelをNSAttributedStringで文字装飾(Swift 4対応) - Qiita

Voice Techを支える音声処理APIをPython+Falcon+Docker+ECSで開発した話 〜技術選定の苦労話を添えて〜

こんにちは! 11月からVoicyでエンジニアとして働き始めたぱんでぃーです。

前回のエントリーからしばらく間が空きましたが、 ここ数ヶ月でVoicyを取り巻く環境も大きく変わってきました。

具体的には

www.wantedly.com

などがありましたが、今回のエントリーは2つ目のGoogle Homeにも関連するテーマで書きたいと思います。

今回のプロジェクトの背景

現在、Voicyでは下記のように1回の配信の中に複数のチャプターが含まれています。

f:id:voice-tech:20171212203554p:plain

実際の音声ファイルもチャプターごとに存在するのですが、Google HomeやAlexaなどのデバイスから音声コンテンツを配信する際にはひとまとまりのファイルに収まっていた方が都合が良い事があります。 そこで、今後Voicyが様々な声に関するサービスを展開していくための処理基板として、音声処理用のRESTful API(以下、AudioProcessor)を開発する事になりました。

今回はそのプロジェクトの中での技術選定の理由や全体のシステム構成などについて、下記の流れでご紹介していきたいと思います。

主要な技術スタック

まずは主要な技術スタックとその選定理由を紹介します。

音声ファイルの処理エンジン

FFmpeg 音声だけでなく動画ファイルにも対応した、マルチメディアファイル用のエンコーダです。 音楽業界のエンジニアさんも使用している、音声処理ソフトウェアのスタンダードなライブラリの一つです。

FFmpeg(エフエフエムペグ)は動画と音声を記録・変換・再生するためのフリーソフトウェアである[3]。Unixオペレーティングシステム (OS) 生まれであるが現在ではクロスプラットフォームであり、libavcodec(動画/音声のコーデックライブラリ)、libavformat(動画/音声のコンテナライブラリ)、libswscale(色空間・サイズ変換ライブラリ)、libavfilter(動画のフィルタリングライブラリ)などを含む。ライセンスはコンパイル時のオプションによりLGPLGPLに決定される。コマンドラインから使用することができる。対応コーデックが多く、多彩なオプションを使用可能なため、幅広く利用されている。 https://ja.wikipedia.org/wiki/FFmpeg

クロスプラットフォームの音声処理用のソフトウェアとしてはPortAudioも対抗馬として挙がっていましたが、FFmpegは「動画ファイルから音声ファイルだけを抽出する」といったこともできるため、今後のサービス展開も考慮してFFmpegを採用しました。

開発言語・フレームワーク

  • Python (ver. 3.6.3)
  • Pydub Python用に開発された、FFmpegの音声処理機能のみを簡単に扱うためのWrapperライブラリ。(ちなみに上述したPortAudio用のWrapperライブラリとしては、PyAudioがあります。)
  • Falcon RESTful APIに特化した高速で軽量なフレームワーク

VoicyではAPIなどのサーバーサイドの言語はGOに寄せていこうという流れがありますが、GO用の音声処理ライブラリで良さそうなものが見つからなかったため、第二の選択肢としてPythonで探した結果、Pydubというライブラリが良さそうだったため採用に至りました。

社内にはFFmpegに精通したエンジニアがいなかったため、公式ドキュメントの充実さは選定基準として重きを置いていましたが、その点、Pydubは公式のAPIドキュメントが非常に充実しており、FFmpegを使用したことが無い場合でも容易に扱うことができました。

GO用のライブラリとしては、gmfが良さそうでしたが、Beta版である事とドキュメントが少ない点がネックとなりました。

また、API開発用のFalconについては下記の記事などが参考になります。

Pythonフレームワークとしては、DjangoやFlask、Pyramidに比べると新しいですが、公式ドキュメントGithubのWikiが充実しており、RESTful APIに必要なRoutingやValidationなどのロジックをシンプルに書けるので、新規でAPIを開発するのであればFalcon一択と言っていいのではないでしょうか。

今回のプロジェクトとは直接的には関係ありませんが、VoicyではまだPythonで書かれたプロダクトがありませんでした。ただ、今後Voicyがユーザのデモグラ情報やビヘイビア情報を活用したサービスを展開していく上で、Pythonを使ったデータ分析は避けては通れない道となるのでこの機会にPython資産を作りたかったという背景もありました。(自分の"好みの声だけ"に包まれた生活とか、想像しただけでステキじゃないですか!?)

APIの実行環境

DockerとAlpine Linuxについて

まずは何と言ってもDocker。これの採用は外せませんでした。 Pythonと言えば、初学者が環境開発(特に仮想環境の構築)で悩むことで有名ですね。

qiita.com

また、FFmpegも複雑・・・という程ではないですが、インストールにひとクセあるソフトウェアですので、Dockerを使ってImageをPullするだけでサクッと同一の環境を作れるのは非常にありがたいです。

DockerのOSは軽量でDocker Imageには最適な、Alpine Linuxを選んでいます。 実際に採用しているのは公式のAlpine Imageではなく、下記のImageですが、

https://hub.docker.com/r/gliderlabs/alpine/

両者の違いやgliderlabs/alpineを選ぶ理由については下記のサイトで詳しく述べられているため、このエントリーでは割愛します。

また、APIの実行環境を構成するためのDockerfileはこちらです。

# Use Alpine Linux as a parent image
FROM gliderlabs/alpine:3.6

MAINTAINER voicy.jp

# change system timezone to Asia/Tokyo
RUN apk update && \
    apk-install tzdata && \
    cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

# setup pyton runtime
RUN apk-install \
        'python3<3.7' \
        'python3-dev<3.7' \
        build-base && \
    echo "Dockerfile"        >> /etc/buidfiles && \
    echo ".onbuild"          >> /etc/buidfiles && \
    echo "requirements.txt"  >> /etc/buidfiles

RUN apk-install 'ffmpeg<3.5'

WORKDIR /app

# Copy the current directory contents into the container at /app
COPY . /app

# Install any needed packages specified in requirements.txt
RUN pip3 install --trusted-host pypi.python.org -r requirements.txt -c constraints.txt

# Make port 8000 available to the world outside this container
EXPOSE 8000

RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

いくつか解説しますと、

# change system timezone to Asia/Tokyo
RUN apk update && \
    apk-install tzdata && \
    cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

Alpineのパッケージ管理ツールである、apkコマンド(Ubuntuで言うところのaptコマンド)の更新を行った後、Dockerコンテナ内のOSのタイムゾーンAsia/Tokyoに設定しています。

# Install any needed packages specified in requirements.txt
RUN pip3 install --trusted-host pypi.python.org -r requirements.txt -c constraints.txt

APIの実行に必要な依存パッケージのインストールを行っています。 プログラムが直接依存しているパッケージをrequirements.txtにバージョン指定無しで記載し、

awscli
boto3
falcon
gunicorn
jsonschema
pipdeptree
pydub
python-json-logger
requests

constraints.txtにこれらの依存パッケージが依存しているものも含めた、全ての依存パッケージをバージョン指定と共に記載することで、柔軟にパッケージ管理を行えるようにしています。

appnope==0.1.0
astroid==1.5.3
awscli==1.12.1
.
. (省略)
.
traitlets==4.3.2
urllib3==1.22
wcwidth==0.1.7
wrapt==1.10.11

詳しくは下記で解説されています。

RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

APIサーバーを起動するためのスクリプトに実行権限を付与してから、実行しています。docker buildコマンドでImageを作成する際に、COPY . /appした時のオリジナルファイルに実行権限があれば良いのですが、念のために設定しておいた方が安心です。(私も実際にここで少しハマりました。。。)

entrypoint.shでは単純にPython製のWSGI(Web Server Gateway Interface)サーバであるgunicornを起動しているだけですが、後述のECSの「タスク定義」で環境変数ENVを設定する事により、gunicornの設定ファイルを開発用と本番用で切り替えています。

#!/bin/ash

if [[ "${ENV}" = 'prod' ]]; then
  gunicorn --config ./environments/prod/gunicorn.conf.py 'audio-processor.app:get_app()'
else
  gunicorn --config ./environments/dev/gunicorn.conf.py 'audio-processor.app:get_app()'
fi

gunicornの起動設定以外にも環境変数を使って、下記のような制御を行っています。

  • データベースやS3などの接続先を本番用と開発用で切り替え。
  • 本番環境ではログ分析を行いやすくするためにJSON形式で出力し、開発環境では見やすいプレーンテキストでログ出力。

このへんの設計方針に関しては、The Twelve-Factor App (日本語訳)が非常に参考になりますので、まだご覧になっていない方は是非読んでみてください。

コンテナオーケストレーションとしてのECS

最後に、このプロジェクトを通して最も悩まされたAWSでのコンテナ管理サービスの選定についてです。 本エントリーを執筆中の2017年12月12日時点では選択肢としては下記の3つになるかと思います。

これら3つの違いについてはこの記事がよくまとまっています。

qiita.com

最終的には、採用実績やWeb上のドキュメントが豊富な点でECSを採用しましたが、実際に運用を始めてみると下記のようなデメリットも見えてきたので、AWSでのベストプラクティスについては今後も検討する必要がありそうです。

  • Dockerコンテナに対するロードバランシングとコンテナのホストマシンであるEC2インスタンに対するロードバランシングを2重で管理する必要がある。
  • SwarmやKubernetesといったDockerネイティブのオーケストレーターを使えない。 ※ Kubernetesについては次期バージョンでネイティブサポート。
    [速報]DockerがKubernetesとの統合およびサポートを発表。DockerCon EU 2017 - Publickey
  • クラスター、サービス、タスクといったECS独自の概念を覚える必要があり、これがまた少し複雑。

Docker for AWSAWSではなくDockerコミュニティ製のオーケストレーターですが、CloudWatch Logsなどのサービスとも簡単に連携でき、機能としては最も魅力的に映ったのでもう少しドキュメントが充実してきたら積極的に採用してみたいところです。

アップデートの早いECSでのコンテナデプロイ環境の構築については公式ドキュメントを読み込むのが一番ですが、上述したECS独自の概念があるため、下記も併せて読むのがオススメです。

コンテナ管理サービスを選定中に「正直、コンテナオーケストレーションではKubernetesがデファクトスタンダードになりつつあるのにな。。。。今回はAWS上で構築すると決めたけど、やっぱりGKE使いたい。。。」と憂鬱な思いにもなりましたが、ついに出ましたね!! 先日開催されたAWS re:Invent 2017で更に2つのコンテナ管理サービスが登場し、AWS上でもKubernetesが使えるようになりそうです。

  • EKS(Elastic Container Service for Kubernetes)
  • AWS Fargate

tech.recruit-mp.co.jp

システム構成

最終的にAudioProcessor周りのシステム構成は下記のようになりました。 (今回のエントリーに関わりの少ないサービスは色を薄くしています。)

f:id:voice-tech:20171212212919p:plain

一例として、Google Home用に複数の音声ファイルを結合する処理の流れを解説します。

  1. パーソナリティが録音アプリで登録した複数の音声ファイルがS3のVoicy App Bucketに登録され、URIがRDSに登録される。
  2. 定期実行されているバッチが結合待ちの音声ファイル情報をRDSから取得し、ELBを通しECSのAudioProcessorに音声ファイル結合のリクエストを送る
  3. AudioProcessorはS3のVoicy App Bucketから音声ファイルをダウンロードし、FFmpegのWrapperライブラリを通し音声ファイルを結合。その後、S3のAudioProcessor Bucketにアップロード。
  4. AudioProcessorからのレスポンスで受け取ったURI情報を元に、AudioProcessor Bucketから結合済みのファイルをダウンロードし、Voicy App Bucketへアップロード。その後、Voicy App BucketURI情報をRDSに登録。(AudioProcessorはサービスとは独立した位置づけにしているため、バケット間の直接移動はあえて行っていません)
  5. Google Homeで音声コンテンツが呼び出された際はAPIサーバを介し、結合済みの音声ファイルをS3から配信。

以上がざっくりとした処理の流れです。 今回のスプリント内では達成できなかった今後の課題としては、

  • TravisCIやCircleCIを使った自動テスト・コンテナの自動デプロイ環境の構築
  • ECSでのコンテナオーケストレーションの最適化

などを進めて行きたいと思っています。

長くなりましたが、今回のエントリーが皆さんのDockerやPythonを使った開発プロジェクトの助けになれば幸いです。 また、Voicyではフロントエンド・バックエンドを問わずフルスタックで新しい技術に挑戦できる環境がありますので、「新しい声の世界・サービスを自分で創ってみたい!!」というエンジニアの方はオフィスに遊びに来てもらえると嬉しいです!

次回のエントリーはVoicyに新卒で入った、美人エンジニアの投稿を予定していますので、乞うご期待ください!