これまでの経緯
エンジニアというのはこだわりの強い人種なので、やはりそれぞれに「ここは譲れない」というポイントを持っていたりする。というよりも、むしろこういった部分こそが、その人のエンジニアリングへの適性の大きな部分を占めているようにも見える。
そういえば昔、とある OS 用の Display Driver を書いていて、コードサイズと nano seconds レベルのレスポンス向上をどう両立させるかについて、ひとわたり試行錯誤してみた挙句、これら二つのファクターを高いレベルで両立させる必要に迫られ、専用の Runtime Compiler を書き上げて Driver に組み込んだことがある。AVIO Window (テキストコンソール) を軽快に動かすために Bit-Block Transfer (Bitblt) を使うのは当時も定石だったのだが、あいにく当時の Host Terminal Emulator が画面を更新する流れと Bitblt との相性が悪く、もっとも基本である Software Draw による文字描画の部分でレスポンスを稼ぐ必要があったのだ。
ちょっと考えてみればわかる話だが、Software Draw による文字図形描画でテキストコンソールを軽快にスクロールさせるためには、一画面＝ 80 x 25 文字を最低でも一秒間に数十回、描き替えなければならない。テキストコンソールは画面上のグラフィック要素であって、当時の DOS/V のように Video RAM の開始アドレスを書き換えて疑似的なハードウェアスクロールを実現するようなわけにもいかず、なおかつ文字図形要素の一つひとつが Video RAM 上の Byte Boundary にキレイに並んでいるわけではないので、当時の Video RAM の構造を考慮すると、文字画像データの書き込み先アドレスを見て文字図形の各 scanline を Byte Boundary にかかる部分とそうではない部分に分割し、各部をそれぞれ rotate/shift した上で書き込み先に合わせて mask をかけて OR で書き込むようなことを、いちいち一つの文字図形要素を構成する数十もある各 scanline のそれぞれについて行わなければならない。その書き込み先の Video RAM も 1 byte の書き込みにうんざりするほどの Wait がかかるような代物だったから、どうしてもレスポンスの良し悪しは Software Draw の部分にしわ寄せがきてしまう。
このような要件を突き詰めてゆくと、ちょっとした画面の更新に何百万回という書き込み処理が必要になってしまい、結局のところ文字描画コードについては machine instruction のレベルで nano seconds レベルでのチューニングを図らざるを得ないことになってくる。当時はまだ 80286 や 80386 などという非力な CPU の時代で、かつ Loop や Jump 命令なども CPU Cache の Pipeline を乱してしまうのでうっかり使うこともできない。でもって、そんなこんなの要件を満たす一つの解決策が、場合ばあいによってさまざまに変化する文字図形描画の条件を Just In Time に判断して、その条件に最適化された超高速でコンパクトな描画コードを吐き出す Runtime Compiler の Display Driver への組み込みであったのだ。
話が大幅に飛んでしまいました。このような「こだわり」とそれへの実行力の有無が、個々人のエンジニアリングへの適性の大きな部分を占めているのはまず間違いのないところ。そんなわけで自分用の Debug code を埋めたまま Release Branch にコードを Check-in して平気でいられるような輩を見かけると、その人のエンジニアリングへの適性を疑わざるを得ないようなことにもなってしまう。
ThinkPad というギミック
ThinkPad はなぜ黒いのか。たったこれだけの事柄についても、その背景には当時のエンジニアの強いこだわりがあった。当時、あの会社が作る Office 什器には「必ずこの色でなければならない」という厳密な理由とそれを徹底させるための厳しい Corporate Standard があった。これに打ち勝つだけの理屈を打ち立てた当時の Yamato Design Center の強烈なこだわりには頭が下がらざるを得ない。と同時に、当時の ThinkPad のアイデンティティを訴求するためにデザインされたあの有名な「Eye Bee M」のアニメーションに注ぎこまれた情熱をどう形容したらよいだろう。このアニメーションはかの 8 セグメントの青い Corporate Identity ロゴの代わりに使うことを許された稀有の事例であって、このことはあの会社の歴史の中においても、とんでもない事件の一つだったのだ。
さて、話はそこから数年をさかのぼる。当時の Workstation Business Unit (BU) で基本設計の仕事をしていたボクは、当時まだ黒くなかった ThinkPad のコンセプトモデルを担いで Armonk や Somers などを行脚してまわっていた。それは当時のお偉いさん方の興味を強烈に惹きつけたが、それでも製品化に向けての要望はとある点に集中することになった。そのキーボードの小ささはどうにかならないのか。膝上で使う場合にマウスはどうするのか、と。もともとこの会社のエンジニアたちはキーボードというデバイスにはとてつもないこだわりを持っている上に、外人さんたちのごつい指先では、このコンセプトモデルの持つ繊細なキーボードはやはり扱いにくかったのだ。
それらの要望に対してのエンジニアの側からのこだわりの回答が、Low Profile でありつつも打ちやすい ThinkPad 伝統の Keyboard、それと皆さんご存知の ThinkPad を ThinkPad たらしめたギミックである TrackPoint と TrackWrite (通称 Butterfly Keyboard) であった。
"TrackPoint"
"TrackWrite", implemented on ThinkPad 701C as "Butterfly"
特に TrackPoint の実現においては、感圧素子への入力とノイズの違いの見極めが難しかったようで、放っておくと何も入力していないにも関わらずマウスポインタが明後日の方向に「ずるずると」流れて行ってしまったりする。そこで常時入力の補正をかけながら動作させているということだったのだが、話によるとそのさじ加減がまた難しいらしい。このあたりのエンジニアリングへのこだわりが、同じような仕組みが他からなかなか出てこない、ThinkPad を ThinkPad たらしめてきた要因の一つなのだろうと思う (ちなみにそのあたりのヘルプのために有能だった同僚が ThinkPad の開発に駆り出されていっていたのだが、彼はそのまま PC 部門の分社化のあおりを受けて別会社に持っていかれてしまった。当時はこれで非常に痛い思いをしたのだが、最近はどうやら「みなとみらい」界隈で体力づくりをしている様子が facebook で見えていて、あいかわらず元気そうで何よりである)
Field Replaceable Unit (FRU) という考え方
これはもう大型機の時代からの伝統なのだが、あの会社には「故障は現場で直せなくてはならない」という強いこだわりがある。単純な話、もし客先で大型機がトラブルに見舞われたとして、その手当てのためにシステム一式を工場に戻さなかればならないとしたらどうだろうか。そんなわけで、あの会社の作るシステムは、たとえそれが PC であっても、現場で交換することのできる FRU という単位で、基礎の部分からてっぺんの仕上げ部分にいたるまでが組み立てられている。FRU は現場でオーダー可能な部品の単位で、FRU の交換手順も、例えばそれがネジ一本の締め込み作業であったとしても、であればその一本一本の締め込みにかけるべきトルクの数値までが詳細に「保守マニュアル」としてきちんと整備されてきた。
この伝統は現在の ThinkPad に至るも受け継がれている。ThinkPad の「ハードウェア保守マニュアル」は今でも Lenovo のサポートサイトからダウンロード可能で、これが手に入れば ThinkPad の部品を FRU 単位で交換するのは誰にでもできる簡単な作業だ。今どきの ThinkPad は Built-to-Order (BTO = カスタマイズ) での受注が多く、モデルによっては標準では設定されていない仕様もたくさんあるのだが、この保守マニュアルと FRU のリストがあれば、標準モデルの ThinkPad を安く手に入れて自分好みにカスタマイズすることも可能だ (いじり方によっては保証の適用外となりうるのでそのあたりは注意されたし。それと FRU を公式のチャネルで入手しようとするとお高くつくことが多いので、その入手経路についはそれなりの工夫が必要になってくる)。
定番のカスタマイズはキーボードの交換だが、LCD パネルの交換も以前に比べると敷居が低くなってきたようだ。そんなわけでデモ用に安く入手した ThinkPad の LCD パネルを 1366 x 768 から 1920 x 1080 に交換してみようと思い立ったのだが、紙数が尽きてしまったので、続きは後編にて。それと今回の内容については記憶に頼って書いているので、もし何か間違いがあるようでしたらご指摘ください。質問はコメント欄からお気軽にどうぞ。
To Be Continued...
補足1: ThinkPad はなぜ黒いのか。それは黒という色のユニークさが ThinkPad という存在のアイデンティティを訴求するのに最適だったからである。ちょっとでも色彩学をかじったことのある人ならばよくご存知のことだと思うが、アイボリーであっても白であっても、その色のバリエーションは無限にあり得るが、真の黒という色はたった一つしか存在し得ない。
補足2: あの会社の持つキーボードへのこだわりは、タイプライター時代のメカニカルな打鍵感にまで遡ることができる。その打鍵感を再現させるために Host Terminal のキーボードにハンマーを組み込んで打鍵のリズムに合わせてキーボードを内部から振動させる仕組みを持たせたりしていたのは有名な話。IBM PC のキーボードに採用されていたあのメカニカルスイッチもその伝統を引き継いでいる。さらに日本でリリースされた PS/55 用の G キーボードもこの流れに連なるものであった。