サンからグーグルへのソフトウェア開発のパラダイムシフト

ACMのQueueで「A Conversation with Wayne Rosing」という長文のインタビュー記事(ウェブ上で7ページにわたる)が掲載された。これはとても貴重な情報である。学会誌が、こういう質の高い、しかもビジネス世界の最先端と交錯する世界をきちんとカバーして、ネット上に無償公開してくれるのは、素晴らしいこと。さすがACMである。

Wayne RosingはGoogleのエンジニアリング担当副社長だ。

「Wayne Rosing brought his 30 years of experience in the computer industry to Google when he joined the company three years ago. Early in his career, Rosing held management positions at Data General and DEC, then was director of engineering for the Lisa and Apple II divisions at Apple Computer. He spent nine years at Sun Microsystems, where he helped found Sun Labs, then joined FirstPerson, a wholly owned subsidiary of Sun, where he developed the technology base for Java. He then served as CTO and VP of engineering for Caere, manufacturer of optical character recognition (OCR) products. After Caere was sold, Rosing took time to pursue his lifelong interest in astronomy before coming back to the industry and joining Google.」

Wayne Rosingは、3年前にGoogleに参加したときに、コンピュータ産業30年の経験をGoogleにもたらした。彼はミニコン全盛時代のData GeneralとDECを経て、AppleのLisa(懐かしい!!)とApple II部門で「director of engineering」を勤める。そしてその後Sunで9年間働く。Sun Labsの設立を助け、Java開発に携わる。そのあとOCRベンチャー・Caereの「CTO and VP of engineering」に転じ、Caereが買収された後はしばらく趣味の天文学に没頭し、Googleからの話があって、3年前にGoogleにやってきた。そういう人である。

「Vice President, Engineering」という仕事

日本とは、人の動き方、キャリアの表現方法などが違うので、簡単に解説しておくが、まずこのWayne Rosingという人は、その時代その時代の旬である企業(DG, DEC, Apple, Sun, そしてGoogle)で実績を積みながら渡り歩いて来た人だということである。そして、今のGoogleでのポジションが「Vice President, Engineering」であるように、その時代を代表する一流IT企業を渡り歩いてきたときの「武器」というのが、エンジニアリング・マネジメントというスキルであることだ。

「VP, Engineering」と「CTO」というのは全く違う。同じくSunでいえばBill JoyのようなビジョナリーはCTOで「VP, Engineering」ではない。

研究所と違い、ベンチャーでは、ビジョンや構想がどんなに優れていても、それを形ある製品やサービスに仕上げられなければどうにもならない。

それもたくさんの技術者を束ねて、正しいタイミングで完成品を世に出し続けなければならない。技術に没頭しているだけでもダメ。顧客のこともわかり、技術者心理を理解した上で開発グループを統率できなければ、このスキルで飯を食っていくことはできない。エンジニアリング・マネジメントというスキルは実に奥が深いのだ。

一流のベンチャー創業チームの場合、CEO的リーダーシップ、CTO的テクノロジービジョンは創業者が兼ね備えているケースが多い。創業してまもない段階では、創業者が持つコンセプトを検証したり、製品やサービスを構想する段階なので、「VP, Engineering」は要らない。

しかし、さあこれから、というときに重要なのが、「VP, Engineering」と、「VP, Business Development」または「VP, Sales」に素晴らしい人を得ることなのである。だから、「きちんとしたモノを作る」というエンジニアリング責任者と、「売り上げをちゃんと立てる」というビジネス開発・セールス責任者というのは、たいていの場合、傭兵として、そのベンチャーに雇われるものなのである。

Googleの3年前というのは、そういう傭兵が必要になった時期だったわけで、そこでWayne Rosingに白羽の矢が立ったわけだ。

「I joined Sun in 1985, essentially as VP of hardware. Eric Schmidt became the VP of software. It transmogrified fairly quickly into Eric and I sharing most of engineering.」

Wayne Rosingが1985年にサンに入ったときのポジションが「VP of hardware」。現Google・CEOのEric Schmidtが「VP of software」だったのだと、Wayneは語る。この二人が「sharing most of engineering」、つまり「きちんとしたモノを作る」という仕事の両輪として、サンの興隆を支えたのである。

確かにGoogle創業者のページとブリンが素晴らしい才能の持ち主であることは間違いない。でも、まだこれから、という時点で、この二人のような本当に仕事をしてきた実績と経験を持つ人たちがCEOと「VP, Engineering」として参画するということがなければ、Googleの現在の姿は全く違うものになったに違いない、ということは確信を持って言えるわけだ。こういうところに、シリコンバレーの凄みというのがある。シリコンバレーにおけるベンチャー創造というのは、若さと勢いで突き進むだけのものではなく、プロの仕事人による仕事なのである。

ところで、この長文インタビューの聞き手は、David Brown。

「He is questioned here by David J. Brown, senior staff engineer in the Solaris Engineering Group at Sun Microsystems. Earlier Brown was a member of the research staff at Stanford University, where he worked with Andy Bechtolsheim on the prototype Sun workstation; was a founder of Silicon Graphics, where he developed early system and network software; and later established DEC's Workstation Systems Engineering Group in Palo Alto with Steve Bourne.」

Wayne Rosingにとっては後輩にあたる人。そんな気安さも手伝って、いろいろと面白く本質的な話が飛び出しているインタビューだと思う。

ソフトウェア開発はどう変わったか

