🎉

初のプロダクトをApp Routerを使用してリリースした話

2023/12/23に公開

この記事はめぐろ LT Advent Calendar 2023の 23 日目です。

はじめに

みなさん、自分自身が実装したプロダクトが初めてリリースされた時のことを覚えていますでしょうか?

どうもけんやです。
かくいう私も先日エンジニアになってから初めて 1 から実装したプロダクトがリリースされたので、その振り返りをこの記事で書いてみようと思います。

アプリケーション構成

私の初プロダクトは何を隠そう、Next.js の App Router を使用したプロダクトとなっております(ドヤ 😤)

使用技術

  • TypeScript

  • Next.js

    という感じでメインの技術は構成されています。
    フロントエンドのメンバーは私と業務委託の方の合わせて2人で、チーム自体のレベルとして全然高くありません。
    プロダクト自体厳しい要件等もなかったので私が使い慣れていた Next.js を使用してアプリケーションを実装することにしました。(私が Remix に慣れていたら Remix になっていただろうし、なんなら Laravel の Blade や Vue に習熟していればそっちになっていた可能性が高いです笑)

ハイライト

プロダクト開発を振り返ってみて印象に残っていることを振り返ります。
大変勉強になった記事等も一緒に載せておきます(大感謝🙏)

  • RSC のつらみ

    ちょうどプロダクト開発に入ろうとした矢先、App Router が stable となりました。どうやらプロダクションで使えるらしいぞと聞いたので、App Router で作ってみることにしました。しかしRSCのテストがうまいことできなかったり、パラダイムシフトにより他の開発者がその概要を理解し難い部分があったりしたのを思い出します。
    ただ、テストや Storybook が徐々に RSC に対応し始めているようであるのでこの辺りもそれに伴いテストを厚くしたり、VRT を入れたりしてプロダクトの改善を行っていきたいです。

https://storybook.js.org/blog/storybook-react-server-components/
https://zenn.dev/uyas/articles/bc58a4bed15ed4
https://quramy.medium.com/react-server-component-のテストと-container-presentation-separation-7da455d66576

  • GitHub Actionsで色々整えた話

    プロダクト開発を通じて初めてちゃんとGitHub Actionsを書きました。社内ではGitHub Actionsについての知見はなかったのですが、テストやStorybookへのデプロイは絶対最初に自動化しておいた方がいいと思い簡単なCIを構築しました。プロダクションコードを書くだけではない貴重な経験ができたので個人的にはとても良かったなと思います。
    またVercelへのデプロイもGitHub Actionsを使用して行いました。ホスティング自体はVercelで行なっているので、pushすれば自動でビルドされるのですが有料プランですとseatのあるメンバーしかpushしてビルドすることができません。業務委託の方や他のメンバーがジョインしてきた時に毎回seatを追加していてはちりつもでコストも意外とバカにならないなと思いVercel CLIを使用してデプロイするようGitHub Actionsを書きました。

https://zenn.dev/ttskch/articles/691fb62fbb6b1b
https://zenn.dev/keitakn/articles/storybook-deploy-to-chromatic

  • monorepo 移行

    開発しているプロダクトがtoBのアプリケーションだったので管理画面とユーザー側の画面に分かれている一般的なアプリケーションだったのですが、それぞれを別ドメインでデプロイすることになり、急遽monorepoに移行しました。移行するまでは1つのNext.jsのプロジェクトのapp配下に管理者側ととユーザー側の両方の画面がある状態でした。
    Next.jsでmonorepoをやるって何がいいんだろう〜と考えていたところ、うっすら聞いたことのあるTurborepoというものに辿りつき「これならサクッとmonorepoを構築できそうじゃないか?」となり試してみました。結果としてかなり簡単にデプロイができ、運用も特に問題なさそうだったのでTurborepoを採用することにしました。正直monorepo移行への期間が十分にあったわけではないので、ベストとはいえないかもしれないですが現状の開発に特に不満はないです。

https://zenn.dev/burizae/articles/c811cae767965a
https://www.chromatic.com/docs/monorepos/
https://tech.asoview.co.jp/entry/2022/12/23/095914
https://zenn.dev/hayato94087/articles/d2956e662202a7

  • AIチャットボット実装

    GPTを使用したチャットボットも実装しました。笑
    リリース時点でのプロダクトからは無くなってしまった機能ですが、半日くらいでサクッと実装できたのでちょっとした息抜きに楽しかったです。

https://zenn.dev/rorisutarou/articles/6f21450ea34cc3

  • React Hook Form を使用したフォームの作成

    私自身初めて React Hook Form をこのプロダクトで使用しました。制御コンポーネント・非制御コンポーネントがなんなのかわからないところからの出発だったので、動的なフォームの作成だったり、型のエラーがかなり出たりで非常に苦戦しました。
    またドラッグ&ドロップもできるフォームや画像を切り抜いて保存するコンポーネントを実装したのも面白かったです。

