美食を極めるには不味いものを食べるべし

美食の王様 ―究極の167店 珠玉の180皿　という本をご存じだろうか。この本の著者、来栖けい氏は若干26歳。なんと、この本のファンサイトまである。

自分が来栖けい氏を知ったのは、フジテレビ日曜PM10時からやっている週間人物ライブ『スタ☆メン』で取り上げられていたからだ。

ちょうど、グルメ評論家の山本益博氏が来栖氏の本を「読み終わっていやな感じがしない、店や料理をけなすようなことがひとことも書いていないのに、圧倒的な情報量で説得力があり、その店に行ってみたくなる」と語っていたところだった。

来栖氏は、こどものころ親に一流の料理店に連れて行かれたことが多くあったとのこと。小さいころから一流の料理人が作った料理を口にする機会があったということだ。しかし、他のグルメ評論家とは違って風貌はお世辞にもオシャレとはいえず、パーカーは高校生のときに買ったものを今でも着ているのだという。大衆店も一流店もその格好で入っていく。（でも、メガネだけにはこだわっているみたい）

カメラは来栖氏の一日の行動を追っているのだが、何しろたくさん食べる。一つに店に入って看板メニューや気になる料理を注文しまくって、テーブルいっぱいに並べる。おそらく４～６人前くらいはあると思う。これらの料理を来栖氏はすべて平らげる。『スタ☆メン』では来栖氏の朝と夜の体重差を計っていて、夜6Kgも体重が増えていた。

でも、彼はほっそりした体型なのだ。ようするに、あまり栄養を消化吸収しない体質なのだと思う。よく、大食いコンテストで優勝する人の中に痩せている人がいるが、これらの人たちに共通するのは食べても食べてもなかなか栄養を吸収できないらしい。

ただ、来栖氏の場合、そのような体質でありながら舌が肥えているという点が他の人たちとは違う。来栖氏は食べても栄養を吸収しないという特徴を活かして、一日に何件ものレストランをまわり食べまくる。そして、3ヶ月たっても記憶に残っている料理のことについて本に書くという。

来栖けい氏のことを今回ブログに取り上げたのには理由がある。ひとつは、「グルメ評論家のプロフェッショナルになるには、最高の料理をたくさん食べて、感銘を受ける経験が必要」また「美食を極めるには不味いものを食べるべし」という彼の発言に、組込みソフトエンジニアを極めるためのアプローチと共通するものを感じたからだ。

来栖氏は「不味いものを食べたときに後悔しないですか？」というインタビュアーの質問に「いや、不味いものも食べないと、おいしいもののすばらしさがわからなくなる」と答えていた。

これと同じことを、先日、娘のピアノの発表会で感じた。娘二人が通っている音楽教室は、個人の教室でありながらピアノだけではなく、バイオリンやマリンバ、サックス、ドラムなどいろいろな楽器を教えている。

発表会は一日2回、4時間ずつに分けて演奏が続く。今回は自分の娘の演奏だけでなく他の子供達の演奏と講師の先生の演奏合わせて4時間びっちり聴いた。

そこで感じたのは、印象に残るのは「こんなに小さいのに上手に弾くなあ」という感覚で、演奏会の最後に披露される講師の先生達の演奏は、子供達よりも遙かにうまいにもかかわらず記憶に残らないという事実だ。

子供達の演奏でも言っちゃ悪いがかわいそうに思えるくらいひどいものもある。特にバイオリンの初心者の演奏はそうだ。ピアノやマリンバやドラムは叩けば、一応意図した音が出るが、バイオリンは意図した音階の音を出すこと自体が難しいので、初心者の演奏は聴くに堪えないようなものもある。

しかし、その段階を抜け出して完璧ではないものの80%～90%きちんと演奏できると、「ああ、すごい。この子はよく練習している、上手だなあ」と感じるのだ。

講師の先生達の演奏は、うまいのが当然なのではっきりいって何の感動もない。

