2006-12-16

組込みソフトの作り方[1]

本論に入る前に、先週の「MATLABのビジネスから見る知的生産性とは」の記事について、ある方からコメントをいただいた。

【「MATLABのビジネスから見る知的生産性とは」の記事について】

ブログいつも拝読しております。
MATLAB と Simulink には上記のような試行錯誤で作り上げる職人芸のような要素はない。

とありますが,ここは私はちょっと別の感想を持ちました。

というのは,最近ではクルマの制御ソフト開発で,MATLAB/Simulinkからの自動コード生成がかなり普及していて一部のサプライヤでは,MATLAB/Simulinkの枠内で,職人芸的なことをやっていると思います。なので,一概に「ない」とも言い切れない状況かなと感じるのです。
MATLAB , Simulink が、研究者と開発現場のエンジニア、科学技術を必要としている企業の橋渡し
とあるように,自動車業界でも,自動車メーカーとECUサプライヤの間では,MATLAB/Simulinkモデルが仕様書のスタンダートになっています。自動車メーカーが作ったモデルは確かにdoubleの世界ですが,これを受け取ったサプライヤは,モデルがマイコンで走る実際のソフトになるようfixed pointに書き換えるなど,実装に伴う苦労をしているわけです。

10年前は自動車業界でも,その苦労は一般の組み込みソフト開発と同じCプログラム上での試行錯誤でしたが,現在では自動コード生成が普及し,すっかりMATLAB上での試行錯誤に変わっています。

要は,『MATLAB/Simulinkだと職人芸がない』というよりも,『職人芸をインプリする抽象度が,より上のレイヤーに移っている業界も中にはある』というのが現実ではないでしょうか?

以下に詳しい資料があります。


●日経エレクトロニクス 2003年12月22日号,no. 863,What's New,p.27.
「ソフト開発でトヨタら先駆け,量産品に自動生成のコード」

●日経エレクトロニクス 2005年8月29日号,no. 907,What's New,p.42.
「自動コード生成の適用拡大,トヨタが来年開発車種から」,


【引用終わり】

メールをもらって、「なるほど、組込み業界の中でも自動車業界は進んでいる」と思った。でも、これって巨大な市場がある業界だからだろうなって気もした。いずれは多くの組込み業界もC言語プログラムをすり合わせるのではなくモデルをすり合わせるような方向に進んでいくのだろう。しかし、どんなに時代は進んでも組込みには職人芸が付きものっていうのがいいね。

さて、今回の記事の本題に入ろう。

このブログを読んでいるのは必ずしも組込みソフトエンジニアではないと思う。IT系のソフトウェアエンジニアもいるだろうし、学生やアカデミアンもいるだろう。

つい最近、組込みソフトを経験していないどころか、技術系でもない方に「いったい組込みソフトってなんですか」と聞かれたことがある。毎日毎日組込みソフトのことを考えていると、周りの人のが持っている組込みソフトの知識レベルは何ら変わっていないのに、自分の中だけで知らず知らずのうちに周りの人も組込みソフトについてよく知っているかのように思ってしまう。

何か一つのことにのめり込んで知識を蓄え、そのことについて友人からとんちんかんなつっこみをされるとつい「そんなことも知らないの?」とバカにしてしまう。その傾向がどんどん強まっていくとその人は周りの人からオタクと言われるようになる。

さて、組込みソフトエンジニアが外部のコミュニティで活動していると、組込みや組込みソフトのキーワードに触れる機会が多くなり、「組込みの認知度が高くなってきたから、組込み機器や組込みソフトに対する理解者は何もしなくても増えるだろう」と勝手に楽観的な未来を想像してしまうことがある。

でも、それは間違いだ。組込みや組込みソフトが世の中のどんなところで役に立っているのか、また、パソコンのアプリケーションソフトの作り方と何が違うのかについての説明を積極的に発信していかないと、組込みや組込みソフトの対する理解は深まらない。

そこで、今回は「組込みソフトはどのように作られてきたのか」について書いてみたいと思う。これは『組込みソフトエンジニアを極める』の第一章に書いてある内容に近いが、第一章に書いた視点とはまた別の視点で組込みソフトの原点を考えてみた。


[1] 組込みソフトの誕生

そもそもマイクロコンピュータが生まれる前は組込みソフトなるものは存在していなかった。現在の巨大化した組込みソフトは組込みソフトが誕生したときに比べると求められている役割が変わっている。現在、組込みソフト開発の現場で起こっている数々の問題は、組込みソフトに求められる役割の変化について組織の上位層やベテランエンジニアが理解できていないことに原因があるように思えてならない。

そう考えると、組込みソフトが誕生したときの最初の役割がなんだったのかについてきちんと理解しておかないと、現在の変容した役割との差異が明確にならないし、その差異を説明することもできない。

マイクロコンピュータが発明され一般の製造業種にも利用できるようになると、組込み機器の開発の中にこれまでにはなかった新しい環境が生まれた。当然だが、そのころ製造業の中には組込みソフトエンジニアどころかソフトウェアエンジニアと呼ばれる職種もなかった。もちろん、そんな昔でもメインフレームなど大型計算機の世界ではソフトウェアエンジニアは存在していたし、製造業に携わる技術者も大学なので大型計算機を使ってプログラムを書く経験はしている。(プログラムの一行一行を一枚のカードにパンチして読み取らせたりしていた) でも、メインフレームのソフトウェアを書くことを仕事をしていたエンジニアと組込み機器の開発から生まれた組込みソフトエンジニアの出発点は実はまったく異なる。極論を言えばメインフレームの世界で培われたソフトウェア工学の技術は組込みの世界でも使えるけれど組込み向けにテーラリングしないと現場に浸透しない場合が多い。その原因はこの出発点の違いだと常々思っている。

マイコンが初めて組込み機器に使われるようになったころ、ハードウェアエンジニア、特に電気系のエンジニアの中では、アナログ系とデジタル系という役割分担はおぼろげながらできあがってきていた。自然界に存在する情報はアナログ情報だからセンサでセンシングするときはアナログ設計の技術が必要だ。しかし、アナログ情報をデジタルに変換した後はデジタル系のハードウェアエンジニアの出番となる。デジタル系のハードウェアエンジニアは規格化されたロジックデバイスを組み合わせて目的のデジタル回路を設計していく。

マイコンが登場したときにマイコンをプリントP板上に配置し、他のロジックデバイスと接続したのはデジタル系のハードウェアエンジニアだ。そして組込みソフトエンジニアが誕生する以前はデジタル系のハードウェアエンジニアがマイコンのプログラムを書いた。

デジタル系のハードウェアエンジニアは当時どのように仕事をしていたのだろうか。だいたい、次のような手順で仕事をしていたと考えて大きな間違いはないだろう。

<昔のデジタル回路の設計手順>
  1. デジタル回路の使用目的を考え、必要なロジックデバイスが何か目星をつける
  2. ロジックデバイスには必ず部品メーカが作ったデータブックがある。このデータブックを読んで、使用目的に耐えうるかどうか調べる
  3. 選んだロジックデバイスをつなぎ合わせて回路図を作る
  4. 実際にロジックデバイスの部品を入手し、マルチP板(穴がいっぱいあいていてすべての配線を自分で半田付けして行うためのP版)に部品を配置し設計した回路図どおり配線する。
  5. 電源をつないで思った通りに動くかどうか試してみる
  6. ダメだ。動かない。3にもどって回路図や配線を見直し想定した動きになるまで繰り返す。
  7. マルチP板の試作ボードが動いたら、本番用の配線をプリントしたP板を設計し生産する。
  8. 上がってきたP板に部品を載せ半田付けして完成させる。

この流れのうち、3~6の繰り返しは非常に効率が悪い。場合によっては部品を壊してしまったりもするので、きちんと完成するまでにどんどん時間は過ぎていく。この失敗の繰り返しを積み重ねていくとその製品や製品群に合った回路のパターンが見えてきて、その回路のパターンを再利用することになる。実際にうまくいった実績を持つ回路は珍重されることになり、新人は一から回路を設計するのではなく、先輩達が作った実績のある回路を眺めて、それを参考にするという手順が生まれる。

こんなことを繰り返しているデジタル系のハードウェアエンジニアのところに、マイコンという電子部品が現れた。マイコンという部品は他のロジックデバイスの接続に成功していれば、プログラムを書き換えることで上記の3~6を繰り返す必要がなくなる。組込み機器への入力の変化に応じて出力を変えたいときなど非常に便利だ。電子回路で要求仕様を満たすすべての組み合わせを設計していたら配線が間違っていたり、仕様が変わったりして手戻りが非常に大きい。

でもマイコンを使えばプログラムを書き込んだROMを差し替えることで間違いや仕様の変更に対応ができる。このころマイコンは自由度の高いシーケンサーだった。デジタル系のハードウェアエンジニアはロジックデバイスの延長線上としてマイコンという部品を見ていたと考えられる。

当時ROMに書かれていたプログラムは処理の流れのシーケンスが書かれていたのであって、ソースコードが設計要素のすべてであり、設計仕様やテスト仕様などの情報は必ずしも必要ではなかった。仕様書やテストの結果がなくても、誰からも怒られることもなかった。 なぜか? それはソースコードはたいした量ではなかったし、ちょっとだけコメント書いておけば、どんなシーケンスで動いていくのかソースコードを追うことで理解できたし、ソースコードを追っかけることは回路図の配線を確認することと対して違いがなかったのである。

また、電子回路のテストはよっぽどのことがなければ、シミュレーション環境を用意して事前に確認するような大がかりなことはしなかったから、回路図の見直しや配線のチェックは机上でしていたものの本当の思った通りに動くかどうかは試作用のP板を作るまではわからなかった。要するに動かしてみて、その動作から問題点を見つけて直すという手順だ。

マイコンが導入されたころは、これと同じ手順でプログラムが作られた。頭の中でシーケンスを思い浮かべながらコードを書き、プログラムをROMに書いて電源を投入し「さあ、動くか!」と息を飲む。

いろいろなパターンを想定してプログラムを作ったから、そのすべてのパターンを実際にテストしてみて、動作を確認しながら完成度を高めていく。

[2] そこで現役を卒業した技術者はソフトウェアはそういうものだと考え思考が止まる

シーケンスプログラムを実装し、試行錯誤で想定したパターンを実際にやってみて完成度を高めるという手順でプログラムを書いていたデジタル系のハードウェアエンジニアが管理職になって自称「ソフトウェアを作ったことのある」プロダクトマネージャや技術部長クラスになるとどうなるか。

<デジタル系ハードウェア技術者出身のプロダクトマネージャの頭の中>
  1. ソフトウェア(実際頭の中に浮かんでいるのはプログラムコードのこと)はソースコードが設計図
  2. 実装してからいろいろなパターン(テストケース)を試して完成度を高める
  3. バグが残るのは想定したパターン(テストケース)に抜けがあるからであり、パターン(テストケース)の想定漏れは経験のなさからくる

このような経験を持つ上司のもとで巨大化した組込みソフトウェアを作らなければならない組込みソフトエンジニアは間違いなく苦労することになる。

バグの原因はすべて「パターン(テストケース)の想定漏れ」であり、その原因は「エンジニアの経験不足」になってしまうからだ。

人間の脳の情報処理は具体的な体験、経験を階層的に抽象化しながら記憶していき、蓄積された記憶に新たに刺激を与えて出力されたアウトプットで思考が進む。だから、具体的な体験や経験の抽象化の階層が浅いと具体的な自分の経験に合致しない出来事は理解できないか、自分の体験に一番近いもので連想された答えが自分の感覚としてアウトプットされる。

だから、ソフトウェアのバグ=経験不足が原因という結論になってしまうのだ。実際、20年以上前なら、試行錯誤の経験を積んでいけば想定するパターン(テストケース)の漏れがなくなり、不具合も減っていった。

その成功体験だけで、21世紀のソフトウェア開発を同じように考えられたらたまらない・・・ が、現実にはそういった現場はたくさんある。

教育の現場でも同じような環境が発生する可能性はある。

