# 概要
https://nana-music.com から, リニューアル版 https://beta.nana-music.com/ の Web フロントエンドの技術選定, 設計から実装, 保守・運用をすべて一人で担当 (現在も, 機能追加, パフォーマンス改善, バグ修正など進行中).
# 既存コードとリニューアルデザインカンプから仕様を把握して技術選定・設計まで
これまでに経験したことのない最も大変なことであり, 前任者などが誰一人いなく, ドキュメントもなく, コードも断片的につぎはぎされたような状態 (リリースプロセスなどもなく, ほぼ放置状態) から, 仕様を把握して, 技術選定・設計をおこなうことでした. そのためには, 既存のコードをリーディングするには限界があり, リニューアルにあたっての MVP (Minimum Viable Product) を以下のように整理して (また, ビジネス的な理由上, 2023 年 10 月にローンチして, 2023 年 12 月末までにリニューアル版としてリリースする必要がありました), それを補完するために既存のコードや挙動をかいつまんで進めました.
- アカウント作成ができる
- ログインができる
- アカウント情報が編集できる
- ユーザーページが閲覧できる
- 検索やフィードなどコンテンツ回遊の導線ができる
- 動画・オーディオの視聴ができる
- オーディオファイルがアップロードできる
また, MVP を意識して, UX 的なことは削ぎ落としたり (例えば, 検索では当初の予定では, さらにフィルタリングができる想定), デザインに時間を要するところはデザイナーと相談して簡素な UI に変更してもらう (例えば, カルーセルは横スクロールにしてもらうなど) などしてこれ以上削ぎ落とせば, nana の Web アプリケーションとして成立しないぐらいの実装コストを減らして, 実質 2 ヶ月の実装時間 (残り 1 ヶ月は QA 項目の作成, QA プロセスの主導) で MVP を実装し, リリースすることができました.
# 技術選定
企業規模, また, 経営的にも人的リソースを確保できる状況ではないので,
- フレームワークやライブラリは充分に枯れているのを選定する
- 開発に関わる人が複数にならないと決められないようなこと (チームメンバーのスキルや経験) に依存しやすいことは避ける
上記の 2 点を意識しました. 具体的には, 既存の Web アプリケーションは Vue.js + Nuxt で実装されていましたが, 現状の Web フロントエンドの技術動向から React + Next.js の方がより枯れていると判断して, 既存資産は使うことをせずゼロベースで実装したり, API スキーマからの型生成もあくまで型定義のみを生成する薄いツール ([openapi-typescript](https://github.com/drwpow/openapi-typescript)) を選定したり (クライアントコードまで生成すると生産性は向上するが, 将来ジョインするメンバーのスキルや経験によっては逆効果になりうるので), ツールで制約できないコーディング規約は作らないといったことです.
# そのほか
技術的理想に対して, 教条的になりすぎず, 後回しでよいことやあればよいぐらいのことはやらないようにしました.
- Storybook は導入し, コンポーネントの Story ファイルは担保しても, VRT まではしない
- そもそもセルフレビューの状態なので VRT の意味がそこまでない. Story ファイルさえあれば, Chromatic などを導入すればいつでもできる
- pre commit フックは使わず, CI でフォーマットや型検査を担保する
- commit 待ちの時間がもったいない
- API スキーマファイルの更新は手動 (Swagger から定義ファイルのみコピーして `openapi-typescript` で生成する)
- 将来的にはパッケージ化するなどして自動化したいが, 現状, バックエンドも人的リソースが少なく, 頻繁に API の更新があるわけではない. また, アプリで使われている API がほとんどのため, 新規に追加されるスキーマもほとんどないので.