webサービスの構築 5,000円〜

商品PR画像作成システム

ドリップコーヒー販売のECサイトです(URLを詳細へ記載)

AIで生成した画像を管理するサイト(URLを詳細へ記載)
ITエンジニア / フロントエンドエンジニア 経験年数 : 5年
ITエンジニア / バックエンドエンジニア 経験年数 : 5年
ITエンジニア / システムエンジニア 経験年数 : 5年
HTML 経験年数 : 5年
JavaScript 経験年数 : 5年
Python 経験年数 : 5年
Sass 経験年数 : 5年
TypeScript 経験年数 : 5年
Next.js 経験年数 : 5年
・webサービスの構築 5,000円〜
webサービスの構築は得意です。また何か案件があればご紹介頂けますと幸いです。 LinkedIn https://www.linkedin.com/in/yutaka-nagasaki-4b5667316/ 個人アプリも作成しているので興味があれば見てみてください。LindedInに貼り付けています。 すみません、ここでは200文字の制限があり貼り付けできませんでした。
英語 ビジネス会話レベル
AMBL株式会社 2025年1月 〜 2025年11月
・ポケモン公式コンテンツ管理システム / バックエンドエンジニア / バックエンドエンジニア 2025年1月 〜 2025年11月
スキルシート↓ https://drive.google.com/file/d/1C1HsstcKdqIkr8V-nJE-a1QjsrgwNrb_/view?usp=drive_link ≪担当業務≫ ・NestJSを用いたバックエンド開発 ・Next.jsを用いたフロントエンド開発 ・新規機能の開発およびリリース後の既存機能の改修・拡張 ・Prismaを用いたDB設計・実装 ・REST API設計・実装(OpenAPIによる仕様管理) ・コードレビュー ・Dockerを用いた開発環境の構築 ・GitHub Actionsを利用したCI/CDパイプラインの構築 ・AWSを用いたインフラの設計・構築・運用(CloudFront、AWS Fargate、Lambda、SQS、CloudWatch等) ・Jest、Playwrightを用いたユニットテスト・E2Eテストの整備 ≪稼働量・稼働スタイル≫ 平日の日中帯に、月およそ160時間(フルタイム相当)で稼働しておりました。 ≪開発手法≫ アジャイル ≪成果・実績≫ アジア圏(シンガポール、台湾等)で展開されるポケモン公式ポータルサイト(https://sg.portal-pokemon.com/)の新規開発に参画。 0→1のプロジェクトとして、CMS基盤のバックエンド・フロントエンド・インフラを一から設計・構築し、運用まで担当しました。 TypeScriptで実装したいという背景があり、技術選定はチームで議論して決定しました。 アジア7カ国への展開まで関わり、完了しています。 ・OpenAPIによるフロントエンド・バックエンド間の型共有: これまでの経験上、フロントエンドとバックエンドで型定義がずれて不整合のバグが起きやすいことがわかっていたため、 開発の初期段階でOpenAPIの導入を提案。 API仕様から型を自動生成する仕組みにすることで、手動での型定義のずれが起きない状態を最初から作った。 その結果、リクエスト・レスポンスの不一致によるバグは発生しなかった。 ・インフラ構成の設計と運用: AWSの構成はチームで議論したうえで、コストや今後の運用体制を考慮し、現状の要件を満たす最低限の構成で構築。 AWS Fargateを採用してスケールを意識した構成にし、SQSを使ってジョブキューも扱えるようにした。 運用面では、CloudWatchの内容をSlackに連携し、エラーが起きるとSlackに通知される仕組みにした。 ・管理画面の更新日時指定に対応したCloudFrontキャッシュ更新の自動化: 管理画面でコンテンツの更新日時を指定でき、その日時はデータベースの値を基準に管理する仕様だった。 Lambdaで5分おきにデータベースへフェッチし、CloudFrontキャッシュのinvalidationを自動実行する仕組みを構築。 手動での対応が必要にならない状態にした。 ・CI/CDパイプラインの構築による開発効率の向上: GitHub Actionsを活用したCI/CDパイプラインを一から構築し、デプロイの自動化と手順の統一を実現。 属人化を防ぎ、チーム全体の開発効率を向上させた。 ・テスト戦略の構築によるバグの早期発見: 公式サイトという特性上、バグを本番に出さないことを最優先とし、テスト戦略を提案。 テストケースをスプレッドシートで管理し、各機能に対して「どのような条件で、どのような結果になるか」を明確に定義。 このケース管理をもとに、ユニットテストはJest、E2EテストはPlaywrightで整備し、開発段階でのバグの早期発見を可能にした。 ・コード品質の維持・向上: 複数メンバーでの並行開発により、コードの書き方や設計方針にばらつきが出やすい状況だった。 コードレビュー・設計レビューを積極的に行い、実装方針の統一とサービスの安定性・保守性の向上に貢献した。 ≪終了理由≫ 本プロジェクトは、各国のポケモン公式ホームページを、これまで各国の担当者が個別に制作・運用していた形から、 CMS化によって管理を簡略化することを目的としたものでした。 当初はアジア7カ国、ヨーロッパ、北米へと順次展開する計画でしたが、アジア7カ国への展開が完了した後、 ヨーロッパ・北米への横展開がクライアント側の予算の都合により一旦延期となりました。 当初の展開計画が見直されたことから、アジア7カ国への展開をもってプロジェクトは終了となり、本契約も終了となりました。
A2Z株式会社 2026年2月 〜 2026年7月
・恋愛マッチングサービス / システムエンジニア/プロジェクトマネージャー / フロントエンドエンジニア・バックエンドエンジニア・システムエンジニア・情報システム・社内SE・フルスタックエンジニア 2026年2月 〜 2026年7月
スキルシート↓ https://drive.google.com/file/d/1C1HsstcKdqIkr8V-nJE-a1QjsrgwNrb_/view?usp=drive_link ≪担当業務≫ (フルスタックエンジニア) ・React Native / Expoを用いたフロントエンド開発 ・NestJSを用いたバックエンド開発 ・Prismaを用いたDB設計・実装 ・GraphQLを用いたAPI設計・実装 ・新規機能の開発および既存機能の改修・拡張 ・大量データを扱うバッチ処理の改善 ・GitHub Actionsの既存ワークフローの修正(Devinレビューの組み込み) (PM業務) ・マッチングアルゴリズムの改修(起案〜実装) ・ユーザー獲得・課金促進キャンペーンの企画・運用 ≪稼働量・稼働スタイル≫ 平日の日中帯に、月およそ160時間(フルタイム相当)で稼働しておりました。 ≪開発手法≫ アジャイル ≪成果・実績≫ 恋愛系C2Cマッチングアプリ「mypappy」の開発に、フルスタックエンジニア兼PMとして参画。 技術選定やアルゴリズムの改善方針はチームで決めたうえで、PM5名・エンジニア20名の体制の中、 アルゴリズム改修とキャンペーンの2つをリードしました。 ・行動指標に基づくマッチングアルゴリズムの改修: 当初は一つの指標でいいねの傾向を判断していましたが、ユーザーによって傾向が違うため、試行錯誤のうえで、 いいねの履歴、プロフィールの閲覧、滞在時間、写真のスワイプなどの行動指標からレコメンドを決める方式に変更。 起案から実装までを担当し、マッチ率が数%程度上昇した。 ただし短期間での計測のため、長期的な効果は契約終了により確認できていない。 ・ワールドカップに合わせたポイント半額のゲリラキャンペーン: mypappyでは「いいね」「デート投稿」「メッセージ付きいいね」などの利用にポイントが必要で、ポイントは無料・有料ユーザーとも購入して使う仕組み。 ポイント購入のきっかけを作るため、需要が高まるワールドカップの時期に合わせて「48時間限定でポイント50%オフ」を企画・運用。 これまでポイントを買っていなかったユーザーの購入が定着し、その割合が数%程度上昇した。 こちらも短期間の計測のため、長期的な経過観察は契約終了により確認できていない。 ・バッチ処理の改善: 大量のデータをスケジュール実行するバッチ処理の一部でバグが発生していた。 今後の運用についてチームで議論し、ジョブの仕様を大きく変える予定はないと判断。 コストも考慮し、EventBridgeなどのインフラを追加するのではなく、DBでジョブキューを実現した。 大量データを扱うため、トランザクションとロック機構を整備。既存のロックは必要な箇所に掛かっていなかったが、 全体をトランザクションでロックすると、後続処理でDB接続エラーが起きた際にコミットされず、他テーブルのインサートに影響する懸念があった。 そこでテーブルとカラムを追加し、ロックが必要な箇所だけに絞ることで、既存機能への影響を抑えながらバグを解消した。 ・AIエージェントの導入提案とレビュー体制の改善: Claude Codeを各エンジニアのローカル開発に導入、Devinをコードレビューに活用することを提案(実装は他のエンジニアが担当)。 DevinはRedash・Slackと連携させ、リポジトリの読み取りが得意なことから、イシュー起票の段階で原因箇所を自律的に特定させる運用も取り入れた。 また、Devinのレビューが実行される条件を整理し、GitHub Actionsに組み込んだ。 従来は、イシューとの乖離や仕様通りに動いているかの確認からコードレビューまでを人間が行っていたが、仕様との適合性やコードの状態の確認をDevinに任せ、 人間はDevinのapproveとAIコメントのresolveを確認したうえで最終判断だけを行う形にした。 その結果、レビューにかかる時間が短縮された。 ≪終了理由≫ toCサービスの特性上、広告費や運営経費が膨らみ、サービス全体として大幅な赤字が続いている状況でした。 サービスの存続を最優先とする方針のもと、追加の新規開発や新規プロモーションといった費用のかかる施策を 一旦取りやめることになりました。 これに伴い、エンジニア・PM・CSなどの人員も削減されることとなり、本契約も終了となりました。