第30回

〜対談編〜


EDAエンジニアになる勉強をしていたYahoo!の設立者,David Filo氏


フーとは,いろいろな面で接点がありますね.まず,同じUC Berkeleyの工学部出身だし,6年ほど前はEDAスタートアップで一緒でしたよね.
「トニー先輩」なんですよね(笑).そうそう,あのスタートアップの時代は今でも本当に懐かしいです.当時,私は博士号を取ったばかりで右も左もわからないフレッシュマンでした.企業で働く責任だとか厳しさをはじめて味わったし,スタートアップだったから相当濃厚な経験をしたと感じています.日本にトニーと一緒に行って日本のメーカーのエンジニアと会ったりして,貴重な経験をたくさん積むことができました.トニーは営業管理部門のエライさんって感じだったけれど,エンジニアだったバックグラウンドがあって話が通じたので,少し不思議でした(笑).
あの当時は,Yahoo!設立者のDavid Filo氏がスタンフォード大学に在学中でしたね.
そうです.David Filo氏の卒論がなかなか進まくてインターネットで遊び始めたのがきっかけで,同じ研究室にいたJerry Yang氏と一緒にYahoo!が作られたのですが,このエピソードはエンジニアの中でもあまり知られていませんね.二人ともちゃんとした工学の勉強をしていました. 

今回のゲストのプロフィール

 Phu Hoang(フー・ホアング)

 Yahoo!社Vice President(副社長).1965年ベトナム,サイゴン生まれ.少年時代,家族と渡米(1975).メリーランド大学で数学と電子工学を専攻,のちにカルフォルニア大学バークレイ校(UC Berkeley)にて,電子・情報工学の修士/博士号を取得.EDAスタートアップを経て,技術責任者としてYahoo!社の立ち上げ時代に入社.現在は電子商取引(E-Commerce)の技術部門を統括する副社長.





EDAソフトから
インターネットポータルへ


フーは現在,インターネットとかE-Commerceをやっているのですが,もともとはかなり硬い分野の勉強をしていましたよね?

学士を取ったメリーランド大学は理論(theory)の分野が強い学校で,工学部でも制御理論の講義などが多くありました.紙を使った演習や数学の勉強ばかりしていたイメージがあります.

EDAの分野にはどうして入ったのですか?

大学院生としてUC Berkeleyに入った当初は,それまでと同じ制御系の理論を勉強しました.結局,修士は1年ほどで取れたのですが,この後ずっと難しい方程式ばかりながめるのに少しずつうんざりしてきたり,優秀な学生が多い大学なので競争も激しくて,修士を取るまでの経験はかなりつらいものになりました.そこで,別な分野を考えてみたくなりました.

  そして,DSPや低消費電力回路で有名なヤン・ラバイ(Jan Rabaey)教授の研究室に入ったわけですか?

当時はラバイ先生が自分の研究室を立ち上げようとしていて,私にとって非常に良い状況でした.DSPの世界では自分の数学に関するバックグラウンドが使えると思っていたのですが,当時の私はコンピュータやソフトウェアについての知識があまりなかったので,研究員になりながら,コンピュータの分野の授業を受けたりしてなんとか研究室でがんばれるようになりました.なにせ理論ばかりやっていたので,とまどうことが多かったです.でもそれを許してくれ,チャンスを与えてくれたラバイ先生には,いまでも本当に感謝しています.ラバイ先生の研究室に4年ほどお世話になり,博士号を取りました.

卒業論文のテーマは,ハイレベル論理合成でしたよね?

そうです.DSPなどで使われるデータパス中心の論理合成ツールを書きました.最適化アルゴリズムも研究しました.

技術的内容がすごく濃いし,専門的な分野ですね.現在はインターネットを代表する会社に勤めているわけですが,分野的に見て,いままで勉強してきたこととか研究したことはどういうふうに役立っていますか?

Yahoo!は,位置づけとしてはコンシューマをターゲットとしたメディア会社になっていますが,やはりエンジニアが影でそれぞれのサービスをしっかり支えています.私がUC Berkeleyに在学していた頃はC++が流行りはじめていて,私もC/C++のコーディングをかなりやりました.Yahoo!でエンジニアとして仕事をするには,基本的に質の高いプログラミングができる必要があります.HTMLなどのときは適当な書き方になることもありますが,そこでも以前自分がやってきたフォーマルなプログラミングスタイルが役立っていると思います.

 最近は,自分自身ではコーディングしなくなったのですが,スタッフの仕事具合や仕事の分配を決めたりするのに,もとエンジニアだったときのコーディング経験は重要ですね.

