2008年12月29日 スゴ！ Dropboxは仕事のあり方そのものを変える
DropBoxは仕事のあり方そのものを変えた！
先日紹介したDropboxですが、使用して３日が経過しました。半信半疑で使い始めましたが、やっぱりこれ、本当にすごいです！
仕事上でいままでいろいろと悩み続けていたいろんな問題を解決してくれますし、仕事の幅が大きく広がった感じがしました。
僕がこの３日間で今までとどれくらい変わったのか、このブログで紹介したいと思います。
大きく分けて３つぐらいのメリットがあるんだけど、まずはもっともメリットが大きいと感じたことから記事にしていきます。
ウェブサイトの制作のスピードがあがった。
ウェブサイトの制作者って、ファイルを編集するためのマスタデータをどっかに持っておかないといけないんですけど、会社でしか作業をしないならともかく、
自宅、Ａ支店、Ｂ支店のような複数拠点や、複数の作業者とウェブを管理する場合は、サーバ上のデータではなく、ローカルベースでマスターデータがあって、それを共有できたらいいなーって前から思ってたんですけど、Dropboxがあっさりとこの問題を解決してしまったんです。
AさんとBさんがいて、それぞれ離れた場所でホームページの編集作業を行っていたとします。毎回サーバ上のデータをダウンロードして更新しなければならないためとても作業が面倒です。先祖返りをすることもしばしばあったりしました。
Dropboxを見つけるまでは、この問題に対して以前はデータを管理する管理系ソフトで有名なTracというのがありますが、高機能でプログラマにとっては重宝しているみたいだけど、巷で噂されているほどは使い勝手がよくないというのが僕のレビューで、使い方を覚えるまでに結局は諦めました。
１分でも迷うものなら、諦めるというのが僕のわがままでありネットツールはマニュアルなくしてユーザーインターフェースのみの操作で直観的に覚えられるというのが僕の信条だからです。そういう意味でTracはダメでした。（せっかく高機能なんだからもっとUIを改善すればいいのにね）
話をもどして、Dropboxを使うとAさん、BさんはDropboxをそれぞれがインストールして、AさんBさんどちらでもいいので、マスターデータとするフォルダに招待してあげればOKということです。
この仕組みを使うと、北海道と沖縄と香港と韓国とかの離れたロケーションで同一のウェブシステムの開発ができるってことになります。
特にDreamweaverユーザーの場合だと、サイト毎にサイトの定義をするわけですが、サイトの定義するときにローカルフォルダの指定をDropboxで作成したフォルダにするだけで、他のユーザーのデスクトップ上のマシンと完全同期されるわけで、開発作業が超超超効率化されるわけですよ！
これが、今のデジタルスタジオにとってどれほどすぐれたメリットがあるか。
会社に社員を常駐させてウェブ開発をしてもらう。これは普通にある話。
大きなウェブ開発をするときは、最初にプロジェクトの概要やコーディングルールとかタスクリストなどを一時的に共有したりする意味で一緒に作業をしなければならない期間は必要だと思うけど、ある程度ルール付が出来上がってきたら、次はやっぱり効率化となるわけですよ。別に会社に来なくったって開発はできるってことに話はなるんです。
効率化となると、人、物、時間、金をどううまく活用するかがキモになってきてDropboxはITでいう場所とデータ保存という部分において効率化をいち早くやってくれたIT企業だと思います。いまどきの言葉だとSaasだね。
外注とはまた違うんだけど、個人レベルでの優秀なエンジニアほど、場所を選ばずにどこでも仕事ができるようになってきていると思います。より短期間で良質なシステムを開発するためにはITを徹底的に使うのが僕の信条であり、うちの会社自体がその見本になるべきだと思っています。
これからはオフィスを持たない族（僕もその一人には違いないんだけど、電源とネット回線があれば場所はどこでもいい）がもっと多くなるのだと思います。
例えばDropbox的な生活ができるようになると、僕が出張中の新幹線の中からでもファイルのダウンロードとかをサーバから一切行わずに、Dreamweaverさえ開ければ、どこでも一瞬にしてウェブサイトの編集ができる…
みたいな超スピード感あるビジネスになるんです。
で、デジタルスタジオにとってはDropboxで社内文書や開発ドキュメントがマネージメントできるようにする方向性で２００９年はやろうと思います
今までの仕事のやり方にしても、この文化を社内に浸透させてもっとグローバルで、かつニュートラルな位置で仕事を進めていこうと思います。
またメリットを発見したら紹介します。
Tags: dreamweaver, Dropbox, IT
2008年10月26日 お問い合わせの窓口が変わりました
弊社の顧客向けのお問い合わせ窓口であるサポートセンターの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に変わるテキストベースのチャットが顧客サポートのツールの１つとして追加されたので、時間がなかったり即答を求めたいビジネスニーズにも答えられるようになりました。
先日よりお気づきのかたもいると思いますが、弊社のウェブサイトのヘッダー部分（ページの上部）に”Live Support” というアイコンをクリックするとオンラインでチャットが開始できます。
Skypeのようにソフトをインストールする必要はありません。ブラウザベースでのチャットです。
私の最終的な目標は、インターネット上で起こるさまざまな問題をウェブサイトと（今回の）サポートツールを使用して自己解決できる仕組みを作ることです。
サポート業務は受ける側（弊社）も、発する側（お客様）もそれぞれエネルギーが必要だと思います。
そのエネルギーの消費をITでできる限り小さくして、限り早い段階で解決できるお手伝いをし、お客様のビジネスをより加速させ、価値を高められるような提案をできるように、弊社自身がこういったツールの開発と研究に業界の先端企業として走り続けたいと思います。
2008年10月1日 ホームページの表示スピードを高速化することによって得られる利益はいくらですか？
最近妙にホームページを高速化するという分野にとても興味が膨らんできています。
ホームページの表示速度を上げることは、自動車でいう改造ですな。小学生の頃に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によってどの程度ユニークユーザー数、ページビューが増え、日あたりの注文件数がどれだけ変化するのかを実験していきたいと思います。ここはとても興味ある所だと思います。
2008年9月27日 3年後くらいのECサイト業界はサービスとしてのソフトウェアへ変身できるか
SAASモデルは2012年までに8000億円市場になるらしい..。（本当か？.）
だとすれば、（旧来のオフライン）パッケージソフトの販売を行ってきたベンター達はサーバにパッケージソフトをインストールし、フロント部分をHTML化するだけで、ユーザーへデスクトップ環境と同じ形でネットワークを介したさまざまなサービスを再び提供するのではないかと思われる。90年代後半に盛り上がったASP時代が再び到来するようなもでしょう。
ネットワークを介してサービスを提供するとなれば、これはもはや非OS依存型のサービスになるので、Windowsの存在はどうなるのやら..。
最終的に、デスクトップに残るアプリケーションは、インターネットとメールだけになってしまうのでしょうか。
これを私の業界に当てはめて考えてみると次のような構図が見えてくる。
ウェブデザイン
ウェブデザインはクリエイティブな感覚が必要とする人間味あるサービスであるため、ソフトウェアとすることは難しい。ウェブデザイン自体の作成方法や作成技術は進化するかもしれないが、デザインを考案するクリエイティブな部分はどんなに時代が進もうとソフトウェア化できないのでSAAS化されることはありえない。
ECサイトの運営形態
ECサイトのソフト自体は自社サーバにインストールする自社運営型とモール型（楽天やYahooなど）の両方にそれぞれのメリットがあるため、今後も同時に進行されると思われる。これは今とそんなに変わるものではないと思われる。
ECサイトの販促系機能
ECサイト構築ソリューションとして、広告、アフィリエイト、アクセス解析、動画配信、アンケートフォーム、ヘルプデスクなどの各機能を補完すること自体が無意味なものになっていき、これらの機能ははいずれも全てSAAS化またはプラグイン（機能保管モジュール）化され、すべてが月額制で利用できるようになる。
受託システム開発だと、要件定義を出す側も、それを受ける側もそもそも共通言語を使ってだれも難しい話し合いなんかしたくない。日本にはいまだに共通のフォーマットがないから、プログラマと発注者でお互いが同じ言語感覚で話し合うことなどしたら、喧嘩になりがち。
受託はバージョン管理も、バグ管理も全てにおいて手間がかかる。受託がなくなることはなくても、受託を発注するプロセスやそのフローが何かSAASモデルによって改善されたらいいなと願ってます！
ECサイトの販売・顧客管理系機能
ここは、大幅に変更される可能性の秘めた領域だと思う。もっともベンダーの参入が多いと思われる。
現状のデスクトップアプリケーションで管理している受注管理や販売管理ソフトはすべてネットワークを介してサーバで管理されることになるだろう。業務系ソフトをSAAS化することにより、エンドユーザーは注文の編集やキャンセルを行いたいときに、メールや電話で連絡するのではなく、ログインをして自分の注文状態を確認し、自由に注文変更やキャンセルができるようになる。
懸念事項としてSAAS化することで全データをネットワークの向こうにあるサーバに保存することの抵抗感やセキュリティー不安の問題がある。
２重、３重のバックアップや、99.9%のアップタイムを保持できるだけの保守体制基盤作りにＳＡＡＳ業者はコスト増を強いられ、この部分がSAAS化産業の成長の鍵になると思う。データセンターやセキュリティー系ベンダーがSAAS化を促進できるだろうか。専用サーバのホスティングサービスはホームページのホスティングから、データ保管のホスティングサービスに変化するのだろうか？
顧客サポート系機能（ヘルプデスク）
電話対応、メール対応などの顧客対応履歴を含むカスタマーサポートに必要な機能はSAAS化される。ホームページに必要なフォーム機能は、すべて月額制で利用できるようになる。
Tags: SAAS
2008年7月8日 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が示す「検索する」という傾向にあると思います。
 |  |  |  |  |  |  |
 |  |  |
