ID:82942さん

キャリアビジョン


フロントエンドを軸に、バックエンド・インフラまで対応できるエンジニアとして、技術で幅広く価値を発揮できる存在になりたい。

これまでの開発経験を通じて、フロントエンドの奥深さと面白さを感じ、まずはこの領域を深く極めたいという思いが強くなりました。 ただ、フロントエンドだけでなく、バックエンドやインフラの知識があってこそ、システム全体を意識した質の高い実装ができると考えています。将来的には、フロントエンドを主軸としながらも、隣接する技術領域にも対応できるエンジニアとして、どんなフェーズのプロジェクトでも貢献できる存在を目指したいと思っています。

プロジェクト経験

2024年/2年以内

縦読みマンガ投稿サービスの新規機能開発・保守

## 縦読みマンガ投稿サービスの新規機能開発・保守 ### プロジェクト経験概要 縦読みマンガ投稿サービスにおいて、新規機能開発および既存機能の改修・運用保守を担当。フロントエンド(Next.js)からバックエンド(GraphQL/Prisma)まで横断的に開発に従事。 ### チーム情報 エンジニア2名体制(自分含む)の少人数チームで、先輩エンジニア1名とともに開発を担当。仕様検討・設計から実装まで一貫して関わる機能を複数担当した。 --- ### 限定公開機能の設計・実装 【概要】 「一般公開はせず、サイト内で開催されているコンテストに応募したい」というユーザー要望に対応するため、特定URLを共有された人のみ閲覧可能な機能を設計・実装。応募作品を編集部が確認できる手段としても機能する。仕様検討・設計から実装まですべて自身で担当。 【課題・問題点】 当初は「TOPやユーザーの作品一覧に該当作品を表示しない」案で進めていたが、コードレビューで「作品IDがアルファベットの連番に近い構造になっており、URLを直接推測されると到達できてしまう」という指摘を受け、表示制御だけでは不十分でアクセス制御レベルでの担保が必要と判断。 【打ち手・使用した技術(自分担当)】 - 設計判断として、URLパラメータに推測困難なキーを含め、そのURLを共有された人のみアクセス可能とする方式を採用。「公開フラグでオン/オフ制御する案」も検討したが、URLを推測されるリスクが残るため不採用。 - DB(Prisma):作品テーブルに公開用キーカラムを追加し、URL限定公開の設定をした場合にレコード作成時に推測困難なキーを生成。 - GraphQL API:リクエストヘッダで受け取ったキーをResolverで検証し、キー不一致時はデータを返さない制御を実装。既存の公開作品取得フローと共存する形で設計し、後方互換性を担保。 - フロントエンド(Next.js):UrqlクライアントのfetchOptionsで、クエリ送信時にURLパラメータからキーを取得しリクエストヘッダに付与する設定を追加。 --- ### いいね重複カウント防止の不正対策 【概要】 いいね数の不正水増しを防ぐため、同一IPアドレスからの重複いいねをカウントしないロジックを実装(自身で担当)。 【課題・問題点】 主に未ログイン状態かつプライベートブラウザを用いた水増しが問題となっていた。Cookieやセッションでは検知できないため、サーバー側で識別できる情報を用いた対策が必要だった。 【打ち手・使用した技術(自分担当)】 - いいねテーブルに元々IPアドレスが保存されていたことを活用し、GraphQL側でいいね登録時に同一IPからの重複登録を弾く制御を追加。スキーマ変更を伴わずに対応した。 --- ### 編集部おすすめ作品表示ロジックの改修 【概要】 TOPに表示される編集部おすすめ作品10件の表示ロジックを改修(自身で担当)。 【課題・問題点】 従来は「編集部がバッジを付与した順」で表示する仕様だったため、訪問のたびに同じ作品が並び、ユーザーから見ても新鮮味がなく、新規作品との出会いが生まれにくい状態だった。 【打ち手・使用した技術(自分担当)】 - 表示ロジックを以下のように改修: - 「直近のコンテストで賞を獲得した作品」「編集部が直近でバッジを付与した作品」は必ず表示枠を確保 - 残りの枠は過去にバッジを付与された作品からランダムに表示 - 「最新かつ重要な作品は必ず見せる/残りは訪問のたびに変化させる」というルールを両立させ、固定表示と動的表示のバランスを取った。 - 実装にあたっては、PrismaのORM機能だけでは「特定条件を満たすレコードを優先しつつ、残り枠をランダム抽出する」という複合的なクエリを表現しきれなかったため、`prisma.$queryRaw` で生SQLを記述して取得する方針に切り替えた。ORMで対応可能な範囲を見極めた上で、必要に応じて生SQLに切り替える判断を行った。 --- ### Next.js Pages Router → App Router への段階的移行 【概要】 Next.jsのPages RouterからApp Routerへの移行を、自分が主体となって段階的に推進。 【課題・問題点】 全ページの一括移行はリスクが高く、運用も止められないため、ページ単位で段階的に移行する戦略が必要だった。一方、移行期間中はPages RouterとApp Routerが共存する状態となり、両者で使い方が異なるAPIへの対応に苦戦した。具体的には、`useRouter` の使い方がApp/Pagesで異なるため、両方で使用される共通コンポーネントでは両対応させる必要があった。また、Urqlクライアントの構成もApp/Pagesで異なり、共通コンポーネントの動作担保に工夫を要した。 【打ち手・使用した技術(自分担当)】 - 影響範囲の小さいページから順次App Routerへ切り出し、リスクを抑えながら移行を進めた。 - 基本方針としてServer Componentに寄せ、クライアント側の機能(フックや状態管理など)が必要な箇所にのみ `"use client"` を付与する形で設計。 - App/Pagesの両方から呼ばれる共通コンポーネントについては、両環境で動作するように `useRouter` やUrqlクライアントの差異を吸収する形で実装。 --- ### 漫画賞コンテストLP・結果発表ページの制作 【概要】 Headless CMSのContentfulを用いて、漫画賞コンテストのLPおよび結果発表ページを制作。 【打ち手・使用した技術(自分担当)】 - 既存のContentfulコンテンツモデルをベースに、今回のページに必要なフィールド追加・調整を実施。編集部が運用しやすい形に整備。 - Next.jsからContentful APIで取得し描画する実装。