注1:Yahooの意味は,俗にいう「ヤロウ」になる.技術的ヤロウの意味?

エンジニアには肩書きを与えない


最近,VP(Vice President)になられたとか? おめでとうございます!

いえいえ! Yahoo!はタイトル(肩書き)を与えないことをポリシーとしています.だから,エンジニアだとだいたい皆Technical Yahoo注1が共通のタイトルです.しかし私の場合,仕事上どうしても他社の技術者と一緒になることが多く,私の位置付けをしっかり示さないといけない状況が発生しました.外部の方に,どういう仕事をやっているかをしっかり伝える必要があって,しぶしぶこの新しいタイトルを引き受けました.

他社のエンジニアと仕事はどのように進めるのですか?

インターネット系の会社の場合,さまざまな提携スタイルがあります.そこでの技術的評価,ようするに他社の技術とYahoo!がどのように協力しあえるかを検討していきます.また,Yahoo!はインターネット業界でのリーダー的存在で,多くのスタートアップからさまざまな提案があるわけですが,ひととおり技術的評価をしておかないと今後どうなるかわからないので,新しい技術も積極的に理解しておく必要があります.

タイトルでエンジニアの位を分けないのは,どうなんでしょう? 普通のシリコンバレーの企業だとエンジニアには,Junior Programmer,Senior Programmer,Chief Architect,VPに相当するエンジニアの最高峰に位置するFellowなど,さまざまなタイトルがありますが,Yahoo!は,こういったものがなく,みなさんすべてTechnical Yahooなんですね?

Yahoo!では,Yahoo!のサイト内の各サービス,われわれはPropertyと呼んでいるのですが,これらは互いにおおむね独立していて,エンジニア5〜6名,マーケティング,マネージャから構成される小さなグループによって考案され,作られ,テストやメンテナンスが行われます.各Propertyをできるだけ単独の企業のようにするわけです.結果的にエンジニアの仕事や責任の量も多くなります.エンジニアをタイトル付けしないことによって,臨機応変にプロジェクトに対応できるようにしています.各Propertyによる広告収益などは一目瞭然なので,それを担当するグループの評価として,直接使えます.

そうですね,たしかにタイトルを与えたりグループを分けたりすると,なわばり意識が働いてしまいますよね?
ええ.また,強制的にグループ間の技術交流をさせるより,必要に応じて社内の誰にでも話ができるようにしておくほうが,エンジニア同士で自主的にC++のライブラリを共有したりインフラ面で協力しあったりするものです.それに,いちいち上司の確認をとったりする暇はありません.へたに何々グループとか作ってしまうと,トニーの指摘どおりなわばり意識が働いて逆効果です.約1000名いる従業員の中の約200名がエンジニアですが,これらをすべてうまく活用するには,一つのリソースとしてみて自由に,臨機応変にプロジェクトにアサインしていくのが最適解だと思います.

障害物を取っ払うのが
マネージャの仕事


今後については? また大学に戻るとか考えることはありますか?

最近,やっと自分のやりたいことが見えてきました.Yahoo!の前には,ASICの設計者とか専門家が使うEDAソフトを書いていました.これはたしかに必要なことだったのですが,Yahoo!のような桁違いに多くの人に使われるプログラムを書いていると,やはり充実感が違いますね.あと,家族に仕事の話をするとわかってもらえるし(笑). 

そうですね,DSPやASICの話からはじめないといけないのでは,苦しいですよね.

それに,マネージャという仕事に自分は合っていると感じています.できるだけエンジニアが仕事をしやすいように障害物を取っ払うのが私のマネージャ像です. だからエンジニアを使っているという意識より,エンジニアに何をやってあげられるか? これを常に考えています.もっと生産性を上げるには,どうするか? さまざまなプログラムを共有することは手だての一つですが,これを強制的にやるとなわばり意識が出るので,いかにバランス良くするかが大切です.エンジニアは,ちゃんと評価されると自主的に動いてもっと良い仕事をしてくれるといつも感じています.また,技術的なチャレンジもたくさんありますから,以前研究していた分野に戻ったりしたいとは思いません.

会社が成功する前と後で,生活は変わりましたか?

