売れるECシステム開発、失敗しない3つの要件：「コンバージョン率改善」×「在庫の見せ方」=「衝動買い」（1）（1/3 ページ）

ネットショップ（ECサイト）を運営および改善提案されている方に向けて「コンバージョン率改善」と「在庫の見せ方」によって「衝動買い」に導く方法を解説する連載。初回は、この連載の概要や今後の内容を説明し、システム構築において「サービス担当」と「システム担当」の相互理解がシステムの良しあしを決めることについて解説します。

[岩崎善彦，オープンストリーム] PC用表示関連情報

LINE

Hatena

ECサイトでの成功がビジネス成功の重要な鍵

　ネットショップ（ECサイト）が私たちの生活の一部となってから約10年、その勢いはとどまることを知りません。その要因として、ペーパーレス形式の決済代行サービスを開発した「ウェルネット」をはじめ、EC-CUBEなど数多くのECパッケージに対応している「ペイジェント」や代引決済など数多くの決済方法に対応している「GMOペイメントゲートウェイ」など、さまざまな決済サービスが登場したことが挙げられます。

　また、毎日帰宅の遅い社会人にも優しいヤマト運輸の「宅急便受取場所選択サービス」や佐川急便の消費者の情報漏えいに対する不安を解消する代金引換サービス「e-コレクト」など、多種多様な配送サービスの充実が挙げられます。このようにECサイトは非常に身近な存在となりました。

　経済産業省によると、平成26年の日本国内のB to C-EC（消費者向け電子商取引）の市場規模は、12.8兆円（前年比14.6％増）まで拡大しており（※1）、私たちの最も身近な存在ともいえるコンビニエンスストアと同等の市場規模となっています（※2）。

※参考

本連載について

　このように、ビジネスにおけるECサイトの重要性はますます高まっており、ECサイトでの成功がビジネス成功の重要な鍵といえる時代になりました。

　そこで本連載では、ECサイトでの売上向上・安定のための重要な手法として、『「コンバージョン率改善」×「在庫の見せ方」=「衝動買い」』というテーマで、ECサイトにおける効果的な「コンバージョン率改善」方法やユーザー心理を突いた「在庫の見せ方」により購買意欲を強く引き起こす、いわゆる「衝動買い」に導く方法を解説していきます。

　本連載は、下記のような方に読んでいただきたいものですが、該当しない方でも参考になると思います。

「自社ドメイン店」のECサイトの企画や運用を担当されていて、「検索エンジン最適化（SEO対策）やプレスリリース配信などの集客対策は適切に実施して、会員数も多く、商品力もあるはずなのに、なぜか売上が思うように上がらない」という方
お客さまのシステム開発会社として従事しているが、お客さまのビジネス拡大につながる「システム改善提案」ができていない方

　筆者はシステム開発会社（SIer）に所属しており、「システム担当の立場」で長年ECサイトなどの「インターネットサービス」構築に関わって参りました。同時に、さまざまなお客さまの近くで共にビジネスを構築してきた経験から、「サービス担当の立場」の課題についても理解していると自負しております。従って、第1回ではシステム構築においてサービス担当とシステム担当の相互理解がシステムの良しあしを決めることについて解説します。そして、第2～3回に「コンバージョン率改善」を解説し、最終第4回で「コンバージョン率改善」と「在庫の見せ方」によって「衝動買い」に導く方法を解説します。

サービス担当者による「データ構造の理解」は必要不可欠

　ECサイトにおいて「個人情報保護」「負荷対策」「データ整合性」を高いレベルで実現するにはサービス担当者のシステムの理解、特に「データ構造の理解」は必要不可欠です。ここでいう「データ構造の理解」とは「システムにおける注文情報やユーザー情報などのデータを格納する『箱』をどうやって分類するのか」「データの単位となる情報はどれにするのか」、そしてデータを管理するシステムである「データベース」の基本的な仕組みについて理解することです。

　「データ構造の理解」が特に必要不可欠である理由は、システムにとってデータは命であるからです。どんなシステムもデータが間違っていれば何も価値がありません。カーナビゲーションにおいて古く間違った地図データでは目的地にたどり着くことができないのと同じです。

　「個人情報保護」「負荷対策」「データ整合性」のシステム設計において、その実現方法は「データ構造」によっても大きく異なるため、システム担当者は「データ構造」についてサービス担当者に理解できる内容で説明をする必要があり、サービス担当者も「データ構造」の理解をした上でシステム担当者からの実現案の提案に対して適切な判断をする必要があります。