なぜなら、ソフトウェアの設計技術として、要求の分析やアーキテクチャ設計、検証、妥当性確認などの意味や考え方、方法論を学生に教えずに、プログラム言語のテクニックだけを教えていると前述の昔のデジタル系ハードウェア技術者と同じようにソフトウェアエンジニアではなくプログラマを作ってしまうからだ。

そうなると、次の思考の呪縛から抜けきれない。
  1. ソフトウェア(実際頭の中に浮かんでいるのはプログラムコードのこと)はソースコードが設計図
  2. 実装してからいろいろなパターン(テストケース)を試して完成度を高める
  3. バグが残るのは想定したパターンに抜けがあるからであり、パターン(テストケース)の想定漏れは経験のなさからくる
このような経験しかしていない技術者の卵の軍団が会社に入ってきて、プロダクトマネージャや技術部長クラスのの思考回路もこんな感じだったら、サンドイッチになったソフトウェアエンジニアはどうすればいい?

この問題を解決するために、次回の記事では、マイコンがシーケンスをトレースする役割から変革していった過程を書きたいと思う。
 

2006-12-09

MATLABのビジネスから見る知的生産性とは

MATLAB というツールをご存じだろうか? MATLAB とは MATrix LABoratory の略で MathWork 社が市販している計算技術用ソフトウェアのひとつである。日本ではサイバネットシステム株式会社が販売代理店となっている。

12月7日に 毎年恒例の MATLAB EXPO 2006 が東京プリンスホテルパークタワーで開催された。

MATLAB EXPO に行くといつも不思議に思うのはどうして一つの製品とそれにまつわるサードパーティだけの資金でこんなに派手な展示会ができるのだろうという疑問だ。

MATLAB EXPO 2006では、ランチボックスの券が配られていたし、講演を聴いたり、サードパーティのブースに立ち寄ってポイントを集めると帰りに抽選ができ、マウンテンバイクやニンテンドウDS Lite などが当たる。はずれても500円のクオカードがもれなくもらえる。他の展示会と比べてもかなりリッチな感じがする。

MATLAB のビジネスがなぜリッチなのかは後で触れるとして、MATLAB EXPO 2006 で MATLAB と Simulink をそれぞれ1時間ずつさわる機会があった。

簡単な例題をMATLAB と Simulink を使い、インストラクターの指示に従いながらノートパソコンで実際にやってみるというトラックだ。

MATLABの演習トラックの例題は、excelシートに格納されたいろいろな周波数が混在した信号のデータ列を読み込んで FFTをかけて、パワースペクトルを表示させて信号の周波数特性を眺めてみるというものだった。

この例題を通して 分かったMATLAB の特徴とは次のようなものだ。
  1. データは何も指定しなければ double 型で読み込まれる。(インストラクターはMATLABは通常のプログラミング言語のようにデータ型を指定する必要がないと言っていたが、正確にはデフォルトで double型になるということ)
  2. MATLABはBASICのようなインタプリタ型であり、コマンドラインから入力した命令を1行ごとに解釈し実行する。
  3. いろいろ試行錯誤してうまくいったら、プログラムファイルに実行したコマンドをコピーして整形し保存するような使い方が一般的。
  4. プログラムファイルにはスクリプトのファイルと関数のファイルの2種類があり、用途によって使い分けることができる。
  5. スクリプトファイルと関数ファイルはテキストなのでライブラリとして公開することが簡単にできる。(利益を考えなくて良い研究者達には便利)
  6. GUIのインターフェースはあらかじめいろいろなものが用意されている。

さて、用意された信号データの周波数成分を調べる演習で感じたのは「これって、自分が excel でやってた手順と同じだなあ」という感覚だ。

信号処理の仕事を生業としていた技術者としては、A/D変換したデータの周波数特性を調べるという作業はなじみが深い。

今回 MATLAB で実施したようなことは、ちょっと面倒だが excelのシート上で計算を行い、最終的に出た結果をグラフ表示させることで同じことができる。じゃあ、なんで MATLAB EXPO がこんなにリッチなのか。それは、MATLAB のパッケージ力と simulink のコンビネーションが強力なのだ。

MATLAB と Simulinkのコンビネーションが利益を生み出すしくみについては後で触れるとして、次に、Simulink の例題を行った。Simulink では MATLABで作成したコンポーネントをワークスペースに配置し、コンポーネント同士を結線して必要なシステムを構成していく。コンポーネントは分野ごとにライブラリが用意されており、自分でコンポーネントをわざわざ作らなくても大抵のことができてしまう。ただ、特定の分野によって必要なライブラリをパッケージにした商品が別売りされておりこれらのパッケージを売るサードパーティの会社がたくさんある。(ここに MATLAB EXPO がリッチである秘密がある)

演習では、SIN波を発生させて、スコープで眺めたり、ノイズを混入させた音声信号にフィルタをかけ、FFTを行ってパワースペクトルを取り、生波形を表示させながらフィルタの効きを見たりした。

MATLAB を使うとローパスフィルタの設計も簡単にできる。たとえば、カットオフ周波数0.4Hz、次数7、通過帯域リップル1dB、遮断周波数30dBの仕様を満たす楕円フィルタを設計したいとしたら、

>> [b,a] = ellip(7, 1, 30, 0.4)

と打ち込めば、b=分子係数と a=分母係数が求まる。このフィルタの周波数特性をグラフに表示させるとあら不思議、狙った通りの特性がでている。

さて、ここからが本論だ。

信号処理系の組込みソフトエンジニアは、MATLAB と Simulink がいとも簡単にやってのけるこのようなフィルタ設計をどうやってやって設計してきたか。

まず、前提条件として8ビット、16ビットの汎用的なCPUで、double の演算をバシバシ使うフィルタを設計したらまず先輩から「バカ」と言われる。C言語で書いた浮動小数点の演算をアセンブラのコードに落とすとどうなるのか見たことがあるエンジニアなら分かると思うが、整数演算なら3インストラクションで終わるようなたった一行の処理が、浮動小数点演算では100インストラクション以上かかったりする。

(unsigned short)x = (unsigned short)x /2



(double)x = (double)x /2.0

は両方ともたった一行で表される式だけれども、アセンブラにすれば上は汎用レジスタに格納して右に一回シフトして終わり。ところが下は延々と処理をこなさないと答えがでない。

要するに浮動小数点の演算は CPUに負荷をかけるし、組込みシステムのCPUはフィルタ以外にもやらなければいけない処理がたくさんあるので、組込みソフトエンジニアはできるだけ整数演算で目的の周波数特性に近い特性が得られるようなフィルタを設計する。

このようなフィルタは基本的な設計の指針はあるものの、最後は組込みソフトエンジニアが試行錯誤で作り上げることになる。組込みソフトエンジニアが要求と制約条件をすり合わせて最適解を求めるのだ。

MATLAB と Simulink がいとも簡単に目的の周波数特性のフィルタを作り上げることができるのは、PCの能力が格段に上がっているからだ。昔なら大学の計算機センターくらいでしかできなかった計算を今ならパソコン上で待ち時間なしで実行できる。

MATLAB と Simulink には上記のような試行錯誤で作り上げる職人芸のような要素はない。MATLAB と Simulink で作るモデルは MDD(Model Driven Design)で言うところの PIM(Platform Independent Model)になるのだろう。ただ、負け惜しみ的な気持ちも含めて言うと、プラットフォームに依存していないといっているのは、非常に高性能なプラットフォームを想定していて、かつ、データ型はデフォルトで double 型にしているからPIM(Platform Independent Model)だと言えるのであって、MATLAB と Simulink で作ったモデルは(コストアップをともなわずに)必ずしも組込みシステムに実装できるとは限らない。

コストアップをともなわずにと注釈を入れたのは、DSP(Digital Signal Processor)を使ったり、FPGAのIP(Intellectual Property:知的財産)に落とし込んでしまえば実装が可能なところまで実装技術が進んでおり、コストを気にしなければPIMはPSM(Platform Specification Model)に変換できる世の中になっているからだ。しかし、多くの場合このようなアプローチはコストアップがともなう。でも、MATLAB と Simulink を使って作ったモデルが商品の価値となり、コストアップとその価値のトレードオフの結果がユーザーに受け入れられるのであれば問題ないし、職人芸で作り上げるコンポーネントよりも早く開発でき品質が高いのであれば、ツールやライブラリが高かったとしても最終的にはペイできるかもしれない。

ところで、Simulink と非常に似ているツールでナショナルインスツルメンツ社の LabVIEW というものがある。LabVIEW も Simulink と同じで、豊富に用意されたコンポーネントをつなぎ合わせて、あっという間にカスタマイズしたオシロスコープなどができてしまう。

MATLAB , Simulink にあって、LabVIEW にないもの、それは研究者に対する配慮ではないだろうか。MATLAB , Simulink は自然科学の研究者にとってとても有効なツールだと思う。過去の研究者が発表した理論式を組み合わせたり修正したりして、まだ未着手の分野の対象から取り出したデータに適用して、グラフィカルに表示させれば論文用の図があっという間にできてしまう。

コンポーネント化された知見を組み合わせるか、モディファイするか、パラメータを変えるかして、未開拓の分野の問題を解決する実験をパソコン上でシミュレーションをし、よさげな結果がでたらグラフィカルに表示して論文にする。うーん、こんなおいしい話はない。(いずれにせよ、科学技術の研究とはそういうものかもしれないが・・・)

そして、新しくできた知見はパッケージにして売り出すこともできる。ただ、ひとつ問題なのは、MATLAB , Simulink で作ったモデルは、強力な性能のCPUと浮動小数点演算によって裏打ちされたPIMであり、ひ弱なCPUと整数演算と限られたメモリいう制約条件を持つシステムに実装するには、また別の組込み技術が必要になるということだ。(どんな技術が必要かは『組込みソフトエンジニアを極め』を参照されたし)

しかし、そうはいうものの、CPUの性能は常に向上し続けており、メモリの価格も安くなっている。分野や用途によっては、研究者が考えた新しいコンポーネントを人の手を介すことなく製品に組み込むことも可能になってきた。

このことは MATLAB , Simulink が、研究者と開発現場のエンジニア、科学技術を必要としている企業の橋渡ししているとも言える。個人的な偏見かもしれないが、研究者と現場のソフトウェアエンジニアは仲が悪い。なぜなら、浮動小数点演算に象徴されるように、研究者は組込みソフトの開発現場の制約条件を考えてくれていないという思いが技術者サイドにあるからである。

しかし、『組込みソフトエンジニアを極める』第2章 機能分割のハードルを越える p147 図2.23 制約条件をクリアしながら最適化を図る に描いたように、規模が拡大したソフトウェアシステムではもうすり合わせ的な作り方では開発が間に合わないし、品質を確保することもできない。

科学技術をコンポーネント化し組み合わせの部品として使うことができればアドバンテージになりやすい。しかも科学技術の部分は利益を欲しないアカデミアンの研究成果やサードパーティのライブラリを使うこともできる。

でも、コンポーネントの組み合わせだけでは十分に要求を満たせないのが組込みソフトの難しいところだ。グニャグニャしたすり合わせ的な要素は必ずある。そして、そのすり合わせ的な要素が商品の快適性や低消費電力を可能にしていたりする。

MATLAB , Simulink を触ってみて分かったのは、MATLAB , Simulink は知的生産性を高めるための道具として優れているいうことだ。科学技術をパッケージ化し、必要な分野の企業に売る。パッケージ化したコンポーネントはオブジェクト指向設計と同じで、高凝集・疎結合なモジュールとなっているためつなぎ合わせて使いやすい。

このコンポーネントの需要が高めれば、黙っていてもどんどん売れる。科学技術をコンポーネントに隠蔽して商品として売るビジネスモデルは当たれば利益率が良いだろう。

組込みソフトウェア、組込み機器自体は、実は知的生産性の高めることに成功した顕著な例と言える。組込み機器のソフトウェアに知見を隠蔽することができ価値が認められば、製品は黙っていても工場がどんどん作ってくれ、知見は製品に乗ってどんどん売れる。

問題は組込みソフトウェアの規模が大きくなってきたので、組込み機器の内部で組み合わせ用のコンポーネントを使わないと開発効率が上がらなくなってきたということだ。

