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に馴染ませることに成功した。

# プロジェクト概要 人材紹介事業の基幹業務システムを Rails + Vue から Next.js (App Router) + Salesforce 直結構成へフルリプレイスするプロジェクト。 共通UIコンポーネント基盤と、バックエンド3層アーキテクチャの実装を担当し、フロントエンドの設計を行いました。画面単位でAPI設計〜フロント実装まで縦に通すスタイルで担当しています。 # チーム情報 【エンジニア4名、PdM1名、EM1名、デザイナー2名（PdM兼任】 # 開発・実装内容A：Salesforce APIコール上限リスクの解消（個人主導） 【概要】 Salesforce の APIコール上限（14万回/日）に対し、想定利用では大幅超過＝業務停止という「プロジェクト全体を止めうるリスク」を、定量化から実装・着地まで一人で主導しました。 【課題・問題点】 - 画面表示のたびに SOQL を発行する構造のため、負荷テストからの外挿で日次７０万コールと試算。初期見積もり段階で、経営層でも懸念事項になっていた 【打ち手・使用した技術】 - 現行システムの本番実測ログ（Datadog・アクセスログ）と新実装コードを突き合わせてAPI係数を算出し、「必要ヒット率」と「削減余地（約2万コール/日）」を定量化。前提の抜けは自ら開示して再計算し、意思決定に耐える精度の見積もりに引き上げた - Redis キャッシュ機構を設計・導入。Apexトリガー＋Webhookによる非同期破棄案は「refetch時に古い値を返しUXを損なう」ため自ら棄却し、更新API内で同期的にキャッシュ破棄する方式を採用。トレードオフ（破棄漏れリスク）を明示した確定版設計ドキュメントを整備 - 読み取り系API全域へのキャッシュ適用と更新API全域への破棄処理を単独で完遂。高頻度画面はTTLベースからキャッシュタグベースへ戦略を再設計 - Composite API による SOQL 集約をADRで採用主導し、実測に基づく優先度分析から呼び出し頻度上位のエンドポイントを集約実装 - キャッシュ構成・データフロー図を作成し、CTOの意思決定に技術判断を接続 【成果】 - 業務時間中の平均キャッシュヒット率 約65%、APIコール 約13万/日 を達成し、要件上の最大想定（17万/日）の内側に着地。事業継続リスクを解消 - キャッシュキー命名規則・実装パターン・破棄フローをドキュメントと共通実装に落とし、他メンバーが同品質で拡張できる状態にした # 開発・実装内容B：求人クローリング基盤の構造改善 【概要】 外部ATS 8サービスから求人情報を取得し Salesforce に反映する日次バッチが、クラッシュによる未完走と「取得失敗を0件と誤認して案件を大量削除する」構造的リスクを抱えていました。止血→調査→根治→再発防止の順で構造から改善。 【課題・問題点】 - ブラウザ自動操作（Selenium）依存でクラッシュが頻発し、失敗がログに出ず検知できない状態だった - 過去に大規模誤削除インシデントの前例があり、「削除を止めれば安全だが情報が古びる／通せば事故る」というトレードオフが未決着だった 【打ち手・使用した技術】 - クラッシュ位置の実測に基づくチャンクサイズ調整と、バッチ単位の例外分離（失敗バッチはRollbar通知して次へ続行）でクラッシュ後も自動復帰する構成に変更 - 対象サービスの通信を実地調査し、ブラウザ操作を伴わない軽量HTTP取得方式へ移行。HTTPステータスで「取得失敗」と「正当な0件」を判別可能にし、誤削除の構造的原因そのものを排除。既存のデータ連携側は無改修で済むようインターフェースを完全互換に維持 - 企業単位の削除率による異常検知（CRITICAL/WARNING）と、クロール停止自体を検知する仕組みを実装。冪等・ATS非依存の復元バッチをセットで用意し、「削除は通して即検知・即復元」への方針転換をADRで合意形成。通知チャンネル分離や重要度別メンションなど運用者視点の通知設計まで実施 【成果】 - クロール所要時間 約7時間 → 約1.4時間 - 誤削除と同型の事故を構造的に防止し、検知〜復元までの運用を仕組み化。障害対応を「止血→根治→先回り」の再現可能な型として実践 # 開発・実装内容C：設計プロセスの主導（ADR文化の定着） 【概要】 技術選定・設計判断を ADR として明文化し合意形成する開発文化を推進しました。 https://tech.forstartups.com/entry/2025/03/24/080000 【打ち手】 - ADRを自ら起票し合意まで主導（Composite API採用 / ORM導入の見送り / URL状態管理ライブラリ選定 / 権限剥奪時の不正アクセス防止設計 / キャッシュアーキテクチャ 等）。「採用」だけでなく「見送る」「一度合意した設計を自ら撤回する」判断も記録に残す運用を実践 - ADR運用開始から半年の節目に振り返りアンケートを自ら設計・実施し、単発の文書化ではなく制度として定着させた - SOQLインジェクション対策として安全なクエリビルダーを共通関数化するなど、セキュリティ設計も担当（React/Next.jsのCVE対応も含む）

