2006-11-26

組込みか組込みでないかの違いはどこにある?

組込みソフトって何だろうと考えていた。組込みシステム(組込みソフト)を定義する試みはたくさんある。

具体的には、携帯電話、自動車、カーナビゲーションシステム、炊飯器、信号機、エレベーター、自動販売機、デジタルカメラ、テレビなどなど、生活の周りにある電気製品のほとんどが組込みシステムだ。

フリー百科事典『ウィキペディア(Wikipedia)によると、組込みシステムの特徴について以下のように書かれている。

【汎用システムに対する組み込みシステムの特徴】
  • ソフトウェアだけでなくハードウェアも専用のものを開発することが多い。
  • 機械の制御を行う場合にはリアルタイム制御が重要になる。
  • 大量生産される製品の場合にはコストが非常に重要となるので、少ない容量のメモリと、安価なCPUで動作する必要がある。
  • ほとんどの組み込みシステムでは、ユーザがプログラムを入れ替えたり更新したりすることは想定されない。そのため汎用コンピュータよりも自由にオペレーティングシステムやシステム構成を選択できる。
  • 多くの場合、ソフトウェアはROMに書き込まれた状態で出荷されるため、出荷後にバグが発見されると、製品回収・ROM交換作業などが必要になり、多大な費用がかかる。近年、ソフトウェアはROMではなくフラッシュメモリに格納され書き換え可能になったが、出荷後の改修が困難なことは変わっていない。
  • ソフトウェアはC言語で記述されることが多い。32ビットマイコンなどの比較的ハードウェア資源が豊富な環境ではC++やJavaが使用されることもある一方で、ハードウェアを直接操作する場面や、4ビットマイコンなどの資源が貧弱な環境では、現代でもアセンブリ言語の使用が必須である。
  • デバッグは、ICEと呼ばれる機器を用いてパソコンをCPUに接続してリモートで行う。近年では、ICEを使わずJTAGエミュレータやROMエミュレータなどのエミュレータや、パソコン上でCPUの機能をシミュレートするシミュレータも使用される。
  • 近年ではPCベースのハードウェアの低価格化に伴い、PCベースのハードウェアを使用し、OSも組み込み向けにカスタマイズしたWindowsやLinuxを採用することも多い。
  • 携帯電話やデジタル家電、自動車など、必要とする機能が多岐にわたるシステムは、複数のマイコン・複数のOSを組み合わせたものとなり、数百人単位の開発人数・数年規模の開発期間を必要とする。このため、大規模組み込みシステムと呼ばれることがある。

逆に組込みシステムではないもの(Wikipediaでは汎用システム)って具体的にはなんだろうか? 一番分かりやすいのはパーソナルコンピュータやワークステーションだろう。

PCの特徴は IBM と Microsoft のおかげで、アプリケーションソフトから見たハードウェアのインターフェースが共通になっているため、アプリケーションソフトの制作者はPCのハードウェアの違いをあまり意識しないでよいという点だと思う。(Mac もMacの中だけで考えれば同じ)

共通のハードウェアプラットフォームがあり、そこへいろいろなソフトウェアをインストールして使える、もしくは、その都度その都度ソフトウェアをダウンロードして使えるようなシステムは汎用システムとなるように思える。

そうすると、現在の携帯電話は電話としての機能は特定の用途を実現するための組込みシステムだが、電話をかけていないときは、インターネットに接続しWEBブラウジングや Java アプリを実行したりできるので、汎用システムであるとも言える。

ゲーム機も同じだ。CDやカセットを入れ替えて共通のコントローラを使って、いろいろなアプリケーションソフトを使うことができる。

そう思っていたら、任天堂の Wii のコマーシャルが流れてきて「ああ、これが組込みの特徴かも知れない」とピンときた。

Wii は何と言ってもWiiリモコンがこれまでのゲーム機にはないデバイスだ。具体的にはモーションセンサと呼ばれる三次元の加速度センサが新しい。この三次元の加速度センタを使うことで、リモコンを上下、左右に振ったり、突き出したりする動きをセンシングしてゲームに取り入れることができる。

これまでのゲーム機は基本的に左手の親指で十字のコントローラを動かし、右手の親指でボタンを押すというインターフェースしか持っていなかったが、三次元の加速度センタを使うことでまったく新しいゲームの遊び方を提案することが可能になった。

ニンテンドウDS のタッチスクリーンとタッチペンも同じようにそれまでのゲーム機にはなかった新しいインターフェースデバイスだった。リモコンに仕込まれた振動装置も新しいデバイスだったがこれはこれまでの環境を劇的に変化させるようなものではなかった。

Wii リモコンを見たときに「これが組込みの特徴かもしれない」と思った。新しいハードウェアデバイスをシステムに取り込むことで顧客満足度を高めることができるのが組込みシステムではないかという考え方だ。

でも、一般的にはパソコンの方がアプリケーションソフトの入れ替えによって用途が無限に広がり、顧客満足を高めるくふうがしやすいように見える。でも、よく考えるとパソコンのインプットデバイスはキーボード、マウス、マイクであり、アウトプットデバイスはディスプレイとスピーカと意外に限定されている。

だからできることのバリエーションの大部分はディスプレイの中だけに閉じている。人間の入力情報の多くは視覚からきているので、パソコンのディスプレイからいろいろな情報を流すことが可能なのだが、人間の生活はディスプレイの中だけに閉じているわけではない。現実の世界はディスプレイの中の世界よりももっともっと広い。

プラットフォームを共通にするということはアプリケーションソフトの入れ替えが容易になるというメリットはあるものの、見方を変えれば「世界を固定する」ことのようにも考えられる。

世界を固定すると言っても、狭く囲う場合と広く囲う場合がある。固定した世界の範囲が広いと、一見そのプラットフォームで提供できる世界が無限に広がっているように見えるが、システムを作る側も利用する側もそう思い込んでしまうと、実際の世界はどんどん広がっているのに、固定された世界の中しか商品や市場を見ていないということになりかねない。

