149. 携帯情報端末の開発記(IT戦記4) (2007/2/15)


戻る前回次回
長机に丸椅子に旧式のコンピュータでやりがいのある仕事をするのと、広い机にふかふかの椅子に最新のコンピュータで変わりばえのない仕事をするのとでは、あなたはどちらを選ぶだろうか。あるとき私はやりがいのある仕事をやっていたが、劣悪な環境に腹が立ち、本腰で仕事に取り組むことが出来なかった。今回はそのときの話をすることにする。

それは携帯情報端末のソフトウェアを作る仕事だった。知っている人は知っているかもしれない製品なのでNDA(機密保持契約)に触れないよう曖昧に多少創作を交えて書く。というか大分前のことなのでかなり忘れた。

■はじまり

部長に呼ばれて今回の話を聞いたとき、部長の話し振りがいつもどおり淡々としていたので、今回もそれまでと大して変わらない仕事なのだなと思った。そういう空気で話を聞いていたので、私はついこんなことを言ってしまった。
「今回の仕事をこなせば次はもっと大きな仕事が来るのですね」
「いや今回の仕事は大きいよ。次はないと思う」

こうして集められた面子は、部内で一番の変人と言われていたH先輩と、寡黙だがものすごい技術を持っているという東工大出のおっさんスーパーハッカーTさん、イギリスの大学を出て英語がペラペラだという同期のMさん、これらの面子を束ねる温厚で背が低いリーダーのEさん、私も入れて合計五人のチームである。

仕事は精密機器に強いメーカーから来た。ハードウェア中心のメーカーなのでソフトウェアのエンジニアが足りていないらしい。向こうにもソフトウェアエンジニアはいたのだが、数的にも質的にもこころもとないのでうちに声が掛かったのである。

開発はメーカーの工場に隣接する研究所で行われた。私たちは郊外にあるその研究所にバスを乗り継いで通い詰めた。

■チーム

チームは大きく二つに分けられた。ファームチームとパソコンチームである。あんまりいっぺんに人物を紹介しても覚えきれないだろうからそのつど説明するので以下は流して読んで欲しい。こういうとき作家さんならうまいこと話を進めながら人を紹介していくのだろうけど。

携帯情報端末というのは、ハードウェアの制限の関係でパソコンと同じソフトが使えない。画面だって小さいし、CPUだって遅い。なにより独自のハードウェアなのでソフトウェアも独自に作らなければいけない。最近ではARMやXScaleなどのモバイルプロセッサを使ってOSはWindows CEやPalm OSなんてのを使うのが一般的になってしまっているが、当時はまだ独自のハードにOSというのが自然だった。従って私たちはこのハードだけのためのOSからAPIからアプリケーションまで全部作らなければならなかった。用語が分からない人のために言うと、要はWindowsみたいな基本的なソフトから作らなければならないということだ。このソフトウェアを作るチームがファームチームだ。メーカーの技術者がOSやライブラリなどの基本的な部分を作るので、私たちはアプリケーションの部分を作るという話だった。こちらがメインなのでリーダーEさんとおっさんスーパーハッカーTさんと私が担当した。

一方で携帯情報端末というのはそれ単体では十分に使いこなせないようになっている。パソコンで用意したデータを携帯情報端末に送ったり、携帯情報端末で作ったデータをパソコンに戻したりする。こうすることで、スケジュール帳やその他のデータを有効に利用できる。となると、パソコン側でもソフトウェアを用意しなければならない。このソフトウェアを作るのがパソコンチームである。ただしこちらは何から何まで全部作るのは大変なので、海外のソフトウェアを利用して今回の携帯情報端末に合わせて使えるようにすることになっていた。この部分は丸々私たちが受けた。英語がペラペラの同期Mさんと、短期ながら海外で仕事をした経験のある変人の先輩Hの二人がこの部分を担当した。

メーカーのソフトウェア技術者は、設計能力を買われてかOSの中核的な部分を担当した横分けXさんと、ちょっと年配だがオタク的な風貌をした髪ボサボサのYさんと、部署内で一番の若手ながら部署の次期リーダー候補のようにかわいがられていた気鋭の技術者いがぐり頭Zさんの三人だった。

あと我々にはブートローダを作る技術がなかったため、うちの部長のツテをたどってよそのメーカー系ソフトハウスに投げた。

■エミュレータ

開発は、のっけからおっさんスーパーハッカーTさんの独壇場だった。