でも、そういう風にしか受け取れないのは、たぶん自分の耳が肥えていないからなんだと思う。もっともっとセミプロや本当の一流の演奏を聞き込んでいけば、演奏のテクニックや表現力の違いを感じ取ることができるのだろう。音響設備も iPODだけでなく、性能のより高いアンプ、スピーカがあった方がいいし、コンサートで生の演奏を聴くことも必要だろう。

組込みソフト開発の世界も料理や音楽の世界と同じだと思う。ソフトウェアは要求された目的を達成するための方法はひとつではなく、無限に存在する。そして、アーキテクチャやモデル、コードが美しければ、品質が高くなり、顧客満足を高めることができる。

アーキテクチャやモデル、コードが美しいかどうかを見極めるためには、もちろん美しいアーキテクチャ、モデル、コードを見ることも大事だが、見るに堪えないコードやモデル、アーキテクチャも見ておかなければいけない。

見るに堪えないコード、モデル、アーキテクチャを見ることで、美しいコード、モデル、アーキテクチャがを書くためにはさまざまな知識やスキルが必要だということがわかる。

だから、ひどいコード、モデル、アーキテクチャを見つけたら感謝をしないといけない。教科書に載っているようなコード、モデル、アーキテクチャばかり見ていると、当たり前のように自分も美しい成果物を作れるような錯覚を起こしてしまいがちだが、実は自分たちもプロフェッショナルの作品とは言い難いものを平気でリリースしてしまっていることの方が多いのである。

人の作品と自分の作品を見比べて、反省したり、ほっとしたり、自信を持ったりする経験をたくさん積むことが大事なのだ。

なるほど、これが海外人材登用の新しいかたちなんだ

先日、渋谷のパソナテックのオフィスでパソナテック 海外事業部 部長の小平達也氏にオフショア開発（海外に開発を委託すること）についてお話を聞く機会があった。

小平氏との話にいくまえに軽く渋谷の複雑性について書いておく。

渋谷はいつ行ってもわかりにくい。パソナテックのオフィスは渋谷のマークシティウェストにある。渋谷マークシティは渋谷駅に直結しているのでJR渋谷駅の改札を出てからすぐにたどり着くかと思うとそうではない。渋谷マークシティに直結しているのは京王電鉄の渋谷駅の方だ。

だから、最短の行き方はJR渋谷駅の改札を出るときに京王への乗り換えの方（ホームから階段を上に上がる）へ行き、京王の改札を目指す。途中マークシティの表示があるのでその表示に従い京王電鉄の改札まで行ってしまうと行き過ぎとなる。改札まで到達する前にマークシティの4階に上がらないといけない。

4階に上がらないと改札を通り越してマークシティウェストまでたどり着けないのだ。4階に上がるとレストラン街が広がっており、オシャレなレストランがたくさん並んでいる。このレストラン街をどんどん進んでいくと、トンカツ屋があるのでそのトンカツ屋の手前のエスカレータを使って5階に上がり、5階のエレベータホールから17階に上がるとパソナテックの渋谷オフィスに到達する。

パソナテックのWEBサイトから案内図をダウンロードしておいてよかった。渋谷に近いからといって案内なしにたどり着けないのが渋谷の特徴だ。

パソナテックのオフィスは白が基調で赤がポイントカラーとして使われており、日本の会社らしからぬかっこいいオフィスだった。

さて、小平達也氏は海外事業部の部長で、パソナテックコンサルティング（大連）有限公司 の董事を兼任されている。中国でのエンジニア事情に詳しい方で、@it にも数多く投稿されている有名人だ。

個人的には『アジア技術者が採点する日本技術者の実力（1）中国編』の記事を興味深く読ませてもらった。

小平氏にうかがったお話の中で、強く印象に残ったのは、パソナテックの「理工系人材・グローバル採用支援サービス」の話だ。

「日本は中国の技術者の人件費の安さだけに着目して開発の一部を中国に移し、そう簡単にはいかないことが分かって撤退し、やっぱり国内では人材が確保しきれないのでまた進出するという“行ったり来たり”を繰り返している」という話をしたところ、パソナテック海外事業部の戦略は違うというのだ。

