sahoooii

フロントエンドを軸に、状態設計・UX・整合性まで考えられるエンジニア

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