A Django site.
10月 26, 2008
» お問い合わせの窓口が変わりました

弊社の顧客向けのお問い合わせ窓口であるサポートセンターのURLがwww.designbomb.biz/support から support.ds-style.com に変わりました。

URLが変わっただけで、何か新しくなったことはないのですが今までと違ってメール、ウェブ、チャットのすべての文字コードがUTF-8化されたので、これでメールやチャットで3バイトだろうが、4バイトだろうが文字化けを心配する必要もなくなりました。

日本製の主要なメールクライアントでは受信確認(文字化け対策OK)ができているので、この先国際化してお客様で外国の方が増えても大丈夫な体制ができたと思います。
サポートセンターは多言語化されています。日本語と英語で表記が可能。
参考)
ウェブサイトでメールアドレスを公開するときはこのツールを使用してメールアドレスを暗号化してスパム対策しておきましょう。

各部署のメールアドレスは今までは公開していませんでしたが、サポートセンターのウェブサイトに公開したので、今後は直接メールを送ってもらっても大丈夫です。メールは2重バックアップの意味でGmailからIMAP経由で自動取り込みがかかっているので、顧客からのメールはサポートセンターからも、Gmailからも見れるようにしました。
ネットビジネスの場合、1つの大事なメールアドレスを万が一に備えて、2つ目のサーバでメールホスティングしておくことはとても大事なことだと思います。
Gmailは本当に役立ちます。

これで、お客様とのコミニケーションはeSupport + Gmail という私なりのアイディアではありますが、ひとまず考えられるものとしては国内最強のサポートバックエンドをもった企業であると自負します!
IT系上場企業や、サポート対応に追われるASP系プロバイダよりも遥かに高度で、自動化されています。(と思っています。)

ちなみにメールのスパム対策ですが、弊社ではスパムアサシンをメールサーバ側に組み込んでおり、スパムの判定度をあえて一番弱い「1」に設定して、スパムボックスへの自動削除をOFFにし、スパムと判定された場合には件名に 「**** SPAM **** 」と付記されるようにセッティングしています。

これはeSupportがスパムメールも同時に取り込みしてしまうというデメリットはありますが、メールの件名から取り込みのルール作成をすることができるので、サーバで自動削除されてしまうよりは安心です。
顧客から送ったけど届いていないといった場合にも、スパムフォルダで検索できるようになります。

そして、SKYPEに変わるテキストベースのチャットが顧客サポートのツールの1つとして追加されたので、時間がなかったり即答を求めたいビジネスニーズにも答えられるようになりました。

先日よりお気づきのかたもいると思いますが、弊社のウェブサイトのヘッダー部分(ページの上部)に”Live Support” というアイコンをクリックするとオンラインでチャットが開始できます。
Skypeのようにソフトをインストールする必要はありません。ブラウザベースでのチャットです。

私の最終的な目標は、インターネット上で起こるさまざまな問題をウェブサイトと(今回の)サポートツールを使用して自己解決できる仕組みを作ることです。

サポート業務は受ける側(弊社)も、発する側(お客様)もそれぞれエネルギーが必要だと思います。
そのエネルギーの消費をITでできる限り小さくして、限り早い段階で解決できるお手伝いをし、お客様のビジネスをより加速させ、価値を高められるような提案をできるように、弊社自身がこういったツールの開発と研究に業界の先端企業として走り続けたいと思います。

10月 1, 2008
» ホームページの表示スピードを高速化することによって得られる利益はいくらですか?

最近妙にホームページを高速化するという分野にとても興味が膨らんできています。
ホームページの表示速度を上げることは、自動車でいう改造ですな。小学生の頃に600円のミニ四駆プラモを買ってきて、ワイドタイヤにしてハイパーダッシュモーターに変更して……
少しでも速く走るようにしていることと、根本的にやっていることは変わらないです。
基本的に、私は改造が好きなんです。

ミニ四駆を例に出しましたけど、ホームページも表示するスピードは速い方が得することがあると思います。物販サイトであれば、特にその恩恵は大大大!だと思います。

