Unofficial Planet WordPress Japan

最近妙にホームページを高速化するという分野にとても興味が膨らんできています。
ホームページの表示速度を上げることは、自動車でいう改造ですな。小学生の頃に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によってどの程度ユニークユーザー数、ページビューが増え、日あたりの注文件数がどれだけ変化するのかを実験していきたいと思います。ここはとても興味ある所だと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ウェブデザイン

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

ECサイトの運営形態

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

ECサイトの販促系機能

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

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

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

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

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

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

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

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

顧客サポート系機能（ヘルプデスク）

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

弊社が現在ヘルプデスクのソフトとして販売しているeSupportですが、eSupportの上位クラスにあたるSupportSuiteというソフトウェアがあります。（日本では現在未発売です）
そして、このソフトに含まれるLiveResponseというデスクトップアプリケーションがあります。

弊社では、来月１０月から１１月にかけて、社内の顧客サポート体制の全面的な改善を行う予定でして、その際にSupportSuiteを活用した社内サポート体制について、簡単ではありますが読者の方にも参考になると思いまして一部を紹介しようと思います。

まず、現状だと、弊社のいくつかのホームページにおいて、新規顧客と既存顧客の問合わせメールが分離されているので、

新規案件担当のスタッフと既存顧客担当のスタッフ間のメール共有、履歴共有が現状だとリレーショナルできていないという問題点があります。

今回の改善ではこれらを統合して、
・１つのシステムで全ホームページからの電話対応履歴、メール対応履歴、チャット対応履歴のすべてを管理
・全社員が顧客の対応履歴を参照できるようにする

この２点を最終的なゴールに設定しています。

イメージとしては、電話が来ても、メールが来てもどちらにしても名前かメールアドレスか、電話番号さえ分かれば顧客対応履歴が一発でわかるようなイメージです。
これにより顧客満足度ＵＰと対応速度の向上ＵＰを図ります。IT業界全体に言えることだと思いますが、ホームページの表（社外）側がきらびやかでも、裏(社内)側のサポート体制が結構ずさんなところがまだまだ多いのも事実です。
私なりに、eSupportやSupportSuiteとの普及につとめて、いち早い改善を訴えていきたいと思います！

eSupportでは電話対応履歴とメール対応履歴は管理できても、ホームページ毎でのチャット対応履歴は管理できないので、今回のSupportSuiteにアップグレードすることによりチャット履歴もカバーできるようになります。ホームページ上でチャットの必要性がなければeSupportで十分ということになります。

では、今回、紹介するSupportSuiteとLiveResponseというアプリケーションのチャット部分についてです。

このアプリは何かというと、
SupportSuiteチャットのスクリプトコードをホームページに掲載し、ホームページ上からこのコードをクリックして訪問者からのチャット要求があると、LiveResponseが起動し、LiveResponseを通してユーザーとのチャットができるというものです。LiveResponseはデスクトップ上のソフトとしてインストールして利用します。

このソフトの優れている点は、
チャットの際にユーザーはアプリケーションを自分のマシン上にインストールしなくても、ブラウザベースで相手とリアルタイムにチャットができるので、チャットまでの開始がとてもシンプルです。
各ホームページに設置されたLiveResponse用のコードから、現在何人のユーザーがどのページを参照中で、どの検索経路で訪問したのかの参照元が分かる点です。図２
訪問中のユーザーに対してのチャット要求を、こちら側からも出せるというものです。

それと、今回のリニューアルで新顧客、既存顧客とのサポートセンターが１つにまとまるので、スタッフ間でのリレーションシップが一層活発化しそうです。

顧客の属性管理機能も初めて利用することになりそうです。
eSupportもSupportSuiteのどちらもユーザーの属性（ゲスト、登録者）のフラグと、属性に応じたメニュー表記カスタマイズなどができるので、どの顧客が、いつ、どのサービスを購入し、どの種類のサポートをいつまで（期限）受けるのかなどの詳細設定
ができるので、本当の意味でヘルプデスクセンターになると思われます。
弊社の活用度により、わずか数万円のコストでＩT関連をはじめとするさまざまな産業で高度なヘルプデスクシステムの構築ができるように、SupportSuiteの日本語版デビューに向けても着々と準備を進めています。

10月から一部ホームページで試験を開始し、１１月から弊社の全サイトで本稼動予定です。

これで、今後は新しいホームページが増えて、お問合せのカテゴリが増えたとしても、当面は大丈夫な体制作りができたと思います！