今回の任天堂のWii を見てそう思った。Wii の登場で、PS3やX-BOXは一見無限に広がっていそうな固定された世界で勝負しようとしていて、現実世界の広さを見失っているように思えてきた。

この話は「洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない」の記事で書いたことに共通する。現行機種と現行機種の使われ方だけを見ていると、真のユーザーニーズや、デバイスの制限でできていなかったことをすっかり忘れてしまう。

ハードウェアデバイスは常に進化している。自分たちの市場とはまったく関係ないところで開発されたデバイスが、思いもよらないところで役に立ったりする。Wii のモーションセンサもITmediaの記事によると、もともとは自動車のエアバッグを作動させるときのために開発されたセンサらしい。

そう考えると、組込みシステムが相手にする世界は非常に広く、現行製品にありとあらゆるデバイスを取り入れることで、その市場における顧客満足をより高める製品に進化させる可能性があるように思う。

そうなると、組込みソフトウェアエンジニア側も、どのようなキーデバイスが取り込まれて、開発環境もどう変化するのか分からないので常に柔軟な対応が迫られる。

逆に言えば、あらゆる未知のデバイスを使いこなせるスキルの下地があればその市場において非常に競争力の高い商品をアウトプットできるようになる。

組込みか組込みでないかの違いは「世界を固定するかしないかの違い」であり、組込みは世界を固定しないだけに技術者に求められるスキルも多様であり、挑戦者にとってのやりがいが大きいと考えるのはどうだろう。

 

2006-11-18

組込みソフトウェアの安全設計

先週、電気回路設計から学ぶ組込みソフト設計という記事を書いた。しかし、たった一週間で考え方を転換しなければいけなくなった。

なぜなら、今週宇宙航空研究開発機構(JAXA) が開催したクリティカルソフトウェアワークショップ(WOCS2006)の中で、マサチューセッツ工科大学のナンシー・レブソン教授の講演を聴いたからだ。

MITのナンシー・レブソン教授は、左の SAFEWARE という本を最近出版した。(日本語版の予定はまだない)

ナンシー・レブソン教授は日本ではほとんど知られていないと思うが、ソフトウェアの安全設計の分野では非常に有名な方で、1980年代から今日に至るまで、アメリカでソフトウェアで安全性の関する大きな事故があると呼び出され調査をし論文やレポートを出してきた。書かれた論文はすでに100を越えている。スペースシャトルコロンビア号の事故など航空宇宙関係のソフトウェアがらみの事故調査やミサイル防衛システムの安全設計に関する研究などもしている。

ナンシー・レブソン教授は口が悪いことでも有名で、自分の経験上でソフトウェア安全のためにマイナスの要因があると感じたときには、はっきりと NO を突きつける。

WOCS2006のパネルディスカッションで、シンドラーのエレベータの安全対策についてパネリストたちがディスカッションしていたとき、ナンシー・レブソン教授は、「自分はエレベータの安全対策について研究したことはまだないが、独立した安全装置の設置は、もっとも安直な対策であり愚かな選択だ」と切って捨てた。(国土交通省主催の事故検討委員会では独立した安全装置の設置を義務づける方向に動いているらしい)

ナンシー・レブソン教授は独立した安全装置の設置対策が本来正しく動くべき基本機能の不具合を見えなくしてしまう危険性を指摘していた。威圧感があり、きっぱりと NO というので曖昧だった部分について再考すべき点が浮き彫りになってくる。

さて、なぜ先週「電気回路設計から学ぶ組込みソフト設計」の記事の中で、組込みソフトの設計も電気回路設計から学ぶべきことがあるといったことを、今週方向転換しなければいけなくなったのかを述べたい。

それは、付け足しのように書いた「組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える」という記述は実は組込みソフトのメリットでもありデメリットでもあり、この問題を避けて通ることはできないから、電気回路設計の方法をそのまま持ってくることはできない、電気回路の設計方法を持ってくると失敗する可能性が高いと気づいたからである。ソフトウェア部品の信頼性を高めて組み合わせるとシステムの信頼性が高まるという考え方は機能安全(IEC61508)の考え方に近く、ナンシー・レブソン教授はIEC61508を「役に立たない」と言っていた。

電気回路設計から学ぶ組込みソフト設計の記事で参考にすべきと書いた「ソフトウェアを部品化して完成度を高めつなぎ合わせる」という考え方は、ハードウェアの設計をベースに考えられており、ハードウェア設計を長年やってきた人が最初に考えうる発想である。

ナンシー・レブソン教授の話を聞いていて「そこには落とし穴があり」25年の歳月の間、エンジニアはこの落とし穴に落ちることで事故を起こしてきたと言っているように感じたのだ。

「組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える」ということは組込みソフトウェアが生まれたときからこれまで変わっておらず、ソフトウェア部品が増えてきて、それらの部品を利用することが多くなってきたことは事実だが、今後も組込みソフトウェアのすり合わせ的な要素は決してなくらなないと感じる。

そうすると、ソフトウェアを部品化して、完成度の高い部品を組み合わせてシステム全体の安全性や信頼性を高めるという考え方は、こと組込み機器の安全という視点で考えたとき非常に危ないような気がしてきた。

そもそも完成度の高いソフトウェア部品を作るのは時間もコストもかかるし、ソフトウェアは変更しやすいだけに5年も10年もソースコードに手を入れないで使い続けることはほとんどないだろう。もともとソフトウェアは必要に応じて姿形を自由自在に変えることができることが特長であるのなら、完全に固定してしまおうと考えること自体にムリがあるように思える。

