2006-08-18

Web2.0 : スライドして統合するパクリ

分裂勘違い君劇場 - Web2.0は自殺し、ゾンビーになって徘徊する

が非常に面白いエントリだったので。以下引用。


ITビジネスにおける独占は、人類がいままで経験したことのない爆発的な富の噴出源となるような、異質の独占となるからだ。その異質さは、

(1)ソフトウェアというのは、設計コストが大きく、製造コストが極端に小さいため、富1.0よりもスケールメリットの効果が大きい。

(2)より多くのユーザが同一のソフトウェア(およびそれに基づくサービス)を使うことによって、大きな価値が生み出される。(集積効果、ネットワーク外部性)

(中略)たとえば、Yahoo、Google、楽天、Amazonが市場を独占or寡占して、独占or寡占による弊害がでてきたとしても、その独占をやめさせ、自由競争状態を作り出すために、新規参入を促したり、企業分割して同じ業種の企業を複数作り出すことは、現実的ではないことが多い。

(中略)ゾンビー市場とは、とっくに自由競争なんて無くなり、独占による搾取が行われている死んだ市場なのにもかかわらず、まるで健全に自由競争が行われているかのように錯覚される市場のことだ。


結論に関しては、全く同意でその通りだと思う。

先行寡占サイトに後発が勝つには、

  • 認知度
  • トラフィックを確保する (=トラフィックライン)
  • コンテンツが揃っている
  • CGMへの対応 (amazon アソシエイトや同Web サービスなど)

を同時に揃えなければ勝てない。
もちろんロングテール部分で先行寡占サイトが扱っていないニッチをかっさらうことは出来るが、amazonにロングテールで喧嘩売るなんてギャグとしても寒いし、まず無理である。

しかも先行寡占サイトのUIはデファクトスタンダードでもあるので、例え使いやすい素晴らしいUIを用意してもそれは、必ずしもアドバンテージにならない。十中八九改良UIはその良さゆえに足を引っ張るだろう。(UIとは「使いやすい<慣れてる」であるから)

さらにユーザ情報やカードの登録リスク、メアドの供託リスク、サジェスト用DB蓄積の差、ブックマーク、etcを突破しなくてはならない。

あー。確かにこんなのやってらんない。

※「電子書籍でamazonのせめて半分の品揃え」をまとめられるんなら勝てるかもしれんが。日本の出版業界と取次ぎ至上主義からは考えられないけどね。


…のだが、

確かに同業種同コンセプトで先行寡占サイトに後発が勝てない構造をWebというものが持っている、というのはその通りなのだが、それで終わるのかというとそうではないのではないか。というのが本題。(なげーよ)

fromdusktildawn氏は社会構造に言及されているのだが、僕は企画屋として、そんな構造の中で、どう生き延びてやるかを考えてみたいと思う。



氏の考察部分

設計コストが大きく、製造コストが極端に小さいため、富1.0よりもスケールメリットの効果が大きい。

は、パクリの概念が抜けている。
Webサービスほど設計(仕様)をパクリやすい物はない。
多分、氏はGoogleとかamazonを想定しての事だと思うが(これは設計がどうなっているのか凄すぎて判らないし、規模が真似出来ないとかとにかく無理)、Googleっぽいとかamazonっぽいサービスなら山ほどあるし、del.icio.usやFrickrなんてのは設計自体は大して複雑じゃない。mixiだってOpenPNEみたいに完全に仕様が模倣されてOpenになっているし。

スケールのメリットとは、先行してシェアを得たことという既得権である。
UIが馬鹿丸出しでも慣れられれば勝ちだし(例:楽○市場)、落ちようが流出しようがコンテンツを供給するプレイヤの絶対数と登録済ユーザがいれば勝ちだ(例:楽天市場)。

で、どうすれば勝てる可能性が出るかというと、サービスの企画のスライドパクリである。
どうスライドさせるかというと、Flickrの劣化仕様で映像なだけ版YouTube(インフラ投資は別だけど)だったり、社内の議論の場としてのローカルSNSとか。

さらに、専門職の強いニッチなSBMだけど、ブックマークレットがアカウントがあれば自動ではてブやdel.icio.usにポストしてくれるんだったら、利用者のニッチSBM管理コストはかからないからいくらでも増殖できる。

統合パクリという手法もあって、mixiとサイボウズOfficeをシームレスに、かつ会社/プロジェクトチーム/プライベートが厳密にレイヤ分けできるなら、予定や行動や意見を各レイヤで何度も書き込んだり、場合分けしたりする手間が無くなるのなら設計もスケールも超えて移行する動機が出来る。

これはマッシュアップで解決しそうに見えて解決しない。mixiもOfficeもセキュアに守らなければならない部分だからだ。

っていうかW-ZERO3で、ローカルで予定が見られるスケジューラを持とうとするとW-ZERO3に仕事とプライベートを同時に持とうとするmixiユーザは3回予定を別のメディアに書かなければいけないのだ!
仕事上のタスクと自宅での仕事の研究課題と家族との花火祭りとスケジュール管理しよう、あ、でも予定はチームで共有しなきゃ、だがしかし家族のことまでサイボウズOfficeに書くわけにはいかないし、でもチームの田中君は家族ぐるみの付き合いだし、mixiにも予定を公開してるけどmixiだから公開範囲は制限あるしインポートできないし、ってな人が僕だけではないはずなのだ!!!!(だよね?)

まぁ、↑は半分がガジェットオタクのスケジュール管理自虐(自慢)なんだけどw

