29 décembre 2008 [sugo] ! Le tambour change la manière elle-même du travail
Le tambour a changé la manière elle-même du travail !
Tambour qu'il y a quelques jours est présentéMais en utilisant, 3 jours se sont écoulés.Étant douteux, il a commencé à employer, mais ceci, il est énorme après tous vraiment, est !
En vue de le travail le divers problème qui a continué à être préoccupé jusqu'ici dans diverses manières est résolu et, le sentiment où la largeur du travail écartée en grande partie.
Si I que le changement d'ampleur jusqu'ici de ces 3 jours, nous voudrait présenter avec ceci [burogu].
大きく分けて３つぐらいのメリットがあるんだけど、まずはもっともメリットが大きいと感じたことから記事にしていきます。
ウェブサイトの制作のスピードがあがった。
ウェブサイトの制作者って、ファイルを編集するためのマスタデータをどっかに持っておかないといけないんですけど、会社でしか作業をしないならともかく、
自宅、Ａ支店、Ｂ支店のような複数拠点や、複数の作業者とウェブを管理する場合は、サーバ上のデータではなく、ローカルベースでマスターデータがあって、それを共有できたらいいなーって前から思ってたんですけど、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年12月26日 大宮と六本木と自宅の３つのロケーションで仕事をするためのツール ファイル同期
最近、大宮と六本木と自宅の３つのロケーションで仕事をするようになると自然とどこかに１つのフォルダに仕事で作成したファイルを集中管理ってことを考えてて、Microsoft Office Groove 2007でファイルの同期をとろうなんて思っていたら、
あらまあ…
全部タダで２GBまでストレージしてくれるサービスがあったのですね。
昔はさくらのリモートデスクトップとかも考えたいたんですけど、さっき検索したら既にサービス停止してたんですね。
で、サービスとしてあったのがこれ↓
たぶん未来のハードディスクだと思います。いまどきの言葉でいうとクラウドってことになるのかな。
ネットワークの向こう側にそのサービスがあるってこと。
ダウンロードしたアプリケーションをマシンにインストールして、アカウントのセットアップをすれば、後は普通のウィンドウズのフォルダにコピーするのと同じ要領で使えるんです。ファイルのアップロードとかも必要なし。設定も何にも必要なし。
マイドキュメント内に自動的に My dropbox というフォルダが生成されるので、その中にファイルを入れるだけで自動的にサーバにアップされる仕組みらしい。
ためしに最初は大宮オフィスで適当なファイルを保存して、そのあとに自宅のPCにもDropboxのアプリをインストールしてみたけど、
こりゃ便利だわ。
ほとんど手間無く、あっさり同期されて大宮のデスクの上でやっていた作業フォルダが一瞬で同期完了ですわ。
サイトにログインすると、同期されているファイルが見れます↓
アプリをインストしてメアドとパスワードを決めてすぐ使えるので、１分もあればセットアップはできてしまうので、これからはネットカフェだろうが、香港のネットカフェだろうが、どこに行っても自分のデスクトップが一瞬で同期されるとおもったら、またまたすごい環境でこれからは仕事ができるんじゃないかって勝手に想像してしまいましたよ。
しかも、Dropboxは誤って間違った内容で上書きしてしまったり削除してしまったファイルを、Web上の管理ページから復旧させることもできるんです。
差分管理やバックアップ的な意味でも役立つってことです。
僕が驚いたのは、それよりも同期スピードの速さです！
これがとんでもなくなめらかで、ヤバイです。
本当にこれでデータの保存から解放されますね。50GBで年間99ドルって安すぎると思う。
パソコンは既に消耗品で、僕はこれから時代は自分のハードディスクにデータを保存することなどは愚かだと思う。
使うソフトだけインストールしておいて、保存したデータすべてネットワーク上に保存して、ネットを経由してデータを編集したりまた作成したりするのがもっとも効率的。
このデータをネットワーク上に保存するっていう考え方を２００９年は徹底して、社内にもっと仕事の効率化をはかるよう自ら実践していこうと思います。
ここで意見が分かれるのって、データを他人のサーバに保存するっていう抵抗感かな。
Tags: Dropbox
2008年12月8日 クリスマスのロゴ
ロゴをさりげなくクリスマスバージョンにしました。
別にこれっていう意味はないですけど、なんとなくこういう遊び心ってあった方がいいですよね！
会社のホームページのロゴで見れますよ。
それと、今日、六本木のオフィスもブラビア化しました！
従来は来客用にプロジェクターを使ってプレゼンやホームページとかの説明をしていたんですけ、プロジェクターでそれなりの満足度のある設備を整えるとなるといい金額になるんですけど、今の時代はやっぱり大画面液晶でしょう。
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月30日 2時間の作業で34%ホームページを高速化
先日ブログでレビューした、「高速サイトを実現する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秒の高速化に成功。
| 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 |
確かにサイトは見るからに高速化されていて、表示スピードが早いのには体感できる。
今までホームページの制作過程の中では一度も見直すことがなかったホームページの高速化であるが、商用サイトの場合で数百から数千ページを動的生成させているサイトなんかだと、ページを高速化することで、日当たりのページビューが増え、１日あたり、年間あたりで計算した場合には相当なPVの増加を期待することができる。また検索エンジンフレンドリー、ユーザーフレンドリーなサイトになることは言うまでもない。
今回試したこの手法のもっとも気に入った点は、サーバのハードウェアをカスタマイズしたり、データベースへのSQL文などハードやアプリの根幹を一切いじらずして、Apache系のカスタマイズだけで高速化を実現できる点が制作側からするとフレンドリーである点だと思います。
ユーザーからサイトのスピードに文句言われる前に、少なくとも商用サイトであればこの手の手段はできる限り早い段階でやっておくことをオススメします。
Tags: website optimization
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
 |  |  |  |  |  |  |
 |  |  |
