ハードウエアの話

日立、富士通日本電気の御三家は、今も超大型コンピュータから組み込みシステムまで幅広いハードウエアを開発しています。これは、企業ブランドという問題だけではなく、日本国の政策として行われてきた開発を続けているということも上げられます。それだけではなく、研究開発における人材ならびに情報や知識のポートフォリオが堅実に実行されているからと考えることは妥当でしょう。つまり、素晴らしい研究開発環境と素晴らしい人材が居るからこそ可能なのです。知的財産権のみならず、人材育成面でも組織システムが安定しているからこそ可能であると考えることは妥当です。
三菱電機東芝沖電気はやめてしまいました。「なぜ?やめてしまったのか?」ですが、東芝の場合には、事業の集中と選択という判断に変わったからであると考えることは妥当でしょう。三菱電機の場合には、官需という安定した市場があるため、そちらを中心に行えばよいという判断からでしょう。さらに続ければ、三菱グループという巨大企業連合体があるわけですから、製造のみならず、販売面においては三菱商事が受け持ち、資金管理等に関しては、三菱UFJ銀行が受け持つという仕組みが出来ているからだと考えることは妥当です。つまり、全体として巨大なパッケージビジネスができる仕組みになっているわけです。沖電気に関しては、通信分野に特化することで生き残りを図ろうとしているのでしょう。もう一つの事業としては、ASIC事業であると考えることは妥当です。後は、既存の顧客に対してサポート面やシステムインテグレータとしてのビジネスを続けようと考えているのでしょう。

ソニー松下電器に関しては、コモディティが中心になりますから、圧倒的に消費者よりのビジネスが基本でしょう。そして、さらには放送・通信分野における特機事業というのが存在するため、こちらが相変わらず主力のビジネスだと考えることは妥当です。
SONYの場合には、コモディティビジネスで培ったIC等の部品のOEMや販売、さらにはメディアビジネスを通じたコンテンツビジネスを中心に展開していくのでしょう。コンテンツビジネスの場合には、金の卵の発掘であるとか、時代への企画ビジネス(マーケティング指向)のビジネスが続くのではないかと考えられるのです。つまり、マーケティングを見据えた上で、次の時代のキーワードを演出するための技術開発を行うというやり方でもありますし、場合によっては周回遅れを取り戻すために、一気に時代の先頭となる技術開発に挑戦するというやり方でしょう。

久しぶりに読んだ本
オブジェクト指向プログラミング入門, 著:ティモシイ A. パッド, 訳:羽部正義, アジソンウェスレイ・トッパン 1992, 東京. ISBN 4-8101-8048-4
オブジェクト指向入門, 著:Bertrand Meyer, 監訳:二木厚吉, 共訳:酒泡寛・酒泡順子, アスキー出版局 1990, 東京. ISBN 4-7561-0050-3
Smalltalk:オブジェクト指向プログラミング, 著:L. J. ピンソン R.S.ウィナー, 訳:富士ゼロックス情報システム株式会社, アジソンウェスレイ・トッパン 1990, 東京. ISBN 4-8101-8011-5

これは今も家にある本たち。

オブジェクト指向のプログラミング -ソフトウエア技法の進化-, 著:B.J.COX, 監訳:前川守, アジソンウェスレイ・トッパン

Appleの思い出

ふと気が付いたのだけれども、Mac OS-Xは「FreeBSD」+「machカーネル」でした。これは、今のApple社のCEOである「スティーブジョブス」氏の「NeXT」からくるものであるということは、有名な話です。「NeXT」は、私にとっても印象深いマシーンだった記憶があるのです。なぜならば、友人と一緒に、見に行ったことがあるかなのです。ちなみに、当時他に気に入ったマシーンは「SONY」の「NEWS(NetWork Stationの略、ちなみにIkki Projectという、社内ベンチャーで開発が行われたというすごいマシーン。最初は、32ビット汎用コンピュータを作るプロジェクトだったらしいのだけれども、部下の方々が厚木にあったVAXと同じ環境を使いたいとの事で開発方針が変更になった。そして、完成したマシーンは失敗プロジェクトのシグマ計画の先を行くワークステーションだったらしい。この辺りは、土井利忠さんの本で読んだことがある。さらには、日経コンピュータの記事でも読んだことがある)」でした。
なぜならば、やっぱり当時の環境(MSXPC-9801)からすれば、広大なメモリーが使えることと、「ネットワーク環境」が標準で使えることだった記憶がある。

