ID:77380さん

# プロジェクトの概要 既存のRailsアプリケーションにおけるフロントエンド部分を、Next.js と TypeScript を用いてフルリニューアルしたプロジェクトです。技術負債の解消と表示速度の改善を主な目的とし、UIの刷新とともにコンテンツ管理の体制も見直しました。 # 背景と目的 長年運用されてきたRailsベースのアプリは、JavaScriptのスパゲッティ化や保守の難しさが課題となっていました。また、表示速度の遅さやSEO対応の限界もあり、モダンなフロントエンドフレームワークへの移行が急務でした。 # チーム構成、担当した役割 - エンジニア：2名 - デザイナー：1名 エンジニアチームにはNext.jsやTypeScriptの知見がほとんどない状態からのスタートでしたが、各自がキャッチアップを進めつつ実装に取り組みました。 ## 開発・実装内容A：記事コンテンツ部分の移行と表示ロジックの構築 【概要】 従来のRails管理画面で管理されていた記事コンテンツを、外部CMS（microCMS）へ移行し、表示ロジックをNext.js/TypeScriptで再実装しました。 【どのような機能の開発・実装か】 microCMS から取得したデータを使った動的ルーティングの記事一覧・詳細ページの構築 構造化データ（JSON-LD）やOGPなどSEO要件を満たす表示構成の設計 コンテンツ更新時のWebhookを使ったrevalidationの仕組み構 こちらは私が主体となり設計・実装まで行いました。 【課題・問題点】 microCMS導入による従来運用フローとのギャップ ビジネスサイドからの入稿レイアウトの希望とデザイナーとのディレクション 表示速度と最新性の両立（静的生成とリアルタイム更新のバランス） 【打ち手・使用した技術】 API取得のキャッシュ層を設け、fallback時のローディング状態やエラーハンドリングを柔軟に対応 Webhook による再検証APIのエンドポイントをNext.js側で実装 OGP対応：next/head + getServerSidePropsを併用したメタ情報注入 ## 開発・実装内容B：UI設計およびチーム連携体制の構築 【概要】 UIリニューアルに際し、デザイナーと密に連携しながら新しいデザインシステムのベースをフロント側に実装しました。 【どのような機能の開発・実装か】 コンポーネントベース設計（Atomic Designベース）での共通UIの構築 デザイナーとのFigma連携によるUIブレの吸収とルール整備（Storybook活用） これらはチーム全体で設計・分担実装し、私は主に記事表示UIとその派生コンポーネントを担当しました。 特に、デザイナーがデザインしたコンポーネントを抽象化し、汎用性を意識した形で再設計・実装することに注力しました。 【課題・問題点】 Next.js初心者が多く、再利用性の高いコンポーネントの設計方針がバラバラになりやすい デザイン上の命名やprops設計ルールが未整備 【打ち手・使用した技術】 UIルールの整備：Props名・スタイル適用方針のドキュメント化 Storybook によるUI一覧・テスト可能なコンポーネント管理 tailwind.config.jsでのカスタムデザイントークン定義 共通ユーティリティ（フォーマット関数など）を lib/ 配下に集約 # 成果 - パフォーマンス改善：Search Consoleの指標が向上しました。 - 運用負荷の軽減：外部CMSへの移行により、非エンジニアでも記事更新が可能になり、運用チームの負担を大幅に軽減。 - 保守性向上：TypeScriptによる型安全とNext.jsのファイルベースルーティングにより、機能追加や修正が容易になりました。 # 思考プロセス 「既存仕様をNext.jsに置き換える」のではなく、「どの@`ようにすれば運用と表示品質の両立ができるか」を常に問い直しながら設計 更新頻度、コンテンツ運用担当のリソースも考慮し再検証のバランス設計を提案 UIにおいてもFigmaだけでなく、実際のユーザー操作を想定したモック動作をデザイナーと共有して設計

# プロジェクトの概要 Railsアプリケーションにおける、社内の別サービスとの連携を目的としたAPIの開発プロジェクト。別サービスからのアクセスに対応するためのエンドポイント群を新たに設計・実装しました。 # 背景と目的 ビジネス要件として別サービスとデータをリアルタイムに連携する必要が生じたことから、新たにAPIを用意することになりました。既存の社内向け機能とは認証やデータの扱いが異なるため、専用の設計が必要とされていました。 # チーム構成、担当した役割 プロジェクトは4名体制（エンジニア3名、PM1名）で進行し、その中で私はAPIの仕様設計・認証設計・実装・テスト設計を主導しました。特に認証まわりについては明確な仕様が定まっていなかったため、拡張性を意識して設計を行いました。 # 開発・実装内容A：API設計と認証方式の導入 【概要】 別サービスとのリアルタイム連携に対応するため、REST API群の認証機能を設計・実装しました。 【どのような機能の開発・実装か】 認証トークンベースの認可ロジックの設計と導入 パラメータバリデーションの統一とエラーハンドリングの標準化 これらを主導して仕様検討から実装・レビューまで担当しました。 【打ち手・使用した技術】 トークンベースの認証（Bearer Token）を提案・導入。将来的な認証方式の差し替えも可能なようにインターフェースを抽象化 認証ロジックは concern に切り出し、既存のコントローラ群と重複しない構成を確保 APIバージョン設計（v1）を明示し、今後の拡張に備えた構造に RSpec によるリクエストスペックを用いて、異常系も含めた網羅的なテストを整備 # 開発・実装内容B：ユーザー保存処理の共通ロジック抽出と再利用設計 【概要】 新APIの実装にあたり、既存処理との重複を避けるため、共通的な処理を抽出・再設計し、保守性と再利用性の向上を図りました。 【どのような機能の開発・実装か】 複数の外部サービスからのユーザーを管理・保存しておく機能 共通パターンのエラーレスポンス出力機構の整備 これらのモジュール設計・実装を私が担当しました。 【課題・問題点】 複数の外部サービス間のユーザー保存ロジックに微妙に仕様差があり、コード共通化の粒度を見極めるのが難しかった データ構造の一貫性を維持しつつ、将来的な仕様変更にも対応できる柔軟な設計が求められた 【打ち手・使用した技術】 app/services に共通的なビジネスロジックを集約 フォーマット処理や認証処理は lib/ 配下に汎用ユーティリティとして切り出し APIバージョン設計（v1）を明示し、今後の拡張に備えた構造に # 成果 - 共通ロジックの切り出しと設計により、今後のAPI追加や仕様変更にも柔軟に対応できる基盤を整備。 # 思考プロセス 単にAPIを作るのではなく、"今後の拡張" や "運用負荷" を考慮し、ドキュメントベースで合意形成を図る設計にしました チーム内の実装者が拡張・利用しやすいよう、責務ごとのレイヤー分離と命名規則の統一にも注力しました 認証方式については、複数案（Basic認証・API Key・JWT）を比較し、現時点の運用と将来の切り替えしやすさのバランスを重視してトークン方式を選定しました