2006年6月25日

ソフトウェアの時代と職人、あるいはMeister

 以前にFORUM×ATOSで書いた話だが、最近のあらゆる「乗り物」は、かなりの部分がソフトウェアで制御されている。

 そのソフトウェアが暴走するといかに恐ろしいか思い知らされる事故が起きた。港区でのエレベーター事故である。

 同種の事故を防ぐには、設計から保守まで情報が共有される必要がある。一つの製品を一貫して扱う「職人」としてメーカーが機能することはできないだろうか。

 内部仕様は公開しないまま「WHQLテスト」や「ロゴプログラム」で連携するMicrosoftとハードウェアベンダーの関係が参考になりそうだ。決して手の内を見せない師匠と切磋琢磨するたくさんの弟子たち。一見すると非合理的だが、実は非常に合理的なのではないか。

 ソフトウェアに明らかな「バグ」(欠陥)はないのに、動かしてみると特定の条件でまずい動作をしてしまう。こうした状態は「不具合」と呼び分けられる。プログラミングの経験がない方から見れば「バグも不具合も同じことじゃないか」「言い逃れをしている」と思われるかも知れない。

 バグがあるとソフトウェア自体が動作しない。ソースコードを丹念に追えば必ず見つけられるので、バグを取り除く手順を「デバッグ」と呼んで、開発スケジュールの中に組み込むことができる。自動的にデバッグを行うツールもある。一方、ソフトウェアの動作としては正常であるが、開発者の意図に反する動きをするのが不具合だ。報告された現象を再現して何が起きているのかを調べないと解消できない。不具合の解消を自動化することは、天と地がひっくり返っても不可能だ。バグと不具合はまったくの別物であることがおわかりいただけるだろう。

 特に、ノイジーな環境で動かすものとなれば余計に意図しない条件が絡んでくるだろう。意図した通りの安全な動作を確保するのは大変に難しいということになる。ソフトウェアも回路の設計も問題ないのに、定期点検時にリセットしただけでおかしくなる、ということもあるかも知れない。ソフトウェアの開発側は「ソフトウェアに問題はない」というだろうし、機械の保守をする側は「機械に問題はない」というだろう。

 どちらの言い分も間違っておらず、その狭間で問題が起きている可能性が高い。お互いに相手の担当部分のことはよくわからないので、境界となるインターフェイス部分の設計には曖昧さがつきまとう。良好な協力関係や全体を見渡すことのできる責任者の存在が不可欠だ。技術というよりは極めて人間的な問題であるといえる。

 不具合の原因究明には、現象の再現が欠かせない。しかし、事故機は異常な動作で天井に激突したという。部品の交換が余儀なくされ、当初の誤動作であるところの「ドアが全開のまま上昇開始」という不具合が再現できる可能性は低下した。エレベーターは建物に合わせて設置され調整されるものであり、別の場所に設置された同型機で同じ不具合が再現できるとも限らない。事故機と同じロットの製品を、まったく同じ条件と手順でセッティングしない限り、不具合は再現できないかも知れない。不具合の中には、そこまで局所的な現象も含まれるのである。

 条件の違いを少しでも減らして品質向上につなげようとすれば、設定のソフトウェア化、製品のモジュール化、現場作業の削減(工場で調整を済ませておく)ということになる。いずれも、事故機のメーカーのみならず今時のメーカーならどこでもやっている真っ当なアプローチである。しかし、それによって不具合が隠れて見つかりにくくなってしまったのは皮肉なことである。昔の電化製品は街の電気屋さんでも修理することができたのに、最近のものは高い修理代をメーカーに納めるか、あきらめて買い換えるしかないというのと似ている。現場のエレベーターも、最終的には別の製品と交換することでしか住民を納得させられないのではないかという気もする。しかし、新しい製品が確実に動作することを、誰がどうやって確かめればいいのだろう。

 一人でソフトウェアから機械まで面倒を見られる、一つの製品について最初から最後まで徹底して関われる「職人」のようなエンジニアを育てていくというのが、唯一の前向きなベクトルといえないだろうか。さすがに「職人文化」が育まれた時代とは背景が違うのでそれは難しいとすると、例えば製造物責任法の考え方の延長線上で、必ずメーカーがメンテナンスに関わらなければならないとしてもいいのではないか。メーカーという法人そのものが「職人」あるいはそれを率いる「マイスター(Meister)」として機能するように仕向けるべきであろう。日常的に大量のフィードバックが得られるようになれば製品開発の刺激になる。メーカーにとっても損はないはずだ。

 報道を見ると、メーカーが技術情報を一切開示しないので、メーカーの系列でない管理会社は大変苦労しているという。ただ、例えばPC用ソフトの業界を考えれば、MicrosoftだってWindowsの内部は明らかにしていない。開発用の機能の使い方は教えてくれるので、開発する各社はそれぞれに試行錯誤しているわけだ。自社の製品がきちんと動作するかは、各社の責任の下で確認されている。

 ハードウェアにしても例外ではない。周辺機器メーカーは四苦八苦してドライバを開発してきた。以前はまともに動かないドライバの何と多かったこと。Microsoftがドライバの認証をしてくれるようになってからは、かなり安定度が増している。ここ数年、ブルースクリーンを見た記憶がない。最近使い始めた人なら「ブルースクリーンって何?」というかも知れない。Windowsの内部を秘密にしたままでも、オープンで実効性のある動作保証の仕組みが作れるという好例であろう。

 エレベーターのメーカーも、管理会社のスキルを認証する仕組みを作ればいいのではないか。もちろん、その認証はなんら公的なものにはならない。(こうした場面ですぐに公的な認証を求める世間というのは、前近代的すぎると思う。)しかし、建物のオーナーが管理会社を選ぶ時に、「うちのエレベーターはA社製だから、A社の認証をパスしている管理会社を選ぼう」などと参考にすることができる。

 適正な競争のためには、メーカーが何もかも情報を出してしまうわけにはいかない。情報は出さず、しかし協調はするという、これは「失敗学」の畑村氏の持論であるが、そういうことで何とかなるのではないか。もちろん、自社の系列だけを有利にするようなやり方は許されない。どれだけのことができるか、日本のメーカー各社にも試練が課せられているといえる。

 余談だが、エレベーター業界の特徴の一端は、例えばこんなところにも現れている。エレベーターの内装にバリエーションが乏しいと思われたことはないだろうか。エレベーターのメーカーが用意する数種類の内装で満足できるのは、デザインに疎い建物のオーナーぐらいのものだろう。不満を持つ建築家やインテリアデザイナーは少なくないはずだ。安全性を損なわずにサードパーティー製の内装材が選べるようになれば、ファッショナブルなエレベーターも登場してくるに違いない。あるいは建築家が建物のデザインと合わせてエレベーターをもデザインできるようになるかも知れない。