Flickrとdel.icio.usとYouTubeとmixiをぐるぐるするのめんどくさいよ。
さっさとパクって統合しちゃってよねぇ>はてなさん
パクリ統合って、これらサービスが一元管理できたら、MacOSXのSpotlightやGoogledesktopの便利さと同じものが価値として出てくるのにね。こうしてみると米Yahoo!ってなにやってんだろ。



IBM→MS→Googleとビッグブラザーが代替わりしてきた。
WalkmanがiPodに駆逐された。

GoogleはMSやWeb1.0の独立アプリ、独立サービス、独立ノードをWebで繋いで集合知にしてしまった。
iPodはCDをHDD内に統合しシャッフルできるようにしてしまった。
各機能は昔からあったものだ。
それを繋いで統合したのがWeb2.0かなにか知らないが今の潮流(スライドして統合するパクリ)なのだろう。

ニッチが隙を突いて統合されていく、まるでナウシカの粘菌みたいだ。

低コストで中小ITを進化させる方法

利益率の低い「受託」と「人投げ(但しこれはリスクも少ない)」から脱却するには、自社商品・パッケージを!!…と思いたい。

が、そんなリスクを負えるようならみんなとっくに手を出している訳です。

いくら「Ruby on Railsで速攻ベータ版リリース出来るよ!」といってもそううまくいきはしない。RoRにしろPrototype等のJavaScriptフレームワークにしろ、それはあくまで手段なのだから。


ではアプローチを変えて、将来設計というか理想地を考えてみる。

コストが安く、生産性が高く、社員が生き生きしていて、営業が楽で、スキルの高い人材が来る!

おお!これは文句ない理想だわ。

では、理想を逆算で具体化してみるにはどうするか。

  • 開発コストを下げる
モダンフレームワークの導入
OpenSouce系のミドルウェア活用
営業の類似案件獲得努力による基礎の共通化
同じく独自機能のプラグイン化(モジュール化)

  • 共同作業への最適化
ノウレッジデータベース
ソースライブラリ
→コメントやドキュメント、組み込みTipsなどの記述ガイドライン
Ruby/RoRやPhytonのようなストリクトな言語へのシフト
→記述の個人差を少なくし、分散化を視野に置く

  • モチベーションを高める
モダンテクノロジを扱う会社・仕事である自負とプライド
繰り返し作業の排除(OpenSauce/社内ライブラリ)


うーむ、昨日のエントリじゃないが、我田引水の感が無くもないw


※営業と企業イメージ(人材確保)は、話が混乱するので後日また。ヒントだけあげるなら、
  • Webからの集客・問い合わせを増やす
  • OSSへのコミットメント


たとえばRoRを導入してそんなに劇的に作業負荷が下がるわけでもない。
どうせドキュメント共有や社内ガイドラインなんて守られも使われもしないし…。

そうなんだけど、ここは運用の意思統一と根気です。
便利なことを判るためには、数ヶ月まじめに運用しなきゃだめですよ。

そのコストは、まぁ、一見ゼロじゃないですか。ココが説得の肝。

◆営業さんには、最近東京ではいっぱい落ちてるRoRやAjax案件(例えばプロトタイプ品や仕様確認案件など多い)を拾ってもらい、小さい案件を数こなす。これはコストゼロ

◆要件定義は、しばらくその手の何件は自分が必ず顔を出して、我田引水しながらどこが共通でどこが拡張で、何が類似拡張かをまとめておく。これはコストは移動日と僕の人件費か

◆できれば、ここからの工程管理の過程でドキュメント整備だのソースライブラリだのをコントロールしたいところ。ここは各PMの意識次第だなぁ。コストは若干だがかかる

はい。
ここでこのいかさまに気づいた人は鋭いか、ちゃんとした仕事をしているSEです。




人(お客)の金で自社パッケージが9割がた出来上がります。
※ちゃんとしたSEさんへ---これで感心する会社が結構あるんですよ!まじで。

設計が巧ければ、拡張機能のカスタマイズと称して案件数をこなすほどにコピペの濡れ手に粟になります。

ところで
個人的意見ですが、独立サービスを想定しています。
僕はこういう案件は、まずASPサービスにはしません。

なぜか。

お客に合わせたカスタマイズが利かない。だから機能が汎用化する。使い勝手が悪い。などなど。
じゃあ、チェックボックスで機能が追加できる形プラグイン式にしたらどうか?
とんでもない。絶対にプログラムが大きくなりすぎてソースがスパゲッティ化する。断言するが、絶対にそうなる。

ここは少し手間でも、毎回、基礎+拡張+開発というスタイルで、いちいち独立したサービスを立てましょう。

  • 鈍重なシステムを抱えたら、保守コスト・カスタマイズコストが雪達磨式に増える。利益率のグラフは放物線型であって、どんどん上昇率が鈍化するモデルなんです。

  • 基礎+拡張+開発型なら、案件をこなすごとに枯れてきて、慣れてきて、コピペが通用するようになるので、利益率の曲線は指数関数型になるモデルです。
※あくまでこの例は一例だし、我田引水がMax巧くいった場合のはなし。


さて、駆け足だけど、目標値と行動指針がおぼろげに出来てきた。

まだまだ先は長い。
品質管理や検証システムの問題もあるし、社内系のライブラリDBは?運用マニュアルの工夫は?中小ITにとっての工程管理とは?などなど問題山積みですな。

しばらくはネタが付きませんw
喜ばしいんだか何なんだか。