だからといって部品化の努力は無駄だとは言わない。再利用可能な資産としてソフトウェアのモジュールを特定し、インターフェースを明確にし、信頼性を上げておくことは、システムの安全性を高めることに必ず貢献する。しかし、システムの安全性はあくまでも、システム全体の安全設計、安全アーキテクチャを考えた上で成り立つのであって、システム全体の安全設計、安全アーキテクチャが十分に考えられていない状態で信頼性が高い思われる部品をつなぎ合わせたのでは、結果的に安全にはならない。コア資産として特定したソフトウェアモジュールはインターフェースは変えないでおいて、中身をブラックボックスにせず常によりよく進化できるようにしておけばよいのだ。

【クリティカルソフトウェアの設計指針】
  1. ユーザー要求や安全要求を考えソフトウェアシステムのアーキテクチャを設計する
  2. ソフトウェアのサブシステムの信頼性を高める努力をする
  3. 最初に考えた設計思想が崩れていないことを開発ライフサイクル全体に渡ってチェックする
このクリティカルソフトウェアの設計指針で大事なのは順番で、2が1より先に来てはいけない。先週の電気回路設計から学ぶ組込みソフト設計の記事では2が強調され、1が置いていかれてしまう危険性があると思ったので今週違う見方を書いた。

WOCS2006でJAXAの片平さんがクリティカルデバイスのソフトウェアを設計する日本のソフトウェアエンジニアにとってとても参考になる講演をされた。(講演資料はしばらくすると JAXAのWEBサイトからダウンロードできるようになる)

最後に片平さんに向けて発信したメールの内容を添付する。

【安全文化について。酒井発信のメールより引用】

さて、WOCS2006の片平さんのスライドで、次の考え方は直感的に「正しい」と思いました。

-ソフトウェア安全確保のための重要な要素-

   □    Design & Verification
  □□□   Methodologies & Techniques
 □□□□□  Rules/Regulations
□□□□□□□ Safety Culture

※Rules/Regulations:Rules/Regulations for Safety Critical System development

安全文化がベースにあるべきだというのは“直感的に”正しいと感じます。しかし、Safety Culture という表現は非常に曖昧で具体的に何をすればよいのか分かりにくいとも感じます。

たとえば、協力会社にソフトウェア開発を委託したり、多人数でソフトウェアを開発するときに何をすべきかということです。

私たちは経験的に協力会社にソフトウェア開発を委託するとき持ち帰り仕事を嫌います。持ち帰られると、開発品がどんな用途で使われ、どんなユーザーリスクがある製品が知らない者がプログラムを書くことがあるからです。(実際にこれは危険だという感覚だけあります)

また、派遣も含むプロジェクトメンバーで新しい人が入ってきたら最初の段階で必ず実施するのは、この製品が用途で使われ、どんなユーザーリスクがあるか、そしてその人が作るソフトウェアのパートは、どの部分なのかということを完全に理解するまでレクチャーするということです。これも直感的にそれがソフトウェアの安全性を確保するのに一番近道だろうと考えるからだと感じます。これは、上の積み木でいえばまさしくSafety Culture を新しい技術者に伝えたということになります。

Design & Verification や Methodologies & Techniques やRules/Regulations にほころびがあっても Safety Culture が伝わっていれば、穴は小さくなるだろうという経験的な直感からそうしています。

でも、これには限界があり、ソフトウェアの開発規模が大きくなってきたら開発者全員に安全文化を行き渡らせるのはむずかしくなります。(特にオフショア開発などの場合)

開発者が何十人にもなると「今日の昼ご飯は何だろう?」などポケッーと考えながらプログラムを書く者も出てくるでしょう。

実際、これが一番危ないと感じるので、素性がよく分からない人には製品のソフトウェアは作らせず、検査用のソフトウェアや実験用のソフトウェアを作らせます。でも、こんなやり方は小さいプロジェクトだからできるのであり、大きなプロジェクトでは難しいと思います。

実際、サプライヤーに対して納品対象のソフトウェアに静的な解析をかけ、一定の成績が出ない場合は検収を挙げないという方策をとっている会社もあると聞きます。

これだけ聞くと、Safety Culture の伝達なしでも、Design & Verification や Methodologies & Techniques や Rules/Regulations でソフトウェアの安全性(この場合信頼性か?)は確保できるように思いますが本当にそうでしょうか?

安全文化を伝えることができない場合は、システム全体のアーキテクチャを安全設計にし、そこで押さえる、そうすれば、グレーボックスのモジュールがあっても、システムの構造でリスクを抑えることができるという考え方が正しいのではないでしょうか。

Safety Culture は人間の曖昧さをポジティブに考えたときの施策で、Design & Verification や Methodologies & Techniques や Rules/Regulations は人間の曖昧さをネガティブに考えたときの施策のように感じます。

人間の曖昧さをポジティブに考えるというのは非常に日本的であり、うまくいけば効果は高いという感覚があります。しかし、対策も曖昧になりがちであるというのも事実です。でも、それぞれのドメインによって違いはあるにしても、安全設計のアーキテクチャというものが存在するのなら、これまではエンジニアの頭の中だけに存在していたアーキテクチャを表に出し継承することができれば安全設計を構築できるようになると思います。

エレベータの独立したソフトウェア安全装置を設定するというモデルは、そのような安全設計アーキテクチャの一つであり、エレベータシステムというドメインでは有効性はあるように思います。Prof. Nancy Leveson は「自分は、エレベータシステムについて調査したことはないけれども、独立した安全装置の設定はもっとも安直な考え方だ」と言っていました。

この「エレベータシステムについて調査したことはないけれども」というところが重要であり、この言葉の裏には、安全対策・安全設計はそれぞれのドメインで異なるということも言えるのだと思います。

だから独立した安全装置のような、どのシステムにも効きそうな対策は安直だという論理につながりますが、実際ドメインによっては独立した安全装置が有効な場合もあるのではないかと感じました。

Safety Culture の重要性を主張するには、Safety Culture の定義と、Safety Culture を伝達するためには何をすればよいのかについて明確にしておかなければいけないと思います。

