第62回

Engineering Life in Silicon Valley

日本でシリコンバレースタートアップを体験する
(第三部)


前回まで:シリコンバレーが本拠地のスタートアップに入社したあとの,日本の開発拠点での仕事について話を展開した.

MBO――数値目標


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

太田博之(おおた・ひろゆき):(株)デンソーにて長年,通信用ASIC開発に携わる.その後,(株)HDラボ(本社新横浜)で通信用LSI開発の設計コンサルタント,出資者,取締役として活躍する.2000年にはシリコンバレーに本社を置く大手IP(Intellectual Property)ベンダであるインシリコン(InSilicon, Corp.,本社サンノゼ)に移り,名古屋郊外に開発研究拠点を開設する.Bluetooth IPの開発にDirector of Engineeringとして従事.その後,フリーの通信関連技術コンサルタントを経て,現在は電子部品商社の加賀電子で通信関連機器,部品のマーケティング業務に従事.本誌,その他エレクトロニクス系技術雑誌に連載多数.



シリコン・バレーの会社だからMBO(Management By Objective注1)があったでしょう?
注1:インテルで発案された経営手法で,結果責任(Accountability)を明確に数値化して正当に評価しようという方法.仕事の内容をすべて数値で表さなければならない.詳しくは,1998年7月号を参照.
ありました.給与に反映する正式なものは,3か月に一度,要するに四半期に一度決めて,その終わりに達成度を確認します.自分でいくつかの項目を考えて,それぞれのゴールを設定します.ゴールを数値で表すことによって客観的に評価されるようになります.いちばんわかりやすい例は,開発プロジェクトの中間ゴール……マイルストーンをいつまでに達成するかなどです.あとは,その間の必要出費をいくらまでに抑えるとか,人事関連のゴールで必要な人材の候補を何名,いつまでに面接するとかなどです.

なるほど,典型的なシリコンバレースタイルのMBOですね.それで何か発見はありましたか?
はじめは変動給を与えるためのしくみぐらいに捉えていましたが,会社としてのゴールとかなり直接的に関係していることに気付きました.

 面白いと思ったのは,私のMBOが私の上司のMBOとリンクされている部分です.そのときは,直属の上司とじっくり協議して内容を決めます.

 また,組織の中の個々の達成するゴールが階層化されたプログラムのように組み上げられています.エンジニアだとプロジェクトをスタートする前に,タスクという最小ユニットで事細かく作業や工程の手順を割り出します.タスクは,だいたい一人が2週間以内でできる作業です.これをつなぎ合わせると一つの仕事の流れが明確になるし,プロジェクトの工程がはっきりします.その結果,タスクの流れからMBOに乗せるゴールが大体割り出せます.逆にいうとタスクにならないものや,タスクとして答えられないもの,うまくMBOに乗らないものは,誰も担当者が決められていないので,問題であるか未解決であるということです.


組織として階層的にゴールを設定しているのは確かで,最終的に社長は役員会に対してMBOを設定します.さらに上から下まで全社員にMBOがある会社もあります.会社によっては,若干MBOの運営方法に差があり,厳しい会社だとMBOの各項目達成はバイナリ的――0%か100%――に評価するところがあります.もう少し緩い会社だと3段階,0%,50%,100%達成などですね.
上司や周りの人に自分のMBOが公開されていますから,それが逆に仕事をやりやすくしていたと思います.周りの人も協力するし,自分のほかのチームメンバにも協力します.そして,上司は私のMBOを自分のMBOとして見ているわけですから,問題があっても責めることなどはしませんね.これが日本だと,年に1回か2回の査定で12か月のゴールを設定するので,期間が長すぎて漠然としていました.シリコンバレーのMBOだと3か月ごとの目標設定ですから,変化の速いエンジニアリングの世界では良いタイミングだと思います.日本の査定の12か月は長すぎるでしょう.3か月なら,仕事量が多すぎれば明確になってくるし,足りなければもっと任せたりできます.また,開発が進む中で仮説を立ててスタートしたプロジェクトのゴールなども変わりますから,非常に現実的で合理的だと思いました.

MBOはプロジェクトに関連性をもたせていますから,日々の作業を整理するうえでも大事ですよね.
そうですね,日本の査定はその人間を評価しようとするところが欠点だと思うのです.シリコンバレー式のMBOだと,プロジェクトに直接リンクした方法で評価されます.「一生懸命頑張ったから……」とか口実がきかないので厳しいようですが,逆に非常にフェアなのでやる気が出ると思います.

参加者全員の時間を無駄にさせないミーティング


開発プロジェクトでシリコンバレーと日本の2か所の拠点で開発が行われると,会議はどうされましたか?
スピーカフォンとNet Meetingを併用しました.表計算ソフトで見積もりやスペックの議論が展開したので,Net Meetingは便利です.チャットで筆談ができますし,後から議事録みたいになりますから一石二鳥です.もっとも感心したのは,ミーティングのやり方ですね.