先日、私のブログを読んだ購読者の方から

ホームページの表示スピードを高速化することによって得られる利益はいくらですか?

という質問をいただきました。

正直ホームページの表示速度を速くしても利益が増えるなんてこれぽっちもありませんが、速くしなければならない原因が分かっているのであれば、高速化することによるメリットは大きなものになると思います。

説明するまでもないですが、ホームページの表示が遅ければ、ユーザーは次のページが表示するまで待たされることになります。これが1秒以内ならまだしも、2秒、3秒となるとその“もたつき“が原因でイライラし、ホームページを閉じてしまうか、他のサイトに行ってしまうと思います。(私ならサイトを閉じます)

これが年に数回ならまだいい方ですが、1日に5回も6回も“もたつく“減少がみられる場合、かなりの機会損失をしていることになると思います。損失金額に直すと….(想像してみてください)

機会損失を防ぐためにホームページが常に一定の表示速度が保たれるような保守メンテナンスが必要だと思います。そして現状の利益を圧迫しない程度の運用コストで、この品質が保たれるのであればECサイトの新たな投資対象の分野になるかと思います。

話はちょっとズレますが、SEOは検索エンジン最適化ですが、勝手に命名しましたが、SEOと連動して、WOSO(Website Optimization and Speed Optimization)も必要なのかなと..。

ただSEOはすべてのサイトでパフォーマンスが上がるのに対して、WOSOはECサイトなどのユーザーに何かのサービスを提供するホームページでないとあまりその効果のリターンがないのでやってみてもしょうがないのかなと。

もう少し突っ込んで、
ホームページの表示を早くする手段はいろいろありますが、一番手っ取り早いのはサーバにつながっているネットワーク速度を上げて、サーバのスペックをいいものにすればとりあえはすぐに速くできますよね。

ただ、この方法だと出力部分のフロントであるHTMLとかを最適化したわけではないのでハードウェアによって高速化されただけなので、HTMLレベルやサーバのアプリケーションレベルで最適化してあげるとこの前書いたようなパフォーマンスが確実に出ます。
あなたのサイトはいかがでしょう?

これをビジネスでなんてことはまだ考えていないのですが、みなさんが身近に使われているosCommerceやZencartにWOSOを施術した場合、WOSOによってどの程度ユニークユーザー数、ページビューが増え、日あたりの注文件数がどれだけ変化するのかを実験していきたいと思います。ここはとても興味ある所だと思います。

9月 29, 2008
» 2時間の作業で34%ホームページを高速化

先日ブログでレビューした、「高速サイトを実現する14のルール」の件ですが早速自社サイトでやってたのでレビューしておきます。

タイトルに書いたとおり、結果的には34%の改善ができたわけですが、書籍には50%以上の期待ができるとか書いてある割には、そこまでは行かなかったものの、本当に高速化されたのには確かにビックリ。

高速化の対象にしたサイトは[eSupport] のホームページ。このサイトは全部で30ページほどある単純なHTMLで作成された静的サイトなので今回の試し台にはピッタリ。

14のルールがある内の今回トライしたのは以下の4項目
・ルール1 HTTPリクエストを減らす
・ルール3 Expiresヘッダを設定する
・ルール4 コンポーネントをgzipする
・ルール10 javasciptを縮小化する

計測はWebSiteOptimization.com にある分析ツールを利用し、Download Timeという項目で実行前と実行後の時間差でパフォーマンスを計測することにした。

他にもルールが書籍には掲載されているが今回のサイトには当てはまらなかったので、とりあえず上に挙げた4つのルールを実行した結果が以下の表。
作業にかかった時間は約2時間、主に画像の再スライスと、CSSの再設定、Apacheの設定変更である。
T1接続で4秒も高速化に成功し、34%改善されている点に注目。128K接続は今の時代にはないが、実際には約6秒の高速化に成功。

Connection Rate ダウンロードタイム

(改善前)

ダウンロードタイム

(改善後)