結果的には曖昧な話になりそうですが、Safety Culture がなければ、安全につながるアーキテクチャを設計することはできない。それぞれのドメインに最適化した安全設計、安全アーキテクチャが確立することが、システムを安全に導くことに有効であるという論理に結びつけることができればいいと思います。

日本のエンジニアは安全文化からドメインに最適化した安全設計、安全アーキテクチャを作り出す能力が高いのではないかと感じます。

裏返すと、その特性をよく考えずに、Design & Verification や Methodologies & Techniques や Rules/Regulations だけに着目すると、安全文化が置き去りにされ逆に安全性が損なわれる可能性がある。

また、Safety Culture の伝達が効くのは日本人の国民性に起因する何かがありからで、海外でシステムの安全を確立する際に Design & Verification や Methodologies & Techniques や Rules/Regulations に力が入るのは日本人の国民性に起因する何かの存在(職人魂、クラフトマンシップ?)を勘定にいれないからではないでしょうか。そう考えると、自分の経験的な直感に近づきます。

【引用終わり】

製品開発に長いこと従事して切磋琢磨している日本の組込みソフトエンジニアは、欧米人に上手く説明できなくても「この製品の信頼性や安全性は高いんだ」という自信がある。

これは根拠のない自信ではない。ちゃんと根拠はあり、その根拠はすでに製品のソフトウェアシステムに実装されている。だから、製品の信頼性や安全性が高いという根拠であるソフトウェアシステムのアーキテクチャを示すことができればシステムの安全性や信頼性について説明できるはずなのだ。

これからの日本の組込みソフトエンジニアはソフトウェアシステムの設計において、どんなアーキテクチャを考え、そのアーキテクチャが製品の信頼性や安全性にどのように効いているのかを説明できるようにならなければいけない。

みんないい製品を作る技術を持っているのに、それがどんなしくみでできているのか説明できないだけなのだ。

また、そのいい製品を作る“しくみ”(アーキテクチャ)はユーザーニーズや装置に求められる安全性、ハードウェアデバイスやソフトウェア開発環境など、製品や製品群の隅々を知り尽くした技術者が設計できるのであり、ソフトウェアシステムの規模の大きくなった現在では、優秀なアーキテクトが考えた設計思想・アーキテクチャを継承するということも考えていかないと開発が追いつかないというところまで来ている。

------ その後 -------

この後、JAXAの片平さんから上記のメールに対する返信をいただいた。私信なので一部これは多くの人に伝えた方がよいという部分だけ紹介しようと思う。(自分はアーキテクトなのでアーキテクチャに目がいきがちだが、安全はアーキテクチャだけで作り上げるものではないということが分かる。)

【片平さんからの返信から】

  :
  :

システムレベル(トップダウン)の安全の考慮が重要であるという考えは、 「もぐらたたき」にならないようにするために重要と思います。 ここは日本のこれまで不得意とする部分かなという印象を持っています。

安全文化を伝えることができない場合は、システム全体のアーキテクチャを安全
設計にしそこで押さえる、そうすれば、グレーボックスのモジュールがあって
も、システムの構造でリスクを抑えることができるという考え方でよいのではな
いでしょうか。
システムレベル(ユーザに利用シナリオを含む)で対処すべき安全対策もありますし、 装置の詳細な設計、コード上の対策が必要で、アーキテクチャだけで押さえ込む ことはむずかしいと感じています。

-安全文化の定義について-

1) 開発側の安全文化
  ・ルール(安全審査)や安全要求などに裏づけられるエンジニアの基本思考
  ・経営者の安全確立のための意識(具体的には組織体制、資金、コミットメント)
  ・現場の文化構築(教育、経験により構築できるもの)

2) 社会的な文化
  ・利用者側の意識(安全に対する理解、犠牲の許容)
  ・過剰なプレッシャーの排除
  ・安全上Noと言ったときの理解

日本人の得意とするところだとも思いますが、上記に記述した安全文化に関して、 安全に対する理解、風土といったものが、日本にあるかというとかなり 疑問があります。 日本人がドメインに最適化した安全設計、安全アーキテクチャをつくりだす能力が 高いというのは同感です。安全設計、安全アーキテクチャの確立は、 Design & Verification のレベルの話で、Methodologies & Techniques やRules/Regulations をそれを下支えするものと信じてます。

安全文化に関しては、おそらく、日本と欧米とでは効かせ方が異なる、と思ってます。 欧米はルールを決めてギシギシやらないと安全文化が崩壊しやすい。それに対し、 日本では理解が高まり、根付けば、うまくいく可能性がある。と思います。

【引用終わり】

「 欧米はルールを決めてギシギシやらないと安全文化が崩壊しやすい。それに対し、日本では理解が高まり、根付けば、うまくいく可能性がある」というところで読者のみなさんはうなずいているのではないかと想像する。

 

2006-11-11

電気回路設計から学ぶ組込みソフト設計

組込みプレス Vol.5が発行された。この号で是非読んでいただきたいのは「文系エンジニアのためのハードウェア講座-電子回路を読む-」だ。

この記事、決して文系エンジニアのためだけではなく、理系の組込みソフトウェアエンジニアにもじっくり読んでみるとよい。

おそらく組込みソフトエンジニアでも回路図を読む機会のないソフトウェアエンジニアは「自分には関係ないや」と思うかもしれないが、それはこの記事の見方を少し変えてみれば違った発見があるはずだ。

その違った発見について書く前に、自分の電子回路との接点について振り返ってみたい。

入社5年目くらいのことだと思う。組込みソフトウェアエンジニアとしてアプリケーションソフトを書き続ける日々が続いた後、CPU周りの電気回路の回路図を書く機会があった。電気系のCADの導入が始まったばかりで採用が決まったCPUのデータがCADに登録されておらず、CPUのデータブックを見ながらピン番号と信号名を入力してくれと電気系の技術者の頼まれたのだ。

