ID:77380さん

あなたを気にしている企業

3年後の目標や野望


社内で頼られるエンジニアになりたい。

現在フルスタックエンジニアとして仕事をしています。 まずはフロントエンドとバックエンドどちらも吸収し幅広く対応できるエンジニアになりたいと考えています。 頼れられる存在になりたい。例えば、新しいライブラリやモジュールの追加決定やメンバーの実装相談、また基盤整備など実装だけでないアプリケーション全体を見れるようになりたい。

プロジェクト経験

2024年/1年以内

Railsアプリケーションのフロントエンドフルリニューアル

# プロジェクトの概要 既存の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だけでなく、実際のユーザー操作を想定したモック動作をデザイナーと共有して設計

2024年/半年以内

外部サービス連携用のAPI開発

# プロジェクトの概要 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)を比較し、現時点の運用と将来の切り替えしやすさのバランスを重視してトークン方式を選定しました

マネージメント能力

アピール項目


アウトプット

GitHub アカウント
あり
Qiita アカウント
未入力です
Zenn アカウント
未入力です
Speaker Deck アカウント
未入力です
SlideShare アカウント
未入力です
特にアピールしたいアウトプット
未入力です

今後、身につけなければいけないと思っている技術は何ですか?

# インフラ含めたアーキテクチャー周り これまでアプリケーションレイヤーの開発経験を積んできましたが、今後はインフラの知見を深め、サービス全体の基盤を支えられるようなエンジニアを目指したいと考えています。サービスの安定運用やスケーラビリティの確保といった観点から、より上流の技術領域にも携わっていきたいと思っています。

あなたが一番パフォーマンスを出せるのはどんな環境ですか?

裁量権のある環境

キャラクター

直近で一番やりたいこと
サービスを作りたい
好きなスタイル
好きな規模
自信を持って人より秀でていると言える点
学習能力 / 調整力 / 問題解決力
スキルのタイプ
得意なフェーズ
会社を選ぶ一番の基準
好きなプロダクトがある
やりたくない分野
SI
その他の特徴
使用言語にはこだわらない
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

手を動かして設計してコードを書きたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
価値あるプロダクトを作り成長させたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
学び続けて技術力でプロダクトに貢献したい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
意義があることや社会に貢献できる仕事がしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
人や計画の調整・マネジメントをしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
レガシーなシステムの保守・運用・改善をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
企画や仕様を考えるところから関わりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
業務効率を改善して一緒に働く人のためになりたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
全社横断的な共通基盤作りや強化をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい
組織や文化を作る・成長させる仕事をしたい
絶対やりたくない
あまりやりたくない
別に普通
やりたい
絶対やりたい

基本プロフィール

年齢
今年で20代後半
好きなテキストエディタ
VScode
希望勤務地
東京都
希望年収
未入力
ご意見箱

要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。

なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。

  • {{error}}
転職ドラフトを友人や同僚に薦める可能性はどのくらいありますか?