14.4K 282.44 seconds 240.88 seconds
28.8K 146.32 seconds 123.74 seconds
33.6K 126.87 seconds 107.01 seconds
56K 80.20 seconds 66.84 seconds
ISDN 128K 31.64 seconds 25.05 seconds
T1 1.44Mbps 12.06 seconds 8.20 seconds

確かにサイトは見るからに高速化されていて、表示スピードが早いのには体感できる。

今までホームページの制作過程の中では一度も見直すことがなかったホームページの高速化であるが、商用サイトの場合で数百から数千ページを動的生成させているサイトなんかだと、ページを高速化することで、日当たりのページビューが増え、1日あたり、年間あたりで計算した場合には相当なPVの増加を期待することができる。また検索エンジンフレンドリー、ユーザーフレンドリーなサイトになることは言うまでもない。

今回試したこの手法のもっとも気に入った点は、サーバのハードウェアをカスタマイズしたり、データベースへのSQL文などハードやアプリの根幹を一切いじらずして、Apache系のカスタマイズだけで高速化を実現できる点が制作側からするとフレンドリーである点だと思います。

ユーザーからサイトのスピードに文句言われる前に、少なくとも商用サイトであればこの手の手段はできる限り早い段階でやっておくことをオススメします。

9月 27, 2008
» 3年後くらいのECサイト業界はサービスとしてのソフトウェアへ変身できるか

SAASモデルは2012年までに8000億円市場になるらしい..。(本当か?.)

だとすれば、(旧来のオフライン)パッケージソフトの販売を行ってきたベンター達はサーバにパッケージソフトをインストールし、フロント部分をHTML化するだけで、ユーザーへデスクトップ環境と同じ形でネットワークを介したさまざまなサービスを再び提供するのではないかと思われる。90年代後半に盛り上がったASP時代が再び到来するようなもでしょう。

ネットワークを介してサービスを提供するとなれば、これはもはや非OS依存型のサービスになるので、Windowsの存在はどうなるのやら..。

最終的に、デスクトップに残るアプリケーションは、インターネットとメールだけになってしまうのでしょうか。

これを私の業界に当てはめて考えてみると次のような構図が見えてくる。

ウェブデザイン

ウェブデザインはクリエイティブな感覚が必要とする人間味あるサービスであるため、ソフトウェアとすることは難しい。ウェブデザイン自体の作成方法や作成技術は進化するかもしれないが、デザインを考案するクリエイティブな部分はどんなに時代が進もうとソフトウェア化できないのでSAAS化されることはありえない。

ECサイトの運営形態

ECサイトのソフト自体は自社サーバにインストールする自社運営型とモール型(楽天やYahooなど)の両方にそれぞれのメリットがあるため、今後も同時に進行されると思われる。これは今とそんなに変わるものではないと思われる。

ECサイトの販促系機能

ECサイト構築ソリューションとして、広告、アフィリエイト、アクセス解析、動画配信、アンケートフォーム、ヘルプデスクなどの各機能を補完すること自体が無意味なものになっていき、これらの機能ははいずれも全てSAAS化またはプラグイン(機能保管モジュール)化され、すべてが月額制で利用できるようになる。

受託システム開発だと、要件定義を出す側も、それを受ける側もそもそも共通言語を使ってだれも難しい話し合いなんかしたくない。日本にはいまだに共通のフォーマットがないから、プログラマと発注者でお互いが同じ言語感覚で話し合うことなどしたら、喧嘩になりがち。

受託はバージョン管理も、バグ管理も全てにおいて手間がかかる。受託がなくなることはなくても、受託を発注するプロセスやそのフローが何かSAASモデルによって改善されたらいいなと願ってます!

ECサイトの販売・顧客管理系機能

ここは、大幅に変更される可能性の秘めた領域だと思う。もっともベンダーの参入が多いと思われる。

現状のデスクトップアプリケーションで管理している受注管理や販売管理ソフトはすべてネットワークを介してサーバで管理されることになるだろう。業務系ソフトをSAAS化することにより、エンドユーザーは注文の編集やキャンセルを行いたいときに、メールや電話で連絡するのではなく、ログインをして自分の注文状態を確認し、自由に注文変更やキャンセルができるようになる。