独自ハードウェアでのソフトウェア開発の場合、特に携帯情報端末だと開発環境を同じハードに入れることが出来ない。そりゃ携帯電話のアプリケーションを携帯電話で開発するわけないし当然だ。そこでクロスプラットフォーム開発という手法が使われる。つまり開発対象のハードウェア用のソフトウェアを、別のハードウェアの開発環境で作るのだ。この手法の利点は、携帯電話のような貧弱なハードウェアのためのソフトウェアを、パソコンのようなありあまる性能を持ったハードウェア上で開発できることだ。欠点もまた明らかで、開発環境上で作ったソフトウェアをそのままでは動かすことが出来ない。そのため、ある程度ソフトウェアを作るたびに作ったソフトウェアを対象となるハードウェアに転送して動かす必要がある。この手間は開発が終わるまで続く。ちょっと考えれば分かるがこれは馬鹿に出来ない手間と時間が掛かる。

そこでスーパーハッカーTさんはエミュレータを開発することを提案した。エミュレータとは一般的にはある仕組みをそっくりそのまま真似る仕組みのことだ。似たような言葉としてシミュレータという言葉があるが、シミュレータがあくまでそれっぽさを再現するだけなのに対し、エミュレータはまさにそのままのものを再現する仕組みを指す。対象となるハードウェアを真似た仕組みを開発環境内に用意することで、作ったソフトウェアをハードウェアに転送することなくその場で擬似的に動かすことが出来る。クロスプラットフォーム開発でごく一般的に使われている手法である。携帯電話を例にとると、パソコン内に携帯電話のハードと同じ動きをするソフトウェアを作るようなものだ。

エミュレータの開発を提案するだけなら誰でも出来る。Tさんのすごいところは、当初そんなものを予定していなかったスケジュール内で、自らの手でそれを作り上げてしまったことにある。とはいっても一から全部作るのはさすがに時間が掛かり過ぎる。対象ハードウェアはZ80という超有名なCPUの互換部品を使っていたため、フリーで公開されているZ80のエミュレータに今回のハード独自の部分を付け加えるだけで済んだらしい。とはいっても今回のハードウェアにしかついていない色々なデバイス、液晶ディスプレイやらタッチパネルやらボタンなどの各種入出力があり、それらを完全に再現しなくてはならない。それでも今回はハードウェアの技術者がすぐ廊下を挟んだ向かい側にいたので、ハードウェアの仕様が完全に分かるだけまだ楽なものだ。

このエミュレータがあるおかげで、開発環境で作ったROMイメージをエミュレータのフォルダにコピーしてエミュレータを実行するだけですぐに動作確認が出来た。もしエミュレータがなかったら、特殊な機械を使ってパソコンからフラッシュROMに書き込み、そのROMをハードウェアの試作基盤に差し込んで電源を入れて実際に操作する必要があった。特殊な機械がいるのでチーム内で機械を使いまわさなければいけない。もっとも開発の終盤になると、ハードウェアがプロトタイプ(試作)として大体完成したことで、普通のパソコンにそのハードウェアを接続し専用のアップローダ(転送ソフト)を使ってソフトウェアを転送することが出来るようになった。

■メーカーの内部

私は普段はIT業界の特にSIと呼ばれる企業向けのカスタムメイドなシステム作りを中心に行う仕事をしていたので、これまでメーカー(製造業)とはあまり縁が無かった。一応メーカーの仕事もしてはいたが、メーカーの内部で仕事をしたことはなかったので、色々と興味深いことがあった。

まず仕事場だった研究所が工場に隣接しており、食堂も共有していたため、昼食のたびに社員食堂で食事をとった。天井が高くて広い部屋に、作業着を着た大勢の老若男女が集う。特に年配の人が多くて新鮮だった。IT業界は若い人しかいないからだ。いかにも工場労働者という風情の人々にまじって食事を取っていると、なんだか別の世界の住人になった気分だった。

私たちがあてがわれた部屋は、なにやら大きな部屋をしきりで仕切った一角だった。研究所の建物ということだったのだが、設備を入れ替えたらそのまま工場になりそうなところである。ボイラーのようなものが近くで動いているらしく、常に低い音が響いていた。おまけにどこからか熱を発しているらしく、当時は冬だったにも関わらず妙に暖かかったのを覚えている。

