ここが変だよ日本の管理職

テレビ東京で毎週月曜日22:00から放映している「カンブリア宮殿」の2006年10月9日放送でソフトブレーン創業者の宋 文洲氏がゲストだった。

【宋 文洲さんのプロフィール－ソフトブレーンWEBサイトより－】

85年に北海道大学大学院に国費留学。天安門事件で帰国を断念し、札幌の会社に就職するが、すぐに倒産。学生時代に開発した土木解析ソフトの販売を始め、92年28歳の時にソフトブレーンを創業。経営を通して日本企業の非製造部門の非効率性を痛感した。
98年に営業など非製造部門の効率改善のためのソフト開発とコンサルティング事業を始めた。2000年12月に東証マザーズに上場。成人後に来日した外国人では初のケースとなる。 取締役会長　宋文洲
2004年経済界大賞・青年経営者賞を受賞。2005年6月1日には東証1部上場を果たし、業界最大手に成長。
営業改革を訴えた著書「やっぱり変だよ日本の営業」は、トヨタ自動車の張富士夫社長（当時）自身が購入し、営業系の役員を中心に配布。12万部に迫るベストセラー＆ロングセラーに。
2006年、企業情報化協会・特別表彰を受賞。

【引用終わり】

宋さんは、自分が感じた日本の組織運営の変なところをズバズバと切る。言われてみればごもっともなことを遠慮せずにピシッと言ってくれるので、組織的問題で悩んでいる人にとっては小気味いい。逆に日本的な組織運営にどっぷり浸かっている人には耳が痛いだろう。

宋さんの本は『 やっぱり変だよ日本の営業―競争力回復への提案』の方が売れているようだが、自分は営業職ではないので、『ここが変だよ日本の管理職』の方を買って読んでみた。

【第2章 ここが変だよ 赤信号をみんなで渡る日本の管理職 より引用】

＊－馴れ合い、もたれ合い

　儲からない会社には、いくつかの共通点があります。その一つは、間違っていることをはっきりさせないことです。
　たとえば、儲かっていない会社ですから、社内には儲かっていない部署が必ずある。そうしたら、その部署が儲かっていない原因をきちんと分析して、将来的にも厳しいようなら、その事業については撤退するなり手を打たなければならないはずです。でも、そんなことを言い出す管理職の人は、あまり見かけません。
　あるいは大きなミスをした人間がいる。でも、「この人がミスをしました」とは誰も言い出さない。しばらくしてから、「こんなことが起こりました。みなさん気をつけましょう」となるだけです。
　どうして、儲かっていない部署をどうすべきかと、はっきりさせないのでしょう。○○さんがこんなミスをしましたと、はっきり言わないのでしょう。自分の会社に責任を持たなければならない管理職の人たちが、なぜ口をつぐんでしまうのでしょう。
　少なくとも、他の部署や他の人の揚げ足を取り、個人攻撃をしようとしているわけではないのですがから、はっきり言わないのは変です。
　日本人のメンタリティーとして、表だって自分が何かについて批判するようなことが、精神的に堪えられないということもあるようです。そんなことをして、「あいつは他人のあら探しばかりするイヤなヤツだ」というレッテルを貼られるのが恐いのです。
　もっと言えば、自分たちの“ムラ社会”に波風を立てることによって、今度は自分が疎外されるのを恐れるからなのでしょう。
　私は、日本人の特性と言うよりは、お互いに信頼感が持てないことが、他人に対してズバッとものが言えない習性をつくり出す、大きな要因になっているのではないかと思っています。そのため、はっきりさせないほうが自分も安全なところにいられると考えてしまうのです。

【引用終わり】

ソフトウェア品質シンポジウムで大場充先生も言っていたが、日本人のエンジニアはソフトウェアレビューの際に確実に間違っているところしか指摘しない、「ここはこうした方がいい」というところも言えるようにならないとレビューにならない。それは宋さんが言うように「あいつは他人のあら探しばかりするイヤなヤツだ」というレッテルを貼られるのが恐いという心理だろう。

その根幹には「ISO9000やCMMIに違和感を感じませんか？」の記事でも書いたように、子供の頃から日本では「あたたかい人間関係の中のやさしい一員」という教育を受けているという事実があると思われる。米国の「創造性と個性にあふれた強い個人」の教育とは対照的だ。