成功しても私生活はあまり変わらない人が多いですよ.私とかDaivd Filo氏とか,あと数人トニーとも知り合いの人達は7年以上運転しているボロボロの車を今でももっているし,仲間の間では,誰が先に妥協して新しい車を買ってしまうかっていう競争をしているんですよ. 

新車を買ってしまった人が負けなんですね? 楽しそうなコンテストだ.

対談を終えて
 フー氏は,いつも謙虚で真面目な印象がいまでも鮮明だ.現在は,かなりの数のエンジニアを管理する職についているが,エンジニアの気持ちをうまく生かし,仕事しやすい環境を考えられるボスになったと思う.大成功したシリコンバレーエンジニアなのだが,まだまだシンプルで謙虚な雰囲気が残っている.




トニー・チン htchin@attglobal.net
WinHawk Consulting

 

copyright 1997-2000 H. Tony Chin

連載コラムの目次に戻る

Interfaceトップページに戻る

コラム目次
New

移り気な情報工学 第62回 地震をきっかけにリアルタイム・システム再考

Back Number

移り気な情報工学
第62回  地震をきっかけにリアルタイム・システム再考
第61回  海を渡って卵を産む北京の「海亀族」
第60回  超遠距離通信とソフトウェア無線
第59回  IT先進国フィンランドの計画性
第58回  物理的に正しいITの環境対応
第57回  年金,e-チケットに見るディジタル時代の情報原本
第56回  「着るコンピュータ」から「進化した布地」へ
第55回  技術を楽しむネットの文化
第54回  情報爆発2.0
第53回  プログラミングの現場感覚
第52回  GPS+LBS(Location Based Service)がおもしろい
第51回  技術の格差社会
第50回  フィンランドに見る,高齢化社会を支える技術
第49回  たかが技術倫理,されど技術倫理
第48回  若者の理科離れ,2007年問題から「浮遊」せよ
第47回  機械のためのWWW――Google Maps APIから考える
第46回 網羅と完備で考えるユビキタスの視点 ―― u-Japan構想
第45回 青年よ,ITを志してくれ
第44回 Looking Glassに見るデスクトップの次世代化
第43回 CMSはブログに終わらない
第42回 二つの2010年問題
第41回 持続型技術――サスティナブル・テクノロジ
第40回 ICカード付き携帯電話が作る新しい文化
第39回 ユーザビリティの視点
第38回 性善説と性悪説で考えるRFID
第37回 時代間通信アーキテクチャ
第36回 ITもの作りの原点
第35回 ビットの化石
第34回 ユビキタスなエネルギー
第33回 ロゼッタストーンとWWW
第32回 情報家電のリテラシー
第31回 草の根グリッドの心理学
第30回 自分自身を語るオブジェクト指向「物」
第29回 電子キットから始まるエレクトロニクス
第28回 映画に見る,できそうでできないIT
第27回 ITも歴史を学ぶ時代
第26回 1テラバイトで作る完全なる記憶
第25回 日本はそんなにIT環境の悪い国なのか
第24回 10年後にも生きている技術の法則
第23回 ITなギズモ
第22回 ブロードバンドネットワークに関する三つの質問

Engineering Life in Silicon Valley
第93回 「だれでも参加できるシリコン・バレー」はどうなる
第92回 チャレンジするためにシリコン・バレーへ 対談編
第91回 テクノロジと教育学の融合
第90回 日本でシリコン・バレーを伝える活動
第89回 営業からベンチャ企業設立までの道のり(第二部)
第88回 営業からベンチャ企業設立までの道のり(第一部)
第87回 エンジニアを相手にビジネスを展開するプロ第三部
第86回 エンジニアを相手にビジネスを展開するプロ第二部
第85回 エンジニアを相手にビジネスを展開するプロ第一部
第84回 出会いには不向きのシリコンバレー
第83回 めざせIPO!
第82回 シリコンバレーでの人脈作り
第81回 フリー・エンジニアという仕事(第三部)
第80回 フリー・エンジニアという仕事(第二部)
第79回 フリー・エンジニアという仕事(第一部)
第78回 インドに流れ出るシリコンバレーエンジニアの仕事
第77回 エンジニア達の健康管理・健康への努力(第二部)
第76回 エンジニア達の健康管理・なぜエンジニア達は太る?(第一部)
第75回 ユーザーインターフェースのスペシャリスト(第二部)
第74回 ユーザーインターフェースのスペシャリスト(第一部)
第73回 放浪の旅を経てエンジニアに……
第72回 凄腕女性エンジニアリングマネージャ(第二部)
第71回 凄腕女性エンジニアリングマネージャ(第一部)
第70回 ビジネススキルを修行しながらエンジニアを続ける
第69回 専門分野の第一線で活躍するエンジニア
第68回 シリコンバレーに夫婦で出向(第二部)
第67回 シリコンバレーに夫婦で出向(第一部)
第66回 目に見えないシリコンバレーの成功要因
第65回 起業・独立のステップ
第64回 インターネットバブルの前と後の比較
第63回 日本でシリコンバレースタートアップを体験する(第四部)
第62回 日本でシリコンバレースタートアップを体験する(第三部)
第61回 日本でシリコンバレースタートアップを体験する(第二部)
第60回 日本でシリコンバレースタートアップを体験する(第一部)

