ID:74933さん

## 概要 ECサイトをHTML,CSSやJavaScriptなどのプログラミング知識がなくても簡単にECサイトを構築し運営できるサービスの新機能提案・開発・運用保守 ## 使用技術 - Nuxt.js(2系及び3系) - TypeScript - HTML - CSS - Bulma(CSS framework) - Spring boot(Java) - JUnit - AWS(ECS,ECR, S3, RDS, CloudFront) - MySQL - WSL2 - Docker - GitHub - GitHub Actions ## チーム構成 メンバー　6~13名（新卒社員含む） - エンジニア　5~10名（新卒社員含む） - チームリーダー・サブリーダー - プロジェクトマネージャー - QA　1名 ## 担当 サービス開発のエンジニア兼サブリーダーとして以下の業務を担当した。 - 管理画面及びお店画面の設計、実装及びテストの実施 - APIの設計、実装及びテストコードの作成 - バッチの設計、実装及びテストコードの作成 - AWSの一部運用 - サブリーダー - サブリーダーとしてチームメンバーへの設計・実装・テストにおける指導、新卒社員に向けた勉強会の提案・実施、タスク管理、他部署との打ち合わせ ### 新機能の提案～リリース **新機能の提案～リリース**に至った機能の一つとして、お店のデザインをAIとのチャットだけで完結できる機能がある。 外部のアドバイザーとの打ち合わせなどもミーティングを重ね仕様を調整しながら、要件定義・デザイン・設計及び実装のすべてを一人で行った。 #### 課題 上記機能の開発に当たり、ユーザーの予期せぬチャット入力によるプロンプトインジェクションやAIから予期せぬ答えが返ってきた際のハンドリング処理などが課題としてあった。 #### 取り組み・工夫点 完全に自由なチャットサービスとするのではなく、サービス側から質問を投げかけユーザーはそれに軽く答えるだけのチャットボットに近い実装にすることでユーザーからの入力に制限を持たせた。 また、AIからの返却値をそのまま返すのではなく、既定の文字形式に変換してから返却する（変換できない形式だった場合はエラーハンドリングを行う）ことでプロンプトインジェクションが起きにくいようにした。 ### Nuxtのリプレイス 当該サービスに携わってから約1年半はNuxt2系＆JavaScriptでフロントエンドの開発を行っていたが、Nuxt2の公式サポートが切れることに合わせてNuxt3にリプレイスするとともにTypeScriptに変更した。 #### 課題 - Nuxt3及びTypeScriptを業務でも個人でも扱ったことのあるメンバーが私を除いて一人もいなかった。 - コード規約が存在はしているものの内容が古くフォーマット化もされていなかったので、リプレイスにあたり一からコードを書き直すのに不十分な内容であった。 - リプレイス前の環境も運用しながらリプレイス用の新しい検証環境の構築をする必要があった。 - テストコードが存在しておらず、リプレイスしながら実装の正しさを保証することが困難であった。 - 重複したコードが多く、8割以上のコードが同じであるコンポーネントなどが複数存在していた。 #### 取り組み・工夫点 この業務における私が担当した内容は以下の通りである。 - 技術選定 - Nuxtのバージョンアップに伴い、開発に使用していたライブラリをすべて再調査し、Nuxt3に対応したライブラリの選定やマイナーなライブラリを信頼性の高いライブラリに変更したり、ライブラリに頼らず独自実装する方針にするなどの意思決定を行った。 - コード規約の作成 - 元々プロジェクトにコード規約自体は存在したが、Nuxt3やTypeScriptに適用したコード規約を再考し作成した。 - 規約区分は、絶対守るべきこと（Must）できるだけ守るべきこと（Should）、できたら守る（Better）の三段階に分けることで運用が曖昧にならぬようにした。 - 「規約を読んでも意味が分からない」ということがないように、規約毎に具体例やサンプルコードを記載した。 - TypeScriptのリード - 開発メンバー全員がTypeScriptの実務経験がなく、個人開発で利用したことがあるのが私のみであったため、TypeScriptに関する知見の共有や勉強会の実施、コードレビューを先導して行った。 - ECSにおける検証環境の立ち上げ - リプレイスにあたってNuxt3専用の検証環境を立ち上げる必要があったため、AWS（ECS,EC2）において環境の立ち上げをすべて一人で行った。 - ESLint・Prettier・Buildの自動実行 - リプレイスにあたり、テストコードを一から導入するのは定められた工数的にほぼ不可能だったため、ESLint・Prettier・BuildをPullRequest時に自動実行するGithub Actionsを構築した。またいずれかに失敗した場合はマージができない設定を施したことで保守性が向上した。 - リファクタリング - リプレイスしながらリファクタリングも可能な限り並行して行った。重複したロジックはcomposableやutilsディレクトリに移動し共通化し、UIコンポーネントは`<slot>`要素を利用することで類似UIコンポーネントの共通化に成功した。（特にモーダルコンポーネントで顕著でした） ### 勉強会の定期開催 毎年プログラミング未経験の新卒社員を採用している中で、教育が十分になされていないと感じていたため勉強会を実施する旨を上長に提案し自ら定期的に勉強会を実施した。 結果的に勉強会の習慣は、チーム内だけでなく部内全体に広がっている。

## 概要 Netflixのマイリストよりも細かく分類できる独自のお気に入りリストを作成できるChrome拡張の個人開発を行った。 ## 担当 全て一人で開発 ## 開発した理由 当時日常的にNetflixを利用している中で、いつか見たいと思った映画やアニメをマイリストに保存していた。そうしている内にいつの間にかマイリストの数が多くなりすぎてしまい、見たい映画をすぐに見つけ出すことができずストレスに感じた。 このストレスを感じている人は他にもきっといると思ったため、以下の機能を有する独自のお気に入りリストを作って公開すれば需要があると思い開発した。 1. カテゴリを自由に作成できる 2. 作成したカテゴリにNetflix内の作品を自由に登録することができる。 3. 登録したお気に入りリストはサイドバーで確認（表示）できる。 ## 取り組んだ課題 ### Netflixのレンダリングを監視する 「作成したカテゴリにNetflix内の作品を自由に登録」が簡単にできるようにするためには、作品情報のモーダル内に独自のボタンを配置する必要があった。 この動作を実現するためには、モーダルがレンダリングされるごとにボタンを埋め込む必要があったため、「MutationObserver インターフェイス」を使いDOMの変更を監視するアプローチで実装した。 ### NetflixのUIに合わせること Netflix内で利用できる拡張機能であることから、UIが浮いていては使い勝手及び心象に悪いと考えたため、Netflix固有のCSSを使うことや同様なコンポーネントを実装することで、Netflixに馴染ませることに成功した。