中国で優秀かつ日本語ができるエンジニアの卵（優秀な大学を卒業したポテンシャルの高い人材）の中から、さらにクライアントの要求に近い人材を抽出し、これらの人材を日本の企業に派遣する。そして派遣先の企業でドメインに特化した技術・知識を学ばせ、将来幹部候補になりそうな人材にまで成長する見通しが立ったところで、その企業に正社員として登用するというサービスを提供しており、これが非常に評判がよいとのこと。

この話を聞いて真っ先に思ったのは、その高い教育を受けた中国人の人材が自分の獲得したスキルを活かして他社に転職してしまう危険性はないのかという点だ。

これについて小平氏は「中国の大学を卒業して、欧米の企業で1年契約の更新を続け、人がどんどん流動している様子を見ていれば、当然自分も条件のいいところに移りたいと思いますよ。」「でも、大学を卒業して真っ白は状態から、長期雇用の日本の企業文化にふれさせて、幹部候補にもなれる期待をかけてあげれば、他社に転職されてしまう危険性はほとんどないんです。」と語った。

そして、日本の企業はその人材が本当に自分の組織に適しているかどうかを見極めるまでは、正社員として登用しないので、雇用のリスクを最低限に抑えることができる。

もちろん、日本の学生を採用する際に支払う給与よりは高い派遣費用がかかるが、そもそも人口の多い中国から厳選して厳選して人材を見つけてきているだけに、いい人材が見つかる確率が高いのだそうだ。

中国を含めた東南アジアのマーケットに進出するつもりがなく、日本発でプロダクトアウトしていく企業が中国の技術者の人件費の安さだけを求めてオフショア開発を進めるとうまくいかないという点については自分も小平氏も意見は同じだ。

日本の組込みソフトとオフショア開発については、技術評論社の組込みプレス vol.4 （2006年8月発行予定）に SESSAME Workshop 2006 の続きの座談会ということで記事が載るので、そちらも参照していただきたい。

また、日本のエンジニアは長期雇用の前提があるため井の中の蛙になりがちで、外国人のインターンを組織的に受け入れて、プロジェクトに配置することで、日本人の技術者達に刺激を与えることができるという話もあった。

日本の技術者には技術を磨き続けなければ生き残れないというプレッシャーも与えないといけない。

世界は広いということを認識しなければ・・・

権限もいらないから責任も取らないってあり？

責任者が誰だか分からないという ソフトウェアプロジェクトを見たことがある。実際にはマネージャ的な存在の人物はいるのだが、どうもだれも自分が責任者だと認識したくないらしい。

組込みソフトの世界で、技術者として長年やってきてベテランといわれるようになったものの、管理職としてプロジェクトマネージャになるのは嫌だというケースは昔もあった。自分は一生技術者でやっていきたい、管理職にはなりたくないという人の気持ちはわかる。

組込みスキル標準 2006年板 キャリア標準 Version 1.0（IPA ソフトウェア・エンジニアリング・センター）によると－組込みソフトウェアエンジニアの職種分類－は以下のようなものがあるという。

・プロダクトマネージャ（開発製品の要求仕様策定と統括管理）
・プロジェクトマネージャ（プロジェクトのマネージメント）
・ドメインスペシャリスト（専門的な知識、技術、経験でプロジェクトを支援）
・システムアーキテクト（アーキテクチャ：構造を設計する）
・ソフトウェアエンジニア（ベーシックなプログラマ）
・ブリッジSE（分散開発における橋渡し）
・開発環境エンジニア（プロジェクトで使用するツール・設備を構築、運用する）
・開発プロセス改善スペシャリスト（開発プロセスを調査し改善を推進する）
・ＱＡスペシャリスト（成果物の品質を保証する）
・テストエンジニア（テストのスペシャリスト）