変人のH先輩は、家が遠いという理由もあり、途中から寝袋を持ってメーカーに寝泊りした。H先輩も変わっているが、それを許すメーカーもメーカーだなと思った。朝食は社員食堂で食べていたそうで、食堂のおばちゃんとも仲良くなっていたらしい。私たちが出勤してきたらまだ机の下の寝袋にくるまって寝ていたこともたびたびだった。

敷地内にある建物は、幾度と行われたであろう建て増しにより、いくつもの渡り廊下が蛇行しており、所々に建物同士の隙間を利用した脇道でショートカットもできた。古い白塗りの建物は年季が入っており、薄暗い廊下を年代モノの照明が照らしていた。一階部分が特に天井が高く、おそらく生産設備を入れるためにそのように設計されたのだろう。

あるときメーカーの社内販売が開かれた。部外者でも買って問題ないということだったので、私も会場に行って一つ買ってきた。メーカーの直販だと修理のときに困るらしいのだが、壊れたときは連絡してくれればなんとかしてくれるということだった。そのときまで親交が続いていればいいのだが、いま現在もう連絡が途絶えているので面倒なことになりそうである。名刺はまだあるのだけど。

社内販売の会場で、年配の温厚そうな人に絡まれた。その人は私にいきなり自分の仕事の話を始めた。自分は以前ここでこれこれこういう仕事をしてきたと語っていた。過去形だったのでもう退職しているのだろう。その人はとてもニコニコしていて、私は愛想笑いを浮かべながらその話を聞いた。この人は多分仕事人間で、引退してからも働いていたときのことが忘れられないのだろう。ちょっとかわいそうな気もしたが、それ以上に、仕事に会社にここまで思い入れを持つことが出来るのは幸せなことなんじゃないかと思ったりもした。

■フラッシュの制限

私はハードウェアの技術者ではないので詳しいことは分からないが、開発対象となるハードウェアはかなり精緻なものだった。板チョコよりさらに小さい本体に、白黒ながら十分な大きさを持つ液晶ディスプレイ、薄いにも関わらず感圧式のタッチパネルを備え、それをボタン電池で駆動させていたにも関わらず、通常の常識的な使用で一ヶ月は電池がもった。今回はソフトウェアの話しかしないが、ハードウェアの設計には並々ならぬ技術と努力が注ぎ込まれており、きっとそこにも大きなドラマがあったに違いない。

それでもやはりどうしても解決できない問題が発生した。記憶装置としてフラッシュROMという半導体を使っていたのだが、読み書きはともかく消去のための電圧が足りないというのだ。

ここでちょっと解説がいるだろう。フラッシュROMというのは東芝が発明し世界を変えた日本発の誇るべき技術で、これまで半導体に何かデータを記録しておくには常に電気を流し続けていなければならなかったのだが、この技術のおかげで電流を流さなくてもデータを保持できるようになった。ただし欠点があって、読み書き特に書き込みが遅いのが一つと、さらに大きな欠点として通常の書き込みはデータの状態を一方向に変えることしかできないので、逆方向に変えるには消去という操作が必要になる。

紙にたとえてみると分かりやすい。白い紙の上に鉛筆で文字を書き込んでいくと、そのうち書く場所がなくなってくる。そこで、必要のなくなった文字を消してやる必要がある。消しゴムをかけるという作業には、鉛筆で書くという作業よりも力が要る上に、消したい部分だけうまいこと消すことが出来ないので周辺部分も消えてしまったりする。フラッシュROMも同様で、データを消すときにはまとまったブロックをまるごと消さなくてはならず、しかもそのためには読み書きよりも大きい電圧を必要とする。

当然ハードウェアの設計段階でこれらのことは分かっていたはずであり、データ消去のための電圧も設計上確保できているはずだった。しかしここに大きな落とし穴があった。小学生の頃、乾電池を使った実験をしたことは誰にでもあるだろう。乾電池は普通のものだと一個で1.5Vの電圧が取り出せることになっている。しかし実際には、1.5Vの電圧が出るのは使い始めて少しのときだけで、使っているうちに徐々に電圧が降下してくる。正直そのくらいのことはハードウェアの技術者なら分かっていて当然だと思うのだが、おそらく駆動時間との兼ね合いがあったのだろう。電圧は電池が切れるまで緩やかに下がり続けるので、最低限使える電圧を低く取ることで電池が長持ちするようになる。逆に言えば、フラッシュROMに対して消去を行うための電圧を確保しようと思うと、バッテリーの持ち時間を短くしなければならないのだ。