懸念事項としてSAAS化することで全データをネットワークの向こうにあるサーバに保存することの抵抗感やセキュリティー不安の問題がある。

2重、3重のバックアップや、99.9%のアップタイムを保持できるだけの保守体制基盤作りにSAAS業者はコスト増を強いられ、この部分がSAAS化産業の成長の鍵になると思う。データセンターやセキュリティー系ベンダーがSAAS化を促進できるだろうか。専用サーバのホスティングサービスはホームページのホスティングから、データ保管のホスティングサービスに変化するのだろうか?

顧客サポート系機能(ヘルプデスク)

電話対応、メール対応などの顧客対応履歴を含むカスタマーサポートに必要な機能はSAAS化される。ホームページに必要なフォーム機能は、すべて月額制で利用できるようになる。

9月 8, 2008
» 自宅や社内でサーバ機を設置している企業や個人向けの年間6万円のサーバ障害保険?

約年間6万円で、意外にもサーバ障害時に保険的役割を担ってくれるソフトウェアがあったのはご存知でしたか?

データセンターに設置して、保守契約を結んでいれば話は別ですが、
そうでない場合、特に自宅や社内でサーバ機を設置している企業や個人にとって、寝ている間におこる障害が悩みの種であることは間違いないはずだと思います。

これを解決するにはサーバ系ベンダーとの保守契約やデータセンターレベルでの保守契約となるとおもんですけど、その額や高額になることがあります。サーバ1台の24時間オンサイト、オフサイト監視・一時対応、OSレベルでのセキュリティーパッチ更新、までやると最低でも月額5〜10万円程度でしょう。
サーバ費用以外に、これは痛たたたた…。

そこで、
ベンダー系のガッチリした保守までとはいかなくとも、もサーバに障害が発生したときにソフトウェアレベルで自動的に復旧してくれたらなんていいだろう。そんなソフトは果たしてあるのか?

実は弊社がサーバ管理ソフトとして販売しているcPanelでできてしまうんです!
この機能はサーバ管理者しか知らなくて、今まではホームページに紹介することはありませんでした。

今回cPanelのページに、サーバ保守系のページを新たに作成し、サーバ保守に対しする格安なソフトウェアとしても利用いただけることがわかったのでこの際、社内のサーバ保守にご活用ください。

サーバ管理費をできるだけ抑えるために

7月 29, 2008
» Skypeでのお問い合わせ - 遠方、海外のお客様の為に

今までスカイプというツールを社内部のコミニケーションツールとしての利用目的で使っていましたが、昨日からウェブサイトにもオンラインステータスを表示し、本格的にスカイプをお問合せのフロントラインとして使い始めました。
遠方や海外にお住まいの方で、対面での新規打ち合わせが現実的でないお客様はこちらをのページをどうぞ。

IT製品の場合、画面を見ながらサポートや商品の説明をしないと、相手に本当の理解は伝わりずらい。

お互いが同じ画面を見ながら、音声付で説明し、一緒に動作を体験することが、最も効率的な商品説明になると思います。

それにはスカイプがとても便利だと改めて感じます。

URLを直接送ったり、画像ファイルを送るのにもドラッグ&ドロップでできるので、これが電話だとURLを説明したりするのにも一苦労。。。

お問合せのページは次の通り。
新規のお客様の場合はこちらのような画像が表示されます。オンラインの場合、スカイプのオンラインボタンをクリックするだけで使えます。

サービスをご利用中のお客様はサポートセンターのページで部署を選択するときに、スカイプボタンを新設したので、直ぐに回答を求めたい時には役に立つと思います。

今回書いた海外、遠方のお客様をスカイプでサポートするという件ですが、会社案内のデジタルスタジオでは… にも追加しましたので、今後遠方のお客様にはぜひ活用いただければと思います。

7月 19, 2008
» 時差のなくなるコンテンツ業界?