結局、Mac Classicが出て、そちらを買うことになったのだけれども。
ちなみに、Macが好きだったのは、「ユーザー・インターフェイスガイドライン」というものが定めてあり、弱者に優しいマシーンだったからということ。資料等を揃えてプログラムをしようとしたら、それはそれは大変な仕組みで動いていることに気がつかされた。ToolBoxというAPIのコールだけで、あっちにこっちに決められたプログラムを組まなくてはならないということ。さらには、セグメントという概念(これは、MC68000シリーズ時代だけの話)が出てきて、びっくり。ええーインテルのCPU(当時のCPUはi8086とi80286とi80386だったけど、MS-DOSで使うと、セグメントの概念が出てきていた。ちなみに、OS/2Unixで動かすと、プロテクトモードが動いてセグメントは関係なかった。ただし、安全なプロテクトモードは、i80386以降の話)と同じだね・・と。「多分、最初にMac設計した人にとっては苦肉の策だったんだろな」と振り返って思うのです。
なぜならば、最初のMacを設計した人は、たった128KBのメモリーを駆使して、GUIやイベント駆動型のソフトを開発しなければならなかったから。つまり、ToolBoxにたくさんのルーチンを内蔵することと、メモリー管理をセグメント化することで、アプリケーションの構造分割を図れるようにしたと考えることは妥当でしょう。ちなみに、「Mac」のご先祖さまに当たる、「Alto」はハードウエアでGUI制御やイベント管理を行っていたそうです。Altoクラスになると、当時のVAXやPDP-11等の「スーパーミニコンクラス」のハードウエアが必要だったからでしょう。

やっぱり当時のMC68000の値段というのは、妥当だったのかも知れません。

最近の、MacPowerPCになったため、こんな話は笑い話です。そして、そのAppleも「インテルのCPUを採用するとか?しないとか?」という記事を読みました。コストメリットを出すために、大量に使用されているCPUを使うというのは、仕方がない選択肢なのかも知れません。近年は、バーチャル環境というのが増えてきていますから、ハードウエア間にある「互換性」の問題に関しては「エミュレーション」で対応できると考えたのでしょう。実際に、バーチャル環境及びモニターというのは、ネットワークのみならず、ハードウエア間の互換性を乗り越える一つの方法でもあります。

「コンピュータの世界も、だんだん独自性がなくなるのかな?」と思う。それだけ、差別化が難しくなってきたんだろうと思う。

独自性を打ち出すためには、結局二極化しか道が無いのかもしれませんね。高級路線(車で言えば、セルシオNSX、シーマ、Ferrari、BENTZやBMWさらにはJaggureかな?)と普通路線(車で言えば、カローラ、ビッツ、サニー、FITS、Demio、さらには日本独自の軽)の2極化していくのかも知れません。ニッチを狙って、3極という選択肢もあるでしょうけど(IBMやHP、SUNの路線かな?)。

でも、既存のユーザーにしてみれば、最終的にはハードウエアより、ソフトウエア資産及びデータ資産になるわけだから。やっぱり、データ資産の標準化であるとか、ソフトウエア資産の標準化というのは大事な気がします。

GECKOとNECKOの話。

この描画エンジンは、「C++」と「Java」によって書かれているらしのです(Mozzilaの公式HPから)。つまり、メモリーヒープの管理がおかしくなって、FireFoxの調子が悪くなったのではないだろうか?と考えらるのです。それでも、これは推測に過ぎないのですが、

それとも、「TclCORE.DLLが無いため起動できない」というメッセージが出ていたところから推測すれば、「電子国土国土交通省)」の「GISプラグイン」との相性だったのかも知れない。


そのため、記憶させていたパスワードやログインのアカウントが消滅してしまったのでした、非常に残念。

 せっかく、バイオDB検索ツールやHTML-Validator、気象情報ツール、Javaコンソール(デバッガ)等も搭載して、強化してあったのに残念です。ちなみに、KDEGnomeデスクトップで動いているFireFox等のブラウザでは問題が生じていないようです。
 なんとなく、WindowsXPというのがUnix(Linux)の子孫達に比べれば、「メモリー管理」等に関してはいい加減なのかもしれない。もしくは、「FireFox」等が「.net」で開発されていないために、「Windows XP SP2」のAPI変更に対応し切れていないのかもしれません。
 ちなみに、これらすら・・「仮説」に過ぎないのだけれども。なぜならば、私自身は関係者ではないからです。元プログラマシステムエンジニア・プロジェクトマネージャーを経験したことがあるだけのエンジニア上がりです。つまり、経験してきたことや学んできたことを元にして推測は可能です。なぜならば、アセンブラから始まり、フレームワーク開発まで見てきましたから。そして、ハードウエア設計からソフトウエア設計まで悩み学び続けてきたからでしょう。