ところが、組込みシステムに使うミドルウェアは必ずといっていいほどチューニングが必要であり、ポーティングを行うことが多い。これは黙っていてもどんどん売れるという流れではない。知的生産性が悪い。

コンサルティングなども同じだ。人がコンサルテーションによって知見を伝えることができる効率には限界がある。著名なコンサルタントの単価を上げても普通のコンサルタント100人分にすることはできないだろう。

一方、書籍は知見を広めるには非常にいい媒体で知的生産性が高いが、単価が安いので利益率が低い。

でも、MATLAB , Simulink はツールを媒介して、比較的単価の高いパッケージを流通させることができる。だから、MATLAB EXPO はリッチなのだ。

今後、MATLAB , Simulink で作ったコンポーネントが組込みシステムに実装できるかどうかは、組込みアーキテクトが組込みシステムを科学技術が適用される部分と適用されない部分に切り分けて設計できるかどうかにかかっていると思う。

科学技術を適用する部分をパッケージにし、インターフェースを明確にして、システムの制約条件をクリアすることができれば製品の付加価値を高めることにつながる。

科学技術は先人の科学者が何百年もかけて積み上げた知見のたかまりだ。すり合わせて作るソフトウェアには数人のエンジニアの知見しか作り込めないが、科学技術をコンポーネント化して組込みシステムに実装できれば、のべ何百人分もの知見を製品にインプリメントすることができる。

それが他社に真似できないような知見ならさらに競争力は高まる。

ちなみに、MATLAB , Simulink を使わなくても、科学技術を利用する部分を特定しコンポーネント化することができ、制約条件をクリアして実装する技術があれば、付加価値の高い製品を作り上げることはできるので、慌ててMATLAB , Simulink の購入を検討するのはやめた方がいい。
 

2006-12-02

エンジニアにどうやってインセンティブを与えるか

先週「組込みか組込みでないかの違いはどこにある?」の記事の中で、任天堂の Wii コントローラを題材にして、組込みか組込みでないかの違いは「世界を固定するかしないかの違い」ではないかと書いた。

この記事の中でハードウェアデバイスは日々進化しており、それらのハードウェアデバイスを取り入れることで世界は広がるはずだとも書いた。

でも、その後よく考えてみたら、これは「洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない」の記事で書いた「真のユーザーニーズ」のことを考えていなかったかもしれないと思った。

「洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない」の記事で書いたのは1993年に聞いた当時東京理科大の高橋 武則先生(現 慶應義塾大学大学院教授,工学博士,健康マネジメント研究科 教授)の話で、ユーザーは衣類をきれいにしたいのであって洗濯機は衣類をきれいにする手段のひとつで、ワイシャツ1枚10円でクリーニングしてくれるクリーニング屋が現れたら、必要なくなるかもしれないという話だ。

この話の真意を考えれば、日々進化するハードウェアデバイスを取り入れることが世界を閉ざさないことに通じるという考え方はおかしい、間違っている。

なぜなら、新しいハードウェアデバイスを取り入れることは手段であって、ユーザーニーズを満たすための本質ではない。

インターネットショップで買ったものが思ったようなものではなかったり、サイズが間違っていたとき、無料で引き取ってくれるサービスを始めた店が売り上げを伸ばしているというニュースを見たことがある。インターネットショッピングで「しまった。やめておけばよかった。」ということはよくある。間違った買い物に対して、ショップが無料で引き取ってくれると店との信頼関係が生まれ次の買い物も安心して気軽に選べる。

これは「プロダクトのよさ」を追求したのではない、サービスのよさを追求した結果だ。

日経ビジネス 2006年11月27日号 に-「お母さん」を狙え! 任天堂がWiiに託すお茶の間戦略 -を読んだ。「組込みか組込みでないかの違いはどこにある?」の記事を書いた後だ。

この記事を見た最初に感じたのは Wii がプロダクトとしてワクワクするのは組込みとか非組込みとかいうことではなく、岩田社長を始め任天堂のトップマネージメントたちは家族を巻き込んで使ってもらうプロダクトやサービスは何かを考えていたということだ。

冒頭の写真は、2006年の5月、米ロサンゼルスの展示会「E3」で Wii Sports をプレゼンする岩田聡社長(左)と宮本茂専務だ。

この写真を見て、社長と専務が自分たちのプロダクトをこんなに楽しそうに披露できる会社ってうらやましいなと思った。

任天堂は今でこそ、ニンテンドウDS Lite が大ヒットしているが、ファミリーコンピュータ以降、ゲームキューブのときに売り上げの低迷を経験している。

岩田社長はもともとゲームソフトHAL研究所から2002年に任天堂に移り社長になった。岩田社長とソフト開発部門のトップの宮本専務とハード開発部門トップの竹田専務の3トップでゲーム人口減少への危機感で議論を重ねたそうだ。

岩田社長がすごいと思うのは、自分が若くゲームソフト会社から来た外様であり、前任社長の山内氏は鋭い直感を武器にカリスマを崇められてきたオーナーであるということをふまえて、自分が何を言ったとしても生え抜き社員が素直に言うことに従うとは限らないと考え、「徹底して丁寧し説明し、同意を得る」ことにしようと決めたことだ。

経営陣とまず議論を重ね、出た結論を自分の言葉で繰り返し社内に説明し続けた。

「高機能・高画質ではない手段で、たくさんのユーザーが楽しめる据え置き型ゲーム機を目指す」という3トップの意見は一致したが、社内からは疑念の声が多く上がったそうだ。これに対して岩田社長は時間をかけて丁寧に説明し、目標を具体的に示した。

この「高機能・高画質ではない手段で、たくさんのユーザーが楽しめる据え置き型ゲーム機を目指す」という目標に、即座に「その通り」と反応する社員が数多くいた一方で、方針転換になかなか踏ん切りにつかない社員もいたそうだ。しかし、ニンテンドウDSが市場に受け入れらたことを目の当たりにして、躊躇していた社員も態度を変えるようになった。

岩田社長が考えるニンテンドウのゲーム機のコンセプトは「ゲームに関心のなかった人にも邪魔に思われないような、特に家庭のお母さんに嫌われないようなゲーム機」とのこと。

これには我が家も見事にはまっている。ニンテンドウDS Lite を手に入れた子供はまず、「どうぶつの森」を買った。どうぶつの森はドラゴンクエストのようなゲームとは違い、特に達成すべき目標のようなものがない。四季が移り変わるどうぶつの森で、虫取りや魚釣りなどをしながら、どうぶつの森の住人達と関わってただ時間を過ごすだけなのだ。

「家庭のお母さんに嫌われない」秘訣がここにある。子供はゲームをしていると季節によってなる果物や釣れる魚の違いがわかったり、お金を貯めて家のローン返すといったことを学ぶことができ、発見したことを母親や父親にうれしそうに話す。そうすると親は「DSは勉強にもなるのか」と思う。

実際、自分は「英語漬け」というソフトを買って、ディクテーション(発音された単語や文章を書き取ること)を続けている。

結局、どうぶつの森は家族全員がやることになり、母親は「ゲームに関心のなかった人にも邪魔に思われないような、特に家庭のお母さんに嫌われないようなゲーム機」に見事にはまっている。

ちょっと話はそれるが、このバーチャルな世界で現実の世界を学習したかのように感じることには問題点もある。どうぶつの森の魚釣りはそれなりに難しいがコツをつかめば釣れる確率は非常に高い。でも実際の釣りはそんなに簡単なものではないだろう。いろいろな経験を疑似体験できるのは良い面もあるが、現実の厳しさや厳しさを乗り切るための我慢強さの重要性を学ぶことができないのはよくない。

現実の世界で、自分の思った通りにならないとキレやすい子供を作っているのはちょっと苦労すれば欲しいものが手に入るバーチャルな世界に慣れてしまっているからではないだろうか。ゲームの存在する世界をいまさら否定することはできないが、ゲームによる弊害についても考えておく必要があると思う。

さて、任天堂の会社の話に戻そう。

Wii の企画で、ハードウェア技術者はロードマップから外れたものを作るという決断に対して不安に思っていたという。そもそも任天堂では (おそらく技術)ロードマップ があったというところがすごい。他社の様子を見ながらの行き当たりばったりの開発ではなく、数年もしくは10年後に開発が進むであろう新しい技術やデバイスの取り込みの準備をしていたに違いない。

そんなロードマップから外れても岩田社長は「ゲームに関心のなかった人にも邪魔に思われないような、特に家庭のお母さんに嫌われないようなゲーム機」を作りたい、作らなければならないというコンセプトを伝え、方針の転換に理解を求めた。

そして、浮かんでは消えた試作品の数々を経て、Wiiリモコンができた。

Wii はハードウェアもすごい、Tech-on の記事によると、「Wii を分解して驚くのは,低コストを狙い,徹底的に練られた設計である」とのこと。

一目見てシンプルと分かるメイン・ボードに載る部品点数はおそらく1000を大幅に切る少なさ。いくつかのカスタムLSIとゲームキューブとの互換性を保つためのコネクタ類を除くと,大半の部品に汎用品を採用している。

数百万台作っても同じ品質を保つのは本当に難しい。ハードもソフトも同じで生産時の検査で乗り切ろうとしても限界がある。設計時に品質を作り込まなければ絶対ムリだ。

だから、Wiiの設計方針は決して低コスト一辺倒ではない。ここぞという部分には思い切ってコストを掛けるメリハリがあり、その象徴が金メッキ部品の多用とのこと。

すぐれたプロダクトには見えないところにさまざまな工夫が施されている。ゲームの遊ぶ側だけした体験していない子供達が、多くの人々に受け入れられるようなプロダクトを作れる技術者になれるのだろうか? ちょっと不安が残る。

Wii の開発秘話で分かったのは、よいプロダクトを生み出すのに必要なのは組織上層部やプロジェクトリーダーの熱意だったりするということだ。

なぜ「だったりする」のかというと、これはあまり科学的でもエンジニアリングでもない話であり、「熱意がなけりゃ良いもの作れないのかよ」という不満も含まれているからだ。

一つ言えるのは組込みはプロジェクトに「熱意」を伝えやすいということだ。プロダクトが形に見えるものであり、最終的に自分たちが思った通りに動くようになるとうれしいし、そのプロダクトが多くの人に受け入れられることを想像すると力がわく。

でも当たり前だが「熱意」だけではものづくりは成就できない。ベースに技術がなければムリだ。また、品質を高く保つには技術だけでなく、組織内でのルールや規範も必要になってくる。

エンジニアにインセンティブを与えるには、市場やユーザーが求めている 顕在的価値(Real Value)と潜在的価値(Potential Value) が何であるかを分析し、根気よく伝え、それらの価値を創造するための製品やサービスを実現するために技術を身につけなければならないと考えてもらうことだろう。(ものづくり戦略とソフトウェア品質 を参照されたし)

市場やユーザーが求めている価値が何であるかがエンジニアに伝われば、必要な技術が何かを理解できるようになり、ツールや規範もなぜ守らなければいけないのかが分かるようになる。

市場やユーザーが求める価値を実感するには、自分以外の人間に心の底から「ありがとう」と感謝される経験を重ねることが大事だ。自分のくふうで感謝される経験が積み重なれば、どんなくふうをすればプロダクトの価値を高めることができるのか分かるようなる。

このことはカルロス・ゴーン氏が語った「働くことの本質は貢献である」につながる。

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つ見た。

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

2006-10-29

顧客満足を高めるためのエンジニアがするべきこと

日経ビジネス 2006年10月23日号の特集は、日本一○○を売るセールスマン・セールスウーマンの記事だった。この特集記事には10人以上の日本一が登場する。

セールス日本一の秘訣というか、共通の特長はあるか考えてみた。

ひと言で言えばお客さんの立場にたって何が求められているのかを自分なりに考え実践し、目的を達成するための努力を惜しまないということだろう。

ここで考えてみたいのは、セールスマン・セールスウーマンは顧客に直接対応するフロントエンドのパーソンで、ものづくりをしているメーカーから見た場合でも自分たちの商品をユーザーに売ってくれるという意味で彼らはフロントエンドだということだ。

