お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

グーグル開発チームの渾然一体としたパワー

2003/10/27 10:05
  • このエントリーをはてなブックマークに追加

プロフィール

umeda

シリコンバレーで経営コンサルティングを行なう傍ら、ベンチャーキャピタリストとしても活躍する梅田望夫さんが、IT業界の先を読むのに役立つ英文コンテンツを毎日紹介していきます。これを読めば、英語と業界動向を読む力が同時に身に付くはず(このブログの更新は2004年12月30日で終了しました)。
ブログ管理

最近のエントリー

さて先週金曜日の「サンからグーグルへのソフトウェア開発のパラダイムシフト」で取り上げた「A Conversation with Wayne Rosing」の後半を解説しようと思ったら、グーグルの来春IPO噂話がメディアに飛び出してきたので、とりあえずまず一言だけ。

IPOプロセスの実態

日経新聞サイトにも「「ネット公募」で株式公開検討か」などという見出しが出て話題になっているようなので、そのことについて約1カ月前に書かれた渡辺千賀Blog「On Off and Beyond」の解説が秀逸なので、少し長いが、ここで引用しておきたい。

「IPOというと、ある会社がどっと通常の市場に株を放出するかと思いきやそうではない。underwriterである投資銀行が、あちこちの機関投資家を回って、「こんな会社ありまっせ。お宅、いくらで何株くらいだったら買いますか」と聞いて回り、その感触を元に価格を設定して、割り当て販売するのだ。(この「聞いて回る」ツアーをRoad Showという。ちなみに、新作映画上映という意味でRoad Showという言葉を使っても、アメリカでは通じませんのであしからず)で、その機関投資家(年金ファンドとか、信託ファンドとか)は、一旦IPOする会社から買った株を市場に出す。こういうプロセスだから、一般人はIPO株を買うことは普通はできない。バブル期には、このプロセスで悪人が暗躍した。まず投資銀行は、ごひいき先の機関投資家に優先的にIPO株を割り当てる。で、IPO価格をあえて低く設定する。そうすると、IPO後株価は急騰する。ごひいき先はここぞとばかり株を売り払って(flipする、という)、あっという間に巨万の利益を得る。でその利益の一部を手数料など様々な形で投資銀行に還元する。たくさん還元すると、次のIPOでまたたくさん割り当ててもらえる、という仕組みになっていた。OpenIPOを考案したBill Hambrecht氏いわく、flipで得られた利益の30%は投資銀行に還元されていたそうだ。」

「投資銀行側は低めに値付けするインセンティブが働くわけで、そうすると上場した企業の取り分は少なくなる。(市場に出てから第3者間で行われる取引のあがりは上場企業には入ってこないので)ひどい話だ。「正直者が馬鹿を見る」という世界だったんである。ま、とはいうものの、結局最後には大事件になり、何人もの人が検挙され、粛清がかかったが・・・。こうした不透明なIPOプロセスの代わりに、オンラインオークションでIPO株を一般投資家・機関投資家双方に平等な条件で売ろう、というのがOpenIPO。考案したBill Hambrechtが設立したブティック投資銀行WR Hambrechtの登録商標。GoogleもOpenIPOを検討したが、それはもしかして一般の大手投資銀行に対して、IPOのunderwriting feeを値切るための手段かも、と記事は続く。」

この解説で参照している元の記事は、9月22日のSan Jose Mercury Newsの「Opening up the IPO to smaller investors」である。

グーグルの開発プロジェクト

さて、本題に戻って、グーグルの「Vice President, Engineering」であるWayne Rosingのインタビュー。後半も一行一行やっていくと大変なので、面白いフレーズのみ抽出して解説するにとどめるので、興味のある方はぜひ原文全文を当たってください。

「Although we have had some projects that have taken multiple quarters, most projects reach "pushable," or "prototypable," or whatever deliverable state typically in a quarter or less. So I think an important part of how we do things is that there's a lot more incremental engineering. It's not the classic scenario where 500 people work for 18 months on a new release of Solaris, or the whole Linux community works for some extended period of time on the next major release of Linux.

Let's say we have a service that we want to enhance - we'll often just give the code to a team, and they will enhance it; they will write their version of the server. Then, after two or three rounds, the senior people will go back and generalize from the work done and will write a new abstraction that will pull the thing back together.」