システム設計の話

なんとなく、重たい部分を書き換える時代が来るのかも知れない。時代は繰り返すというから、重たくなると分割して、軽い仕組みに変わるのかもしれませんね。つまり、「セキュリティパッチみたいな仕組みから、セキュリティモジュール的な開発手法に変わるんじゃないかな?」と考えています。つまり、「オブジェクトモジュール化が行われることによって、システムの持つ脆弱性に対しても、機能追加にしても作業がしやすくなるんじゃないかな?」と、考えてしまうのです。「CPUの性能も良くなってきたから、そちらに任せることも重要だけれども、OSやシステム環境も含めて、再びコンテンツ型の開発手法というのは見直されてもいいんじゃないかな?」と考えます。
つまり、巨大になってしまったシステムを分割して、フレームワークにしても、デスクトップにしても、サーバアプリケーションにしても、オブジェクトコンテンツ型の開発手法があっても良い様な気がします。オブジェクトコンテンツとは、クラスライブラリーを機能毎に分割した部品群のことです。

つまり、オブジェクトコンテンツだけをチューニングすれば、より高性能なアプリケーションに変えることが出来るという訳です。また、オブジェクトコンテンツ自身の雛形をたくさん用意することによって、それらの交換をしやすくすること。これらによって、柔軟な機能拡張や新しいハードウエアの出現にも対応できるというわけです。実際に、組み込み型のOSはそんな設計になっているようです。

さてそのことによって、コード開発の見通しが付きやすくなります。さらにはプロジェクトの再生産性が高まるから、たくさんのエンジニアの人たちが幸せになれそうな気がするのです。

T-engineの話

こちらに関しては、「ユーザーインターフェイスガイドライン」がやっぱりあるようです。その目的は、標準化にあるような気がします。ユーザとコンピュータ間やコンピュータとコンピュータ間のインターフェイスを統一することで、情報流通の流れを標準化すること。そのことによって、様々な応用アプリケーションに適応していこうという考え方のようです。もともとの目的が、「Real Time Nucleas」だったわけですから、本当に進歩を遂げたんだなと思います。坂村健さんの夢は、コンピュータ全体の環境をデザインすることだったわけですから、一部の特定用途向け大型コンピュータ(デジタル交換機)から、組み込みのコンピュータまで、統一された形でのシステムデザインが達成されつつあるわけですね。M-TRONは実現しませんでしたが、T-engineになってから、データ流通のしくみであるとか、本当の「組み込み向け」の用途システムとして花を開きつつあるような気がします。

この項目、遠い昔によんだ「電脳構築学」や「TRONを創る」、さらには「ITRON」関連の書籍を思い出して書いています。

X86Free上でのデスクトップの話。

KDEデスクトップでは、「内部モジュール化」が図られていて、かつまた、「ユーザ・インターフェイスガイドライン」が定められているようです。そのおかげだと思いますが、全体のデザインとして統一された印象を受けます。
Gnomeデスクトップは老舗です、これに関しても「内部モジュール化」が図られています。こちらは、「ユーザ・インターフェイスガイドライン」はありません。ゆえに、widgetを上手に使って各アプリケーションを作成するという方針のような気がします。

Mozilaのお話

先日、自宅で使っているFireFox(Mozilla)がおかしくなってしまいました。

これは推測に過ぎないけれど、いろいろな拡張機能(XPI)を搭載したために、コンフリクトが発生してしまったためであろうと思うのです。
Geckoという描画エンジンを搭載しているのは、FireFoxMozillaNetscapeなのは確かです。「Necko+Gecko」で正しいようでした。

CVS等を見るとエンジン自身の開発は最近は滞りがちのような気がします。なぜならば、高度なエンジンだから、内部コードを変更することはリスクを伴うからなのでしょう。しかし、それでも内部コードの最適化は行われていると考えることは妥当でしょう。
そして、将来は完全に書き換えて、もっと「コンパクト」になるのかも知れません。なぜならば、「Linux」や「Unix」、さらには「Windows」や「T-engine」等でもデスクトップの環境を決めているWidgetの性能が良くなってきたので、そちらに委ねることで開発が楽になるからだと思います。

さらに続ければ、これらのシステム環境(もう、すでにどれもOSという概念を超えて、システム環境と呼ぶのにふさわしいくらいのシステムになっています)を構築するのは、非常にセンシティブであり、かつまた、緻密な設計が要求されるということなのでしょう。なぜならば、それらのコードの品質が、即機能及び性能に直結してしまうからだと考えることは妥当だからです。