大型機能リリースを振り返る

はじめに

Voicyでバックエンドエンジニアをしているmasaです。

先日、パーソナリティ向けの新機能としてコラボ収録機能がリリースされました。

自分が入社して初めて携わった大きな機能開発ということもあり、せっかくなのでつらつらと振り返りをしていこうと思います。

コラボ収録ってどんな機能？

一言で表すと、「リアルタイムで離れた距離にいる参加者と顔を合わせながら収録ができる機能」です。
ざっくりイメージとしては、ZoomやGoogle Meetのようなオンライン通話機能 + 収録機能 といったイメージになります。

コラボ収録機能を利用するステップとしては、

1. ホストが収録をするためのルームを作成し、ルームURLを参加者に共有する
2. 参加者がURLリンクからルームに入る
3. ホストが収録開始する
4. ホストが収録停止する
5. ホストが収録した音源を放送として公開する
   といった流れになります。

プロジェクトの進め方

プロジェクト全体のスケジュールは以下のような形で進んでいきました。

コラボ収録機能のプロジェクトは今年の2月末ごろから始まり、全体のリリースまでできたのが10月中頃と、半年以上の期間がかかった大型のプロジェクトでした。

プロトタイプの開発

2月末にエンジニア/PdM/デザイナーなどの関係者が集まり、プロジェクトの目的や仕様の共有などをチーム全体で行いましたが、この時点では「やりたいことは決まっているが、どこまでのことが実現できるのかが不透明」といった状態でした。
そのため、まずは「やりたいことが本当に実現できるのか？」ということの検証からプロジェクトが進んでいきました。

プロトタイプでは、「いかに早く検証を完了させるか？」ということをチーム全体で意識をしており、

• 最低限の機能開発をする
• まずは実現できるかどうかを検証したいものなので、設計の汚さは許容する
• コードレビューは基本的には不要
  • テストで挙動をある程度担保する

といったような考えのもとで開発を進め、約2ヶ月というスピード感で「やりたいことは実現できそう」ということを検証することができました。

本格開発開始

上述の通り、4月末ごろにプロトタイプでの検証を終えて「このまま本格開発に進んでいこう！」という意思決定をすることができたので、5月から本格開発を進めていきました。

Voicyの開発組織の中でちょうどこのあたりの時期にClean Agile(原著)の輪読会が開催されていたりと、開発組織全体でアジャイル文化について学んでいたということもあり、コラボ収録機能の開発でもプロトタイプを開発している時からアジャイルに開発を進めていきました。
イテレーションの終わりにエンジニアだけでなくPdMやデザイナー含めたチーム全体で集まってそのイテレーションでの成果物を共有することで、

• 想定していた仕様と異なるところはないか？
• デザインに違和感はないか？
• ユーザー体験として悪いところがないか？

などを短いスパンでチーム全員で細かく確認をすることができたため、大きな手戻りなどなく開発を進めていくことができました。(私のいるチームでは、2週間を1イテレーションとして開発を進めていました。)

アジャイルの思想になりますが、差分の大きくなるビッグバンリリースを避け、「安全な単位で1つ1つデプロイを進めていく」という方針でを開発を進めていきたいと考えていたのですが、「どのようにして未完成の機能をユーザーには見せないようにしつつ、1つ1つの開発を進めていくか？また、デプロイしたものが期待した動作を実現できているかどうかをどのようにして確認するか？」ということを実現する方法が問題になりました。

これまでのところで述べているように、「小さく安全にデプロイは進めていきたい。しかし、未完全な機能をユーザーに見せることはできない。一方で、開発を進める上では色んな環境(Dev, Stage, Prod)で動作確認をしたいので、機能自体は扱えるようにしたい。」というジレンマのようなものがあったので、この問題を

• リクエストしてきたユーザーがコラボ収録機能を利用してもいい人がどうか？

という表現ができるものを追加することでを解決しました。(いわゆる、フィーチャーフラグと呼ばれるものです。)

小さな単位で安全にデプロイを少しずつ進めていったことで、半年以上という大きな開発だったにも関わらず、リリース後に発生した優先度高く対応が必要な不具合を1つだけに抑えることができたのは非常に良かったなと思っています。(12/14時点。この問題がどういったものだったのかについては後述します。)
また、まずは一部の限定したユーザーで使えるようにしたいという要望もあったので、フィーチャーフラグを使うことでその要望に簡単に対応できた点も良かったと思います。
フィーチャーフラグを利用した開発は今後の新機能開発でも使える手法になるので、必要なタイミングで今後も使っていきたいと考えています。