【第2章 ここが変だよ 赤信号をみんなで渡る日本の管理職 より引用】

＊－みんなが後出しジャンケンをする組織

　モラルの問題だけでなく、個人、自己が弱いと困ることがたくさんあります。たとえば、そういう人たちには“群れたがる”傾向があることもその一つです。
　どういうことかと言うと、お互いに傷つけ合わない者同士でないと安心できないために、同じような感覚の人で集まりたがるのです。
　つまり、「オレはお前の悪口は言わない。その代わりお前もオレの悪口を言うなよ」と暗黙のうちに目で語り合う。そして、「オレたちの悪口を言うヤツは、仲間には入れるな」とも。

【引用終わり】

後出しジャンケンとまで言わなくても、「お前の責任だ」と言われないために、何の意見も言わずに黙っている者が技術者にも管理職のもいる。

【第5章 まだまだ変だよ 不合理がいっぱいの日本の会社の人事評価　より引用】

＊－成功した旗の舌には百人が集まる

　「成功した旗の下には百人が集まる。敗れた戦場には一人も残らない」－ちょうっとうろ覚えで恐縮ですが、ある実力派の社長さんから伺った言葉です。
　人間心理からすれば当然の働きかもしれませんが、日本の会社ではとくに目立つパターンだと感じるのは私だけでしょうか。
　集団主義にどっぷり浸かり、組織から排除されないように、後出しジャンケンでしか意思表明しない人が多いと、当然そんな現象が顕著に表れます。
　たとえば、新しいプロジェクトに挑戦しようという時には、どこの会社でも、何回もブレーンストーミングや会議を重ねることになるでしょう。そんな際に、出席者の多くが必ず口にする言葉があります。
　「よいアイディアだとは思うんだ・・・」というのと、「大丈夫かい。リスクはないの・・・」です。この二つの意味を含んだ内容の発言が、折りに触れていろんな人の口から発せられます。
　大丈夫かどうかなんてわかったら、誰も心配しません。進めながら大丈夫なように処理していくのですし、リスクのないような仕事を誰がよろこんでするのでしょう。
　でも、そのひと言が“保険”のようなもので、後々それが効いてくるのです。
　つまり、たまたまプロジェクトが成功したとします。すると、「ほら、オレが言ったとおりだろ。成功するアイデアだと思ったんだ」とみんなが口にします。なかには、「ほら、オレが言ったように、リスクに気をつけたから上手くいったんだ」なんて言う人もいます。
　一方、不幸にしてよい結果につながらない場合には、「ほら、だからオレがリスクがあるから危ないって言っただろ」となるのです。
　これも全部、後出しジャンケンです。
　要は結果がすべてで、どんなふうにプロジェクトが進行したかなんて、誰も関心がないんです。これでは成功のノウハウが蓄積されるなどということは、絶対にありません。

【引用終わり】

宋さんの言うように、失敗を恐れていたり、失敗したプロジェクトを振り返って、プロセスを見直すことから逃げることしか考えない管理職は多いように思う。これは「あたたかい人間関係の中のやさしい一員」の悪い側面に他ならない。「あたたかい人間関係の中のやさしい一員」は、うまくベクトルが一つになって、それぞれが犠牲をいとわず目標を達成する気持ちになったときは強いが、プロジェクトが成功しそうになく、一人一人が保身を考えるようになるととたんに弱くなる。

【第6章 こうしていこうよ 新しい日本の会社　より引用】

＊－顧客価値を決めるのは管理職