これが、グーグルにおける開発プロジェクトについて語られた部分である。本連載5月12日「天才社員が支えるGoogleのマネジメント手法」で、グーグルにおける「平均3人の小さい組織ユニットでの仕事の進め方」について詳述したが、そういう組織で仕事ができる理由(技術的背景)である。

ファイルシステムまで自分達で作る

また、本連載ではグーグルが自前で構築した巨大分散システムについて何回も触れてきたが、だからこそ、自前で様々な道具も作らなければならないという話が述べられている(このACM学会誌は開発ツールをテーマとした特集だから)。

「We have to write a lot of stuff ourselves. Just to give a few examples, we have a very large distributed file system called GFS, for Google File System. We've had to do a fair amount of fundamental computer science in distributed systems, because we essentially have one of the largest distributed computers in the world.」

「The fundamental tools to do that kind of work aren't off the shelf. And you have to consider the spectrum of not only having to solve the problem, but also deploying it. And then we can't do it with an infinite number of people; we have to do it with a small number of people. We have to manage those machines when they're running in production, providing a service on a 24/7 basis.」

「But the basic notion is that when you have very large numbers of computers in multiple data centers, it's probably risky to attempt to manage this with human beings at the control panel. The management is done by software systems. We have some very good engineers who write those management systems. When you get up to the level of routers and big co-location operations, then human beings get involved. But at the scale of our computing elements, most management now is automatic, all done programmatically. The hard part is writing those programs.」

科学の世界で最先端のことをやろうとすると測定機器から自前で作らなければならないのに似た話である。

続いて、グーグルの巨大分散システムの一つ一つのマシンは「x86 Linux boxes」であり、それが始終壊れるのは当然なので、電球を取り替えるように壊れたものを入れ替えているという話が続き、Rosingはこう言う。

「If you want to think of a huge distributed system, with a high degree of transactional integrity, there's a lot of really hard problems yet to be solved. We're just skirting around some of those problems now.」

巨大分散システムで高レベルのtransactional integrityを実現するには、解決しなければならない難題がたくさん残っており、グーグルはその難題をかろうじて回避できているという状況だ、と。聞き手が、たとえばどういう問題なのかと尋ねたのに対する答えがこれである。

「Well, the most important one is how to build a large distributed database that has high transactional integrity - bank grade - and that's a very difficult problem. An example where this comes to roost is in billing. Because of the nature of our business, which is showing ads that are part of a dynamic auction, we essentially have a micropayment billing system. There are millions of teensy little transactions per day. Then that all has to get reconciled, and brought into Oracle Financial Systems, and made to work, and be rock solid.」

開発現場の雰囲気は渾然一体

そして、次の部分は、グーグルの開発現場の雰囲気を実によく表しているところだ。全く新しい問題に取り組んでいるので、自分で何でもかんでもコードを書いて、日々の難題を解決していかなければならない。

「The point is that we write a lot of our own code. And I would say we rewrite a lot of our own code. There's no such thing as an organized "Oh, let's do another Google." It's just that things get a little ponderous - a little too much spaghetti starts hanging out at the edges of something - and the engineers will say, "Let's fix it." Then a gang will form, and they'll go attack it.

So there's just this ongoing tension between writing new things and sort of refactoring the old work, and rewriting and evolving it.

It's remarkable in that the people who get interested in doing this come from all over engineering - sometimes newer people, sometimes old-timers, and sometimes mixtures of them. We don't have a rewrite group or a tools group here. We pretty much have a large concentration of very good engineers, and they tend to migrate toward the hard problems, wherever they may be. And those problems vary over time. So our engineering culture is actually very unstructured. It's far less structured than most companies I've seen.」

難問に直面したとき、「the engineers will say, "Let's fix it." Then a gang will form, and they'll go attack it.」という感じが会社に出てくるかどうかが、いいチームとダメなチームの分かれ目とも言える。そして、開発グループとツールグループなんて区別もなく、ただただ、いいエンジニアたちが一体となって難問に取り組んでいると、またこれまでにたくさんの会社を経験してきたけれどこんなに構造化されていない会社は初めてだと、Rosingはグーグルについて語るのである。

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー

個人情報保護方針
利用規約
訂正
広告について
運営会社