2011-01-30

『課外授業 ようこそ先輩』で湯浅誠さんが言いたかったこと

深夜のサッカーの試合を生で見る元気がなく、朝起きてから結果を見ようと思ってテレビをつけたらたまたま、NHKで『課外授業 ようこそ先輩』をやっていてついつい見入ってしまった。

【番組ホームページより】
さまざまなジャンルの第一線で活躍する著名人が、ふるさとの母校を訪ね、後輩たちのためにとっておきの授業を行います。授業は通常2日間、リハーサルなしの真剣勝負です。内容や仕掛けは、先輩によって実に多彩。人生で得たこと、創造の秘密、専門分野の面白さなどを、独自の方法で解き明かします。そんな先輩の思いがこもった授業を、子どもたちはどう受け止めるのか?そこには毎回、思いがけない発見と感動があります。1998年に番組がスタートして以来、これまでに400人を越える先輩が、母校の子どもたちに熱いメッセージを送ってきました。

今回の先生役の有名人、どこかで見たことがある。芸能人ではない。誰だっけと思い出していたら、やっと思い出した。2008年12月社会問題化したいわゆる「派遣切り」への緊急対策として、開設された「年越し派遣村」の村長、湯浅誠さんだ。

かつて、湯浅さんが有名になる前、TBSラジオの夜PM10:00からやっていたアクセスのゲストで来ていたときに反貧困ネットワークでの活動について聞いたことがあった。

この人の学歴がすごい。
1988年 武蔵高等学校 卒業
1989年 東京大学教養学部文科I類 入学
1995年 東京大学法学部 卒業
1996年 東京大学大学院法学政治学研究科 入学
2003年 同大学院博士課程 単位取得退学

詳しくは Wikipedia を見ていただきたいのだが、以下の一節だけ読んでもすごい経歴だ。
東京都小平市で、新聞社勤務の父と小学校教諭の母の間に生まれる。1988年に武蔵高等学校卒業後、1浪して東京大学に入学。児童養護施設のボランティアや映画鑑賞にのめりこんで授業にはあまり出席していなかったが、5回生の夏に一念発起し学者を志して勉学に集中、一時的にボランティア活動から離れた。
さてさて、肝心の『課外授業 ようこそ先輩』の内容に進もう。


2011年1月30日 「目を向ければ 見えてくる!?」 東京都小平市立小平第十三小学校
湯浅誠 (「反貧困ネットワーク」事務局長)

まず、最初の授業はクラスのみんな(たぶん6年生)に自分の宝物を持ってきてもらい、どんな宝物なのかを説明してもらっていた。ある子供は地球儀をある子供はオカリナや写真をある子供は水筒(病気で頻繁に水分補給が必要とのこと)を持ってきてみんなに説明する。

この授業は何のためにやっていたのか。この授業には湯浅さんの明確な意図があった。それは「他人には分からなくてもその人にとっては大事なもの」が存在し、なぜ大事なのかはその人にしかわからないということに気がつかせるということだった。自分では分かっている自分の宝物の意味が他人には分からないことに気がつかせ、一見理解できない他人の宝物が大切な理由を聞いて理解させる。

つぎに湯浅さんは3人の大人の方を一人ずつ呼んで、クラスのみんなに「この人は一体誰か」を当てされる。3人とも学校で働いてる方だ。

種を明かせば、一人目は給食のおばさん、二人目は校庭の芝部を手入れする芝生キーパーさん、三人目は警備員さん。

一人目の給食のおばさんはいつも割烹着を着てマスクをしているため、誰も当てられない。警備員さんは多くの子供が当てた。

この授業の意図は制服を着ているとその人の制服から想像される役割だけに注意をとらわれてしまうということを示したかった。制服を脱いだ一人の個人には役割から離れた個人としての人格があり、それに気がつかなければいけない、その人個人に関心を持って欲しいと湯浅さんは言いたかったのだ。

三つめの授業は、班に分かれて普段気になっている街の人達にその役割ではなく、その人の人生を聞いて見ようというもの。社会科見学はその人やその施設の役割を聞くが、これは社会科見学ではなく、一人一人の人格に向き合ってみようという授業。

農家のご主人に宝物は何かと尋ねると「それは奥さんかな」と答え、奥さんを呼んできて奥さんにも同じ質問をすると「このおじさんよ」と答えた。ご主人は「僕らには子供がいないので、そう答えるのかもしれない」「君たちのお父さん、お母さんに聞いたら、宝物は君たち」と言うかもしれないねと語った。

モヒカンヘアの和菓子職人は、若い頃バンドをやっていて今でも音楽が好きで、今は和菓子職人を継いでいるのだと語り、交通指導をしてくれているボランティアのおじいさんは戦時中に使っていた飯盒を宝物として見せてくれた。

