2008年10月22日 ドイツで6つ子が生まれた
なんと、ドイツで6つ子が生まれたらしい。
ロイター通信 10月21日▼
ドイツで６つ子誕生、確率は４０億分の１
ベルリンのCharite 病院が２０日、不妊に悩んできたドイツ人女性が元気な６つ子を出産したと発表した。Ulrich Frei医長によると、６つ子は男児４人と女児２人で、体重はそれぞれ８００─９００グラム。母親の女性は妊娠２７週間だった。
出産に立ち会った医師は記者会見し、女性は標準的な不妊治療の結果、妊娠し、出産は問題のない帝王切開で行われたと説明した。３００年の伝統を持つドイツ有数の同病院だが、医長は、６つ子の出産は初めてのことだとしている。
メディア報道によると、六つ子が誕生する確率は、４０億分の１という。
食べるものが変わり、生活環境が変わり、世の中が変わり..
それにしても、最初の出産でいきなり６つ子とは…。
2008年10月20日 SEで”うつ”にならずに仕事を”さくさく”やるにはどうしてます？
とても悲しい記事がありました。
↑の方が言うとおり、SEでプログラムを組む時は、想像以上の集中力とパワーが必要なのは私も同感です。
たとえば、会社にいるときは、正直プログラムのコードなんかをいちいちチェックしている暇なんでない。電話、メール、接客に追われその対応だけで手一杯。
帰宅後、静かになった深夜に２、3時間かけて一気に書き上げる。ヘビーなプログラムを書くときほど、会社ではなく自宅のでやるのが私のルール。
リラックスした状態で、静粛なことがＳＥには必要なんだと思う。これは職業柄、特殊なことなのかもしれない。
いくら会社で、机とマシンと要件定義を与えられたからといってそうできるものでなない。
イメトレをして、「ヨッシャ！”」みたいな気合いと、モチベーション（顧客のプロジェクトを成功させるぞ！）が噛み合ってコードは書けるものだ。
会社の”ガヤガヤ”した状況で、しかも電話もあちらこちらでなっている状況で、すかさず「社長、電話ですよ〜」 なんて言われ瞬間に、 「あれ… どこまで書いてたっけ…」 ってことになる。でしょ？
だから、私は会社では緊急を要する場合を除き会社ではやらない。
どんな職業であれ、スケールは異なっても、結局のところ同じ作業の繰り返しになるわけで、クリエイターは環境を変えたり、ロケーションを変えたりすることで、さらにクリエイティブになるんだと思う。
たとえば、ミージシャン。
ライブで歌うこと自体は同じ作業の繰り返しだが、歌を歌う環境は、地域や会場によって空気の色は違うものだ。それは彼らにとって新しい”何か”をつかんだりするきっかけになる。レコーディングにしてもスタジオを変えることで曲や詩に変化がでる。
同じとは言わないが、実は私も環境を変えて自宅、会社以外でコードを書くことがある。
ノートＰＣとネットと電源さえあれば、ＩＴ業界のＳＥなら基本的にはどこでも仕事はできる。
ヘピーなコードを書こうと思ったら、石垣島に行ってビーチで書き始めたり、新しいアイディアを探しにハワイに行ってホテルで考えたり、集中的にビジネスの勉強が必要だと感じれば、1週間アメリカに行ったり…
サイトの文言を考えるのに成田空港の待合ロビーで書き留めたり…
たとえば、もっと無線LANスポットが増えれば、プログラムを書くときだけ外で出張なんてものありなんだと思う。
自分がそうなだけに、外で環境を変えてPG書くことがこれほど大事なのを認識しているので。
どのようにして環境を変えたりするのかは人それぞれであるが、ノートＰＣとネットと電源さえあればどこでも仕事ができるのはこの業界にいてとてもよかったと思う。ヘッドフォンとマイクとカメラもあれば、基本的には会話もＯＫでしょ。
2008年10月17日 IT業界で最も影響力のあるTOP25人
BusinessWeekが9月末に発表したIT業界で最も影響力のあるTOP25人が発表されていました。
その中に何とWordPressの生みの親であるMatt氏がエントリーされているではないですか。
彼はまだ24歳だというのだからこれはスゴイ…。
digg.comの生みの親であるKevin Rose氏もまだ31歳と若い。
TOP25
1. Steve Ballmer（microsoft.com)
2. Mitchell Baker(Mozilla.org)
3. Jeff Bezos(amazon.com)
4. Sergey Brin, Larry Page, and Eric Schmidt(google.com)
5. Jeff Clavier(softtechvc.com)
6. Paul Graham(ycombinator.com)
7. Arianna Huffington (huffingtonpost.com)
8. Joi Ito(joi.ito.com) 日本人ランクイン！
9. Steve Jobs(apple.com)
10. Jonathan Kaplan(theflip.com)
11. Loic Le Meur(Leweb3.com)
12. Jack Ma(alibaba.com)
13. Matt Mullenweg(Wordpress.org)
14. Rupert Murdoch(myspace.com)
15. Craig Newmark(craigslist.com)
16. Gabe Rivera(techmeme.com)
17. Kevin Rose(digg.com)
18. Sheryl Sandberg(facebook.com)
19. Jon Stewart(thedailyshow.com)
20. Peter Thiel(clariumcapital.com)
21. Maria Thomas(etsy.com)
22. Anssi Vanjoki(nokia.com)
23. Jimmy Wales(wikia-inc.com/wiki/wikia)
24. Evan Williams(twitter.com)
25. Jerry Yang(yahoo.com)
The 25 Most Influential People on the Web
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
2008年9月25日 SupportSuite これは次の時代のホームページヘルプデスクかも！？
弊社が現在ヘルプデスクのソフトとして販売しているeSupportですが、eSupportの上位クラスにあたるSupportSuiteというソフトウェアがあります。（日本では現在未発売です）
そして、このソフトに含まれるLiveResponseというデスクトップアプリケーションがあります。
弊社では、来月１０月から１１月にかけて、社内の顧客サポート体制の全面的な改善を行う予定でして、その際にSupportSuiteを活用した社内サポート体制について、簡単ではありますが読者の方にも参考になると思いまして一部を紹介しようと思います。
まず、現状だと、弊社のいくつかのホームページにおいて、新規顧客と既存顧客の問合わせメールが分離されているので、
新規案件担当のスタッフと既存顧客担当のスタッフ間のメール共有、履歴共有が現状だとリレーショナルできていないという問題点があります。
今回の改善ではこれらを統合して、
・１つのシステムで全ホームページからの電話対応履歴、メール対応履歴、チャット対応履歴のすべてを管理
・全社員が顧客の対応履歴を参照できるようにする
この２点を最終的なゴールに設定しています。
イメージとしては、電話が来ても、メールが来てもどちらにしても名前かメールアドレスか、電話番号さえ分かれば顧客対応履歴が一発でわかるようなイメージです。
これにより顧客満足度ＵＰと対応速度の向上ＵＰを図ります。IT業界全体に言えることだと思いますが、ホームページの表（社外）側がきらびやかでも、裏(社内)側のサポート体制が結構ずさんなところがまだまだ多いのも事実です。
私なりに、eSupportやSupportSuiteとの普及につとめて、いち早い改善を訴えていきたいと思います！
eSupportでは電話対応履歴とメール対応履歴は管理できても、ホームページ毎でのチャット対応履歴は管理できないので、今回のSupportSuiteにアップグレードすることによりチャット履歴もカバーできるようになります。ホームページ上でチャットの必要性がなければeSupportで十分ということになります。
では、今回、紹介するSupportSuiteとLiveResponseというアプリケーションのチャット部分についてです。
このアプリは何かというと、
SupportSuiteチャットのスクリプトコードをホームページに掲載し、ホームページ上からこのコードをクリックして訪問者からのチャット要求があると、LiveResponseが起動し、LiveResponseを通してユーザーとのチャットができるというものです。LiveResponseはデスクトップ上のソフトとしてインストールして利用します。
このソフトの優れている点は、
チャットの際にユーザーはアプリケーションを自分のマシン上にインストールしなくても、ブラウザベースで相手とリアルタイムにチャットができるので、チャットまでの開始がとてもシンプルです。
各ホームページに設置されたLiveResponse用のコードから、現在何人のユーザーがどのページを参照中で、どの検索経路で訪問したのかの参照元が分かる点です。図２
訪問中のユーザーに対してのチャット要求を、こちら側からも出せるというものです。
それと、今回のリニューアルで新顧客、既存顧客とのサポートセンターが１つにまとまるので、スタッフ間でのリレーションシップが一層活発化しそうです。
顧客の属性管理機能も初めて利用することになりそうです。
eSupportもSupportSuiteのどちらもユーザーの属性（ゲスト、登録者）のフラグと、属性に応じたメニュー表記カスタマイズなどができるので、どの顧客が、いつ、どのサービスを購入し、どの種類のサポートをいつまで（期限）受けるのかなどの詳細設定
ができるので、本当の意味でヘルプデスクセンターになると思われます。
弊社の活用度により、わずか数万円のコストでＩT関連をはじめとするさまざまな産業で高度なヘルプデスクシステムの構築ができるように、SupportSuiteの日本語版デビューに向けても着々と準備を進めています。
10月から一部ホームページで試験を開始し、１１月から弊社の全サイトで本稼動予定です。
これで、今後は新しいホームページが増えて、お問合せのカテゴリが増えたとしても、当面は大丈夫な体制作りができたと思います！
 |  |  |  |  |  |  |
 |  |  |
