組み込みソフトではないが、暇を見つけてはアマチュア無線機の組み込みユニットの作成を手がけている。最近では、見かけなくなった大規模なキットであり、中身は半端ではない内容となっていて、もう中年真っ最中の私としては視力補正機構を付けなければ仕事にならないのも事実である。まあ携帯電話の開発現場とは異なり米粒ほどの表面実装部品0603などの部品を採用している部分までは、ないのがせめてもの救いでもある。そんなキットがあったとすれば、まともに組み上げられる人は数少ないし、ビジネスとして成立するとは思えない・・・。まあ、古きよき時代を懐かしむ世代が暇を潰していくのには最適なおもちゃである。半田ごてを握り、組み立てていくといった風景は、最近ではロボコン参加を目指す子供たちぐらいなのだろうか。

組み上げている無線機には、既に数多くのマイコンが搭載されているようだ。マイコンが搭載されているからといってもPICマイコンなのでI/Oラインと簡単な発振子と電源位しか接続されないのでシンプルな限りである。構造から言えば、各構成ユニット毎のコントローラとしての機能をうまく通信しつつ動作するようになっているものだと感心したりもしている。かつて四半世紀前に遭遇した自動車電話の商用機種にマイコンが複数搭載されていた史実(?)などを思い出したりしてアマチュアが自由に使いこなせる時代に到達したのだなと感慨もひとしおである。ビット同期をソフトウェアで行ったりトーン検出を行ったりといったのが当時のサブシステムの4ビットマイコンの役割でもあった。信号処理と系統制御を行っていたのは16ビットマイコンでもあった。

アナログ無線機で構成されていた時代では、分散マイコン同士が通信して協調動作するといったものではなかった。機能ブロックのハードからの置換といった目的で自由に組み替えられるいってみればCPLDのような位置づけでの使い方だった。周期を計測してトーン周波数を検定したり、低速信号の同期捕捉処理を行ったりといった使い方である。当時の8ビットパソコンなどでもデュアルマイコンなるものも登場してきたのは、グラフィックスなどの機能拡大とメモリ領域の確保といった背景があった。無論各社の対応は巧みに隠し機能を使いアドレス拡張を施したシングルチップ構成もあったし、グラフィックスプロセッサを開発したりといった会社もあった。素直に二個のマイコンを搭載した国内メーカーではメインCPUとのコマンド通信処理で実現していたのだが、通信オーバーヘッドが仇になりゲームなどが作りにくいといった風評もあったのだが、ハッキングして流出した情報は「ＹＡＭＡＵＣＨＩの謎」というものだった。

リバースエンジニアリングなど当たり前の時代でもあり、解析をした結果分散マイコン側にソフトウェアをダウンロードするためのパスワードが”YAMAUCHI”という文字列だったのである。開発担当者の名前だったのかも知れない、キーボードなどのイベントのみを通信経由で実装することでいわゆるインベーダやらギャラキシアンといったゲームの実現が果たせたというのである。シングルであれば簡単なテーマが分散処理することによりアーキテクチャにあわせた実装検討を強いられることになるのは繰り返す事由なのだろうか。低速な8ビットマイコンからアドレスも速度も解決することになった16ビットマイコンへの移行などで、こうした分散処理が集約されたりといったことの繰り返しをしてきたように思い返す。機能部品としてのマイコンのソフト開発はハード屋の仕事だったりするのも常だったりして組み込みソフトの中でも光の当たらない世界だったりもしていた。

アセンブラからCに移行して開発速度の加速と共にメモリ容量も拡大の一途となり、FlashやRAMの容量なども機種ごとに次々と大きくなっていった。PDAに無線機を接続したような機種が登場したりしてモデムとして高い携帯電話を活用しようという動きや、実用的な速度を低コストで実現することもあわせて実現したPHSなどの登場なども携帯ソフトの複雑化を加速したのである。そして４年ほど前のiMODE事件などを契機に本格的に油を注いだ形になったといえる。携帯だけでWebブラウジングが出来たりMailが出来たりといったことをHTMLベースで実現したりJavaを登場させるなど様々な技術が投入されて開発に繋がった。機能競争としてPDCとCDMAとが違った切り口で登場したことなども加速した要因の一つだったのだろう。低速度に特化した言語を開発したベンチャーなども今では標準化の流れの中に埋没しようとしているようだ。