　このように、日本の会社にとどまらず日本の社会にも好影響を与えることが期待できるプロセスマネジメントですが、その中核となる「顧客価値の決定」というのは、非常に重要な仕事だということがわかっていただけると思います。
　この重要な仕事を担うのが、基本的には経営者と管理職ということになります。
　顧客価値を決めるには、徹底的にお客さんを知る力が必要です。それが身についておらずに、間違ったプロセスを設計してしまうと、その影響は計り知れません。大変なことになります。
　今までも、経営者や管理職の多くは、自分たちがやっていることはみんなお客さんのためだと思い込んでいます。実はこれが独善で、顧客価値など考えていないことが多いのです。
　「徹底的にお客さんのことを知る力を身につける」というのも、口で言うのは簡単ですが、そんなにたやすいことではありません。
　これは、理屈ではないと思います。どういうことかというと、個人の自立なんです。
　この本では、日本の会社やそこで働く人たちの現実を見て、変なことだらけだと言い続けてきました。欧米の人も中国の人も日本の人も、みんな少しずつ見た目は違っているだけで同じ人間なのですが、日本の人を見ていると実はかなり違和感を感じる部分があるのです。その一番の原因はそれぞれが自立できていないということだと思います。
　サラリーマンになって、一生同じ会社しか経験しないのが当たり前。その会社を辞めたらもうやっていけないと思い込んでいるとか、日本の管理職の人たちの価値観はとても単純です。
　それというのも、学校を卒業して大きな会社に入ったら、かなりの額の給料が約束されます。そうなると、その会社から離れることを考えないようになりますし、お酒を飲むのも全部会社の仲間、先輩、後輩。言ってみれば、一つの会社しか経験しないために、その会社で通じる理屈しか知りません。
　そんな人間に、徹底的にお客さんのことを知らなければならないと言っても、ムリな話なんです。これは、極論ですが、狼と一緒に育った子は、いくら頑張ったって人間のことがわからないのです。
　人間としていろいろな価値観があることを知った上で、消費者の視点をちゃんと持った人間との交流を持たなければいけません。
　そのためには、やっぱり経験を積むしかありません。自分自身がきちんと自立した消費者になることです。

【引用終わり】

自立していない者ほど「こんな会社辞めてやる」と言いながら絶対に辞めずに何とかしてすがりつこうとする。

【第7章 プロセスマネジメント 導入・実践のために　より引用】

＊－意識改革は「気づき」から

　これまでの日本企業は、精神主義と結果主義を根幹に据えたマネジメントを行ってきたと、私は見ています。この二つのがんじがらめになった日本企業のマネジメントをガラリと意識改革するのが、私自身の仕事でもあり、私の会社の主要業務となっています。意識改革をもたらすために、私たちが実際に行っている手法についてお話ししましょう。
　まず、部長と支店長クラスを集めて、私が社内講演会を一回やります。講演のテーマは「どうしたらマネージャはラクになれるか」です。
　日本のみなさんは、ラクになることに罪悪感があって、「どうしたら頑張れるか」しか語ろうとしませんが、私は「どうしたらラクになれるか」という話しかしません。
　ここが重要です。従来の意識改革の手法は、「もっと頑張れ」でした。私は逆です。「頑張らないでください。それでもあたなの方にメリットのある仕組みがあります。それをやりませんか」とお話しするのです。つまり、仕事をラクにするために発想を変えることを提案し、結果主義からプロセスマネジメントへの転換を促すわけです。
　同じ頑張りならば、もっとインセンティブや給料を増やすような方法、給料を増やせないのなら早く家に帰ってラクになる方法を考えたほうがいいに決まっています。
　こうしたことについて具体論で話し合うと、「そういえばそうだね」「やってみようか」となります。
　「気づき」です。自分で気づき、自分で変えようと思わせることが、意識改革のポイントなのです。

【引用終わり】

宋さんがこの本で一貫して主張しているのが効率のよいマネジメントをしましょうということだと思う。これまで日本の技術者は技術のことだけ考えていればよかったのだか、開発するソフトウェアの規模が増大し、プロジェクトメンバーの数も増えてくると、技術のことだけでなくマネジメントのことを考えないとプロジェクトが成功しない世界に入ってきた。

宋さんは日本は工場のプロセスマネジメントは世界一なのに、ホワイトカラーの効率性が非常に低いと指摘している。この非効率なマネジメントの手法が、ソフトウェアプロジェクトのマネジメントにも影響を及ぼしている。

ただ、この状況に気付いたとしても、プロジェクトメンバーの意識改革を行うのはそう簡単ではない。宋さんのようにトップの地位にいたなら、いろいろな指示が可能だが、絶対的な権限を持たない状況でプロジェクトの意識改革を行うには、それ相当のエネルギーがいる。