セールスマン・セールスウーマンはメーカーと同系列の社員であるとは限らない。独立した販売店なら複数のメーカーの商品のうち、お客さんが求めていることを聞き出して「ピタッと」きている商品を勧める。

だから、メーカーは日本一のセールスマン・セールスウーマンに成り代わってユーザーが求めていることを調査・分析し、その要求にピタッときた商品を開発しなければいけない。

そうすれば、メーカーの系列ではない独立した販売店の店員も、自分たちの商品を紹介してくれる可能性が高まる。

この話は部品の供給者や、ソフトウェアの受託開発業者にとっては関係ないと切り捨てない方がいい。なぜなら、メーカーは部品やソフトウェアのサプライヤーに「顧客要求を満たすために必要な、安価で品質のよい部品、ソフトウェア」を求めており、それが何なのかを考えるにはエンドユーザーが何を欲しがっているかについて知っておいた方が絶対に有利だからだ。

そう考えると、トップセールスが顧客要求を正確に吸い上げているノウハウをメーカー、サプライヤーサイドのエンジニアが知ることは非常に大事だということが分かる。

<トップセールスが顧客要求を吸い上げるノウハウ>

  1. “お客さんの立場にたって”何が求められているのかを考える
  2. それを“自分なり”に考える
  3. 分析した顧客要求を“実践(実現)”する
  4. 目的を達成するための努力を惜しまない

一見、この4つはマーケティングの技術のようにも見えるが、必ずしも既成のマーケティングテクニックだけで実現できることではないように思える。

たとえば、1の「“お客さんの立場にたって”何が求められているのかを考える」は、顧客へのアンケート調査なので実現できそうな気がするが、トップセールスが実践している顧客要求の分析方法はそのような画一的なやり方ではない。

たとえば薄型テレビのトップセールスウーマンは若干20歳にして、メーカーの新製品展示会があると、休暇を潰してでも見学に行き、開発担当者を質問攻めにする。そして、新機能をリモコンで完全に操作できるようになるまで、展示機の前を離れない。そして、電化製品に詳しくない母親に説明して分かってもらえるかどうか確認する。そして、店頭でこの情報をお客さんに披露し、その反応を見ながら提供した情報がフィットしたかどうかをリサーチしフィードバックする。

2の「それを“自分なり”に考える」という部分は、他社よりもよりフィットしたユーザー要求を吸い上げて商品に反映させるという意味で重要である。ようするに人と同じような調査では他を出し抜くことはできない。ちなみに、このような外部環境を含めた経営戦略分析手法の一つに SWOT分析というのがある。

SWOTとは Strength(強み。内部環境・自社経営資源の強み)、Weakness(弱み。内部環境・自社経営資源の弱み)、Opportunity(機会。外部環境・競合・顧客などからのチャンス)、Threat(脅威。外部環境・競合・顧客からの脅威)の4つの要因の頭文字を会わせたもので、この4つの要因をマトリックスにして、分析する方法である。『通勤大学MBA1 マネジメント』(¥893)を参照されたし。

別の見方をすると日本のトップセールスは、MBAを取らなくても、顧客が何を求めているのかを分析する能力を自らの経験により身につけているということである。

ただし誰もがトップセールスのなれるくらいの分析能力を身につけられる訳ではない。そういう場合は、先人の知恵が体系化されているマーケティングの技術を知って自分の現場のテーラリングすることができれば、人が何十年もかかって蓄積した知恵を効率よく拝借することができるはずだ。

さて、次は3の「分析した顧客要求を“実践(実現)”する」だが、これは関わっている人間の数が少なければ少ないほどやりやすい。トップセールスは自分の中で閉じている環境を持っているので、顧客要求に応えるための戦略を実践しやすいと言えるだろう。

技術者の方はどうだろうか。メカ、エレ、ソフトの技術者がひとりずつといった小さいプロジェクトならば、分析した顧客要求の実践は自分の役割分担の中で実現させることができる。逐一誰かにコンセンサスを得ながら進める必要もない。しかし、プロジェクトの規模が大きくなってくると、プロジェクトマネージメントのテクニックを使わないと顧客要求の実践を効率よく適用させることは難しいだろう。

エンジニアもトップセールスマン・セールスウーマンの気分を味わいたい。トップセールスは顧客の要求にピタッとあった商品を選んだり、顧客が望んでいる使い方をサジェスチョンしたりするのだが、エンジニアは顧客の望んでいるものを作り上げることもできる。

ただ、トップセールスの場合は「分析した顧客要求を“実践(実現)”する」は成功すれば組織全体に利益をもたらし、失敗してもセールルマン・セールスウーマンの販売実績が伸びないという被害にしかならない。

ところが、エンジニアの場合はそうではない。「分析した顧客要求を“実践(実現)”する」が組織的にコンセンサスを得られていない状況で失敗した場合、その影響は個人の責任範囲では済まされない。

機能が足らない、期待した性能が出ていないといった顕在的価値が低いだけならまだしも、エンジニアがよかれと思ってやったことが安全性や信頼性を損ねるような結果になっていると、ユーザーに不利益をもたらし、リコールにより組織に経済的な損失をもたらす。

したがって、「分析した顧客要求を“実践(実現)”する」は技術者の場合は、組織的コンセンサスを得ながら進めていく必要がある。要求分析やユーザビリティの分析結果は、組織としてオーソライズされなければならない。

ただ、そのときにトップセールスが実践しているように、自分自身のオリジナルの分析を盛り込むことは可能だ。ユーザビリティの分析方法としてペルソナ法というのがある。ペルソナ法は、仮想の特定ユーザーを想定して、そのユーザーならこんな使い方をするだろうとか、こんな趣向があるのでこのような機能の提供のしかたが好まれるはずだといった分析をする。

トップセールスが「自分が考えるユーザー像」から、販売戦略を考えるように、ペルソナを想定するときに「自分が考えるユーザー像」を設定するのである。この2つの違いは、トップセールスの場合は自分だけの秘密にしておける可能性があるが、エンジニアの場合は自分だけの秘密にしてしまうと、失敗したときにユーザーに不利益をもたらすような組織的失敗に結びついてしまう危険があるという点である。

最後に、4の「目的を達成するための努力を惜しまない」については、トップセールスもエンジニアも同じだと思う。みんなと同じことをやっていて、競争力の高い商品やサービスを提供できる訳がない。

ただ、トップセールスの場合は個人の中で閉じた話になることが多いが、エンジニアの場合は目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者と、誰かが設計した仕様を忠実にコードの落とす者に分かれる。

どっちのサイドに行くのかはエンジニアの心づもりひとつだが、普通なら「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」と「誰かが設計した仕様を忠実にコードの落とす者」の間には評価に差が生じるはずだろう。

アメリカではエントリーしたばかりのプログラマとアーキテクトやアナリストとのサラリーの差は10倍以上もあると聞いたことがある。

日本の場合、ソフトウェアエンジニアの職種が明確でないこともあって「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」と「誰かが設計した仕様を忠実にコードの落とす者」の間に明確な評価の差がないことが多い。

そうなると、「誰かが設計した仕様を忠実にコードの落とす者」のサイドにいた方が楽だと考える技術者が増えても不思議ではない。

「目的を達成するための努力を惜しまずに、より顧客要求を満たした競争力の高い商品やサービスを提供するための設計を行う者」が組織からルールに基づいた評価を得られる確証がないのなら、自分の努力が顧客満足につながるという方向に持って行くしかないだろう。

しかし、エンジニアの自己努力(多くの場合、オリジナリティを主張した努力)の成否の影響は、自分の中だけに閉じないため、大枠で組織のコンセンサスを得ながら進めていく必要があるのだ。

ここがトップセールスがある程度自分の裁量でいろいろなことができるのと違う部分だ。

したがって、組織はエンジニアの貢献度を客観的に評価するためのシステムを確立できていないのであれば、エンジニアが考えた顧客満足を達成するためのアイディアについて大枠でとらえてオーソライズしながら、ディテールについては権限を持たせて自由にやらせるということも必要ではないだろうか。

ただ、忘れてはいけないのは、顧客要求の中には設計品質の代表さえれるような潜在的価値の部分が含まれており、エンジニアが好き勝手にプログラミングしていたのでは決してソフトウェア品質を高めることはできず、潜在的価値を高めるという顧客要求を満たすことはできないということだ。

「エンジニアにある程度権限を持たせて自由にやらせる」を詳細に分解すると、次のようになる。

  1. 顕在的価値(カタログに載るような機能・性能)については自由度を広げる
  2. 顕在的価値(安全性や信頼性)については、顧客要求を満たすために1とは逆に自由度を制限する
2の自由度を制限するというのは「自由にやらせる」と背反しているように見えるが、組織が作ったルールをプロジェクト内である程度の自由度でカスタマイズしてもよいと考えれば完全否定にはならない。

トップセールスもトップエンジニアも顧客満足を高めたいという目標設定は同じでよい。しかし、エンジニア特にソフトウェアエンジニアの方は、以下の4点を進めるにあたり、エンジニア個人のオリジナリティを持って進めていい部分と、組織やプロジェクトのルールを満たしながら進める部分の両面がある分難易度が高い。
  1. “お客さんの立場にたって”何が求められているのかを考える
  2. それを“自分なり”に考える
  3. 分析した顧客要求を“実践(実現)”する
  4. 目的を達成するための努力を惜しまない
何はともあれ、日経ビジネス 2006年10月23日号の特集で各分野のトップセールスの戦略や努力を見ると「自分も顧客満足を高めるために頑張らねば」という気持ちにさせられる。

2006-10-22

シンドラーのエレベータ事故(つづき)

日経ものづくり 2006年10月号に シンドラーのエレベータの検証記事が掲載された。2006年6月,東京都港区のマンションで起きたエレベータでの事故の原因はまだ分かっていないが、日経ものづくりの記事ではエレベータの構造や安全装置のしくみなど、かなり深いところまで掘り下げておりいろいろと勉強になった。

特集 -事故は語る-「シンドラーの波紋」 記事の内訳】

Part 1 総論
相次ぐ事故に共通する課題
再発防止に三つの視点

Part2 安全装置の裏側
トビラが閉じずに動くカゴ
想定外の事態で表れた弱点

Part3 軽視された保守
自覚のなさが高めるリスク
業者間の責任分担を明確に

Part4 生かせぬ教訓
埋もれてしまう不具合情報
分析と公開が予防のカギ

【引用おわり】

自分が興味があるのは、エレベータの構造とハードウェアデバイス、そしてエレベータの詳細な要求仕様である。これらが分かればエレベータの制御ソフトウェアをどのように作ればいいかだいたい分かる。

組込み機器はユーザーとして使う立場に立てば、その機器の表に出ている制御仕様はだいたい分かる。ソフトウェアの価値である顕在的価値と潜在的価値のうち、顕在的価値の部分は、外に見えているところからその中身を予測できる。

しかし、組込み機器の潜在的価値を構成している「使いやすさ」や「安全性」「保守性」などの部分は、外側からではよく分からない。よく分からないのだが、「使いやすさ」「安全性」「保守性」に使われているハードウェアデバイスがシステムとどのように結合しているのかが分かると、ソフトウェアがどんな制御をしているのかもある程度想像できる。

今回、日経ものづくりの記事で再確認したのは、安全装置に関しては「かご側のトビラ確認スイッチ」「乗り場側のトビラ確認スイッチ」「モータ」「電磁ブレーキ」の関係がベースにあるということだ。

戸開走行しないための安全機能は、かご側のトビラと乗り場側のトビラが両方とも閉じているときのみ、電磁ブレーキを解除し、モータを回転させてよいということだ。

2006年6月の事故では、かご側のトビラと乗り場側のトビラが両方開いてるにも関わらず、電磁ブレーキが効かずにモータが回転してしまった。電磁ブレーキの摩耗の疑いがあるようだが、電磁ブレーキが摩耗していたとしても、それとは別に、トビラの開閉のセンシングを誤り、モータを積極的に回転させなければ事故は起こらないことから、どう考えても運転制御プログラムが怪しい。

そう考えていたら、ソフトウェアの不具合を誘発しそうな要因があることが今回の記事でわかった。それは、戸開走行の例外処理だ。

