sosokura

事業内容: 中堅SIer（Web開発）｜東証プライム上場｜従業員数: 1,330名 《QAエンジニア》 海外開発チームとの協業において、英語で基本・詳細設計書の作成、テストケース・チケット作成を実施。API一括検証ツールの実装も行い、QAリーダーへの昇格内示を受けた。 《大手保険会社SOMPO BtoC/SNSサービス｜バックエンドエンジニア》 技術環境: TypeScript（Node.js/Express）, Jest, Docker, Amazon Aurora（MySQL）　チーム10名（インフラ1, BE6, FE2, PM1） Hexabase→MySQLへのインフラ移行に伴い、170個あるAPIのうち40個のリプレースを一人で担当。最も複雑なGET系APIを含む実装を、チーム内最速の進捗で完了させ他メンバーのヘルプにも回った。 《大手薬局tomo's BtoC/処方箋オンライン申請サービス｜バックエンドエンジニア》 技術環境: TypeScript（AWS CDK）, DynamoDB, API Gateway, Lambda　チーム3名（BE1, FE1, PM1） バックエンド唯一の担当者としてほぼ全てのAPI・インフラを構築。作業の細分化と逆算による進捗管理で1ヶ月前倒しで完了。 パフォーマンスチューニング：DynamoDBへの数百件の単一GETによりLambdaが20秒でタイムアウトしていた問題を、X-Ray/CloudWatchで特定。データ構造の集約化・BatchGetItem・Promise.allの分割により5秒前後まで改善。 クリーンアーキテクチャ：による設計で可読性の高いコードを実現し、単体テストを効率的に実施。 DynamoDB設計：GSI未設定時のフィルタリングでlimit指定より後に評価される仕様に対し、再帰処理で所定件数取得を実装。 《Woven by Toyota 社内開発プロセス支援ツール｜BE/FEエンジニア》 技術環境: Python（Django）, Nuxt.js（TypeScript）, Docker, EB チーム4名のうちBE/FEを担当しつつ、リファクタリング・開発支援ツール選定などリーダー的役割を遂行。PMと開発メンバーの橋渡し、後輩エンジニアのフォローも実施。

中古車販売・買取ブランドGulliverのオウンドメディア（月間5000万リクエスト規模）のリニューアルプロジェクト に参画。バックエンド担当として、API設計・実装、ECS on Fargate/Lambda/SQS構成の検討、CI/CDワークフ ロー初期構築を担当。要件整理・関係者調整にも関与し、技術的論点の整理と代替案提案を 行った。 具体的には、申込受付・CRM連携・自動返信に関するバックエンド構成を整理し、障害時の復旧性と運用容 易性を重視した非同期処理基盤の設計方針を策定。複数部門の要件を調整し、マスタ管理と既存IF維持を両 立する変換レイヤを提案した。 【主要な技術的意思決定の詳細】 • 自動返信APIの設計改善：申込受付後の自動返信メール送信について、CMS／Next.jsなどのフロントエ ンド基盤側を経由して処理を呼び出す構成案に対し、以下の問題を指摘。信頼性面では、申込保存とメー ル送信が別操作となり結果整合性が得にくい点、およびフロント側障害時にメール送信も巻き添えで停止 する点。保守性面では、「申込を受けたら返信する」というビジネスロジックの責務がフロントエンド側に漏 れ出し、フロント側にインフラ管理権限がない組織構造とも整合しない点。これらを整理し、バックエンド完 結の非同期構成（SQSによる再処理・DLQ退避を前提とした構成）を提案・採用された。 • データ整合性パターンの選定：申込データ保存・CRM連携・自動返信の3処理における整合性リスクに対 し、Outboxパターン、同期処理、SQS先行の非同期処理を比較検討。OutboxはDB更新とイベント発行の 整合性を担保しやすい一方、DBを受付時の永続化先とするため、DB障害時には申込受付自体が停止す る。今回は「申込情報のロスト回避」と「障害時の受付継続性」を優先し、申込時点で発行したIDを含むイ ベントをSQSに先行投入。後続処理は、Visibility Timeout経過後のメッセージ再処理、 maxReceiveCount=3によるDLQ退避、申込ID単位のステータス管理によるCRM連携・自動返信の重複 処理防止を前提とする構成を選定した。 • 要件定義・複数ステークホルダー間の合意形成：申込データのカテゴリー分類設計（ハードコード vs マス ターテーブル管理）の議論において、関係者ごとの要件を整理。データ分析側にはマスター化のメリット （新仕様追加時のデプロイ不要、組み合わせバリデーション、ID参照による分析容易性）を平易に説明し 合意を獲得。一方マーケ側・後続システムは既存IFの維持を要求したため、メモリキャッシュでマスタとID を相互変換するレイヤを設計し、技術制約とビジネス要件を両立させた。