ID:70369さん

目的・背景

• オンラインコミュニティ内のエンドユーザーの悪質、不適切な発言によって、運営者が疲弊し、コミュニティクローズになるケースが複数発生していた。

• 上記のようなメッセージを投稿しているユーザーをシステムが強制的に解約したと見えるように、管理者から削除の要請ができるようにしたい。

プロジェクト概要

オンラインコミュニティ内での不適切なメッセージに対して削除を要請する機能、及び削除されない場合に自動で退会させる機能を追加しコミュニティ運営者を守る。

担当

エンジニアとして1人で以下実装を全て担当

• DB設計

• バックエンドの実装

  • APIの実装
  • Sidekiqを用いた該当ユーザーの退会予約処理の実装

• フロントエンドの実装

  • 削除の要請を行うモーダルの実装
  • 管理画面での削除要請履歴の表示

プロジェクトのチーム規模

• エンジニア1名
• PM1名
• テスト担当者 4人 （カスタマーサクセス3人 PM1人）

仕様

悪質なメッセージに対して、管理者が削除を要請しそれに応じなかった場合24時間後にメッセージ送信者を自動で退会させる

工夫した点

機能の実装を慎重に行い、テスト（Rspec）での品質の担保

ユーザーの退会を扱うこともあり慎重に実装する必要があったので、Rspecはかなり手厚く書きました。
該当するメッセージを削除しなければ24時間後にそのユーザーを自動退会させるという機能なので、あらかじめテスト観点を作成しておきそこからテーブルの追加 => Rspecでのテスト項目の追加 => モデル及びコントローラーの実装という順番で進めました。

以下のようなテスト観点を事前に細かく作成していました。

• 削除要請を行ったとき、メッセージ送信者、運営者にメール及びコミュニティ内での通知届くこと
• 対象のユーザーが24時間以内にメッセージの削除を行ったとき退会させられないこと
• 対象のユーザーが24時間以内にメッセージの削除を行わなかったとき退会させられること
• 運営者が削除の要請を24時間以内に取り下げたとき、メッセージを送ったユーザーが退会させられないこと

Request Spec、Model Spec、MailerのSpec、Sidekiqで非同期処理を行うWorkerに対するSpecを慎重に書くことを徹底していました。Timecopを用いて24時間後、24時間経つ寸前の状態を作り信頼できるテストを書いていました。

削除要請されたことを履歴として残すことを考慮した設計

削除要請されたことを履歴として管理画面に残せることを考慮した設計を行いました。
メッセージが保存してあるテーブルと削除要請の履歴を残すテーブルの間に中間テーブルを作成することによって、該当する不適切なメッセージが削除された場合でも削除要請された履歴を残すことができます。

中間テーブルが残っていた場合は、削除要請された後、該当する不適切なメッセージが削除されていないという判定を行い、そのユーザーを24時間後に自動で退会するという要件を満たした適切な運用をすることができました。

メール配信の丁寧な実装

この機能で10種類メールを追加しました。これらのメールが不具合なく送信されるよう、Mailerのテスト（Rspec）の実装、非同期処理においてjobが積まれることを確認するSpecを丁寧に実装しました。

慎重な動作テストの作成

カスタマーサクセスチームが行う動作テストを上記Rspecの元、PMと話し合いながら慎重に作成しました。
あらゆる操作を想定しスプレッドシートで数百行のテストを作成しました。
無事に全てのテストを通過しリリースすることができました。

目的・背景

• コミュニティ毎にPV数や流入経路の変化などのデータの可視化を行い集客に関する効果検証を行えるようにしたい。

• GAは活用ハードルが高く、使いこなせてない人が多いのでコミュニティ内の管理画面で月毎、日毎のコミュニティのPV数を見れるようにしたい。

プロジェクト概要

各コミュニティの管理画面でトップページ（ / ）、概要ページ（/about）のPV数の変化のグラフを日毎、月毎に表示できるようにする。

担当

エンジニアとして1人で以下実装を全て担当

• DB設計
• バックエンド
  • 日毎、月毎のPV数を取得するためのAPI
  • AWS EventBridgeを用いてBigqueryから取得したPV数をS3にバイナリデータとして保存するバッチ処理
• フロントエンド
  • PV数をグラフにして表示する処理

使用技術

• Ruby on Rails
• Vue.js
• AWS EventBridge
• AWS StepFunctions
• Bigquery
• AWS S3

プロジェクトのチーム規模

• エンジニア1名
• PM1名
• テスト担当者 1人（PMが担当）

実装内容

仕様：各コミュニティの管理画面でトップページ（ / ）、概要ページ（/about）のPV数の変化のグラフを日毎、月毎に表示する

工夫した点

実装において以下のような課題がありました。

• 運営しているコミュニティは約130個あるため、膨大な量のページビュー（開いたページのパスや時刻やURL）がBigqueryに記録されていてそこから特定の期間のPV数をBigqueryからRailsで動いているサービスに読み込むと5〜10秒かかってしまう。

そこで以下のような方法で上記の問題を解決しました。

PV数を事前にキャッシュすることによってBigqueryからデータを取得したときの遅延を回避

解決策として、毎日午前0時に前日までのPV数をS3にキャッシュすることで解決しました。
定期実行にはEventBridgeとstepFunctionsを使用しました。
EventBridgeとstepFunctionsでECSコンテナを立ち上げRailsのrakeタスクの中で以下の処理を実行しました。

① Bigqueryにコミュニティ毎に、日毎、月毎にデータを集計するviewを作成
② 定期実行を行いRailsコンテナのrakeタスクからBigqueryのAPIを叩いて①のデータを取得
③ ②のデータをrubyのハッシュの状態でバイナリデータとしてS3にキャッシュする

グラフを表示するときは、RailsでS3からデータを取得してRubyのハッシュとしてデータを表示しました。
これによってコミュニティがオープンした日にちから、現在から1日前までの全ての日付のトップページと概要ページのPV数をグラフとして1秒以内に可視化できるようになりました。