世界中のありとあらゆるコンテンツサービスにおいて、時差はますますなくなってきたと思う。
アメリカ発のベンチャー企業が何らかのWEB2.0的サービスを公開したとすれば、その1ヶ月後、2ヶ月後には日本の品質で同じサービスが生まれる。サー ビス品質(顧客サポート、画面デザイン、説明補足)は異なるものの、アイディアやロジックは全部アメリカ生まれのものになる。違うのは日本人の品質に直す 必要があるだけだ。

こういったことが、今の時代は当たり前になったのだと思う。
どの国のサービスでも日本流に直してすぐにサービスインできる環境が今はできているのだと思います。
僕がこの世界でビジネスを始めた2003年は、アメリカ発のITビジネスをこれでもかってくらい毎日ウォッチングしてたけど、今や、その必要もなくなりま した。海外ウォッチャーと呼ばれるヘビーブロガーによりほとんど時差なくして日本に毎日のようにして何らかのサービスが紹介されていて、どんなサービスか はすぐに確認することができる。

例えば、GoogleCheckoutは現在日本のサービスとしては提供されていませんが、すでにアメリカで多くのユーザーを獲得しているのに、なぜ日本の決済業者は○○○チェックアウト的なサービスをやらないのだろう…. と思ってしまう。
僕がもし決済インフラを持っていれば、同等のビジネスモデルをすぐに作り、名の知れた大手企業と組み、違った名前ですぐにサービスインなんてことも考えてしまう。

ただ、日本ではこういうことをやりたいと思ったベンチャーに対しての資金調達インフラがアメリカほどよくない。だから新しいサービスが活発に生まれないのだろうと思う。アメリカのように株主ありきではなく日本の家族型経営ではやはり資金調達は難しいのか。

こういう現実の中で、僕が最近とても感じることは、長い目で見るとやっぱり日本発型のサービスが残っているのかなと思いました。たとえば楽天、Yahoo オークション、ブログにしても日本向けにアイディアをひねり出して考えて考えて考え抜いたサービスはやっぱりユーザーの心をつかむ。

例えば、顧客から新規案件を受ける時も、僕の頭になかにある数千サイトのフレームワークを使って、顧客がこんなサイトをやりたいんだけどと言われれば、僕の引き出しからあのサイトの○○○をコピーすればすぐにできる …. みたいなフレームがたくさんあります。
顧客には、それは○○○のサイトでも同様のことをやっていて、こんな風なケーススタディーがありますとか、こんなロジックと組み合わせするのはいかがでしょう… みたいな提案をするんですけど、結局はどれだけ顧客のウォンツを頭を使ってひねり出せるかだと思います。

僕がどんなに世界中のあらゆるコンテンツサービスを知っていたとしても、日本の品質にあう提案をするにはやっぱり頭を使う。逆に僕は世界で流れているコンテンツサービスと、実際の顧客との屈折で話す時の時差を埋めるのが大変だったりします。(笑)

時差のないサービスは簡単にできる時代になったけど、それを日本人的文化や気質にあわせる為の温度差を埋めるのはやっぱり難しいです。

7月 8, 2008
» ECサイトで販売機会の損失をしかねない5つの失態

最近ブラウザが新しくなったこともあり、Eコマースサイトのウェブサイトを徘徊しているとたまに、SSLの有効期限切れウェブサイトやSSLにインストールされたドメイン名とウェブサイトのドメイン名があっていなかった為にエラーが表示されたり、またウェブサイト上のあらゆる所に不適切と思われる個所がいくつか見つかったりするものです。

特にEコマースに関しては、自分が制作するサイトと比較しながら見てしまう癖がありますが、少なくとも確認したほうがいい事項があるので今回紹介しておきたいと思います。

1.コピーライトの日付が古い
ユーザーは意外にフッター領域にある Copyright © 会社名< 開始年” の文字列を見ることがあると思います。

この”年”の部分が古い場合(たとえば1995 - 2005)、

