Engineer Life in Silicon-Valley 第58回

ドキュメンテーションがきっかけ

ニックはもともとハードウェアエンジニアだったのですよね？　最近はソフトウェア寄りの仕事をしているみたいですが……．

そうです，Amdahl社でECLチップの設計をやっていました．当時は最大500ゲートぐらいのチップで各ボードに20～30個ぐらい実装されていましたね．すべて社内で作ったツールを使ってデバイスを作っていました．

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

Nicholas Y. Pang（ニコラス・パング）：マレーシア生まれ，少年時代をイギリスで過ごした後，アメリカで電子・情報工学の勉強をする．ウィスコンシン州大学にて修士号を取得．メインフレームメーカーのAmdahl Corporationを経てCadence Design Systemsのコンサルティンググループでハードウェア設計の経験を積む．その後インターネット関連の仕事に転進，PointCastでコンテンツプロデューサの職につく． ’99年からWhere2Net, Inc.を設立する．男の子2人，女の子1人と奥様の5人家族．

ECLチップとAmdahl！　懐かしいですね． ’80年代の初期だと私はまだ学生でしたが，大学でも人気の会社でしたよね．ECLは富士通で製造されていたと記憶しているのですが……．

たしかに80年代だとまだパソコンも業界として認知されなかったので，コンピュータの仕事をするならIBMかAmdahlでした．8080や8086がやっと出てきた時代で，ECLデバイスは富士通のラインで作られており，当時は3週間程度のTATでした．のちにAmdahlが富士通の子会社になったのはこの関係からです．

内製ツールはどういうものでしたか？

ロジックやブール方程式を手動で作成し，チップ上の素子に自社製回路図エディタみたいなもので入力して組むものです．シミュレータや検証ツールは自社で開発しました．元となるアルゴリズムやソースコードは，大体CADが盛んな大学の研究論文，たとえばUC Berkeleyなどの論文と一緒に発表されるソースをヒントにしたりしました．また，その大学の出身者を雇ったりもしました．私は設計のほうだったのですが，ツールを作る部門とよく意見を交換しました．

それでソフトウェアの世界に入っていったのですか？

いいえ，それがちょっと変わったきっかけでして……．当時の社内で複数のグループと共同設計をすることが多かったのですが，それぞれのグループが異なったドキュメントを作るので設計ミスが多かったのです．あるグループはWordとFrameMakerを使ったり，あるグループはUNIXのviを使ったり，また違うグループはtroff/nroffを使ったりしていました．お互いに設計したドキュメントが読めないのでミスが出るわけですね．そこで自分でプログラムを書き，すべてRTF（Rich Text Format）に変換して，ファイルはFrameMakerで読むことができるようにしました．結局，データベースのようなものを構築し，内容のクロスリファレンスを取ったりできるようにしました．まあ，1982年ぐらいだからまだハイパーテキストができる前の時代ですよね．そのときはMIF（Markup Interface Format）というマークアップ言語を初めて使ったため苦労しました．現在あるようなブラウザがあればどんなに楽だったことでしょうか．

troff/nroff……懐かしい名前です．大学ではほとんどあれで卒論などを書いていたし，職場でもそのまま使うところが多かったですね．現在のHTMLなどのマークアップ言語が出る前のハイパーテキストによるプログラミングで，そういう意味では時代の先を行ってましたよね（笑）！

ユーザーのフィードバックのたいせつさ

実際はAmdahlではメモリやキャッシュの設計などをちゃんとしていたんですよ．それでRedwood Design Automationというベンチャー企業を経てCadenceのコンサルティンググループに移りました．ここでは，いままでの設計経験をもとに顧客のデザインサービスを行うわけです．SONET ATMやDEC Alphaのシミュレーションモデルやツール上で動くエミュレータを作りました．

どういうところが面白かったですか？

Cadenceはツールベンダなのですが，私のグループはそのツールを実際に使って設計の一部を行っていました．これはツールのバグ出しや足りない部分を見つけるのには有効でした．オラクルでもよくやるのですが，まだ存在しない製品をコンサルティング契約の中から作りあげる方法です．つまりコンサルティング契約で作業した結果を製品に反映させるわけです．

う～ん，まだできていない，もしくは存在しないVapor Wareを売りつけて先にお金をとってからつじつまを合わせたりするという話に似ていますが（笑）．でも顧客の欲しいソフトと実際の問題を元にプログラムが書けるので，確実ですね．

同感です．私もこの数年自分で製品を企画して書いたりしていますが，テストには頭を痛めます．自分の想定したセルフテストでは限界がありますが，良いベータテストならば本当に製品の質が変わると思います．どうしてもプログラムの中から外を見た感覚でテストを作ってしまいますから．

内面から見たバグ出しはメモリリークを直したりとかデータのやり取り的などの基本演算みたいなものが多いですよね．でも，実際のユーザーテストになると企画する際に想定したユーザーモデル，ストーリーボードが正しいかチェックされますね．