この長い長い舞台の中で大道具は次々と変遷を遂げていったので、使用してきた台本があわなくなってしまった。時代に合わない平屋作りの実写のサザエさんから二階建てのアニメに変えなければならなくなってきた。登場するキャラクタは変わらないのだが・・・。電話帳を開いて電話をかけて、メールをして書き込みや写真を控えたりといったことがオブジェクト連携で実装されるというのが現代のソフトウェアである。500人を超す電話帳に可変長のデータが格納された現在では、まともなデータベースなしではタブで飛んだ瞬間に画面展開できないような実装では受け入れられないのである。そうした基本機能の追及をしている中でインプットメソッドなどへの逆連携も要求されている。メールアドレスフィールドに入れる全角データを半角に変換したり、電話番号の長さや名前の長さといった制限を越えた入力に対して警鐘を鳴らすといった機能も要求される。ダブルバイトでの日本語処理と画面描画などにも細かく要求されることは多いのである。

実はマルチメディアなアプリケーション開発をしていくことよりも、必要なオブジェクトのクラスライブラリを開発してきたことの成果のほうがコスト高くかかって来たのが実情のようだ。「携帯電話用に開発された欧州生まれのOSをベースに1000人月を越すアプリケーション開発費用を投入して出来た成果を次に生かせるのか？」という問いかけは、私達に掛けられた物なのか自問自答なのかもちょっと曖昧のようだ。彼ら自身、成果なのか足かせなのかという自問自答を、開発のベースにしたプラットホームOSを考え直すのかどうなのかということにも繋がっているようだ。Windowsと同様なコンセプトで開発してきたバイナリなAPIが彼らの期待する機能性能を果たすクラスライブラリなのであれば、彼らのアプリケーション開発に投入されてきたリソース自体が無為なことになりかねないという危惧を最初に露にしていた。

モデムチップ以外にアプリケーションプロセッサを搭載して実現してきた人たちが、アプリケーション開発費用として投入してきた開発費用という成果を資産とみているのか、負債とみているのかは微妙なところでもある。いずれにしてもドラスティックなスマートな判断が下せるような日本企業は存在しないのも事実で、破綻した決裁機構の判断なきままに現在の方策を負債と認識した上で現場は動いていくのだろう。ポータブルゲームセットを凌ぐグラフィックス性能をシングルチップで叩き出してきた技術の積み重ね自体に誤りはなく、視点を変えたAPIの拡充が尤も重要なテーマとなっていることを認識していくことが我々の課題でもあるようだ。YAMAUCHIの謎ではないにしてもアプリケーションプロセッサとの処理分担をどのようにするのかについては、意外な答えが待っているのかもしれない。逆に言えば、アプリケーションプロセッサを使ってきたお客様が考えている付加価値は自身のクラスライブラリの移植するために必要な期間との算段なのである。

YAMAUCHIの謎を知っているのかどうか、このお客様に問いかけることはしない。お客様自身が考えるというあるべき姿についての叩き台についてのコンサルティングに向けて私自身もアーキテクトの端くれとしてオプションを揃えたいと考えている。技術的な最良解が見つかったからといって決裁機構の破綻したお客様が選択できるとは限らないからでもある。いずれにしても日本の通信機メーカーをここまで貶めるにいたったのは通信キャリアのビジネスモデルの誤りなのか、ソフトウェア開発管理の失敗なのかはまだわからない。こうした実情を知らずに国のトップがOSのことを論じていたりする姿をみるとサポートしている見識者の方々にも見せないこうした組み込みソフトの背景は、本当に闇の中にエンベデッドされているようだ。デジタル家電を持っているメーカーは少しは潤ったボーナスが出るという景気上向きの状況のようだが、埋め込みソフト技術者がビジネスモデル自身に埋め込まれてしまっている状況からの離脱を考えなければ自身のビジネスの将来を考えられないのだろうと思う。