これからの、Eコマースシステムについて、SaaSの可能性というより、レガシー基幹システムからの脱却のためも
本記事は、30億超えを目指すD2Cブランド
30億円超えの、レガシー通販企業が、基幹システムをリプレイスするため
をメインのターゲットにしていますが、これからのコマースビジネス（デジタル・リアル・オムニ）の基本的なシステム要件の考えかたを示しています。
D2C・サイトは、2020年のパンデミックで参入ブームとなり、現在（2021年時点）は、参入された、事業拡大、ピボットされた事業者がどうなっているのか興味津々です。
テクノロジーの進化のお陰で、事業者にとっては、身近なサービスで、シンプルで、簡単で、運用費用も比較的簡便にスタートできる環境が整っていてとても素晴らしいことだと捉えています。
個人事業主から、町のパパママストアーから、飲食、小売形態の事業者から、そして、製造・流通ビジネスをそれなりに展開していて、Eコマースビジネスとしての拡大を考えて参入された事業者など、それぞれについての参入目的や、目標とされるKPIやターム（スケジュール）はマチマチではあります。
事業規模を大きくしないで（ここでは、年商10億円を１つのボーダーラインとします。）、事業の運用を目的とするのであれば、システム仕様での差異はそれほど大きくはありせん。
一方で、それを超えていく、超えて行こうとしている事業にとっての、その検討範囲はとても広く、複雑なものになります。
ECビジネスを始める方法たくさんあります。
＊モールへの出店
＊オリジナルドメインでの展開（自社Eコマースと一般的には表現されています。）
＊既存ビジネスとの連携での、オムニチャネルでの展開（目指しても含む）
など
自社の目的を最大限達成するために最適なものを選択することが重要なポイントであることは、各システム提供会社からも提言されていますのでそちらを参考にしてください。
本記事では、Ｄ２Ｃ・Ｅコマース事業者の皆様にとって、システム選定のための視点について事業者視点から選択のお役に立てるような情報提供をさせていただきたく思っています。
＊5億円システムを構築したり、提案していましたので、０円から100億超えまでの事業者様の要件はフォローアップしています。
事業者にとって、システム選定は、要件定義が重要 って、ちょっとマッテ！
お問い合わせをいただいていたり、ご相談いただく多くの事業者が、世の中に溢れる多くのシステムを選択肢せざるを得ないうち、どれが自社に合うか迷われています。
→自社に合うって何？は、追々事例（しくじり）と共にご共有します。
システムの提供形態から言えば、
•SaaSとパッケージ、どっちがよいか
•パッケージとフルスクラッチ、どっちがよいか
開発方法などで言えば
・アジャイル型開発でスピード優先か、
・ウオーターフォール型開発でしっかり進めるか
背景には、
・機能数（これが充実しているからって、TCOが安いわけではないのですが）
・初期費用（見積）・カスタマイズ費用・オプション追加費用・月額固定・従量課金・保守費用などのコスト比較
どのサービスを選択するかについて、機能仕様面では、〇×をつけても差や、特徴が見えないという検討課題・問題を引きずっています。
大儀名分として
「自社のビジネス上最適なビジネス基盤の構築・運用アプローチはどれだ」
がまかり通っています。
私たちはそうした、事業者様とのご相談や、相互研鑽会・勉強会で、疑問や課題、困難な壁について、事業者同士で知恵と経験を出し合うだけではなく、プロセスを共有することで、次の自社の課題として、乗り越える「Ｔｏｂｅ」を、設計して解決していただきたくお手伝いしてきました。
さて、ここまででみなさんお気づきのことはありませんでしょうか？
そう、そうなのです。
顧客のことを一切考えていないのです。事業目標＝売上 だけなのです。
事業とは、顧客があって初めて成り立ちます。
・経営者からは
今年の、Ｅコマースの事業運用はこれくらいだから、５年先は、50％アップで50億から80億円にする。年率８％の成長を目指す。
運用では、
・マーケティング部門からは、この課題（工数＝費用を減らす視点）
・カスタマー部門からは、この課題（顧客情報が散逸しているから、システムを統一）
・フルフィルメント部門からは、この課題（作業工数を削減したいから、自動化してほしい）
・ＭＤ部門からは、この課題（昨年はどの商品が売れたっけ？ 今年はどうするが見えない）
・ＣＲＭ部門からは、この課題（顧客分析、施策シミュレーションをモット簡単にしたい）
・経営からは、追い打ちで安くしろ
などの、機能要件が現状ベース「As Is」でEXCELシートに記載されて提示されてきます。
この、裏に隠れている、
「顧客の購買体験・顧客の購買動機・顧客のUI・そもそも顧客って５年後どうなっているのか」
が、全く語られていないのです。
これが無いままに、売上目標と、実装したい機能（当面の業務コスト削減だけ）を羅列して、システム費用と、コストだけを比較して、高いの安いの、出来るの、出来ないのを検討してもどうしようもありません。
であれば、システムを変更する必要はなく、そのまま運用することをお勧めしています。
（銀行や、自治体と一緒で良いのでは。・・・と）
わたしたちは、事業戦略って大げさなことではなく（戦略・戦術って言葉を使う、コンサルタントやシステムベンダーは要注意です。）、御社にとっての顧客ってどうなのですか？ その顧客の期待に添う、MDと、それをお伝えする、CRMコミュニケーションと、そこから産まれる、オーディエンスを描いてください。
と、とことん向き合ってお話します。それがあってはじめて
•デジタル活用した、顧客体験の提供のための、フロントサイドの構築運用ノウハウ
•それを支える、バックオフィス業務設計（データ連携がとても重要）
•システム化に頼らない、外だし化として、AIや、RPAを活用した省力化ノウハウ（→これは、しっかりとワークフローを確認して運用設計しないと、ブラックボックス化してしまい、後々の業務コスト＝改善が出来ない＝コストの肥大化につながるので注意ください。）
•事業基幹業務改善（効率化はその結果です）ノウハウ
ワークフローそのままで、システム化しても真の効率化にはなりません。
をご提供してきました。
この経験から、まずは自社の顧客にとって価値を提供できる、コマース（これは、デジタル：Eも、リアル：Rも含めて）の環境についてご案内していきます。
参入がとても簡易なモール型での展開について
モールか、自社ドメイン Eコマースか の前に
モール型ECサイトとは（復習と確認）
モール型ECサイトは、日本で有名で、みなさんもご利用されているものであれば、
Amazon、楽天、YahooShopping、ZOZOTOWN、Ｑoo10（eBay）
などといったものがこれに当たります。
「ショッピングモール」にいくつかの店舗が出店、出品しているサイトのこととします。
モール型ECサイトは「テナント型」と「マーケットプレイス型」の2種類があります。
モール型ＥＣサイトの特徴としては、
一般的は、集客力があると言われています。サイト（モール）への集客はプラットフォーマーが実施しますと言われています。例えばAmazonはAmazonで、楽天市場は楽天市場で自社のモールサイトにお客が集まるように独自にプロモーションを行います。（ＭＬや、マスキャンペーン、ＳＥＯ的→これが一番重要、にですが）、モールサイトへの訪問者、月間や、年間利用ユーザが多いという点が、１つのメリットです。
これは、ＵＳＡの、Ｄ２Ｃでも顕著な事業トレンドですが、自社の顧客層（ペルソナ）にとって、購買体験が提供し易い、購買場所・購入方法であれば、自社ドメインではなく、マーケットプレイスから、提供を開始するという事業展開を採用しています。
一方で、同じカテゴリー、ＳＫＵで商品が陳列、比較検討されますので、プライスや、ポイント還元での、競争が発生しやすいとは言われています。
顧客も、同一的な商品であれば、ブランド有意性（優位）や、指名買いが無いものであれば、商品価格を比較しやすいため、価格競争も激化しやすい傾向があると言われています。
（自社ドメインでの展開でも同様のことは生じていますが、特段、マーケットプレイスで激しく価格競争に晒されると認知するのはなぜでしょうか？型番ビジネスではないよね。）
ブランディングが難しいって言われていますが、今では、都市伝説のような気がしています。
ストアというサービスがありますから。これを使えば良いだけです。
モール型ECの場合、顧客は「Amazonで購入した」「楽天で購入した」という購買行動をしています。が、一方で、Amazonでの購入優先態様が高い層を顧客にするのであれば、自社ドメインと同様の購入条件（価格）で、都度買いをメインとして、FBAのメリットを顧客に還元するのは、とても有意義な購入体験です。
＊Amazonが次々と提供する、顧客サービスを自社で１から構築することがそもそもでもあります。（プライム・ワードローブとか、返品サービスとか）
ブランド・企業（そもそも企業で商品購入するのってもう少ないのでは？）の認知度向上が難しくなるのであれば、コーポレイトサイトでの、オウンド・ペイド・アーンドでブランド化して、購買体験をモール誘導すれば良いです。
後ほど、D2Cのオムニチャネルで触れますが、オンラインコマースだけでのグロースの良し悪しは別として、Whole Sale チャネルは一考すべきだと捉えていますので、そうなる傾向だと捉えています。
信頼度が高いは、裏腹ですが、Amazon、楽天、といった、マーケットプレイスブランド力は顧客に安心感を与えているようです？。
出展企業の知名度が低い場合でも、特に不安なく顧客は購買体験していると言われていますが、そうでしょうか？。
トラブルは絶えませんし、顧客は「返品」「返金」のプロセスが明確なので購入しているという要因の方が強いと捉えています。（レビューもアテにならないのは経験済ですよね）
だからこそ、自社で、オウンドメディアなどでのブランド化へのコミュニケーションはとても重要なのです。
開始が容易ではあります。が、モールに出店する場合はモール独自の機能（OMSなど）の
＊Oder Management System（オーダーマネジメントシステム）の略
注文を受けた時、どの在庫拠点からいつ出荷し納品するべきか、最適解を導き出し、実行指示する仕組みで、簡単にいうと商品の受注から配送、在庫管理、入金管理、お客様への注文管理メールまで一括管理することができるようにするシステム。
・Amazon は セラーセントラル
・rakuten は Rakuten Merchant Server RMS(店舗運営システム)
・Yahoo は ストアクリエイターPro
など、各プラットフォーム指定のOMSを使うことでECビジネスをスタートすることができます。
独自ドメインの取得やECサイトのデザイン検討といった手間の一部を省くことができますが、SaaS型のEコマースシステムであれば、機能・仕様面では大きく変わらないようになってきました。
ビジネスには、出店料や手数料だけではない、運営・運用のための費用は盛沢山、モール型ECに出展する場合は初期登録費用や月額の出店料、システムの利用料といった手数料がかかります。そのため自社ECサイトと、月次の損益分岐点を、比較してみてください。
Amazon
出品者はアマゾンに対し、取引手数料や物流サービスの費用なども支払っています。
2021年USAでは、商品販売価格の5割以上をアマゾンに支払う大手も珍しくないといいます。大手：アマゾンアグリゲーター はアマゾンセラー（出品者）買収して、資金とECエキスパート人材で事業成長をさせるビジネスモデル事業者なども成長しています。
これは、自社モデルでも重要なポイントです。
rakuten
Yahoo
マーケットプレイス型
とはモール内で商品を販売したい企業が、商品のデータのみを掲載するタイプのモール型ECサイトです。
出店するのではなく、あくまで“出品”となります。Amazon タイプです。（先ほどの例のとおり、変わりつつありますが）
商品データを登録するだけで良いのでECサイト作成の負担が軽減され、事業の初期投資を抑えることができる傾向にあります。
商品力や価格や、「スポンサープロダクト」と呼ばれる広告。（利用者が入力した検索キーワードや閲覧内容に関連するスポンサー企業の商品を、検索結果ページや商品詳細ページに表示）。などの施策が、売上に大きく左右します。
さらには、レコメンド機能があるものの、自社商品のページで他社商品が表示されることもあります。
ブランドごとの出店もできるようにはなってきています。（ストア機能）
ビジネスとしてのアイディア
視点を変えてみれば、自社がそれなりの顧客基盤を有しているのであれば、自社サイトをAmazonタイプのマーケットプレイスとして発展していくことも一考です。
ＧＭＳや、デパートや、ＡSKUL などがそうですよね。いろいろな、流通・小売で応用の効くモデルですので、これを実現できるＥコマースシステムもしっかりとウオッチするべきです。
ＵＳＡなら、Shopifyに対抗しての、BigCommerce みたいな。
テナント型
とはショッピングモールのように、ECサイト（個店）が立ち並ぶモール型のECサイトの形態です。楽天市場とYahoo!ショッピングなどですね。
テナント型ではマーケットプレイス側と比較し企業側の運用負担があるものの、店舗ごとに特徴を出したリ、ブランド力を売りにすることもできます。このため上手くマーケティングすれば、リピート率の向上も期待できます。
ただし商品登録だけでなく、サイトデザインなどの管理業務はすべて企業独自に行うので、負担が増加するというデメリットもあります。
ビジネスとしてのアイディア
こちらは、不動産型の事業モデルですので、ＳＣや駅ビルなどのリアル店舗型の事業者が、自社ビジネスとして展開を検討しても良いモデルでもあります。（既に多くの事業者がサービス展開されていますよね。思い浮かべてみてください。）
このビジネスモデルを実現するためのシステムを選定する一番の参入メリットがあるのは、アパレルなどの多ブランドを扱っている事業者が、Eコマースシステムを共通化して、フロントサイドでのブランド・マーケティング展開をすることで、顧客のライフスタイルの変化に応じてブランドスイッチをスムーズにして、顧客の購買体験を充実させることがこれからとても重要になって来きます。
顧客のライフステージ・ライフスタイルのチェンジポイントはそんなに多くはなく、そのポイントで顧客との接点を醸成出来ると、ＣＬＶ（日本的には、ＬＴＶ）が最大化することは実証すみです。
自社オリジナルドメイン・Eコマースサイト
とは、自社で運営するEコマースサイトと定義しておきましょう。
自社ECサイトは自社独自ドメインと、サイト構成、ページでEコマース運営する形態になります。
デザインの表現などの制約がなく、オリジナルのサイト構成やデザインや、サイト構成、チャネルをはじめ、マーケティング・コミュニケーション、キャンペーンサービスを、顧客の購買体験、購買ニーズに応じて提供することができるのが最大の特徴です。
ブランドのミッションやバリューの伝え方も、オウンドメディアとして（アーンドメディアとの連携も自由）特徴が出せますし。
一番のポイントは、顧客に応じて商品提供の仕方が、自社で自由に設計・設定することができるということです。
（リアル店舗・ポップアップ（POPUP）・常設型などとの連携など）
顧客の購買行動に応じて、場とサービスを提供できるので、ファン化を通じて、ロイヤルカスタマーに醸成する多様な施策
（マーケティングとコミュニケーション）
を展開できるってことです。
そのためは、
システムの自由度＝拡張性＝（費用対効果）、
費用＝工数＝自由度・容易性（簡易性だけではない）
を考慮することです。（詳細は後述）
利益率が高くなる傾向にあると言われています。が、採用するシステムや関連する施策を実施するためのシステムなどの費用次第です。
自社でECサイトを構築・運用する場合は、モール型ECに出展する場合の出店料や手数料などのコストが発生しません。が、上記のEコマースシステムなどの費用などは発生します。
自社ECサイトでユーザが購買してくれるまで、モール型のような価格競争は起きづらいとは言われていますが、自社サイトで購入体験していただくまで（出会い）の、プロセスコストや、競合コストは精査する必要はあります。誰でもが、高い利益を誰でもが確保できた時代は、遥か昔といえます。
ブランディングがやりやすいと言われていました。が、サイトデザインや、ＣＲＭなどについては制約（メールだけに頼らない、SNS：LINEなどのコミュニケーションや、同梱施策も展開できるなど、顧客情報を保持・活用できる）がないため、商品やサービスのコミュニケーションについては比較的自由度は高いです。その結果としてブランドを醸成することは可能です。（モールだと出来ないって時代は終わりましたけど）
■提言
マーケットプレイスも展開すべき。これもオムニチャネル
チャネル別での、マーケティングコストの算定と改善は必要です。
自社ECサイトへ顧客の来訪を促進するためのマーケティング・コミュニケーション施策は、３P-４Pロジックに応じて、設計・企画・実施・分析・改善する必要は、モールと同様にあります。
SEO対策・顧客インサイトに応える質の高いコンテンツ・LP・アフリエイト施策・などや各種広告出稿のマネージメントについては様々な対策が必要です。
リピート率向上を図りやすいと言われています。が、それは出来ての話。
顧客情報を自社で獲得・管理することが可能です。（モールで全くできないわけではないですが）。ご縁を紡いだ顧客に対して、マイページ機能や購買体験・動機などの顧客行動・態様データに則した、コミュニケーション活動をメインにして設計・実施することができます。リピート顧客への対応を通じて、ロイヤル顧客（定義は自社で決める必要があります。基本は、顧客を差別するのではなく、区別・判別するということです。）の拡大につなげるようなCRM（これもとても定義が幅ひろいので自社で定義することが大切です。）を実施することが重要になってきます。
成果が出るまでの時間は、どちらも同じ。
モールに限らず、自社ECサイトでも、集客や、顧客との関係性構築等は一朝一夕にはできるわけではないのは、リアルビジネスでも同様です。中・長期的なプロセス（期間という時間タームと、コミュニケーションの質と頻度、商品・サービスの改善など）をかけて取り組みを行うことは必須です。Eコマース事業の成果が出るまでにも工数＝時間＝費用＝キャッシュフローのコントロールが必要です。
ECサイト運営・改善・継続について、
モール型のように施策にある程度の制約がある場合は別として、自由度が高い自社ドメインサイトの運営の場合は、顧客の購買行動や、体験を充実させて、変化するために、設計・改善を進めることが必要で、運用の柔軟性を求めて、システムメンテナンスやコスト管理を継続していくのか、システム機能に合わせて、運用を設計するのかなど、事業責任者だけではなく、各ファンクションの担当スタッフが、主体的に行い、相互連携する必要があり、それが事業＝顧客へのインパクトに表現されてきます。
オムニチャネル化に伴っての、顧客の行動、購買履歴や、顧客IDの連携・統合に伴う、個人情報の保護に関してのセキュリティや、不正対策、決済手段の多様化への対応、配送方法の多様化への対応、環境対策、各種規制対策（法律も含め）など、ビジネスを継続させるための対策も行う必要があります。
自社オリジナルドメインEコマースサイト構築方法の種類のまとめ
先ほどの、自社にとっての顧客の購買行動と、求める購買体験を実現するための、コマースシステムの提供形態について復習しておきましょう。
SaaS「SoftwareasaService」型
（古くはASP型明確な違いは機能面や提供形態としての、差異はほとんど無いです。敢えて区別する必要性は、事業者側には有意としては無いです。）は、現在では、クラウド上のソフトウェアをサービスとして利用するものです。
SaaS型EコマースシステムとはECサイト構築・運用のために必要な基本仕様のシステムをインターネットを通して利用できるシステムとしましょう。
逆視点で、自社にEコマースサイト構築のためのHW・NWインフラが要らない。
ソフトウェアのインストール、保守も必要ないという形態とします。
Eコマースサイト構築期間の短縮、それに伴う構築コストを抑えることを目的としてサービスベンダーから提供されています。
Eコマースシステムとしての、サービスとして一通りの機能が揃っており、テンプレートになっていることが多いのと、機能のバージョンアップもベンダー主導で実施してくれます。
導入後の運用に関しても、一番も費用面では負担の少ないECサイト構築方法です。（運用工数負担が低いかは、事業モデル次第）
パッケージ型システム
パッケージとは、Eコマースビジネスに必要な基本機能がパッケージ化されているシステムとします。
パッケージ型は、独自性（なにかは別です。勝手な思い込みが多いのが、日本企業にありがち・自社の勝手なこだわりで、顧客にとっては何らベネフィットが無いものは、独自性とは言わないです。独断・専横です。）や、多様・多彩な機能（そもそも必要でないのですが）が求められるコマースビジネスを実現するための、コマースサイトが必要になる大規模なEコマースビジネスに向いているようです。
（業務基幹システムまで含むかは、そのシステムの生い立ちによりますが、残念ながら日本では両方をカバーするものは殆ど存在しません。）
パッケージ内には、カート機能、受注・売上管理、顧客管理などEコマースサイト運営に必要な機能が備わっているという点はSaaS型と同様です。
パッケージ型は、機能によってパッケージ（ブランドの末尾に機能名がついていたりします。）が分離しているパターンや、SaaS型と同様に、追加オプションの選択で、機能追加・仕様拡張を提供している場合もあります。
AWSのような、IaaS環境にパッケージシステムを導入して利用する場合以外には、オンプレミスという導入形態で、ハードウェアやネットワークは別途、設計構築保守する必要があります。（いまどき、したいかどうかは知りませんが）
インストールと基本的な設定だけ（語弊はありますが）で済む場合や、
様ざまな設定開発をする必要があるもの（こちらがほとんどです。）に分かれます。後者の方が、全体（初期、月額、従量、保守など）費用は高めになります。
フレームワーク型
比較的新しいテクノロジーでの開発、提供方法です。簡単に表現すると、システム開発を楽に行えるように用意された、プログラムとかのひな形のこと、真面目に表現すると、software framework、プログラミングにおいて、アプリケーションソフトウェア等の実装に必要となる一般的な機能や定型コードを、ライブラリ（サブルーチンやクラスなど）としてあらかじめ用意したもので、その集まりが、application frameworkとなります。
なんのこっちゃですが、（レゴブロックのシステム版として捉えておいてください。）これからの環境整備のメイントレンドになり、様ざまなメリットがあり、SaaS型のノンコーディングのトレンドとも相まってくる、大事なポイントですので少し深堀しておきます。
深堀
システム構築に必須な標準的かつ下位レベルの詳細（機能群など）を
設計者やプログラマが検討する時間＝工数を省くことを可能にして、
上位レベルの要求仕様（ビジネスロジック）の実現に多くの時間＝工数を割けるするとともに、ソフトウェア開発を容易（わかりやすく）＝生産性向上（再生産も含む）にすることを目的としています。
（開発者側としては、高付加価値業務にシフトできるので、より顧客視点のシステムサービスが提供できる）。
ユーザ側としてのベネフィットは、高機能なシステムが、短納期＝工数が少ない＝費用を逓減して、導入することが可能である。といいます。
簡易に表現すると、数多くの再利用可能なコードをフレームワークにまとめることによって、開発者の手間を省き、新たなアプリケーションのために定形的で標準的なコードを毎回改めて書かなくて済むようにするので、ポイントは、便利、簡単、進化ってことです。
オブジェクト指向とか、API、とか、
Eコマースでは、Web Application Frameworkとして、動的な ウェブサイト、Webアプリケーション、Webサービスの開発をサポートするために設計されたアプリケーションフレームワークといった表現が飛び交っている世界です。
フレームワーク型はカスタマイズという追加開発を前提としているものが多いですが、設定ベースで機能実装も可能であったり、独自性を求める場合でも、オブジェクトの追加という手段で機能実装しやすいことがメリットポイントです。
この次で提示する、フルスクラッチ開発（純粋なフルスクラッチはほぼ無い時代ですが）とは違い全てをゼロから開発するわけではないので自由なカスタマイズが実現するのに、開発期間を短縮できることになります。（あくまでも、ＰＭ次第）
フルスクラッチ開発
Eコマースシステムを、まったくのゼロから開発する方法です。4つのECサイト構築方法の中でも最も難易度が高く、かつコストもかかります。
しかし、メリットはやはり自由度の高さだと言われています（フレームワーク型でも出来ますが）。
システム設計、ECサイトのシステムデザイン、その他諸々をすべて自社独自に決定していくので、要件を完全に満たしてEコマースシステムと、基幹システムまでを包含しての一環（統合システム）を構築することが、理論的にはできます。（金に糸目をつけないのであれば。動くとは限らないのは、みずほ銀行のシステム事件を見れば明らかです。）
パッケージと、フレームワークと、フルスクラッチで選択する開発手法について
これはあまり深追いしても、価値がないので、さらりと
ウォーターフォール開発
とは、システム開発の工程を上から下へと順番に進めていく開発手法です。
「要件定義」「設計」「製造」「テスト」に分割して開発を進めていくパターン
最初の企画段階で必要な機能を全て確定させ、分割した工程ごとに確定された仕様に基づいて開発を進め、前工程が終わってから次の工程に進み、平行作業や後戻りはしないです。
開発プロジェクトの進め方：システム開発
① 要件定義
導入・開発するシステムの目的、全体機能目的、対象範囲を決定します。仕様を決めることのできる意思決定者と現場のスタッフ担当者、開発会社のプロジェクトマネージャーが打ち合わせを重ねながら進めていきます。必要な機能や対応を確認するまでが要件定義です。
「カート画面にて割引クーポンが使えること」などの文章で要件が記載されていきます。
＊RFPや、要件定義のポイント・TIPSは別記事で
② 基本設計
要件定義の段階で決定された事項を具体化するフェーズです。基本設計では、要件について、おおよそのどのようなＵＩ画面になるのかというところまで可能であれば、モックアップで決定していきます。（むかしむかしは、EXCELなどで、ポンチ絵的にしていましたが、これではスタッフが、データ遷移やワークフローが確認できないのでかわいそうです。）
画面を含めて必要な機能を確認していくことです。
③ 詳細設計
基本設計で決定された事項を、より詳細に機能レベルで分割して設計するフェーズですが。フレームワーク型で、ノーコード型に近いものであれば、基本と詳細を一気通貫で実施する方が理に叶っています。
そもそも、スクラッチ＆ウオーターフォール型での、フェーズの刻み方なので、基本設計が開発者と発注者の認識合わせが主目的で、詳細設計はプログラマがプログラミングできるレベルまで詳細に内容を落とし込むためであるためです。ドキュメントに落とし込んだもの「詳細設計書」をもとにプログラミングが行われています。
④ 製造（プログラミング）
製造段階で仕様の変更や追加があると、影響範囲の調査や追加作業が発生し費用増につながってしまいます。通常基本設計完了時点で要件の変更や追加はいったん完了がいままです。
新しい機能を追加しない、といったシチュエーションは、顧客対応がメインであれば珍しくなくなるかも知れません。一般的には、納期遅延、コスト増につながるので、これを前提にどれだけ影響があり、フレームワークなどの構造的に吸収できるかなどを調整する必要があります。（一発で、完璧なシステムなんてできませんを前提にしましょう。まずは、１つのメルクマークを超えて実装していくことです。バグがあっても良いってことではないです。）
⑤ テスト
プログラム機能の挙動確認から、実際の業務シナリオをもとにしたテストなどです。
プログラムが仕様通り動作するかの内部テストと、他システムとの連携が問題なく動作するかの外部テストです。
当初の要件定義で決定した機能を満たしているか、操作感に問題はないかといった点までをスタッフが確認します。（と、言っても、イレギュラー処理なんて思い出していないので、運用ではじめて、遭遇するなんてあたりまえだと思ってください。ですので、如何にリカバリーするか、できるかが、ポイントです。）
⑥ リリース
開発した新システムを本番環境でリリースします。
ここからが、本当のシステム開発で、システムが、顧客と、スタッフにとって有益なもの、役立つものとして、育てていくフェーズになります。
ベンダーは、システム運用や保守を行うフェーズを分けたがります。契約や費用面ではそうですが、これからが、ベンダーの力量が問われます。（発注者側もですが）（本当に任せてよかったかどうかが分かるフェーズです。運や、見立てが悪ければ、1か月もしない内に別のベンダーやシステムを探すことになります。）
アジャイル開発は、
ソフトウェア開発を迅速に行うための開発手法です。「常に改善している状態」「より良いものを持続的に作っている状態」を目指すとしておきましょう。短い期間で開発、テスト、運用を繰り返しつつ開発していくことになります。
顧客体験や顧客購買価値の環境変化に応じて、計画（仕様や機能）変更を柔軟に実施できます。素早く立ち上げ、ビジネス環境に応じて柔軟に改善し続けるという、これからのＥコマース＆オムニチャネルで顧客体験を高めたい事業者にとっては、魅力的でフィットした開発手法ではあります。最低限の機能を実装して、まずは公開をして、顧客の反応をみて、その後、機能を追加、変更していくビジネス運用イメージです。3か月後に、顧客行動・体験が変化しているかも知れない時代にはあっています。
余談
連携するシステムは、捨てる・替えることを前提にして、選定・運用しましょう。
笑い話ですが、とある、Eコマースの会社さんには、BIツールが、３つも入っていました。
１つ1人・１オブジェクトでの随時導入です。１つで運用できるにも関わらず。理由の１つは、業務のブラックボックス化、もう１つは、基幹やEコマースビジネスとの連携コストが高かったのと、高いので捨てられないです。
これって、本末転倒ですが、よくある話です。
あとは、なんでもEXCEL病もなんとかしないといけないですね。
OSS（オープンソースソフトウェア）は、
一時期、流行りました、基本仕様が公開されている利用料がかからないソフトウェアです。無料の部分には不具合への対処・セキュリティ対策などをしっかりと自社で行う必要がある反面、技術力さえあれば比較的低コストでのEコマースサイト構築ができますが、そんな環境の整備は（人的リソースがないので、そもそも人材が業界全体として不足・不一致な環境で、なぜ、御社にスタッフが参画するかを見落としてはいけません。これがIT人材だけの問題ではないです。）出来ないので、サポートベンダ―パートナーの力を借りることになりますので、フレームワークの方がまだ増しかも知れません。（ブラックボックス化はほぼ同じ結果になるので）。
Ｅコマースビジネスの基本的な構築ステップ
1.Eコマースビジネスモデルからの商品・マーケティングデザイン策定
どの顧客に、どんな商品・サービスを、どのようにしてコミュニケーションして、どれくらいの顧客との出会いと、お付き合いをしたいのか、その果実としてどのような・TopLineとBottomLineを実現するのか。
D2C Eコマースビジネスでは、最初にこうしたビジネスモデルの検証（これは、マーケットと顧客からの対話から）から初めていくことになります。（〇〇の、キャットコピービジネス、パクリでもビジネスモデルでもです。）
コンセプトは具体的である方がよいのですが、完成形である必要はありません。（顧客次第で枝葉だけではなく、マーケットもピボットする必要があるからです）完成形は、顧客とともに出来上がるものですから。（テストとか、モニターとかがとても重要になってきます。）
複数のシステムベンダーや、コンサルティング、サイト制作パートナーから提案を受けても、実際のところ、自社にマッチしているのか？提案＝費用などが妥当なのか？どのパートナーが自社のモデルを理解しているのか判断がつかないというケースは実際少なくありません。
そういった場合によくある間違いが、他社の実績だったり、提案費用（その時の）でのみ比較して選定することです。費用だけで選択して成功できるのであれば、だれもが成功しています。
D2C/Eコマース事業としての目的＝顧客×商品なので、当てが外れるのは当然、観点から順番に事業をデザインしてください。（顧客には深い因子がありますが、別記事で）
コンセプトとしては、よくペルソナを活用します。が、
そんな顧客いませんよ。とか、
その顧客へのタッチポイントは、どうなのですか？
が、そもそも、何処かの代理店からの情報や、記事からの寄せ集めだったりします。
小売店舗や、製造業であれば、顧客の購買体験に焦点をあてて、
「デジタル化する顧客の購入体験にキャッチアップして、購買チャネルを提供するため」
「売上を拡大するために、チャネルを拡張するため」
ということから、アプローチしていくことの方が現実的です。そこに即して、３Ｃ-４Ｐをブレイクダウンする形で「Eコマースで展開する要素としてデザインや、機能や、仕様や、ワークフローをベースとしての、システムへ展開・検討するとブレが少なくなります。本来は、ＢＰＲなども考慮して、一貫性のある進め方をするのがベターではありますが、既存ビジネスがあれば、組織や手順を変えることよりスムーズに意思決定を行うことができます。新規ビジネスであれば、知らないことは設計できませんので、システム仕様に合わせることです。（無料セミナーを掻い摘んでありないモデルをデザインしても運用出来ない以前の問題に直面します。）
顧客とのコミュニケーションだけでも、Eコマースサイトだけで購買体験を提供するだけでなく、SNSなどの多様なチャネルがありますし、顧客がそこで購入したいと選択するなら、モール出店（出品）して、顧客のいるところに進出することが一番の正解です。
「自社オリジナルEコマースサイトで無くてはいけないなどの、コンサルタントの意見は本末転倒ですし、ＥＣ化率なんてＫＰＩなどは間違っても重点指標にしないでください。」というところの明確な、ビジネスコンセプトをいい意味で、顧客視点で昇華、蝉変していってください。
目的が明確でなくていいと言っているわけではなく、真・信・芯の目的は一貫してください。そうでないと、ビジネスプロジェクトは失敗になりがちなのでは、論を待たないと言えます。メンバーそれぞれの視点を共有して、納得、理解するまで共有しましょう。（総意・合意では無いですので間違いのないようにしてください、異論・各論は尊敬して、まずは方向性を決めて、進み、やってみて、顧客の声などで、間違いに気づいたら、修正・撤回する勇気を持つということです。）
2.要件定義
D2C/Eコマースサイトビジネスコンセプトの次は、どのようなシステム機能・仕様が必要であるかについて
・顧客体験の、フロント部分
・顧客体験を、最大限に満足度を上げる、支えるための、バックオフィス部分
・顧客体験で、より顧客との関係性を、維持、継続、昇華させるための、コミュニケーション部分
について、顧客視点の行動ケースを元にした、ワークフローまでに落として、システム要件を定義していきます。
ここでの要件定義は、自社がコマースシステムとそれ以外のシステムを選定するにあたり、どのようなシステムが、必要か、システムを採用すべきか、当面は、人力（導入したいけど、効果が不明、不確定、継続性に疑問があるのでとか）や、パートナーアセットで代替えするなど、どうあるべきか、重要度や優先順位を、スタッフで決めていくプロセスです。
既存ビジネスがある場合は、現行システムの機能一覧をベースに不満点や改善したい内容を洗い出していくというやり方が一般的ですが、これでプロジェクトを進めて、成功した事例は少ないです。
システムベンダーはこの機能一覧をベースに見積作業を行うことが一般的ですので、ここがどれだけ表現できているかで提案時の見積の正確性が左右されます。
が、そもそも、ベースモデルからの修正レベルですので、既存ベンダーが優位です。（余程、事業スケール、ピボットしていない限りです。）
機能の視点だけでなく、システムでの非機能要件も見逃しがちですので忘れずに確認ください。
サイトパフォーマンス・セキュリティー
デジタルマーケティングに関するデータ連携などは結構穴があります。
一番の問題は、Eコマースシステム単体で、機能・仕様提供が、完結するケースは、ほとんどなく、他システムとの連携はマストです。
・どのシステム
・どのデータ情報
・どうやって
・どれくらいの頻度・タイミング
で連携していくか、
このシステムと、あのシステムで重複機能がある場合は、どちらを優先するのか。
重複機能がある場合は、片方のシステムを無くせないか。また、両方無くして、別システムに置き換えられないか
などについてもしっかりとリ・デザインしてください。
直接的な、システムコストだけではなく、ワークフロー工数や、連携コストなどの費用面だけではなく、シンプル化することで顧客体験もデザインしやすくなります。
スタッフ工数も減らせることが出来ますので、業務生産性が向上するので、相対的なコスト削減になります。（絶対的ではないですよ）
3.ブランドデザインコンセプト
これは、別記事で展開します。
4.コンタクト・コミュニケーションチャネルについて
PC、スマートフォン、タブレット、といったデバイスに視点が行きがちですが、
むしろ、顧客のタッチポイントが多様化していますので、タッチポイントメディアからの、顧客体験（CX,カスタマージャーニーとも表現されます）が、重要性をましてきます。
それが、最近の話題となっている、ヘッドレスコマースという概念です。
どのチャネルからのアクセスが多く、顧客の比率はどのくらいかという、チャネルまたぎ、オムニ化の情報を整理することが大切な時代になってきました。
顧客にとって、優先すべきコミュニケーションから、購買ポイントに至る、行動は様々に違います。
購買体験チャネルであれば
・リアル店舗
・Eコマースサイト（複数チャネル・外部モール）
・コールセンターのチャネル
になど対しての顧客体験の提供
購入までの顧客体験から、購入受取までの顧客体験
・様ざまなチャネルで購入できて、好きなところで受け取れる。
その情報を踏まえての
・顧客情報や、嗜好性・行動履歴・などを反映した、
CRMとキャンペーンマネージメント（CXとCEなのですが、ここでは割愛します。）
・商品情報・店舗情報・スタッフ情報の管理（連携）
・ レコメンドエンジン・パーソナライズ（各種履歴からのFB）と顧客ID統合
顧客の変容に合わせてのマーケティング・コミュニケーションの展開
・SNS・チャットアプリとの連携
・その他SaaS系アプリケーションとの連携
・WEB接客対応
・AR VRなどのシミュレーション対応
バックオフィスシステムとの連携
・WMS
・返品対応
・予約販売
などです。
5.決済方法について
決済は、オンライン・オフラインともに、多様化しています。益々、顧客にとって便利な決済方法が提供されてきます。
・クレジットカード決済
・代引き着払い
・コンビニ決済
・BNPL決済（上記２つとは別で）
・ID連携決済
・モバイル決済
・アップルペイ/アンドロイドペイ
・デビットカード
・越境ECならアリペイ、Stripe、Paypal、
・リアル店舗での決済（POS）
など実に様ざまです。多くの顧客は望む決済方法が用意されていないことを知るとサイトから離脱してしまう傾向があると言われていますが、多様な決済方法に対応するに越したことはありませんが、運用、連携だけではないコストも大きくなるので、残念ですが、顧客としてお付き合い出来ないバランス（代引き顧客は、〇〇という購買行動があるので、後払いを選択して貰おうとか）を考慮しつつ取捨選定する必要があります。
6.配送パターン
Ｄ２Ｃ/Eコマースビジネス運営費用（原価コストとして捉えてください）で、一番ウエイトが大きく無視できないコストが物流コストです。物流コストの見直しを目的にEコマースサイトをリニューアルするタイミングで異なる配送業者に切り替える、あるいは併用していくということを検討されるケースも少なくありません。
複数の配送業者を利用する場合、どのような基準で配送業者（倉庫もですが）を判定するのか。
・商品に対して
・エリアに対して
・店舗ピックアップ「BOPIS」なのか（店舗からの配送なのかも含めて）
その逆なのか。
・デリバリー期間と費用の関係はどうする
・返品はどうする
・モールのフルフィルメントサービスとの連携はどうする
を、デザインしてください。あくまでも、基本は、顧客視点です。
システムによっては、対応出来るかポイントが分かれてきます。
費用
これは、誰でもが見て、検証する視点ですが、見落としがちでもあり、算定が困難な数値でもあります。
・継続運用のためのポイント・ビジネス拡張のために伴う追加開発費用、メンテンナンス
・対応スピードとコストと、パートナー化と内製化
・外部システムとの連携の可否と容易性
・ビジネスモデル変化への対応性
で、大きく変わってきます。ポイントは、システム要員の基準単価コストと、開発モジュールのユニット単位を組み合わせて、標準原価を仮設定していくことです。
それで、採用するか、しないか、実施するか、しないかを、現場の担当レベルでまずは判断できる環境をつくることです。
（実は、マーケティングや、商品原価などのＭＤ部分では、何気に無意識で情報を蓄積して、判断していますよ。）
ECサイト構築パッケージの選定ポイント
・D2C/Eコマースビジネスのグロースのための、機能追加や、ワークフローの制約を受けないか。
D2C/Eコマースビジネスに限らず、グロース、拡大をしない企画・検討はされていないと思います。（永遠ではありませんが）、他の事業形態・モデルでも、ビジネスが拡大するに連れて、システムの機能や、それを支えるインフラはスケールアップされていきます。
例えば、
導入システムのライセンス形態（費用課金形態）が、サーバ台数やCPU数に依存する場合や、ユーザーライセンス数や、トランザクションベースや、売上課金ベースなどの費用形態をとっています。
ビジネスが、ある事業規模以上を超えた場合に、この手の費用がとても負担になります。（階段上になっていると尚更）。
クラウド上インフラ環境構築している場合のメリットである、事業の需要変動に応じての、スケールアウト、スケールアップで、費用を変動化するとともに、顧客体験を最大化するというクラウド環境のメリットが相殺されないようにするべきです。（いまの時代、オンプレで環境を構築、メンテする事業者も稀だとは思いますが）
導入コストを下げる方法としてはクラウドサービスを利用して、インフラ・機能的に不足する部分をどうカバーして運用設計するかも大事です。
拡張性を視野に入れてのシステムだけの費用ではだけではなく、インフラ面でのチェックも怠らないことが大切です。
要件変更に柔軟に素早く対応できることはマスト。
仮に、コスト、機能、開発、セキュリティのバランスが整っている、SaaS型を選択した場合に、事業グロースに伴う充分な対応が出来なくなることは当たり前です。（いくら機能追加などを、年間〇〇〇件実施していると謳っても所詮はバグ潰しだったりします。大事な機能追加はされていなかったり、機能追加は、外部システム連携だったりします。＝月次コストが追加されていくという、APIコストの肥大化・肥満化をしているだけが多いです。）
その場合は、システムのマイグレーションを、検討することになりますが、
パッケージ製品や、システムベンダーのフレームワークタイプとなるとソースコードのブラックボックス化は、避けて通れません。
（フレームワーク型で、開発フレームワークが一般的ソースコード（フレームワークのドキュメントがしっかりしている）で開示してくれるタイプを選択するか、APIドキュメントなどが、オープンフレンドリーなサービスの選択がマストです。は、理想形ですが、システムベンダー、サービス提供会社への依存というか、コラボレーションは避けられないので、その関係性は十分にリレーションする必要はあります。）
顧客の購入体験のトレンドにキャッチアップすることが、D2C/Eコマースビジネスの基本だと、幾度もお伝えしてきました。
そのために、カットオーバー後に継続的な追加開発を行う必要があります。その追加開発はビジネスの変化、成長のスピードに合わせて、期間と費用のバランスを有して、実現される必要があります。
＊とても乱暴な言い方ですが、ドキュメント作成時間・工数に費用を費やすより、機能追加、修正してから、確定情報のドキュメントを作成した方が3社のためで、三方よしです：（本当の意味は違います。）
最後のポイントとしては、
追加改修に適した構造になっているか（そもそもが、うまく構造化されていないとか、オブジェクト間の影響を最低限にする設計思想ではないとかが、あると出来ると言っても費用面や納期面不可なことは沢山です。）」
の3点が、柔軟でスピーディなD2C/Eコマースシステム改修が実現できるかどうかを判断するポイントではあります。
＊システムを更新、マイグレーションするという本体側だけに視点がいきがちですが、データ移行の可否や、その、埋没（サンクス）コストって見落としがちです。これは、連携するシステムだけではなく、決済関連データ、IDは移せるけど、PWは移行できないコストなどで、顧客側で再設定が必要なことは、見えないコストとして効いてくる、顕著な事例です。
将来（スポット）のトランザクション増加への耐久はあるか
ECサイトを構築し、広告の運用や継続したPDCAサイクルを回すことによりアクセス数は堅調に伸びていくとします。集客力の高さは売上にダイレクトに影響する要素ですので、あらゆる手段を用いてお客様を自社のECサイトに誘導しなくてはなりません。ただし、このとき、構築したECサイトが大量のトランザクションに耐え得るものでなかった場合、広告やキャンペーンに費やした費用が無駄になるだけでなく、売上機会の損失、信用を損なうというマイナスの結果をもたらすことになってしまいます。
そのような事態を発生させないために、ECサイト構築パッケージを選定する上で大量のトランザクションに耐えうるアーキテクチャの製品を選定することが求められます。
肝心要セキュリティチェック
Eコマースサイトを運営していく上でのポイントです。サイバー攻撃による個人情報の漏えいなどですが、昨今サイバー攻撃が深刻化していることで、様々なECサイトが被害に遭っています。（ニュースにもならないくらい多いですね。）ので対策については、認証制度も含めて確認はしましょう。
外部システムやサービスなど多様な連携先との自由度
D2C/Eコマースビジネスでは、当初に連携している、外部システムやサービスだけでは、変容していく、顧客体験を、最適に提供することが、難しくなってきます。（かと言って、古いチャネルを無くすことも出来ないのが、悩ましいところではあります。）
それにともない、フロントサイド、バックオフィスサイド、コミュニケーションサイド、で業務が回らなくなってくることがほとんどです。
・仕入や在庫や売上を管理する販売管理システムなどの基幹システムとの連携
・リアル店舗POS連携
・外部決済サービスの拡張と入替利用
・分析・マーケティングツールの入替・導入
など、様々なシステムやサービスとの連携は、欠かせなくなってきますというか必然です。オムニチャネル対応のD2C/Eコマースビジネスでグロース・成功を実現するためには連携機能は避けて通れません。（外部連携システム側は、柔軟性が、低いことや、無いこと、有っても、改修費用などが高額になりがちなので、コマースシステム側で、連携機能を取り込む必要が高かったりします。ポイントとして、多様な連携先を有しているか、それを実現するための、ＡＰＩとか、オブジェクト追加機能有していることが大切なポイントです。
顧客体験（ＵＸ）、ＣＸをメインとした機能を提供することが可能かどうか
UXとは、顧客視点でＤ２Ｃ/Ｅコマースのタッチポイントである、サイトデザインや、バックオフィス機能を提供するということです、顧客が求める、ベネフィットと、それを確信する、快適な購買体験を提供するということです。顧客満足度を向上させることができれば、ビジネス価値が向上されていきます。
まとめ
1つのソリューションで最大の柔軟性を確保すること
キーワード：APIファースト
完全で一貫性のある文書化されたAPIを提供されていること
キーワード：ヘッドレスコア
デジタルコマースエクスペリエンスを顧客に提供できることです。
私たち（あなた）は、私たち（あなた）の顧客に、私たち（あなた）のブランドと、関わりを持たせたい場所と、方法を決めることが出来るということです。
キーワード：B2C・B2B・D2C
ビジネスモデルに関係なく、特定のビジネスニーズに簡単に適合してサポートできることです。
Eコマースだけが、ビジネスを体現するモデルではありません。私たち（あなた）と、その商品・サービスを求めている顧客とのお取引の仕方は様ざまです。（WholeSaleは、D2Cには避けて通れないと捉えておいてください）
キーワード：コンテンツとコマース
顧客は、購入を決定するために、あなたを知り、好きで、信頼する必要があります。コンテンツとコマースのシームレスな統合のおかげで、その不可欠な信頼要素を構築し、堅実で顧客中心のブランドアイデンティティ（体験と価値）を構築することが必要です。
優れたデジタルコマースエクスペリエンスを作成して、リーチを有機的に拡大し、すべてのチャネルで顧客のエンゲージメントを維持することができるかです。
キーワード：無敵のTCO
直接的なコスト比較（見積）はされています。最先端のテクノロジーで、TCOを把握、管理して、そのプロセスと価値が完全な透明性、隠れたコストなしで、継続的な技術改善を提供して、成功に必要な競争力を提供してくれるパートナーと出会い、お互いの価値を認め、育成していくことです。
キーワード：市場投入までの最速・最短
プロジェクトサイクルが大幅に短縮されるというメリットを追い続けてください。デジタルコマースでのスムーズで離陸ができれば、成功・グロースに役立ちます。すぐに、あたらしい、モデルを開始して、顧客からの支持があれば、それを拡大します。そして、顧客が不要と言えば、撤回、撤退します。
今回は、とてもラフなアウトラインとなっていますが、まずは、コマースシステムってなんだろうから共有いただければと思っています。
次回以降は、個別の機能などについて、しくじり事例 を元にこうしたら良いをお伝えできればと思っています。
何故なら、成功は真似するのではなく、掴みとるものですし。
同じ条件が無いので、他社の成功をそのままで超えることは出来ないです。
失敗は、同じことを無駄に繰りかえす必要が無いので、しくじりのポイントが分かれば、回避できます。
その浮いたリソースで、トライをして私たち（あなた）の成功をデザインすれば良いだけです。
長文にお付き合いいただきまして、ありがとうございます。コメントや、リクエストなどお待ちしております。
どこかで、お声がけいただけ、お会いできますことるを楽しみにしています。
この記事が気に入ったらサポートをしてみませんか？