CRM2.0

以下のIT MediaのCRMの新潮流を読んで。
CRMの新潮流：「CRM2.0」はバズワードか――SaaSがもたらす新シナリオ
CRMの新潮流：CRMを振り返る――何がいけなかった？

ここ最近、CRM市場が伸びているようですね。
その成長率は2ケタ台だとか、リサーチ会社が発表していました。（ソースは忘れました）

2000年頃に流行り、多くの導入失敗を生んだCRM。
その失敗の原因は現場の営業、サポートに負担を強いることでした。

本来の自分の業務とは関係の無い、管理、マーケティング部門のために
ただ入力を強制させられることはモチベーションＵＰとなりません。

さらに、その入力した結果、どうなったのか、本人たちにはわからない、
効果があるのかどうかもわからない常態では
徐々に入力しなくなるのも当然でしょう。

「人は自分の利益になることでしか動きません。」

CRMの新潮流で述べているCRM2.0では、
入力の強制ではなく、CGMからの情報収集。
顧客の自発的行動結果を記録し、マーケティングに活用するというものです。

顧客が自発的に行動するのは、SNSなどコミュニティ活動が楽しいからであり、
自分のためです。
決して、そのSNSを提供している企業のために行動しているわけではありません。

つまり、ここでの顧客と企業はWin-Winの関係と言えるでしょう。

企業は顧客が欲しいと思う製品などのマーケティング活動をするわけですから、
顧客にとってデメリットとなるわけではありません。
勝手に自分の行動結果が利用されるのを快く思わない方もいらっしゃるとは思いますが。

ここで、営業とサポートにフォーカスを戻しますが、
この方たちにも、入力することで自分のためになる仕組みが必要です。
入力し、その結果を受ける、また入力する、これにより正のスパイラルを
回すことがCRM文化を企業に根付かせるためには必要です。

CRMはシステムではありません。
CRMを実現するためにシステムを活用するのです。

最後に、繰り返しになりますが、
「人は自分の利益になることでしか動きません。」
新しいシステムを導入する際は、これを念頭に置くべきでしょう。

ApacheのListenBacklog

ApacheのMaxClients,ServerLimitsで最大接続数を設定できるが、
それを超えた時の新規リクエストは全てエラーが返されると思っていましたが、
ListenBacklogで設定した数までは、キュー待ちになるそうです。

知らなかった。

ちなみに、ListenBacklogの設定値は変更することはあまり望ましくないとか。
デフォルトは511。
また、OSの制約値も関係してくる。
ListenBacklogよりもOSの方が受け付けられなくなると、
OSのエラーが発生するらしい。

以下、参考URL。
http://his.luky.org/ML/linux-users.a/msg02360.html

jQueryの勉強始め

このサイトはjQuery初心者に優しい。
jQuery UIで実現！ Ajaxで複数選択ドラッグ＆ドロップ

がんばって英語を読みましょう。
jQuery JavaScript Library

jQueryは1.0系、1.1系、1.2系で動作が違う！

jQuery（1.0系）にはＵＩ操作を行うためのinterface.jsがあります。
ドラッグ＆ドロップなどはinterface.jsが必要です。

1.0系と1.1系とは互換性がないらしいです。
jQuery開発者向けメモ

私が確認した範囲では、jQuery1.2.6にはinterface.jsがありません。
代わりに、ドラッグ用、エフェクト用など細かくファイルが分かれています。

これは不要なライブラリを排除できるという点で非常に有効です。
Webアプリケーションでは、Javascriptのダウンロードから展開までがけっこう時間がかかるんです。
CSSや画像ファイルもそうです。
HTMLを生成するための、サーバ側をいくらチューニングしても
この部分がネックになることは十分にあります。

さて、パフォーマンスの話はおいといて
1.0系と1.1系は互換性がないらしいと書きましたが、
実際、互換性がありませんでした。

以下の例は実際には1.2.6で試したものです。
話の都合上、1.1系と表記しています。

例をあげると、sortableを使ったdivブロック上のリンクについては
1.0系：クリックできる
1.1系：クリックできない
（クリックできるようにするための方法はあるようですが、まだわかってません）

sortableでソートできる範囲も異なります。
1.0系では特に考えなくても全体が対象となったのに
1.1系ではconnectWithで対象範囲を明示しないと対象にならなかったりします。

このブログで言いたかったのはインターネット上には
1.0系と1.1系の情報が混在しているので気をつけて！ってことです。
最新は1.2系です。（2008/6/23現在）

jQuery 1.2.1 で script 要素を append すると意図しないパラメータが勝手に付いてしまう
↑の記事によると、1.1系と1.2系もちょっと違う点があるようなので注意です。

RSSでBasic認証

気になりつつも今まで調べなかったこと。
アプリＡのRSSフィードをアプリＢのRSSリーダー機能で表示させたいけど、
RSSフィードの情報を認証無しで見れたら危険。
だから、せめてユーザ・パスワードによる認証をかけたいけど、
RSSリーダーでその機能はどうやって実装したらいいんだろう？と疑問でした。