今までは、WEBの技術系書籍ではPHPやMySQLといったどちらかというとプログラム寄りの本ばかりを読んでいましたが、
今回読んだ「ハイパフォーマンスWEBサイト　高速化サイトを実現する１４のルール」は、プログラムでもデザインの話題でもなく、ブラウザとサーバとHTMLの３つを理解していることを前提に書かれた本だったので、今までとはまったく異なるタイプの技術本で興味をそそられました。

高速サイトを実現する14のルール

1. HTTPリクエストを減らす
2. CDN（Content Delivery Network）を使う
3. Expiresヘッダを使う
4. コンポートネントをgzipする
5. スタイルシートは先頭に置く
6. スクリプトは最後に置く
7. CSS Expression の詩うようを控える
8. JavascriptとCSSは外部ファイル化する
9. DNSのルックアアップ数を減らす
10. Javascriptを縮小化する
11. リダイレクトを避ける
12. スクリプトを重複させない
13. ETagの設定を変更する
14. Ajaxをキャッシュ可能にする

ふむふむ。
内容はホームページの表示速度を高速化するために米Yahooのチューニング担当者による１４のテクニックが紹介されており、即実践可能な内容に絞って紹介されていました。まず最初に感じたことは、この本は技術本ではなく、ノウハウ本であることです。

「知らないことが致命傷となるIT業界」だけに、WEBサイト制作にかかわるすべての人に必須のノウハウであることが手にとってすぐに伝わってきました。社内スタッフには速攻で取得してもらう必要性がある本ですね。

まずは、ホームページの表示を単に高速化するだけのチューニングに、これだけのテクニックと技術が必要であること。
はたして、この本に書かれている14のテクニックの内、私がどの程度理解して顧客の案件に取り組んでいるかと自分をレビューしみました。

実際に知っていた知識レベルだと、９つはすでに知っていたので評価点は5点中の4点といったところでしょうか。残りの３テクニックを試すだけで全体で約50%近くも表示が高速化されるそうです。

ホームページの表示を高速化するために早速自社ホームページで改善・実行です！

改善後のレビューはまたブログで書きたいと思います。

ほんとにちょっとしたお問合わせをしたい場合に、お問合わせフォームに記入したり、電話で用件を伝えるのにためらう時ってあると思います。

スカイプにしてもスカイプのソフトをインストールしてコンタクトに追加してしまえば以降のコンタクトは楽ですが、その敷居がまだまだ高かったりするものです。

そこで、弊社の全ホームページにアプリケーションのインストール不要で名前とメールアドレスだけ入力すればすぐに弊社スタッフとチャットを開始できる仕組みをホームページに追加しました！

これで、ちょっとしたことだけですぐに聞きたいことがあれば問い合わせフォームや電話不要で、いきなりチャットでお問合わせができます！お客様にとっても弊社スタッフにとっても両者にメリットがあると思います。

画像をご覧くださいませ。

弊社のホームページの上部にLive Supportというアイコンが表示されています。スタッフがオンラインだと「オンライン」と表示され、オフランだと、オフラインと表示されます。オフラインでもお問合わせはできますが、返信はメールになります。

こちらは実際にチャットをしている画面です。

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

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

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

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

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

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

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

iPhoneを近くのお店でたまたま在庫があるとのことだったので買いました。

いろんなブログやニュースではiPhoneの魅力が伝えられていて、孫さんは人生のスピードが変わったなんて言っていますが、
確かにこの携帯はノートパソコンを持ってきたと言っていいほどスゴイです。
得にGPS連動してGoogleMapが動作するのはヤバイと思いました。近い将来カーナビに代用できるのではないのかと期待してます。 

ただ、それ以上にこの切り替えで難があったのは、おそらくiPhoneを購入した半数以上のユーザーが必ず思うであろう不満として、既存の携帯のアドレス帳転送をショップでやってくれないことです。（私だけかな？）

販売店から無料配布されるアドレス帳転送ソフトは貰ったが、このソフトが全く役立たず。

というか、全く機能していない。
このソフトを利用するには携帯をPCに認識させる必要があるので同iPhoneと同時に携帯認識用のUSBケーブルを買った人も多いはず。

結果からいうと
ソフト　→　USB認識せず利用ができない。
USBケーブル　→　無駄な買い物に終わる。 

このアドレス帳の転送用ソフトはソフトバンク社のロゴが入っているにも関わらずなぜ使えなかったんだろう。
公式のものだと思われるが、本当にこのソフトを利用してアドレス帳の転送に成功した人はいるのだろうか。
このソフトを利用するために旧端末のメーカーサイトからUSBドライバをダウンロードして再度セッティングしてもダメ。