2025年/3ヶ月以内

自社コーポレートサイトのリニューアル対応(フロントエンド改修)

## 自社コーポレートサイトのリニューアル対応(フロントエンド開発) ### プロジェクト経験概要 自社コーポレートサイトの全面リニューアルに伴うフロントエンド開発を担当。既存サイトをゼロからNext.js(App Router)で作り直し、デザイナー作成のデザインをもとに画面構築・多言語対応・お知らせ機能・アニメーション実装までを一貫して担当した。 ### チーム情報 デザイナー・ディレクターは別途いるが、フロントエンド開発担当は自分一人。設計・実装まで単独で完遂した。 --- ### Next.js(App Router)でのサイト全体構築 【概要】 既存コーポレートサイトをゼロからNext.js(App Router)で再構築。デザイナー作成のデザインを忠実に再現する形で実装(自身ですべて担当)。 【打ち手・使用した技術(自分担当)】 - Next.js App Routerを採用し、基本はServer Componentで構成。"use client" を付けるClient Componentが必要最小限になるよう、コンポーネント単位での切り分けを意識した。たとえばインタラクションが必要な部分だけを子コンポーネントに切り出し、そこにのみ "use client" を付与することで、サーバー側でレンダリングできる範囲を最大化した。 - スタイリングはTailwind CSSを採用。ユーティリティクラスベースでデザインを再現しつつ、再利用しやすいコンポーネント設計を意識。 - 画像表示にはnext/imageを使用し、Next.jsの標準機能を活用した実装とした。 --- ### next-intlによる多言語対応(日本語・英語) 【概要】 日本語・英語の2言語に対応するため、next-intlを用いた多言語化を実装。 【課題・問題点】 日本語をデフォルトロケールとし、URLにロケールプレフィックスを付けない方針となっていた一方で、英語ページは /en/... のようにプレフィックスを付ける必要があった。デフォルトと非デフォルトでURL構造を分ける構成と、それに伴う言語切り替え動線の実装が必要だった。 【打ち手・使用した技術(自分担当)】 - next-intlの localePrefix: 'as-needed' 相当の設定を採用し、日本語は /...、英語は /en/... というURL構成を実現。 - 言語切り替え時のリンク生成、各ページでの翻訳ファイル読み込みなどをnext-intlのAPIを用いて実装。 --- ### Contentful連携のお知らせ機能 【概要】 お知らせの新着一覧ページと詳細ページの両方をContentfulと連携して構築。編集部側でContentful上から記事を投稿・更新できる運用を実現。 【打ち手・使用した技術(自分担当)】 - Contentful APIから記事データを取得し、一覧ページ・詳細ページそれぞれで描画する実装。 - App RouterのServer Componentで取得することで、クライアント側にAPIキーや余分なJSを送らない構成とした。 --- ### アニメーション実装 【概要】 デザインに含まれる各種アニメーション(複数オブジェクトのふわふわとした動き、ページ表示時の順次表示、オブジェクトの明滅など)を実装。 【打ち手・使用した技術(自分担当)】 - CSSの transition / animation を用いて、複数オブジェクトのふわふわとした動きや明滅などのループアニメーションを実装。 - ページ表示時にオブジェクトを順番に表示させる演出は、animation-delay を組み合わせることで実装。 - スクロール連動の表示アニメーションは Intersection Observer API を用い、ビューポートに入ったタイミングで発火させる実装。scroll イベントの常時監視を避けることでパフォーマンスを担保した。

2022年/2年以上

Webサイトの新規コーディング・保守改修

