昔の購買過程と、インターネット時代の購買過程では違うそうな、ってこれって衝動買いでは（＾＾；）

　放送大学大学院、総合情報学（’０６）によると（テキストP３１、第二回）、

　昔の商品を買う購買過程と、
　インターネットによる商品の購買過程でちがいがあるそーな。

---

　昔の購買過程は、AIDMA（アイドマ）と呼ばれるもので、以下のように、購買過程が進みます

　認知(Attention)：ほお、こんなものが売っていると知る
　↓
　興味(Interest)：興味を持って調べる
　↓
　欲求(Desire)：買いたいと思う
　↓
　記憶（Memory)：商品を買うことを、記憶にとどめておく
　↓
　行動（Action):お店に行って買う

　頭文字をとって、AIDMAといいます。はい。中小企業診断士のお勉強で、勉強した気がします。
　ここの特徴は、「記憶する」という過程が入ることです。

　買いたいと思っても、お店に行かなけりゃ買えません。
　持ち合わせが無ければ、買えません。

　なので、その間記憶しているわけですが、そーすると、忘れるっていうことももちろんあるけど、冷却期間もあるわけです。例えば、買いに行こう！と思っても、いやまてよ。。高くないかあ？とか・・
　したがって、興味を持ち続けさせることが重要なわけです。

---

ところが、インターネット時代は違うそうです

　認知(Attention)：ほお、こんなものが売っていると知る
　↓
　興味(Interest)：興味を持って調べる
　↓
　検索(Search)：ネットで検索してお店を調べる
　↓
　行動(Action)：その場で発注・購入
　↓
　情報共有(Share)：メールやブログで買ったことをいろいろ話す。

　つまり、検索して、お店が見つかったら、もう、行く必要が無く、すぐに買えて、すぐに決済です。記憶している必要は無いです。お店に行かなくていいし、カードがあれば即決済ですから。。

---

　って、これって、よーするに、「ネットは一歩間違えば衝動買い！」って言ってるような気が。。

　たしかに、それはありますよね。

　カード決済の場合、お金は出さないので、１０万円、２０万円といっても、その重みというのは感じられない。
　とくに、これはカード決済ではないけど、株の信用取引なんかそーです。
　３０万のものを買いを入れたり、ふつーにしますけど。。
　３０万円って、すごいっす（＞＿＜！）

　ってなことで、ネットの場合、すぐにお店を見つけられて、すぐに買えてしまい、決済のときにあんまりお金の重みを感じないので、今までの購買パターンとは、ちがうかもしんない。
（知らず知らずのうちに、無駄遣い？）

家庭用電話機をスカイプに利用できるアダプタ「すかい楽」

こんなニュースが

イーレッツ、家庭用電話機をスカイプに利用できるアダプタ「すかい楽」
http://bb.watch.impress.co.jp/cda/news/13684.html

一瞬、「おお、これいいかも、入れようかな。。」って思ったけど、
冷静に考えたら、スカイプで話さなきゃいけない相手は、いなかった（＾＾；）
あ、入れてもムダだ・・・

ケータイ、webアプリで必要な「ファイル等のデータをどこに置くか」戦略（その１：置き場所）

　ここに書いた、ファイルをどこにどう置くかという戦略について。

---

■なぜ、そんな戦略が必要か

　FlashやJAVAScript、Javaのアプレットを利用したプログラムの場合、参照・更新できるデータがある場所というのは、（セキュリティ上）限られている。ローカルのファイルを、基本的に更新・削除できないなど。

　また、ケータイの場合、ＢＲＥＷは、そんなに容量的な制限を感じないかもしんないけど（なことない？）、iアプリなどでは、容量的な制限があるかもしんない。

　てなことで、データをどこにどのような形で置くかということを考えないと、システム的な処理スピード上、問題が出ることがある。

　たとえば、商品コードを入れたら、商品マスタを参照し、単価を表示するといった場合、商品マスタがサーバ側にあると、必ず、サーバー通信が入る。そうすると、商品１件ごとにサーバーと通信しないといけなくなり、入力が極端に遅くなって、実用にならなくなる。
　このようなことを避けるために、データのおき場所戦略が必要になる。

---

■戦略の立て方
　戦略には、次の３ステップがある
第一ステップ：どこにおけるか考える
第二ステップ：どんなデータがあるか考える
第三ステップ：どんなデータをどこに置くかを考える

今回は、まず第一ステップについて考える

---

■第一ステップ：どこにおけるか考える

　データを、どこにおけるか、そしてどうやってアクセスするか考える。
　この場合、今回、話題がクライアントなので、クライアントを中心に考える。
　なお、ここであげた置き場所は、考えられるものを挙げただけで、実際の場合は、この中にも使えないものがある（ケータイの場合、環境変数って？のように）

おき場所

（１）サーバーにおいて、サーバー通信で取得する
　サーバーに、ファイル、ＤＢ，プロパティファイルの形でおいておき、サーバーと通信することによって、値を取得する。一般的な方法である。
　クライアントの立場から考えているので、サーバーでは、どんな形（ファイルかＤＢか）ということは問わない。とにかく、サーバーにあるものは、クライアントは通信して取ってくることになる。

（２）クライアントの環境変数
　クライアントの環境変数の中に入れる。
　一般にこの場合は、
・複数のアプリで利用するもの
・（後述の各プログラムの）プロパティファイルのありか
　を入れておくのがいい。なんでも環境変数にいれてしまうと、バージョンごとの競合が起こったり、予期しないアプリ同士の名前の一致で変な動きになったりする危険があるので。

（３）プロパティファイル、INIファイル
　クライアントの中にあるプロパティファイルや、INIファイル。
　クライアントのプログラムごとに、独自のデータを入れとくのに都合よい

（４）クライアント側のファイル、ＤＢ
　クライアント側にファイルを持つ。もてないものもある。
　制約は、いろいろある
　また、BREWの場合、IDATABASEを使って、クライアント側にＤＢっぽいものももてる。
　ある意味、ケータイのアドレス帳もＤＢとみていいだろう。

（５）プログラムの中に埋め込み
　短いコードなどでありえるのだが、プログラムの中にコードとして埋め込んでしまう。
　たとえば、Webアプリの場合、性別：男、女は、これ以外、普通ないので（ということにしておく）
＜Select name=seibetsu size=1>
　＜option value=1＞男＜/option＞
　＜option value=2＞女＜/option＞
＜/selected＞
としてしまって、もう、男、女を１、２で返すものと、ＨＴＭＬファイルの中で埋め込んでしまうのもありだ。星座、血液型、都道府県、などなど、この手は結構いっぱいある。
　Javaの場合は、static finalの形、Ｃなどの場合はdefineにする。

（６）データを返すアプリをつくる
　あんまり言われないけど、こーいうことも考えられる。
　アプリ側で、値を返すアプリを作ってしまい、そいつを呼び出すということだ。
　これが、サーバー側にあると、ＳＯＡということになる。

（７）外部から
　ＱＲコードやＩＣタグなど、外部からデータを持っているものを取り込むケース。
　現在は、コードのみだが、ＱＲコード等の場合、データだけでなく、商品名、単価を持つことも、可能である。

---

■実際には
実際には、ケータイの場合、
（１）サーバー、
（４）ファイル
（５）プログラム埋め込み
（（６）データを返すアプリもあり？）
（７）外部から
が利用可能であり、

JavaScriptの場合、
（１）サーバー、
（４）ファイル（読み込み）
（５）プログラム埋め込み
が中心となる。

---

っていうことで、今回はおしまい。続きの「第二ステップ：どんなデータがあるか考える」については、また気の向いたときに。