おじこむアプリ開発秘話

管理サイト主担当

社内で『おじさんと小娘』とつながりのあるメンバーがPMとして企画を立ち上げたのが始まりです。田村さんやPMが先に動いていて、私はプロジェクトの途中からチームに加わりました。

アプリ主担当

私はプロジェクトが本格稼働した段階から参加させていただいて、まずアプリの画面遷移図を作るところから始めました。どういう画面が必要で、どう遷移するかを整理して、アプリの全体像を設計したんです。

管理サイト主担当

私が加わってからは、田村さんの画面遷移図をベースにFlutterでアーキテクチャや認証基盤の土台を作りました。その後PMが『おじさんと小娘』からいただいた素材をもとにレイアウトを整えてくれて、そこから田村さんが機能実装をメインで進めてくれる体制になっていきました。

アプリ主担当

土台とレイアウトが揃った状態で機能実装に入れたのは大きかったですね。管理サイトの方はどう進めていったんですか？

管理サイト主担当

管理サイトの方は、尾形さんが画面設計で必要な画面を洗い出してくれていたので、それをベースに動くプロトタイプを自分で作るところから始めて、一通り動くようになった段階でチームのリポジトリに組み込み、PRベースの開発体制に移行しました。

アプリ主担当

アプリは「iOSとAndroidの両方をひとつのコードベースで開発できる」という観点からFlutterに決まりました。触れたことのない言語だったので、学習目的という側面も大きかったです。

管理サイト主担当

その上で状態管理にRiverpod、ナビゲーションにGoRouterを組み合わせて、Flutter公式推奨に近い構成で土台を整えました。

アプリ主担当

Flutter のおかげで Android と iOS の差異をほとんど意識せずに開発できました。UI もロジックも共通化できたことで、両プラットフォームで同じ品質を維持できたのは大きかったです。管理サイトの方はどんな技術構成にしたんですか？

管理サイト主担当

管理サイトはNext.jsとCloudflare Workersの構成です。以前別のプロジェクトでCloudflareを使ったことがあって馴染みがあったのと、画像アップロード用のストレージを検討したときに、FirebaseのストレージよりもCloudflare R2の方がシンプルに扱えそうだったんです。R2を使うならホスティングも同じCloudflareで統一した方がスムーズだろうと考えて、Workersを選びました。

アプリ主担当

R2を起点にホスティングまでCloudflareで揃えた流れは合理的ですよね。データベースの方はどう決めたんですか？

管理サイト主担当

データベースはFirestoreを選んだんですが、管理サイト側でCloudflareを使う関係で、CloudFlare D1も候補に挙がっていたんです。エンジニアとしては慣れ親しんだRDBのD1も魅力的でしたが、Firestoreの方がカラム追加などの柔軟性が高くて、アプリ開発に適した特性があった。せっかくなら新しい技術にチャレンジしようという判断もあって、Firestoreに決めました。

アプリ主担当

その選択は正解でしたね。リアルタイムリスナーを使っているので、管理サイトでデータを更新するとアプリ側にほぼ即座に反映される。このリアルタイム性はFirestoreならではの強みでした。

アプリ主担当

私はFlutterアプリ側の機能実装をメインで担当しました。当初はライブ予約機能・イベント参加意向登録機能のみだったのですが、スタンプカード機能やQRスキャン機能、お知らせ表示機能・静的ページの作成なども任せてもらいました。アプリ側だけでなく、Google Play Console の設定も担当し、色々なことに積極的に携わらせてくれる環境でしたね。

管理サイト主担当

私もかなり自由にやらせてもらいました。管理サイトは設計からデプロイまで一気通貫で任せてもらって、機能単位でいうと、会員情報管理、イベント管理、予約管理、お知らせ管理、スタンプマスタ管理と、管理に必要な機能をひと通り。加えてR2 Storageでの画像アップロードやCSVエクスポート機能、開発環境と本番環境の構築も自分の判断で進めました。

アプリ主担当

杉山さんはアプリ側の基盤構築もやってくれていて。Riverpodベースのアーキテクチャ設計、Googleサインイン・Appleサインインの認証基盤、iOSのビルドエラー修正など、土台の部分をしっかり作ってくれたおかげで、私は機能実装に集中できました。

管理サイト主担当

アプリの土台は私が作りましたが、その上でユーザーが実際に使う機能をどんどん形にしてくれたのは田村さんです。特にスタンプカード機能やQRスキャンはアプリの目玉機能なので、それを全部実装してくれたのは大きかったですね。

アプリ主担当

一番苦労したのはFirebaseの移行対応ですね。開発途中でFirebaseの設定を変更する必要があって、アプリ全体に影響が出るような大きな変更でした。あとはiOSとAndroidの設定差分、例えばアプリアイコンの設定やアプリ名の表示、環境ごとの切り替え処理など、細かいけど地味に時間がかかる作業が多かったです。

管理サイト主担当

アプリ側ではiOSのビルドエラーに相当悩まされました。mobile_scannerやGoogle Mapsのライブラリがバージョン競合を起こしていて、ライブラリの最新化とPodfileの調整を一つずつ試しながら解決していく地道な作業でした。

アプリ主担当

管理サイト側はどうでしたか？

管理サイト主担当

管理サイトはCloudflare Workers上にNext.jsアプリを構築する構成にしたんですが、デプロイ周りのハマりポイントがいくつかありました。あとはFirestoreのセキュリティルールとの兼ね合いで、管理者権限のアクセス制御をしっかり組む必要があって。開発環境と本番環境を用意して、安全にテストできる体制を整えるのにも時間をかけました。

アプリ主担当