この職種分類が実現するなら、技術者→管理職というキャリアパス以外にいろいろな選択肢が出てくるのだろう。でも、今現在、ほとんどの組織ではまだ、技術者で何年もやってきてベテランといわれるようになるとプロジェクトマネージャになるという流れが多いと思う。

でも、同じ製品に携わったことでドメインの知識はあるが技術力がないという状態で、プロジェクトマネージャはやりたくない、技術もないけど管理職もイヤというのはないだろう。

このパターンで最悪なのは、何か問題が起こると技術を持っている協力会社に問題の解決を押しつけて、再発防止にはちっとも乗り出さないというケースだ。「しょうがないよ。誰も悪くないんだ。」「緊急事態だから、ここはなんとか頼むよ。」といいつつ、明らかに協力会社のアウトプットしたものに誤りがあった場合は「次からは気をつけてくれよ。」という態度にでる。

ようするに発注者の立場を利用して外注いじめをするようなタイプだ。

以前、英語でしゃべらナイトにカルロス・ゴーン氏がゲストで出演していたとき、一番大事な英単語は何かと聞かれて“commit”と答えていた。commitment の意味は、必ず果たすと約束 と理解している。

カルロス・ゴーン氏は社員に「あなたが必ず果たす約束は何か？」と聞くわけだ。責任と権限が曖昧な日本では、この質問をされると躊躇する者もいるだろう。

組織の中で commit する＝必ず果たすべき約束をする ということは、技術者なら大抵は現状で足らないスキルを獲得するというオプションが付いてくるだろう。足らないスキルを獲得する努力なしに、組織と約束したことを実現することはできないはずだ。だから、commit するのに躊躇するエンジニアは足らないスキルを獲得できる見通しが立っていない、もしくは、最初から無理だとあきらめているのだと思う。

でもソフトウェアの品質を高めて顧客満足の高い商品を作りたいのなら、足らないスキルを何とかして獲得しなければいけない。

また、責任と権限という観点で考えれば、自分たちでルールを決めてそれを守るという習慣を付けなければ何事もうまくいかない。

ツールに任せるのにも限界がある。人間はもともと過ちを犯しやすく、技術者が毎日毎日作り込んでできあがるソフトウェアの品質を高めるには、自戒的アプローチは必須である。プロジェクトメンバーは多種多様であり、メンバー全員にルールを守ってもらうためには、メンバー一人一人の責任と権限を明確にしておく必要がある。

プロジェクトメンバー全員が「あたたかい人間関係の中のやさしい一員」という認識のもと、困ったことがあったら誰がということもなくみんなが自己犠牲を払いながら問題を解決していくというアプローチは非常に日本的であり、これでうまくいくのならそれもいいように思う。

しかし、この考え方はともすれば、自らを律してスキルアップすることからエスケープしたり、責任回避の結果、ユーザーにしわ寄せがくる可能性がある。誰も責任を取らずにユーザーが不利益を被るようだと、その組織の存続は危うい。

「あたたかい人間関係の中のやさしい一員」という考え方だけでものづくりができる時代はとっくの昔に終わっている。「創造性と個性にあふれた強い個人」と「あたたかい人間関係の中のやさしい一員」のバランスを取る必要があるのだ。

だから、権限もいらないから責任も取らないという選択肢はない。そんなあまあまな体質のプロジェクトで顧客満足の高いプロダクトができるはずがない。

後5年もすれば、組込みスキル標準「ETSS」で当たり前のように技術者のスキルが診断されるようになり、プロダクトマネージャやプロジェクトマネージャの素養のない者は、責任や権限から解放されるかもしれない。

でも、管理職から解放された技術者は他人よりも優れた技術を持って、スペシャリストとしてやっていけなければ、どんなにベテランでもプロジェクトの中でやることがなくなってしまう。

ベテランの技術者は自分の技術の優れている点が何かをもう一度チェックし、特に優位な技術がないのであれば責任と権限を意識して、プロジェクトマネージャとして組織から信頼を得られるようにしなければいけない。

これって厳しすぎ？