インタビューの1ページ目は、イントロに加えて、Wayneの来し方(history)が語られている。そして2ページの冒頭で、聞き手のDavid Brownは、

「It's really interesting to hear you also talk about this evolution from the sort of software we were building in the past to these large-scale deployments or large-scale-release consumer-based software products, and the acute problems of software development surrounding the quality issues that we now face. That's certainly something we've been observing very intimately at Sun, surrounding Solaris, over the past 10 years.

And, really, it's changing all of our disciplines. In fact, when we were talking about this issue of Queue, the interest was to take a look at tools; one of the big things that we were thinking about was the problem of scale. Initially, we'd mostly been thinking about people wandering into large tracts of code, and how the heck they grapple with it.

But with Google, you've got this other huge area, which is the huge problem of scale for data. I thought I'd ask you a little bit about what you're doing in managing large amounts of storage and data and how that has impacted what goes on in your development at Google.」

と質問する。「this evolution from the sort of software we were building in the past to these large-scale deployments or large-scale-release consumer-based software products」というのが質問背景の第一エッセンス。つまり、過去のソフトウェアから、顧客ベースもコード自身の大きさも巨大化した現在のソフトウェアへの進化について、議論したいというのが主旨。申し遅れたが、このACMのQueueは、開発ツールの特集号なので、開発ツールという観点からも議論したい、というのも主旨の第二。また、Googleでは、それに加えて「the huge problem of scale for data」という未開の分野が広がっているので、まず、Googleにおいて「managing large amounts of storage and data」という点で今何をやっているのか、そしてそれがGoogleでの開発全体にどういうインパクトを与えたのか話してくれ、と問いかけた。

それに対してまずWayne Rosingは、SunとCaereとGoogleにおけるソフトウェアの違い、問題の本質の違いをこう分類した。まずソフトウェア・プラットフォームのSun。

「I think there are different dimensions. Sun built a platform that third parties build, arbitrarily, pieces of software upon - including banks and people who are really very, very serious about everything working right.

So Sun has to come out with a product, as represented with a software interface, for which, in some sense, the minimal acceptable standard is perfection. Now, we all know that you never really, truly achieve that. Because you can't - Sun cannot possibly test every conceivable use that its software is put to - it's a pretty tough software engineering problem.」

サンは、プラットフォームを作ってきた。プラットフォームというのは、その上でサードパーティがどんなものを作るかわからない。そのサードパーティの中には銀行のようにシステムが完璧に動くことを徹底的に求める人もいる。だからサンは、ソフトウェアインタフェースとして表現される製品を、完璧なものとして提供しなければならない。でもそんな完璧なんて無理。その上にどんなものが乗っても完璧に動くことを保証するなんてテストはできっこない。本当にタフなソフトウェア・エンジニアリング問題だ。

「リリース」に対する概念が全く違うGoogle

次に、顧客が使うパッケージ・ソリューションのCaereについてだが、そこは省略。原文をご参照。そしてGoogle。

「Google is very different. First of all, if we make a mistake, as soon as we see it on the site we can have the engineers go figure out the fix. We can push the software in a matter of hours, and we can update it. If we make a mistake on our own site, short of bringing the thing down - which, of course, we'll know instantly - we can fix things, because we don't have this problem of software recall or the associated revenue problems.

Googleはぜんぜん違う。ミステイクを犯して、それが発見されたら、エンジニアがすぐに直せばいい。数時間で、またソフトウェアをプッシュすればいい(ソフトをネットの向こうに押し出す、というような意味合いだろうと思う)。ソフトウェア・リコールやそれに伴って売り上げが減少するというような問題は起きない。

「And, with the exception of our Google API - which is a rather small, experimental thing - people don't write applications on top of Google directly.

We are enjoying a relatively simple problem in producing software for the outside world. We have a few APIs. We will no doubt be adding more over time. But, at the moment, outside users at the software level aren't our significant problem.」

GoogleにもAPIがあるのでそこは例外だが、こちらはサンなんかの問題に比べて軽微。だから、今のところ、ソフトウェアレベルでの外部ユーザの問題というのは、重要でない。

「And when I came here, I was 54 years old, so it took me a little bit of time to really grapple with what it meant to push software. I always thought of software as something you released, at the end of a year, with great pain and agony. At Google, we just push software all the time, so it's a very different notion. By the way, it's no less tolerant of sloppy engineering.」

自分は54歳になってGoogleにやってきて、最初はものすごく戸惑った。ソフトウェアをプッシュするということの意味についてね。自分はずっとソフトウェアというのは、期限がやってくるごとに、苦痛を伴いながらリリースするものなのだと思っていた。でもGoogleは常時、ソフトウェアをプッシュしている。これは全く違う概念だったね。だからといって、いい加減なエンジニアリングでいい、というわけじゃないけれど。

Wayne Rosingのようなプロのエンジニアリング・マネジャーにとっての真のネット体験が、語られている部分だと思う。

さてさて、まだまだ3分の1もいかないうちに、本欄の紙幅が尽きてきた。続きはまた来週、解説することにしよう。

週末にでも、興味のある方は、ぜひ原文「A Conversation with Wayne Rosing」をどうぞ。あと、本当は、この記事の技術的な面からの解釈という点では、CNET Blogチームに新たに加わった江島健太郎さんが、きっと僕なんかよりうんと適任だろうと思う。いつか、ぜひ江島さんの視点でのこのインタビューの解説が読めたらな、と一応、リクエストを出しておこうと思います。