予算オーバーの費用とリスク。ECカートの自社開発という暴挙の末路とは？
- 2020.07.22
2024.01.30
✓ 先行運営されているECオーナーは、どのような過程を経てECサイトを立ち上げたのか？
✓ 運営開始にあたって、どんなことでつまずいたのか？
ライター業を営む傍ら、自身でECの運営代行やwebサイトのディレクションも行う筆者。
このシリーズは、そんな筆者が、実際業務にかかわったECサイトの構築過程や、課題・売上目標を達成していく様を赤裸々にご紹介する体験談を綴ります。
▼前回のお話はこちらから
▼ECサイト構築のポイントや流れについてはこちらの記事を参考にしてください。
目次
フルスクラッチ（自社開発）の提案を出したものの
ECサイトでは珍しい、木材カットや塗装などオーダーメイドの加工。
それにきめ細やかな顧客対応が功を奏し、売り上げが立ってきた木材の通販のECサイト。
その反面、使っているオープンソースがこれらのサービスにまったく対応できていないことから、クライアントの業務が機能不全に陥りかけていたことは前回お話ししました。
そこで我々は、ECサイトを完全にECカートを自社開発でカスタマイズする「フルスクラッチ」で新たに制作するという提案を行ったわけですが、今思えばこの提案は大胆すぎましたね…。
売り上げもそれなりに立ってきたものの、使っているECサイトが木材カット受注に対応していないことや、自社の在庫・経理システムと連携が出来ていないことが問題に。
そのため、顧客対応と事務対応に追われ、連日深夜まで作業をする羽目になっていたサイトオーナー…。
この問題を解決するために、我々はサイトリニューアルを提案します。
しかし、「ASP（Saas）カートはカスタマイズができず、融通が利かない」という誤った先入観から、肝心のカート部分をフルスクラッチ（自社開発）で行うという方針を立ててしまうハメに…！
確かに我々サポートチームは、ライター兼ディレクターでマーケターでもある私と、デザイナー陣、それにシステムエンジニア・プログラマーからなるチームではあります。
それゆえ、ECサイトをいちから制作するスクラッチやオープンソースのカスタマイズは可能です。
ただもう一度機会があれば、このような提案はしません。
その理由は、「要件定義」「制作構築」「運用管理」「セキュリティー対策」というECサイトを構築～運用するすべての工程において、クライアントやサポートチームともに負担が大きいから。
この木材メーカーさんのサイト構築を例にして、ご紹介したいと思います。
■フルスクラッチとは？カートの種類や機能がわからない方はこちらの記事をどうぞ。
要望が膨らみすぎて要件定義を決めきれない
ECサイトは、いわばカートシステムの上に成り立っているサイト。
ですから、
✓ どのようなお客さまに向けてサイトをつくるのか？
✓ どんな機能をつけるのか？
を
きちんと整理する「要件定義」ができていないと、サイトをつくることができません。
人は自由な裁量を与えられると、なかなか物事を決められないものです。
今回のケースもそうでした。
もともとの想定では、従来のオープンソースに初めからついている機能に加えて、木材カットや塗装といった加工の選択。
それにクライアントサイドの経理と、在庫帳票入力用のCSV出力機能が付いていれば十分だったはず。
でも打ち合わせを重ねるうちに、複数の運送会社に最適化された送り状用のデータ出力。
それに付随して、発送日ごとの問い合わせ番号の発行。エンドユーザーからの問い合わせ用・受注用・発送用に分けた、何種類もの自動返信メールの設定など。
それこそ、数限りなく要望が出てきます。
機能追加に伴い当初の想定予算を大きくオーバーする
やりたいことが増え、機能が追加されると、当たり前のことながら制作費用も増えます。
クライアントにそのことを伝えると、こちらが提示した制作費用では「費用が高すぎてサイトリニューアルの稟議が通らない」というご返事。
「現場のやりたいこと」と「経営者の求める費用感」のバランスが合わないという事態は、制作案件ではよくある話です。
とくにECサイトの構築は、カートシステムとホームページを組み合わせるという作業を行うため、通常サイトよりも倍以上の制作費用が掛かるのは当たり前。
ですから、このような状況になるのは珍しいことではありません。
ECサイトリニューアルの本来の目的とは
そうなるとクライアントサイドより値引き交渉を持ち掛けられるわけですが、さすがにここまで膨らんでしまった追加機能を、先方の希望価格に抑えるのは無理。
私も制作サイドから価格交渉を一任されている以上、一歩も引けません。
交渉を繰りかえすうち、要件定義を見直すことになるのですが、
今回は「やりたいことの取りまとめ⇒価格交渉」というループを4～5回も繰り返しました。
何度もご説明しているように、このサイトをリニューアルするのは、担当者の業務がオープンソースでは対応できなくなっていたことに端を発しています。
ですから、担当するスタッフの使い勝手向上は重要な要件。
けれどEC本来の目的は、利益を確定すること。
要件定義が膨らんで、サイトの制作費用がかさんでしまうと、EC事業での経費と利益のバランスが崩れてしまいます。
同時にただでさえ忙しい業務の合間を縫いながら、どのような機能が必要なのか？の社内検討から、どういった機能を実現すればいいのか？という機能詳細も自分たちで決めなくてはいけません。
さらには、できあがった後のテスト作業までもすべて自社内でやらなくてはいけない。
我々制作会社とも何度も打ち合わせを繰り返すなど。
時間も労力もかかって、ヘトヘトになってしまいます。
ECサイト運営で本来やるべきことは、提供する商品・サービスをより良くしたり、お客さまとの対話を重ねていくこと。
それなのに、社内外でのミーティングで時間をものすごく取られてしまう。
これでは何のためにリニューアルを進めているのかわからなくなります。
最後は機能を絞って開発を進めることに
要件定義に対するミーティングが6回目を迎えた時、オープンソースの標準機能ではカバーしきれなかった機能。
つまり、もともと最初にやる必要があるという話になった部分に立ち戻って開発を進めることを提案してみました。
最初は渋っていたクライアントの担当者でしたが、結局、予算と収益のバランスをお考えになったのでしょう。ご納得いただくことができました。
なぜフルスクラッチのリスクが高いのか？
このように、ひとまず最初の難関である要件定義を取りまとめることができましたが、課題は山積。
このあとデザイン構築で一山超えなければならないのですが、それはまた次回のお話とさせてください。
ECサイトをフルスクラッチで構築したり、オープンソースをカスタマイズすることがなぜリスキーなのか？
この辺をもう少し掘り下げてみたいと思います。
１．ECサイトの保守管理に対する不安
サイトをオリジナルで構築するということは、構築した人間でないとメンテナンスや不具合を解消できないことを意味します。
そもそもECを一から構築したり、オープンソースをカスタマイズするノウハウや技術は、誰にでも備わっているわけではありません。
特にサイト構築を依頼した相手が、フリーランスや小規模であった場合、人間関係や廃業トラブルなどのリスクに常にさらされます。
サイト上でトラブルが発生したり、改修が必要になったとしても、誰も触ることができず、
改善すべき点を改善できないまま、放置状態で運営されるECサイトとなることもあります。
カスタマイズで自社開発されたシステムを他社が改修するのは、まず構造の分析から始めないといけないため難易度が高い。
また、構造を分析して改修する場合も、分析コストが追加発生するため改修コストがかさむのです。
２．スピードが速いECの進歩についていけるのか？
ECはその周辺環境含め、非常に進歩が速い業界です。
設計段階では最新のシステムであったものが、完成時には陳腐化してしまっている。なんてことも起こりかねません。
３．マーケティングツールや各種プラグインをすべて自力開発するのは非現実的
［ 2 ］の説明とリンクしますが、最新のEC運営ではCRMやMAなど、外部マーケティングツールの導入が不可欠です。
これらマーケティングツールもEC同様、非常に進歩のスピードが速く常に進化し続けています。
CRMやMAについてもっと詳しく知りたい方はこちら
スクラッチやオープンソースをカスタマイズしたサイトは、マーケティングツールを自由に導入できるわけではありません。
ツール導入のためには、都度、開発のコストと時間が掛かります。
かといって、マーケティングツールであるCRMやMA、WEB接客ツール等を自社開発するのは非現実的です。
マーケティングツールは、クラウド型でサービス提供している各社が「餅は餅屋」で、その領域の最先端の動向に合わせて進化しています。
そういったサービスを、自社・自店のEC事業の成長に合わせて選んでいくほうが、賢い選択だと言えるでしょう。
４．ハッキング対策など情報漏洩に対処しきれるのか？
ECにとって財産ともいえるのが顧客情報です。
これら大切な情報を、どこまで守れるのか？本当に一社で対応できるのか？
訴訟問題を抱え込むことになるかもしれません。
実際に自社開発でカスタマイズしたECサイトの売上規模が拡大してきた頃に、外部からの攻撃によって個人情報漏洩をしてしまい、クレジットカード決済が使えなくなるケースもあります。
また、このような外部からの攻撃をきっかけに、自社開発することを辞めて、ASPやSaasモデルのサービス利用に移行する会社もあります。
５．保守料金が割高になる
ECサイトを運営する際、忘れてはならないのがカートの保守費用。
フルスクラッチやオープンソースをカスタマイズした場合、いくら安く見積もっても最低限 月額 15～20万円 の保守費用が掛かってしまいます。
この金額を聞いて、システム業務に明るくない方は驚かれるかもしれませんが、ご案内した金額はあくまで保守対応に関する最低限必要な費用。
新しい機能を追加する際は、別途、高額な費用が掛かります。
ECにとって「魔法の杖」となるカートはあるのか
ではECオーナーにとって、「魔法の杖」となるカートはあるのでしょうか？
「魔法」と呼べるか否かはわかりませんが、時流に合わせて必要となる機能の追加を自動的に行ってくれる、ASPやSaasモデルは魔法の杖に近い存在といえるかもしれません。
例えばフューチャーショップを例に出すと、2015年にはAmazonPay。2020年には「PayPay」と「d払い」との連携を基本機能として追加。
他にも、多数のユーザーが必要との判断をすれば、自動的に機能追加が行われます。
ECサイトの構築や運営に関する相談も、自社で抱える数千数万の対応事例をもとに、接客・マーケティング・運営の各視点に立って専門家からアドバイスをもらうことができます。
セキュリティー面においても、外部からの攻撃を検知・遮断することができるWAF（Web Application Firewall）を導入しているところもあります。
カート自体がWAFを導入していれば、セキュリティー面で非常に心強いといえるでしょう。
まとめ
我々はマーケター・ディレクター・ライター・デザイナー・システムエンジニア・プログラマーという混成チームだったこともあり、クライアントにフルスクラッチという提案を行いました。
ただ中小規模事業者の場合、我々のようなサポート陣営を丸抱えすることは費用面的に難しいと思います。
その金額を出すのであれば、ASP・SaaSモデルのECカートシステムを利用し、最新の各種マーケティングツールを導入する方が時流にうまく適応し、より高い費用対効果が見込めるはず。
EC事業の成長規模に合わせ、各種外部サービスをうまく取り入れていくのが、コスト面でも自社リソースの配分の面でも現実的
だといえるでしょう。
但し売り上げが100億円を超え、各種開発に3,000～5,000万円の費用を投入できるのであれば、パッケージソフトのカスタマイズや、完全自社開発のフルスクラッチシステムを開発していく選択肢もアリだと思います。
次回のおはなし
ようやくどんなECにしたいのか？の取りまとめと、それを制作する予算が決まった、フルスクラッチEC（自社開発EC）。
しかし今度は、顧客動線が決まらない。
そもそもより多くの集客を狙うための改善案としてフルスクラッチを行うのに、お客さまが迷子になるようなECサイトではリニューアルする意味がありません。
このリニューアルではモバイルファーストインデックスを意識して、デザインをレスポンシブ化しました。
ということは、レシポンシブ化に伴い作業は2倍になる訳で…。
続きはこちらから！ ↓
▼『EC運営奮闘記』シリーズはこちらから一覧で読めます♪
サイト構築にまつわるお話です。