ネットプレイス マーケティングサービス
2024画面
概要
地域マーケティングサービスのオンライン窓口を構築するために進めました。
役割・技術スタック
React 18, NestJS, MySQL, Docker Compose
実績 01
手作業の申請フローを24時間オンラインサービスへ移行
- 背景・原因
- マーケティング商品の案内と申請は、担当者への問い合わせと手作業で処理していました。情報の漏れや重複のリスクがあり、運用者は申請内容を繰り返し入力していました。顧客との処理状況の共有も難しく、申請可能な時間は営業時間に限られていました。
- 検討・選択理由
- 顧客画面と業務APIをReactとNestJSで分け、独立した開発・デプロイ境界を作りました。管理者チャネルも同じAPIとデータ契約を再利用するように構成しました。画面変更が業務規則へ直接影響せず、顧客・管理者チャネルで申請データを重複実装しないためです。
- 結果
- 顧客が時間に関係なく会員登録・ログイン後に商品を閲覧し、サービスを申請できるようになりました。申請情報は一貫した形式で保存され、漏れ、重複、運用者の繰り返し入力を減らし、両チャネルが同じ申請データを共有しています。
- 振り返り
- オンライン化は画面を作るだけでは終わりません。漏れと重複を防ぐデータ構造を先に定め、顧客申請と運用処理を一つの流れにつなぐ必要があります。
実績 02
JWTによる顧客・管理者の権限境界の分離
- 背景・原因
- 顧客と管理者が同じAPIを使うため、ログイン済みかどうかだけでは内部運用機能とデータアクセス範囲を安全に区別できませんでした。
- 検討・選択理由
- 顧客・管理者の認証経路を分け、APIにロールベースのアクセス制御を適用しました。JWTはHttpOnly Cookieで渡し、ブラウザースクリプトがトークンへ直接アクセスできないようにしました。それでも両チャネルは同じ認証契約を使えます。
- 結果
- 顧客と管理者が同じ業務APIを再利用しながらも、それぞれの役割に許可された機能だけにアクセスする境界を分離しました。
- 振り返り
- 認証ではログイン成功より先に、ユーザー種別ごとの権限とデータアクセスの境界を設計すべきです。