・このホームページに掲載されている情報は確かか?(正しいのか)
・この会社は本当にビジネスをやっているのか?

コピーライトの日付が古いだけでユーザーはウェブサイトを疑ってしまう可能性があります。

解決策

PHPプログラムを利用すると次のように書ける。
1995年から開始している場合
Copyright © 1995 - <?=date(”Y”)?> 会社名

次のように表示される
Copyright © 1995 - 2008 会社名

2.SSLがドメイン名と一致していない
SSLがドメイン名と一致していない場合、これは致命的です。IE7、Firefox3のどちらに関してもSSLのインストールしたドメイン名と実用しているドメイン名が違っていたり、SSLの有効期限が切れている場合、下記のような画面が表示されてしまう。

ユーザーがこの画面を見た時、もしかしたら以下のことを想像してしまうだろう。
・フィッシング詐欺にあったのか?
・インターネット回線のトラブルにでもあったのか?
・パソコンが壊れてしまったのか?

ここでこのユーザーはブラウザを閉じることは間違いない。今すぐSSLが正しくインストールされているかどうか確認しておこう。

3.配送方法、決済方法に関する視覚的表示(バナー画像等)をしていない
どのような方法で支払ができるのかをすべてのページに表示すべきです。ユーザーは会社案内やFAQのページなどは実はほとんど見ないです。

商品をクリックしたら、後は購入完了まで一直線にクリックするだけだ。その過程でユーザーが考えることは次の3つくらいしかない。
・何日で届くの?(納期について)
・送料はいくら?(送料について)
・支払方法は何?

クレジットカードのロゴマークや配送業者のロゴマークがあればユーザーは視覚的に理解でき、支払手続きをスムーズに進めることができる。

4.「カートに入れる」などの各ボタン類のデザインへの配慮
ウェブ2.0の流行があってか、ウェブサイト上に置かれるボタン類や素材になんでも影を付ける傾向がある。これはこれでウェブサイトを美しくしていることに違いはないが、ユーザーがそれをボタンであることを認識できないことがある。

そのボタンがどのような目的で存在しているのかをもう一度考えてデザインする必要がある。

ウェブ2.0系のウェブサイトではAJAXについても多用されている。ユーザーがAJAXのアクションを実行したときに、Loaddingしてページを読み込みしていることがわからないとユーザーはその先にあるページを見る前にページを閉じてしまうことがあるかもしれない。

これもAJAXを利用している場合(特にデータ量が多い読み込み)は改善する必要があるだろう。Loadingアイコン素材はこちら

5.貧弱なサイト内検索
Googleは今やとても有名で誰もが使う検索エンジンです。これはGoogleの検索能力の高さが証明しています。また1秒以内に結果をはじき出す高速性も重要です。

サイト内検索機能で、ユーザーがミススペルをしたときに補完語を表示できる機能はありますか?
もしない場合はGoogleをサードパーティーとしてサイト内検索に使うか、それに代わるサードパーティーを探すべきです。
今やユーザーはGoogleが示す「検索する」という傾向にあると思います。

6月 24, 2008
» Zend FWとcakePHPを見比べた結果、LiveCommerceはZend Frameworkを採用

理由は以下の通り。
cakeや他のフレームワークにあるような自動生成やORMなどは確かに魅力的だが、どれもそれをまたフレームとしてつくれる要素を残した中途半端というか、フレームワークっぽくないところが逆にプログラムの組み手にとっては自由度があって良かったりする。

その中途半端な部分を独自に自由に組み立ててたり、特定の必要機能だけをスポットで使ったりできるのは骨太フレームワークに比べた時、最初の開発に一時的に時間はかかるものの、自分で書いているので迷路入りすることはまずないだろう。
つまりフレームワークのスクリプトの依存度は少なく、自分で書いたコードの範疇で自己解決を見出すことができそうだとZend Frameworkは判断した。