自分は、そのエネルギー源は「顧客満足を高めるために必要である」という意識だと思う。「顧客満足を高めるため」というコンセプトの対して反対する経営者はいないし、エンジニアにしても「顧客満足を高めること」に後ろ向きなことを言うのはイヤだからである。

今の日本の組織で一番恐いのは外から見ると「ここが変」というところが、組織の中にどっぷり浸かっていると「お前の言っていることの方が変だ」と思ってしまうことだと思う。

本当にマルチコアがいいんですか？

日経エレクトロニクス2006年10月9日号 に　『マルチコアが変えるソフトウェア開発』というタイトルの特別企画が載るらしい。Tech-On! の日経エレクトロニクスのサイトで、その概要を見た。

Tech-On! の記事をずっとウォッチしていると、マルチコアプロセッサの話題が目に付く。マルチコアプロセッサの記事を見るたびに自分はしっくりこない何かを感じる。

こういう「何かしっくりこない感じ」がわき出るときは必ず理由がある。これまで記憶した数々の経験や知見から構築された脳内のネットワークに刺激が与えられたときにこのような感覚はアウトプットされる。

自分の場合は最初に感覚がきて、あとからその感覚を説明する論理はなんだろうかと理由付けすることがよくある。「何かしっくりこない感じ」の論理がはっきり分からないと、もやもやした感覚だけが残り気持ち悪い。

そこで、マルチコアプロセッサの話題がなぜ自分にとって「しっくりこないのか」よく考えてみることにした。

たぶん、もやもやする最大の原因は、プロセッサをマルチにしようというのはプロセッサメーカーの都合であり、プロセッサのユーザーがプロセッサの内部をマルチにして欲しいと切望しているわけではないからだではないかと思う。単純にプロセッサがマルチになっていると、アーキテクトとしてはどのプロセッサになんのタスクを割り当てたらよいのか悩むことになる。もしかすると、その割り当ての技術がアーキテクトとしての腕の見せ所になるのかもしれないが、考えなくてもいいのなら余計なことは考えたくない。

最近マルチプロセッサが話題になっているのは、これまでシングルプロセッサでCPUの性能を上げてきたCPUメーカーが、これ以上CPUの性能を上げながら低消費電力を実現するのが難しくなってきたからだと聞いている。消費電力を押さえながらCPUの性能を高めるための技術的ブレークスルーがCPUコアのマルチ化だというのだ。ようするに、これまでのCPUアーキテクチャではこれ以上の進歩は望めないので、CPUコアをシングルからマルチにして負荷を分散させようというのだ。

しかし、組込みアーキテクトから言わせてもらえば、それはCPUの作り手側の都合であり、我々の切なる要求というわけではない。ちなみに、自分のプライベートPCのCPUは Intel の Pentium Dプロセッサで、デュアルコアプロセッサだが、たぶん、Windows アプリケーションのプログラマは、デュアルコアプロセッサの特性を活かしたアプリケーションソフトを作ってはいないと思う。

CPUがシングルかマルチなのかを気にしているとしたら、Windwos XP のOSだろう。どこかのWEBサイトで、Pentium Dプロセッサを使うのなら、XP Personal ではなく、XP Peofessonal にした方がパフォーマンスが上がる場合があると書いてあるのを見た記憶がある。

ようするに、デュアルコアプロセッサの特長を活かしているのはOSであって、アプリケーションソフトではない。もしかすると、OSもシングルコアかデュアルコアか気にしなくてもいいように、CPU側がくふうしてくれている可能性もある。

組込みの方もそういう考え方で、アプリケーションエンジニアやアーキテクトがCPUがシングルであったり、マルチであることを気にしなくていいのなら、「何かしっくりこない感じ」はしないはずだ。

ところが、日経エレクトロニクス2006年10月9日号 に『マルチコアが変えるソフトウェア開発』には、次のようなことが書いてあるらしい。

【＜事例編＞マルチコアに向けたソフト開発の現場から】

並列処理を意識したソフトウェア開発にとってマルチコア型マイクロプロセッサの性能を引き出した例が民生機器で登場しつつある。事例から見えてきたのは、ソフトウェア開発者がスレッドの粒度や同期の在り方にまで気を配ることの大切さである。