そうそう！　自分達のストーリーボードの内容が間違っていると，根本的に使い方に無理があるとかそういうことですから．また，そこそこ使えたとしてもユーザーの使った感覚，User Experienceに大きく響きます．そういう意味ではマイクロソフトのUIはうまいですよね．みんないろいろ文句はあるかもしれないけれど，レガシー的なものから新しいものまで，うまく吸い上げて製品に反映させていると感じています．

　あとは，子供の使うソフトなどのUIも出来が良いですよね．ソフトではないのですが，子供がゲームボーイで遊んでいて，自分の名前を入力するところを見ていたのですが，キーボードがないのに画面上の疑似キーボードみたいなものでスイスイと入力してました．十字キーとほかのボタンいくつかだけでもかなり速かったですね．ゲーム機も少ないボタンやインターフェースでさまざまな機能をよく実現していると思います．子供にとって自然にできているのでしょうか？　それとも過去遊んだゲームの経験が反映できるようになっているのでしょうか？　とにかく，マニュアルなど読まないでゲームが進められるみたいです．だから，自分のソフトも子供にGUIの部分を見せて意見を聞いたりします．

デベロッパープログラム

良いソフトウェアには，必ず良いお客さんが裏にいるといわれてます．親身になってちゃんと製品を使って，意見や感想の述べてくれるお客様は本当にたいせつです．どんな規模のソフトウェアの会社になっても，ユーザーコミュニティを上手に育てられるかどうかが大きいですね．

同感です．実際ツールやプラットホーム上でまたアプリケーションを展開していますから，技術的な質問などはすぐ対応があるとこちらの仕事も進みます．

私もPDAの会社でデベロッパプログラムの一部に参加していましたが，もしかしたら製品を世の中に出すよりたいへんかもしれません．PDAだからエミュレータ，ライブラリ，ドキュメントなどの整備と，ハードの手配，外部のプログラマにはフラッシュでアプリを書き込める特別のハードの手配など．出荷する製品よりもそろえるものが多いですね．それから実際の技術的な対応とか．コアのデベロッパはソフトの世界でけっこう発言力があるので，へそを曲げられるとたいへんです．

自分でソフトウェアの会社をやってみて気が付いたのですが，開発者以外にエンジニアが必要ですよね．たとえば，こういうデベロッパプログラム関係の人とか．会社によっては，技術者ではないマーケティング系の人がやる場合が多いのですが，エンジニア対エンジニアの付き合いが多いので，やっぱりエンジニアのほうが信用されます．たしかに，「このプラットホームでソフトを書けばもうかる」という話で，ビジネス系の人とも会う必要はあるのですが……．

でも基本的にはエンジニアの仕事なので，エバンジェリストなどはエンジニア系のほうが受けが良いですね．たしかにサポートやテストをする人などいろいろと考えると，実際にプログラミングをする人以外に人数をそろえる必要ありますね．

インターネットコンテンツの仕事

さて，話題は変わってPointCastの話をしてください．設立当時は，プッシュコンテンツの先駆的な存在でしたよね？

そうですね， ’96年あたりはまだ28K，56Kのダイヤルアップが主流でしたし，一般消費者に対するオンラインショッピングやオンラインバンキングがまだまだできつつある段階でした．そういう意味でプッシュ型のニュースなどが面白く感じたのでしょう．私は， ’80年代ぐらいから株取引が好きで，暇さえあればいろいろと研究したりしていました．そういう背景もあってPointCastの金融ニュース関係のプロデューサの職に就きました．

そうですよね，ニックは株が大好きですもんね（笑）．趣味と仕事が一致して楽しかったのでは？

はじめは良かったのですが，会社の経営的な問題と技術的な問題がありました．技術的な問題は，コンテンツを変えるのに社内での複雑な書類手続きが必要だったことと，ツールが独特だったことです．ツールは，MIT出身のエンジニアが多かったのか，Perlを採用せずに，MITのSchemeという言語でコンテンツを扱っていました．LISPみたいな言語で，パースされるのが遅いし，拡張性が低いうえに学ぶのに手間がかかり，なかなか社内のエンジニアが育たない状態が続いていました．また，私は個人的にWebサーフするのが大好きなので，ほかのコンテンツがどれぐらいのレベルに達していたかをよく見られたと思います．しかし，経営が創業者のChris Hakettから大企業のメディア系の人に代わっていく段階で，いままでのメディア業界的な考え方が持ち込まれました．結局，Web上の変化についていけない状態になってきました．

たしかに，ある時期メディアの融合ということで大量にメディア系の人達がハイテク業界に入ってきましたよね．でも結局自分からヘビーユーザーになるぐらい使いこなさないと，何が必要かわからないわけですよね．ツールの選択でもけっこう落とし穴があるものですよね．これは意外な話です．

次回の予告：

　PointCastの経験を経て新しい会社を自ら設立したり，今後の技術的なトレンドや個人的な生活などについて語られる予定である．

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