|
私はプログラマになる前,チェーン展開する写真店のサラリーマン店長をしていた時代があります。
そのころ,日々の売り上げや来店するお客の人数について,事細かに記録しておくように上司に言われていました。まだ店舗にパソコンなどない時代です。言われるままに帳票に書き留めてデータを保存していましたが,本部や上司がそれを使って何らかの分析をしたり,指示することは一度もありませんでした。本来ならば,蓄積したデータによって人員シフトを計画したり,商品手配に役立てねばならないデータは,ただの無駄にしか見えない転記作業にとどまっていたわけです。
この話はWeb+DBサイトにも当てはまります。データの蓄積に“だけ”躍起になっている案件は,とても多いのです。活用されないデータは,ハードディスクのゴミでしかありません。ハードディスクの容量は無限ではありませんし,タダでもありません。
企業サイトで扱うデータは2種類ある
前回,データの出所は3経路あるというお話をしました。経路とは別に,Web+DBサイトのデータを“意味”で大別すると,次の2種類が考えられます。
・作るためのデータ
・まとめるためのデータ
商品情報(価格/名称/説明など)は,一覧や詳細を生成するために使用します。これはページを「作るためのデータ」です。ユーザーに見せるためのデータとも言えます。
データベースを使う使わないにかかわらず,商品を選択して販売ボタンを押し,ユーザーが送付先や支払い方法を入力すれば,物販サイトとしての役目は最低限果たしています。しかしそれだけでは,いつ売れたのか,何個売れたのかといった販売に関する情報はどこにも記録されません。
「まとめるためのデータ」というのは,後で統計を出すために使用するデータです。Web+DBサイトを初めて作ろうとする企業の担当者は,往々にして統計ということが頭に浮かばないようです。どういうことなのか少し考えてみましょう。
図1 「作るためのデータ」の考え方 |
図2 「まとめるためのデータ」の考え方 |
商品が売れない理由を分析するためのデータ
サイト構築業者とクライアントの折衝の席で,「ユーザーに対してWebでこういうサービスを提供したい」という話をする場合――商品を検索できて,そこから購入させたい,絞込み検索の機能がほしい,自由入力検索がほしい,別ウィンドウで詳細を出したい…と,ものすごく細かい希望が述べられることがあります。ところが,「その日に売れた商品の一覧確認」「日別売上統計」「リピータ率チェック」などの管理画面機能を考えているクライアントはあまりいません。
例えばECサイトで販売している,ある商品の売れ行きが鈍いとしましょう。この商品が売れない理由は(商品そのものに問題がある部分を除いて)いくつか考えられます。
A)検索すら行われていない
B)検索されるが詳細が見られていない
C)詳細も見られているのに販売に至らない
A)のケースは,そのサイトにあるべき商品だと認識されていない,あるいは何らかの不具合でどの検索にもひっかかっていない可能性があります。
B)のケースは,一覧に出ている情報(値段,外観写真など)の時点で魅力がない可能性が考えられます。
C)のケースは,スペックないし詳細に書かれている内容のどこかが魅力に欠けている可能性があります。
「売れない」という結論は同じでも,売れない理由はそれぞれに違っているわけです。どのパターンに合致しているのかを調べることで,この商品に適切な措置(値下げ,説明やカテゴリーの変更,検索キーワードの再設定)がとれますし,何らかの対策をすることで死に筋商品ではなくなるかもしれません。
このケースで販売に至らない理由が,上記三つのいずれであるかを知るためには,
・その商品に対して検索が行われたか
・その商品の詳細は見られているのか
といった要素を記録しておく必要があります。逆説的に言うと,検索ヒット件数と詳細閲覧件数を記録しておけば,ある商品が売れる理由,売れない理由の分析ができるということです。こうした要素が記録されていなければ,当然分析は困難で「この商品は売れないね」という表面上の結果しか見えません。
データベースはデータを記録するという「器」としての要素以外に,分析を行うための「素材」の要素も持ち合わせているのです。
最初のうちにデータを分析するために必要なことを洗い出しておく
前述したように,サイト構築業者との折衝で検索オプションについて考えるのは,実はそれほど重要なことではありません。商品を検索するにあたって,商品のスペック以外に,検索に用いるべき情報は存在しえないからです。例えばボールペンを販売する場合,
・インク色
・本体色
・芯の太さ
・値段
・説明文
およそこの5点以外の項目はありません。つまり検索はこの組み合わせ以外では作れないのです。
では,その管理画面はどうでしょう。以下のような管理項目が考えられます。
・商品別売上統計
・色別等詳細項目別統計
・販売価格帯分布統計
・日/月/年/時間別売上統計
・検索キーワード順位統計
・詳細説明閲覧回数順位統計
・在庫回転率
・在庫切れ頻度
・購入年齢層/性別統計
こうした管理項目を実現するには,あらかじめデータを記録する部分を用意し,正しく記録できる仕組みを設計しておく必要があります。
しかし開発が完了する寸前になって,「こういう管理画面を増やしてほしい」という追加の要求をされることも少なくありません。依頼する側は「画面を一つ増やすだけなのに」と思いがちですが,開発側から見ると「そんな統計をとるためのデータはとってない」ということもあります。そうなると,データベース設計の見直しにもなりかねず,場合によっては実装不可能というケースも出てきます。
管理画面の1ページ追加は,実はシステムとしては1週間以上も納期延長が必要になるくらい,裏側には大きな変更を要するといことを,覚えておいてください。
Web+DBサイトの依頼を考える場合は,ユーザー側のインタフェース以上に,まず管理側でどういった統計を取りたいのかを明確にしておくようにする,ということです。企業が欲しがっている管理統計画面だけは開発者では想像できませんし,後になってからの追加は,かなりの確率で断られます。
自社業務として必要とされる管理統計項目は,できれば開発会社と折衝する早い段階に提案できるように準備しておきましょう。
仕様書はマニュアルではない
どの開発案件でも必ず「仕様書」という書類が出てきます。仕様書はシステムの大まかな構成や制限について記載した書類です。
一般的には概要の交渉が終了すると仕様書が作成され,双方の合意を経て仕様書に沿ってシステムが構築されます。Web+DBシステムを構築するような場合,データベースを使わないサイトとは異なり,何十ページから何百ページにもわたる仕様書が手元に届くことになります。
初めてWeb+DBのシステムを導入する企業の担当者は,分厚い仕様書にたじろぐかもしれません。しかし必ず仕様書は入念にチェックしてください。一度仕様書に対して了承を出してしまった場合,仕様書に書かれていない管理画面の追加などは困難です。仕様書は取扱説明書ではありません。「開発担当はこの書類に沿ってシステムを構築します」という,いわば約定です。約定としてFIXしてしまう前に,十分な時間をかけて確認し,疑問点はあまさず確認しましょう。
とはいえ現実には,発注主,開発会社ともに中小企業だと,途中で何回もの追加要求が出てきて,システム本番稼動直前どころか,本番運用開始10日“後”(前ではありません)に仕様書が編集されている――つまり今のシステムについて後追いでドキュメントを書いている――といった事例も少なくありません。それでも,そうした悪例を許し続けてしまえば,日本のIT業界はいつまでたっても家内制手工業クラスから脱却できなくなると私は思います。
さて,本連載は今回までを概要編とし,次回からはサイト構築業者との折衝で知っておくと話がスムーズになるデータベースやサーバーの知識について説明していきます。