メモ

http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/

私自身の採用ポリシーは「少数精鋭」「プロパー指向」「全員エンジニア」で、製品を熟知し、能力も意識も高いメンバーが縦横無尽に協力しながら、非技術要員に対するコミュニケーションのオーバーヘッドをゼロにしつつガンガン進めていく、というものでした。

ロータスでクライアントアプリの開発からキャリアをスタートし、組み込みネットワーク機器開発、Javaツール開発を経て、今ではRailsでバックエンドを書いたりサーバの保守運用まで面倒を見ているダニーとか、日本で一番使われているIRCクライアントLimeChatの作者で、RubyCocoa/MacRubyなどのホットなオープンソースプロジェクトへのコミッタとしても知られ、サーバのみならずWindowsMacの両方でクライアントアプリが書け、新しいところではiPhoneアプリWikiamoがリリースから2ヶ月で100万ダウンロードを達成したサトシとか、数学と哲学の両方の学位を最優等で卒業後、シンクタンクやパフォーミングアートの業界で仕事をしたあとサウンドアーティストとして仕事をし、ここではウェブデザイナープログラマーとしての才能を発揮し、そして今後は世界中を旅しながら写真家としてやっていく道を探るというクリス。住居はダニーがサンフランシスコ、サトシが東京、クリスがニューヨーク、ぼくがサンマテオということで全員バラバラのリモートでしたが、電話すらほとんど使うことなく仕事が進められました。

しかし一方で思うのは、4人というのはやはり大所帯だったということです。アーキテクト・デザイナ・クライアントという専門には重複がなく、これにアーキテクチャとデザインの両方を見られるマネージャであるぼくを加えて4名なら、適正な少数精鋭と言えると思っていました。しかし、これは決して「少数」ではなかったのです。


自分が技術的に成長した今だから言えることですが、今のLingrRejawのようなプロダクトなら、1人か、多くても2人ぐらいで作れるべきであった、と思います。「少数精鋭」を突き詰めると、究極的には1人になるということでしょう。


そして、人数が多くなると「スピード」の遅さに直結します。専門分野の違う優秀な人たちが協力して作り上げることで確かにクオリティは高くなるのですが、開発時の意見のぶつかり合いによるストレスは格段に増え、あるいは専門による分業を明確にして衝突を避けようとするとその隙間でとんでもない見落としがあったりして、どうしてもスピードが落ちます。それぞれ個人としていかに優秀であっても、その能力が存分に活かせなくなってしまうのです。その結果、3年間で2製品。変化の早いウェブの世界のものさしで測ると、これは泥亀のようなスピードだったことに気づかされます。

そのたった一人分の人件費と比べて、チープ革命クラウド化によってインフラのコストはどんどん安くなっていく。


たとえば仮に、サーバ運用のためデータセンターにかかるコストが年間100万円というと、事業コストとして経営者の目から見ると全然たいした金額ではありません。社員が数名いれば、相対的には無視できるぐらいの金額と言えるでしょう。


しかし、これが年間10万円、あるいは1万円ならどうか。もはや個人のポケットマネーでも躊躇せずに支払える水準になってくるでしょう。


数名以上の規模の事業として考える場合、事業の主軸であるインフラへの投資が年間100万円というのはすでに安いので、これをさらに切り詰めて50万円にしようとか、そういうことに努力を傾けるのは合理的に考えて無駄ですから、そういうインセンティブは働きませんし、実際に無意味でしょう。

もっと具体的な例では、うちの場合ではLingrRejawを合わせて計30台ぐらいサーバがあり、フルラック2つで年間計350万円ぐらいかかっています。しかし、上述の人件費に照らしてみれば、大した金額ではないのがおわかりいただけるでしょう。Lingrの場合、データベースのレコード数にしてだいたい7,000万件ぐらいの発言データが蓄積されていますが、以前サービスの負荷が妙に高かったときに急いでマシンを増やして対処したところ、その後にアーキテクチャの見直しで劇的に負荷が下がり、今ではデータベース以外の負荷はスカスカです。つまり、この程度の規模のサービスなら、データベースや各種サーバをちゃんとチューニングするノウハウがある今なら、Amazon EC2などをうまく使って年間10万とはいわないまでも、100万をだいぶ切る構成で運用が可能かも知れないという感触があります。ただ、それをとことん追求するインセンティブがなかったということです。

個人で開発するということは、意志決定の速さが格段に違ってきます。たとえば作っている最中で何かが根本的に間違ってるのでプロジェクトを中止したほうがいいと思っても、チームでやっていると中々言い出せず、ずるずる引きずって時間を浪費してしまうというようなことがあると思います。しかし、10発撃って1発当たるかどうかという世界で勝負していくには、そういう「見切り」の速さこそが命ではないでしょうか。


愛情の込められてないプロダクトは絶対にいいものになりませんが、「愛着」が「執着」になるのは変化への拒絶反応であり危険な兆候です。そのバランスが難しいからこそ、ものづくりは面白いのだともいえます。そういう意味では、今回のシャットダウンの決定は、とても残念ではありますが、「見切り」のチャンスを与えてもらったのだ、と前向きに解釈しています。