【引用終わり】

モデル駆動開発の用語でPIM（Platform Independent Model）と、PSM(Platform Specific Model) という言葉がある。

PIM（Platform Independent Model）はプラットフォームから独立したプラットフォームに依存しないモデルで、PSMはプラットフォームに依存したモデルを意味する。

PIMはプラットフォームから独立しているので、プラットフォームが変化してもモデル自体が変わらない、だから寿命が長い。モデル駆動開発では、ユーザー要求をプラットフォームに依存しないPIMとして記述し、プラットフォームに依存する実際に実装するためのPSMはツールを使ってモデル変換できるようにしようと考えている。

実は、自分はこのモデル駆動開発の支持者ではない。モデル駆動開発がうまくいってしまうと、組込みアーキテクトが職を失ってしまうという危機感もあるが、それ以上に組込みの場合、ユーザー要求を最適化することがツールで簡単にできるとは思えないからだ。

しかし、だからといって、PIM（Platform Independent Model）が重要でないとは言わない。PIMを目指す重要性は十分分かっている。プラットフォームに依存したモデルばかり設計していると、ハードウェアやプラットフォームの変更があるたびにソフトウェアを修正しなければいけない。それは効率的でないし、ソフトウェアエンジニアの首を絞めることにつながる。

だから『組込みソフトエンジニアを極める』では、ユーザー要求を性能的な面で実現させる PSM的ボトムアップの視点と、ユーザー要求を機能的な面で実現させる PIM的トップダウンの視点の両方の視点を持つことだ大事だと書いた。

ここで、PSM的ボトムアップの視点を考慮すると言っているのは、製品の機能や性能を実現するためのキーデバイスの特性を考慮することを想定しているのであって、CPUアーキテクチャを考慮することが重要だと言っているのではない。

CPUが変更されたとしても、できるだけアプリケーションソフトウェアは変更しないでよい作りになっていた方がよいと考えている。

なぜなら、CPUは製品の価値を実現するための直接的なデバイスではないと思うからだ。CPUの機能や性能は製品の価値を高めるために間接的に関与するが、パフォーマンスや消費電力などを満たすことができるならばなんでもいい。

T-Engine ではアプリケーションソフトは 明確にCPUから Independent であることを目指している。

そう考えると、 “マルチコア型マイクロプロセッサの事例から見えてきたのは、ソフトウェア開発者がスレッドの粒度や同期の在り方にまで気を配ることの大切さである。” は、PIM を目指そうと考えるソフトウェアエンジニアから見ると PIMからPSMへ逆戻りしているように見える。

マルチコアでもCPU+DSPのような組み合わせは、それほど「もやもや」しない。なぜなら、DSP（Digital Signal Processor）は画像の圧縮・伸張や、デジタルフィルタなどの信号処理に適しており、CPUの役割とは異なり処理を分離することがユーザーの直接的な利益につながるように思えるからである。

そう考えると、同じCPUコアを複数搭載し、どちらのCPUコアにどのタスクを割り当てるべきかを考えるのは、組込みアーキテクトにとって余計な作業であり、どんなに上手に割り当てを行ってもユーザーに直接的なメリットをもたらすように思えないのだ。

たとえば優先度の高いタスクをデュアルコアの片方のCPUに割り当てるという方法はある。でも、よく考えて欲しい。それは組込みソフトエンジニアから見れば、リアルタイムOSを使ってタスクを分割し、タスクの優先度変えることで、限られたCPUパフォーマンスを最適化してきたのと何ら変わりないように見える。

リアルタイムOSでタスクの優先度を変えるのは簡単だが、デュアルコアでCPUに対してのタスクの割り当てを変えるのは簡単ではないように思う。さらにデバッグのことを考えると頭が痛い。CPUが分かれていると同期を取りながらデバッグするのはとても難しいだろう。シングルチップなら、突き詰めれば処理はシーケンシャルなのでなんとかデバッグもできる。

だから、マルチコアプロセッサを選択しようとしている方達にタイトルのような「本当にマルチコアがいいんですか？」という質問をしたいのだ。