電気系CADの使い方を覚え、ピン番号や信号名を入れていくうちにだんだん回路図を書くのがおもしろくなってきた。すでに登録してある部品は部品番号を入れるとその部品の回路がCADの画面にパッと表れる。そして、使用する部品をあらかた画面上に表示させておいて、信号線をつないでいくという作業はとても楽しい。

ちなみに、このときから10年以上たって、UMLツールでモデリングするときのこの電気系の回路図を書いていたときと同じようなおもしろさを感じた。

ただ、初めて電気回路の作図に挑戦したとき実際に書けたのはCPUとROM、RAM、拡張ポート、SCIの石などとの接続だけで、電源周りやアンプなどの回路については書けなかった。

「文系エンジニアのためのハードウェア講座-電子回路を読む-」を読んで、組込みソフトエンジニアとしてのキャリア20年間でなんとなくデジタル回路を書く電気屋さんが普段やっていることで「なんでそうなっているのか分からなかった」ことや、「そんな方法もあったのか」といったことがいろいろ解き明かされた。

たとえば、スイッチ入力で起こるチャタリングはコンデンサでもある程度押さえられるということ。

また、通常のオペアンプは電源電圧まで振幅を振ることができないが、Rail to Rail のオペアンプは電源電圧近くまで使えること。(Rail to Rail ということばを電気屋さんがよく使っていたが、何のことだか初めて分かった)

プリントP板上でICの近くに必ず配置されている青い小さなパスコンと呼ばれるコンデンサ、このコンデンサはデジタルICの出力パルスが切り替わる瞬間に発生するスイッチングノイズを押さえるためにICと近くの電源とグランド間に設置し、ICが電流を流したときにこのコンデンサにたまっていた電気を放電して供給することで対応していたということなどなど。

この記事には、デジタル電気回路の実践的設計に関するノウハウがたくさん書かれている。そういう意味では、電気屋さんが基礎をおさらいするときにも役立つだろう。

組込みソフトエンジニアがこの記事を熟読して、渡された回路図の間違いやこう直したほうがよいという点を指摘できるとかっこいいかもしれない。

さて、組込みソフトエンジニアでも回路図を読む機会のない、読む必要がないと考えるソフトウェアエンジニアが、「文系エンジニアのためのハードウェア講座-電子回路を読む-」の記事をどう読んだらよいのかについて考えたい。

実は、デジタル回路を設計するアプローチについてよく考えてみると、巨大化した組込みソフトウェアの海で喘いでいる組込みソフトエンジニアの救いの船が見えてくるのだ。

--- (a) --- デジタル回路を設計する電気系エンジニアのアプローチ

デジタル回路を設計する電気系のエンジニアはまず、電気回路の基礎(電源やトランジスタの仕組みなどなど)を学んだのち、自分たちが使う分野の部品についての調べる。

電気部品は自分で作るのではなく、市場に供給されている部品から必要なものを選ぶ。部品にはデータシートが付いていて、その部品の仕様、実装するときの例、入力や出力の Max値、Min値、Typical値などが書いてある。

電気系のエンジニアはこのデータブックに書いてある情報をよく読んで、必要な部品を選別し、目的の回路を組み上げていく。場合によっては、既存製品のある機能をつかさどる部分の回路をそっくりそのままコピーして使うこともよくある。でも、前の製品に使われた回路の設計思想をよく考えずにコピーしたりすると、うまく動かなかったり、最悪の場合回路が壊れたりするので、中身の構造を理解しないで既存の回路図をコピーするような新人がいると先輩は「データシートを見て、なぜそのような回路構成になっているのかよく考えて使え」と怒る。

このような電気系のエンジニアが回路図を作るアプローチと組込みソフトエンジニアのアプローチの違うはなんだろうか。それは“部品”の存在だ。デジタル回路の世界では自分ではない他人が作った“部品”が存在しており、これらの部品にはデータシートがあり、制限事項が書かれており、品質が保証されている。ごくまれに不良品やデータシートには書かれていない制限があったりするが、データシートを読み込んでいれば問題が起こる確率は非常に低い。

そして部品を組み合わせて目的の機能を満たす回路を設計する。同じ部品を使っているとその部品を使うノウハウがたまってくる。

たとえば、同じような部品を使っていると「ブラシ付きのDCモータが回転するときは整流子とブラシの間で火花が発生し、ノイズを誘発するので、モータの端子間に0.001μF程度のコンデンサを接続し、ノイズが外部に出るのを防ぐとよい」といったノウハウだ。

--- (a)'---

ある意味、組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える。しかし、融通が利かないのは流通する部品の数が少ないときであって、いろいらな種類の部品が入手可能な状況でそれらの部品のインターフェース仕様が事前に分かっていれば、それほど不自由はない。

だから、この話をソフトウェアの世界に置き換えると 21世紀の巨大化した組込みソフトウェアの世界では、ソフトウェアもハードウェアの“部品”に相当するソフトウェア資産(部品)があると有利なことがわかる。

(a)から(a)'までの部分を、ハードウェア部品から再利用可能なソフトウェア資産に置き換えてみよう。

--- (b) --- 巨大化した組込みソフトウェアの設計アプローチ

組込みソフトエンジニアはまず、組込みソフトに関する基礎(プログラミング言語や、割り込み、OS、ドライバの作り方)を学んだのち、自分たちが使う分野のあらかじめ用意されたソフトウェア再利用資産(部品)について調べる。

ソフトウェア部品は自分で作るのではなく、すでに用意されている部品から必要なものを選ぶ。ソフトウェア部品にはデータシートが付いていて、そのソフトウェア部品の仕様、インターフェース仕様、実装するときのパターンの例、制限事項などがなどが書いてある。

