Osamu Ichikawa  Osamu Ichikawa photo       

contact information

Research Staff Member
Tokyo Research Laboratory, Japan
  +81dash3dash3808dash5236

links



OS/2日本語版

PCのOSといえば DOS が全盛だった頃、次世代を担う OS として期待されていたのは Windows ではなく、OS/2 でした。
ハードウェアの方では、IBM PC からマイクロチャネルを備えた PS/2 へ進化させるという動きがあり、それと歩調を 合わせたソフトウェア側の進化という意味で、戦略的な匂いのプンプンする製品でした。
このプロジェクトに配属されることが私の入社時の希望でしたので、まさにその通りになって私としては大変にわくわくしていました。
海外出張の機会にも恵まれ、配属されて半年ほどしか経っていない時期に、フロリダ州のボカラトンにある開発研究所で1ヶ月ほど働きました。ボカラトンでは、大規模なソフトウェア開発の現場を間近に見ることができました。この時体験した品質管理や仕様管理のシステマティックな手法は、私のその後の仕事においても良い手本になりました。
思えば、当時の開発部門には、PCソフトウェアのミッションだけでも、DOS、OS/2、ワープロ、かな漢字FEP、ホスト端末エミュレータなど多彩なものがあり活気がありました。

IBM日本語音声認識合成アダプター

OS/2 の開発で得た知識と英語力をもとに、新たに取り組んだのがこのミッションでした。私はここで東京基礎研究所の研究員と初めて知り合い、知的な啓蒙を大きく受けました。開発職から研究職に変わろうと決心したのはこれがきっかけです。
このアダプターは、名前とは裏腹に、中身はただのプログラマブルなDSPで、それにライン入出力と電話線のインターフェイスが接続されているだけのものでした。DSPマネージャは、このDSPの上にISPOS というリアルタイムOSを走らせ、音声認識や音声合成などのDSPコードをロード・アンロードし、リソース配分を行いました。プログラマブルであるだけに、1000単語の離散単語音声認識だけでなく、電話を自動発着信して合成音で応答するなどということもできる実に多彩なカードでした。また、アダプターはマイクロチャネルで、一台のPCに4枚まで装着可能であり、それぞれがバスマスター機能を持つことができました。ハードウェアインタラプトは共有となり、私の担当したデバイスドライバーとDSPマネージャの部分は、かなりややこしい処理が必要だったのを覚えています。
結果的に、大量に売れるカードではありませんでしたが、当時のハードウェアとソフトウェアの開発部門および研究部門の英知が結集された State-of-Art な作品ではありました。

読み上げくん(後の Pro-Talker)

当時、先のアダプターの売れ行き不振の理由を自分なりに分析しました。

  • アダプターが高価(パソコン程度の値段)
  • API (Application Program Interface) の提供に主眼が置かれていて、すぐに使えるアプリケーションが同梱されていなかった。

この反省をもとに、Sound Blaster などの当時の一般的なオーディオ アダプターで動作する音声合成ソフトウェアのプロトタイプを作りました。アプリケーションとしては、クリップボードリーダを考案し、クリップボードに入ってくるテキストは何でも読むという仕様にしました。このプロジェクトは、私が東京基礎研究所の研究員と共に自主的にプロトタイプを作り、その結果、製品化のプランが立ち上がり、世の中に出て行ったという異例の経緯のものでした。
開発部門の体制は「まず開発予算ありき」というのが普通です。一介のエンジニアの発案がそのまま製品となってでていくということは当時大変珍しいことでした。ボトムアップの文化のはしりとしては良かったのではないかと思います。

衛星データ放送受信システム

郵政省・通信放送機構のプロジェクト「衛星データ放送システム技術研究開発」に参加しました。
当時はまだナローバンドの時代でしたので、ギガ・バイト単位の大きなコンテンツを配信するのには、衛星による一斉配信が期待されていました。現在、放送・通信衛星の主流はアナログ方式からデジタル方式に移行しつつありますが、当時のアナログ方式であっても音声部分はデジタルデータで伝送されていましたので、この部分を使ってパソコンに巨大なファイルを転送するというプロジェクトでした。私は、受信API部分のグループリーダとして、基本設計と開発を担当しました。
放送局にのりこんでいってファイルを送信すると、3万6千キロ上空の衛星を経由して自分のパソコンに「ボコッと」ファイルができる様はなかなか感動的で、「こんな(どーでもいい)テストファイルの送信のために、衛星なんか使っちゃっていいの?」と一同 顔を赤らめておりました。

MMS

MMS(=Multi-Media Station)は、タッチパネルを備えたキオスク端末です。普段は自由にタッチできる情報端末として、新譜の視聴やキャンペーンの紹介などを提供していますが、夜中になると、前述の衛星データ放送受信システムを起動し、新しいコンテンツを受信します。また、コンテンツだけでなく自分自身のソフトウェアの書き換えも衛星経由で行います。さらに、ゲームセンターで人気のプリクラと接続し、衛星で受信した背景画データをプリクラに転送しました。私は全体の基本設計を行うとともに、LCS(=Location Control System) という全体の動作を管理しコンポーネント間の連携をとる部分を作成しました。当時は、実験室にプリクラを設置して楽しくお仕事をしておりました。