授業の最後に湯浅さんは自分の座右の銘「見えないことは無視につながり、関心は尊重につながる。」を黒板に書いた。

日本の貧困問題に対峙することで生まれたポリシーかもしれないが、自分の周りでも起こりうることのように感じた。不具合を起こすソフトウェア、調子を崩すエンジニアの気持ちが見えない、いや見ようとしないことで無視することにつながり、直近の納期や売り上げだけを気にして行動する人達があまりにも多くないだろうか。

湯浅さんが言いたかったのは、偏見の排除だと思う。昔、妹尾河童の『少年H』を読んで、戦争中に威張っていた学校の先生が戦争が終わったとたんに180度態度が変わった部分を読んで、制服の威厳を笠に着るのは絶対にやめよう、自分自身の内面、中身で勝負しようと思った。

ようするに肩書きが外されたときでも、態度を変えられないようにしよう、態度を変えるような人と接するときは注意をしようということだ。

『課外授業 ようこそ先輩』を見て、見えないものを分からないといってそのままにしない、その人の制服、役割ではなくその人個人に関心を持ち尊重することの重要性を再認識した。

2011-01-19

機能安全の意味がわかった(IEC61508とISO26262の最新情報)

クルマ関係の仕事をしている技術者は日経エレクトロニクス 2011.1.10 の特集記事『クルマの電子安全始まる-ISO26262を越えて-』を必ず読んでほしい。

機能安全規格IEC61508と自動車の電子制御系に関する安全規格ISO26262の概念について詳しく解説されている。

自分自身、機能安全ということばがどうしてもすっきり理解できずもやもやしていたが、この記事を読んですっきりした。

だいたい、「機能」と「安全」の結びつきが直感的にイメージできない。Safety は functional ではない、安全は機能的に実現するのではなく、あらゆる使用環境、ハザードを想定してシステム全体で確保するものだと思っていたから、どうしても機能安全(functional safety)ということばがしっくりきていなかった。その疑問点をこの特集記事はクリアにしてくれている。

この記事がいいところは規格の内容を解説するだけでなく、規格の策定メンバーにインタビューして規格が作られた時代背景や思惑にまで突っ込んで書かれてところだ。

