キラーアプリは技術者の夢 ---「LingrとRejawサービス終了のお知らせ」を読んだ感想 ---
面白く読ませていただきました。
共感したところ
自分が技術的に成長した今だから言えることですが、今のLingrやRejawのようなプロダクトなら、1人か、多くても2人ぐらいで作れるべきであった、と思います。「少数精鋭」を突き詰めると、究極的には1人になるということでしょう。
http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/
あるプロダクトを完成に導くのに1〜2名で可能というのは確かだと思います。仕事量にしないと意味がないわけですが、そう、2名＊3か月あれば大概のサービスのクローンを高品質にカスタマイズして"仕上げる"ことは可能だろうと思います。一人で開発されてリリースされているソフトウエアは結構多くありますし。
開発者自身のやりたいことと一致しているときの効率は、100倍というお話、本当にその通りだと思います。その人の脳内でほとんどの設計と実装が生まれ、サービスの実現する様が思い描かれ、書かれるコードはシンプルかつ強固なものになります。
これを多人数で構成しようとした時から、メンバー間での情報管理に多量のリソースを取られます。プロジェクト管理についての多くの議論の焦点はそこにあります。
クラウドに似ている
強力なマシン１機上で動かすためのシステムは簡単に書けるけれども、より普通もしくはやや劣ったマシンを束ねて大量の処理をさせるクラウド用のシステムを書くのは簡単ではないのと似ています。
人でも同じで、高い能力の一人が開発できるシステムを、多人数で開発しようとすると、当然、開発以外の作業が発生するので、その分ロスが生じるわけです。
理想的なチームのように思える
では、何がまずかったのでしょうか。
http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150
...中略...
私自身の採用ポリシーは「少数精鋭」「プロパー指向」「全員エンジニア」で、製品を熟知し、能力も意識も高いメンバーが縦横無尽に協力しながら、非技術要員に対するコミュニケーションのオーバーヘッドをゼロにしつつガンガン進めていく、というものでした。
...中略...
しかし一方で思うのは、4人というのはやはり大所帯だったということです。アーキテクト・デザイナ・クライアントという専門には重複がなく、これにアーキテクチャとデザインの両方を見られるマネージャであるぼくを加えて4名なら、適正な少数精鋭と言えると思っていました。しかし、これは決して「少数」ではなかったのです。
4人の優秀なスタッフがいたということは、アジャイルな開発体制としては相当にうらやましい環境のように思います。
4人が大所帯だったのでしょうか。本当に？
その理由として、製品のリリーススピードを上げられていて、「開発時の意見のぶつかり合いによるストレスは格段に増え、あるいは専門による分業を明確にして衝突を避けようとするとその隙間でとんでもない見落としがあったりして、どうしてもスピードが落ちます。」とのことなんですが・・・そこが本当に「何がまずかったのか」の答えなんでしょうか。
技術的には成功していたのでは？
つまらないメタファーをあえて持ち出すと、（ビジネススクールの初級編みたいでいやらしいですが、PHPer向き）、
うまいケーキを焼ける職人は確かに一人いれば十分でしょう。でもそれで流行るケーキショップを作ってビジネスとして成功できるでしょうか。個人的に趣味で焼いているんなら別ですが、投資を受けて会社としてやっていくならそんな甘い話はないですよね。うまいケーキさえ焼いていれば口コミで客が増えて・・・っていうサクセスストーリー、たまにあるのかもしれませんが、それはある意味夢物語か、もしくはそう装っているだけだろうと。
だって、そもそも、Lingrは"技術的に"失敗なんでしょうか。そうは思えないんです。
上記の引用の中で、4人が大所帯でメンバー間の衝突が開発スピードに影響したという話があります。スピード重視の部分は同意ですが、メンバー間の衝突によってスピードが落ちるという側面があるとしても、その問題は人数を減らすことではなく、メンバー間の問題をうまく解消する仕組みを導入することによって解決する方法も考えられます。実際、それはできていたのではないでしょうか。開発者がリモートにいながら作業を進め、一定の製品をリリースできたという事実は、その部分の管理は、江島さんの理想のレベルではなかったのかもしれませんが、一般的なレベルからみると高度に洗練されていたのではないでしょうか。
ただ、そのコストを容認できるようなプランを立てていたかどうか、容認できないなら、それをカバーする別のプランを用意していたかというビジネスプランニングの問題という気がしてなりません。
クラウドを例にとりましたが
少数精鋭という考え方は、少数の高価なリソースで大量のタスクを処理をさせようという試みだと思います。一方、平均的な技術レベルの開発者を多数束ねて開発するスタイルもあり得ます。
大量のリソースをかけて下らないシステムしか納品しないウォーターフォールな開発体制が揶揄されることはあるわけですが、それはリソースを管理する技術がまだ未熟だからであって、大量のリソースをコントロールすることの意義そのものが否定されているわけではありません。
サーバーの単体性能に依存していた時代から、大量（多数）のサーバーをクラウドとしてタスクを分散して管理する方法が開発されてきたように、開発者のリソースについても、技術レベルの違う開発者を無駄なく管理する方法が求められます。
それでも、いまだに特定の分野ではメインフレームが現役であるように、少数精鋭体制が必要なフィールドももちろんあります。
戦場は
ランチェスターの法則的に考えると、広大なフィールドで勝負するときは、総リソースの差が重要であって、それを跳ね返すにはセグメントを制限して狭い領域で戦うか、さもなくば、リソースの差を圧倒的にカバーしうるキラーアプリが必要になります。
少数精鋭で成功するのは、開発スケールの変動が少なく、需要と供給が緩やかな均衡を保てるような限定的なセグメント、もしくは他者が容易に真似できないようなキラーアプリの時だけのように思えます。いわゆるイノベーションの領域。
最近の技術の並列化の状況をみると、Webサービスでキラーアプリをリリースするのは非常に難しいように思います。流行しているサービスでもバックエンド技術的には実に「なんてことない」わけです。スピードと変化への対応が要求されるＷｅｂサービスに必要なのは、キラーアプリを開発するときの費用対効果に優れた少数精鋭式よりも、平均的な成果物での費用対効果に優れ、リソースの追加削除をタイムリーに行えるクラウド的な開発体制の方が向いています。
さて、Lingrの対象としているフィールドは広大なサービス空間にあります。それでいて優れたシステムではあるものの他者がまねできないキラーアプリかというとそういうわけでもなさそうです。でもそれがサービスを閉める要因になるとは思いません、ただ、広大な空間でキラーアプリを持たずに戦うときは、綿密かつ高度なマーケティングが必要な難しい領域であるということは言えそうです。
安定して戦えるのは、
- セグメントNo1となるようなビジネスプランを持つ
- キラーアプリを作る
という2拓がわかりやすいわけですが、セグメントNo1を目指すという、もう10年以上も言い古されたＷｅｂ業界の常識は主にビジネス指向の人のサクセスストーリで、キラーアプリによるサクセスストーリーは技術指向の人が抱く夢なんですね。おそらく、少数精鋭を理想とする時、後者を選択しようとしたということなんだろうと思います。
ビジネス的な観点でみると
ビジネスとしての安定性は少数の優れた人材に高価な報酬を払うよりも、平均的で入手しやすく交換可能な人材で廻るプロジェクトの方が優位でしょう。開発者重視のプロジェクトだと、おそらく一番コストが張るのはメイン開発者だろうと思います。当然開発以外のお仕事もたくさんあります。開発の中でも、比較的安い作業内容と高い作業内容があります。そういう単価の安い仕事までも少数精鋭と割り切ってしまうと単価の高い開発者が行うことになります。それは非常にもったいない。
"企業の競争相手が個人になる時代は目の前まで来ている"
それで、上記のようなもろもろで何を言いたかったかというと、この分野では「企業の競争相手が個人になる時代は目の前まで来ている」ということです。スタートアップ企業を作って数名で作るのと、一人の個人が副業で立ち上げるのとでは、最終的に出てくるモノの差がだんだんなくなってきており、単に「かかるコストだけが100倍違う」ということになりかねない、と思うのです。
http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/
技術的には「"企業の競争相手が個人になる時代は目の前まで来ている"」という側面があることは事実と言えるかもしれません。
ただ、個人の高い技術によって素晴らしいシステムがリリースされたとしてもそれがビジネスとして成功するにはまた別の才能も同時に持ち合わせている場合に限ります。いえ、みんな、その部分には暗黙の自信を持っているから、個人レベルの技術力差にこだわってしまうんだろうとは思いますが。逆に言えば、
個人の技術力差がサービスの本質ではなくなる
企業が集団によって構成される一側面は人件集約がもたらす経済効果にあるので、その集約という商業の基本理念を技術的にカバーするクラウド的な発想があれば、技術力の差は、個人に内包される流動性の低い状態から、貨幣交換可能な市場価値へと変わると思います。そうなれば、Webサービスというビジネスは、発想を証券化して売買しつつ、それを実体化させるだけのために技術者が使われるような総フリーエージェント化が進むという仮説もありえるのではないでしょうか。
そういえば、発想の証券化ってどっかでやってましたね。
終わりに、
こうして日本語で記事を書いている方が、北米マーケットで闘志を燃やして開発してくれているということは、日本の開発者に勇気を与えてくれているのではないでしょうか。すくなくとも、私は今回の記事にとても感銘をうけました。
ゴタクはいいから、アウトプットしようぜってことで、私も、いつか北米マーケットでチャレンジしてみようかなと。
テクノロジーが勝利要因でない時代
妙にタイムリーだったので追記です。
TABLOG:「Twitterは人間性の勝利であって、テクノロジーの勝利ではない」創業者Biz StoneのUCバークレーでのスピーチ - livedoor Blog（ブログ）
クラウドソーシングは専門性が命
その後、ちょっとググってたら、気になる記事を発見。クラウド状の集団にアウトソースする際の成功のコツは。
クラウドソーシングで成功と失敗のわかりやすい分かれ道がある。それは、いかに有能なプロ集団をクラウド化するかということだ。
http://japan.internet.com/busnews/20090423/8.html
[追記]CNETの過去記事で興味深いものをメモ
そういえば、過去記事をあさっていてみつけました。
お待たせしました、ガツンとLingrの新リリースです:Kenn's Clairvoyance - CNET Japan
APIの提供ってある程度、責任がありますね。それを使ってミニアプリを構築するのに、それなりに労力をかけているはずです。オープンソースならこういうときに開発したリソースは無駄にならないんですけど。
コメント欄で鋭いツッコミが。
