自社仕入れサイトとAmazon間の在庫連携に利用していたRPAを、 APIベースのWebアプリへ移行するプロジェクトです。

従来は、自社仕入れサイトからCSVをダウンロードし、 ローカルPCを介してAmazonへ連携する仕組みでした。 そのため処理中はPCを起動し続ける必要があり、 Amazon側の仕様変更によって処理が停止すると、 その都度手動での対応も発生していました。

そこで、「PC起動不要・エラーゼロ」を目標に、 SaaS上で処理を自動化する仕組みへの移行を行いました。

Webアプリの画面を設計する前に、既存のRPAがユーザーと運用チームにどのような問題を生んでいるのかを整理しました。

主なターゲットは、本業を持ちながら限られたスキマ時間で ECを運営する20〜50代の副業ユーザーです。

運用に割ける時間が少なく、デジタルツールへの習熟度も必ずしも高くないことから、
多機能な管理ツールではなく、「簡単で、ミスが起きにくく、安心して任せられるシステム」が必要だと整理しました。

Webアプリの設計に先立ち、在庫管理サービスのzaicoとSANKAを調査しました。 主な機能、サポート体制、カラー、タイポグラフィ、画面構成を比較し、 在庫管理サービスで一般的に用いられる機能やUI要素を整理しました。

お知らせ、お問い合わせ、ガイド、インポート・エクスポート、 ログイン、ユーザー情報、在庫一覧、商品詳細、商品登録などの共通要素を抽出しました。

次に、プロダクト全体の情報設計を行いました。
在庫管理ツールは機能追加によって複雑になりやすいため、必要な機能を整理し、メインメニュー、在庫連携、在庫一覧、ユーザー設定、API連携設定、問い合わせ、エラー画面など、全16画面に整理しました。

管理ツールでは、多階層のサイドナビゲーションもよく使われます。
しかし今回のプロダクトは、ユーザーが利用する主要機能が比較的絞られていました。

そこで、多層的なサイドバーではなく、 主要機能へ直接アクセスできるフラットなヘッダーナビゲーションを採用しました。

在庫情報を登録・更新するCSVアップロードは、ユーザーが日常業務で最も頻繁に利用するコア機能です。
そのためこの画面では機能を増やすのではなく、「ファイルを指定する → アップロードする」という主目的が一目で理解できることを重視しました。
ファイルアップロード領域を広く取り、ドラッグ＆ドロップでも操作できるようにしています。
また、次に行うべき操作が視覚的に分かるよう、主要なアクションボタンの優先順位を明確にしました。

CSVアップロード後の確認画面では、仕様書上、注意事項がアクションボタンの下に配置されていました。
しかし、この画面ではデータの登録・更新など、結果に影響する操作を行います。
ユーザーが注意事項を読む前に目立つボタンを押してしまう可能性を考え、デザインでは注意事項をボタンの上へ移動しました。

上から下へ情報を読む流れの中で、リスクや注意点を確認してからアクションへ到達できるようにすることで、意図しないデータの上書きや削除を防ぐことを狙いました。

旧システムでは、エラーの発生とその対応自体がユーザー・サポート双方の負担になっていました。
そのためWebアプリでも、エラー画面を単に「エラーが発生しました」と知らせるだけの画面にはしないようにしました。
予期しない問題に直面したときでも、ユーザー自身が状況を理解し、次の行動を選べる構造にしました。

このプロジェクトは当初ベータ版として位置づけられており、事業部からは制作工数に対する懸念もありました。
一方で、今後の機能追加や運用も想定されていたため、短期的に画面を完成させるだけではなく、
あとから変更・追加しやすい状態をつくることも重要だと考えました。

色、タイポグラフィ、余白などの基本ルールを定義し、ボタンやフォームなどのUI要素をコンポーネント化しました。
これにより画面ごとのUIのブレを抑えながら、 機能追加時にも既存ルールを再利用できるようにしています。

フロントエンドでは、 BEM / Component指向のCSS構造を採用しました。

カスケードによるスタイルの衝突を抑えながら、Figmaで定義したUIと対応させ、再利用・保守しやすい構造を目指しました。

Figmaで設計したUIは、HTML / CSS / JavaScriptを使って自身でフロントエンド実装まで担当しました。
開発にあたっては、エンジニアに用意してもらったDocker環境を自身のローカルに構築し、
プロジェクトの開発環境上で実装を行いました。
また、Git / STGの運用に沿って開発連携を行い、環境構築や運用の中で必要となる情報をドキュメントとして整理しました。