今回はプロセッサの舞台裏ともいえる、開発者にフォカースを当ててみる。プロセッサの設計にはどのような人々がかかわっているのだろうか?
今回は、いつもと毛色を変えて、「プロセッサを設計しようなどという設計チームには、どのような人々がいて、どのような楽しみ(悩み?)を抱えて仕事をしているのか」という話をしよう。プロセッサの設計というと、あまり一般的とはいえない仕事だが、「結局自分達の仕事と似たようなもんだ!」と分かっていただけたらうれしい。
実はプロセッサの設計過程について書く予定だったのだが、2つの理由で方向を転換した。1つは、数ある設計チームごとに、それぞれ特有のやり方があり、お互いに話をすれば楽しく(?)議論もできると思うのだが、一歩下がって関係ない人の視点に立てば、「ビミョー」なところの議論が白熱してしまって面白くないと思ったからだ。もう1つは、一般的な設計手法などの話もできるが、そういうのは設計者相手の専門誌を読めば十分だからである。
さて今回、想定するのは「新しいプロセッサを世に問おう!」と燃えている設計チームである。まぁ、実際には新しいプロセッサ・コアを設計するようなチャンスはそれほど多くない。多くの場合、プロセッサ担当といっても、「ちょっと直した」派生品やら、仕立て直しの改版品などにかかわっている人が大多数であるし、そうした仕事にかかわる時間も圧倒的に長いのだ。それはそれで日々の生活なのだが、今回は大プロジェクト「新プロセッサの設計」にかかわる人々を取り上げることにする。
1人や2人でプロセッサが設計できないわけではない。特に最近は設計ツールもFPGA(Field Programmable Gate Array:プログラミングによって機能が変更可能なLSI)のようなデバイスもあるので、「取りあえず」モデルを作って動かす程度ならば、1人でもけっこうなことができる。だが、「商売になる」プロセッサを作ろうと思った瞬間に、相当な人数とお金がかかることを覚悟しなければならない。このあたりがプロセッサ商売の難しいところだし、プロが必要になる部分でもある。
まずプロジェクトの主要人物だが、第1に挙げるとすれば「アーキテクト」、訳せば「建築家」だろう。昔は一種の芸術家的な雰囲気があり、少し格好いい響きがあったので、敬意も込めてプロジェクト・リーダーあるいはマネージャよりも先に取り上げる。要は、プロセッサの基本構想を作る人物である。たまに「構想」というよりも、「妄想」を撒き散らしている場合もあるのだが。昔の有名なコンピュータには、必ず「スター」アーキテクトがいたものだ。「定量的」なアプローチが定着した昨今では、実際はそう芸術家のように「表現」を求めるわけにもいかなくなり、地味な仕事になりつつある。
だが、アーキテクトが1人いれば、エンジニアの40〜50人分の仕事をすぐに作ってくれる、というのはだいたい正しい。そんなアーキテクト商売の一番大事なことは、後についてくるエンジニアに確固たる自信で、ときには尊大な態度で、「こういうものを設計せよ!」と指示し続けることである。アーキテクトが自信ない顔で後ろを振り向いて、みんなと相談し始めると、だいたいにおいてチンケなプロセッサが出来上がる。
次に、その苦労からプロジェクト・リーダーを取り上げよう。これが、またけっこう微妙な立場なのである。いわゆる管理職なのだが、マネージャがプロジェクト・リーダーをしていることも多いし、あるいはアーキテクト兼リーダーとか、プレイング・マネージャ的にエンジニアの兼務という形も多い。プロジェクト・リーダー、マネージャ、アーキテクト、エンジニアは、同じ人がたとえ担当していたとしても、仕事の内容は別であるべきだ、というのが筆者の持論だ。
アーキテクトは、主として性能や機能といった面から設計する「物」を計画するのが仕事だ。プロジェクト・リーダーは、そうしてできた仕事を分割し、エンジニアなどに割り当て、スケジューリングし、進捗具合をモニタし、叱咤激励し、場合によっては悩みを聞いたり、病院に見舞いに行ったりする。半導体なんていう物の上で踊っているが、こちらは本質的には物相手でなく、人相手の仕事だ。当然ながら人の気持ちが分かる人でないと務まらない。だからアーキテクトと兼任すれば二重人格になるし、エンジニアと兼任すれば自分の仕事をしながら他人の仕事も手伝う羽目になる、といった具合になってしまう。
設計の仕事は、始めゆっくりと動き始め、あとで一気に盛り上がるのだが、新規のプロセッサともなると、その盛り上がった状態の期間が長い上に、かかわる人数も多くなる。そのため、プロジェクト・リーダーが、プロジェクトのフェイズとメンバーの適性、能力、負荷のバランスをよく見て、仕事をうまく割り振っていかないとプロジェクトは破綻・発散といった事態におちいってしまう。成功すれば偉大なアーキテクトの功績だが、失敗すればプロジェクト・リーダーが責められることが多い。何とも割に合わない仕事である。
じゃぁ、マネージャは何をしているか? プロジェクト・リーダーの仕事は、一般にはマネジメントの一部かもしれないが、新規プロセッサ・コアの開発プロジェクトにおけるマネージャともなると、もう少し後ろめたい業務に携わることも必要になってくる。もちろん、会社組織の中で必要になる諸々の管理業務も一杯あるが、ここでの最大の仕事は「自分のプロジェクトを守る」ということだ。何せ、新規プロセッサ・コアの開発となると、人・物・金のリソースを大量に消費する上に、たびたび問題が勃発したり、設計しているものよりも良さそうな製品が他社から発表されたり、その上スケジュールは大幅に遅れたり、といった具合に社内での風当たりが強くなっていくからだ。
ぼやぼやしていると、プロジェクトの打ち切り、という憂き目をみる。そこでマネージャは、どこからかリソースを奪ってきたり、スケジュールの遅延の言い訳をして何とかごまかしたり、あるときは他社と同盟を結んだり、ときには逃亡を企てたりと、あらゆる使える限りの策謀と術策で製品が世に出るまでプロジェクトを守らないとならない。社外で競合するプロセッサと争う前に、後ろから飛んでくる矢や鉄砲でボツになるプロジェクトの何と多いことか。そう、マネージャには夢はいらず、ただし恐れもない。多かれ少なかれマキャベリスト(陰謀家)でないと務まらない。
さて、次に主力設計部隊の話をしよう。ここは大きくフロントエンド部隊とバックエンド部隊の2つに分かれる。
フロントエンド部隊は、アーキテクトの構想をうけて論理設計や回路設計をするエンジニア達だ。最近は言語設計(回路を言語で記述するという設計方法)が主力なので、傍目にはソフトウェアをコーディングしているのと見分けがつかない。ときどき、シミュレータ出力の波形を眺めたりしているので、ハードウェアの設計を行っているのだ、ということが分かる程度だ。ただ、本質的にソフトウェアと違うのは、最後は神の定めたる物理法則に支配されるという制限があることである。アーキテクトの出す無理難題と神の狭間で頭脳を使って肉体労働する定めだ。
バックエンド部隊は、フロントエンド部隊の作った「ネットリスト」などと呼ばれる回路情報から、半導体上に回路として動作するパターンを形成するためのマスク(本当は「レチクル」と呼ばれる)情報を作り出すのが仕事だ。というと何だか分からないかもしれないが、ペルシャ絨毯のような半導体のレイアウトを思い浮かべると分かりやすくなるだろう。このレイアウトを、設計どおりの細密画として描くのが仕事である。小さな四角を組み合わせただけのパターンながら、1個のトランジスタを表現するのに数十程度の図形が必要となる。1000万トランジスタともなれば、数億から数十億もの図形がある勘定だ。この図形からこの図形までの間は0.1μmにしろとか、オーバラップ(重なり)は0.2μmだとか、やたら細かいルールがたくさんある。その上、数十億の図形のうち、ただ1個所間違えても半導体は動かない、と脅されるのだから始末が悪い。もちろん、大多数の図形はコンピュータのプログラムで作る。しかし、手で1個1個入力するような部分も必ずあるのだ。向き不向きもはっきりあって、そうそう向く人がいないのもこの仕事の特徴である。
バックエンド部隊の人(特にバックエンド部隊に向いていて、そればかりやってきた人)の中には、フロントエンド部隊に変わりたいとひそかに思っている人も多いようだ。というのも、フロントエンド部隊が「ネットリスト」を作成して、ようやく動けるようになるバックエンド部隊は、常に受動的になりがちだからだ。その上、フロントエンド部隊のスケジュール遅延をバックエンド部隊でつじつまを合わせるといったことは、よくある現象である。「押し付けられる」バックエンド部隊でなく、「自主的に動ける」フロントエンド部隊で仕事をしたいと願うのも、もっともなことである。もちろん、「隣の芝生は青い」ということなのだが。性能の高いプロセッサには、いいバックエンド部隊が必須なのだが……。
さて、このあたりがほかの半導体と違うところなのだが、プロセッサの場合には半導体の設計部隊以外にも設計部隊が必要になる。開発ツール、その中にはICE(In-Circuit Emulator:マイクロプロセッサをハードウェア的にエミュレーションするデバッガの1種)のようなハードウェアもあるし、コンパイラやアセンブラのようなソフトウェアもある。そういう道具を作る部隊だ。それらがあって初めてプロセッサを使うことができるようになる。当然、プロセッサが完成したところで、それを載せるボードがなければ動かしてデモを行うこともできないし、OSだって必要になるだろう。通信するにも、絵や音を出すにもミドルウェアといわれるようなソフトウェアがいる。このようなハードウェアやソフトウェアを担当する人たちがいなければ、プロセッサの商売は始められないだ。
小規模なプロセッサ開発プロジェクトの場合、そういう担当者がプロジェクトに数人いるだけ、ということもあるが、大きな会社ではそういう製品を作る専門の独立した子会社になっていることさえある。専門のサードベンダに委託するというケースも多いので、一概にいえないが、最低でもそういうハードウェアやソフトウェアが分かっているメンバーが数人はいないとプロセッサ開発のプロジェクトは成立しない。ただ、半導体業界の中にいる、そういうハードウェアやソフトウェアの担当者は、ICを担当しているほかの大勢のエンジニアの中では、少し異端な存在になる。世間的にはソフトウェアにかかわる人口の方が圧倒的に多いはずなのに、ここでは逆転して少数派になってしまうのだ。その上、ソフトウェアのエンジニアでも、ロジアナ(ロジック・アナライザー:計測器の一種。デジタル回路が出力する電気信号の波形などを調べることが可能)など使い、正しそうなソフトウェアを使ってバグのあるプロセッサのデバッグなども行うので、もう普通のソフトウェア・エンジニアではなくなってくる。深みにはまって行く人もいるにはいるが、普通のソフトウェア・エンジニアに戻りたいとひそかに願っている人が多いのも事実である。
ほかにも設計ツールなどを整備するCAEエンジニアや、出来上がったLSIのテストを担当するテスト・エンジニア、試作から量産まで面倒をみるプロダクト・エンジニアなどもいる。それに各種半導体の中では、一番分量の多いマニュアルを書かなければならないプロセッサを担当させられたテクニカル・ライターや、質問の多い顧客と向き合うFAE(フィールド・アプリケーション・エンジニア)、売り上げが立つまでの忍耐が必要とされるセールスなど、巻き込まれてしまった多くの人々もいるのだ。さらに、マーケティングに広報、販促、あと忘れてはいけない品質保証まで、けっこういろいろな人がいてようやくプロセッサが世に出るわけである。それに、忘れたわけではないが、製造関係者やプロセス、デバイスの開発者といった人々もいる。実に多くの人がかかわって、プロセッサができていることが分かる。
日本では数少ないx86プロセッサのアーキテクト。某米国半導体メーカーで8bitと16bitの、日本のベンチャー企業でx86互換プロセッサの設計に従事する。その後、出版社の半導体事業部を経て、現在は某半導体メーカーでRISCプロセッサを中心とした開発を行っている。
「頭脳放談」
Copyright© Digital Advantage Corp. All Rights Reserved.