自己紹介
こんにちは！ゲーム開発ゼミに所属している3回生のtomaです。
PlayGroundではゲーム開発ゼミや岡山オフィスの運営をしています。
岡山オフィスではオフィスを利用する人が年々減っていき、PlayGroundメンバー内での交流が少なくなっていました。「そんな現状を変えたい！」という思いで以下のようなアプリを作成しました！
以下が私が作成したアプリのリンクです。
・モバイルアプリ
・Webアプリ
| モバイル | Web |
|---|---|
 |
 |
以下はGitHubリポジトリのリンクです。
・Webアプリのリポジトリ
・モバイルアプリのリポジトリ
・APIクライアントリポジトリ
当初は小規模なWebアプリでしたが、実際に使われる中で要件が増え、設計や技術選定も大きく変化してきました。
この記事では、「プロダクトの成長に伴って、どのように技術的判断を変えてきたか」を時系列で振り返ります。
フェーズ1：まずは全体像を固める
技術選定・アーキテクチャ・サービス概要
最初にやったのは、実装ではなく設計でした。
- どんな課題を解決したいのか
- 誰が、どの頻度でどのように使うのか
- 技術スタックの選定
- アーキテクチャの大枠
- MVPとして何が必要か
を重点的に検討しました。
このフェーズではプロダクトの方向性を決めることを意識しました。
フェーズ2：MVPをデプロイし、何人かに使ってもらう
プロダクトの必要性を確認
実際にMVPを使ってもらうことで、今後このプロダクトをグロースさせるべきか確認することができました。
そして数人ではありますが、このプロダクトを必要としてくれるユーザーがいたり、オフィスの利用率が向上したので、このプロダクトに価値があることが確認できました。
しかし、ユーザーの声を何でもかんでも取り入れてプロダクトの方向性が分からなくなってしまった時がありました。
その時にフェーズ1に戻ってどんな課題を解決するためのプロダクトなのかというものを再確認し、必要のない機能を削除したりして、一貫性のあるアプリにすることができました。
このフェーズで学んだのは、
プロダクトの必要性の確認は早ければ早い方が良い
ということです。
フェーズ3：UX向上に本気で向き合う
エッジケース対応・楽観的UI・最適化
このフェーズになるとUXの粗さが目立つようになりました。
対応したこと：
- 通信失敗・二重操作などのエッジケース対応
- 楽観的UIによる操作感の改善
- 無駄な再レンダリングやAPI通信の最適化
そしてさまざまな「機能追加」
しかし、ユーザーの声を何でもかんでも取り入れて
プロダクトの方向性が分からなくなってしまった時がありました。
その時にフェーズ1に戻ってどんな課題を解決するためのプロダクトなのかというものを再確認し、必要のない機能を削除したりして、一貫性のあるアプリにすることができました。
このフェーズで学んだのは、
「ユーザーの意見」と「プロダクトの方向性」とのバランスが大切
ということでした。
フェーズ4：グロースを見据えた品質担保
テストコードとCI自動化
機能を追加するたびに、意図しない形で他の機能に影響が出てしまうことがありました。
Gitでバージョン管理はしているものの、別の機能を追加して push した後に、
「いつの間にか別の機能が壊れている」という状況が発生していました。
ここから、新しい機能を追加した際に、既存機能に影響がないことを継続的に確認する重要性を強く感じるようになりました。
しかし、機能が増えるにつれて手動確認だけでは限界があるとも感じました。
このプロダクトを継続的に育てていくと決めたタイミングでもあったため、以下の対応を行いました。
- テストコードの整備
- CI/CDによる自動チェックとデプロイの仕組み構築
これにより、
- 安心して機能改善やリファクタリングができる
- 開発スピードを落とさずに変更を重ねられる
といった、グロースを前提とした開発環境を整えることができました。
フェーズ5：利用範囲の拡大に耐える設計へ
東京オフィス対応とテーブル拡張
「東京オフィスでも使いたい」という声が上がり、単一オフィス前提の設計が限界を迎えました。
これは初期の設計段階では想定していなかった要件であり、
破壊的な変更や、数人規模から数十人規模の利用に耐えられる設計が必要になりました。
場合によっては、
- 使用しているサービスの見直し
- データ構造の大幅な変更
も必要になる状況でした。
それでも、東京オフィスのメンバーにも使ってもらうことで、このプロダクトの価値はさらに高まると確信し、対応することにしました。
対応した内容は以下です。
- オフィス概念の導入
- テーブル構造の拡張
- 既存データとの互換性を維持したマイグレーション
- 人数拡大に耐えられるストレージサービスへの変更
これらの対応を通して強く感じたのは、
プロダクトは完成させるものではなく、成長させ続けるもの
ということでした。
フェーズ6：アプリ化を見据えたAPI設計
OpenAPIベースのSDK運用
Webアプリとしては MVPの段階を超え、
実運用に耐えうるレベルまで改善できたため、
次のステップとして ネイティブアプリ（MMP）への展開 を考え始めました。
Webとモバイルを並行して開発していくことを見据えると、
クライアントごとにAPI実装を持つのは、仕様のズレや実装コスト増加の原因になります。
そこで、
- APIをOpenAPIで定義
- Web・モバイル共通で利用できるSDKを生成・運用
という形に切り替えました。この変更により、
- クライアント間での仕様ブレ防止
- API仕様を起点とした開発フローの確立
- 実装スピードの向上
といったメリットを得ることができました。
フェーズ7：ネイティブアプリの作成
バックエンド側は、フェーズ6で整備した OpenAPIベースのSDK をそのまま利用しました。
一方で、クライアントサイドについては、あえてネイティブ専用の実装を選択しました。
WebとネイティブでUIを共通化する選択肢も検討しましたが、
- 操作感
- 画面遷移
- OS標準のUIコンポーネント
などを考えると、Webとネイティブでは求められるUI/UXが大きく異なると判断しました。
そのため、UIは共通化せず、ネイティブアプリとして最適な体験を前提に一から設計・実装しました。
結果として、
- ネイティブらしい操作感を実現できた
- 不要な抽象化を避けられた
- 高品質なアプリを短期間で開発できた
という成果につながりました。
フェーズ8：App Storeにリリース 🎉
ネイティブアプリとして完成したため、App Storeへリリースしました。
今回は一般公開ではなく、Unlisted App としてのリリースです。
Unlisted Appは、
- App Storeの検索結果には表示されない
- 専用リンクを知っている人のみがインストール可能
という配布形式のため、社内利用や限定ユーザー向けの配布に適しています。
おわりに
これからもこのプロダクトをグロースさせ続けていきたいと考えています！
改善してほしいことがあれば是非tomaに連絡をお願いします！
最後まで読んでいただきありがとうございました！
