toCアプリ開発を１年やってみて学んだ知見まとめ
業務委託案件にて約１年間（実際には10ヶ月）toC向けアプリ開発を経験しました。
toC向け（一般ユーザー向け）アプリ開発は初めての経験でしたので、そこで感じた（学んだ）内容を退職を機会にアウトプットしてみようと思います。
どんなアプリを開発してた？
ライブ配信アプリを開発していました。
有名なライブ配信アプリでいうと、17LIVE (イチナナ) 、LINELIVE、Pococha（ポコチャ）があります。
そこまでの最大手とはいきませんが、DAU（Daily Active User）が１万人ほどの中規模ライブ配信アプリを開発していました。
技術スタックはどんな感じ？
クライアントサイド：Unity
バックエンド:Rails
クラウドインフラ: GCP, K8s,Firebase
音声配信: Agora
AWSではなくGCPを選択した理由はシンプルに料金体系がAWSより安かったからです。
自分はバックエンドのRailsでAPI開発（DB設計、API設計、テスト、バグ改修）をメインに担当していました。
toC向アプリ開発して楽しかったことは？
toC向けアプリ開発を経験して楽しかった（身になった）ことをまとめます。
1. ユーザーのリアクションがダイレクトに見える
toCアプリの最大の醍醐味は本番リリースした後にすぐにユーザーのリアクションが見えることだと思います。
自分はTwitterなどで自分が担当した機能がリリースされる度に必ずユーザーリアクションを確認していました。
実際にユーザーが面白いなどの感想をTwitterで書き込んでくれることがあるので、それはすごくやりがいを感じることができました。
無論、ネガティブな感想などもあるのですが、それはそれで勉強になるので良い経験になりました。
2. 開発スピードが速く、エンジニアとして成長できる
次々に生まれるライバルアプリに対抗するためには、新機能を開発してユーザーを飽きさせないようにするフローを高速で回すことが大事です。
そのため開発で一番大事になるのはスピードです。新機能をスピーディーにリリースする必要があります。
その上で保守性やパフォーマンスを意識して開発する必要があります。
エンジニアとしてはきつい環境ではあるのですが、その分成長するスピードが速いです。
スピーディーに開発する貴重な経験を積めました。
3. 友達に自慢できる
toC向けアプリ開発をしていると友達に自慢できるのもメリットの一つかもしれません。（あまり自慢しすぎると嫌われるかもですが笑）
自分の開発しているアプリを利用している友人がいるときに、このアプリ自分が開発したんだよ〜と伝えると、結構の割合ですげ〜と言ってくれます笑
toC向けアプリ開発して辛かったことは？
逆にtoC向けアプリを開発して辛かったこともあるので記載します。
1. 大規模アクセスを見越してパフォーマンス意識してコード書く必要がある
toB向けアプリや社内向けアプリだと、ユーザー数が多くても1000未満のケースが多いですが、toC向けアプリだとユーザー数が数万人になるケースが多いです。
例えばアクセスが少ないアプリだと最悪N+1が発生していてもアクセスが少ないので最悪スルーしても問題にならないケースが多いです。（本当は良くないけどね....)
しかし大規模アクセスになってくると、一つのAPIに数万アクセスされるケースがあります。
そんな状況でN+1が発生している、もしくはクエリ発行回数を意識しないで書かれたパフォーマンスが低いコードを書いてしまうとユーザー体験を著しく落としてしまいます。
とりあえず動けばいいかで書かれたコードではなく、パフォーマンスを意識したコードを書かなければならないのは結構負荷が高いです。
2. バグ出した時が辛い
toCアプリでユーザー数が増えてくると、バグを出した時辛いです。
ユーザー数が多いので、バグでアプリ落としてしまうと多くのユーザーに迷惑をかかってしまうのでバグに常に最新の注意が必要です。
バグを出さないためにも、バグ検知ツールを導入したりQAテストを本番リリース前に行う必要があります。
3. 開発しているアプリのファンになる必要がある
これは盲点だったのですが、toC向けアプリを開発する上で自分の開発しているアプリのコアユーザーになる必要があります。
なぜなら、自分の開発しているアプリのファンにならなければ開発モチベーションを保つのがしんどいからです。
このアプリをもっと多くの人に届けたいという気持ちがtoCアプリ開発では大事になります。
実際に自分の開発していた会社のエンジニアの多くは仕事外でもアプリを趣味で利用していました。
4. アクセス負荷分散が大変
ライブ配信のようなtoCアプリでは負荷分散システムの構築が重要になります。
例えばライブ配信アプリのようなエンタメ系のアプリでは、何かのバズが起きた時に急に普段の数倍のアクセス発生するケースがよくあります。
大量アクセスがあったので、アプリ落ちましたすいません！ではユーザーが激怒するのでインフラアークテチャ設計をミスると取り返しがつかないことになります。
私たちの会社ではアクセス負荷システム（オートスケール）にk8sを利用して、アクセスに応じてコンテナオーケストラレーションシステムでコンテナ管理を負荷に応じて自動化できるようなシステムを採用していました。
ユーザーが爆増した時にもスムーズにオートスケール出来るようなアークテクチャシステムを設計を考えるのが大事になります。
まとめ
今までのお仕事ではtoB向けアプリや社内ツールアプリの開発が多かったのですが、toCアプリ開発を通して多くのことを学ぶことが出来ました。
ただ、toCアプリ開発する上ではそのアプリのファンにならなければ開発モチベーションを保つのがしんどいなと感じました。