筆者は端からソフト開発（ASPサービスを含む）とは「ものづくり」であると言う前提で物事を考えています。先日のものづくり魂の話も私たちのASPサービスの話であるのですが、どうもWeb2.0を取り巻く世間の雰囲気は、まったく別のところにあるように思われます。ここらへんの違和感をnaoya氏も大規模サービスを展開する企業が陥るジレンマにこう書いています。（少々引用が長いですが）
What Is Web 2.0のなかでオライリーは、早期に且つ頻繁に機能を改善、リリースしていくことが重要だと述べていますが、トラフィックが大量に集まるサービスではその変更がどうしても難しくなってきます。ユーザー数が多いために、新しい機能を追加したり既存の機能を変更したりする場合の影響が大きかったり、あらかじめ十分な負荷分散を見積もらないと変更できなかったり。それから、企業として、求められる責任の度合いがどうしても大きくなる。そういう状況では、どうしても変化に対して鈍くなり、遅くなってしまいます。たとえばはてなダイアリーは、現在 100 台以上のサーバーで運用されていて、データベースのパーティショニングや、コンテンツキャッシュの仕組みなんかはいたるところにあって、その運用と開発に結構な工数がかかっています。これはサーバーが1台のときから継続的に運用開発をしてきたからできた芸当で、初日から 100 台サーバー用意して、なんて言われてもたまったもんじゃありません。
いきなり100台はオーバーにしろ、大きな企業ではそういうことが常なんだろうなあと。ニフティにいたときも、ココログをオープンするときにはその辺にすごく神経使いましたし。それでも開始早々障害が起こって、何日も会社に泊まったりしました。そういう状況で、早期に且つ頻繁にリリースしる! それが Web 2.0 だ! なんて言われても「オイオイ」って話になるなあと。
以前の、オープン化によるソフトウェア周りのコモディティ化の議論でも、大方の評論家の方々がおもいっきり勘違いしたコメントをしていましたが、機能自体がコモディティ化することはあっても技術そのものがコモディティ化することはあり得ません。
そこにものづくり魂の本質があります。naoya氏も、どう手を打つか考えているようです。
ふたつめ。Google には低レベルレイヤのコア技術がいくつかあるそうですが、そういうものを早期に確立して、技術面での変化に対するリスクを下げるという方法。Yahoo! にも、大量のトラフィックをさばくための独自の技術があると聞いてます。これからは Binary 2.0 だ! なんてちょっと笑い話っぽいですが、あんがい笑ってる場合じゃないかもしれない。間違いなく、はてなに足りないテクノロジーはこのレイヤにあるし、そこで成果を出すことができればもっと飛躍できるのではないかと思っています。
ただ、全部 C や C++ で作るとかそういうのはアレなので、やはり Lightweight な言語とフレームワークで開発自体はラピッドに、開発者の技術レベルがある程度ばらついてても対応できるような開発体制でいつつ、彼らがそれを意識しなくても良い、低レベルレイヤでそれらアプリケーションを支える特化型の技術を持っているという、そういうのが理想かなと思います。
筆者はこれが正解だと思います。ただ、詳しくは次回のエントリーに書きますが、何もすべて自分たちでやる必要はありません。餅屋は餅屋、『低レベルレイヤでそれらアプリケーションを支える特化型の技術を持っている』会社はあります。提携なりを模索していく中で、お互いの技術を磨くことを考えるのもMOT（技術経営）をあずかるCTOの重要な仕事です。
今回は引用ばかりで中身のないエントリーでしたが、次回オンライブテクノロジー（あくまで予定＾＾；）で中身を入れます。 KAI
コメント