ネットプレイス マーケティング管理者
2024画面
概要
マーケティングサービス運営（顧客・サービス状況管理）のためのバックオフィスとして進めました。
役割・技術スタック
React 18, NestJS, MySQL
実績 01
顧客サービスから分離した管理者運用チャネルの構築
- 背景・原因
- 顧客申請の確認・処理と、顧客、商品、担当者、状態の管理を行う内部チャネルが必要でした。顧客に見せてはならない運用機能に加え、一般管理者と最高管理者の権限も分ける必要がありました。
- 検討・選択理由
- 管理者機能を顧客画面に条件付きで置かず、別のReactアプリケーションに分離しました。顧客チャネルとデプロイ・露出の境界を分けながら、同じAPI契約は再利用するためです。情報密度の高い運用画面はAnt Designで一貫して構成しました。
- 結果
- 一つの管理者チャネルで顧客、商品、申請業務、担当者の割当、状態変更を処理できるようになりました。一般管理者は運用業務を、最高管理者は管理者アカウントと権限までを管理し、実際の運用環境へもデプロイしました。
- 振り返り
- 顧客チャネルと管理者チャネルはデータ契約を共有できますが、UI、権限、デプロイの境界は分けるべきです。そうすれば一方の変更が他方を不必要に制約しません。
実績 02
繰り返される一覧・検索・フォームの共通構造化
- 背景・原因
- 顧客、商品、申請の管理画面ごとに、一覧、検索、フィルター、ページネーション、登録・編集フォームが繰り返されていました。画面ごとに独立実装すると状態処理がばらつき、新しい画面を追加するたびに同じコードを再び書く必要がありました。
- 検討・選択理由
- 共通のテーブル、検索、フォームコンポーネントを作り、画面ごとの設定とデータだけを渡す構成にしました。検索、ページネーション、API呼び出しの状態をカスタムフックへ分け、UIとデータ処理の責任を分離して画面間の動作を統一しました。
- 結果
- 繰り返される運用UIの操作方法を一貫して保ち、新しい管理画面の追加・変更範囲を減らしました。
- 振り返り
- 管理者画面では、繰り返される一覧、検索、フォームのパターンを先に共通化すべきです。個別ページを急いで増やすより、長期的な変更コストを減らせます。