第36回
ITもの作りの原点

 前回は「ビットの化石」と題してCP/M 1.4復元計画を実行し,エミュレータ上での動作が確認できた話をした.

 その時点ではディスク内容のバイナリイメージを復元し,ネットで入手したエミュレータで個々のユーティリティの動作までは行ったが,その先,つまり完全なるCP/M 1.4の復元まではたどり着いていない.8080のエミュレータを使えばすぐにでもブートできそうなものだが,CP/M 1.4は77トラック×26セクタという8インチ片面単密度のFDの物理フォーマットを前提に作られているので,FDDのエミュレータも作らなければならない.

 それ以前に,データリカバリを依頼した結果として帰ってきたのは,マスターディスクのコンテンツをファイルとして解読してWindowsのファイルシステムに変換してくれたものだった.データ復元という意味ではこれで良いのだが,私がやりたかったのはシステムの復元だったので,改めてディスクの物理復元を追加発注している所である.たかがCP/Mなのだが,0から始めるとなるとこれがなかなか疲れるのである.何でもそうだが,何もない所から始めることはたいへんなのである.

遠くなる技術の原点(?!)

 20世紀末からの数年間だけで,IT革命,ITバブル崩壊,そしてユビキタスや電子タグをキーワードとし,組み込み系,IT,もの作りの復興と持ち上げられたり叩かれたりと忙しいIT業界なのだが,とりあえずハード,ソフトの開発手法高度化はどんどん進んでいる.開発を効率化しつつ信頼性をあげるためには,開発環境の高度化が必須なわけで,それがあっての現代IT社会が成立しているのは間違いない.

 しかし,何かが変だと思うことがある.かつて開発スタイルが原始的だったころの開発に要求された技術常識と,今の抽象化された開発スタイルに要求される技術常識が変わってきているように見えるのである.

 かつて手作りのパソコンにCP/Mを入れるときには,FDの物理フォーマットまで知っていることが常識だったのだが,DOS/Vパソコン時代になるとFDの常識はケーブルの接続法までで止まってしまう.ソフトウェアもVB世代になってソフト開発の重要なノウハウは,いかに多くのコンポーネントの使い方を知っているかということになってきている.

 それ以前に,かつては組み込み系の話をするときに,ハード,ソフトという分化があいまいで,ハードを設計する人が,ソフトも作っていた.しかし,それでは効率が悪いということで,開発スタイルが階層化し,需要の多い上層担当の技術者が求められているのだから,そういう層に特化した技術者教育がもてはやされるのも当然といえば当然なのである.

原点を忘れると何がおこるか?

 有名なところでは,インテル8080の初版でのGNDパターンの設計ミスの話がある.かつてインテルが8080を作ったとき,論理的にはエラーがなかったにも関わらず,GNDのパターンが細かったために,ワーストケースでは論理0の電圧が十分に低下しなくなり,動作条件が厳しくなってしまうということがあった.レイアウト,回路設計,論理設計が分化した結果,全体を見る視点で盲点が出たということか.LSIもオームの法則に縛られるという原点を忘れてはいけない.

 ソフトウェア開発はスタート地点が高レベルになると,逆に自由度が低下する.高レベルな開発システムで作るとできあがるプロダクトの外見や機能が似てくるのである.もちろん,開発ツールを提供する側は,デザイン変更やコンポーネントそのものの開発もサポートするのだが,使う側は開発ツールに付属するサンプルコードの改造でできることに限定して使っていることが多い.

 以前,ファイル圧縮解凍ツールを探したときのことなのだが,あるサイトでフリーソフトウェアがたくさんならんでいるのを見て,まだまだ日本のソフト開発力も捨てたものではないと思ったことがある.しかし,実際にダウンロードして走らせると肝心の圧縮・解凍のエンジンはどれも同じDLLを使っていて,違うのはユーザーインターフェースという皮の部分だけだった.これらツール開発の原点はアルゴリズムではなく,DLLであるらしい.

 計算機業界ではずいぶんと昔にハードとソフトの分化がなされており,今では教育体系もまったく異なっている.たしかに情報処理としてのハードとソフトは最終製品のレベルで別物として取り扱われる社会通念が同時にできたため,自然と受け入れられているともいえる.

 問題は,元祖日本組み込み系である.これは最終製品が「物」であり,ソフトとハードが不可分なのである.今一度,IT物づくりの原点を確認しておく必要があると感じている.