組込みソフトエンジニアはこのデータブックに書いてある情報をよく読んで、必要なソフトウェア部品を選別し、目的の機能・性能を満たすためのモデルを組み上げていく。場合によっては、既存製品のある機 能をつかさどる部分のモデルをそっくりそのまま、コピーして使うこともある。でも、前の製品に使われたモデルの設計思想をよく考えずにコピーしたりする と、うまく動かなかったり、最悪の場合機能や性能を満たすことができなくなるので、モデルの設計思想を理解しないで既存のモデルをコピーするような新人がいると先輩は「ソフトウェア部品のデータシー トを見て、なぜそのようなモデル構成になっているのかよく考えて使え」と怒る。

ソフトウェア部品は自分ではない他人が作った“部品”であり、これらの部品にはデータシートがあり、制限事項が書かれており、品質が保証されている。ご くまれにソフトウェア部品にはバグが混入していたりするが、データシートを読み込んでいれば問題が起こる確率は非常に低い。

そしてソフトウェア部品を組み合わせて目的の機能を満たすモデルを設計する。同じようなモデルやパターンを使っているとそのソフトウェア部品を使うノウハウがたまってくる。

--- (b)'---

しかし、(b) には (a) とは違った難しいところがある。まず、ソフトウェア部品は多くの場合他人が作ったものではないし、インターフェース仕様や制限事項が書かれたデータシートに相当するドキュメントがあることは少ない。品質が保証されているかどうかも分からないし、問題が発生してもバグの修正を保証してはくれない。バグを修正するのは自分だったりする。

また、ソフトウェアを部品化できたとしても実際には、RTOSなどを使いひとつのCPUで疑似的に並列で動くだけなので、他のソフトウェア部品から影響を受けてしまう。メモリリークなどが発生するとソフトウェア部品としての独立性を高めてあったとしても動けなくなってしまうこともあるだろう。

また、組込みソフトのソフトウェア部品はCPUパフォーマンスやメモリ資源のことを何も考えずに設計し、つなぎ合わせていくと制限をクリアできずに破綻してしまうことがある。

だから、ソフトウェア部品を組み合わせて配置しても制限をクリアできるような、フレームワークやアーキテクチャの設計ができていないといけない。また、このようなフレームワークやアーキテクチャは、製品や製品群によってそれぞれ異なるので一般的なものは存在しない。

だから、再利用可能なソフトウェア資産を作ることができたとしてもハードウェア部品を組み合わせるように簡単にはいかない。

でも、巨大化した組込みソフトウェアを効率よく開発できるようにするには、このようなハードウェア部品を組み合わせて目的を達成するアプローチを見習わなければいけない。

そうすれば、ソフトウェア資産を使うノウハウがたまり、組込みソフトウェアもどの資産をどうやって使えば効率的に開発できるのかわかるようになる。そのドメインに特化したデザインパターンが構築され、そのコンセプトがプロジェクトや組織の中で継承されていくということだ。

「文系エンジニアのためのハードウェア講座-電子回路を読む-」を読みながら思い浮かんだのは、デジタル回路設計ののアプローチは、組込みソフトエンジニアの問題を解決するのに役に立つということだった。

ところで、デジタル回路の世界では FGPAなどのプログラマブルなロジックデバイスがよく使われるようになってきた。このようなプログラマブルロジックデバイスはCライクな高級言語を使って動作を記述することもできる。ということは、これまで部品を組み合わせてデジタル回路を作ってきたハードウェアエンジニアが我々の“何でもあり”の世界に入ってきたということになる。

ハードウェアエンジニアは(わざわざ苦労しに)組込みソフトの世界入ってこようとしており、組込みソフトエンジニアはハードウェア設計のアプローチを学ぼうとする。

隣の芝は青いということか・・・

2006-11-05

仕事と教育そして自分の知らない世界を知ること

11月3日 文化の日、テレビ番組を3本見た。1本目は NHK 特集あしたをつかめ 平成若者図鑑 「職人になる!」~建設現場の夏~。2本目は、フジテレビ 金曜プレステージ 「泣きながら生きて」、3本目は NHK教育テレビ ETV特集 「いいもんだよ、生きているって」夜回り先生 水谷修

(ちょっとこじつけもあるが)これら3本に共通しているテーマは「教育」だ。

まず1本目のあしたをつかめ 平成若者図鑑 「職人になる!」~建設現場の夏~。

この番組は、東京都内の巨大なビルを建設する現場の職人の働きぶりを追ったドキュメンタリーである。ビル建設の現場では、鳶(とび)、左官、鉄筋工、墨だし工、電気工、内装工、防水工、配管工、塗装工など、いろいろな職種の職人達がそれぞれの役割を果たしながら建物の完成を目指す。

番組の中で印象的だったのは19歳のALC工の若者だ。ALCとは「オートクレーブトライトウェートコンクリート」の略で、オートクレーブトは気泡、ライトウェートは軽量を意味し、軽量気泡コンクリートの事を指す。ビルの枠組みができたあと、ALC工はALCの長細い板で各階の部屋の壁を仕切っていく。軽量コンクリートとはいえ、一人で持てるほどの重さではない。職人何人かが手伝わないとALCの板を立てることはできない。番組の中では一つの階のエレベーターホールをACLの板で囲うのにまる1日を費やしていた。

ALCの職人の親方は年季の入ったベテランで、10種類以上の工事関連の免許を持っている。19歳のALC工の若者は他の職場で数年ALCの仕事をしたあと、この親方のもとに移ってきた。

親方は、若者がALCの仕事についてちっとも学習してきていないことに嘆きつつ、本来なら自分でそろえるべき道具一式を親方がホームセンターで買って与えていた。

19歳のALC工の若者は、最初のうち四六時中親方に怒られていた。一つのことがうまくできなかったりするのはまだしも、後片付けしないで仕事を上がってしまったときは、親方も怒り心頭に発していた。