小学生の問題も解けないなんて！

小学一年生の娘が宿題をもらってきた。４文字で一番後ろに“え”が付くものをできるだけたくさん考えてこいという問題だ。

家族4人で頭つきあわせて考えたがなかなか浮かんでこない。どうしても出てこないのだ。結局、数十分が過ぎて、宿題を出された末娘が“くちぶえ”を 思いついた。その後、小学校4年生の上の娘は“油絵”と“胡麻和え”を思いついた。

自分と妻は回答ゼロだった。

この問題がなぜ難しいのか？　それは、人間の記憶はシーケンスが重要な役割を担っているからだ。人間の記憶とシーケンスは深い関係がある。このことは『考える脳 考えるコンピューター』にくわしく書いてある。また、『考える脳 考えるコンピューター』でジェフ・ホーキンスは、人間の脳は特に意識しなくても、各センサーから入力される信号から次に起こることを予測しているのだという。その予測結果と実際のセンサーからのインプットが異なると「何かが違う」という感覚を発生させるというのだ。

だから、だれかがあたなの家の玄関のドアノブにヤスリをかけてざらざらさせるといういたずらをするとどういうことになるか。

あなたはいつものように仕事から帰宅し、いつもの道を歩いている。目からはいつもの風景が入力されスーパーの次にはラーメン屋が現れる。脳の中ではスーパーを通り過ぎたころからラーメン屋の感覚が予測されているが、予測と目から入力される情報に差異はないため特に何も感じない。何も感じなくても脳は常に働いている。

しかし、自分の家に近づき玄関のドアノブに手をかけた瞬間に「おやっ」という感覚がわき上がる。ドアノブを握る直前に脳が予測した手の感覚と実際に感じた感覚に相違があったため脳がシグナルを送ったのだ。

これと同じような例で、しょっちゅう感じているのが携帯電話のバイブレータによる着信の勘違いだ。自分は会社では常に胸ポケットにPHSを入れている。音が鳴るとうるさいのでいつもマナーモードにしている。自分のPHSの内線番号が呼ばれるとブルブルッと振動する。

先の脳の予測機能は覚醒しているときは常に働いているため、胸ポケットにさしているPHSがカサッと動くと着信したときの感覚が予測・連想され、本当に着信したかのように勘違いしてしまうのだ。

この勘違いは1日に何回か発生する。PHSが胸ポケットの中で揺れたときに着信の振動の予測が想起されたことにより勘違いが起こる。普段、マナーモードにしておかないで着信音による呼び出しにしておけば、胸ポケットの中でPHSが揺れても振動の連想は起こらないはずだ。

このように、人間の記憶は時間的なつながり、すなわちシーケンスによって記憶され、次に起こることを無意識に予測している。

したがって、過去に経験したことのないシーケンスを初めて試みるときは何事もうまくいかない。冒頭で紹介した最後に“え”が付く4文字の単語探しは、最後の文字が指定されているから難しい。最初の文字が“え”の4文字単語なら、“え”を脳にインプットすることで、連想される単語のうち4文字のものを拾っていけばよい。たとえば、“エプロン”、“襟巻き”、“煙突”など、大人でも比較的簡単に思いつく。

ところが、最後の一文字が“え”の単語となると、このシーケンスによる連想が使えない。もしもくふうするなら、最後に“え”が付く短い単語を考えて、これに修飾語を付けるという方法がある。

たとえば“え”＝“絵”と考えて、“絵”に3文字の修飾語を付ける方法だ。絵から単語を連想することはできるので、この方法なら“油絵”を思いつくことができる。“口笛”や“胡麻和え”も同じように“笛”や“和え”を思いつけば、口や胡麻を付けることで4文字単語ができあがる。

『Software People Vol.4』のコラム「人間の考え方，コンピュータの考え方」でも書いたが、自分の経験が積み重なってできたシーケンス記憶と、連想のメカニズムは、自分の中だけにあるものであった、他人のシーケンス記憶とは異なる。