結局このソフトでのアドレス帳の転送はあきらめ、手動で入力するはめに。幸い100件くらいだったのでマンパワーでやりました。

ネットで調べるといろいろなやり方があるみたいですが、以下は私が行った手順。

iTuneダンロード
↓
OutLook起動
↓
エクセルでアドレス帳作成後、CSV吐き出し
↓
 OutLookにインポート
↓
iTuneとOutLookを同期
↓
アドレス帳転送完了 ！

結局、非常に原始的なやり方になりました。 

販売した若い店員さんは、”アドレス帳の転送にこのソフトとUSBケーブルで簡単にできますよ”　なんて軽々しく言ったが、ここまでやるのにソフト使わず、マンパワーで1日がかりだぞ！　と吠えたいところだが、彼女はただ販売するだけなのでしょうがないですよね…..。

1つの管理画面で、複数のフロントをもつマルチosCommerceが海外で出始めました。
これはosCommerceを1つのサーバに管理（admin）を1つインストールして、複数台のサーバにはカタログ（admin）をインストールして異なるネットワーク間で複数のサイトを同時運用するものです。

複数のインストールしたサーバのURLとIPアドレスはもちろん異なります。
商品URLはmod_rewriteを利用して適当に書き換えます。

するとそれぞれのショップは検索エンジンに対して全く異なるショップとして認識され、検索エンジンでの各商品ページへのトラフィックが全体的に上がるというものです。

これは自社ドメインサイトに特化した一番安い方法で販路を拡大できる方法です。

かかる費用は、各複製したサーバでかかるドメイン代、SSL代のみということになります。
この方法でショップを運営する方法は旧来から知られていた古い手法ではありますが、実際にやっているosCommerceストアはまだ国内には無いと思われます。

この運用方法は自社ドメイン型のECサイトにとってはかなりのメリットを享受できるものだと思います。

弊社が作成したその例がこんな感じになります。
www.yogamad.com
www.fitness-mad.com

butter-contact
bl-contact

同様の商品を、異なるコンセプト、異なる趣旨、異なるドメイン、異なるIPアドレス、異なるネットワーク空間で販売するのであればそれは全く異なるウェブサイトとして認識されるのでかなり効果の高いマーケティング手法だといえると思います。

見方を変えればデータベースマーケティングとも言えます。

ECサイトのデータベースを活用して、複数のサーバからDBへのアクセスパーミッションを許可し、独自ECサイトとして展開するのです。

この手法の実行には5万円の開設費用のみで弊社では受託することができますので販路拡大したい場合は是非ご相談ください。

待っていたといえば、否定はできないんですけど、ついにGoogleも日本のGooglemapにもストリートビューが入ったようです。
人、建物、車、全部がGoogleに飲み込まれそう….。

会社の六本木のビル

自社サイトをAUの公式サイトに　申請代行業務を開始しました。
AU公式化申請パック

携帯電話キャリアの公式サイトに登録する際に必要となる申請業務から登録完了までのすべての工程を一括して受託するサービス「AU公式化申請パック」を開始しました。

AU公式化申請パックでは、AU公式サイトとして登録することももちろんのこと、現在携帯サイトをお持ちでなかったとしても、本サービス内にAU公式サイトでも利用できるショッピングカート機能まで付いているのでこのサービスを申込みするだけで携帯ECサイト制作も同時に受けれるサービスとなっているのが特徴です。

現在はAU公式サイトではさまざまなジャンル/カテゴリのサイトがありますが、本サービスでは、AU公式サイトのオンラインショップの限定したサービスとなっています。

価格はAU公式承認化だけで現在数百万する業者がおりますが、弊社ではAU公式サイト用ショッピングカートも付いて89万円（税込）となっております。

同時に、ホームページ制作会社向けのモバイルソリューションとして代理店募集も行っております。詳しくはホームページをご覧ください。
“AU公式サイト化申請パック” を御社のお客様に紹介しませんか?

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

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

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

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

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

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

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

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

いまさら自社サイトにアフィリエイトをやったところで優秀なアフィリエイターを獲得し、彼らに自商品の良さを知ってもらい、良質なコンテンツを作って、アフィリエイターをよい子よい子してあげても、期待したほどの成果は出ずというのが本音である。
オンラインマーケティングの１つツールとして認知され、今もなお成長過程にはあるアフィリエイトだが、

もしあなたがこれから自社ECサイトでアフィリエイトマーケティングを行おうと考えているのなら、このポストをぜひ読んだ方がいいと思う。

