PROJECT
ECプラットフォーム開発
機能設計 / フロントエンド / バックエンド / 運用改善
カテゴリに特化したECサイトを複数展開できるECプラットフォームの開発に、長期インターンとして参加しました。
履歴確認工数
約90時間
/ 月の削減
開発チーム
約10名
エンジニア4名 / ビジネス6名
担当領域
Full Stack
設計・フロント・バックエンド・運用改善
Project Overview
プロジェクトの概要と、自分が担当した領域です。
「デニムスカート専門」「花柄ワンピース専門」といったカテゴリ特化型のECサイトを複数展開できるプラットフォームです。自社でのEC運営だけでなく、他社へのプラットフォーム提供も行われています。私は管理画面のUI改善から開発に参加し、徐々にエディター機能、Slack通知、履歴管理機能など、フロントエンドからバックエンドまで担当範囲を広げました。
開発体制：約10名（エンジニア4名 / ビジネスサイド6名）
担当したこと
- 管理画面・UIの改善
- RichTextEditorの開発・改善
- Slackエラー通知機能の改善
- 商品・記事情報の履歴管理機能の設計・実装
- 既存機能の不具合調査・改善
Tech Stack
Main Work 01
商品・記事情報の履歴管理機能
エンジニアに依存していた履歴確認業務を見直し、運営担当者自身がGoogleスプレッドシートから過去の情報を確認できる仕組みを設計・実装しました。
背景
商品情報や記事情報に誤った変更が行われた際、過去の状態を確認するためにエンジニアが本番環境のデータベースを直接確認する必要がありました。確認依頼が継続的に発生しており、月あたり約90時間相当のエンジニア工数が履歴確認に使われていました。
発生していた問題
- 運営担当者だけでは過去の情報を確認できない
- エンジニアの対応を待つ必要があり、確認までに時間がかかる
- 履歴確認のためにエンジニアが他の開発を中断する必要がある
- 本番DBを直接扱うため、操作ミスによるデータ破損のリスクがある
課題整理・設計
まずECサイト運営担当者とエンジニアの双方にヒアリングを行い、誰がどのような場面で履歴を必要としているのかを整理しました。その上で、開発工数や運用方法、検索性、長期利用のしやすさを考慮しながら複数の実現方法を比較しました。
解決方法の比較
Slack / Discordへの変更通知
不採用リアルタイムで変更を通知できる一方、通知が流れてしまい、過去の特定時点の情報を探して確認する用途には適していないため。
履歴専用DB + 管理画面
今回は不採用拡張性は高いものの、DB設計から管理画面まで新規開発する必要があり、スタートアップの限られた開発リソースに対して工数が大きいため。
Googleスプレッドシート
採用比較的短期間で実装でき、非エンジニアでも操作しやすく、履歴を後から参照するという目的を必要十分に満たせるため。
DESIGN DECISION
なぜ「1日1回のスナップショット」にしたのか
商品情報は頻繁に変更されるものではなかったため、すべての変更をリアルタイムで記録するのではなく、1日1回スナップショットを保存する方式を採用しました。必要な履歴を残しながら、実装・運用コストを抑えることを意識した設計です。
実装
Ruby on RailsのActive Recordを利用して商品・記事情報を取得し、Google Drive APIと連携してGoogle Drive上へ自動保存する処理を実装しました。年・月・日単位でフォルダを生成し、その日のスナップショットをGoogleスプレッドシートとして保存する構成にしています。
STEP 1
Rails / Active Record
STEP 2
商品・記事情報を取得
STEP 3
Google Drive API
STEP 4
日付フォルダを生成
STEP 5
スプレッドシートへ保存
苦労した点
- 初めてGoogle Cloud・Google APIを利用したため、認証設定やAPIの仕様理解に時間がかかった
- スプレッドシートが作成されない問題が発生し、ログを追加しながら処理を一つずつ切り分けた
- 技術的に理想的な構成ではなく、会社のフェーズや開発工数まで含めて要件を決める必要があった
RESULT
約90時間
月あたりの確認工数削減
- 運営担当者自身で過去の商品・記事情報を確認できるようになった
- エンジニアが本番DBを直接確認する作業を削減した
- 月あたり約90時間相当の確認工数削減につながった
- 履歴確認のために他の開発作業を中断する必要が減った
Main Work 02
RichTextEditorの開発・改善
商品説明などを編集する管理画面の入力環境を、textareaからMonaco Editorを利用したRichTextEditorへ改善しました。
背景・課題
従来の入力欄では、コピー＆ペースト時に目に見えない特殊な空白文字が混入して表示崩れが発生するほか、HTMLなどの構文ミスを保存前に発見しづらい問題がありました。
実装した機能
- Monaco Editorの導入
- Markdown編集への対応
- Markdown内HTMLの構文チェック
- JavaScriptの構文チェック
- CSSの構文チェック
- 構文エラー箇所のエディター上への表示
- 特殊な空白文字の検知・半角スペースへの正規化
- Markdown入力用ツールバーの実装
- 太字・斜体などのショートカットキーの実装
- 画像挿入機能
- 保存直前の構文チェック
TECHNICAL ISSUE
バリデーションによる処理負荷
当初は入力内容が変化するたびに構文チェックを実行していましたが、検証処理が何度も走ることでエディターの動作が重くなり、実用的に操作できない問題が発生しました。
SOLUTION
debounceによる検証タイミングの最適化
入力のたびに検証するのではなく、入力が一定時間止まったタイミングで検証を実行するdebounce方式へ変更しました。また、Markdownについては必要なHTML部分のみを検証することで、処理回数と検証対象を減らしました。さらに保存時には最新の入力内容を即時検証し、構文エラーが残った状態で保存されないようにしました。
VALIDATION
構文エラーを入力中に可視化
HTMLなどに構文エラーがある場合は、 Monaco Editor上の該当箇所へエラー表示を行い、 エディター下部にもエラー内容を表示します。 これにより、保存後に画面崩れへ気づくのではなく、 編集中の段階で問題を確認できるようにしました。
この実装から学んだこと
- 外部コンポーネントの仕様を理解して既存システムへ組み込む方法
- 非同期処理やdebounceを考慮したUI設計
- バリデーションと画面表示の責務を整理する重要性
- コード量が増えた際に責務を分けて整理する必要性
Main Work 03
Slackエラー通知機能の改善
本番運用時のエラー通知を見やすく整理し、Slackからすぐに原因調査へ移れる通知方式へ改善しました。
背景
500エラーや決済エラーなどの通知に長いバックトレースがそのまま含まれており、Slackチャンネル上で重要な情報を確認しづらい状態になっていました。
対応した通知
- 500エラー通知
- 決済エラー通知
- メール送信エラー通知
- 未キャプチャ決済通知
- お問い合わせ通知
- 通知処理の共通化
通知構成
親メッセージ
エラー概要
スレッド
Backtrace / 詳細情報
工夫した点
- 親メッセージにはエラー概要のみを表示し、詳細なバックトレースはスレッドへ分離
- WebhookではなくSlack Bot APIを利用してスレッド投稿へ対応
- 長文のバックトレースを複数メッセージへ自動分割
- 可能な限り改行位置で分割し、ログの可読性を維持
- 「[1/3]」のように分割されたメッセージの現在位置を表示
- Slack APIへの送信失敗によってRails側の主要処理が停止しないよう例外処理を追加
VERIFICATION
動作検証
Rails consoleで各通知処理を個別に確認したほか、開発環境で実際の決済フローを実行し、成功・失敗時の通知、長文分割、エラーログなどを繰り返し確認しました。
Main Work 04
EC管理画面・UI改善
開発参加当初は管理画面を中心に、日常的に利用する画面の見やすさ・操作性を改善しました。
余白やレイアウトの調整
画像サイズの統一
色・デザインの調整
トグルUIの実装
表示情報の整理
複数ECサイトでの表示確認
その他の改善
主要機能以外にも、既存システムの運用性・品質を改善する開発を継続して行いました。
CSVインポート機能の改善
商品情報を一括登録するCSVインポートについて複数の入力パターンを検証し、Boolean値などが正しく反映されないケースを修正しました。
SEO向け文字数チェック
Metaタイトル・descriptionの文字数を評価し、短い・適切・長いといった状態を管理画面上で確認できる機能を実装しました。
Google Analytics設定
複数のECサイトに対してGoogle Analyticsの設定を行い、運用環境を整備しました。
既存機能の動作検証・不具合修正
パンくずリスト、商品情報のインポート、表示条件などをECサイトごとに確認し、不整合や誤動作を調査・修正しました。
開発を通して学んだこと
この開発に参加した当初は、依頼された機能を正しく実装することが エンジニアの役割だと考えていました。 しかし実際のサービス開発では、 「誰が使うのか」「何に困っているのか」 「どこまで解決する必要があるのか」 「作った後にどう運用されるのか」 まで考える必要があることを学びました。
- 機能を実装する前に、誰のどの課題を解決するのかを明確にすること
- 技術的に高機能な方法が、必ずしも事業にとって最適とは限らないこと
- 開発工数・会社のフェーズ・運用方法まで含めて設計すること
- エラー発生時はログを追加し、処理を一つずつ切り分けて原因を特定すること
- 実装だけでなく、検証・運用・保守まで含めて考えること