はじめに
合同会社HURM TECHの代表をしています、かいと@kaito_hurmtechと申します。
今回はZennのPublicationでTech Blogを開設したので、メインで取り組んでいる事業について書くことにしました。
メンバーの一人にはnoteで自己紹介記事を書いてもらったので、私は技術寄りの視点から、カードゲーマー向けマッチングアプリ「Shuffle Match」の開発について共有します。
Shuffle Match - カードゲーマー向けマッチングアプリとは
弊社が開発・運営している「Shuffle Match」は、カードゲーマーが対戦相手を見つけるためのマッチングアプリです。
主な機能：
- カードゲーマーに特化したプロフィールページ
- スワイプで自分と相性のよい相手とマッチング
- カードゲームなどでフィルタリングしてじっくり相手を探せるリストビュー
- マッチングした相手とのチャット機能
2025年6月にリリースし、iOS/Androidの両プラットフォームで展開しています。
なぜこのアプリを作ったのか
カードゲームは、コレクションだけでなく、対戦してこそ楽しいものです。
私と開発メンバーは学生時代からの友人ですが、学生の時は毎日のように友人と集まって遊んでいました。学校という場が自然に対戦相手を用意してくれていたからです。
しかし社会人になると状況は一変します。必ず集まるという場はなくなり、日中は仕事。土日も予定が合わなくなることが増えていきます。
そうなると新たなカードゲーム仲間を探す必要が出てきます。多くのカードゲーマーはSNSや掲示板、大会への参加、カードショップに足を運ぶことで対戦相手を探していると思いますが、それぞれにハードルがあります。
では最初から対戦相手を探す人が集まる場を作ればよいのではないか ― そう考えて、このアプリの開発を始めました。
実は最初は違うアプリを作ろうとしていた話
当初は飲食店関連のマッチングアプリを作ろうと動いていました。
仕様決めを行って仕様書まで作成し、技術的には実装可能でしたが、私たちの経験やリソースの観点から運営自体が難しいと判断し、断念することになりました。エンジニアリングの力だけでは解決できない課題があることを痛感した瞬間でした。
そこで、自分たちがよく知っている領域であるカードゲーム界隈へピボットすることを決めました。
技術スタックと選定理由
フロントエンド：Flutter
開発がスタートした2023年夏頃、FlutterとReact Nativeを比較検討した結果、Flutterを採用しました。
選定理由：
- 当時の勢いやシェアがFlutterの方が高かった
- 私自身がなにか新しいものをと、Flutterを学習し始めていたタイミングだった
今なら成熟したExpoを備えたReact Nativeも良い選択肢だと思いますが、当時の判断としては妥当だったと考えています。
バックエンド：Firebase + Google Cloud
バックエンドは以下の構成を採用しました：
Firebase
- Authentication（認証）
- Firestore（NoSQLデータベース）
- Hosting（静的ファイルホスティング）
- Storage (画像・ファイルストレージ)
- Cloud Messaging (通知)
- Remote Config (リモートでの設定変更)
- Cloud Fucntions (サーバーレス関数)
- App Check (不正アクセス防止)
Google Cloud
- Cloud Run（コンテナ実行環境）
- Cloud Load Balancing（負荷分散）
- Cloud Armor（WAF）
- Cloud SQL（PostgreSQL）
- Cloud Logging (ログ管理)
当初からFirestoreだけでは限界があると考え、リレーショナルデータベースとしてCloud SQLを併用する構成にしました。よく言われることですが、RDBのコストは確かに高いですね。
バックエンドの技術選定の変遷
バックエンドは初期段階で何度も作り直しています：
- Hasura（GraphQL BaaS） → 運用時の制限とコストの問題で断念
- MongoDB → データ構造が複雑になりPostgreSQLへ移行
- Django検討 → 過剰と判断しFastAPIを採用
- GraphQL採用 → アンダーフェッチ・オーバーフェッチの解決、単一エンドポイントでの運用を実現
- Strawberry（GraphQLフレームワーク） → FastAPIとの相性を考慮
- SQLModel + SQLAlchemy → ORMとして採用
開発で詰まったこと3選
1. Firebaseメールリンク認証の罠
パスワードレス化のためFirebaseのメールリンク認証を採用しましたが、Firebase Dynamic Linksが廃止予定という問題に直面しました。
公式の移行手順に従いHostingを利用する方法に移行しましたが、iOSのUniversal Linkの仕様にぶつかり、最終的にはカスタムスキームで対応することになりました。
しかしもっといい方法が見つかったので、改善予定です。（詳細は別記事で共有予定）
2. Apple審査でのリジェクト
iOS版のリリースがAndroid版に遅れた原因は、何度かのリジェクトでした。主な理由は凡ミスでしたが、良い学習機会になりました：
リジェクト理由1：誕生日取得
- アプリの年齢制限のため必要である旨を説明し承認
リジェクト理由2：WAF設定
- JP以外のリージョンをブロックしていたため、審査地域からアクセスできない状態だった
- 正直、恥ずかしいミスでした
3. プロジェクトマネジメントの課題
技術的な課題以外にも、少人数ですがプロジェクト管理には苦労しました。特にJIRAを使ったタスク管理に慣れていないメンバーがいたため、初期は進捗管理が難しい状況でした。
私自身、現時点でまだ社会人5年目ですから、PMなんかしたことはありませんし、何もかもが初めての経験となりました。(そもそも起業も初めてです)
メンバー全員が当初から兼業だったこともあり、時間の捻出が大変だったと思います。しかしここまで時間がかかってしまったのは大きな反省点です。今同じことを始めればここまで時間がかからないと思いますが、これも経験があってこそだと考えます。
うまくいったこと・工夫したこと
少人数でもなんとかリリースできた理由
少人数チームでリリースまで辿り着けた要因：
- 時間を味方につけた - 焦らず着実に開発を進めた
- 絶対にリリースするという意気込み - メンバー全員の強い意志
- AIの活用 - 特にここ1年でAIツールが大幅に進化し、開発効率が向上
当初は全て自分で実装していましたが、AIを活用することで開発速度が大幅に改善されました。
とはいえ本当は4月リリースの予定だったのですが、リスケにリスケを重ねてなんとかリリースにこぎつけたのが正直なところです。
プロジェクト管理の工夫
- タスク管理：JIRAのカンバンボードを活用
- コミュニケーション：Discordでの日常的なやり取り
- 定期ミーティング：週1回の進捗確認と課題共有
最近ではメンバーもJIRAの使い方に慣れ、効率的なタスク管理ができるようになってきました。
人数が少ない時はリーダーが突っつくのも良いと思います。必ずしも最初から全員が自律的に動けるとは限りませんからね。
今後の展望
実装予定の機能
カードゲーマーがより楽しめる機能を追加していく予定です：
- 招待機能の実装
- プロフィールのカスタマイズ拡充
- 大会開催機能
- その他、ユーザーフィードバックを基にした機能追加
ロードマップは随時更新し、今後の記事でも進捗を共有していきたいと思います。
技術的な改善点
現状の課題と改善計画：
-
ドキュメント整備
- 現在は一部ドキュメント化されているものの、古かったり、私の頭の中に仕様が入っている状態
- AIフレンドリーなドキュメント作成が急務
-
リファクタリング
- 他のメンバーがメンテナンスしやすいコードへ
- スケーラビリティを考慮した設計へ
-
パフォーマンス最適化
- 現在のユーザー規模では問題ないが、将来を見据えた改善
-
モデレーションの自動化
- リリース初期段階においては工数の問題から省いて、手動でモデレーションできるように管理コンソールで実装を行いました。
- 現在のユーザー規模ではまだ手動モデレーションで問題ありませんが、段階的に移行していく計画を立てます。
おわりに
最後まで読んでいただきありがとうございました。
このアプリを通して、カードゲーマーの皆さんがより楽しいカードゲームライフを送れることを願っています。
今後もHURM TECHでは新規事業に取り組んでいきますので、技術的な知見を含めて発信していければと思います。
ShuffleMatch - カードゲーマー向けマッチングアプリ
ぜひ一度お試しください。フィードバックもお待ちしております！
Discussion