【戸開走行する例外処理も-「シンドラーの波紋」より引用-】

実は、安全制御装置にはトビラが開いた状態でも電源を投入するようにバイパスが設置されているときがある。それが、再床合わせ装置を持つエレベータの場合だ。

再床合わせとは、ロープの伸びなどによってカゴの床面と乗り場側トビラの床面に発生した段差を調整すること。乗り場の床とカゴの床に段差があった場合に、つまづいたりして危険だからだ。主に、ロープが長い高層エレベータや積載容量が大きいエレベータで採用される。

【引用おわり】

要するに、トビラが開いたときでも再床合わせゾーンの範囲内であれば電磁ブレーキを解除し、エレベータをゆっくりと走行させる。この際には、一種の戸開走行となる。ただし、この例外仕様の安全対策として、再床合わせゾーンを越えてドアゾーンを外れると安全装置がモータへの通電を遮断し、エレベータを制止する。

この再床合わせの戸開走行のソフトウェアは危険を伴う例外的な処理であり、他のソフトウェアに比べて、より慎重により正確に作り込まなければならない。

ここで組込みソフトエンジニアとして思うのは、安全面から考えたときのこの例外処理が他の処理より重要度が高いということを示すのは以外に難しいということだ。

安全装置がハードウェアデバイスとして、メインCPUの制御から独立している場合、その機能や役割は外から見えやすい。メインCPUとのインターフェースも明確であり、安全装置単体としてのテストもしやすい。しかし、安全をつかさどる制御ソフトウェアがその他のソフトウェアと一緒になってしまっていると、その重要性の高いソフトウェアをマーキングして「ここが装置の安全性を確保するためのソフトウェアですよ」と強調したくても、外からその重要性を分からせる方法がないのだ。

結局、ソースリストを追いかけることでしか問題があるのかないのか分からないということになりがちだ。

たとえば仮に、モータを制御する関数の中身が以下のようになっていたとしよう。

void driveMotor( 命令 )
{

  /* モータを止める処理 */
  if ( 命令 == STOP) {
    モータを止める;
    電磁ブレーキON;
  }

  /* モータを正転させる処理 */
  else if ( 命令 == UP ) {
    status = getCageStates();
    if ( status != open ) {
      電磁ブレーキを解除;
      モータを正転させる;
    }
  }

  /* モータを逆転させる処理 */
  else if ( 命令 == DOWN ) {
    status = getCageStates();
    if ( status != open ) {
      電磁ブレーキを解除;
      モータを逆転させる;
    }
  }
}

ようするに、モータを正転、逆転させるという処理に入ってから、ドアが開いていないかどうかをチェックしている。安全のための同じ処理が複数点在してしまっている。

一方、安全確認のソフトウェアはモータ処理とは独立させて監視させたり、モータ制御の関数を呼ぶ前にチェックをし、そのチェックがOKにならなければモータを制御させないという作り方もできる。

問題なのは、ソフトウェアの場合、目的を達成するための方法(プログラムの作り方)はいくつもあり、どのようなプログラミングをしているのかは、外からはよく見えないということだ。

上記のプログラミング構造に、戸開走行の例外処理を追加し、 "SLOWUP" や "SLOWDOWN" などの制御を追加し、付け足し付け足しでシステムを完成させたとしたらどうだろう。

関数の複雑性は増し、テストから漏れるパスが生まれる可能性も出てくる。

試行錯誤でソフトウェアシステムを作り上げる怖さはここにある。外見では同じように動くソフトウェアであっても、潜在的価値の低いソフトウェアはある。ソフトウェアエンジニアがそうしたいと思っていなくても、試行錯誤でソフトウェアを作り上げることで、なかなか到達しにくい部分に爆弾を作り込んでしまうことはあるのだ。

この危険は排除するために、メインCPU(制御プログラム)とは独立した、安全機能の装置を設ける方法はある。しかし、このような独立した安全装置は確実にコストアップにつながるので経済性を優先させようとした場合、取り除いてメインプログラムの中に入れればいいという判断になりやすい。

そうすると、安全機能は外から見えなくなり、キチンと機能しているかどうかわかりにくくなる。

日経ものづくりの記事では、制御装置のプログラムミスの可能性を示唆しているものの、どのようなミスの可能性があったかについては言及していない。国土交通省のエレベータワーキングチームでは、安全装置の独立化と安全制御プログラムに関しては第3者の専門家によって認証・確認する体制を構築することを提言しているらしいが、第3者の専門家による認証・確認というのはたぶん機能しないと思う。

なぜなら、第3者の専門家が安全性に関してお墨付きを与えるということはおそらくできないからだ。安全機能のためのソフトウェアの独立性や完全性は、同じCPUで動いている他のソフトウェアの影響を絶対に受けないという保証ができないだけに、どんなときでもキチンと動くということを証明するのは難しい。スレッド(タスク)を動的に生成しているシステムでメモリリークなどの影響を受けないことを保証することは非常に難しい。

不確定要素がある中で、第3者が安全性を保証することはできない。安全性の検証や妥当性確認は装置を組み上げてユーザーに提供するメーカが行うしかない。完成された部品をシステムに組み込む場合は、それがハードウェアであってもソフトウェアであってもその部品が仕様どおりに動くかどうかを検証することはできても、システムに組み込んだ後の安全性を保証することはできない。

実は、日経ものづくりの記事を読んだ後に感じたのは、「これだけ詳細な内容を記者はよく調べたなあ」という感想と「これだけ詳細な記事の中でソフトウェアについてはほとんど突っ込まれていない」という印象だ。

日経ものづくりは生産や機械設計といった話題が得意分野の雑誌だけに、ソフトウェアにメスを入れろということ自体ムリなのかもしれないが、分かったのはやっぱりソフトウェアは見えにくいということなのだ。探偵のようにエレベータを調べまくった記者もソフトウェアの中身までには切り込むことができない。この見えない世界の中で何が行われているのかは、ソフトウェアエンジニアしか知らない。

だから、ソフトウェアエンジニアが口を閉ざしてしまうと、ソースリストから問題の原因を探るしかない。事故が起こりやすいソフトウェアであればあるほど、構造が複雑であり問題を起こすカラクリを解きほぐすことが難しい。

安全をコントロールするソフトウェアの独立性を高め、その機能や性能の検証が容易になるようにしておかなければいけない。

そして、ソフトウェアモジュールを動かすベースである、オペレーティングシステムの検証は十分に行い、リスクがないことを確認しておく必要がある。

組込みソフトウェアの安全性を高めるための技術はある。それはなんだろうと思った方は『組込みソフトエンジニアを極める』の第4章-品質の壁を越える-を読んでいただければと思う。

以前書いた「シンドラーの事故を再発防止するためにエンジニアは何をすべきか」の記事も参照されたし。

2006-10-15

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

テレビ東京で毎週月曜日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-09

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

日経エレクトロニクス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も十分に使いこなせていないのに、安易にマルチコアプロセッサという解決策へ逃げているように見えるのだ。

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

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

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

2006-10-01

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

ソニーエナジー・デバイス製のリチウムイオンバッテリの回収が話題になっている。回収の規模は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電源につながれていない機器でも大きなエネルギー源を抱えていて危険と隣り合わせにあることがわかったと思う。

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

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

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

2006-09-24

体脂肪を燃やそう!

めずらしく組込みソフトとはまったく関係ない話題。

7月から地元のスポーツクラブに通い続けて2ヶ月半たった。これまで、何をやっても長続きしなかった自分としてはこんなに長続きしているのが信じられない。

そもそも、スポーツクラブに行こうと思ったのは、SESSAMEのメンバーでちょっと太めだった方が久しぶりに会ったら見違えるように昔より細くなっていて、「どうして?」と根掘り葉掘り聞いたところ、週二回くらいスポーツクラブで泳いでいて、運動の前にヴァームを飲んでいるというのだ。

あとから調べて分かったのだが、ヴァームとはスズメバチの幼虫が分泌するアミノ酸組成物らしい。

- VAAM-WEBサイトから引用】

「V.A.A.M.」とは、スズメバチアミノ酸混合液(Vespa Amino Acid Mixture)の略で、その成り立ち、効果など多くの面において他のアミノ酸とは全く異なる、17種類のアミノ酸の混合物です。これは、スズメバチの研究をしていた理化学研究所の阿部岳博士が、1日に約100km移動するというスズメバチの驚異のスタミナに注目。スズメバチの成虫は幼虫に餌を運んでくる代わりに幼虫から特徴的なアミノ酸組成を持つ分泌物を栄養として与えられます。V.A.A.M.と名付けられたそのアミノ酸組成物を経口摂取することによって脂肪燃焼を促進しうることが明らかになりました。

【引用終わり】

よく、体脂肪を燃やすには20分以上運動しないとダメと言われるが、このヴァームを運動する前に飲むと体脂肪がすぐに燃え始めるというのだ。

- VAAM-WEBサイトから引用】

一方の体脂肪はどうでしょう?通常、運動する際には、まずグリコーゲンが消費され、その次に積極的に体脂肪が燃焼されはじめます。一般的にそのタイミングは運動をはじめてから約20分後と言われています。しかし、一般的に体内に蓄えられる体脂肪の量は、体重が60Kgの人の場合で54,000Kcal (※)。これは同じ条件の人のグリコーゲンの蓄積量と比較すると約30倍にあたります。また、疲れの元となる「乳酸」の発生が抑えられるというメリットもあります。

【引用終わり】

ヴァームは医療用ではないので、WEBサイトには効果効能についてストレートには何も書いていないが、パンフレットには運動してからすぐに体脂肪の消費が始まるようなことが確か書いてあった。(薬事法上の届け出を行っていない食品や栄養ドリンクは効果効能をカタログ等にうたってはいけない)

自分はスポーツクラブで運動する前に必ずヴァームを飲んでいる。ヴァーム経験者の方の話では、運動前にヴァームを飲むのと飲まないのでは、疲れ方がかなり違うというのだが、比較したことがないので自分はその違いが分からない。

なぜ、疲れにくいかというと、普通運動すると最初にエネルギーになりやすいグリコーゲンが消費されしばらく運動し続けると体脂肪の方が燃焼される。グリコーゲンが消費されると乳酸が発生し、この乳酸が疲れのもとになる。ヴァームを飲むと、グリコーゲンの消費が押さえられて体脂肪の方が使われるため、乳酸の発生も少なくなり、いざというときのエネルギー源であるグリコーゲンを温存できるというのだ。

グリコーゲンは60Kgの大人で、1,800Kcalしか蓄えられないというから、長時間運動していると乳酸がいっぱいたまってしまうらしい。

- VAAM-WEBサイトから引用】

「グリコーゲン」は直接ブドウ糖に分解できるという、即座にエネルギーに変えられるという利点があります。運動をすると、通常は右のグラフのように、まず「グリコーゲン」が多く消費され、一方の「体脂肪」はしばらくたってから使われはじめます。しかし、「グリコーゲン」が消費されると、疲れの元となる「乳酸」が発生します。
また、「グリコーゲン」は、たとえば体重60Kgの人の場合、一般的に体内に蓄えることができる量はわずか1,800Kcal (※)しかありません。そうなると長時間運動することが難しくなってしまいます。

【引用終わり】

かくして高校生のとき教科の中で“生物”が一番好きでミトコンドリアとか、ATP(アデノシン3リン酸)とか、グリコーゲンとかの話が好きだったソフトウェアエンジニアはヴァームを飲んでから運動することにした。ヴァームを飲んでから運動するのと、飲まないで運動するのを比べたことがないので効果のほどははっきりわからないが、だんだん慣れてきたせいもあって、あまり疲れを感じない。

三日坊主の自分がこんなにスポーツクラブ通いを長続きさせている最大の理由は、心地よい疲れで毎回終えられているからかもしれない。

自分でも驚いたのは、最初プールで25mを4本くらい泳ぐとゼーゼーいっていたのが、最近は途中休みながらなら300mくらい泳げるようになったことだ。

ちなみに子供のころとは違って、今や水泳するときは、水中めがねと耳栓は必需品だ。一度水中めがねを忘れて裸眼で泳いだら、とても泳ぐのがつらかった。泳いでいる最中に水の中が見えているというのは長く泳ぐには結構重要な要素であることがわかった。

