ID:79543さん

### プロジェクト概要 老朽化したワインECサイトのフルリプレイスを担当。 新しい基盤としてShopify公式のReactベースフレームワーク「Hydrogen」を採用し、モダンな開発体験・拡張性・パフォーマンス改善を図った。スクラム体制でのアジャイル開発。 ### チーム情報 - チーム規模：PM・企画含む10名程度 - フロントエンド：3名（テックリード担当） - バックエンド：3名 - デザイン・企画：複数名 ### 使用技術 - 言語／FW：TypeScript / React / Remix / Hydrogen / GraphQL（Codegen利用） - ドキュメント／ナレッジ共有：Notion / Slack - バックエンドとの連携：GraphQL Code Generator / Apollo Client - フォーム・バリデーション：zod - CI/CD・補助：GitHub Actions（lint / test） --- ### 開発・実装内容A：チーム開発体制の再構築 **概要** プロジェクト中盤で参画。前任のテックリード不在時に設計・コードの品質に大きなバラつきがあり、チームとしての技術判断・レビュー体制も確立されていなかった。フロントエンドのリードとして、技術選定や設計方針の再整備、レビュー体制の立て直しを主導。 **課題・問題点** - 技術選定や設計の方針が曖昧で、コードベースに統一感がなかった - タスクの優先順位が曖昧なまま進んでおり、メンバー間の認識齟齬も多発 - PRレビューが形骸化しており、品質がメンバー任せになっていた - 新規メンバーを複数名迎える必要があり、技術的な選考・教育体制 **取り組み** - 既存のコードベースと課題を洗い出し、設計指針・ディレクトリ構成・命名ルール等の共通方針を整備 - GraphQL Codegen を導入してバックエンドスキーマとの型整合性を担保し、フロント実装効率と保守性を向上 - スプリント計画時に各メンバーのスキルを考慮し、進捗・特性に応じたタスク分解と再アサインを実施 - 新規参画メンバーの技術面談（React / チーム開発経験など）を実施し、選考および適正判断を支援 - 参画後はオンボーディング資料・ペアプロによる立ち上がり支援を行い、早期に戦力化 **成果** - 開発速度と品質のばらつきを抑え、安定したスプリントを継続できる状態へ改善 - 既存コードベースのモダン化と保守性の向上（） - 新規メンバーのオンボーディングも支援し、開発力の底上げに貢献 --- ### 開発・実装内容B：BFF層（GraphQL）と主要機能の実装 **概要** GraphQLベースのBFFを用いた商品情報取得などの主要機能を実装。また、未ログインユーザーの導線制御やフォームバリデーション、ルーティングガードなど、UIと連携したUX改善にも注力。 **課題・問題点** - GraphQL・Hydrogenなど初採用の技術が多く、チーム内の実装経験が不足 - フロント・バックエンド間のIF定義が曖昧で、画面ごとに冗長なGraphQLクエリが乱立 **取り組み** - Python (FastAPI) 側の実装者とGraphQL設計方針をすり合わせ、スキーマ設計の分担・IF整合を調整 - 認証情報のGraphQL経由での取得/確認方法を整理し、BFF層での認可制御を共通ロジック化 - ユーザー未ログイン時の動作をルーティング・フォーム両面で保護 - zod によるフォームバリデーションを導入し、UIエラー制御と型整合性を強化 **成果** - GraphQL未経験ながらも短期間で実装に貢献し、他メンバーの質問対応もリード - 認可・導線制御の不具合を解消し、ログイン状態に応じた正確な遷移制御を実現

