受注処理・バックエンド
マルチチャネル受注パイプライン
担当
要件定義・設計から実装・運用まで(上流〜下流一気通貫 / 2名体制のメイン開発)
期間
2026
使用技術

※ 実際の管理画面は前職の著作権・機密保持規定により掲載不可。機能を再現したモックアップ(ダミーデータ・匿名化)に置き換え。
概要
複数のマーケットプレイスで販売する事業者。担当者がチャネルごとの管理サイトに個別ログインして注文を落とし、手作業で整えていた状態。設計で最初に決めたのは「全部を1つに統一する」ことではなく、共通化の境界を一度だけ引くこと。共通であるべき方針(Policy)、コアに骨格を置き差分はアダプターで注入する仕組み(Mechanism)、あえて統一しない拡張点(Adapter)の3層に分離。チャネルごとに異なるAPI・認証・データ形式を1つの処理へ吸収。非開発の商品企画チームと定期的に打ち合わせ、要件定義・仕様のドキュメント化という上流工程から、実装・運用という下流工程まで一気通貫で担当。属人化していた手作業を仕組みに落とし込み。
担当業務
- 01
韓国の主要ECモール(ABLY・ZIGZAG・NAVERスマートストア)のオープンAPIを自ら発行・連携。プラットフォームごとに異なる提携申請・審査のプロセスを、開発以前の段階から自ら対応。チャネル別の認証方式とレスポンススキーマを共通コア(collector-registry)背後のアダプターで吸収し、API連携とExcelアップロードの2経路を単一の注文フォーマットに統一。運用では25万件以上の注文明細を処理。
- 02
マーケットAPIの仕様変更に対応する failed_import テーブルを設計。収集に失敗した明細を元のペイロードごと自動で退避し、どのチャネルが何で壊れたかを即座に特定。自動リトライで流さず、担当者が1件ずつ判断して処理する構成。
- 03
合流発送(同一顧客の注文をまとめる)・注文分割(1リスティングに複数商品)・誤発注などの例外を信頼度で判別し、高信頼のみ自動処理、曖昧なものはレビュー用キューへ振り分け。
- 04
完全性ゲートは、アダプターが取りこぼしを正直に返せる場合だけ fail-closed を保証すると契約として明文化。「コアを入れたから安全になった」とは報告せず、過去に起きた注文のサイレント欠落を根本原因から遮断。
成果
チャネルを行き来する手作業を、境界を意識した共通コアの上で例外まで捌く自動パイプラインへ置き換え、担当者の工数を大きく削減。