■データベース実装

そこでどうしたか。スーパーハッカーTさんは、この小さなハードウェアに簡単なデータベースを実装しようと提案した。データベースで包んでしまえば、アプリケーションからメモリの心配をしなくて済む。フラッシュROMの制限はデータベース内で吸収してしまえばいいのだ。データを書き換えたいときは、もし通常の書き込み操作だけで済む場合は書き込みだけを行い、消去が必要なときはそのブロックを丸々放棄し、新しいブロックにデータを書き込む。放棄したデータはゴミとなって容量を圧迫するが、携帯情報端末のほうでデータを大幅に書き換えることはあまりないので大したことはないし、定期的にパソコンにつないでフラッシュROMを消去してやることで掃除ができる。ブロックに点在するデータをアクセスするとき、ブロックの管理はデータベース内で処理してくれるので、アプリケーションから考える必要がない。

口では簡単に言えるが、データベースの実装となるとそう簡単にはいかない。なにせハードウェアがZ80互換の8ビットCPUだ。優れたフリーウェアはいくつかあるが、とてもこのCPUには実装できない。従ってフルスクラッチ(部品を使わず材料だけで作ること)で新たに書き起こす必要があった。スーパーハッカーTさんはまたしてもやってのけた。スケジュールにほとんど影響のない程度の時間でデータベースソフトを書き上げてしまったのだ。

出来上がったデータベースの仕組みはとても完成度が高かった。現在よく使われるデータベースソフトはSQLと呼ばれる言語で操作するが、そんな言語なんてものは当然実装できないので、テーブルや列やインデックスをIDで直接指定する最低限のAPIを使って操作する。テーブルとテーブルを結合(ジョイン)するなんてことは当然できない。ただしインデックスはあるので、APIを何回かに分けて組み合わせて使えばちゃんと結合できる。まあ携帯情報端末で使われるカレンダーやメモ帳などでそこまで複雑な操作は必要ないのでこれで十分である。

おまけにTさんはこのデータベースのために専用のODBCドライバまで書いてしまった。これでMicrosoft Accessなどからこのデータベースを操作できてしまう。さすがにフルセットの機能は持たないのだろうが、使えてしまうだけで十分驚きだった。このへんの用語はいちいち解説しないのであしからず。

データベースが実装されたことで、アプリケーションを作る私たちにも影響が出てきた。小さいマシンなのでメモリを使うのにも慎重にならなければならない上に、アプリケーションで使用するデータをデータベースから読み書きしなければならないのだ。画面に表示するために最低限必要なデータだけを逐一データベースに読みにいく。もしこれがパソコンだったら一気に読んでいたんだろうなと思うと非常に窮屈だったが、とても勉強になった。何より驚いたのが、こんな面倒なことをやっているにも関わらず動作が意外にスムーズなことだった。コンピュータを遅くするのは複雑な計算よりも劣悪なアルゴリズムに因るところが大きいのだということがこれほど体感できた経験はこれまでなかった。

■エディタ

私が担当したToDoというアプリケーションはまだ楽な方だったが、リーダーEさんが担当したメモ帳はデータベース化により大幅に複雑になった。このメモ帳はWindowsのメモ帳のような最低限の機能しか持たないものの、いわゆるフルスクリーンエディタだった。フラッシュを積んだZ80マシンでフルスクリーンエディタだなんて使い物になるんだろうかと思った。なにせCPUとメモリが遅すぎる。フラッシュを効率よくアクセスするための下位のライブラリを買っていたので、データベース化を考えていなかったときでも恐らくフラッシュを普通のメモリのようにアクセスしてアプリケーションを作ることを考えていたのだと思う。メモ帳だったら動作が鈍くても最低限の機能さえあればいいんじゃないかという程度ならこれで十分だ。しかしデータベース化によりこの方法は使えなくなってしまった。

リーダーEさんは雑事に追われていてなかなかメモ帳の設計・製造に入れなかった。そうこうするうちに一番簡単な部分を受け持っていた私がToDoの編集画面に入り、複数行のテキストを編集可能な部品が欲しいと打ち合わせの場で言った。実はこのときメンバーの負荷を考えると私が作るべきだったと今でも思う。ところが話は冒頭に戻るが、私は当時いい加減職場環境にうんざりしていた。丸椅子に長机に型落ちのパソコンにノイズの入った液晶モニタ。メンバー全員がある程度の残業をしていたにも関わらず、私だけ大体定時ぐらいにいつも帰宅していた。こんな劣悪な環境で長時間働きたくなかったのだ。だから私は、部品が欲しいとは言ったが、自分で部品を作るとは言わなかった。じゃあ誰が作るんだ、ということを話し合った結果、メモ帳担当のリーダーEさんが「俺!?」と言い出したので、これ幸いと押し付けることにした。