## Webサイトの新規コーディング・保守改修(受託開発) ### プロジェクト経験概要 受託開発として、コーポレートサイトを中心としたWebサイトの新規コーディングおよび既存サイトの保守・改修を担当(2022年〜、約2年以上)。数十ページから数百ページ規模のサイトを多数手掛け、HTML/CSS/JSによる静的サイトの構築と、WordPressを用いたサイト構築の両方を同程度の比率で経験。EJS・Webpack・Dockerなどを用いた開発効率化や、後輩エンジニアへの指導も担当した。 ### チーム情報 案件によってチーム構成は異なるが、自分一人で一括して担当する案件が多かった。設計・コーディング・運用保守までを単独で完遂するケースを複数経験。後輩エンジニアが入った際には、作業手順やツール使用方法のレクチャー、隣でのサポートなどを担当。 --- ### コーポレートサイトのコーディング(数十〜数百ページ規模) 【概要】 デザインカンプ(Figma / Photoshop / XD)をもとに、コーポレートサイトのコーディングを担当。数十ページから数百ページ規模まで、さまざまな規模のサイトを扱った。 【打ち手・使用した技術(自分担当)】 - HTML / CSS(SCSS) / JavaScriptを用いて、デザインカンプを忠実に再現する形でコーディング。 - デザインカンプで指定されたPC / タブレット / SPの各ブレイクポイントに沿って、レスポンシブ対応を実施。 --- ### WordPress開発(オリジナルテーマ構築) 【概要】 WordPressを用いたコーポレートサイト制作を複数担当。担当案件はすべてオリジナルテーマをゼロから構築する形で対応した。 【打ち手・使用した技術(自分担当)】 - オリジナルテーマをゼロから設計・実装。テンプレート階層に沿ったファイル構成で、案件ごとの要件に合わせて構築。 - ACF(Advanced Custom Fields)を用いてカスタムフィールドを設計し、編集部・運用者がWordPress管理画面から自由にコンテンツを編集できる構成を実現。 - カスタム投稿タイプを設計し、お知らせ・事例・実績などの定型コンテンツをWordPress上で適切に管理できるよう設計。 --- ### EJS / Webpackによる開発効率化(静的サイトコーディング向け) 【概要】 静的サイトのコーディング業務において、開発効率と保守性を高めるためEJSとWebpackを導入・活用。 【打ち手・使用した技術(自分担当)】 - EJS:ヘッダ・フッタ・ナビゲーションなどの共通パーツをテンプレート化し、`include` で各ページに取り込む構成で実装。 - Webpack:Sass/SCSSのコンパイル、複数JavaScriptファイルのバンドル(マージ)を実施。ビルドコマンド一発で本番用ファイルを生成できる開発環境とした。 --- ### Dockerを用いたWordPress開発環境の構築 【概要】 WordPress開発において、ローカル開発環境をDockerで構築。 【打ち手・使用した技術(自分担当)】 - docker-composeを用いて、WordPress本体とMySQLをまとめて立ち上げる構成で開発環境を用意。 --- ### 後輩エンジニアの指導 【概要】 後輩エンジニアが参画した際の指導・サポートを担当。 【打ち手・使用した技術(自分担当)】 - 作業手順や使用ツール(Git・Webpack・WordPressのローカル環境など)の使い方をレクチャー。 - 詰まったタイミングで隣でサポートしながら、自走できるようになるまで伴走。

マネージメント能力

アピール項目


アウトプット

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

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

フロントエンド、バックエンドのほかに、インフラについても身につけたいと思っています。

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

前職では、レビューや指摘の場面で強い口調や追及されるようなやり取りが続き、仕事に対して萎縮してしまう面がありました。指摘の中身を受け止めること自体には抵抗がないので、次は穏やかに意見を交わしながら進められるチームで、安心して力を発揮できる環境がよいと考えています。

生成AIの活用状況

日常的な情報収集・業務活用
ChatGPTやGeminiなどのチャットツールを、情報収集、ドキュメント作成、翻訳に日常的に活用
業務でコード生成、コーディングエージェント系の生成AIを利用
コードレビュー、テストコード生成、デバッグに生成AIを活用

キャラクター

直近で一番やりたいこと
技術を極めたい
好きなスタイル
一人で黙々
どちらかといえば一人で黙々
どちらともいえない
どちらかといえばみんなでワイワイ
みんなでワイワイ
好きな規模
小さい会社
どちらかといえば小さい会社
どちらともいえない
どちらかといえば大きい会社
大きい会社
自信を持って人より秀でていると言える点
学習能力 / 問題解決力 / 責任感
スキルのタイプ
ゼネラリスト
どちらかといえばゼネラリスト
どちらともいえない
どちらかといえばスペシャリスト
スペシャリスト
得意なフェーズ
0 → 1
どちらかといえば0 → 1
どちらともいえない
どちらかといえば10 → 100
10 → 100
会社を選ぶ一番の基準
一緒に働く人
やりたくない分野
未入力です
その他の特徴
未入力です
その他のやりたいこと・やりたくないこと
未入力です

やりたい事

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

基本プロフィール

年齢
今年で30代前半
好きなテキストエディタ
VSCode
希望勤務地
埼玉県 / 千葉県 / 東京都 / リモート勤務
家庭の事情や体調など、都合に合わせてリモート出来れば問題ない
希望年収
500万円
ご意見箱

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

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

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