一番危ないのは、アプリケーションやシステムの構造がどんなに無駄な動きをしていてもCPUの性能をどんどん高くしていけば、製品の機能性や性能をカバーできてしまうと考えてしまうことだろう。

ソフトウェアは見えにくいだけに、アーキテクチャの悪さが外からは見えないことも多い。シングルコアとRTOSの使い方のくふうで十分にユーザー要求を満たすべく、機能・性能を最適化できるにもかかわらず、CPUの性能を上げることで強引に解決してしまおうと考えるのは、本質的な問題に蓋をして表面的なくふうでその場をしのごうとしているようにも思える。リアルタイムアーキテクチャーを実現するための道具としてのリアルタイムOSも十分に使いこなせていないのに、安易にマルチコアプロセッサという解決策へ逃げているように見えるのだ。

また、「何かしっくりこない感じ」の原因は、作り手側の都合が先行していて、ユーザーへの価値を最大にするという考えに基づいていないように思えるからかもしれない。

もしも、デュアルコアプロセッサで成功しているプロジェクトがあるのなら、それはデュアルコアであることを製品の価値を高めることに結びつけることに成功しているからに違いない。ようするに、その製品はデュアルコアプロセッサを使う必然性がある筈なのだ。

だから、必然性もないのに最近の流行だからといってデュアルコアプロセッサを選択するのは危険なにおいがする。

バッテリーは大きなエネルギーを内在している

ソニーエナジー・デバイス製のリチウムイオンバッテリの回収が話題になっている。回収の規模は200億円、バッテリの数は590万個にも上るそうだ。

2006年6月に大阪で開催された Dell laptop explodes at Japanese conference で、会議中に突如 Dell 製のノート・パソコンが発火、炎上したとのこと。

この事故が今回の回収につながった。パソコン関係のリコールというと、「メーカから交換の連絡を待っていればいいかな」という軽い気持ちで受け止めていたが、写真のように発火する可能性があるとなると、対象機種のユーザーなら、さすがに心穏やかにはしていられないだろう。

海外の航空会社では飛行機の中ではノートパソコンはバッテリでの使用を禁じており、バッテリなしのAC電源で使用できない場合はノートパソコンは使えないようにしているところもあるらしい。

なぜ、バッテリが燃えるのかについて、日経エレクトロニクス 2006年9月11日号の「視点焦点」の記事に書いてあった。その内容をもとになぜバッテリが発火するのかについて考えてみたい。

まず、電池がなぜ電気を貯めておけるのかについて考えてみよう。

銅と亜鉛を電解液となる希硫酸や食塩水などに入れると、銅は原子がほとんど溶けず反対に亜鉛は原子が溶け出して電子が出る。そして、銅と亜鉛をつなぐと銅から亜鉛に電気が流れる。これがボルタの電池の基本だ。

要するに正極と負極を二つに分け、この二つの極の間を電荷を付帯したイオンが移動することで電流が流れる。リチウムイオン電池の場合はLi+イオンが正極と負極の間を行き来する。

バッテリが蓄えられる電力が大きければ大きいほど正極に蓄えられるLi+イオンが多いということになる。ノートパソコンが低消費電力になったとはいえ、6時間も8時間も連続で使用できるようになったということは、リチウムイオン電池やニッケル水素電池の蓄電量は非常に大きいということだ。

だから、リチウムイオン電池やニッケル水素電池の正極と負極を電気的な負荷なしに短絡させたりするととんでもないことになる。爆発するかもしれない。

だから、このような大容量のバッテリではショートしたときのための不可逆的なヒューズや発生したガスを逃がすための安全弁が用意されている。

ではこのような安全装置が施されているにもかかわらずバッテリが燃えてしまうのはなぜか。

【バッテリが発火するメカニズム】

1. 電池セルの製造工程で微少な金属粉がセルに混入する。
2. 金属粉が正極部に付着する。
3. 充放電を繰り返す。
4. 正極に付着した金属粉が金属イオンを放出する。
5. 金属イオンが樹枝状に析出し、正極と負極を隔てているセパレータを破り両極を短絡する。
6. 短絡による電流漏洩でセル内部の温度が上昇する。
7. 200℃ほどで正極材料の結晶が崩壊して酸素放出し、さらに熱を発する。（熱暴走）
8. セルの内圧が一気に高まり可燃物である電解液が気化して安全弁から放出され発火に至る。