ところで、スポーツクラブに通ってわかったのは、何しろクラブに来ている人たちの平均年齢が高いということだ。平均したらおそらく40は越えていると思う。昔では考えられなかったように思うのだが、50代、60代の方達がごろごろいる。

聞くところによると、このクラブは普通会員なら何回来てもいいのでスポーツクラブが社交場となっているのだそうだ。確かに、一度一通りの運動をすると1時間から2時間くらいの時間は潰れるので、健康にもいいし時間をもてあましている人にはちょうどいい暇つぶしであり、情報交換の場にもなる。

スポーツクラブが社交場になるというのは昔ではちょっと想像がつかなかったが、高齢富裕層の増加がこのようなスポーツクラブ需要を押し上げているように思う。

おかげさまで、このスポーツクラブは非常に繁盛し混み合っていて、2ヶ月たったのにプライベートロッカーが空いたという連絡が来ない。(申し込んだときは後5人待ちで、今は2人まちだそうだ)

英会話学校へ通っていたときよりも、スポーツクラブの方が長続きしているのは、たぶん「心地よさ」の要素があるからだと思う。

やっぱり大事なのは、どんなことでも「楽しい」とか「やりがいがある」と感じられることではないだろうか。

2006-09-16

ものづくり戦略とソフトウェア品質

記事をお読みいただく前にお知らせがある。インターネット書店のアマゾンで『組込みソフトエンジニアを極める』の 「なか見!検索」ができるようになった。

なか見!検索」とは、アマゾンのWEBサイト上で書籍のページをぱらぱらめくったり、書籍の中身に対して全文検索できるサービスである。(アマゾンのWEBサイト内でアカウント認証していることが条件になっている)

このサービスは著者にも便利なサービスだ。たとえば「状態遷移」について書いたところを探したいなと思ったら、「なか見!検索」の検索バーに“状態遷移”と打ち込んでリターンキーを押せば、11ヶ所で使っていることがわかる。是非、こちらで試してみて欲しい。

さて、今回のテーマは『ものづくり戦略とソフトウェア品質』である。9月14日、15日、東京お台場のTFTビルで日科技連主催の-ソフトウェア品質シンポジウム-が開催された。このシンポジウムでは何人もの著名な方々が講演されているが、特に印象に残ったのが、広島市立大学情報学部教授 大場充先生の「ソフトウェアのテストと品質保証」と、東京大学大学院経済学研究科教授 兼 ものづくり経営研究センター長 藤本隆宏先生の「ものづくり論とソフトウェア-組織能力とアーキテクチャの視点から-」の2コマだ。

大場先生はソフトウェアテスト・品質保証の専門家で、米国IBMや日本アイ・ビー・エムで培われた実践的なソフトウェア品質保証の話をしてくれる。藤本先生は日本の製造業を生産の現場を中心に調査し、日本の製造業(特に自動車製造)の組織論、ものづくりの優位性について研究されている。

お二人の代表的な著書は大場先生は『ソフトウェアプロセス改善と組織学習―CMMを毒にするか?薬にするか?、藤本先生は『日本のもの造り哲学』などがある。

大場先生も藤本先生もそれぞれちょっとだけ面識があり、ソフトウェア品質シンポジウムが始まる前にプログラムをチェックしておいて講演を聞きに行った。そこでおもしろい発見をした。今回のソフトウェア品質シンポジウムで別々のコマで発表された専門分野のまったく違うお二人が二人とも偶然アリストテレスの話をしたのだ。

大場先生は講演の中で、アリストテレスは物質(実体、存在するもの-Substance-)とは何かを考え、その量的側面と質的側面を分けて考えようとし、量的な側面を表現する言葉として現在の英語の Quantitiy(質量)に相当するギリシャ語を用い、その対立する概念である質的な側面を表現する言葉として「様態」に近いことばを造り、そのことばがラテン語の Qualitas 、英語の Quality の語源となったと語った。

アリストテレスの哲学における「質」は、日本語で言えば「様態」に近い概念で、「ものが存在している様子」を表し、たとえば、水と氷のように水の「液体状」と「個体状」の様態の変化を明確に区別したいという意図から「質」という概念と、それを意味する言葉を創りだしたと大場先生は言った。

ここからがおもしろいのだが、藤本先生はご自分の講演で、大場先生と同じようにアリストテレスを引用して、「アリストテレスはものの中に真意が宿っていると考え、ものは“質量”と“形相”が合体したものであり、“形相”とは品質と設計情報に分離される」と語った。

アリストテレスが物質を表すためにに Quantity(質量) とは異なるもう一つの概念を考え、大場先生はそれを“様態”から Quality(品質)へ変化したといい、藤本先生はそれは“形相”であり、品質+設計情報であると言った。

藤本先生の話では、ものづくりの結果できあがった“もの”には設計者の意図が含まれており、ものを手にしたユーザーはパッケージなどから設計者がものに埋め込んだ設計情報を推定しているとのことだった。藤本先生は壇上でミネラルウォーターのパッケージを示してこの情報も設計情報の一部であると説明していた。

【藤本先生の講義スライドから引用】

-ものづくり現場発の戦略論とは-

広義の「ものづくり」・・・ 人工物に託して、設計情報=付加価値を創造し、転写し、発信し、お客に至る流れを作り、顧客満足を得ること。「ものをつくる」ではなくむしろ「ものに(設計情報を)つくり込む」

ものづくり現場に偏在するものは何か? 実はモノではない。設計である。

したがって、「ものづくり現場発の戦略論」とは、高度5メートルの世界(ものづくり現場)に偏在する「設計情報」にこだわり、製品・工程の設計のありかたを虚心坦懐に観察することから出発し、そこから組み立て直す戦略論である。

[1] ものづくりの組織能力 = その企業特有の「設計情報の流し方のうまさ」
[2] アーキテクチャ = その製品・工程の設計情報がもつ構想(設計思想)

【引用終わり】

藤本先生は、ものの価値は設計情報の価値であり、企業はお客様の方向に設計情報を流す流れを作ることが大事であり、設計情報の流れから無駄を省くことが必要だと言っていた。そして、トヨタ自動車はこの設計情報の流れをできるだけ早く無駄なくするということに集中しており、実際に効果を上げているという。

このような組織能力(Organization Capability) と流れを早く無駄なくするアーキテクチャを構築するには組織としての統合力が必要であり、分業しすぎずに全体が見えている必要があるとのこと。そして、最適化された組織能力(Organization Capability) は他の組織には簡単にまねすることができない。

組織の特長とアーキテクチャの組み合わせを間違えるとあっという間に組織能力を下げ、市場競争力を下げてしまう。藤本先生はIBMの歴史について、昔IBMの組織能力とクローズドのメインフレームアーキテクチャは相性がよかったが、オープン・サーバーのアーキテクチャを採用したことで組織能力との相性が悪くなり、この分野の業績を悪化させた例を挙げていた。

ひとつのブログ記事で藤本先生の考えを語り尽くすことは不可能なので、今回はモノの価値と顧客満足と品質との関連に絞って書きたいと思う。

「ソフトウェア品質とは何か」の記事で、「品質とは、顧客要求を満たし満足させる程度」であると書いた。『組込みソフトエンジニアを極める』の第4章 -品質の壁を越える-では、「組込み製品の価値」には 顕在的価値(Real Value)と潜在的価値(Potential Value)の2種類の価値があると書いた。(冒頭の図)

顕在的価値は簡単に言えばカタログスペックとして掲載されるような機能や性能であり“魅力的な品質”を表す、潜在的価値とは品質の中でも“当たり前品質”と呼ばれるようなものである。

大場先生は一般にソフトウェア品質の定義としてよく引き合いに出される ISO9126 の6つの品質特性「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」は品質に関するひとつの View であり、時代の流れによって品質に対する考え方は変遷しており、“魅力的な品質”と“当たり前品質”といった日本的な価値を重視した考ええ方もあるのでISO9126 の6つの品質だけが品質の定義だとは思わない方がよいと言っていた。

“当たり前品質”は良いからといって評価につながらないことが多いが、悪い場合には企業自体の悪い評価に直結する可能性が高い傾向がある。

さて、藤本先生が語る「ものづくりの競争力」には次のような流れがある。

・ものづくり組織能力(問題解決、改善能力。ジャストインタイム。フレキシブル生産)
 ↓
・裏の競争力(生産性、コスト、生産リードタイム、開発リードタイム、開発生産性など)
 ↓
・表の競争力(価格、性能、納期、ブランド、市場シェア、お客の満足度)
 ↓
・収益力(会社のもうけ、株価)

藤本先生は「アリストテレスはモノを質量と形相に分け、形相は品質と設計情報のことである」と言った。上記のものづくり競争力の流れの最初の2つは設計情報に関係し、後の2つが品質に関係する。

「ものの品質が顧客要求を満たし満足させる程度」であるなら、それは顕在的価値(魅力的な品質)と潜在的価値(当たり前品質)の2つに分解できる。

設計情報(付加価値)を創造し、モノに転写し、発信し、ユーザー至る流れを作ると顧客満足を得ることができる。

・設計情報がモノの価値を生み出し最終的に顧客満足につながる。
・設計情報をモノに転写するときに品質が生まれ、品質が価値を生み出す。

この話は、組込みソフトエンジニアにとっては朗報と言える。ソフトウェアは設計情報の固まりだ。メカやエレキのようにQuantitiy(質量)の要素がないので、100%設計情報であり、その設計情報が顧客満足を高めることに直結する。また、顧客満足の度合いである品質は設計情報を転写するときに生まれるため、ソフトウェアの場合はソフトウェアエンジニアによってのみ品質が作り込まれる。

部品の歩留まりや、寸法のずれ、生産、組み立て効率などの要素がないので、ソフトウェアエンジニアの能力がストレートにモノの価値や品質を作り上げる。

逆に言えば商品の価値や品質を下げる要因がソフトウェアにあった場合、もとをたどると設計情報そのものが悪かったか、それとも設計情報を転写するときに問題があったのかどちらかになる。部品や生産の仕方などに責任を押しつけることはできないので、全部組込みソフトエンジニアに戻ってきてしまうのだ。

組込みソフトエンジニアが設計情報そのものを質を高め、設計情報を転写するときの品質を高めると、企業の組織能力、競争力、収益力が高まる。

組込みソフトエンジニアが技術を磨いてよい設計情報を作り上げ、設計情報を転写する際に品質を作り込むことができれば勝ち、設計情報自体もたいしたことがなく、設計情報を転写する際の品質も低ければ負けということになる。誰のせいにもできない。

やりがいもあるし、いい加減にしたときのしっぺ返しも強い。因果な商売である。

2006-09-10

組込みソフトの安全性

今 、組込みソフトを搭載した組込み機器は世の中にあふれている。携帯電話、FAX、エアコン、TV、リモコン、ミニコンポ、プリンタ、エレベータ、自動車、信号機、自動ドア、電子レジスタ、医療機器、鉄道、飛行機などなど。

そして、組込みソフトが原因となって社会問題に発展するような事故も少なからず起きている。

今回は、組込みソフトの安全性について、『組込みソフトエンジニアを極める』のプロローグの一節から考えてみたい。

【『組込みソフトエンジニアを極める』-プロローグ-より引用】

組込みソフトエンジニアがハードルや壁を乗り越えゴールに到達するまでには、高いモチベーション(動機付け)が必要です。では、組込みソフトエンジニアは試練を乗り越えて技術を高めるためのモチベーションをどこに求めればよいのでしょうか。

ひとつは、常に追いつめられながらギリギリの状態で仕事に取り組まなければならない悪循環から抜けだし、開発効率を高め余裕を持ってクリエイティブな気持ちで仕事に臨めるようになるため、そして、もう一つは魅力的な製品を開発し、ユーザーに信頼を持って快適に使ってもらい次回も自分たちの製品を選んでもらえる自信が持てるようになるため、この2つ理想が試練を乗り越えるためのモチベーションの源泉になります。