https://zenn.dev/manalink_dev/articles/manalink-react-hook-form-v7
https://react-hook-form.com/docs/usefieldarray
https://zenn.dev/kyosuke_14/articles/e892bffc0357da
https://zenn.dev/wintyo/articles/d39841c63cc9c9

  • デザインシステムの構築

    私が開発したプロダクトから少しづつ自社のデザインシステムを作ることになりました。私はデザインシステムで重要なのがSSoT(Single Source of Truth)だと考えているので、いかにFigmaにコードが追従していくかが重要になると思いました。なのでできるだけデザイントークンをコードと同期させたり、コンポーネントは Storybook と紐付けて管理しています。現状このデザインシステムを使用しているのが私の開発したプロダクトのみなので、この管理が功を奏すかはわかりませんが、今後の開発が柔軟にデザインシステムの変更に同期できるようにベターな方法を選択していきたいです。

https://zenn.dev/mi_/articles/453f7594120c9a
https://zenn.dev/poteboy/articles/4739b882e22961

経験できてよかったこと

  • コードを書く以外の経験

    1 人でフロントエンドをドリブンするとなると先に述べたように GitHub Actions を使用した簡単な CI や ESLint/Prettier を使用した開発環境の構築はもちろん、デザイナーとの連携や PO とのコミュニケーションなども経験しました。普段与えられたチケット、指示を元に実装するだけの経験とは違い 1 からの開発は決まっていないことについての議論に参加したり、後のことを考えた開発環境を整えたりと途中からのジョインではできない経験だったなと思います。
    毎回経験できるわけではないので、これらの経験は非常に貴重でしっかり自分の中で反芻して自身の血肉にしたいです。

  • スケルトンレビューの経験

    React のコンポーネントをレビューするのにスケルトンレビューを取り入れてみました。これは簡単にいえばコードベースの実装の前に、設計段階でレビューするというものです。今までコンポーネント設計+実装でレビューを出していましたが、一度設計段階でレビューするようにしてみました。すると開発者・レビュワーともに設計フェーズと実装フェーズでそれぞれ別の観点に集中できたのでスケルトンレビューを採用してみて非常に良かったなと思います。ただ、レビュワーのコミットメントが少ないと開発スピードが落ちてしまうのでそこだけ今後改善していきたいです。

  • テストコードを書く経験

    テストコードをちゃんと書くのもこのプロダクトが初めてでした。
    言うても Unit Test を厚めに書いてるだけですが、それでも非常に良い経験だったなと思います。テストコードを書く時には仕様を表現しようと意識しておりました。テストコードを通して他の開発者が仕様をある程度キャッチアップできるようにすることで、テストケースの漏れを最小限にとどめることができると感じています。またそれによりコンポーネントの設計や実装段階で仕様の漏れなどにも気づくことができます。
    徐々にインテグレーションテストや E2E も増やしていきたいです。

https://zenn.dev/takepepe/articles/frontend-testing-book
https://peaks.cc/books/testing_with_jest

  • リリースまですること

    規模の小さい会社で 1 からの開発だとリリースまでたどり着けないことも珍しくはないのではないでしょうか?私自身個人開発でもリリースまできっちりできたことの方が少なかったですし、自分の手で実装したプロダクトがリリースされるのは非常に達成感があり、これからアップデートし続けることに胸が躍る想いです。これからは書き捨てのコードではなく他の開発者にみられても恥ずかしくないコードをかけるような力をつけていきたいです。

もっとやりたいこと

  • React の綺麗な設計を勉強したい

    開発している中で複雑なロジックを内包したコンポーネントが爆誕することも多くありました(今もある🤫)。やろうとは思いつつ hooks へ切り出すベストプラクティスやナレッジがなかったためにそのままの状態で放置されています。見通しの悪いコードをなるべく排除し、美しい React の設計ができるように根本の理解・勉強をしていきたいです。

  • フロントエンド/バックエンドという分け方ではなくて、機能まるごと開発したい

    最近やっとバックエンドの開発に携われるようになってきました。ちょっと前までは完全にフロントエンドとバックエンドが分離されており、それぞれに関心事が分離されてしまっていてプロダクト開発としてはあまり望ましくない状況でした。ですが最近は少しずつ改善の傾向にあり、プロダクトチームとしての開発ができるようになってきています。とはいえ今までに蓄積された暗黙知がありすぎるので、ペアプロやモブプロなどのチーム単位でのコミットを増やして経験・ナレッジの偏りをならしていきたいです。

  • 社内で TypeScript/React をかける人を増やしたい

    現状 TypeScript/React で満足にアプリケーション開発ができるエンジニアが社内にいません。多くはバックエンドエンジニアなので TypeScript/React をかけるエンジニアを増やすために私が積極的に勉強会を開催したり、ペアプロをしたいです。
    関係ないですが、ちょっと前に connpass でNext.js のワークショップをやったら社外の方もご参加いただき非常に楽しかったです。こういったコミュニティ内での活動も増やしていきたいです!

まとめ

経験の浅い私にフロントエンドの権限を委ねてくれた CTO に非常に感謝しています。
おかげさまでオレオレなアプリケーションが完成してしまいました。しかしこのプロダクト開発を通して学べたことはそれ以上のバリューとしてチーム・会社に還元できるよう私自身が貢献していくつもりです。笑
ボーイスカウトルールに則り少しずつ良いコードにしながら、今後もチームでプロダクトを作り上げていきたいです。最後までお読みいただきありがとうございました!

GitHubで編集を提案
株式会社EISHIN

Discussion