こういうこともできるのである。

以下のリンクはアフィリエイターが自分のサイトに張ったリンクである。
http://esupport.ds-style.com/user_26_0000026

その転送先は以下のリンクです。
http://esupport.ds-style.com

何か気付きました？
私が言いたいのは何かというと、アフィリエイターはリンク先のURLのドメイン名に対して直リンクしている点です。

現行のアフィリエイトASPは必ずアフィリエイターが張るＵＲＬがＡＳＰの書式になるのに対して、今私の説明したリンク書式は直リンク、つまりＥＣサイト側からすると「被リンク」を獲得していることになります。

SEOをやっている方ならもしかしたら、”ピン”　と来た人もいると思うんですけど、この時代に1件の被リンクを取得するためにどれだけのコストがかかるか…　けして安いものではありませんよね。

しかし、私がやったこの方法。
アフィリエイターのアフィリエイトリンクはmod_rewriteで静的置換し、自社ＥＣサイトは301 redirect　+　 mod_rewriteで転送先のURLはさらに301 redirectさせた状態。

つまり2回301を行った。double redirectでググルといろいろと情報が出てくるが、Googleクローラーはこの方法を認めている。2回リダイレクトしても（A→B→C）、結果的にはA→Cと同じことと理解してくれているらしい。

これを約1年半ほどやったいたが、自社保有ドメイン　www.buy-link.net ※ のPageRank5、被リンク数約80件を獲得している。いまだGoogleのインデックスからも削除されることなくSEOのキーワード検索で多くのトラフィックを獲得している。
こんなことがあり得るのか？

あんまり大きな声では言えないが、

もし、こんなことがまかり通るのであれば、SEO業者を介せずに直リンクアフィリエイト天国に行けるじゃありませんか。

※こちらのドメインは以前SEOのサービスをやっていましたが、現在はSEO素材の無料ダウンロードサイトになっています。

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

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

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

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

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

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

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

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

海外でのオンライン販売をしたい企業担当者にとって打ち合わせの際に必ず聞か
れることがあるのでここで詳しく説明しておきたいと思います。

海外向けにオンラインショップの構築を行う以前に確認しておかなければならな
いのは以下の3点です。

・販売する地域と言語

・決済する通貨

・配送方法、送料ロジック

これはＥＣサイトのシステム関連との連動になるためです。この部分が決まって
いない状態で打ち合わせに来られてしまわれても、どの地域で売れるの？なんていう質問にはお答えできません。

販売戦略を構築する上でコンサルタントなどと十分協議してください。

まず、多言語をサポートし、他通貨をサポートしているショッピングカートシス
テムと言えば、世界的に認知度が高いosCommerce、そしてその派生でさらに使い
やすくしたZencartです。

基本的にどちらも多言語、他通貨をサポートし、さまざまな決済モジュール、配
送モジュールが公開されているため海外向けでやるならこの2つがベストと言え
ます。弊社で扱うのはこの内、osCommerceとなります。

他にも実際には新しいオープンソースとして以下のようなソフトがリリースされています。いずれも海外ではとても有名ではありますが、情報量がまだ少ないため弊社ではどれも手を出していません。

Magento

http://www.magentocoomerce.com

レビューを見る

Prestashop

http://www.prestashop.com/

Ubercart

http://www.ubercart.org/

Livecart

http://www.livecart.com

レビューを見る

どちらを使うかは制作を担当する会社やPG、SEの裁量判断になるので運営側が一
概に選ぶのはあまりお勧めしていません。

それでは、海外オンラインショップ制作に必要となる5つの重要なポイントにつ
いてそれぞれ詳しく解説していこうと思います。

1.言語

2.通貨

3.決済方法

4.配送方法

5.サーバ設置地域

1.言語

弊社の提供するショッピングカートは標準で　英語、日本語、ドイツ語、スペイ
ンが含まれています。

この言語分だけ商品を登録することができます。言語の切り替えはウェブサイト
上に表示されている国旗をクリックすると切り替わります。

言語は中国語やその他の言語を無限に追加することもができます。

現在対応可能な言語としては以下のサイトで確認できます。

http://addons.oscommerce.com/category/Languages

もしご希望の言語がない場合は、英語をベースに翻訳をすることで対応できま
す。※別途料金がかかります。

言語別にURLは存在しません。

あなたのウェブサイトが http://www.exmple.com/ で、英語、日本語、ドイツ
語、スペイン語がインストールされており、初期言語が英語だとします。ユー
ザーがアクセスした時はシステムで設定した初期言語が優先して表示されます。