一方cakeやsymfonyを採用した場合、開発スピードを早めたり、余分なコードを書かなくて済んだりと初期開発時のメリットや、第3者が介入してもコードの体裁は保たれるものの、迷路入りした時の自己解決において最終的にフレームワークそのものを理解する必要があったり、フレームワークの外に出たい時に(例えば外部のjavaやaspと連携など..)ドキュメントを1から読み返したりとなると、フレームワークの皿の上で踊らされているスクリプトになってしまうと判断した。

フレームが頑丈すぎて一度操作し始めたら、何を動かしていいかわからなくなってしまう。行きたい所に行けない。フレームワークの呪縛にかかってしまうという懸念がどうしても取り除けなかった。
これもPGのセンスや感覚なので十人十色だと思うが。
入口がPHP4から入ったものとしてのあくまで結論です。

先述した『中途半端というが、フレームワークっぽくないところ』が将来やりたいことを実現するときに苦労はあるが、自分で書ける要素が残っているし何より自分で書いたコードの方がアドバンテージがある。(単なる自己満にすぎないが)

GoogleやIMBがスポンサーになってたり、PHP本体の開発を手がけているZENDがサポートしているのもプラスファクターになっている。

では、Zend Framework一本でコードを書いていきます!

簡単に今後のフローを説明しておくと、MVCのロジックにデータベース、ビュー、スクリプトを全部分解して再度コーディングです。
その後、LiveCommerceで独自に開発したクラスライブラリーやファンクションをZend Frameworkの中にインクルードして両方のスクリプトが利用できるようなイメージで再開発する予定です。

6月 11, 2008
» eSupportを使いたくなるわけ

本日、弊社で販売中のヘルプデスクeSupportのさらに分かりやすく、どうしてこんなに使うのかを書いた記事を新たに追加しました。

eSupportを使いたくなるわけ

6月 10, 2008
» osComerceの1PageCheckout

今日ダウンロードリンクつけました。

こちらのエントリーです。

5月 26, 2008
» osCommerce¤Ç¥é¥ó¥Ç¥£¥ó¥°¥Ú¡¼¥¸¤ò³èÍѤ¹¤ë

Google¥¢¥É¥ï¡¼¥º¡¢¥ª¡¼¥Ð¥Á¥å¥¢¹­¹ð¤ÈϢư¤·¤Æº£¤ä¥é¥ó¥Ç¥£¥ó¥°¥Ú¡¼¥¸¤Ç¥×¥í¥â¡¼¥·¥ç¥ó¤ò¤ä¤Ã¤Æ¤¤¤ë¥·¥ç¥Ã¥×¤Ï¿¤¤¤Ç¤¹¤¬»Ùʧ¼ê³¤­»ÅÁȤߤޤǴÊά²½¤·ºÇû¼ê³¤­¤Ç¤ä¤Ã¤Æ¤¤¤ë¤È¤³¤í¤Ï°Õ³°¤È¾¯¤Ê¤«¤Ã¤¿¤ê¤Þ¤¹¡£

¤Ç¡¢osCommerce¥Ð¡¼¥¸¥ç¥ó¤Çºî¤ê¤Þ¤·¤¿¤Î¤Ç³§¤µ¤ó¤Ë¥Ç¥â¤ò¾Ò²ð¤·¤Þ¤¹¡£

¥À¥¦¥ó¥í¡¼¥É

osCommerce¤Ç¥é¥ó¥Ç¥£¥ó¥°¥Ú¡¼¥¸¤ò³èÍѤ¹¤ë ¤È¤¤¤¦¤³¤È¤Ç¤¹¤¬¡¢´Êñ¤ËÀâÌÀ¤¹¤ë¤È¼¡¤Î¤è¤¦¤Ë¤Ê¤ê¤Þ¤¹¡£

¥é¥ó¥Ç¥£¥ó¥°²½¤·¤ÆºÇû»Ùʧ¼ê³¤­¤ò¹Ô¤¦¥¤¥á¡¼¥¸

