この記事は何回かにわたって投稿します。
自称「通販プラットフォーマー」を自負する筆者が、これまでやってきた経験からECで通販やるなら
どんなことを知らないといけないのか、を説明していきます。
(この記事は5分で読めます。)
##こんな人に読んでほしい
- 通販サイトを作ってくれ!といわれた
- 通販サイトは使っていても、作ったことはない…
- バックグラウンドも通販分野に携わったことがない
ECを作る分野は経験があっても、モノをアツカウことには未経験という方向けのセクションです。
自称通販プラットフォーマーの経歴
- DMMのエンドユーザー向け通販事業部に4年所属 → 内部のシステム構造を嫌というほど知る
- DMMの法人向け通販事業に2年所属 → はじめて0から通販システムを設計、リリース
過去のバックグラウンドもあって、要件からリリースまでは 1年 でローンチしました。
(これは知ってる人ならなかなかえぐいスピード感です。)
それ以外にも日常的に、
- 商品の入庫出庫データの管理
- 物流側との保守管理
- 新規倉庫とのつなぎこみ
- ECサイトの改善企画
などをやっております。そんな経歴を含めて、通販プラットフォームってほんと奥深いという気づきから、似たようなエンジニアの方に向けて、ノウハウを共有したく、記事を書き始めています。
何はともあれ、通販システムってなんだ
まずは、一般的な通販システムはどういう構成でつながっているかを俯瞰的に説明です。
通常のエンドユーザー⇔買い物ができるサイト から踏み込んで何を作らないといけないか?の全体像です。
エンドユーザーが見る世界から、通販では階層に3ステークホルダーが関わっていること が基本構造です!
そのため、EC側はエンドユーザーとの接点以外に、
- 仕入れ会社とのシステム連携
- 物流倉庫とのシステム連携
- 配送業者とのシステム連携
を配慮する必要があります。
C2Cの場合には、仕入れ会社と物流倉庫が「enduser」になるという感じ。概念は同じです。
めっちゃ時間がかかる工程はどこ?
はっきりいって、EndUserとECサイトは割と簡単です。
一番時間がかかるのは、受注在庫管理を行うシステム(図だと上部の右側) です。
ここのセクションは工期の半分を使うといっても過言ではないです。
プラットフォーマーとして意識したいこと
EndUserがよりサービスを使いやすくするのは当たり前の世界。
でも、通販プラットフォームはそれ以上に、各ステークホルダーとの連携をいかに早く・ランニングコストをかけずに運用できるようにしておくか、を最初の設計から考えておくことをおススメします。
図でいうと、★のところを最初の段階から自動化しておくこと。です。
##自動化とかあったりまえじゃん…
はい、そのとおりです。
でも、なぜここが時間がかかるかというと、とにかく仕入れ会社や物流倉庫のクライアント側は割と老舗的なシステムを使っていることが多い!という状況です。
(APIに対応している、とかもわりと稀)
この連携先とのデータ連携I/Fの仕様の読み解きがかなり難儀 というのが私の経験則になります。
当然、仕入れ業者が複数、倉庫が複数になればそれだけの読み解きと実装コストが上乗せされていくことになります。
そして、重要なことは自動化できるのはデータのみ。
実際には各ステークホルダーごとにオペレーションがあること。
これを理解しないと、システムだけできても全く機能されないものを世に放ってしまうことになります。
もやもやさせといて今回はここまで!
(つらいところだけを伝えて、もやもやさせてしまいましたが)
今回は、まず通販プラットフォームの全体像とどの工程が大変なシーンか、という点のみお届けしました。
次回からは、**「倉庫オペレーション」**にどんなものがあるのか?
業界用語がなかなか難しいので簡単に解説したいと思います。