# プロジェクト概要 ドーパミンコンテンツ時代、自らスマホの利用を道場の精神で断とうというだけのコンセプトのiOSアプリを、市場調査・要件定義・デザイン・実装・ストア申請まで一人で完遂しリリース。 企画から実装まで全工程をAIエージェント前提のワークフローとして設計した、AIネイティブな個人開発です。 [Apple Storeリンク](https://apps.apple.com/jp/app/%E9%80%80%E5%B1%88%E9%81%93%E5%A0%B4-%E3%83%89%E3%83%BC%E3%83%91%E3%83%9F%E3%83%B3%E4%B8%AD%E6%AF%92%E3%82%92%E8%A7%A3%E6%B6%88-%E4%BD%95%E3%82%82%E3%81%97%E3%81%AA%E3%81%84%E3%82%92%E7%B6%99%E7%B6%9A%E3%81%99%E3%82%8B/id6763999603) # チーム情報 企画からリリースまで全工程を個人で担当。 # 開発・実装内容 【概要】 Expo (React Native) + TypeScript + Zustand + expo-sqlite 構成のオフラインファーストなiOSアプリ。ビルド・配信は EAS Build で自動化。 【開発プロセス：AIネイティブなワークフロー設計】 - 要件定義：競合調査を踏まえ、Claude との壁打ちで仕様を詰めて800行超の要件定義書に構造化。実装前に判断基準を固め、個人開発にありがちな仕様の迷走を防止 - デザインシステム先行：画面デザインに入る前に Claude design でデザインシステムを構築。和のモチーフ（墨黒・生成り・朱のパレット、明朝体、円相）をトークン化し、「稽古」「型」「段位」などドメイン用語を含む世界観の一貫性を先に担保 - デザイン：各画面のデザインも Claude design で作成し、全画面分のモックとして固めてから実装工程へ - 実装：要件定義書とデザインシステムをコンテキストとして Claude Code に供給し実装を推進。「上流ドキュメントの質がエージェントの実装品質を決める」という業務でのAI駆動開発の知見を、0→1の個人開発で実証 【課題・問題点と打ち手】 - 「習慣化アプリなのにプッシュ通知で気を散らせては本末転倒」というプロダクト矛盾に対し、あえてプッシュ再訪促進を実装しない意思決定を行い、オーガニック導線（X・ブログ）に振り切ったグロース設計を採用 【成果】 - App Store にリリースし運用中 - 要件定義→デザインシステム→デザイン→実装のAIネイティブな開発プロセスを個人で一気通貫に運用できることを証明 - 業務のtRPCとは異なる技術選定（ローカルファースト構成）を意図的に行い、技術の引き出しを拡張