今日やっと重い腰をあげて、ネットで調べたらすぐにわかった。。。

以下の書式でRSSリーダーに登録すれば、認証が通る。

http://ユーザ名:パスワード@RSSフィードのURL

アプリＡ自体にBasic認証がかかるようにしておくか
アプリＡにBasic認証がかかる場所にRSSフィードを出力させるかしておけば問題解決。

実際には試してませんが、Apacheのアクセスログにはパスワードは残らないらしいです。
でも、httpでのBasic認証だから、パスワードを抜き取ろうと思えば出来ちゃうのかな。

Digest認証は、Basic認証よりも複雑なので、
URLの書き方変えたぐらいじゃ動きません。
たぶん、RSSリーダー側で認証を通す機能が必要になります。

Digest認証はメンドイので、https + Basic認証でやれば
一応のセキュリティは確保できるんじゃないかと思われます。

参考元
RSS フィードをメールで受け取る (2) Basic 認証のある場合は?

SCMとグループウェア

もともと企業間取引の効率化を目指すのがSCM。
グループウェアは社内業務の生産性を上げることが目的。

社内外の業務の生産性を上げたい場合どうなるか？
社外とは外出中だけでなく常駐も含む。
何か通常の作業をして、それが自動的に記録され、システムに登録される仕組みが欲しい。
それを実現するための一例として、メールベースのグループウェアがあります。
MicrosoftのExchange Serverがそれですね。
Outlook連携は使いこなすと強力です。

そもそも、通常作業で使うシステムがグループウェアと連携してればいいんですよね。
仕事でＩＴを使わないことはないんですから。

データ連携、マッシュアップも重要だが、データがなければ意味がない
データ入力も考慮した方がいい
入力するルールにすれば出来るのかもしれないが、果たしてそれが徹底できるのだろうか。
根付かないから、導入したシステムが活用されず、失敗に終わったのではないのか。

BIで有名なウィングアークのDr.Sumは入力を簡単にするツールがあると聞いたことがあります。
使ったことはないので、実際にどうなの？っていうのはわかりませんが。

まったく、SCMの話がありませんでしたが、
それは今、読んでいる本が読み終わった後に。

Google（グーグル）と補完財の戦略的価値（とWebOS）

グーグルが本当に怖い理由　〔補完財の戦略的価値）

このサイトを読んだのだけれど、
補完財という戦略は、けっこうどの企業でも実践してるようですね。

自分としては、キヤノンのトナーカートリッジ戦略が
補完財戦略として、一番しっくりくる。

それについて、ちょっとググってみたら、以下のサイトがあった。
コモディティと代替財/補完財
それはそれでおいといて。

メインのハードか何かがあって、
それを使うには必然的に「ある物」が必要になる。
その「ある物」が補完財だ。

だから、メインの売り上げが伸びれば、
自然と補完財の売り上げが伸びる。

株価もトヨタの株が伸びれば、
トヨタに部品を納入している企業の株も伸びる。
そんな感じかな。

グーグルは広告収入で利益を得て、
利用者には無料でサービスを提供する。
利用者が増えれば、広告価値も上昇して、
もっと提供できるサービスが増える。
だから利用者も増えて。。。と正のスパイラルが回っている。

しかし、他社のマイクロソフトなどは
ＰＣを使う場所をネットに持っていかれて、
それが無料となると、自分たちのビジネスモデルが壊れてしまうから困っているわけだ。

WebOSをグーグルが立ち上げたら、どうなるか見てみたい。
今はワードとかメールなど個々のアプリをネットで提供しているけど、
OSそのものをネットで提供したら、どうなるか。
それがGmail並に使われるようになったら、どうなるか。

そしたら、もうハードもOSも関係なく、ブラウザさえあればいい。
自宅でも出張先でも同じ環境が使えるようになる。
（ブラウザの描画速度として、若干、CPUなども関係してはきますが）

企業レベルでは、何かと問題が出てくるかもしれませんが、
一般ユーザとしては、使えるレベルのものが出てこないですかね。
WebOSはそれ自体は意味がなくて、そこから使えるアプリが
どこまでユーザのニーズに応えられるかが問題ですけど。

ちなみに、WebOSでがんばっているところとして、
StarForceがあります。

ただ、WebOSの場合、CDを自分のPCに入れても
そのデータをネット上に持っていけないと使えないんですよね。
iTunesの曲みたいに、初めからネット上にデータがあればいけど、
ローカル上にあるデータはまずネット上に持っていかないといけない。
だから、曲を作る場合に外部入力でPCにデータを入れても
それを一度、ネット上にアップしないといけない。
その辺に限界があるのかな。

他にも、何かのファイルをダウンロードする時も
ダウンロード場所として、ローカルだけでなく、
WebOSを指定できるようにならないと。

とにかく、データの中心がWebOSにならないとうまく行かない気がするな。
スピードも遅いしね。

