sahoooii

ユーザー体験とデータ整合性を両立できるエンジニア

## なぜそう考えるのか ハワイのアパレルストアで約5年間、アシスタントセールスマネージャーとして働いていました。 多国籍のお客様と接する中で強く感じたのは、 「**同じ商品でも、誰に・どう見せるかで体験がまったく変わる」** ということです。 商品の配置、導線、声をかけるタイミングによって、 お客様の行動や満足度が変わる経験を多くしてきました。 この経験から、エンジニアとしても 「どう実装するか」だけでなく、 **「ユーザーにどう体験してほしいか」から逆算して設計する** という視点を大切にしています。 個人開発でも、 - WebSocketを採用しない判断（UXと運用コストのバランス） - カートと注文で状態管理を分離する設計 - トランザクション導入による整合性改善 など、実装だけでなく「なぜその構成にするのか」を意識して改善を重ねてきました。 単に機能を作るだけでなく、 **設計の意図や判断理由まで言語化しながら改善を重ねてきました。** --- ## 現在強みとしていること フロントエンドを主軸に、API設計・DB設計・状態管理まで一貫して担当できること。 **① 技術選定とトレードオフ整理** 「新しい技術だから使う」ではなく、 **その機能に本当に必要か** を基準に判断することを重視しています。 例えばチャット機能では、 リアルタイム通信を導入することも可能でしたが、 補助機能であること・運用コスト・構成の複雑性を踏まえ、 Server Actions を用いたシンプルな構成を選択しました。 技術を増やすことよりも、 要件に対して適切な構成を選ぶことを意識しています。 --- **② 状態設計・整合性設計** 複数ユーザーや外部サービスが関わる機能では、 「どの状態を正とするか」を明確に定義することを重視しています。 個人開発では、 - MongoDBトランザクション - 状態ごとの責務分離 - 補償処理を前提にした設計 - UIとAPIの責務分離 などを通して、 「**動く」だけでなく「破綻しない」** 構成を意識して実装してきました。 --- **③ UXを起点にした改善** UI上の違和感を、 単なる見た目の問題として終わらせず、 APIやデータ構造まで含めて原因を考えるようにしています。 - Skeleton UIによる体感速度改善 - 表示条件をDBクエリ側で整理したマッチングロジック - APIレスポンス整形によるUI責務分離 など、UX改善を設計レベルから行ってきました。 --- **④ 判断理由を共有すること** 冒頭で触れたハワイでの経験は、 **開発における判断理由の共有** にも活きています。 **「何をするか」だけでなく、 「なぜそうするのか」「どんな体験を目指すのか」** まで共有することが、チームの動きやすさにつながると学びました。 現在の開発でも、 設計判断の背景やトレードオフを言語化し、共有できる状態を意識しています。 --- ## やりたいこと 直近では、 **1つの機能において設計〜実装〜改善まで一貫して任せてもらえること。** UIの課題をデータ構造やAPI設計まで含めて解決する、という動き方がしたいです。 フロントエンドの実装だけでなく、その裏側の状態設計・API設計まで踏み込んで 改善できるエンジニアとしてチームに貢献したいと考えています。 長期的には、 **ユーザー行動・UX上の違和感・運用時の課題を起点に、 UIだけでなくデータ構造や設計まで含めて改善サイクルを回せるエンジニア** を目指しています。 「実装する人」だけではなく、 **なぜその設計が必要なのかを整理し、チームで共有できるエンジニア** として価値を出していきたいです。