やまもと・つよし

北海道大学大学院工学研究科電子情報工学専攻

計算機情報通信工学講座 超集積計算システム工学分野


「移り気な情報工学」のトップへ戻る

Interfaceのホームページへ戻る

コラム目次
New

Engineering Life in Silicon Valley 第79回 フリー・エンジニアという仕事(第一部)
移り気な情報工学 第36回 時代間通信アーキテクチャ
フリーソフトウェア徹底活用講座 第14回 GCC2.95から追加変更のあったオプションの補足と検証(その3)

Back Number

フリーソフトウェア徹底活用講座
第13回 続々・GCC2.95から追加変更のあったオプションの補足と検証
第12回 続・GCC2.95から追加変更のあったオプションの補足と検証
第11回 GCC2.95から追加変更のあったオプションの補足と検証
第10回 続・C99規格についての説明と検証
第9回 C99規格についての説明と検証
第8回 C言語におけるGCCの拡張機能(3)
第7回 C言語におけるGCCの拡張機能(2)
第6回 GCCのインストールとC言語におけるGCCの拡張機能
第5回 続・C言語をコンパイルする際に指定するオプション
第4回 C言語をコンパイルする際に指定するオプション
第3回 GCCのC言語最適化以外のオプション
第2回 GCCの最適化オプション ――Cとアセンブラの比較
第1回 GCCの最適化オプション

移り気な情報工学
第36回 ITもの作りの原点
第35回 ビットの化石
第34回 ユビキタスなエネルギー
第33回 ロゼッタストーンとWWW
第32回 情報家電のリテラシー
第31回 草の根グリッドの心理学
第30回 自分自身を語るオブジェクト指向「物」
第29回 電子キットから始まるエレクトロニクス
第28回 映画に見る,できそうでできないIT
第27回 ITも歴史を学ぶ時代
第26回 1テラバイトで作る完全なる記憶
第25回 日本はそんなにIT環境の悪い国なのか
第24回 10年後にも生きている技術の法則
第23回 ITなギズモ
第22回 ブロードバンドネットワークに関する三つの質問

Engineering Life in Silicon Valley
第78回 インドに流れ出るシリコンバレーエンジニアの仕事
第77回 エンジニア達の健康管理・健康への努力(第二部)
第76回 エンジニア達の健康管理・なぜエンジニア達は太る?(第一部)
第75回 ユーザーインターフェースのスペシャリスト(第二部)
第74回 ユーザーインターフェースのスペシャリスト(第一部)
第73回 放浪の旅を経てエンジニアに……
第72回 凄腕女性エンジニアリングマネージャ(第二部)
第71回 凄腕女性エンジニアリングマネージャ(第一部)
第70回 ビジネススキルを修行しながらエンジニアを続ける
第69回 専門分野の第一線で活躍するエンジニア
第68回 シリコンバレーに夫婦で出向(第二部)
第67回 シリコンバレーに夫婦で出向(第一部)
第66回 目に見えないシリコンバレーの成功要因
第65回 起業・独立のステップ
第64回 インターネットバブルの前と後の比較
第63回 日本でシリコンバレースタートアップを体験する(第四部)
第62回 日本でシリコンバレースタートアップを体験する(第三部)
第61回 日本でシリコンバレースタートアップを体験する(第二部)
第60回 日本でシリコンバレースタートアップを体験する(第一部)

フジワラヒロタツの現場検証
第72回 現場検証,最後の挨拶
第71回 マイブーム
第70回 OSぼやき放談
第69回 技術者生存戦略
第68回 読書案内(2)
第67回 周期
第66回 歳を重ねるということ
第65回 雑誌いろいろ
第64回 となりの芝生は
第63回 夏休み
第62回 雑用三昧
第61回 ドリームウェア
第60回 再び人月の神話
第59回 300回目の昔語り
第58回 温泉紀行
第57回 人材ジャンク
第56回 知らない強さ
第55回 プレゼン現場にて


Copyright 1997-2004 CQ Publishing Co.,Ltd.