実は私は本心ではエディタを作りたかった。学生の頃、作ったことがあるのだ。しかもフルアセンブラで。当時流行っていたVz Editorに影響を受けて、プログラミングの腕試しのつもりで作ってみたらできた。最低限の機能しかないが、ちゃんとファイルを編集できた。しかもプログラムサイズはたった4キロバイトだった。何故か古本屋で安く売っていた98用のBorland Turbo Assemblerを、自分でクラッキングしてFM TOWNSで使えるようにし(一個割り込みを潰しただけだけど)、友人の影響を受けてアセンブラでプログラムを書いて万能感に浸っていた。ところがこのとき私が作ったエディタはアルゴリズムが幼稚すぎて、大きいファイルを編集しようとすると使い物にならなかった。いかに一番速い言語を使っても、アルゴリズムがグダグダだったらどうしようもないのだと思い知った。その後、LSI-CというフリーのC言語を手に入れてCを覚えた私は、Cでまたエディタに挑戦しようとしたが、やる気が失せてコードを途中で放棄した。

だから私はこの機会を利用すべきだったのかもしれなかった。しかも今回は仕事だ。しかし私は、エディタを書いて自分の優秀さを証明しようという動機が薄かった。なにせ既に一度書いているからだ。昔は自分がいかに優れているかを周りにアピールしたくてしょうがなかったので、役に立たないソフトを腕自慢に書きなぐっていた頃があった。しかしそんな欲求は根拠不明の自信過剰により無くなった。もう自分は多分望むものはなんでも書けるだろうと思い上がっていた。だから、エディタを作る役目をリーダーEさんに「押し付けた」と思っている。そこにあったのは表面的には余裕だった。

リーダーEさんはスーパーハッカーTさんの助けを借りながらもかなり残業しつつ基本的にほぼ一人でこのエディタを作り上げた。出来上がったコードを見て私はその完成度の高さに驚いた。Tさんならともかく、これまで割と平凡な人だと思っていたリーダーが、ここまでのコードを書けるとは思わなかったのだ。Eさんはこの精鋭チームをまとめるリーダーとして部長が選んだだけの実力のある人だったのだ。

リーダーEさんは自分の私物のマシンを現場に持ち込んでいた。複数の人間で開発を行う場合、リポジトリと呼ばれる共同開発管理用の入れ物を用意し、各自がプログラムに手を加える場所が重ならないようにすることが多いのだが、このリポジトリを作るためのマシンがなかったのでわざわざ自腹で用意したのである。いまではとても考えられない。というか今思えば当時でも考えられない。もしこのマシンがクラッシュしたら一体誰が責任を取るのだろう。そりゃバックアップぐらい取っていた…かどうか自信がないけど、何か事故があったら少なくともスケジュールに影響してしまう。それに何より仕事で使う機器を社員に持ち出しさせていいのかという問題でもある。私が当時の環境に腹を立てていたのとは逆に、リーダーEさんはそこまでしてでもこのときの仕事に全力を掛けていたのだろう。

■業界裏話

私は当時は喫煙していたので、非常階段の隣にある喫煙所でよくメーカーの技術者の人たちと世間話をした。ふとしたことがきっかけで業界裏話まで聞くことが出来た。このあたりの話は特にヤバいので半分創作だと思って雰囲気だけ感じて欲しい。

このメーカーは既に述べたように精密機器に強いとされているので、海外のパソコンメーカーが目を付けて超小型マシンを作ってみてくれと依頼が来たことがあったらしい。そこでここの技術者さんたちは結構がんばって色々やってみたのだけど、パソコン本体をリュックサックのように背負わないといけないほど重かったり、マウスやキーボードなんかの入力デバイスもめちゃくちゃだったので、発注したパソコンメーカーの人が口にこそしなかったがあからさまにガッカリしていたらしい。ちなみにそのあとちゃんとこのメーカーは小型のノートパソコンのOEM(相手先ブランドによる製品の供給)をして一定の評価を得ている。