日経BP SAFETY JAPAN「失敗学法則の解説インタビュー(後編)」

 > 事故の原因を企業体質に求めれば、当事者以外の企業や組織は思考停止に陥り、
 > 「我が社はJR西日本や三菱自動車とは違う」と結論づけてしまう。これでは失敗を生かすことができません。
 > 同業他社も多かれ少なかれ似たような行為をおこなっているでしょう。

 エレベーターについても、まったく同じことがいえるはずである。

 エレベーターの事故ではドアに挟まれたわけではなく、ドアは開いたままであった。いわば、「ドアプロジェクト」は上位のレイヤーでの検証だったのであり、下位のレイヤーは既にしっかり作り込まれていて問題がないことを前提にしていたわけである。今回のエレベーター事故では、ドアの開閉速度やトルクが云々という以前の部分、ドアの開閉検知やドア以外の部分の不具合が原因となっていることが考えられる。

 「1:29:300の法則」に従えば、膨大な数の「ヒヤリハット」が存在することになる。これらを一々書式の定まった文書にして伝達していては追いつかない。だからこそ、「ちょっとあの部品のことだけど…」などと技術者同士が口頭で伝達しあえる環境がなければならないのである。それが無理なら、せめてグループウェアでも使って些細なことでも共有できるようにしなければならない。

 何しろソフトウェアで動く時代である。ソフトウェアの問題を解決するのにも、ソフトウェアを大いに役立てたいものである。
posted by tht at 14:06 | コメント (0) | トラックバック (0) | ながめよみのすすめ
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。
この記事へのTrackBack URL
http://blog.sakura.ne.jp/tb/900955
※ブログオーナーが承認したトラックバックのみ表示されます。