　そこでまず今回は「個人情報保護」「負荷対策」「データ整合性」の重要性について述べ、次にサービス担当とシステム担当との相互理解がシステムにどのような影響を与えるのかを実際の事例を挙げて解説していきます。

システムにおける技術力とは相手の理解度に合わせて説明できること

「個人情報保護」「負荷対策」「データ整合性」の重要性

　事例を解説する前に、「個人情報保護」「負荷対策」「データ整合性」の重要性と、「これらにより、企業やシステムにどのような事象が発生してしまうのか」を解説しておきます。

個人情報保護

　企業にとって扱っている個人情報が漏えいした際の信頼の失墜によるダメージは計り知れません。信頼回復には、まず被害状況の事実確認と情報漏えいに関する事実を素早く公開をする、そして被害者本人への連絡や損害賠償などのお詫びを速やかに行う必要があります。しかし一度漏えいしてしまった情報を完全に回収することはほぼ不可能であり、企業はこのような真摯な対応で企業の信頼とイメージへの影響を軽減することしかできません。つまり個人情報漏えいにより一度失った信用を完全に取り戻せないのです。

　また情報処理学会研究報告の「企業・組織における個人情報漏えい事故の補償について～お詫び金に着目した考察～」（PDF）によると、氏名や住所、性別、生年月日といった個人情報が漏えいした場合の1名当たりの損害賠償額の相場は500～1000円となっており、100万人規模の会員を持つECサイトであれば、数億円の費用が掛かります。さらに、口座番号やカルテ情報などによる二次被害やプライバシー侵害につながる情報が流出したとなれば、さらに多くの損害賠償が必要になりますので、個人情報漏えいは企業にとって致命的なダメージといえるでしょう。

　個人情報漏えいというと「不正アクセスやメールの誤送信、そして盗難が原因である」と想像する方が多いと思います。NPO日本ネットワークセキュリティ協会（JNSA）が発表した「2013年情報セキュリティインシデントに関する調査報告書～個人情報漏えい編～」でも「誤操作が原因」が34.9％と最も多かったと報告されています。不正アクセスやメールの誤送信、そして盗難が原因だと一度に漏えいする件数が多く世間の注目を浴びます。また、有名企業でも同様の原因による個人情報漏えいが後を絶たないため、どの企業もそれらの対策は意識して取り組んでいると思います。

　一方で「バグ・セキュリティホール」による原因は0.5％にとどまっており、世間一般の方も具体的に「どういったことなのか」をイメージできる方は少ないでしょう。それはECサイトを運営しているサービス担当の方にもいえます。しかし実店舗に比べれば、まだまだ信用度の低いECサイトにおいて、もしも自分の購入履歴が第三者に閲覧されていたとしたら、そのユーザーはそのECサイトを二度と利用しないでしょう。たとえ、それが数名だけに閲覧されていたしても被害者からすればECサイトへ信頼は地に堕ちます。そのため情報漏えい対策には万全なものが求められます。

負荷対策

　次に、負荷対策がECサイトに与える影響について解説します。大手検索サイトGoogleでは「表示速度は0.5秒遅くなると、検索数が20％減少する」と報告されています（※3）。また、CDN（コンテンツデリバリーネットワーク）大手のアカマイの報告では、「表示に3秒以上かかるとサイト訪問者の実に40％が離脱してしまう」そうです（※4）。そして、オンライン通販サイト大手のAmazonでは「表示速度が0.1秒遅くなると売上が1％減少する」とのことです（※3）。このようにシステムの負荷増大による影響はシステムダウンや遅延にとどまらず、そのビジネスにも大きな影響を及ぼします。

※参考

※3：Public DNS System and Global Traffic Management（PDF）（Microsoft Researchより）
※4：September 14, 2009 - Akamai Reveals 2 Seconds as the New Threshold of Acceptability for eCommerce Web Page Response Times（Akamaiのプレスリリースより）

データ整合性

　そしてシステムに最も致命的なダメージを与えてしまうのが「データ不整合」です。サービス停止が難しいECサイトにおいてデータ不整合が発生すると、データ補正などの手動対応が長期に渡り必要になり、その運用ミスやデータ量増加による2次災害のリスクを伴い続けることになります。

　このように個人情報保護は社会的信用に、負荷対策はユーザーの離脱やビジネスに、そしてデータ整合性はシステム自体に大きな影響を与えます。

求められるスピードに対して「サービス担当」と「システム担当」との間にできる高い壁

　　　　　　 | 次のページへ