Watcher for MMS

これは先のMMSの副産物で、小さなものですが、面白いと思うので紹介します。
MMSは、OS に Windows® 95、コンテンツの表示部に NetScape Navigator を採用したために、ソフトウェアの安定性の問題に苦労しました。今ではすっかり弊社も自前主義を脱却し他社製のソフトウェアをインテグレーションすることに何の違和感もありませんが、当時は「ソースコードがない=メンテナンスできない=品質に保証がもてない」という図式でした。にもかかわらず、他社製の(しかも無料の) NetScape Navigator を採用したために、問題が生じても対応することができませんでした。
そこで、私が作ったのは、Windows 95/98 の Blue Screen や UAE (Unrecoverable Application Error - これは16bitと32bit の2種類がある)や システムフリーズを検知して、徹底的にリブートをかけるツールでした。特に工夫が必要だったのは Blue Screen からの復帰で、仮想デバイスドライバーを作り ring 0 で待機しているスレッドが ring 3 からの定期的なポーリングを受けないと、ring 0 で CPU のリセットをかけるということで解決しました。

社内論文


  • 市川,「ソフトウェアによるKIOSK PCの障害検知および自動復旧の手法」, 大和事業所後期論文大会 (優秀技術論文賞), 1998

マルチメディア製品

パソコンに映像や音声を取り込むという今では当たり前のことも、先駆的な技術だった時代がありました。私が開発に参加したマルチメディア製品がいくつかあります。

Power9100ビデオアダプター

動画の録画機能を備えた高性能ビデオアダプターでした。私は約14万行のソースコードと格闘したあげく腰を痛めました。

マルチビデオコンボ

一枚で、テレビも録画もVideo CD (MPEG)再生もできるというアダプターです。当時はパソコンに期待するものが少し違いますね。今だと素直にDVDハードディスクレコーダを買うでしょう。シンガポールに出張に行けて楽しかったなというのが思い出です。

ビデオCDプレイヤー

IBMとして初のS/W MPEGを搭載した家庭用PCが出るにあたり、Video CD 再生用のプレイヤーGUIが用意されていなかったので、私が作ってしまいました。当時、国産他社はプレイヤーGUIが優れていたので、対抗策としては良かったと思います。この頃は、自分が関与した製品がパソコン雑誌で取り上げられることが生きがいでした。

ビデオコントロールプログラム

当時あまり知られてはいませんでしたが、SONY製のビデオ、チューナー、セレクター、モニターといったあらゆるオーディオ機器には、遠隔操作のための LANC または Contro-S というインターフェイスが備えられていました。VBOXというデバイスを経由してパソコンからそれらのオーディオ機器をコントロールするミドルウェアを作成しました。オーディオ機器に囲まれる楽しいお仕事でした。

TCO削減ツール

最近では オートノミック コンピューティングという言葉を使うようになってきましたが、管理コストの削減はずっと叫ばれてきた課題でした。1997年ごろだったと思いますが、ガートナーグループから公開された「Windows PCの管理コストは、初期の購入費を上回る」というレポートが衝撃をもって業界に迎えられました。PCの部門では、UMA(Universal Management Agent)、CAT(Computer Assited Transfer)、Smart Reaction、Rapid Restore など、TCO削減ツールと言われるソフトウェアを矢継ぎ早に開発しました。特にUMAは、その後UMS、IBM Director と進化する管理ツールの初期型で、革新的なものだったと思います。そこでは、クライアントPCの1台1台が Web Server となって、自身の持つ構成情報、エラー情報を publishするとともに、管理者からの操作を Webベースで受け付けました。また、Tivoli, NetView, SMS といったエンタープライズ レベルの管理ソフトウェアとの接続性も備えていました。私はそれらTCO削減ツールの日本語版の開発を担当しました。今から眺めると当時のTCO削減ツールというのは、本当にTCOの削減につながったのか、正直に言って自信がありません。TCO削減ツールの使い方を覚えるのに逆にコストがかかっていたのではないかという疑問がありました。特に、当時の Tivoli 製品は使い方を覚えるのに3ヶ月はかかるなどと言われていました。オートノミック(自律)というキーワードはそういう反省から来たのではないかと考えています。

BUSツール

BUlk Setup Tool の略で、「設定」を一括で配付することを目的としたツールです。TivoliやSMSは「ソフトウェア」を一括で配布できますが、「設定」を一括で配付するというツールは見当たらなかったので、私が仕組みを考案し、川瀬さんという優秀な派遣エンジニアの方と一緒に作ってしまいました。シナリオファイルを与えれば、コントロール・パネルなどのダイアログボックス・ベースのウィンドウを、シナリオファイルに従って操作することができます。このプログラムは、高齢者向けのPCを提供するプロジェクト"ITry"に採用され、文字を大きくしたり配色を変更したりといった細かな設定変更を自動化しました。

社内論文


  • 市川,「設定変更自動化ツールの開発」, 大和事業所前期論文大会 (入選), 2001