sosokura

デジタル・インフォメーション・テクノロジー株式会社 在籍期間：2024 年 1 月〜2025 年 2 月 事業内容：中堅 SIer（Web 開発）／東証プライム上場／従業員数：1,330 名　主な役割：バックエンドエンジニア／BE・FE エンジニア SOMPO BtoC／SNS サービス（バックエンドエンジニア） 技術環境：TypeScript（Node.js／Express）、Jest、Docker、Amazon Aurora（MySQL）／チーム 10 名（インフラ 1 名、BE 6 名、FE 2 名、PM 1 名） Hexabase から MySQL への基盤移行に伴い、170 API のうち約 40 API のリプレースを一人で担当。最も複雑な GET 系 API を含む実装をチーム内最速で完了し、完了後は他メンバーの実装支援も行った。 Tomod's BtoC／処方箋オンライン申請サービス（バックエンドエンジニア） 技術環境：TypeScript、AWS CDK、DynamoDB、API Gateway、Lambda／チーム 3 名（BE 1 名、FE 1 名、PM 1 名） バックエンド唯一の担当者として、ほぼすべての API と AWS インフラを構築。作業を細分化し、納期から逆算して進捗を管理することで、予定より 1 か月前倒しで完了した。 パフォーマンスチューニングでは、DynamoDB への数百件の単一 GetItem により Lambda が約 20 秒でタイムアウトする問題を X-Ray・CloudWatch で特定。データ構造の集約、BatchGetItem、Promise.all の分割により数秒前後まで改善した。 クリーンアーキテクチャで可読性・テスト性を高め、GSI なしの Limit 後フィルタリングには再帰取得で対応した。 Woven by Toyota 社内開発プロセス支援ツール（BE／FE エンジニア） 技術環境：Python（Django）、Nuxt.js（TypeScript）、Docker、AWS Elastic Beanstalk（EB）／チーム 4 名 4 名のアジャイル開発チームで BE／FE を担当。リファクタリングや開発支援ツールの選定などリーダー的役割を担い、PM と開発メンバーの橋渡し、後輩エンジニアのデバッグ支援も行った。 デザイン案が未確定の段階から、フロントエンドのモックを継続的にブラッシュアップしながら、スライダー画面の仕様具体化と実装を並行して進めた。 発注者・デザインチームから提示された要望の業務目的を確認する必要があると考え、要件調整の場を設けることを提案。技術制約や工数を踏まえたスケジュールも提案した。

概要 中古車販売ブランド Gulliver のオウンドメディアリニューアルプロジェクトに参画。年間約 70 万件の顧客申込受付システムをバックエンド主担当として担当。 申込受付 API、CRM 連携、自動返信メール機能の実装に加え、要件整理、非同期処理方式の検討、AWS 基盤構築を担当。要件整理では、業務目的と実装内容の整合性を重視し、レビューにおいても要件漏れや業務フローとの整合性を確認しながら設計検討を実施。必要に応じて、業務理解のための情報整理方法も提案した。 システム全体（月間約 5,000 万リクエスト）の一機能として、複数の設計案を検討し、レビューでの議論を通じて方針を決定したうえで実装を行った。 担当 API 実装／ECS on Fargate 構築／Lambda 実装／SQS 実装／CI/CD 初期構築／要件整理／技術検討 主な取り組み 顧客申込受付システム 年間約 70 万件の申込受付システムを主担当。 申込受付 API／CRM 連携 API／SendGrid による確認メール送信／非同期申込履歴保存を実装。 非同期アーキテクチャの検討 申込受付・CRM 連携・メール送信について複数の非同期方式を検討。 Transactional Outbox パターンを提案し、レビューでは「DB 障害時にも受付を継続すること」を最優先とする業務要件を踏まえて複数案を比較検討。最終的に、DB への登録ではなく SQS への投入成功をもって受付完了と定義し、冪等なコンシューマーが DB へ反映する構成を採用し、実装を担当した。重複配送を前提とした冪等化や DLQ による復旧まで含めて検討し、整合性と可用性のトレードオフを業務要件の観点から整理して判断する経験を得た。 メール送信基盤 SendGrid によるメール送信について、SQS を利用した非同期送信方式を提案。レビューでの検討を経て採用され、実装を担当。 データモデル検討 複雑な申込種別を簡易分類するデータモデルを提案。他指標との整合性を保証できるかを業務側の運用も含めて確認した結果、簡易分類では要件を満たせないことが判明したため、既存マスタ管理方式を採用した。 申込 ID の採番方式検討 申込受付 API では、DB 障害時にも受付を継続するため、DB 保存前かつ SQS 投入前に API 側で ID を発行する必要があった。後続 CRM の 20 文字制約から標準 ULID（26 文字）は使わず、その時系列性を参考に「13 桁のミリ秒タイムスタンプ＋7 桁の Base62 セキュア乱数」の独自 ID を設計・実装。ランダム UUID と比べ、B-tree 上で追加位置が末尾付近にまとまりやすく、ページ分割・断片化を抑える構成とし、冪等処理キーにも利用した。