電脳事情にし・ひがし
第14回 韓国インターネット社会の光と陰

第13回 ドイツのソフトウェア産業とヨーロッパ気質〜優秀なソフトウェア技術者は現代のマイスター
第12回 開発現場から見た,最新ロシアВоронежのソフトウェア開発事情
第11回 新しい組み込みチップはCaliforniaから ―― SuperHやPowerPCは駆逐されるか ――
第10回  昔懐かしい秋葉原の雰囲気 ── 取り壊し予定の台北の電脳街 ──
第9回 あえて台湾で製造するPCサーバ――新漢電脳製青龍刀の切れ味
第8回 日本がだめなら国外があるか――台湾で中小企業を経営する人
第7回 ベトナムとタイのコンピュータ事情
第6回 ヨーロッパ/ポルトガルのエンジニア事情〜インターネット通信〜
第5回 ヨーロッパ/ポルトガルのエンジニア事情〜ポルトガルのプチ秋葉原でハードウェア作り〜
第4回 ヨーロッパ/ポルトガルでのエンジニア事情〜市場と就職編〜
第3回 タイ王国でハードウェア設計・開発会社を立ち上げる
第2回 国内外に見る研究学園都市とハイテク産業の集中化…中国編(下)
第1回 国内外に見る研究学園都市とハイテク産業の集中化…中国編(上)

フリーソフトウェア徹底活用講座
第24回 Intel386およびAMD x86-64オプション
第23回 これまでの補足とIntel386およびAMD x86-64オプション
第22回 静的単一代入形式による最適化
第21回 GCC2.95から追加変更のあったオプションの補足と検証(その9)
第20回 GCC2.95から追加変更のあったオプションの補足と検証(その8)
第19回 GCC2.95から追加変更のあったオプションの補足と検証(その7)
第18回 GCC2.95から追加変更のあったオプションの補足と検証(その6)
第17回 GCC2.95から追加変更のあったオプションの補足と検証(その5)
第16回 GCC2.95から追加変更のあったオプションの補足と検証(その4)
第15回 GCCにおけるマルチスレッドへの対応
第14回 GCC2.95から追加変更のあったオプションの補足と検証(その3)
第13回 続々・GCC2.95から追加変更のあったオプションの補足と検証
第12回 続・GCC2.95から追加変更のあったオプションの補足と検証
第11回 GCC2.95から追加変更のあったオプションの補足と検証
第10回 続・C99規格についての説明と検証
第9回 C99規格についての説明と検証
第8回 C言語におけるGCCの拡張機能(3)
第7回 C言語におけるGCCの拡張機能(2)
第6回 GCCのインストールとC言語におけるGCCの拡張機能
第5回 続・C言語をコンパイルする際に指定するオプション
第4回 C言語をコンパイルする際に指定するオプション
第3回 GCCのC言語最適化以外のオプション
第2回 GCCの最適化オプション ――Cとアセンブラの比較
第1回 GCCの最適化オプション

フジワラヒロタツの現場検証
第72回 現場検証,最後の挨拶
第71回 マイブーム
第70回 OSぼやき放談
第69回 技術者生存戦略
第68回 読書案内(2)
第67回 周期
第66回 歳を重ねるということ
第65回 雑誌いろいろ
第64回 となりの芝生は
第63回 夏休み
第62回 雑用三昧
第61回 ドリームウェア
第60回 再び人月の神話
第59回 300回目の昔語り
第58回 温泉紀行
第57回 人材ジャンク
第56回 知らない強さ
第55回 プレゼン現場にて


Copyright 1997-2005 CQ Publishing Co.,Ltd.


Copyright 1997-2000 CQ Publishing Co.,Ltd.