19歳のALC工の職人は怒られながらも黙々と仕事を続ける。カメラは仕事が終わって帰宅する19際の職人の家を写している。そこには、生まれたばかりの赤ちゃんがいて、2つ年上の奥さんが夕飯の支度をしていた。

この若者は子供が生まれたことをきっかけにして、ALC工の親方のもとに弟子入りし、家族のために働くことを決めた。口の重い彼が、自宅で次のように語っていた。「自分は怒られているばかりだけど、何か悪いのか、何をしなければいけないのか、言ってもらわなければ分からない。」「何か疑問に思えば、尋ねることもできるが、疑問に思わないから質問もできない。」「だから、できていないことは言われなければわからない。」

彼はやる気がないわけではない。ALC工としての技術を磨きたいという意欲はある。ただ、しゃべりがうまくないのと、今の親方のようにいろいろ教えてもらう機会に恵まれていなかっただけなのだ。

カメラはまたビルの建設現場に舞台を移し、ACLの板を天井に金具を使って溶接で止める作業をしている親方とそれを見ている若いALC工の姿を写している。

そこで、19歳のALC工が親方に「自分にやらせてくれ」と言う。その後、19歳のALC工はなんとか溶接をこなし、次の場面では「仕事がおもしろくなってきた」とつぶやく。

親方も「最近、ミスが減ってきたのは仕事がおもしろくなってきて、もっと上手くなろうという意欲がわいてきたからだろう」「仕事がおもしろいと感じるようになれば上達も早い」と語っていた。

自分は教育・学習の原点とは、この「何かを達成したい」と「そのために学びたい」が結びつき、その結果「楽しい」「おもしろい」「うれしい」につながることだと思う。

19歳のALC工は、新しい家族が増え家族を養うためにきちんと定職に就きたいと思った。
→「何かを達成したい」

そのために、親方のもとでACLの技術を学びたいと思った。
→「そのために学びたい」

そして、徐々に技術が身につき始めミスが減り、仕事ができるようになった。
→「楽しい」「おもしろい」「うれしい」

非常にシンプルな好循環のサイクルだ。そのサイクルをぐるぐる回していけば熟練工になることができる。しかし、実際にはこのようなサイクルでは済まない複雑な仕事はたくさんある。自分が「何かを達成したいために学びたい」と思っても、つまらない理由からストップがかかることも少なくない。

たとえば、開発効率を高め、ソフトウェア部品の再利用率を上げたい、だからオブジェクト指向設計の技術を学びたい、外部セミナーを受講させて欲しい、このような技術者がいたとする。ところが、この技術者の上司にとっては、まったく未知の技術であり自分の知らないことを学習されて先を越させるのはイヤだという心理が働き「まだ早い、やめとけ」と言われるかもしれない。

ガテン系のようにスキルが外に見えてこない場合、つまらないことでつまずくことは多い。でも、仕事をする上で何かを学ぶということのベースにあるのは、「何かを達成したい」→「そのために学びたい」→「楽しい」「おもしろい」「うれしい」の流れではないだろうか。

○○のための学びたい、の○○が明確でない学習はむなしいし、あまり身につかない。それよりも何よりも楽しくない、おもしろくない、うれしくない。

-----------

2本目に見たテレビ番組は涙なしには見られない内容だった。

【フジテレビ 金曜プレステージ 「泣きながら生きて」 毎日新聞 視聴室より】

こんな父親がいたのか!

上海に妻と一人娘を残して、1989年に35歳で日本に留学に来た中国人、丁尚彪(てい・しょうひょう)さん。当初の夢破れ、やむなく東京に不法滞在。15年も朝から晩まで働き、ひたすら家族へ送金を続けた。命を削るような貧乏・節約生活に耐えることができたのは「娘の希望する米留学を実現させてやりたい」一心からだ。こんなにも、自分を犠牲にしてまで家族のために尽くせるものなのか。

96年から、この家族を追い続け、2時間余りに凝縮したドキュメント。「小さな留学生」などで、日本で生きる中国人のさまざまな生態を活写した張麗玲さん、それをサポートしたフジテレビの横山隆晴プロデューサーの作品。過酷な運命に愚痴を漏らさず、日本に感謝しながら帰国した丁さんの実直な目が、日本人が忘れた者を気づかせてくれる。

【引用終わり】

この番組途中から見たので、丁さんが日本に来たいきさつについては見逃した。丁さんは日本で清掃関係の仕事を3つ掛け持っていて、風呂のない早稲田の古いアパートに住んでいた。毎日帰りが深夜になるため銭湯が開いていない。そのため、丁さんは流しで温水器を使って頭を洗う。体はどうするのだろうと思ったら、巨大なビニール袋を取り出して、この中に入って温水器でシャワーを浴び、たまったお湯を流しに流すのだという。夕飯につくったおかずは明日の弁当のおかずにもする。

丁さんの奥さんは、上海の縫製工場で黙々と働いている。娘はニューヨークの大学で医学を学んでいて、丁さんの奥さんは13回目にやっとビザ申請が通り、ニューヨークの娘に会いに行くところだった。

飛行機の予約をくふうして、トランジットで72時間だけ東京での滞在が許された。この72時間の間に夫と会うのだが、なんと夫に会うのは13年ぶりだというのだ。

丁さんは、13年間上海に帰らなかった、いや、帰れなかった。家族がバラバラで過ごしている理由は、おそらく清掃の仕事でも東京で働いていた方が上海で働くよりも稼ぐことができ、多くのお金を送金できるからだろう。

そこまでして、丁さんが日本で働く理由を丁さんが語っていた。丁さんは十分な教育を受けておらず、祖母は字が読めなかった。日本への留学もおそらく技術を身につけて自分でしかできない仕事がしたかったのだろう。自分ができなかった夢を娘に託して、娘には教育を受けさせ、そして、仕事としてやりたいことをさせてやりたかったのだ。