App Storeの審査でアカウント削除機能が必須になっていて、その対応も意外と手間がかかりましたね。退会フローを作るだけでなく、関連データの整理や確認画面の設計もきちんとやる必要があって。審査基準に合わせた対応は独特の難しさがありました。

管理サイト主担当

iOSのビルド周りでは黒田さんにも実機確認を手伝ってもらいましたね。Xcodeの環境依存で再現する問題もあったので、別の環境で検証してもらえたのは心強かったです。

アプリ主担当

印象に残っているのは、QR コードのスキャン機能ですね。スタンプを押すときのワクワク感を、デジタルでもどう再現するかはかなり悩みました。スキャン直後にあえて黒塗りのスタンプ画像を表示することで、「何がもらえるんだろう」という余白が生まれ、ちょっとしたドキドキ感につながったのではと思っています。ファンの皆さんに少しでも楽しんでいただけていたら嬉しいです。

管理サイト主担当

管理サイトでは、ITに詳しくない運営メンバーでも迷わず使えることを最優先にしました。ダッシュボードを開けば総ユーザー数、イベント数、予約数、お知らせ数がすぐわかる。イベントの登録・編集もシンプルなフォームで完結するようにしています。

アプリ主担当

Google SignInとApple Sign Inの両方に対応したのも大事なポイントでした。面倒な会員登録なしですぐ使い始められるので、ライブ会場でも気軽にインストールしてもらえます。

管理サイト主担当

管理サイトにはR2 Storageでの画像アップロード機能を組み込んでいるんですが、カスタムドメインの構成や画像削除時の挙動など、想定外のハマりポイントがいくつかありました。地道に一つずつ潰していって、最終的には管理者がフライヤー画像やアーティスト写真を登録するとそのままアプリに反映される、という直感的な仕組みにできました。

アプリ主担当

会員証の表示まわりは池田さんが担当されました。マイページで会員証を見せる場面を想定したデザイン調整をしてくださいました。私の方で一部レイアウト修正をした際も確認を一緒にやってくれて。細かいところですが、ユーザーが実際に使う場面を想像しながら作れたのは良かったです。

管理サイト主担当

管理サイトのUIで特に意識したのは一覧性の高さですね。スマホアプリとは設計の考え方がまったく違っていて、管理者が必要な情報をいかに1画面で把握できるかがポイントでした。あとCSVエクスポート機能は当初の要件にはなかったんですが、運営者の立場で考えるとデータの出力機能は必要になるだろうと思って自主的に追加しました。リリース後に喜んでもらえたので、先回りして用意しておいて良かったですね。

管理サイト主担当

基本的にFirestoreを共通のデータベースとして使っているので、データ設計さえ揃えておけばアプリと管理サイトは独立して進められました。管理サイトでイベントを登録すればFirestoreに入り、アプリ側はそれを読み取って表示する。このシンプルな構造が結果的にうまく回りましたね。

アプリ主担当

PR（プルリクエスト）のマージ管理もきちんと回っていましたね。アプリ側はPMがメインでマージを担当してくれて、私もいくつか対応しました。管理サイト側も私がマージを担当する場面がありました。一人で実装して一人でマージする状態にならなかったのは、品質の面でよかったと思います。

管理サイト主担当

管理サイト側ではCloudflareのプレビュー機能を活用して、修正が本番環境に適用される前にチームメンバーに確認してもらうフローを整えていました。あとはGoogle Chatで日常的にやりとりしていたので、誰かが困っていたらすぐに声を掛け合えて。チーム一丸となって前に進んでいる感覚がありましたね。

管理サイト主担当

開発中は尾形さんと池田さんにもテストに入ってもらっていました。自分たちだけだと見落としがちな操作の不具合やデータの表示ズレを、開発と並行してこまめに拾ってもらえたのは助かりましたね。

アプリ主担当

開発している本人は「動くはず」という前提で触ってしまうので、別の目で確認してもらえる体制があったのは大きかったです。

管理サイト主担当

リリース前の最終テストでは田村さんがおじこむプロジェクトとは別の部署のメンバーにも声をかけてくれて、実際にアプリを触ってフィードバックをもらう場を作ってくれたんです。開発している側はどうしても『動くかどうか』に意識が寄りがちなので、ユーザー目線でのフィードバックは本当に助かりました。

アプリ主担当

プロジェクトに関わっていない人の目で見てもらえたのは本当にありがたかったですね。自分たちだけだと気づかない操作感の違和感とか、文言のわかりにくさとかを拾ってもらえて。あの工程がなかったらリリース後にもっと修正が増えていたと思います。

アプリ主担当

スマホアプリのリリースは今回が初めてだったので、知見のない領域を手探りで進む日々でした。最後までハラハラする場面も多かったのですが、iOS も Android も無事に公開できて、ようやく肩の力が抜けた気がします。ここまでたどり着けたのは、チーム全体の粘り強い取り組みのおかげだと感じています。

管理サイト主担当

管理サイトも無事にリリースできました。ゼロからのスタートだったので、アーキテクチャの選定から環境構築、全機能の設計と実装、テスト環境の整備まで、全体を見渡せる立場でやらせてもらえたのは良い経験でしたね。また、プロジェクトに携わってくださったチームメンバーの方の協力あってこそのリリースだったと思います。あらためて皆様ありがとうございました。

アプリ主担当

初めてのスマホアプリ開発でしたが、実際のプロジェクトに関われたことは大きな経験になりました。ここで得た知見を、今後の開発にも生かしていきたいと思います。

管理サイト主担当

アプリ開発はユーザの方からすると何をやっているのか分からないところも多いと思います。そういった意味でもこういった記事を通して開発者が普段どういったことを考えてアプリを作っているかを少しでもお伝えできていれば幸いです。