船田さんは,
UNIX営業支援からパフォーマンス重視の世界へ
- 船田さんは1992年にNECに入社しました。最初に配属されたのは,
UNIXワークステーションのセールス部隊です。そのころの日本のメーカでは珍しかった, 製品を売る前に技術支援を行う特別チームの一員となりました。 - 私が入社した'92年当時,
日本のメーカはそれぞれ自前のUNIXワークステーションを売っていたんですよ。当社だとEWS4800などですね。私は, その上で動いているEWS-UXというUNIXの担当でした。お客であるVARやISVさんのところに行って, ワークステーションを使ったシステムをユーザさんに提供する手伝いをする仕事です。 -
たとえばCADソフト。国内のCADメーカさんも,
DECやSunのワークステーション上で動いているソースをEWS4800用に移植してくれるんですよ。ただ, 単純にコンバートしただけなので, 性能が思ったほど出なかったり, 特性に合うコーディングになってないことが多かったんです。それで, CADメーカと一緒に, たとえばタブレットの割り込みのタイミングを調整してCPUパワーを消費しすぎないように, といったところを支援して, サクサクっとスムースに動くようなところまで持って行く手伝いをしたりしていました。 -
大学では制御工学で,
ものをコントロールする研究をしていました。物体を見て, その動きに合わせて微分方程式を立てて, 式をソースコードに変換して, ポテンショメーターなんかを見ながら調整する。UNIXワークステーションに演算させ, RS-232Cで機器をつないで実験しましたから, NECに入ってからもそういうことに抵抗はありませんでした。そういう意味では即戦力だと思われていたのでしょうね。 - 船田さんが次に移ったのは,
通信系ソフトウェアの開発部門。ここではUNIXとは打って変わって, ひたすらプロトコルを追う毎日が待っていました。 -
通信といっても,
まだTCP/ IPなどは普及していなくて, 9600bpsのモデムで通信するものです。銀行やカード会社系で使っている 「全銀協手順」 だとか 「ベーシック手順」 と呼ばれていた独自のファイル転送プロトコルなどを実装する仕事です。言語はCOBOLでした。UNIXの支援の仕事のときはCでしたから, まさかCやったあとCOBOLの仕事が来るとは思いませんでしたね (笑)。 -
銀行やカード系などの業界標準のプロトコルは仕様が決まっているのすが,
そのハンドブックを見ても, 読み手によって解釈が違うところがあるんですよ。だから違う会社の機器どうしがうまく通信できない。そうなると, 通信回線に流れるデータを結局全部16進数でダンプをとって, RS-232Cの信号のDTRとかCTSとかどこで上がってどこで下がってっていうのを見なければいけなくなるんです。それで 「このタイミングでこの信号が下げてるから結局こっちで拾えないんだ」 と。それを見ながらどこまでも追いかけて直していました。 - このように書くと,
慣れない仕事に苦労していたように思えるかもしれませんが, 船田さんにとってはむしろ得意分野だったようです。それは, コンピュータやデジタル技術に趣味としても親しんでいた経験によるものでした。 -
学生のころから,
個人的にもプログラミングはやってました。GUIなどまだなくて, MS-DOS 3. 1とか, PC-9801にN88BASICがついてくる時代ですよ (笑)。ちょっと気の利いたことをやろうとすると, モニタコマンドで16進数で入力して, チェックサムで入力したものが合ってるかどうか, なんてことをやっていました。PC-98のBIOSは, この割り込みを使うとこういう音が出るとか, 色が出るとかあるじゃないですか。INT18でレジスタセットしてから最後にここを叩くとか (笑)。 -
そのあたりのプリミティブなことをやった経験があると,
今新しいことが出てきても, だいたい想像がつくというか, 理解がしやすいですね。そういう意味では, 今の学生は結構つらいのではないでしょうか。もっと原始的な, 積み木を組み合わせるような感覚で, コンピュータをどんどんいじった方がいいと思います。仕事上での粘りという点でも生きているはずです。
- こうした経験を経て,
今度はLinux上のネットワークで負荷分散を調整す る仕事に就くことになりました。Webシステムのロードバランサーの開発です。 -
Webの3階層システムをラックに組んで売ることになったんです。その1Uの筐体1つにロードバランサーが入っていました。Webの画面からロードバランサーの設定が全部できるという製品だったのですが,
その状態の変化を電子メールで通報するためのバックでリンクする部分を作りました。 -
ロードバランサーというのは,
1秒間にいくつセッションを振り分けられるかという性能勝負の世界なんですが, CPUの種類や周波数が変わってしまうと, 今まで処理できていた性能がガクッと落ちる場合があるんです。そのチューニングが大変でした。どこかのモジュールのルーチンが, たまたまそのクロックだとうまい性能を発揮しているというのがあって, 微妙なバランスで成り立っていたりするんですね。そういう場合は絶対マイクロ秒で待つのではなく, こっちのデータのIOが来たときに変わるようにしなければダメだった, というのが結構あるんですよ。さっきのタブレットの例みたいに。 -
最終的にはプロファイラにかけるんです。ソースコードのそれぞれの行に何クロックチップ使っているかを一覧表示して,
無駄なクロックがかかっているところは省くという作業をどんどんやっていって, 高速化を図ります。出荷時に一番スピードが出るよう最適化するのですが, 出荷直前になって歩留まりがどうのとかいう理由で, クロックやCPUの種類が違うモデルに変わっちゃうことがあるんですよ (笑)。はじめからやり直しです。ハード屋さんに言わせると 「ソフトなんかちょこっと変えたらすぐできるだろ。こっちは工場ラインの計画どおりきっちりしか動けないんだ」 なんですよね (笑)。