### プロジェクト概要 社内のテスト業務・報告業務の効率化を目的とした支援ツールを新規開発。エンジニア・委託メンバー双方が利用するツール。フロントエンドからバックエンドまで、1人で実装。Turborepoを用いたモノレポ構成にて開発。 ### チーム情報 - 全体：５名ほど（レビューあり） - 実装：主担当としてフロント・バックエンドを一貫して実装 ### 使用技術 - フロントエンド：Next.js / TypeScript / React - バックエンド：NestJS（gRPC + GraphQL） - 共通：Turborepo / Docker / ESLint / GitLab CI - 補助ツール：GraphQL Codegen / 自動スキーマ検証 / 社内デザインシステム（v2） --- ### 開発・実装内容A：初期開発と基盤設計の整備 **概要** ほぼゼロからの新規開発。エンドユーザー（委託含む）がストレスなく使えるよう、APIの型整合性・UIの一貫性・安全性を重視しながらフルスタックで実装。NestJS（gRPC・GraphQL）やTurborepoなど未経験技術を短期間でキャッチアップ。 gRPCやGraphQLなど初採用技術のキャッチアップと、DDDによる責務分離を並行して推進。 **課題・問題点** - gRPCやGraphQLなど、バックエンド通信の技術スタックはすべて初挑戦 - 型安全性が低い実装は、委託メンバーとの連携やAPI変更時の影響が大きくなる懸念があった - テスト仕様が曖昧で、データの取得条件・表示要件が複雑な画面が多かった **取り組み** - gRPC + GraphQL APIをNestJS上に実装し、GraphQLスキーマとフロント型を自動連携する設計に構築 - API設計時点から型とユースケースを明示的に整理し、変更コストの少ない構成を意識 - テストレポート画面では、動的な集計・表示条件に対応するために、GraphQLの型とUI要件を何度も見直しながら仕様を詰めた - デザインシステム v2 に合わせ、全ページ・UIをリファクタ。100以上のコンポーネントを整理し、命名・再利用性・アクセシビリティも改善 - Storybookを活用して UIコンポーネントをドキュメント化し、デザイナーや他開発者との連携効率を向上 - バリデーションに zod を導入し、UIエラー制御と型安全性を両立 **成果** - DDDベースの明確なレイヤー構造により、責務ごとの変更影響を局所化し、以後の機能追加が容易に - 未経験技術（gRPC / GraphQL / NestJS）も短期間でキャッチアップし、安定して自走可能な体制を構築 - フロント全体のリファクタを実施し、保守性・再利用性の高いUI基盤を確立 - デザイン刷新による100以上のUI要素のリファクタに成功し、再利用性と保守性を改善 - Storybookの導入により、開発・デザインの非同期連携を効率化 --- ### 開発・実装内容B：E2Eテスト・CI整備・品質改善 **概要** E2Eテスト戦略・CI自動化・セキュリティ脆弱性対応を担当。PlaywrightによるE2Eテスト導入・拡張を推進し、社内テストレポート要件に応じて独自のカスタムレポート出力機能も構築。 **課題・問題点** - PlaywrightによるE2Eテストの導入はあったが、テストパターン管理やレポート出力が未整備 - CI整備や脆弱性対応が後回しになっており、信頼性が低かった **取り組み** - Playwrightのテストコードをベースに、テストケースをパターン別に整理し、ページ単位で網羅 - 独自のカスタムレポート出力ロジックを作成し、テスト結果をHTML形式で自動生成・保存 **成果** - PlaywrightベースのE2Eテストで主要な画面遷移・入力パターンの自動検証を実現 - 開発した独自レポート出力ロジックは、QA系の全プロジェクトに共通導入され、組織内の標準に - 脆弱性対応を通じ、リリース前品質の底上げに貢献