­¡Yahoo¤äGoogle¤Ê¤É¤«¤é¥é¥ó¥Ç¥£¥ó¥°¥Ú¡¼¥¸¤ØÍ¶Æ³ ­¢¥×¥í¥â¡¼¥·¥ç¥ó¤Î¥Ú¡¼¥¸¤Ø
¤³¤Î¥Ú¡¼¥¸¤«¤éEC¥µ¥¤¥È¤Î¥Ú¡¼¥¸¤Ø¤Ä¤Ê¤°
­£EC¥µ¥¤¥È¤ËͶƳ¤··èºÑ´°Î»¤Þ¤Ç¥æ¡¼¥¶¡¼¤òͶƳ

¤³¤³¤Ç½ÅÍפʤΤϡ¢Ç㤦°Õ»×¤Î¤¢¤ë¸ÜµÒ¤Î°Õ¼±¤¬¹â¤¤¤¦¤Á¤Ë·èºÑ´°Î»¤Þ¤ÇͶƳ¤¹¤ë¤³¤È¤Ç¤¹¡£¤Ê¤Î¤Ç¡¢¿Þ¤Î­£¤Ë¤¢¤¿¤ë

¥×¥í¥â¡¼¥·¥ç¥ó¥Ú¡¼¥¸¡¡¢ª¡¡£Å£Ã¥µ¥¤¥È

¤³¤Î²áÄø¤ÇEC¥µ¥¤¥È¤Î¥Ú¡¼¥¸Á«°Ü¤¬Ä¹¤¤¤È¡¢¤â¤·¤«¤·¤¿¤é¥æ¡¼¥¶¡¼¤Ï¾¤Î¥µ¥¤¥È¤Ø¹Ô¤Ã¤Æ¤·¤Þ¤¦¤«¤â¤·¤ì¤Þ¤»¤ó¡¢Ç㤦¤Î¤ò¤ä¤á¤Æ¤·¤Þ¤¦¤«¤â¤·¤ì¤Þ¤»¤ó¡£
¡Ê¤Á¤Ê¤ß¤Ë»ä¤Ïº£Æü¡¢²Ö¥­¥å¡¼¥Ô¥Ã¥È¤Ç¥ª¥ó¥é¥¤¥ó¤Çͧ¿Í¤Î°Üž½Ë¤¤¤Ë²Ö¤ò¹ØÆþ¤·¤è¤¦¤È¤·¤Þ¤·¤¿¤¬¡¢¤¢¤Þ¤ê¤Ë¤â¹ØÆþ¼ê³¤­¤¬Ä¹¤¯¡¢¥Õ¥©¡¼¥à¤Î¥¨¥é¡¼¤¬¤¢¤Ã¤Æ¤â¤É¤³¤òľ¤»¤Ð¤è¤¤¤«¤ï¤«¤ê¤º¤é¤¤¥Ò¥å¡¼¥Þ¥ó¥¤¥ó¥¿¡¼¥Õ¥§¡¼¥¹¤À¤Ã¤¿¤Î¤Ç¡¢·ë¶É¥Õ¥©¡¼¥à¤«¤é¤Î¹ØÆþ¤òÃÇǰ¤·¤Æ¤³¤³¤ÇÇ㤤¤Þ¤·¤¿¡Ë

¤³¤¦¤¤¤¦¤³¤È¤¬ÉáÄ̤ˤ¢¤ë¤Î¤Ç¡¢ËÜÅö¤ËEC¥µ¥¤¥È¤Ï¹ØÆþ¥×¥í¥»¥¹¤Î¼ê´Ö¤ò¤Ç¤­¤ë¸Â¤ê´Êά²½¤¹¤ë¤è¤¦¤ËÅØ¤á¤ë¤Ù¤­¤À¤È»×¤¤¤Þ¤¹¡£

osCommerce¤Î¥é¥ó¥Ç¥£¥ó¥°¥Ú¡¼¥¸Âбþ1¥Ú¡¼¥¸·èºÑ¤Ï¤³¤Á¤é¤Î¥Ú¡¼¥¸¤Ç¸ø³«¤·¤Æ¤Þ¤¹¡£

5月 18, 2008

Ecommerce Research
Ecommerce Research
Ecommerce Research is about »