このような内部短絡にはセル外部に搭載したヒューズや温度管理用のサーミスタは何も意味をなさない。内部が短絡しているから、ヒューズで電流の流れを切っても内部の短絡から電流は流れてしまうのだ。

したがって、製造工程での金属片の混入はもっとも注意を払わなければいけないらしい。金属片の混入の可能性としては、製造ラインを循環する空気の洗浄が不十分であるということも考えられるそうだ。

ただ、金属粉が原因で短絡しても、150℃前後でセパレータが溶解してLiイオンが通過する穴がふさがり、科学反応が止まる仕組みになっているので、金属粉の混入だけが原因ではなく、いくつかの製造工程上のミスが重なったのではないかと予想されている。

リチウムイオン電池やニッケル水素電池は取り扱いに注意しなければいけないということは、ずいぶん前から知っていた。かつてリチウムイオン電池を使った製品のバッテリ充電のソフトウェアの状態遷移について分析したことがあるからだ。

リチウムイオン電池やニッケル水素電池の取扱説明書にはおびただしい数の警告文が書かれている。バッテリを火の中に投入したり、五寸釘で打ち抜いたりしては絶対にいけない。

今回のリチウムイオン電池の事故でよく考えなければいけないのは、大きなエネルギーを持つデバイスはどんなに安全装置を施しても危険が近くにあるということだ。

組込み機器メーカーやデバイスメーカーは危険が表面にでないように幾重にも安全装置を施すので、ユーザー側はそんなリスクをまったく感じることなく機器を日常的に使用している。だからこそ、日常的ではない何かがあったときに危ないのだ。

身の回りにある機器が危ないか危なくないかは人を傷つけるほどのエネルギーを制御するものかどうかで判断できる。

たとえば、車、電車などはもちろんだが、エレベータや自動ドアだって大きなエネルギーを制御する。車や電車がなく、徒歩で目的地まで行ったらどれだけエネルギーを消費するかわかる。エレベータを使わず8階まで階段で上がったら、どれだけの位置エネルギーをエレベータが肩代わりしてくれているのかがわかる。バッテリは一見たいしたエネルギーを持っていそうにもないが、ノートパソコンを連続で8時間動かすエネルギーを一気に放出するような場合は傷害を起こしうる。

逆に言えば、単4電池2本くらいで動いている電子機器は人を傷つけるほどのエネルギーをもともと持っていないので、どんな故障の仕方をしても安全性は高いと言える。

AC電源は大きな電流を取り出すことができるので、AC電源から電流を取り出す電子機器の電源の安全性は非常に高いものが要求されている。

組込みソフトはハードウェアデバイスをコントロールすることができるため、設計の仕方によっては巨大なエネルギーの制御を誤り人を傷つけるような事故を起こしかねない。

組込みソフトエンジニアは、自分が関わっている組込み機器が扱うエネルギーの大きさに注意を払い、取り扱うエネルギーが大きければ大きいほど、慎重にソフトウェアを設計し、ハードウェアデバイスを制御し、検証や妥当性確認を納得がいくまで実施しなければならない。

今回のバッテリ事故は、ソフトウェアが絡んだ事故ではないが、AC電源につながれていない機器でも大きなエネルギー源を抱えていて危険と隣り合わせにあることがわかったと思う。

世の中がネットワークでどんどんつながれていくと、大きなエネルギーを制御するソフトウェアと、たいしたエネルギーも制御しないソフトウェアが通信するようになり、何かの間違いで大きなエネルギーを制御するソフトウェアの中に眠っていたバグを呼び覚まし、大きな事故を起こすような事態が起こるかもしれない。

ユビキタスの時代になると、組込みソフトエンジニアは自分のプロダクトだけでなく、自分のプロダクトが通信によって流す情報にも責任を持つ必要がでてくる。

高密度のバッテリ開発など世の中が便利になればなるほど、そのような利便性とは対照的に組込み機器を取り巻く環境の危険度は増し、逆に安全に対する要求は高くなるのだ。バッテリの事故は対岸の火事ではない。