### プロジェクト概要 社内エンジニアの生産性向上を目的とした、Backstageベースの開発者ポータルにおける新機能追加と運用改善を継続的に担当。 申請フローの電子化、マイクロサービス情報の可視化、通知機能の整備などを通じて、開発・運用に関わる工数削減と属人化防止を実現。 フロントエンド・バックエンド・インフラ（IaC）領域を横断し、一貫して設計・実装を担当。 ### チーム情報 - チーム規模：2〜5名（変動あり） - 自身の役割：主担当としてフロントエンド〜バックエンド・IaCまで幅広く実装、レビューも一部対応 ### 使用技術 - フロントエンド：React / TypeScript / React Flow - バックエンド：Go（Lambda） / AWS SDK - インフラ：Terraform / CloudFormation / Step Functions / LocalStack（デバッグ） - 共通：Backstage / GitHub / Slack通知 / AWS（RDS / IAM など） --- ### 開発・実装内容A：申請・承認フローとインフラ連携機能の整備 **概要** DBやレプリカなどのリソース申請をWeb UIから可能にし、通知・承認・Lambda実行までの自動化を実現。Terraform / CloudFormation の実行制御も組み込み、GUI操作による安定したインフラ変更を支援。 中でも、**リードレプリカの個数調整フォームは新規機能として提案・設計・実装まで一貫して対応**し、運用フローにおける属人性の排除に寄与。 **課題・問題点** - リードレプリカ数や構成に制約があるものの、それを制御するUI・申請フローが存在しなかった - 初期フェーズではFigmaなどの設計資料もなく、仕様も抽象的な状態でスタート - Terraform / CloudFormation の習熟も必要であり、インフラ知識が求められた **取り組み** - **リードレプリカの申請フォームを新規開発**。 - 仕様はプロジェクトリーダーと1on1で要件定義・すり合わせを行いながら具体化。制限ルールやユースケースを整理 - AWS SDK for Go による Lambda 関数を実装し、**リードレプリカ数の制限チェック**および**調整API**を作成 - LocalStack によるローカル環境でのデバッグフローを整備し、ユニットテストによる動作確認も実施 - Step Functions + Lambda による申請〜承認〜実行の非同期処理を構築 - Terraform / CloudFormation に関しては、関連リソースの変更・修正も担当。初学習ながら周辺リソースの依存関係を把握して対応 **成果** - **リードレプリカ調整をGUIで実現する初の社内フォームを構築し、インフラ設定申請を簡素化** - 要件定義から設計・実装・テストまでをリードし、抽象的な要求を具現化する自走力を発揮 - Terraform / CloudFormation を通じたリソース制御も可能となり、チーム内でのカバー範囲を拡大 --- ### 開発・実装内容B：マイクロサービスの可視化・UX改善 **概要** Backstage 上でのマイクロサービスの構成・依存関係の一元可視化、通知連携の実装、UXの改善を実施。抽象的な仕様を具現化しながら、チームの運用効率向上に貢献。 **課題・問題点** - サービス情報が分散しており、構成把握や障害対応に時間がかかっていた - 「いい感じに見せてほしい」など抽象度の高い相談が多く、要件具体化にスキルが求められた - 通知や依存関係可視化の機能は未整備で、導線が分かりにくかった **取り組み** - React Flow によるグラフ表示機能を新規実装し、サービスの依存関係・構成を視覚化 - サービスのメタ情報を統一形式で管理し、YAMLからの集約と表示を実現 **成果** - サービス構成の可視化により、障害対応・引き継ぎ時の負荷を大幅に削減 - 抽象的な要件からプロトタイプ・設計・実装まで自走し、要求を具体的な機能へ変換できるスキルを発揮

【目的・背景】 求人情報の自動収集を行う商用クローラーの安定運用・新規求人媒体の追加。 会社の売り上げの99%はこのクローラーで売り上げを上げていました クロール対象は多数存在し、営業からのリクエストで媒体が追加され続ける状況。媒体数は200以上 【技術・開発環境】 AWS EC2 / AWS S3 / Java HTML / CSS / macOS 【規模感】 運用・保守担当者：２～３人 営業や他の部署の方と遅延の連絡など密接に連絡をとる必要があった 【課題】 約400インスタンスで構成された大規模クローラー群の監視・運用体制が属人化しており、ドキュメントも存在しなかった サイト構造の変更によるXPATHやセレクタ破損への対応が場当たり的 IPブロック対策やBright Data設定変更などのノウハウも属人的だった 【対応・成果】 ソースコードと挙動を読み解き、仕様ドキュメントを自ら整備 クローラー停止時の原因究明と再発防止を繰り返すことで、問題解決力を強化 新規媒体追加時には営業からの要件をもとにクローラー設定・インスタンス立ち上げまでを一貫して担当

【目的・背景】 社内でGoogleカレンダー・スプレッドシートを用いたメール運用にミス・漏れが多発していたため、それをアプリケーション化するプロジェクト 【技術・開発環境】 TypeScript / React / Firebase / Firebase Authentication / AWS Lambda / AWS API Gateway / AWS S3 / Python HTML / CSS / macOS 【規模感】 開発担当者：１人 責任者：１人 デザイナー：１人 【課題】 社内向けSaaS、単独開発に近い形で0→1開発を担当 第三者がテスト項目を定義し、自身がテスト・リリースを実施 【対応・成果】 初学だったReact/TypeScriptを1週間でキャッチアップし、本番リリースまで完遂 フロントエンド〜バックエンド〜認証〜デプロイの全工程を自走 シンプルながら、実務で使われるSaaSの構築・運用経験を積むことができた

