シンドラーのエレベータを考える

先日、扉の開いたまま上昇をし、間に挟まって高校生が命を落とすという事故があった。同じエレベータを私の出身大学である東工大でも使っており、半年くらい前からいろいろトラブルが発生していたらしい。このエレベータは、世界シェア2位のシンドラー製のエレベータらしく、どうやらこの会社のエレベータが怪しいのではないかという報道がなされている。今日のエントリーではこの事故に対して思うことを書きたい。

まず、某巨大掲示板でこのニュース(シンドラーエレベータが東工大でも利用されトラブルが頻発していた件)で紹介された。そのレスポンスが非常におもしろい。かなり多くの意見として”東工大ならそのくらい直せ”と。問題のエレベータがあるキャンパスにいる学生は全員が工学部。多少分野が違うとはいえ、半年間トラブルに対して何も対策は取らなかったのははっきりいって残念だ(実際には今回の報道を見た感じかなり自信満々の会社のようで、修理依頼をしても無視したのかもしれない・・)。エレベータは危険な乗り物である。工学部学生として、扉が半分閉まらなかった、階数表示に有るはずのない階数が表示される、人が多く乗ると沈む、変な音がするなどの現象がありながら何もしなかったとしたら、それは本当に残念であるし、もう少しエンジニアリングについて考え直した方がいいと思う。私はまだまだエンジニアの下っ端も下っ端だが、世の中にあるエンジニアリングについて疑問をもったら、業者でもメーカーでも必ず質問している。なぜその設計にたどり着いたのかなどを聞くだけで自分の種にもなるからだ。今回、高校生の命が失われたが、可能性として東工大でももちろん起こりうるわけで、工学部しかもほとんどが大学院生のキャンパスでこのトラブルを事前に解析し、事故を防げなかったのが本当に残念だ。

さて、シンドラーエレベータ自体を考える。まず、シンドラージャパンのホームページには、かなり強きのコメントが載せられている。

>2006年6月6日時点では、この事故がエレベーターの設計や設備によるものではない事を確信している旨を述べさせていただきたいと思います。
http://www.schindler.co.jp/jpn/WEBJPNJP.nsf/pages/new-060606-01

以上のようにかなりの強気のコメントである。彼らの主張も少し理解できる。世界シェア2位で世界中で使われているエレベータは、十分に信頼性があり、今回の事故は個々の特殊な(たとえば建物の問題など)問題に起因するものであり、エレベータそのものの設計には問題がないと。少なくとも東工大やほか多くの同社エレベータでトラブルが多発していることから、こんなコメントを発表したことを後悔することになるだろう。

まずこのエレベータの設計思想が甘いと思う。フェイルセーフの考え方が私のような素人でも甘すぎると思う。今回のトラブルの多くはたぶんソフトウェア・回路系のトラブルでハードウェアが暴走しているようである。ソフトウェアをどんなに完璧に開発してもトラブルは起こりうることを想定していないのだ。
 扉の開閉状態は何個ものセンサーでセンシングし、内部ソフトウェアはその情報を把握しているはずだ。その中で、”扉が閉まっている時は昇降しない”というプログラム(条件分岐)は必ず書いているはずである。しかし、今回の悲しい事故では実際に起こっている。エンジニアとして設計に盛り込まなくてはいけないことは、扉が閉まらなかったら昇降できないハードウェアの設計である。たとえば扉が閉まったら初めて歯車がかみ合い昇降運動が有効になるような設計であれば、どんなにセンサーなどのソフトウェア・回路が不具合を起こしても昇降運動は起こらない。このようなフェイルセーフ設計が全く行われていないと考えざると得ない。
 保守会社が変わろうと、どんな変な建物で使おうと、あいている時は動かないという仕組みなどは絶対に確保して設計しなければならない。私は人工衛星を作ってきているから、修理が絶対にできないエンジニアリングである。そのため、このようなフェイルセーフは最新の注意を払い、この未知のエラーにどれだけ想像力を働かせられるかが、一番おもしろいところである。宇宙という極限状態に人間の設計で立ち向かうときに起こりうるエラーをどこまで回避できるか、それは自然と人間の能力の戦いであり、そこに宇宙開発を行うおもしろさを感じている。
 今回のエレベータは明らかにそういったフェイルセーフの設計が甘いエンジニアリングである。エレベータという人命を扱うものに対してあまりにも設計が甘い。私の予想では、ソフトウェア系、回路系の熱暴走あたりじゃないかな?と思っている。日本は湿度も高いし、ビルの中のエレベータも十分な空間をとって作られていない。そのあたりでソフトウェア、または回路系に不具合でも発生したのではないだろうか?しかしそういう未知のエラーに対して、前述のように、物理的に閉まっていなければ昇降しないなどの設計を絶対に行わなければならないと思う。実際にエレベータの設計は非常に大変だと思う。それを簡単にこう言ってしまうのは大変失礼なのかもしれないが、何とか原因を究明し、人命を扱っているということを再認識して良いエンジニアリングをしてほしい。

 今回、シンドラー社がトラブルを起こし、人命が失われた。しかしこのトラブルはエレベータに限らずこれから多くのエンジニアリングで起こりうると予想する。その原因の一つは何か?

”プログラマブルエンジニアリング”