したがって、自分が考える「相手の頭の中」の状態と、実際に相手方のシーケンス記憶の内容が違っているときはうまく意志の疎通がとれないことがある。

このようなときは、双方が共通の認識であるシーケンス記憶の例を探し、その例を使って目的へ導くことが効果的である。

特に抽象的な概念を教えるときにメタファーによる説明が有効なのは、人間の記憶がシーケンスによって刻み込まれており、シーケンスから連想が引き起こされるからに他ならない。

T-Engine に乗ったやつは勝ち組か負け組か？

第9回 組込みシステム開発技術展（ESEC）の基調講演で、TRONの生みの親で、T-Engineフォーラム会長の東京大学 大学院 情報学環教授の坂村健先生の話を久しぶりに聞いた。

歯に衣着せぬ坂村先生の滑舌はいつ聞いても小気味よい。今回印象に残った坂村先生の話は次のようなものだ。

まず、坂村先生が T-Engine を作ろうと思ったきっかけについて。ビジネス系のソフトウェアエンジニアはノートパソコンとネットワークがあればどこでも仕事ができる。仕事場だけでなく、出張先や、リゾート地でさえ特に不自由なくソフトウェア開発が可能だ。それに比べて組込みソフトエンジニアの環境はどうだ。ここで、先生は「組込みソフトエンジニアは劣悪な環境で仕事をしており、士農工商、組込みソフトだ。」と発言し、会場の笑いを誘った。ちなみに、SESSAMEでは組込みソフトエンジニアの地位の低さを「士農工商、メカ、エレキ、ソフト」と表現している。

さて、話を戻すと、坂村先生は組込みソフトエンジニアの仕事の現場の状況を憂い、事務机半分くらいを占めているターゲットボートとインサーキットエミュレータなどをコンパクトにし、手のひらに乗るくらいの大きさの標準的な組込み機器の開発環境を作りたいと考えた。これが T-Engine を作りたいと思った理由の一つだと語っていた。

したがって、T-Engine は組込みソフトの開発環境のことであり、T-Engine のボード自体を組み込むわけではない。この点を勘違いしている人がたくさんいると言っていた。自分も勘違いしていた一人だ。

T-Engine という開発環境で作ったソフトは、T-Kernel で動くターゲットボード上で動かす。ターゲットボートは必ずしも T-Engine の規格に合致している必要はない。SDカードなどのカードインターフェースも必ずしも使う必要はない。

要するに、ビジネス系のソフトウェア開発では当然となった、　IBM-PC, DOS-V規格のハードウェアの流れと Windows の組み合わせという、共通プラットフォームを 組込みソフトの世界でも作ろうということなのだ。

この考え方は CPUのパフォーマンスを最大限に生かすために弱い標準とした TRON からの大きな方針の転換と言える。TRONは性能の最適化を優先させるために、CPUの違いによってはミドルウェアなどの互換性が完全ではなかった。そのために、μITRON上で動くファイルシステムやTCP/IPのプロトコルスタックなどはCPUが変わると、ターゲットCPUに適用させるためにポーティングする必要があった。

このことが、μITRONという共通OSを使っているにもかかわらず、ミドルウェアが普及しなかった理由だ。これによって、ビジネス系のソフトウェア開発のようにソフトウェアの共通部品が簡単にそろわず、作り込みなしにはミドルウェアを実装できないという弊害を生んでしまった。

そこで、T-Engine はインターフェースを強い標準で規定し、ミドルウェアの普及を促して、組込みソフトの開発を加速させるというねらいがあった。

開発環境とミドルウェアのインターフェースが共通であれば、組込みソフトの教育もやりやすいということだ。

もう一つ、今回の坂村先生の話で印象に残ったのは、メーカーが変わることによるCPUのインターフェースの違いを、FPGAで吸収するという話だ。リトルエンディアンやビッグエンディアンといった、バスの違いをもFPGAで吸収するという話だった。ザイリンクスやアルテラといった、FPGAのサプライヤーの協力をすでに得ているとのこと。