携帯情報端末の表示部分が液晶だったので液晶の話になった。液晶は過渡的な技術だからじきに本命の有機ELが来るだろうとメーカーの技術者は言っていた。しかし今の世の中を見ると液晶がプラズマまで押しのける勢いで発展している。

このメーカーは半導体も生産していたが、半導体の生産技術は特許に守られているのでライセンスが必要らしい。実は影でこっそり生産してたとかしてなかったとか。半導体の生産ではなく半導体を生産する機械の話だったかもしれないがよく覚えていない。その流れで、メモリの価格が決まるメカニズムについても講釈を受けたので、以前メモリの話で書いたことがある。

ある超有名な海外の半導体メーカーがこのメーカーにLSIの配線部分の発注をしていたことがあったらしい。日本の技術力の高さがこういうところからも分かる。

■残りの機能

話は前後してしまうが、Eさんが自分の担当であるメモ帳になかなか取り掛かれなかったのは、確かAPIまで手伝わなければならなかったからだった。

メーカー側のソフトウェアエンジニアでアーキテクト(設計主任みたいなもの)みたいな横分けXさんがOSやAPIを全部一人でやる予定だったのが、予定が遅れてきたので増員された年配ボサボサ頭のYさんが日本語変換機能などを分担することになり、それでもまだ人が足りないので若手いがぐり頭のZさんがハードと兼任で描画ライブラリを作ることになった。ところがそれでもまだ厳しいので、Z80のアセンブラが出来る人が優先でそっちを手伝うことになった。私はあいにく世代じゃないので出来なかった。86系やMIPS系なら経験があるのだけど、まさかいまさらZ80なんか使うことになるとは思わなかった。聞いた話だとアセンブラでVRAMにアクセスして直線とかアイコンとかを描画するルーチンを作ったりしたらしい。ちなみに横分けXさんはこのときの不手際もあったのか、この開発が終わったあとにメーカーを退職している。

私は私でとばっちりが来て、ソフトウェアキーボードや日本語変換機能のインタフェース部分を作る仕事が押し当てられた。日本語変換機能自体はあっちの増員メンバーの年配ボサボサ頭Yさんが作っていたので、私の方はそれを呼び出して結果を受け取り選択機能を持たせるだけだ。ここで一つ懺悔するが、私の作ったインタフェースが日本語変換機能を最初に二回も呼んでしまうために、初回ロットでは日本語変換に倍の時間が掛かっていた。次のロットからなおったらしい。日本語変換機能を同じ引数で呼んだらキャッシングしてくれればいいのに、と無理なことを思ったりもした。

ほかに、途中まで変人先輩Hさんがやっていた辞書も私に引き継がれることになった。辞書とは文字通り辞書で、有名な出版社に辞書のデータを発注し、それをROMに焼いて使うことになっていた。どのようなデータ構造で焼くのかまで変人先輩Hさんが決めたが、最後になって私に引き継がれたため、もしヘンなままROMに焼いちゃったらお金も時間も百万単位で掛かるよと脅された。最終確認のあとちょっとしたミスがあることが分かったが、プログラム側で最終的になんとかしたような覚えがある。

開発途中でよく出来たプロトタイプ(試作)の本体が作られた。三色ぐらいカラーがあって、どれもデザインが良かった。ところが実際に製品版になったときは結局一色だけで行くことになったらしい。多分色が沢山あっても在庫とか余計な面倒が掛かるから一色になったのだと思う。そう考えると、ユニクロとかiPodがあそこまで沢山の色を出せるというのはすごいことなのだなと思う。ちなみに内部の技術者は、そのプロトタイプのカラフルな外側部分だけ製品版と付け替えて、特別限定版みたいなものを作っていた。もしどこかで見かけない色の携帯情報端末があったらひょっとしたらそれを持っている人はメーカー内部の技術者かもしれない。ちなみによそのメーカーとのタイアップで限定色版もあったらしい。

■アドオン

なんだかんだで開発は順調に終わった。

その後、アドオンのソフトを作る話が持ち上がってきた。アプリケーションは基本的に内部のROMに焼くのだが、それだけだと既に作られたソフトウェアしか動かないので、フラッシュROMに書き込んだソフトも動かせるような仕組みも用意していたのだ。ただし容量の制限があってあまり大きなソフトは動かせない。