である。この言葉が正しいかはわからない。しかし、この10年エンジニアリングが非常に変化してきている。あらゆることが、”プログラマブル”になったことである。その最新のものを紹介すると、アイピーフレックス株式会社”DAPDNA”である。パソコンや電化製品などを分解すると必ずといって良いほど入っている緑色の基板。いわゆる回路基板であり、一つの基板には、たくさんの抵抗・コンデンサ、トランジスタなどがたくさん並び、その電気の通り道が迷路のようにつながっている。この回路が現在、自由にソフトウェアで開発できるようになった。つまりソースコード(のようなもの)を一つの電気素子に書き込むとその通りに回路ができあがることができるようになった。その中でもDAPDNAは、ナノ秒単位でその回路を切り替えることができる。つまり今までかなりハードウェアに依存していたものが、ソフトウェアでできる分野が格段に広がった。

 このプログラマブルエンジニアリングは、電気回路が入っていないモノがない現代において革命的に開発時間と開発コストを低減させた(といわれている)。しかし逆に、”緊張感のないエンジニアリング”をもたらしたと思っている。プログラマブルということは、逆にいえば、改変が可能ということである。つまり出荷し、エラーがでたらそのソフトウェアを再プログラミングするというエンジニアリングが一般的になった。もちろん、最初から完璧な物作りは難しいので、エラーなどはさけられない。しかしこの出荷後にも改変できる甘えと何でもソフトウェアで解決できるという過信が様々な業界で問題になってきているのではないかと思っている。今回のエレベータ事故、昨年の電車事故、飛行機のトラブルなど、このプログラマブルエンジニアリングが少なからず起因しているのではないかと思っている。

 エンジニアリングの最も難しく、そして日本のエンジニアリングが本来得意としていたものは”壊れないエンジニアリング”だと思っている。はっきりいって目的の機能を実現するエンジニアリングはそれほど難しくない。しかし1年動かしっぱなしで壊れないエンジニアリングは非常に難しい。今この伝統が失われつつある。この理由は経営面など様々な要因はあるが、一つは出荷後に改変できるという甘えから、物作りの精度が落ち、また壊れたら買い換えれば良いという消費者に問題がある。

 完璧なエンジニアリングなどほとんどありえない。上記のような現状でエラーが起こりうる設計の甘い物作りが今後益々増えていく。最近はモノだけではなくインターネット(ウェブ2.0)でも、ベータヴァージョンと堂々と表示している(gmail, mixi, greeなど・・)ページが増えている。このような現状であるからこそ、何かおかしいとか、不安に思ったら堂々と問い合わせるべきである。今回のエレベータ事故で、エレベータは総点検される。しかし、この尊い命が失われなければ点検されないのがとても悔しい。

シンドラーのエレベータを考える」への4件のフィードバック

  1. >未知のエラーにどれだけ想像力を働かせられるかが、一番おもしろいところである。

    いつもプログラムを書くときに「例外が発生したときの処理を書くのダリー」と思ってたんですが、この言葉を読んでちょっと考えを改めようと思いました。

    単なる失敗、間違い、設計上の欠陥、作業の手落ちを「バグ」とか「仕様」とか「ベータ」などと様々な言葉を駆使して表現するところにソフトウェアエンジニアリングの問題がある気がします。失敗は失敗と素直に認める謙虚な姿勢、同じ失敗を繰り返さない努力が大事ですね。
    そういう意味でシンドラー社には近視眼的印象をうけます。

  2. ファームウェア技術の重要性を軽視した結果なのかな・・って個人的には思っています。

    ハードウェアが分かる技術者と、ソフトウェア技術者を1人づつ連れてきたからといって、ファームウェアは作れないですよね。

    かといって両方を専攻したひとでよいかというと、それでも力不足。
    ハードの脆弱性と、ソフトの脆弱性を共に熟知して、じゃあ、その脆弱性はどうすれば回避したり低くすることが出来るのか?・・とか。
    劣化後のハードウェアの性能を前提として、劣化後の機械にストレスをかけないで制御する技術とか。
    劣化が進行して致命的なブレークポイントに達したら、安全を最優先して停止させるしかけとか。。

    反復動作に見えて、実はそうではないという、ハードの特性を理解したうえで設計を出来るセンスを持ってるファーム屋さんが不足してる点が背景かも知れないな・・って思いました。

  3. Sparkyさん>

    コメントありがとうございます!
    私も全くこのような記事を書けるほど物を作っているわけではないですが、逆に自分への戒めも含め書かせていただきました。

    ベータやバグなど横文字でごまかさずに真剣に良いものをつくり、想像力を超えるエラーのみ最新の技術で補完するというスタイルでいきたいですね。修正できる甘えを前提にものづくりをしないようにしたいものです。

  4. おでちんさん>

    H/W, S/W両方できるのが理想ですが、難しいでしょうね。そのあたりを大学などでやるべきなのですが、日本の大学生はほとんど勉強していないですし、ちゃんとしたものづくりを勉強する環境はほとんどないと言えるでしょう。
    たとえば、C言語のポインタが、ただの文法理解ではなく、CPUアーキテクチャのD-FFにどう作用するかを知っていればエレガントで安全なプログラムが書けると思っています。しかし全員にそれっていうのは難しいでしょうねぇ・・。

コメントは停止中です。