結局、すべてがネット上に行くことはないし、どこかに均衡点がある。
どこまでGoogleがネット上に持っていけるかってことですかね。

受託ソフト開発会社「富士ソフト」によるSaaS

SaaSで「富士ソフト」「グーグル」「堀田」の組み合わせには驚いたが

富士ソフトがグーグルと提携してSaaS事業に取り組むらしい。

上記サイトでも指摘しているが、
ドカンと大きな金額で受注して、作るというビジネスモデルでやっている会社に
小さい金額（１ユーザ500円とか）で、ちょっとずつ積み重ねていくSaaSは合わない。

営業の評価基準を変えない限り、営業は絶対に売らない。
数千万から1億の案件を扱ってきた営業が
SaaSをやっても、金額が違いすぎるためだ。
それでは金額で評価されるような営業が動くわけはない。

SaaSはただサービスを提供するだけでなく、
企業の根幹となる人事評価も変えるぐらいの気概がなければ成功しないだろう。

皆が一丸となれる体制を整える必要がある。

Googleを支える技術

Googleはホントーにひたすらスケールスケール、
障害対策障害対策、分散分散を突き詰め
検索エンジンに特化したシステムなんだなと実感。

第一部では初期のGoogleの仕組みの説明があります。
ここでは３つの要素があります。
１、Webページをクロールしてインデックスを作る機能
２、インデックスを保存しておく場所
３、インデックスからランキングリストを作成して表示

ここは検索エンジンの概要を知るための入り口。

次章からは有名なGFS,Bigtableなどの説明に入っていきます。

これらの説明は直接はシステム設計に役立たないかもしれませんが、
考え方として参考になります。
実際には分散や障害対策のために、そんなにサーバ台数使えるか！
そんな完全冗長構成のスケールしまくりシステムを開発する期間なんてあるか！
っていう話もありますが、それは置いておいて。

若干、Googleはこうなっている。Googleはこうだ。
というGoogleGoogleし過ぎている感じは受けました。
特にMapReduceを簡単に扱うための言語の使い方の章は
ちょっとどうでもいい感じがした。

その言語を使って実際に開発するわけではないので。。。

言語を開発している人にとっては楽しく読めるとは思います。

著者に対する感想としては、よくここまでGoogleの出した論文を
自分みたいな一般エンジニアにわかるよう噛み砕いて解説してくれました。
素晴らしい。

ちょっとアルゴリズム色が強いので読みがたい部分もあるかもしれませんが、
検索エンジンの裏側を見れるのはおもしろいです。

SaaSの低価格化（適正価格はいくら？）

【ノークリサーチ調査】「SaaSは今後5年で普及し、領域が広がった“XaaS”が登場する」

SaaSはまだまだ普及に時間がかかるのが世間の予想だ。

SaaSはまだ普及段階だが、元々、中小企業でもＩＴが使えるようになるという目的だったはず。
セールスフォースでは「中小企業も大企業と同じレベルのＩＴが使える」
なんていうキャッチコピーもあった。

しかし、以下のニュース記事でもある通り、
SaaSの導入に至るにはＩＴリテラシーが高いところでなければ
なかなか実現しないのではないだろうか。
というのが今の感覚だ。
SaaSは大企業にこそ普及する

そして、日本では大企業で普及、実績が出てから
中小へ普及するという流れもある。

今、SaaSの１ユーザの価格が月額500円であるところが多い（特にグループウェア）

1,000ユーザで500x12x1,000=6百万円
1万ユーザでやっと6千万円

毎年、6千万の売り上げがあるので、
1万ユーザでやっと事業が成功しそうな気配だ。

1,000ユーザの6百万では採算が合わない。
専任の技術者が1～2人？

SaaSは魅力あるWebアプリケーションはもとより、
それを支えるネットワーク、サーバ管理・運用、セキュリティなど
幅広い知識・技術が必要だ。

それを数人の技術者でまかなうのは無理がある。
数人でまかなえるなら、その技術者の給与は高くなければおかしい。（高くあって欲しい）

何が言いたいかというと、けっこう力を入れないとSaaSモデルは難しいはずなのだが
今の500円でやっていけるのか？
SaaSにはもっと価値があるのではないか？ということ。

もともと中小企業をターゲットとしたから低価格を打ち出しているのだろうが、
採用するのが大企業の方が多いなら
もっと高く、1,000円でもいいのではないだろうか。

普及するまで後、5年もかかるのであれば、
1万ユーザに到達するのも後、5年かかる。
それまで企業体力が持つのは、大手だけだろう。

今はSaaSやります！と手をあげて
市場に対してアピールするマーケティングの材料になっている感じもある。

少し前のOSSと扱いが同じだ。

しかししかし、SaaSは新たなITの提供形態の1つであり、
その潜在可能性は大きい。

OSS（アプリ分野）もSaaSも普及への課題は山積みだが、諦めるにはまだ早い。