アドオンをどうしようかまだ未定だったときに、とりあえず我々開発者が個人で適当に作ってみろということになり、冗談で一本三万円出すとメーカーの部長さんが言い出した。この部長さんは外の展示会でのちょっとした思い付きでIBMと共同で製品を作った逸話があるというフットワークの軽い人だった。

私はまあ三万円には期待していなかったのだが、一仕事終わったあと時間があいたので、ふと思いつきでマインスイーパを作ってみることにした。Windowsについてくるあの爆弾探しゲームである。さらっと二日で出来たので、ごく個人的にメーカーの技術者のうち親しい人に送りつけた。そのうち、百万で何本か作ってくれという仕事の話になった。三万円は結局もらえなかったが、勤務時間内に作ったものなので仕方あるまい。結果的に私が自社の営業を手伝ったことになって良かった。百万だと一人月つまり20日分にしかならないのだが、私がもう一つ英和辞書ROMを使ったハングマンという単語当てゲームを作り、ゲームばっかじゃダメだということで他の人が時刻表やら単語帳やらを作った。

ちなみにハングマンとは、単語をハズすたびに画面の中の人が首を吊るという伝統的なコンピュータゲームだ。私は最初その画面の中の人の絵として、小学生の頃よく描いていた少年の絵を描いて使っていた。するとそれがいつのまにかメーカーの営業会議の話題にまでなり、少年が首を釣るのはよろしくなかろうということで、結局ほかの絵柄になった。なんでも懇意にしていた技術者の人がちょっと粘って私の少年の絵柄を守ろうとしてくれたそうなのだが、最後は妥協せざるをえなかったとのことだった。正直私は割とどうでも良かったのだが、それを聞いて嬉しく思った。

時刻表がなんといっても一番実用的だった。時計と連動して次の電車があと何分何秒で発車するのかリアルタイムで表示するもので、時刻表のファイル形式はフリーウェアのものをそのまま流用していた。リーダーのEさんが設計し、途中から私が製造した。

アドオンはユーザレベルでも作ることが出来るようにしたのだが、コンパイラだけはよそから買ってこなければならなかったため、敷居が高かった。メーカーは自腹を切ってコンパイラ込みの開発環境を希望者に限定販売したが、話によると一本数万円程度の赤字だったらしい。Z80のコンパイラなんてフリーウェアでありそうなものだと思っていたが、よく分からないが少なくとも我々の使っていた環境に適合させる都合とかがあったのだろう。なんとかならないのか私も強く言ってはみたものの、スーパーハッカーTさんにもどうにもならなかったみたいだった。

■英語版

さらに話は続く。なんとこの携帯情報端末の英語版を作ることになった。

なんでもアメリカでこの端末に目をつけた会社があって、自社ブランドでカスタマイズして販売したいと言ってきたらしい。そこでうちにもまた声が掛かり、ソフトウェアも多少改修を加えることになった。ハードウェアのほうも若干の仕様変更があったが、辞書ROMを削った分フラッシュを増量するとかその程度だったと思う。海外の会社というのは自社ブランドにこだわるところが多いのだ。以前なにかで聞いた話だと、サッカーで使う笛を製造している日本の会社があって、そんなものも海外の会社は自社ブランドにして売っているらしい。

向こうの会社は英語で書いた仕様書を送ってよこしてきたので、それを読みながら開発をすることになった。大した英語ではなかったが、自分が海外の仕事にこんなことで関わるようになるとは思わなかった。向こうが提示してきたインタフェースはとてもかっこよかった。オリジナル版はメーカーの社内の技術者がデザインしていて、当然デザインの専門家ではないので、シンプルで合理的でこれはこれで良かったのだがどうしても垢抜けないところがあった。英語版のはマック風のフォントを使ったクールなデザインだった。

いまになってWikipediaのこの製品の項を見てみると、英語版はアドオンを作る敷居がそれなりに低くて、オリジナル版よりも多くのアドオンが作られたらしい。詳しいことはよくわからない。

そういえば変人のH先輩と同期の英語ペラペラなMさんが途中でアメリカに出張した。確かパソコンとの連携用ソフトの関係で行ったのだと思うのだがよく覚えていない。H先輩はおみやげに日本のポケモンカードを向こうの人に持っていったら喜ばれたらしい。H先輩は現地であやしいお菓子やジュースを買い集めておみやげに持ってきてくれた。