日本語を表示させたい場合のURLは

http://www.exmple.com/?language=jp

ドイツ語を表示させたい場合のURLは

http://www.exmple.com/?language=de

スペイン語を表示させたい場合のURLは

http://www.exmple.com/?language=es

となります。もし言語別にパラメータのつかないURLの書式にした場合は、 htaccessでmod_rewriteで指定することで可能になります。

例えば”?language=”の部分を省略して http://www.exmple.com/jp/ とすること
もできます。

2.通貨

通貨も言語と同様に無限にインストールすることができます。通貨は通貨単位を
表すISO codeを入力します。日本円の場合はJPYとなります。

詳しくはoanda.com を参照。

複数の通貨をインストールして運用する場合は基準通貨（レートが1.0）を初期
設定にし、他の通貨との同期をすることができます。

CRONなどで定期的に同期処理を行うことで最新の為替レートにすることができます。

初期通貨が円の場合は商品登録時に円で入力します。カタログ画面でUSD表示に切り替えると自動的に$9.35と表示されます。

※為替レート0.009649の場合。

3.決済方法

国を跨ぐ決済にはクレジットカード決済が一番便利で確実です。以下に紹介している決済業者は主に英語圏で利用されている頻度が高いものです。

標準で対応している決済システムは以下の通りです。契約するだけですぐに利用することができます。さらに詳しい情報はこちらに掲載しています。

サービス名称	主要国	初期費用	月額費用	決済手数料	送金に必要な手数料	送金必要な日数	決済対応通貨	決済対応言語	３Dセキュア	契約種別	決済画面カスタマイズ
	全世界	0円	0円	4%-3.4%	500円	5営業日	16通貨	日本語、英語	なし	包括契約	可能
	全世界	$49	0円	5.5% + $0.45	$6 又は $4	10〜21営業日／14営業日以内?	12通貨	英語・スペイン語	あり	包括契約	可能
	欧州	200ポンド?	30ポンド	3.75% - 4.5%	£0.35又は£10相当	7日＋23日	144通貨	多言語	あり	包括契約	可能
米国本社をお持ちの企業向	米国・英国	0円	0円	2% + $0.20	0円	3-5営業日	米ドル・英ポンド	英語	なし	包括契約	可能

もし日本のクレジット決済システムで英語の画面に切り替えができるサービスがあれば、それを選択されるのも可能です。

• 主にアメリカ圏での販売を検討されている場合は、Paypal、2checkoutが有効です。
• 主にヨーロッパ圏での販売を検討されている場合はWorldPay、2checkoutが有効です。
• それ以外の地域の場合はPaypal＋WorldPayでほぼ全地域に対応できるかと思います。

4.配送方法

現在EMS国際スピード郵便のみシステムでは対応しています。商品登録時に重量を入力し、注文者の配送先国との掛算により送料は決定されます。

• 配送可能な国
• 国際郵便として送れないもの

EMSで配送できないような商品については民間業者（DHL、Fedex）を利用する形になりますが、オンラインショッピング上で送料計算ができないためオンラインショッピングとしては不向きです。DHL、Fedexのそれぞれの担当者にお伺いしたところ、オンラインショッピングなどで利用できる送料計算のオンラインAPIなどはまだないため、オンライン上では送料の計算ができないそうです。

※2008年7月1日現在

海外から商品を配送する場合は、現地業者の送料テーブルが必要になります。（要システム開発）

5.サーバ設置地域

ターゲットとするユーザーの地域に最も近いサーバであることがベストです。アメリカを商圏とする場合はアメリカ本土にサーバをレンタルし、アジアであれば香港かシンガポール、ヨーロッバであればドイツかイギリスになります。

日本国内からのアクセスは遅くなりますが、現地からのアクセスは抜群によくなります。

弊社で制作を受けるときは、販売する地域に応じてサーバロケーションは選択しています。

以上の5点を説明しましたが、特に重要なのは4の配送方法です。配送できる地域であるかどうか、配送できる商品であるかどうかが一番の要です。送料部分の検討で何人も方が海外オンラインショップの制作を断念されていましたので、十分に検討してください。

EMS以外にも民間配送業者（ヤマト、佐川、DHL、Fedex）がありますが、現時点ではEMSと比べるとあまりにも送料が高すぎて（重量によっては10倍も差がある）しまい、オンラインショップ参入の壁になっているのも事実だと思われます。

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

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

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

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

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

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

解決策

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