リアルタイムSNS「ブラックキャット・カーニバル」を支える技術

新しいプロダクトを立ち上げるとき、企画側から見るとやりたいことがあるが技術的にどこまでできるのかがわからない、技術側からみると何を支援すればよいのかわからない、ということはありませんか？

ブラックキャット・カーニバル（以下、ブラキャニ）はiOS/Androidで動作するSNSアプリです。デザインにおいては外部の方にご協力をいただいていますが、基本的に私1人で企画から開発まで全てを担っています。

私はこれまでtoCプロダクトをゼロから開発した経験は多く、iOS・Android・バックエンドの開発も高いレベルで対応可能です。やれることの見極めや、やる場合の実装コストや運用コストのざっくり見積もりを高速に行えます。

このような状態ですから、ブラキャニは擬似的に1チームが「企画」と「技術」を行き来しながら理想的なすり合わせを行えたらどうなるのか？の参考事例と見なすことができるでしょう。

本稿ではチームとして一丸となって挑むと、どのようなことが効果が得られるか？の知見を提供できるよう、ブラキャニのそれぞれの仕様が決まった経緯や、技術面での検討をどのように行ったのかをご紹介します。

• keyboard_arrow_down 再現したかったTwitter時代の「息づかい」
• keyboard_arrow_down 最初の一歩は技術ではなく、動くプロトタイプ
• keyboard_arrow_down リアルタイムを実現するためのアーキテクチャ選定
• keyboard_arrow_down 開発効率を追求したフレームワーク選定
• keyboard_arrow_down クライアント実装中も市場の意見を取り込んでブラッシュアップ
• keyboard_arrow_down 挑戦の先に実現したリリース
• keyboard_arrow_down まとめ

ブラキャニはSNSに対する不満から、自分であればこうつくるのに！と考えた結果、結果生まれたプロダクトです。

ここを出発点として、順を追っていきます。

▲プロトタイプの画面

システムの設計に取りかかるには、仕様を概ね決める必要があります。また経験上、図を並べるのではなく、実機で操作できると検討が非常に進みます。よって最初に行ったのはFigmaのプロトタイピング機能をつかって隅から隅まで画面を作成してみることでした。

プロトタイプ作成コツは妥協せずに全遷移を網羅することです。これを怠ると、後から手痛い見落としが発生し苦労する場合があります。

これをベースにデザインの検討を重ね、ブラッシュアップをしていきました。

画面上部がオーナーの投稿 / 画面下部がそれに対するコメントやリアクションです。フォローの概念は無い / ショート動画のようにオススメをスワイプで巡回するのが基本 / リアルタイムが基本、などは最初から決まっていましたが、ルームのレイアウトは現行とはかなり異なっていますね。

出発点が“他人の息づかいを感じたい”であるブラキャニにとって投稿やコメント、絵文字によるリアクションがリアルタイムであることは重要です。しかしリアルタイム処理は難易度が高く、コストも高くなりがちです。ネットゲームを除いて普通はやりません。そのうえtoCプロダクトはいきなり跳ねることがあるのでスケーラビリティの確保も重要になってきます。やり遂げるのは難しいでしょう。

しかし、今回はユーザー体験の要となる以上、技術を駆使して乗り越える必要がありました。

最終的にはこのようにしました。

1. 1. CQRS/ESを採用し、Server-Sent EventsやRedis Pub/Subを使って隅から隅までイベントがストリームしていくアーキテクチャ
2. 2. マスターデータはDynamoDBにイベントとして保存、読み込み側は全部Redis(Replication構成)にして読み書き共に高速でスケーラビリティもあるとされるもので統一

CQRS/ESとは何か？に関しての説明は割愛いたしますが、注目してほしいのは読み込み側が基本的にRedisのみという非常にチャレンジングなことをしている点です。熟練の方であれば、このアーキテクチャに何が起こるかを想像できるはずで、実際にそれは発生します(した)。何が起こるかを想像できない場合は絶対にまねをしないでください。