【目的・背景】 Watson Discoveryを活用したチャットボットの業務適用を検証するPoC（Proof of Concept）プロジェクト。既存の試作フェーズを踏まえ、実用性の高いUI/UXと構成を整備。 作成したアプリを実際に外部の方に触ってもらってレビューなども行ってもらった 【技術・開発環境】 TypeScript / React / HTML / CSS IBM Cloud / OpenShift / Playwright（E2E Test）] Windows 【規模感】 フロント・バックともに実装を担当（小規模チーム 合計７人程度） 開発者は２人（内１人はAI側の実装） 【対応・成果】 未経験のIBM CloudやWatson Discoveryを短期間でキャッチアップし、機能実装 セッションの可視化、自然文検索の強化など、ユーザー体験を意識した改修を主導 AIに学習させる仕組みや、テスト・CI/CDフローも自力で構築

【目的・背景】 複数の自動車関連企業を横断する共通プラットフォームを構築。業務支援機能を集約し、B2B向けサービスとして展開。 【技術・開発環境】 TypeScript / React / Next.js / HTML / CSS（Material UI） Kotlin（Spring Boot）/ AWS CodeCommit 【規模感】 中規模チーム (20人程度) React/Next.jsでの画面設計・修正・コンポーネント開発を担当 【対応・成果】 フォームのバリデーションや基本設計の見直しなど品質面も強化 Kotlin/Spring Bootの構成理解を進め、バックエンドと連携しながら実装を推進

【目的・背景】 製薬会社のデータ管理業務を支援するDBツールのフロントエンド刷新 現行ツールの課題解消とUX向上を目的としたウォーターフォール型開発 【技術・開発環境】 TypeScript / React / Next.js / HTML / CSS（Material UI） TanStack Query / Zustand / Java（Spring Boot） / MSW 【規模感】 数名のフロントエンドチームに所属し、主要ページやテストの実装を担当 単体〜結合テストまでを含めた一連の品質保証プロセスに貢献 【対応・成果】 レイアウトの条件分岐が多く、Material UIのカスタマイズに苦労したが、独自テーマ設計と関数化で可読性と再利用性を担保 時間が少ない中で数十ページの実装

【目的・背景】 既存の社内向けQAシステムが保守しづらく、UI・操作性にも課題があったため、大規模なUIリプレイスと構成整理を目的に再構築 【技術・開発環境】 Next.js / TypeScript / Docker / ESLint / CI / Github 【規模感】 開発メンバーは2人もう一人はインフラ担当 【対応・成果】 従来UIの課題をユーザーとすり合わせ、実際の業務フローに合った操作性へ改善 コードベースを整理し直し、重複や複雑な構造を簡素化 UI設計の見直し、デザインの細かい動作仕様も含めて提案 デザイナーからのフィードバックも取り入れつつ改善 新たに参加したエンジニアや委託メンバーも、把握しやすく使いやすい設計を実現

【目的・背景】 社内のUIコンポーネントのばらつきやアクセシビリティ不備を解消し、再利用性と統一感を持ったデザインシステムを整備することで、開発効率と品質を両立することを目指した 【技術・開発環境】 React / TypeScript / Storybook / Next.js 【規模感】 デザイナー・エンジニア含め小規模 【対応・成果】 アクセシビリティチェック（キーボードナビゲーション・スクリーンリーダ対応など）を実装に反映 Storybook によるVRTでUI崩れ検知を自動化 運用者目線を意識した設計（Props設計・ドキュメント整備） で他開発者の学習コストを最小化 また外部のデザイン会社からのフィードバックの対応を実装に反映

【目的・背景】 デザイナーやエンジニアが社内で再利用するための アイコン・アニメーション素材を一元管理できるアプリケーション を構築 運用上の煩雑さを解消し、デザイナーの作業効率を支援 【技術・開発環境】 Astro.js / TypeScript / Tailwind CSS / Gitlab CI 【規模感】 デザイナー・エンジニア含め小規模 実装担当者は自身のみ 【対応・成果】 検索性の高いUI、ファイルアップロードの自動分類、タグ・カテゴリ機能を実装 デザイナーと話し合い、社内の運用負荷を削減できるような構成に実装 デザイナーからのフィードバックも取り入れつつ改善