組込みソフトウェアは単に組込み機器の中で動くソフトウェアという意味ではありません。組込み機器は、さまざまな形状の外観を持ち、さまざまなユーザーインターフェースで人々の生活の中に入り込み、生活の表舞台に、あるいは、生活を支える裏方として役に立っています。組込みソフトウェアは、その心臓部であり、コントローラです。そして、組込みソフトエンジニアには自分たちが作ったソフトウェアが組込み製品の中で重要な役割を果たしているという喜びと満足感があります。

しかし、その喜びや満足感の後ろには大きな責任もあります。組込み機器が私たちの人間の身近にあって役に立っているということは、一歩間違えば組込み機器は人間を傷づける凶器にもなりかねないということです。特に組込みソフトウェアは中部の構造が見えにくいにも関わらず、設計の自由度が高いため、設計者の意図に反して社会的な問題を起こしてしまうことも残念ながらあります。

私たちは、ものつくりの喜びを感じながらも、自らの技術を磨き、組込み機器を使ってもらうエンドユーザーの満足を満たしつつ、安全で信頼性の高い組込みソフトウェアを世に送り出す義務を背負っています。

組込みソフトエンジニアは、目的を達成するための技術を磨き極めることで、仲間と創造の喜びを分かち合うことができ、便利なだけでなく安心して使える魅力的な組込み機器を世に送り出すことが可能となり、社会と組織への責任を果たすことができるのです。

日本の組込みソフトエンジニアを取り巻く環境を振り返ると、組込みソフトプロジェクトでは、技術者のぎりぎりのがんばりで増加した要求や計画された製品のリリース期限をこなしているという現状があります。場合によっては、プロジェクトに新しい人を投入することで解決しようとする組織もあるでしょう。

しかし、安直な増員はかえって技術者の負担を増加させることになり悪循環からなかなか抜け出すことはできません。組込みソフトエンジニアは技術を磨き極めることでのみ、悪循環を脱し、好循環の世界に突き抜けることができるのです。好循環の世界に入ることができれば、高い品質の組込みソフトウェアを効率よく開発することが可能となり、今リリースしている製品よりももっと顧客満足を高めることのできる商品を作り出すことができます。効率化によってできた余裕でオリジナリティの高いアイディアを考え、新しいキーデバイスの導入をハードウェア技術者と検討することも可能になります。

組込みソフトエンジニアを極める目的は、ものつくりの喜びを分かち合い、生活を豊かにし安心して使える商品を世に送り出し、商品をより競争力の高いものに引き上げ競合他社に打ち勝つことにあるのです。そこに至るまでの道のりは長く、途中にはハードルや壁が横たわっています。私たち組込みソフトエンジニアは、到達すべきゴールから目を離すことなく技術を極めることでハードルと壁を乗り越え、悪循環から好循環への境界を突破できるのです。

【引用終わり】

組込みソフトエンジニアは組込み機器を世に送りだし、自分が作った機器が社会の中で役立っているという喜びや満足感を得ることができる、しかし、その喜びや満足感の後ろには大きな責任もあると書いた。

組込み機器が私たちの人間の身近にあって役に立っているということは、一歩間違えば組込み機器は人間を 傷づける凶器にもなりかねない。

組込みソフトはハードウェアを制御することができるが、ハードウェアが扱うエネルギーの大きさを考慮せずに設計することもできてしまう。

CPUに接続されているポートを ON/OFF するだけで、巨大なクレーンのアームを動かしたり、エレベータを昇降させることができる。

組込み機器に搭載するソフトウェアの規模が小さいときは、組込みソフトエンジニアはプログラムを書きながら組込み機器の動きを想像することができた。しかし、ソフトウェアの規模が10万行を越えて100万行クラスになってくると、今作っているソフトウェアモジュールがシステム全体の中でどのような役割を担っているのか、どのような優先度で動いているのか分からなくなったりすることがある。

特に、システムの一部をオフショアに出したりすると、一部の機能を任されたプログラマ達は、システムがどのようなエネルギーを扱うのか分からないまま、現在ある情報だけでソフトウェアを作ることになる。

規模の大きいソフトウェアの信頼性を高め安全性を高める方法はあるが、唯一の解決策、ゴールドスタンダードはない。

ソフトウェア開発のプロセスを定義し、プロセスのインプットとアウトプットを Verification(検証)し、不整合なないことを確認する。また、設計の努力によって不具合の作り込みを減らし、テストやレビューなどによって、不具合を摘出する。そして、作り上げた組込みソフトウェアと組み込み機器がユーザーニーズに合致しているかどうかを Validation(妥当性確認)する。

また、想定されるリスクを防止、軽減するためにどんな対策をすればよいか考え、その対策を確実に実施したことを確認し、過去に起こした不具合の再発を防止するための対策を追加し、他の機器で起こった問題が自分たちの機器にも起こりえないかどうかを分析する。

不具合の発生件数をトレースしたり、継続的な技術者教育を行うことも大事だ。

いろいろなアクティビティはあるのだが、ひとつ言えることは、自分たちがリリースする機器が社会の中で安全に働いて欲しいという強い思いと、安全な作品をリリースしているという自覚と、裏付けのある自信がなければダメだ。

組込みソフトウェアの規模が小さいときは、製品の開発に関わるソフトウェアエンジニアのすべてが自分の作ったソフトウェアにそのような自覚を持っていた。

しかし、規模の大きくなってしまった現在では、組込み機器を組込みソフトを安全で信頼できるものにしたいという自覚を持った技術者がシステム全体の安全性や信頼性の実現を確認していかなければいけない。

組込みソフトの安全性の確保、妥当性の確認には終わりはないのだが、組込み製品が抱えるリスクの大きさによって、その努力はより慎重により深く実施されなければいけない。

組込みソフトエンジニアのモチベーションの源泉である “自分が作ったものがユーザー個人や社会に役立っているという喜び” が、その思いとは裏腹に人を傷つけ、社会問題を起こさないようにためには、自分たちが作るソフトウェアの安全性や信頼性を高めるための設計技術・検証技術を獲得し実践するしかないのである。

2006-09-03

2006年3月から8月までの記事の索引

今回は、これまでこのブログ『組込みソフトウェア工房』に書いた記事・エッセイの索引を作ってみた。リファレンスリストを作ってみると、組込みアーキテクチャや人材育成に関する記事が多いことがわかる。裏を返せばやっぱり、組込み機器の開発を成功させるにあたっていろいろ壁になっているのがこの2つのテーマなのかもしれない。

★はお勧め記事

--- 組込みソフトウェア工房 記事リファレンスリスト 2006年3月~8月 ---

組込みソフトエンジニアを極める
組込みソフトウェア工房へようこそ
なぜ、『組込みソフトエンジニアを極める』を書いたのか?
★『組込みソフトエンジニアを極める』に送られたメッセージ
★『組込みソフトエンジニアを極める』に送られたメッセージ2
缶バッジ


【ソフトウェア品質に関するもの】
★★シンドラーの事故を防止するためにはエンジニアは何をすべきか
★ソフトウェア品質とは何か

【日本人の気質とソフトウェア開発】
★ISO9000やCMMIに違和感を感じませんか?

【エンジニアとしてのスタンス】
★働くことの本質は貢献である
権限もいらないから責任も取らないってあり?

【組込みアーキテクチャ・アーキテクト】
すり合わせと組み合わせ
音声のプロフェッショナル
★TOYOTAの組込みソフトウェアに関するリスク
リアルタイム設計技術の難しさ
★★T-Engineに乗ったやつは勝ち組か負け組か?

【技術者教育・鍛錬、人材】
新人技術者へのハードルは確実に高くなっている
組込みソフトエンジニアの情報検索能力は低い?
★★仕様書を書かないエンジニア
★教材がいいと受講者の食いつきが違うね
★美食を極めるには不味いものを食べるべし
なるほど、これが海外人材登用の新しいかたちなんだ
英語は苦手
30代が主役

【マーケティング】
★マーケティングの重要性
★洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない

【組込みソフト開発に役立つ雑誌・書籍】
組込みプレス vol.3
どんな本を読むといいか?

【人間の脳とソフトウェア開発について】
★考える脳考えるコンピューター
小学生の問題も解けないなんて!

【役立つツール】
★Lifehacks って知ってた?(僕は知らなかった)
Mindmapで幹を太くする方法

【再利用・プロダクトライン】
プロダクトラインがNEのカバーストーリーに登場
Nokiaの技術戦略

【その他】
ライオンと魔女

2006-08-27

洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない

非常に古い話である。1993年の日科技連のソフトウェアの品質管理セミナーに参加したとき3日目の東京理科大の高橋武則教授の講義で「品質とは顧客満足度である」というテーマを「秋葉原に洗濯機を買いに行く」というたとえ話で聞いた。

当時29歳の自分にとって、この話は青天の霹靂だった。大げさだがこの話を聞いて製品開発をする場合に何を目標にすべきかということをイメージとしてつかんだと思う。

この話は『組込みソフトエンジニアを極める』の第3章 -再利用の壁を越える- の中で「洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない」というコラムで紹介している。古い話だったし、テキストにも書かれていない内容だったので出典情報は書かなかった。高橋先生ごめんなさい。

さて、今回はこのコラムを引用する。

【洗濯機メーカーは新しい洗濯機を開発しようとしてはいけない】

現在東京の秋葉原は電気製品のメッカというイメージから、別な意味での聖地と変わりつつあるようです。ところで、1980年代、郊外に大型家電量販店がなかったころ、地元の電気屋さんではなく秋葉原に家電製品を買いに行く人々がいました。なぜ、秋葉原に洗濯機を買いに行ったのでしょうか。もちろん、秋葉原の電気店では最新の商品が豊富に取り揃えられており価格も安かったということが一番の理由でしたが、秋葉原の店員は各メーカーの洗濯機の特長を熟知していて、予算や使い勝手などの要求に応じて一番ピッタリ合う洗濯機を選んでくれるだけの知識と販売の経験(洗剤はどれくらい使うのか、乾燥機能はついているのか、サービス体制は万全かなど)を持っているという理由も大きかったと思います。

2000年代になって家電製品はインターネットで激安のものを購入できるようになりましたが、いろいろなメーカーの商品をおしなべて比較し、誰かにアドバイスしてもらいたいという買い手側の要求はまだあります。その要求に答えるように、都市近郊では郊外に家電量販店の大規模店舗が出店するようになりました。郊外の家電量販店では、かつて秋葉原の電気店の店員が行っていた販売のノウハウがマニュアル化され秋葉原へ行かなくても、地元で最新の機種を適切なアドバイス付きで購入できるようになりました。賢いユーザーはこのような家電量販店で商品の知識を仕入れてインターネットで最も安く買える店を探すのかもしれません。

さて、販売側がこのように商品だけをただ売るだけでなく、商品+サービス(商品知識とアドバイス)をセットにして売るようになってきたことを考えると、作り手側はどのようなスタンスで物作りをしていけばよいのでしょうか。

この問題を考えるおもしろい例題として洗濯機メーカーが新しい商品を開発するときに、「どのような洗濯機を作ろうか」と考えてはいけないという話があります。洗濯機メーカーならずともメーカーは新しい商品を企画する際に現行モデルをベースにして新しい機能を追加しようと考えがちです。なぜなら、現在販売している商品は目に見える「物」でありその機能や性能について自分たちは熟知しており、お客様からの評判や要望もある程度把握できているので、それをベースに新しい商品を考えることが最も自然だからです。

しかし、このようなアプローチには大きな落とし穴があります。なぜなら、洗濯機を使っているユーザーの真の目的は衣類を洗濯することではないからです。洗濯機を使っているユーザーは決して洗濯をすることが本当の目的ではありません。ユーザーの本当の目的は「汚れた衣服をきれいにすること」です。へりくつのように聞こえるかもしれませんが「洗濯機で洗濯すること」と「汚れた衣服をきれいにすること」未来永劫、同等だとは言い切れないのです。