そのために丁さん夫婦は自分たちが贅沢なことを一つせず、こつこつとお金を貯めることを選んだ。

丁さんの奥さんが一つだけ贅沢をしたのを見た。それは、ニューヨークの娘に会いに、東京の夫に会いに行く前の日、仕立ててあった服を近所の洋服店に取りに行き、美容院で髪を整えにいったときだ。でも、ぜいたくは本当にそれだけだったのだ。

丁さん夫婦は東京で再会し、72時間だけ一緒に過ごし、その後奥さんはニューヨークに発った。

番組の最後で、ニューヨークの娘さんは大学の医学部を卒業間近で、産婦人科の医師になることが決まっていることを伝えていた。

娘が医師になることが決まり、丁さんは日本での役目を終え上海に戻ることを決め、上海行きの飛行機に乗っているところで番組は終わった。

この話では「何かを達成したい」→「そのために学びたい」→「楽しい」「おもしろい」「うれしい」という流れとはまた違った、もっともっと重い教育に対する思い入れを持った人がいることに気づいた。

学びたいのに学べなかった自分の夢を自分の子供に託すために自分は犠牲になっても人の倍働こうという人が世の中にはいる。

実際丁さんは、日本で清掃などの特殊な技能を必要としない仕事を3つも掛け持っていた。たぶん、娘には知識や技術を持たせ自分のようにはさせたくないと考えたのだと思う。

もちろん、娘は両親がそれだけの苦労をしていることを知っていて、決して医者になる目標を捨てないという強い意志を持って学業に励んでいた。

この話を聞いてしまうと、「何かを達成したい」→「そのために学びたい」→「楽しい」「おもしろい」「うれしい」はもともと安定した地盤の上にいる我々の甘い考えのようにも見えてしまう。

広い世界の中には「学ぶ」ことに人生をかけている人もいる。

カルロス・ゴーン氏が言った「働くことの本質は貢献することである」は丁さんの話にも通じている。

-----------

さて、3本目の番組はETV特集 「いいもんだよ、生きているって」夜回り先生 水谷修である。

夜回り先生 水谷修さんは、渋谷の町などをパトロールしたむろしている少年・少女に声をかけて回る先生だということは知っていた。でも、水谷先生が自らものすごい経験をし、危機的な状況に陥ってしまったこどもたちをストイックなまでに救おうとしていることは知らなかった。

水谷修さんは、3歳のときに両親が離婚し、祖母・祖父に育てられた。いったん決めたことはやり遂げないと気が済まない性格で、自分で決めた範囲の勉強ができないことを悔やんでリストカットしたこともあったそうだ。(水谷さん曰く、リストカットは死ぬためにするのではなく、生きるためにしていることが多いのだろうだ)

水谷さんが話すエピソードはどれも重い話でおいそれとは書けない。

水谷先生のホームページがあるので、ここから情報を得て欲しい。

番組では、水谷先生が中学校で講演している内容に、江川紹子さんが水谷先生にインタビューしているところ挿入されて流れていく。

水谷先生には、毎日SOSを発信するこどもから150通以上のメールが届く。多いときには一日3000全通のメールがきたそうだ。

夜、水谷先生はこのメールに返信をするのだが、メールを打っているそばからこどもからの電話もかかってくる。

水谷先生は、自分がドラッグの知識がないばかりにシンナー中毒の少年の心の叫びの真意を聞くことができずに少年を亡くしてしまい、これを機に猛然と麻薬のことについて調べ始めた。

そして、ドラッグのことについて一般の人が読める本がまったくないことに気づき、専門の医師に分かりやすい本を書いてもらうように頼んだ。

そうしたら、医師達からは「水谷さん、あなたはもう十分に知識を持っている。」「ご自分で書いたらどうですか。」と勧められ、自らドラッグに関する本も書いた。

シンナー中毒の少年を亡くした際に、専門の先生に「麻薬による依存症は病気です。病気は愛では治せません。」と言われ、自分の考え方が間違っていたことに気づき、この状況を変えるために何とかしないといけないと思ったそうだ。

水谷先生はインタビュアーの江川紹子さんに「昔のこどもたちと今のこどもたちは変わったか?」と聞かれ、「昔の暴走族は警察に捕まっても、一人で突っ張っていた。でも、今の暴走族は一人なると、すぐ謝る。仲間で集まっていると強がるが、一人になると弱い。」と言っていた。

また、水谷先生は、今の日本人は攻撃的になっていると言う。子供達は昼間の世界で責められ、家に帰り親から責められる。元気のいい子供は暴走することで反発するが、一人部屋にこもる子供は責めを逃がすすべを知らずにリストカットしたりするのだどうだ。

水谷先生の話で思うのは、「あたたかい人間関係の中のやさしい一員」という日本人の特性の陰の側面だ。

「あたたかい人間関係の中のやさしい一員」の環境で育ち、自己主張することを無意識に押さえつけてきた子供達は、他との違いを許容せずに、違いをもった子供を責めるようになる。

社会人の世界でも同じような環境があるとは言わないが、他との違いを許容しない、自分の経験にないものは受け入れないといった風潮を「あたたかい人間関係の中のやさしい一員」から引きずっているように見える。

2つ目の話にでていた丁さんは「日本人は勤勉であり、日本人の勤勉さは見習わなければならない」と言っていたが、勤勉さだけで勝負してきた日本人が、勤勉さだけでは太刀打ちできない壁にぶつかったときに、効率を上げるくふうを学ぶことが必要であることに気がついていないようにも思う。

11月3日はテレビを通して自分の知らない世界を3つ見た。

今、日本人そして日本の技術者は自分が知らない世界が存在し、自分の知らない世界から学ぶべきものがたくさんあることに気がつかないのではないだろうか。浸かっている湯の温度がじわじわと上がってきたことに気がつかずゆでガエルにならないためには、自分の知らない世界のことにアンテナを張っておくことも大事だと思う。