Mさんの英語はシンガポール仕込みでぱっと聞いた感じうまくないのだが、ちゃんと通じているみたいだった。通じる英語というのは私たち生粋の日本人では理解できないポイントのようなものがあって、そこを押さえればあとは適当でも通じるもんなんだと話し合った。その後別件で彼が海外の格安パソコンショップにマシンを発注し、そのマシンがなかなか来ないので彼がクレームの電話を英語で掛けていたのだが、分かりやすい英語だったので横で聞いていた私にも分かって思わず笑ってしまった。

でもって驚いたのが、この英語版が発売されてからしばらくして、販売元の会社が半導体大手企業に買収されてしまったことだ。Z80を使った携帯情報端末でこれだけの機能が動いてしまうと都合が悪いから買収したんじゃないかと勘ぐったりもしたが、さすがにそれは考えすぎでちゃんと他の理由があったらしい。

■デモ版

まだまだ話は続く。今度はもっと性能のいいハードウェアを作ってみようという話が出た。またまたソフトウェアで我々に声が掛かった。

今度は製品化のメドが立たない状態で、とりあえず社内展示会のためのデモ版ということで、一部のソフトウェアだけこれまでのコードを元にちょっと移植する程度となった。この時点で既にスーパーハッカーTさんは退職しており、仕方なく私と同期のMさんともう一人うちらより年上の女性を入れた三人だけでやることになった。このプロジェクトのリーダーはMさんがやった。正直なところ、私よりMさんのほうを部長が評価していたのだと知ってガッカリした。あとで部長に理由を聞いてみたところ、Mさんのほうが仕事をやりとげてくれると思ったからだと言っていた。まあ確かに一人だけ定時で帰るような人間よりMさんのほうが信頼できそうなのは自分でも否定できなかった。

今度の開発は面白いことにライブラリレベルでの互換性を持った開発環境をメーカーの人が作っていた。以前はクロスプラットフォーム開発でパソコン上に互換ハードウェアをエミュレーションしていたが、今度はVisual C++で互換ライブラリを作り、パソコンでビルドするとWindowsのアプリケーションになるような形になった。ここでいったん動作を確認した上で、メーカーのほうで新しいCPUとハードウェア向けにビルドしなおしてハードウェアに埋め込むという段階を踏むようになった。CPUがARM系になり結構スピードが上がったとの話を聞いていたが、ついに私は実機を拝むことがなかった。

開発はほんの一ヶ月半ぐらいで終わり、社内展示会に出品されたが、結局製品化はされなかった。幻の機種と言えよう。社内展示会はうちの会社の近くで行われ、勤務時間中だったが何人かが見学に行ったが、私は結局行かなかった。メディアの取材も入っており、このデモ版もメディアに露出した。製品化されないものは意外に多いらしく、実際のところ確か二割ぐらいしか世に出ないとのことだった。聞いたところによると私たちの開発していた隣で携帯ミュージックプレイヤーも開発されていたらしいが、今に至るまでそのメーカーから出たという話は聞いていない。あるいはどこかよその会社のブランドでOEMとして出た可能性もあるが分からない。

*

以上で今回の話は終わりである。

日本はソフトウェアで大きく遅れを取っていると言われている。輸出と輸入を比べてみればすぐ分かる。技術者一人一人の実力にはそんなに大した違いはないどころか、日本には突出した人材は少ないかもしれないが平均的には結構高いと思う。なぜ日本が立ち遅れているかというと、突出した人材の不足のほかに、経営層の問題があると思う。技術を生かせる事業をやっていないのだ。これではいつまでも海外に依存することになるだろう。情けないことである。

いま私は何の仕事をしているのかというと、ここ二週間ほど延々テスト結果を印刷したりチェックリストの紙に手でチェックを入れたりするのをずっとやっている。これも仕事だから仕方がない。重要なシステムの改修なのだが、このシステムの開発では過去に大失敗を繰り返したらしいので、テスト計画がとても念入りでキチガイじみたものになっている。いまは空前の投資信託ブームで、私はいま投信を扱っている会社の仕事をしており、今のところこういう感じに書くほどに面白い仕事はないが、金融関係もなかなか面白いなと思っている。何か面白いことがあったらまた今回のようにほとぼりが冷めた頃に抑え目に書く予定である。

そういえば前回IT戦記3で書いた志村部長が大赤字の責任をとってついに退社した。といっても、もう一つ大赤字プロジェクトを抱えていたのでそちらのせいかもしれない。


戻る前回次回
gomi@din.or.jp