【EC開発体験記-SaaS-】 カストマイズは本当に可能なのか

　今回の話はSaaSである。私は当初、自社基幹システムを含めたサービスの利用、つまり、システムをすべて外部業者に委託できないかということを真剣に考えていた。そもそも、私の本来の目的はECを開発するのではなく、ビジネスを黒字化することであったので、極端な話、EC事業をサービス化した外部の会社があって、サービスを利用できるのであれば開発しなくてもよかったのだ。実際に自社サイト以外にも、楽天やYahooといったモールを利用しており、これで全て業務ができるのであれば結構な話である。しかし、実際には下図のようにEC機能としては十分ではあるものの、出荷、販売管理といった機能がないため、自社の基幹システムに受注を取り込む必要があった。





　SaaSは定義が曖昧で分かりにくいという話はよく聞くので、次の記事を参照いただきたい。ASPとの違いという観点でよくまとまっている。

代表的なSaaS企業といわれているSalesForce.comのモデルを説明した記事（SaaSの衝撃(2)　セールスフォースの凄み

セールスフォースの提供するSaaSは従来のASPとは異なる。なかでも特筆すべきは、ASPが抱えていたカスタマイズの難しさや、外部のアプリケーションとのデータ連携、 システムの信頼性への疑問といった問題点を解決したことだ。

　逆の言い方をすると、自社システムを用意しなければならないのは、カスタマイズの難しさや、外部のアプリケーションとのデータ連携があるからである。外部の業者、例えば、楽天やヤマトのシステムに集約できれば話は簡単であるが、より多くの機会やきめ細かなサービスをやるためには、サイトも配送業者も一つだけでは不十分である。実際のプロジェクトでは、様々なフロントエンドのECシステムとの連携、および、大・中・小の３つの配送業者のシステムとの連携を行う必要があったので、自社基幹システムを開発することになった。
　もっといえば、商品によってもサービスが異なってくる。今回のECシステムでは、家電の受発注品を皮切りに、家具、DVD、そしてドロップシッピングと、様々な商品に対応すべく拡張していったが、それぞれにおいて受注の方法、管理の方法が異なるため、実際にはまるで別のシステムをゼロから構築するかのようにカストマイズせざるを得なかったのである。私はECについては素人であり、商品が異なっても仕組みはどれも似たようなものだろうと甘く考えていた。まさかここまで違いがあるとは思いもしなかった。一例を挙げよう。

　＜家電受発注品＞
　　１）　注文を受けてから発注するので納期は曖昧である（３日～７日）
　　２）　基本的に在庫管理しない。（受注を受けられれば配送できる）
　　３）　小物であればお客様もお届け日の指定にこだわらない
　　４）　粗利が低いため、配送料は配送地域によって差をつけたり、高額商品であれば無料にする
　　５）　ドロップシッピング品においては返品が不可

　＜家具＞
　　１）　家具は在庫管理が必須である
　　２）　大物が多いため納期はお客様指定の日を厳守する
　　３）　配送管理におけるLT計算が必要になる
　　４）　商品の大きさにより配送料をきめる。また、設置、組み立てサービスを別途用意する

　＜DVD＞
　　１）　予約販売が必須であり在庫管理が必要
　　２）　発売日の発送を厳守する
　　３）　受注を受けてから配送までの時間が長い（半年などもある）ため、すべての商品を発送しないうちに代金を回収することがある（一品発送をもって決済）
　　４）　発送枚数が１枚であれば配送料を安くできる（メール便）

　それから、大切なことで細かい話ではあるが、ぜひ気をつけておきたいことに、受注の括り方と金額の計算方法の統一化がある。受注金額の計算では、一品一葉単位であれば商品ごとに消費税が加算された合計となるが、受注単位であれば受注金額の和で消費税計算をすることになる。また、小数点以下は切り上げ（常にお客様が得になるように計算する）とするなど、計算方法がシステム全体で統一されていないと不具合となる。
　先ほど、もし、モールに受注・出荷・販売といった管理機能があればとはいったが、これだけの違いを吸収するだけでも大変である。ASPであれば、パッケージソフトのように出来ることだけを選択すればよいが、カストマイズを前提にしたSaaSでは、基本は全ての要求に応えなければならないだろう。そうなると果たしてどこまで対応できるか疑問である。
　たしかに、費用と時間をかければ不可能ではない話ではあるが、SaaSは多くの顧客に対応することでスケールメリットを追求するモデルなので、それほど多くをかけられないというのが現状だろう。また、通販というビジネスモデルを考えると妥協できないのは運用コストである。結局、システム運用・保守に多くのコストをかけてしまうのであれば、SaaSにする意味がなくなってしまう。
　これについては、私たちのプロジェクトに当てはめてみると反省すべき点が多い。そもそも当初の目的である受注センターの効率化のために、異なる商品の受注業務を一本化して、システムと人の統合を進めなければならなかった。しかし、実際は家電・家具・DVD用のそれぞれの受注システムとスタッフが縦に並ぶ構造になってしまった。商品の特徴を知るバイヤーを中心に販売方法を決めていたこともあったので３チーム編成は悪くはなかったとは思うが、受注スタッフの縦割りは明らかに非効率であった。ここでも書いたが、コストを最小化できてはじめて利益を高めることができ、あるいは、お客様にサービスとして還元できるようになる。もう少し踏み込んだシステム統合、および組織改革は必要だったと思う次第である。

　なお、SaaSの利用については、安全性・信頼性といった問題も考えなければならない。これはまた別の機会に触れたいと思う。

ASP・SaaS安全・信頼性に係る情報開示認定制度