そうですよね,長い会議はほとんどありませんからね.
3人以上集まる会議では必ず議題(アジェンダ)が設定されます.これは数日前からメールで送られて来て,議題に載っていない話題は会議中に話をしません.その場で答えられないものは,アクションアイテム(宿題)にして締め切りを明記します.要するに,会議は議論する場であってその場で考えるのではないという共通認識があります.

そうですね.ですからたとえば10人集まった会議で3人だけで議論をしていると,その3人で別な会議をもつべきだということになり,次の議題にいきます.ほかの参加者の時間を無駄にしないという意識があります.
上下の関係なしに会議前の作業,準備そして会議後の宿題をちゃんとやってきますから,会議は短い時間で終わるし,ペースが速いです.日本だといつ終わるのかわからない会議とかがたくさんありますからね(笑).

翻訳ソフトを文法チェッカーとして使う?!


さて,英語の話が出ましたが何か苦労されたことは?
上司も元々英語がネイティブでない人だったので,日本人スタッフの英語のハンディに非常に理解がありました.口頭で通じないことなどがあるといけないので,電子メールでの連絡,Net Meetingのチャットや筆記でのやり取りが重要でした.そこで感じたことは,シリコンバレーのエンジニアたちは文章にするのがけっこう好きだということです.仕様書などもしっかり書かれているし,日常生活でもレストランのメニューでも文章が多いですよね.

たしかに英語は日本語と比べるとかなり細かい言語だし,曖昧さを許しませんね.方程式やプログラミング言語みたいなところがありますよね.
同感です.語彙が豊富で明確なところがありますよね.WillとShallの使い方でも違うし……日本人同士だと語彙が少なく主語がない文章でもOKですからね.日本語はすぐ絵や図にしたり,箇条書きが多く一見しっかりしているようで,実際じっくり読んでみると曖昧な仕様書などがよくあります.英語の仕様書の説明をよくやるのですが,順番に読んでいくとブロック図がちゃんと描けたりします.私は後から追っていくスタイルを取ります.

面白い読み方ですね!
だいぶ慣れてきて思ったのですが,意外と日本語は矛盾している文章を書けてしまいます.そのため,英語を書くときに翻訳ソフトの力を借りました.英作文は自分でしっかり書くのですが,書いた後に英語から日本語に訳してみます.これで自分の伝えたいことがまともな日本語で返ってこなければ,自分の英文に問題があるということが判明します.最近のソフトは大分よくなっていて,かなり使えると思いました.そのおかげで送ったメールも問題なくアメリカ側で理解されていました.自分の英作文の能力も向上したと思います.たとえば定冠詞・不定冠詞の使い方などですね.

なるほど! 文法チェッカーとして英日翻訳ソフトを使うのは賢い使い方ですね.

次回について


 アメリカ人エンジニアの特徴など,シリコンバレーのスタートアップでの貴重な経験について報告する.また,今後日本のエンジニアがどうあるべきか?についての話が出た.

Column ストックオプションの扱いについて

 不正会計疑惑が多い最近,アメリカ企業で議論になっているのがストックオプションの扱いだ.ストックオプションは,ある価格で株を購入できる権利を与えられる 注A.この価格は,ストックオプション交付日の15%引きなどが多い.株価が上昇すれば将来ストックオプションを行使することで安価に株が購入でき,そのまま売れば現金化できる.もともと重役レベルにしかなかった特権だが,シリコンバレーのスタートアップが一般社員に与えて士気を高めようとしたため,アメリカの多くの企業で広く採用されるようになった.とくに現金の余裕のないスタートアップでは,給与をかなり低めに設定する.給料が低い分,ストックオプションで会社の魅力を得ようとするものだ.

 しかし,最近の事件で企業のトップが架空の売り上げを計上し株価を吊り上げたり,問題が発覚する直前に上層部がオプションを大量に行使したなど(インサイダー取引になる),さまざまな問題があった.株主からすると社員だけが安く株を購入できるということは,全体の株価の価値を下げ,一般株主の懐からストックオプションを運営している……という議論が展開されている.上層部の乱用を見ると安易にストックオプションを与えるのは良くないのでは?とかストックオプションには会社側のコストやリスクがあるのでそれを公開すべきだという議論がもっともホットだ.しかしオプションの会社側コストを明記すると赤字に転じる会社があまりにも多いので,かなり慎重だ.また,ストックオプションをコスト化するにしても,価格を明確・正当に評価するのは会計的に見ても非常に難しい 注B.コカコーラなどがオプションをコスト化する方向で最近発表があった.逆にシリコンバレーを代表するインテルは,コスト化をしないと表明した.シリコンバレーでは,ほとんどの企業がオプションを与えており,大幅な人件費圧縮に貢献しているので猛反対なのは間違いない.


注A:詳しくは,1998年8月号を参照.
注B:会計の分野では最先端らしく,ノーベル賞を取った経済学者がいるとか?




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

 


copyright 1997-2002 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-2002 CQ Publishing Co.,Ltd.