また、テストもこれまでは書けていると書けていないところがあり、テストを書く方針も明確なものがなかった(ように思う)のですが、このプロジェクトではチームとして「基本的にテストは書くもの」という共通認識を持ちながら開発を進めていくことで品質担保にも注力しました。(ここで述べているテストはユニットテストを指しています。)

テストをすることで品質の担保が一定できるようになったことに加えて、これまでテストするかどうかの方針がなかったところに対して、「ROIの合わないと判断できそうなところはテストしない」というような方針を持てるようになったことは良かったです。
例えば、「外部サービスと繋がるところなどテストすることが難しく、ROIが合わないと判断できそうなところはテストをしない」というような方針をチームで共通の認識を持てるようになりました。

ただ、ここは今振り返ると、「外部サービスと繋がるところは似たような挙動をする偽物を作って、それが呼ばれていることと外部サービスをラップしている部分が期待している動作を提供していることをテストする」ということはできたのかなというようなことをぼんやり考えたりしています。

開発の上で難しかったポイント

ここまでのところは、どのような開発プロセスで開発を進めたのか/このプロセスで上手くいった点はどこだったか、などにフォーカスしていたので、ここでは反対に難しかったポイントなどについて触れられればと思います。

参加者の情報をどうやってリアルタイム性を持たせるか

最初の「コラボ収録ってどんな機能？」というところで述べたように、コラボ収録機能はオンラインで参加者同士が会話できる機能になるので、参加者全員が他の参加者の状態を常に分かるような状態になっておく必要があります。
ここは、Heartbeatという考え方を元にして実現できるようになっており、定期的に他の参加者の入退室情報などを取得できるAPIを実行することで(ほぼ)リアルタイムで他の参加者の情報を取得できるようになっています。

外部サービスとの付き合い方

Facebook Messengerからコラボ収録を開始できない

これが、上述の「コラボ収録機能リリース後に気付いた不具合」になります。
コラボ収録機能では、ホストがルームに入るためのURLをSNSやメールなどでゲストに共有すると、ゲストはそのリンクをタップすることでコラボ収録に参加できるようになります。

SNSでリンクがコピーされた場合は、そのリンクをタップするとアプリ内ブラウザが起動し、Webページに配置している「アプリを開く」のようなボタンをタップするとアプリに遷移してコラボ収録ルームに入れる、といった流れになるのですが、なぜかFacebook Messengerから入ろうとする場合のみアプリに遷移しないという不具合が起こってしまっていました。

おそらく、Meta社の方でリンクからアプリへの遷移ができないように制御しており(公式からの情報は見つけられませんでしたが、フォーラムから同様の事象を発見し、他のアプリでもMessengerからアプリが起動できないことなどを確認しました。）、それによってうまくアプリへの遷移ができませんでした。

(詳細は割愛しますが、)別の解決法でなんとか対応できたのですが、リリース前のQAでは、自分たちの都合のいいSNS(主にslack)でしか参加までの一連の流れを確認できなかったので、QA事項として使うことが想定されているSNSいくつかでリンクを共有した際の挙動を確認するべきだったね、という振り返りをチームでしました。

また、実装時点ではMessenger経由の動作も確認していたのですが、フォーラムを見る限りではおそらく私たちが確認をした時より後にMessenger上の仕様の変更がされており、それ以降でちゃんと試せていなかったことでリリースするまで気づけなかったという問題もあったので、「外部サービスに依存するところはリグレッションテストなどで定期的に確認するべき」などといったことも振り返りとして出てきました。(ここは工数との兼ね合いにもなりますが...)

Voicyサービスと外部サービス間の整合性の担保

コラボ収録機能のオンライン通話機能や、オンライン通話の録音機能としてAgoraという外部サービスを使用しています。
録音状況など、Voicy内で管理しているデータとAgoraで管理しているデータで不整合があると、予期せぬエラーが発生する可能性があるため必ず整合性をとれるようにする対応をしました。
ここでどういった対応をしたのかなどは、数日後にアドベントカレンダーの記事として公開予定です。

まとめ

Voicyに入って初めて携わった大きなプロジェクトを振り返ってみて、プロジェクト全体で良かった点/改善できる点や、ここには書ききれませんでしたが、個人として良かった点/改善できる点を改めて考えることができるいい機会になりました。
今現在もどんどん新規機能開発のプロジェクトが走っており、今後もどんどん新機能開発が想定されているので、今回の学びを活かしてよりよい開発プロセスで、よりよいサービスの提供をしていきたいと思います！