さて、ここまでの話で、ひとつ疑問が生じた。組込みソフトエンジニアにとって手に乗る開発環境があり、その開発環境のデバッグがJ-TAGインターフェースでノートパソコンがあればよいとなれば、海辺のリゾート地のホテルのデッキで潮風に吹かれながら、組込みソフトの開発をすることも可能になるだろう。ミドルウェアもポーティングの必要はなくなり、場合によってはオープンソースのミドルウェアを使うこともできる。CPUだって、一社に縛られることなく、ルネサスでもNECでも東芝でも、ARMでも何でもよくなる。

でも、待てよ。よく考えてみよう。この環境が実現されると、組込みソフトエンジニアとビジネス系のソフトウェアエンジニアの違いはいったいなんになるのだろう？

楽になるのはうれしいが、ビジネス系のソフトウェア開発のアプローチと、組込みソフト開発のアプローチが同じになることで、本当に組込みソフトエンジニアは顧客満足を最大にできるのか？

『組込みソフトエンジニアを極める』では、組込みソフトエンジニアが自分のスキルを高めることが、顧客満足を高めることにつながるようにしていけば、組織の目標ともオーバーラップすることができると書いた。

組込み機器においては組み合わせ的アプローチだけでなく、すり合わせ的なアプローチを取ることが、商品の機能、性能を最適することに役立つとも主張した。

坂村先生の T-Engine 構想は、坂村先生がもっとも嫌っている PC+Windows のコンセプトを、組込みソフトで実現しようとしてはいないだろうか？　（坂村先生は、講演のプレゼンテーションに、決してPowerPoint を使わない。使っているのは超漢字だ）

ユビキタス社会が実現すると、どんな組込み機器もネットワークにつながってしまう。そうなると、組込みソフトエンジニアはいままでやらなくてよかった他の機器との通信やセキュリティ対策なども組み込まなければいけない。そんな状況では、これまでやってきたような雑誌や本で勉強し、スクラッチでソフトウェアを作り込むというアプローチでは絶対に開発が追いつかない。

そうなったら、共通プラットフォームと選択可能な豊富なミドルウェアの存在はありがたい。しかし、性能の最適化にはすり合わせのアプローチも必要だ。

ようするに、ユビキタス社会になっても日本の組込み機器が競争優位を保つためには、組み合わせ的なアプローチと、すりあ合わせ的なアプローチのバランスを考えることがもっとも重要になる。

『組込みソフトエンジニアを極める』の全体を通して主張したのは組込みソフトエンジニアはこのバランス感覚を磨くことがとても大事だということだ。

T-Engine 構想は非常にいい、だけれども、PC+Windows との違いを見いだすことができないと、日本の強み、日本の良さを消してしまう危険性もあるように思う。

最後に、坂村先生は、デジタル家電や携帯電話がこぞって Linux をOSに採用しようとしているのは、リアルタイムでないOSをリアルタイムシステムに無理やり適合させようとしている愚の骨頂だと言っていた。

自分もその通りだと思うが、『組込みソフトエンジニアを極める』でμITRON、 T-Engine、 Windowｓ、 Linux を比較したときは、それぞれリアルタイム性を高めた OSを出してきているだけに、慎重にそれらの違いについて書いた。

坂村先生が言いたかったのは、もともとリアルタイムシステム向けではなかったOSをリアルタイムに適応するために無理矢理パッチを当てるのではなく、最初からリアルタイムシステム向けに作ったOSを使った方がいいということだと思う。

それはたぶん、その通りなのだろう。いま多くの家電メーカがLinuxをハードディスク内蔵のDVDレコーダに採用した結果、機動時間が我慢できないほど遅くなっていることにその違いがでていると思う。

では、T-Engine に乗ったやつは勝ち組になるのか？　それは『組込みソフトエンジニアを極める』をマスターしてすり合わせと組み合わせのバランスを取ることのできた者が勝ち組になるはずなのだ。

やっぱりそうくるか・・・