おはこんばんちは、Webチームで今年5月からエンジニアをやっている ぐりこ（@glico800）です。
先週の5/20(月)に弊社で開催した「visasQ Engineering Meetup #2 -ビザスクを支える技術-」について、当日の様子や発表内容などを一部ご紹介します。ここでご紹介する内容は発表のごく一部なので、より詳しく知りたい方は各項目末尾にあるスライドを覗いてみてください。
ちなみにWantedlyにもLite版のイベントレポートがあるので、こちらからぜひ覗いてみてください。
イベント概要
visasQ Engineering Meetup は日本最大規模のスポットコンサルのマッチングプラットフォーム「ビザスク」の開発に関する学びやサービスの立ち上げ・拡大過程でエンジニア組織がどのように変化し、どのような取り組みを行っているのか、その学びや知見をもとにエンジニア同士が交流・意見交換する場です。
今回は「ビザスクを支える技術」をテーマにCTOの花村、VQポータル開発チームの喜多、Webチームの村上から発表がありました。
また、会場ではお酒（今回はクラフトビール🍺）とピザを提供しており、最初に乾杯をしてからLTが始まるスタイルでやっています。会場には登壇者以外にもビザスクのエンジニアが参加しており、お酒を飲みながら気軽に話し合える場を目指しています。
LT#1 「ビザスクを支える技術」
最初の発表は CHO（Chief Hamburger Officer ）の花村による「ビザスクを支える技術」
ビザスクのやっているスポットコンサルのマッチングサービスはここ数年でかなり認知されてきているのですが、エンジニアさんからの認知率がとても低い（花村調べ）ため、まずはスポットコンサル自体の説明をしていました。
続いてビザスクの開発環境について。インフラは GCP、バックエンドは Python (Django) を使っており、フロントエンドは AngularJS から Vue.js へ移行中です。
また、データ分析ツールをかなり積極的に導入していて、Google Analytics や Redash などはもちろん、サイト訪問者の様子を録画してくれる FullStory なども採用しています。
今後のチャレンジとしては、スピード最優先な開発で溜まった技術的負債の返済に向けた大規模なリファクタリングやWebチームによるUX改善プロジェクトなどを進めています。
さらに、グローバル展開に向けた開発や新サービスの計画などの長期プロジェクトも今後ぞくぞくと始動予定です。
そのため、現在ビザスクではエンジニアを超積極採用中です！ご興味のある方はぜひ Wantedly や Forkwell Jobs からぜひ気軽にお声掛けください！
LT#2「クライアントポータルを支える技術」
2番目はクラフトビール大好きエンジニアの喜多による「クライアントポータルを支える技術」
最近VQポータル開発チームで開発したクライアントポータルとそこで使った Firebase Realtime Database の話がメインでした。
まずはクライアントポータルの説明から。
クライアントポータルとは、フルサポート形式「VQ」において、クライアントと弊社スタッフのコミュニケーションをサポートするためのプラットフォームです。
クライアントポータルの開発では、Vue.js や Firebase などの比較的新しい技術を積極的に採用しています。
クライアントポータルにおけるチャットの構成と Firebase 採用についてのお話。
バックエンド開発なしでチャット開発に必要な認証やDBなどの機能が一通り揃う Firebase は本当に便利です。また、最近はかなり Firebase に関する知見も多く公開されていて、情報が集めやすいのも嬉しいですね。
そしていよいよ Firebase Realtime Database のお話。
初めて Firebase Realtime Detabase のような NoSQL DB の設計する時は特に悩ましいところ。特に RDB の設計をしっかりやったことがある人ほど頭を抱えるのではないでしょうか。
設計のコツの1つとして紹介されていた「データの冗長化」について。
Users と Rooms だけで実現すると Rooms の件数が増えるほど処理時間が増えてしまいますが、userRooms のような中間データを用意しておくことで、件数に依存しない処理が実現できるそうです。
私は RDB の設計は基本的なことしか分かりませんが、データを冗長化するというのはちょっと不思議な感覚です。
最後は Firebase Realtime Database のアクセスルールの作成で便利な Bolt Compiler の紹介。
JavaScript風の書き方でルールを書くと、実際のアクセスルールに変換してくれる優れものです。これで type や Function などを使って書けるようになるので、ルールを書くのが少し楽になるようです。
以上、VQポータル開発チームの喜多による「クライアントポータルを支える技術」から一部紹介でした。
今回のイベントページには Firebase のことが全く触られていなかったので、Firebase を普段から使っている、または興味があって触ってみたい思っている人はぜひ以下のスライドも覗いてみてください！
LT#3「TwilioとStripeを使った従量課金サービスの裏側」
最後のLTはサラダチキンとオールドファッションをヘビロテしている村上による「TwilioとStripeを使った従量課金サービスの裏側」
昨年8月リリースの通話課金機能で使った Twilio と Stripe のお話。
通話時間によって依頼料を自動で決定する通話課金機能での電話API の Twilio を採用理由の話。
また、電話した後に依頼料が決定し、事後決済になることから Stripe で仮売上の仕組みを利用したそうです。
まずは Twilio の説明から。通話課金では依頼者が Twilio の050から始まる番号に電話することでアドバイザーに電話転送されるようになっています。
Twilio を使うと通話時間の計測や通話の強制終了が実現できるそうです。また、ユーザー同士が直接電話番号を交換せずに通話が実現するというのもサービスによってはメリットになるかなと思いました。
まずは Stripe での仮売上の話。
依頼者とアドバイザーによる事前相談の時点でクレジットカードを登録してもらい、そこで与信だけ通すようにすることで、キャンセル料金分を事前に確保するそうです。
ただし、確保期間が7日のため、電話相談の実施3日前にもう一度与信の確認をしています。この辺は実際に仮売上の仕組みを利用したことがないと知らなそうな内容ですね。
Twilio を使った実際の通話フロー。twiml を記述することで依頼者からの電話をアドバイザーの電話番号に転送するようになっているそうです。
本編では触れられていませんでしたが、twiml を追加することで特定の日にしか電話を受けないようにしたり、転送待ちの間に音声メッセージを流したりもできるらしいです。
また、依頼者から電話しなくても Twilio から依頼者とアドバイザー両方に架電することもできるそうです。（手数料が高くなるので今回は利用を見送ったとのこと。）
最後は、Twilio からもらえるCallログの話。
今回の主目的は「CallDuration」（通話時間）の取得でしょうか。
以上、Webチームの村上による「TwilioとStripeを使った従量課金サービスの裏側」から一部抜粋しての紹介でした。
まとめスライドにさらっと書いてありますが、依頼者がSkypeで取得した050の番号を使って Twilio の050の番号にかけると転送がうまくいかないなどのトラブルもあったようです。（発信者番号が非通知になるため、転送できなかったようです。）
今回の発表では主に決済の正常系を前提にした話が多かったですが、決済系は本当に考えることが多く、かつ少しの失敗が大きなトラブルに繋がるので、本当に大変だったと思います。
まとめ
いかがだったでしょうか？
今回のイベントレポートでは、当日の発表内容から技術的な話をメインで抜粋してご紹介してみました。（そしたらものすごく長くなってしました。）
また2~3ヶ月後に開催を予定しているので、興味のある方はぜひ connpass のグループ に参加してください！！