【日経エレクトロニクス 2011.1.10 p44 機能安全、素朴な疑問より引用】
機能安全(functional safety)の「機能」とは、制御対象(プラント、EUC: equipment under control)や制御器(コントローラ)を監視する安全装置の役割のことを意味します。通常、安全装置(安全関連系(SRS: safety-related system)にはコンピュータが使われ、いざ制御器に故障などが発生した場合は、このコンピュータが制御対象を停止したり、ユーザーに警告を出したりします。安全装置があることによって実現されているこうした安全性のことを、特に「機能安全」と呼んでいます。機能安全とは、いわばマイコンなどを使った安全装置による安全対策といえます。なお、安全性そのものは、こうした電子的な安全装置の付加によって担保するだけでなく、危機源(ハザード)そのものの設計上の除去(本質安全)や、危機構造的なフィルセーフ機構(構造安全)などによっても担保するのが一般的です。機能安全によって実現できる安全性は、包括的な安全性の、あくまでも一部でしかないといえます。IEC自身も機能安全について、「Functional safety is the part of the overall safety」と明記しています。
【引用終わり】

この特集記事には IEC61508策定時の裏話が書かれている。 IEC61508 はバックグラウンドとなる理論的体系や支柱がほとんどないまま、1990年代初頭に「ともかくPLCなどの電子的な安全装置に関する規格を作らねば」という欧州企業の意向によって策定が始まったというのだ。そして、根拠は後付けでいいからというスタンスが強かったという。何からの裏付けや蓄積を経た上で策定される通常の規格とは真逆の順序で作られたらしい。

機能安全規格のIEC61508と特に強く批判してきたのが、米国を中心とする安全の専門家やソフトウェア工学の専門家だという。ソフトウェアの安全設計の権威であるMITのナンシー・レブソン教授がIEC61508に批判的だというのは知っていたが、米国の多くの専門家が批判的だというのは知らなかった。

IEC61508に対する批判は主に次の4点に集約されている。

  1. 安全性の規格でありながら、定量的な故障検出率といった確率論に重きを置きすぎている。
  2. 故障率低減のための複雑な機構の導入が、かえってシステム全体の安全性を損なう危険性に配慮していない。
  3. 部品ごとに安全性の認証を与え、認証を得た部品の採用によって安全を担保しようとしている。
  4. バックグラウンドとなる理論的体系や支柱がなく、規格が膨大で分かりにくい。
あー、それだ。そう、何年も前から自分はこの規格を読んでいてそう思っていたのだ。特に3つめの部品単位での安全性の認証のところ。日経エレの進藤記者、分かりやすく明確に書いてくれてありがとう。この記事読んでいて「がってん」ボタンを何回も押してしまったよ。

さて、IEC61508はそもそも、化学プラント、原子力産業、工作機械などの産業用機器を対象に作られた。だからそこ、ハザード事象が発現したときに、安全装置があることによって実現されているこうした安全性のことを「機能安全」と言ったのだ。

機能安全の説明でよく踏切の例が挙げられる。踏切ではなく高架橋を作ることによって通行者の安全を確保するのが本質安全で、踏切という安全装置によって安全を確保するのが機能安全。

ちなみに、自分がこの機能安全ということばに違和感を覚え続けていたのは、日頃から安全の確保はハザード分析やリスク分析から始まるということが当たり前だと思っていたからだ。

システムを取り巻く環境にあるハザードやリスクを分析して、それらのリスクを受容できるまで低減するのことが重要と教わってきた。リスクを軽減するための手段は、設計上の対策かもしれないし、表記上の対策かもしれないが、手段が先になることはない。

機能安全の規格は安全装置によって安全を確保する狭義の Safety という意味合いが強いということがこの記事を読んでよく分かった。本質安全に対する安全装置による安全(=機能安全)と考えると非常にすっきりする。

そして、安全は安全装置の設置という狭い考えではなく、システム全体を踏まえた包括的な安全性の実現を考える必要がある。

折しも、昨日今日とWOCS 2011(クリティカルソフトウェアワークショップ)が開催され、MITのナンシー・レブソン教授が基調講演に登壇された。その後、トヨタ自動車の川名氏、電通大の西氏、JAXAの片平氏も含めて、口々に「認証されたツールや部品を組み合わせることで安全を確保できると思ってはいけない」と語っていた。

なお、日経エレの特集記事を読んでいただければ分かるように ISO26262 は IEC61508の問題点をアンチテーゼとして、クルマドメインに合うようにかなりカスタマイズしている。

ISO26262がDIS(Draft International Standard)と呼ばれるドラフト段階のときに、「リスクの高いコンポーネントは形式手法を強く推奨する」という記述があった。これを見た、ツールベンダーや規格認証機関は「形式手法は絶対に使わないといけない」というニュアンスをクルマドメインの人たちに伝え恐怖をあおった。

ところが、FDIS(Final Draft International Standard)では、選択肢を複数に増やしてかつ、代替えの方法でも可という表現に変わっている。わざわざそうしたのは、ソフトウェア部品の信頼性を高めることがシステム全体の安全につながるかのような誤解が開発の現場に蔓延するのをなんとか防ごうとしたからである。

このように ISO26262 は IEC61508で指摘された問題点の多くを積極的に改善してきている。規格の策定委員の一人であるトヨタ自動車の川名氏は「選択肢が増え曖昧さが加味されたことによって骨抜きになったと思う人もいるかもしれない」とWOCS2011で語っていたが、そんなことはない。技術者が「安全を確保するのはどうしたらいいのか」「自分達がやってきた方法は安全にどれくらい寄与しているのか」と正面から考えるきっかけを作ったくれたのだ。

そうではなくて、形式手法を使えばよいとか、規格認証を取れたツールを使ったり、プロセス認証を取ったサプライヤーにソフトウェアを開発委託すれば、安全なシステムを作れるなどと考える者を減らすのを助けてくれたのだと考えて欲しい。

自分は、システムの安全を考えるときには、必ずどんなリスクを回避しようとしているのかを常に思い浮かべて欲しいと思う。例えばクルマなら次のようなことだ。
  • 衝突したのにエアバッグが開かない
  • 衝突回避のための超音波センサに泥が付いた。
  • パワーウインドウに子供の手や首が挟まった。
  • エンジンがオーバーヒートしたらどんなときにも止めていいか。
  • バッテリ切れのときにブレーキは働くか。
上記のようなリスクを回避するのに、形式手法やメモリ保護、カバレッジ100%のテストはプラスの効果を与えると思うが、安全を確保できているという確固たる根拠にはならない。安全を確保するには想定したリスクをどのようにして安全設計によって回避できるのかを説明しなければいけない。

ソフトウェアは電子部品のようにランダムな故障はしない。Systematic Failure (決定論的故障) といった問題の起こし方をする。想定しきれなかった、テストしきれなかったバグによって問題は起こる。そのようなバグを完全にゼロにすることはソフトウェアの場合困難であると認識しつつ、ハザードが発現しないためにはどうしたらよいのかを考え、できるだけ完全に近づけようと努力する。

日本のソフトウェア技術者は世界でも最高レベルの品質を持つ製品を世に送り出してきたのだから、なぜ、それができたのかをよく考えて、その強み・ノウハウを殺すことなく、グローバルな世界に対して説明責任も果たせるようにならないといけない。

規格の翻弄されるのではなく、自分達が安全を実現するためにやっていることを規格を使ってどうどうと説明するにはどうしたらよいかを考えればよい。