なぜなら、例えば、自宅近くに、もしも、ワイシャツ1枚を10円でクリーニングするクリーニング屋が現れ、夜玄関脇のボックスに洗濯物を入れておくと朝にはきれいになって戻してくれるようなサービスを始めたら、それでもユーザーは洗濯機で洗濯するでしょうか。もちろん、21世紀になってもそこまでクリーニング料金が安くなるような時代にはなっていませんが今後絶対にそのような状況が現れないとは言い切れません。人々のライフスタイルが変化したり、新しいデバイスが発明されたりすることにより既存の考え方が一変することはよくあるのです。

したがって、洗濯機メーカーは新しい洗濯機を開発することを考えるのではなく、お客様の要望(この場合は衣服をきれいにするということ)を満足するための商品またはサービスとは何か、また、現在の技術や新しい技術を開発することによってどのような商品またはサービスを提供することができるのかを考える必要があるのです。そうやってユーザー要求を第一に考えた商品やサービスと現行商品に新しい機能を付け加えたものがイコールであるとは限らないのです。洗濯機自体がいらなくなる時代だってくるかもしれません。目の前にある形あるものにとらわれないようにしないと時代に取り残されてしまう危険性があるのです。

【引用終わり】

実際、1993年当時ではまったく予想できなかったのではないかと思うが、今ではドラム型でしかもヒートポンプ式の乾燥機が内蔵されている洗濯機まである。

商品開発のディスカッションで何も考えないで話をしていると、今の製品の一部の機能を新しくしたり、他社製品のいいところを取り入れたりといった誰でも思いつくアイディアしか出てこないことが多い。

ユーザーニーズの本質にまで立ち返って、ユーザーが本当に求めているものを、現在世の中にあるあらゆる技術やデバイスを使って実現できるかどうかを考えなければいけない。

イノベーションを起こすためには現実を一度破壊しなければいけないが、組込みの場合、アーキテクトは新しい技術やデバイスを使ったときの実現可能性についてできるかどうかピンとこないといけない。

そのためには、常日頃、まったく関係ない業種であっても新しいデバイスやサービスが現れてきたら、自分のドメインで使えるかどうか考えるくせを付けることが大事だ。

今回の話題は「マーケティングの重要性」の記事にも書いているのでこちらもお読みいただきたい。

2006-08-20

仕様書を書かないエンジニア

組込みソフトエンジニアを極める』の第4章-品質の壁を越える-の中に組込みソフトウェアプロジェクト簡易評価指標を載せた。

組込みソフトウェアプロジェクト簡易評価指標の10個の質問事項は、ジョエル・テスト(The Joel Test: 12 Steps to Better Code)を参考にしたものだ。2005年の12月に、このジョエル・テストを考えた Joel Spolsky 氏の翻訳本、『Joel on Software』が出版された。

Joel Spolsky 氏はMicrosoft にいたとき、Excelの開発に携わっていたソフトウェアエンジニアで、彼のウェブログ Joel on Software は、独立したプログラマ向けのサイトとしては最も人気のあるものの一つである。

組込みソフトエンジニアを極めるで紹介した 表4.6 組込みソフトウェアプロジェクト簡易評価指標】
  • コーディングルールを定めているか?
  • 障害票データベースを持っているか?
  • ソース管理システムを持っているか?
  • 開発の節目節目でレビューを実施しているか?
  • スケジュール表を常に更新しているか?
  • 仕様書を作ってからプログラムを書き始めているか?
  • プログラムを変更した後の回帰テストは実施しているか?
  • 買える範囲で一番良い開発ツールを使っているか?
  • OJT以外に技術者教育のカリキュラムを持っているか?
  • テスト担当者はいるか?
参考:ジョエル・テスト(The Joel Test: 12 Steps to Better Code)
The Joel Test とはソフトウェア開発チームを評価する簡単なYes・No形式のテスト

Joel on Software』は、Joel Spolsky 氏のウェブログ Joel on Software をベースにしたもので、そのフランクな語り口がとても軽快でおもしろい。具体例が満載でネタの宝庫だ。

今回は、エンジニアがなぜ仕様書を書かないのかについて Joel Spolsky 氏が書いたことについえ考えてみたい。

【Joel on Software 第5章 やさしい機能仕様 パート1:なぜわざわざ書く必要があるのか? より引用】

2000年10月2日 月曜

ジョエルテストを発表したとき、読者から寄せられた最大の不満の種は、仕様書を書かなければいけないということだった。前にも行ったことだが、仕様書はデンタルフロスみないなもので、みんな書かなきゃいけないとは思っているけど、誰も書かない。
 
なぜみんな仕様書を書きたがらないのだろう? 人々は、仕様書作成フェーズを飛ばして時間を節約しているんだ、と主張している。彼らは、仕様書作成がNASAのスペースシャトルのエンジニアや巨大な保険会社で働いているような人たちのための贅沢品であるかのように振る舞っている。戯言だ。何よりも仕様書を書かないということは、あなたがソフトウェアプロジェクトに持ち込む、最大かつ不必要なリスクなのだ。それは着替えだけリュックに詰めて、その場になれば何とかなるさとモハーベ砂漠を横断に出発するのと同じくらい愚かなことだ。仕様を書かずにコードに飛びつくプログラマやソフトウェアエンジニアは、自分たちがかっこいい早撃ちガンマンであるかのように思う傾向がある。そんなんじゃない。彼らはとても非生産的だ。彼らはまずいコードを書き、お粗末なソフトウェアを作り、まったく必要のない大きなリスクを負うことでプロジェクトを危険にさらしている。

     :

<ここに仕様書を書いた場合と書かない場合の具体的な例が入る>

     :

この物語の教訓は、人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからないということだ。ワープロ文書の段落を1つ削除するのを残念に思う人はいない。しかし、あなたがプログラミング言語で製品をデザインしているなら、反復デザインには何週間もかかる。さらに悪いことに、あるコードを書くのにほんの2週間かけただけで、プログラマは、どんなにまずいコードであっても、そのコードにとても執着するようになる。たとえそれが最高のアーキテクチャを表現していなくても、上司や顧客が何と言おうとも、スピーディにその美しいコンバータのコードを捨てさせることはできない。その結果、最終的な製品は、初期の間違ったデザインと理想的なデザインとの間の妥協の産物になりがちだ。それは、「すでに書いてしまったコードがあり、そのコードは捨てたくなかったので、それを前提とすれば私たちに得られた最良のデザイン」ということになる。これは「私たちに得られた最良のデザイン」ほど良いものではないのだ。

これが仕様書を書く大きな理由の1番目だ。大きな理由の2番目はコミュニケーションにかかる時間を節約できるということだ。あなたが仕様書を書いておけば、プログラムがどう動くと想定されているか一度だけ説明すれば済む。チームのみんなはただ仕様書を読めばいいからだ。品質保証の人たちは、プログラムがどう動くと想定されているかを知るために仕様書を読み、何をテストすればよいのかを理解する。マーケティングの人たちは、Webに載せるための、まだ作られていないベーパーウェア製品のホワイトペーパーを書くときに仕様書を使う。ビジネス開発の人たちは仕様を読み違えて、その製品がいかに禿やイボによく効くかという奇妙なファンタジーを紡ぎ出すかもしれないが、それで投資家を引き寄せられるのだから、それはそれでOKだ。開発者たちはどういうコードを書くべきか知るために仕様書を読む。顧客は開発者の作っているものが自分たちの欲しい製品であることを確認するために仕様書を読む。テクニカルライターは仕様書を読んでマニュアルを作る。マネージャは経営会議で何が起こっているかについて知っているような顔をするために仕様書を読む、などなど。

【引用終わり】

前半の仕様書を書く第1番目の理由「仕様書を書かないと、すでに書いてしまったコードが既成事実になってしまい、デザインの修正に時間がかかる」の説明はよく分かる、実際その通りであり現場をよく観察していると思う。それに対して、第2番目に理由は、日本のそれも組込みソフトの開発現場に照らし合わせたとき「そうだ、そのとおり」と相づちが打てるだろうか。

チームのために仕様書を書くという点は分かるものの、「品質保証の人たちのために書く」「マーケティングの人たちのために書く」「ビジネス開発の人たちのために書く」「顧客のために書く」「テクニカルライターのために書く」「マネージャのために書く」というところが引っかかる。一つ一つそうなっているのか検証してみよう。

「品質保証の人たちのために書く」は、品質保証担当がソフトウェアをテストするのに、仕様書をもとにテストケースを作るから仕様書が必要だということだ。でも、10人以下の組込みソフトプロジェクトでは、プログラムの作成者が自分で自分の作ったプログラムをテストしたりする。そうなると仕様は自分の頭の中にあるということになる。

次に「マーケティングの人たちのために書く」はまだ完成していない製品のホワイトペーパーを書くときに仕様書を使うとあるが、組込み製品の場合はホワイトペーパーは書かない。

「テクニカルライターのために書く」は、取り扱い説明書の原案をソフトウェアエンジニアが書いたりする。

「マネージャのために書く」もそうだが、何しろ日本の小規模な組込み開発では、製品の機能仕様について知りたいプロジェクト外の人間は、直接製品開発をしているエンジニアに仕様について聞く。人の流動が少ないので誰が製品仕様について詳しいか知っているし、知らなくてもプロダクトマネージャに尋ねると「彼に聞いて」などと言われる。「仕様書を読んでくれ」とはなかなか言わない。仕様書を読まなくても聞きたいことを直接聞けるから仕様を知りたい側は楽だ。

プロジェクト外の人間のみならず、プロジェクトの内部でも製品の機能仕様を一人のアーキテクトが作っていたりすると、エンジニアもマネージャも誰も彼もが、その一人のアーキテクトに仕様を聞きに来る。

要するに人間仕様書だ、いや生き字引だ。そのエンジニアがすべての仕様を知っていて、その人に聞けばだいたいのことがわかってしまう。そんなエンジニアがあなたのプロジェクトにもひとりぐらいいるのではないか?

権限もいらないから責任もとらないってあり?」の記事でも書いたように、日本の組込みソフトウェアプロジェクトは責任と権限が曖昧な場合が多い。責務が曖昧だから、仕事の分担がはっきりせず、人間仕様書状態が発生しやすい。

しかし、人間仕様書状態の発生により日本の組込みソフトウェアプロジェクトは2つの大きなリスクを抱えることになる。1つ目は、生き字引となっているアーキテクトが何かの理由でプロジェクトから離れたり、会社を辞めたりするとものすごく製品開発の生産性や品質が落ちる。また、後を引き継いだアーキテクトはろくな仕様書がないから非常に苦労することになる。

2つ目のリスクは、人間仕様書となっているアーキテクトに情報が集中してしまい大きな負荷をかけることにる可能性があるということだ。知らず知らずのうちにそのアーキテクトへの負担を累積させて潰してしまう危険がある。

人間仕様書となったアーキテクトは潰れないまでも、いろいろな会議に呼ばれ、マネージャが外部の人間から製品の仕様について説明を求めら得ると「それは○○君から答えさせます」などと振られる。どこに何が書いてあるか知らなくても、人間仕様書が必要な情報を適宜加工してアウトプットしてくれるので非常に便利だ。

しかし、機能仕様について尋ねられると、自分のやっている作業が一時的に止まるので集中が途切れる。だから、質問が来なくなる残業時間の間に集中して自分の仕事をやったりする。

ああ、無情。悲しきアーキテクトよ。人間仕様書状態から彼を解放せよ! と叫んでみても始まらない。人間仕様書となっているアーキテクトが、この状態を解消しようとしてがんばって紙の仕様書を書いても、彼に聞いた方が早いので仕様書の方を読んでくれないのだ。

大規模なビジネス系のプロジェクトでもろくに仕様書が書かれないのなら、小規模な組込みソフトプロジェクトで人間仕様書状態を解消するのはかなり大変だ。

いまは小規模でも、ソフトウェアの規模が増大し、一人のエンジニアが製品の仕様全体を把握できなくなったときに、仕様書がないことでプロジェクトが破綻するのを待つか、それとも人間仕様書状態になっているアーキテクトにしばらく倒れてもらうか・・・

現時点では、いいアイディアが浮かばないが、もしも、ドキュメントがなくて困っているプロジェクトマネージャやアーキテクトがいたら、『Joel on Software』を読んで、この本に書いてあるいろいろなシチュエーションの具体例の中から解決のヒントをつかんでいただきたい。