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

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

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

　今やAmazon Web Services（AWS）やMicrosoft Azure、Google Compute Engine（GCE）などのクラウドサービスは、セキュリティの観点から利用を見送っていた企業にもセキュリティ対策の向上もあって、積極的に利用されるようになりました。総務省によると、クラウドサービスを利用している企業の割合は平成25年末から上昇しており、資本金50億円以上企業ではついに7割を超えました（※5）。

※参考

• ※5：総務省「平成26年度版 クラウドサービスの利用動向」

　こうしたクラウドサービスのおかげで、数人の小さな企業でもアイデアさえあれば新しいサービスサイトを立ち上げることが可能になったため、ECサイトの運営者には新しいライバルサイトへの対応スピードが求められます。たとえ、すでに着手中のシステム改善案件があっても、ライバルサイトに後れを取らないためのシステム改修案件は最優先で取り組まなければなりません。

　このような状況においては、システム担当者は「ビジネスとしての突発案件への理解と対応」、サービス担当者は「着手中の案件から突発案件の工数に相当する機能の納期延期」など、両者の相互理解が不可欠です。

　しかし、複数の案件が混在しシステムが複雑になればなるほど、システム担当者は「難しくてどうせ理解してくれない」とサービス担当者が理解できる内容で対策案の説明ができていないことが多いのです。サービス担当者からすれば、難しいことは全てオブラートに包まれてしまうため、システム担当者の言い分を心から信用することができず、対策案を承認できないなどのケースが少なくありません。

　こうなってしまうと、サービス担当者とシステム担当者とが良い信頼関係が築けずに壁ができてしまいます。両者が本音で会話できないだけではなく、システム開発にも支障を来します。

システム担当者とサービス担当者とが相互理解を深める方法とは

　ここまではECサイトにおいての「個人情報保護」「負荷対策」「データ整合性」の重要性とその影響、そして近年求められるスピード対して、サービス担当者とシステム担当者の相互理解でよくある課題について解説しました。ここからは、その相互理解を深めるための事例を紹介します。

　なお、これから紹介する事例はシステム担当者からすれば技術的には至極初歩的な内容です。ポイントは「技術的にどうこう」ではなく、「システム担当者は下記の事例のようにサービス担当者に対してデータ構造を理解してもらっているか否か」という観点で、そしてサービス担当者は「システム担当者から下記の事例のように説明を受けて、かつその内容を理解しているか否か」という観点でチェックしていただきたいと思います。

「データ整合性」「個人情報保護」にまつわる事例

　まず「データ整合性」「個人情報保護」にまつわる事例から紹介します。

　あるECサイトでは通常の配送が必要な商品のみを扱っていたが、2010年前後から注目されているOnline to Offline商品（以下、O2O商品）や、大きな集客効果がある抽選商品など多種多様な商品を扱いたいとサービス担当者から要望が挙がった。通常商品は注文ごとに配送先の情報が必要であるが、O2O商品では必要がない。また抽選商品は通常商品に比べて「エントリー状態（未当選）」や「当選」「落選」などの注文の状態を管理する情報が必要になる。そのため、扱う商品の種類によって必要となる「データ構造」は異なるのである。

　今回は、ひとまずO2O商品のみを対応したいと要望を受けたシステム担当者は「商品の種類によって注文情報データを格納する箱を分ける必要があるため、工数が掛かる」と説明し、さらに万が一に備えて分けた注文情報の注文IDが決して一致しないように大きく離して採番することを提案した。

例

通常商品	1〜999999999（10億未満）
O2O商品	1000000000〜（10億以上）

　ここでシステム担当者からサービス担当者に「データ整合性」と「個人情報保護」の観点からだという説明だけで済ましてしまうと、「わざわざデータを格納する箱を分ける必要が分からない」「1つのままなら、工数が減るのか？」「注文IDは管理上できるだけ間を空けたくない」とシステム担当者の提案が通らない。

　では、注文情報データを格納する箱が単一だと、どのような事象が発生してしまうのか。実際に筆者がシステム担当者としてサービス担当者へ説明している内容を解説しよう。

　データベースには「この情報には数字だけしか入れられない」「この情報は100文字までしか入れられない」「この情報は必須」などのようにルールが設定できるため、極力そのビジネスや業務合わせたルールを設定するべきである。データを格納する箱が単一だと通常商品で設定しておきたい「住所情報が必須」というルールが設定できず、もしアプリケーションで住所情報の必須チェックの漏れがあれば不完全な注文データが登録されてしまい、住所情報を参照する処理において、あるべきはずの住所情報が存在しないためにエラーとなってしまう。それをアプリケーションで全てカバーするとなると、住所情報を参照する全ての処理において注文情報の「データ存在チェック」が必要となる。

　要は「データ不整合が発生するかもしれない」状態を「正」としてシステムを構築し、そのデータ不整合をアプリケーションにて力ずくでチェックして対応することになる。先述した通り、そのチェックが漏れれば、たちまち大きなトラブルへと発展する可能性が高い。ここで、データを格納する箱が分かれていれば通常商品の注文情報に「住所情報は必須」というルールを設定できるため、もしアプリケーションの住所情報の必須チェックが漏れていても最悪登録時にフロント画面でエラーとなるため、注文データは登録されずデータ不整合は『絶対に』発生しない。また住所情報を参照する処理においても、注文情報が格納されていれば、住所情報が必ず存在することが保障されるため、関連する処理全てがシンプルに設計できる。

　次に、分けた注文情報の注文IDが重複しないように大きく離して採番する対応であるが、これは注文情報データを格納する箱を分けたことで発生し得る個人情報流出を未然に防ぐための対策である。

　もしも、通常商品とO2O商品とで参照する注文情報データの箱を判断する処理にバグがあり、誤って別の注文情報データを格納する箱を参照してしまい、かつ同じ注文IDが存在した場合は、どうなるだろうか。いわゆる個人情報流出の発生となる。少しシステム的な話をすると、参照時にユーザーIDなどのその他の指定があれば防げる可能性はあるが、その指定を忘れてしまうというバグが発生すれば防げないのである。アプリケーションのサービスが開始すると、データ構造は大きく変えられないが、アプリケーションのバグはリリースのたびに発生する可能性がある。それに、システムの仕様を理解した初期開発メンバーがいつまでも、そのシステムを担当するとは限らない。

　筆者は上記のような内容を企画や営業、運用担当の方に対して説明し、時間がかかっても全員に理解してもらっています。