しかし、理論上、この設計はかなりリアルタイムの処理を実現できますし、ブラキャニにおいてもパフォーマンスもスケーラビリティも良好であることが確認できています。

iOS開発 / Android開発 / ScalaやTypeScriptによるバックエンド開発と、3系統もつくっているとさすがに時間がかかりすぎてしまいます。よってiOS/Android開発はマルチプラットフォームフレームワークの採用が現実的でした。

しかしながら、マルチプラットフォームフレームワークにはプラットフォーマーの仕様変更という地殻変動に追従しつづけなければならない宿命があり、長期間の安定が望みにくい分野です。

人材確保・育成の観点も含め、個人的にはマルチプラットフォームフレームワークには否定的です。しかしAndroidの標準UIフレームワークのComposeをiOSやデスクトップでも使えるようにしたCompose Multiplatformが登場しました。

Compose MultiplatformはAndroid部分はそのままAndroid向け実装そのものなので、万が一Compose Multiplatformが放棄されてもAndroid資産はそのまま残ります。

ならばよしとし、Compose Multiplatformを採用しました。

クライアントの実装に入ってもブラッシュアップは続けます。実際に実装しながら改善した部分をいくつかご紹介します。

• タブバーを透過にしてみたら開放感があってよかったが、画面下がさみしくなった
  → 誰かがルームにきたらねこちゃんがにゅっとでてくるアニメーションを入れてみよう！

• ローディング処理は普通のくるくるを出すと味気ない
  → ねこちゃんアニメーションつくっていれよう！ (LottieのCompose実装である alexzhirkevich/compottie を使いました)

• 工数削減のためにできるだけMaterial Iconを使っているけど、自分のルームのアイコンはかわいくしたいな…
  → マイルーム=自室=段ボールだ！ねこちゃんが段ボールにはいってるアイコンにしよう

戦略やプロダクト性質によりますが、効率的な開発・改善のためにプロダクトは早めにお披露目して市場の感触を確かめておくとお得です。

ブラキャニはCompose Multiplatformを採用したことにより、Wasmで動作させることができました。かつ実装的には外部との通信は全てダミー実装を差し込める設計にしてあるためバックエンド無しでもブラウザで動作デモを行うことができました。

手応えを確かめるために2024月5月10日にChromeのみで動作する「ブラックキャット・カーニバル・シミュレーター」を公開しフィードバックを募り、好感触の意見がもらえたため開発を継続。

2024年12月上旬には招待制でアプリを試してもらえる機構(TestFlight/ Google Play早期アクセスアプリ)を利用しフィードバックを集め、最新の投稿にしか返答できない制限をゆるめ、ほぼ現在のブラキャニの仕様に落ち着きました。

このように全てできてからリリースするのではなく、刻んでお披露目できるような開発計画を立てるとよいでしょう。

そして2024年12月20日に正式リリースを行いました。

2025年8月27日の段階でAppStore 4.8、Google Play 4.7の高評価をいただいています。おそらく年内には1万人を超えられるし、その後もどんどん成長していけるのではないか？と考えています。このまま企画面でも技術面でも全力を尽くして楽しさを増していきたいと考えています。

企画面で実現したいことに芯を持ち、こだわっていくことは大事だと思います。

それを鑑み、技術面で最大限サポートしていくことも大事だと思います。

しかし「企画側がこだわっていく / 技術者がサポートしていく」、という体制ではなく、企画者と技術者が互いの専門性を持ち寄り、多方面から良くしていくという姿勢が何よりも大事なのではないか？と感じています。

ブラキャニは私が1人で企画と開発を担ったことで、技術的な制約により企画のアイデアを阻害せず、かつ実装可能なソリューションを選択することができました。特に、ユーザー体験の核となるパフォーマンスやスケーラビリティの部分を重視してアーキテクチャを選定したことは、将来的に開発コストを抑えることにもつながると考えています。

チーム開発ですり合わせの際に発生するコミュニケーションコストがなかったことも、私が「企画」と「開発」をスムーズに行き来できた大きな要因です。

企画のために技術がありますし、技術があれば企画をより楽しくすることもできます。がんばっていきましょう。