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

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

[岩崎善彦，オープンストリーム]

「負荷対策」にまつわる事例

　次に「負荷対策」にまつわる事例を紹介します。

　「ユーザーの問い合わせに柔軟に対応するため、管理画面において注文情報に対して既存の検索項目のユーザーID、注文ID、商品ID、注文日時に加えて、商品属性、電話番号、性別、住所……などできる限り多くの項目でリアルタイムに検索したり、対象のリストを出力したりしたい」とサービス担当者から要望が挙がった。

　しかし、システム担当者は「システムの負荷が上がるため」と十分な説明をせずに対応を拒んでしまった。納得できないサービス担当者は「なぜ既存の4項目が良くて、その他の項目はダメなのか」「1つだけの追加だったら平気なのか」「1つの検索項目追加でどのくらい負荷が上がるのか」などの追究が強まってしまう。サービス担当者としてはユーザーへの対応が絡むため敏感に反応してしまうからだ。また、その上司への報告（検索項目を増やせない）に必要な材料もなくサービス担当者自身が最も困ってしまうであろう。

　では、このケースにおいてはどのように説明すれば良かったのか。こちらも実際に筆者がシステム担当者としてサービス担当者へ説明している内容を解説しよう。

　データベースはデータの単位、注文情報であれば注文IDでの検索は非常に高速である。例えるならExcel行数。何番目であろうとスクロールすればすぐたどり着けるだろう。

　また、データベースの機能の一つである「インデックス」を利用すればデータの単位である注文ID以外でも高速に検索が可能となる。

　例えば注文情報の中にユーザーIDがあり、そのユーザーIDにインデックスを適用すると、注文情報が登録されるたびに注文情報とは別に「インデックス情報」が登録される。そのインデックス情報には「ユーザーIDとそのデータが注文情報のどの位置に格納されているのか」を示す位置情報が登録される。さらに、そのユーザーIDで昇順に並び替えられた上で、均一な塊に細分化される。そのため、ユーザーIDが指定された検索の際は、そのインデックステーブルを参照してから注文情報を参照するので、高速な検索が可能になる。逆にユーザーIDにインデックスが適用されていないと、注文情報が1000万件あれば1000万件全てを対象にデータを探すため非常に時間がかかり負荷も増大してしまう。

　「それならば全ての項目にインデックスに適用すればよいのでは」と考える方もいるだろうが、残念ながらインデックスは万能な機能ではなく、むしろ「もろ刃の剣」として扱うべき機能である。なぜなら、インデックスには「登録時の負荷が上がってしまう」問題と、「データ容量が増加する」問題があるからである。つまり、データが登録されるたびにインデックスを適用した項目分のインデックス情報が登録されるので、適用した項目が10個あればデータ登録回数だけでも10倍の負荷が掛かる。

　また注文情報などのようにシステムの大半のデータ容量を保持するデータに対して、それだけのインデックスを適用すれば、それだけでデータベース全体のデータ容量が何倍にもなる可能性があるため、注意が必要だ。諸説あるが、1つのデータを格納する箱に対してインデックスは3〜5個までに抑え、それを超える場合はデータ構造自体の見直しをする方が良い。

　筆者は上記の事例が最も遭遇率が高く、サービス担当者とシステム担当者との相互理解における最重要ポイントだと思っています。

　よく管理画面だからといって新人エンジニアなどに開発させて、上記の視点を怠っていることがあります。そのままサービス担当者がその管理画面からインデックスの効いていない検索項目でポチポチと検索してしまうと、データベースの負荷が一気に大きくなり、いくらフロント画面の負荷対策をしても意味がなくなってしまいます。

　負荷対策されたフロント画面への何百万アクセスよりも、負荷対策を怠った管理画面でのたった一度の検索の方がシステム負荷を上げるかもしれないのです。

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

　システム担当者の方は上記のようにサービス担当者に正しく問題の本質を理解していただけるように説明しているでしょうか。できればその都度相手に合わせた資料を用意して、専門用語を使わずに、相手の理解度に合わせた説明をすることが望ましいでしょう。よく「知識は人に教えることができて初めて身に付く」と言いますが、「システムにおける技術力」とは「相手の理解度に合わせて説明できること」だと筆者は考えています。

　資料作成は時間がかかりますが、サービス担当者との認識合わせがスムーズになるのなら惜しむべき労力ではありません。またサービス担当者の上司を意識した資料作成も必要です。これはトラブル報告時にエンドユーザーへの報告を意識するのと同じです。スケジュール変更の相談を普段やりとりしているサービス担当者に何時間もかけて説明し理解してもらっても、サービス担当者がその上司にうまく報告や説得ができなければ、その相談は結果的に却下されてしまうでしょう。

　システム担当者の多くは、新しいビジネスを誕生させる、また自らの営業活動で売上が上がるなどの喜びを感じる機会はありません。また常に自分が希望するプロジェクトへ配属されることは非常に“まれ”なケースです。そのようなシステム担当者にとってはサービス担当者に感謝されることが何よりの喜びであり、感謝されることで積極的なシステム改善提案などのモチベーションにつながります。それは筆者のようにオンサイト開発の経験が多いシステム担当者には特にいえることです。

　サービス担当者もシステム担当者から根気よく説明を受け、システムを理解していけば仕事への向上心が生まれ、システム担当者に頻繁に相談するなどして、信頼関係は飛躍的に高まっていくでしょう。

　ビジネスにおける目指すべきゴールはシステム担当者もサービス担当者も同じです。両者が密接に絡み、お互いに理解することがゴールへの最大の近道になります。

業績好調ECサイトの売上の8割を占める「リピート売上」その改善方法とは

　今回は、主にシステム担当者からサービス担当者への相互理解をターゲットに解説しましたが、逆にサービス担当者からシステム担当者へ相互理解を深める事例も今後紹介していきたいと思います。

　次回は「コンバージョン率改善」対策として「リピート売上」の改善方法について解説したいと思います。ECサイト運営における一般的な内容ですが非常に重要なポイントですのでチェックしておいてください。

筆者紹介

岩崎 善彦（いわさき よしひこ）　株式会社オープンストリーム

1978年生まれ。神奈川県横浜市出身。2001年からシステムエンジニアとして電子商店街（ネットショッピングモール）および宿泊予約などのECサイト、広告配信、動画配信、携帯電話キャリアサービス、SNS（ソーシャルネットワーキングサービス）に携わる。10年以上にわたり複数のネットサービス企業に入り込み、お客さまのビジネス拡大に向けて従事している。現在はグループ長として複数のB to CのネットサービスプロジェクトのPM（プロジェクトマネジャー）を担当している。