Embedded Software Manufactory

100%の安全が確保できないからルンバを作らない？

2012-02-12T16:54:00.003+09:00

特集記事はお休み

今回は ISO 26262 の記事ではない。特集記事8回、関連記事3回書いて分かったのは、規格の日本語訳には膨大な時間がかかり、規格をすべて和訳するのはあまりにも効率が悪く、自分自身のモチベーションもなかなか続かないということだ。

これだけ話題になっている国際規格だから、近い将来、きっと自動車系の工業会が和訳を作ってくれるに違いない。全体を正確に把握するには、工業会が作った和訳をじっくり読むのが一番いい。

問題は和訳が出そろった後の話だ。規格適合を目指す技術者は大抵和訳が出ても隅から隅まで読まない。誰かが自分がやるべきことを教えてくれるのを待っている。

そして、組織はしびれを切らし担当部門もしくは担当者を決めて、その担当がエンジニアに指導する。医療機器の世界では自分がその役目を担っている。

ISO 26262に関してここで方針変換しようと思っているのは、ISO 26262 の和訳がリリースされたら、日本のソフトウェアエンジニアが自分達の良さやアドバンテージを消さないように、自動車の安全を確保するためには規格をどのように解釈したらいいか、また、和訳から読み取りにくい規格原文のニュアンスは何かなどをこのブログで解説するということだ。

また、規格のここが分からないとか、ここの部分を知りたいというリクエストがあれば、積極的にそのリクエストに応えていきたい。自分は、自動車業界には何のしがらみもないので、安心して質問や要求を投げてきて欲しい。（現時点でもリクエストがあれはお答えします。）

さて、今回は下記のニュースを掘り下げてみたいと思う。

■日本の家電各社が掃除ロボット「ルンバ」を作れない理由…国内製造業の弱点

日本の家電各社が、米アイロボット社の「ルンバ」に類似した製品を作らない、作れない理由について書いた記事である。（東芝は外部に製造委託して掃除ロボットを販売している。）

アイロボット社の「ルンバ」は確か7万円以上はしたと思うが、結構売れていると聞く。いろいろできないのではないかという心配をよそに、狭い日本の家庭でも賢く掃除してくれるらしい。

サイクロン型掃除機のように日本の家電メーカーが似たような商品を作りそうなのにそうしない理由として次のようなことが書いてある。

それなのに、技術力で世界の家電業界をリードしてきた日本メーカーが、どうしてルンバ発売から10年以上が経過しても同様の製品を製造しないのか。

「技術はある」。パナソニックの担当者はこう強い口調で話しながらも、商品化しない理由について「100%の安全性を確保できない」と説明する。

例えば、掃除ロボットが仏壇にぶつかり、ろうそくが倒れ、火事になる▽階段から落下し、下にいる人にあたる▽よちよち歩きの赤ちゃんの歩行を邪魔し転倒させる－などだという。

家庭で使う家電製品の第一条件は「安全性」だ。一方、日本の製造業は「リスクを極端に嫌う」傾向が強いため、開発の技術力がありながら、獲得できる市場をみすみす逃しているケースも指摘されている。

記事ではこのあと医療機器の例が書かれており、日本では製造物責任を恐れて新規参入しない企業があると言っている。

上記の「技術はあるが、安全を考えると参入できない」という気持ちはよく分かる。それが日本人の顧客の安全を何よりも重要視する気質( Awareness: Worrying about Quality:品質を心配する意識)の表れだと感じる。

ただし、記事が主張しているように、リスクを恐れて市場に参入しないというのも間違っていると思う。ちなみに、記事の中に出てくる「100%の安全性を確保できない」から市場参入しないというくだりは、誤った考え方だ。福島の原発事故が示すように100%の安全性など、この世に存在はしない。何をするにもリスクは必ず存在する。

薬がよい例だ。リスクよりも効用が上回った場合は、リスクコントロール手段を施した上で、リスクよりも効用の方を取る。薬の場合、製薬メーカーは治験等で十分な調査を行い、消費者は服用の注意事項をよく読み、禁忌禁止事項はやらない、医師や薬剤師の指示を守るといったこと要求される。それがリスクコントロール手段だ。

それをやった上で、副作用というリスクよりも薬の効果効能の方を取るのだ。掃除ロボットの場合は、薬や医療機器ではないので、リスクといっても人の生き死にとは直接は関係ない。

しかし、上記のパナソニックに担当者は「火事」や「赤ちゃんの転倒」といったリスクを想定した。こういうところはさすがだと思う。日本の製造業のすごいのは、品質保証担当でなくても、このような目の届きにくいリスクを拾い上げる能力を持っている点だ。その根底にあるのは、日本人の相手を思いやる気持ち、習慣のお陰ではないかと思う。

さて、商品に関係しそうな細々としたリスクを洗い出す能力が高いのはよいのだが、その結果、市場に参入しないという判断は正しいのだろうか。記事は技術力があるのに獲得できる市場をみすみす逃していると書いているが自分はちょっと違った視点を持っている。

というのは、日本のメーカーがやらなくても、韓国のサムスン電子、ＬＧ電子は参入しているのだ。日本は安全、安心の商品を作ることが最も得意な国なのに、そこに手を出さなくてどうするのか、そのままジリ貧の状態に甘んじるのかという気持ちだ。

ようするに、模倣商品が市場に出回って消費者を危険にさらすくらいなら、ブランドの信用がある日本のメーカーが安全でリーズナブルな商品を開発したらどうだということだ。ブランドを傷つける可能性をぬぐいきれないので参入しないという選択は、安全でリーズナブルな商品を望んでいる消費者の期待には応えられないという敗北宣言と同じだ。市場を逃しているのではなく、消費者の期待に応えられていないと考えて欲しい。（前者は金儲けが目的の考え方、後者は社会貢献が目的の考え方）

これからの日本の製造業者は効果効能が高く、かつリスクも大きい商品があったらチャンスと思わないダメだ。過去の栄光を守ろうと考えたら、あっという間にアジアの国々に抜かれる。あのソニーだって、新社長が4本柱の一つとして医療分野に力を入れると言っているではないか。

米アイロボット社に敬意を表して、白旗を揚げて模倣製品は作らないというのも選択肢の一つだとは思うが、安全性が担保できないから市場参入しないというのはなさけない。パナソニックは家電業界でユーザーの安全分析、安全対策、是正改善は相当やってきているだろうから、安全を確保できないから市場参入しないという理由はおかしい。

安全を分析、実現するノウハウは持っているはずなので、市場におけるユーザーからの苦情や故障情報を持っていないというのは理解できる。しかし、そのような情報はルンバのユーザーや家電量販店へのリサーチである程度は収集できるから、できない理由にはならないと思う。

新規参入した分野で事故を起こせば、ブランドに傷が付き主力商品の売り上げに支障がでると考えたのなら、既存商品の分野でジリ貧となる運命を受け入れるしかない。

リスクを伴う商品開発に関わりたくない、命に関わる商品開発はしたくないという話は、医療機器ドメイン外の技術者や、大学生から聞くことがある。そういう時は「リスクから逃れることを考える前に、自分達が作った商品やサービスで人や社会にどんな貢献ができるのかを考えてみて欲しい」と言う。

患者さんの命を助ける、人のためになる、社会に貢献するための仕事に従事できれば、毎日の仕事自体がやりがいにならないか、もっとお客さんに満足してもらう、もっと社会に貢献したいという気持ちにならないか。そのためにまたがんばろうと考えられるようになったらいいと思わないかと問うようにしている。

高い効果効能、高い社会貢献を実現する商品にはユーザーリスクが伴う。しかし、人間はそのリスクを軽減するための知恵をこれまで構築してきた。その先人の知恵を使うことで、できるだけリスクを下げることができる。ただ、100%の安全はないのでそのことは決して忘れてはいけない。

ここまでの考えをまとめると、次のようになる。

【今日のまとめ】

効果・効能をもたらす商品にはユーザーリスクが伴う。
リスクの低減を実現し、高い技術で効果・効能を実現できれば、それが組織の強みになる。
100%の安全などあるわけないのだから、リスクから逃げるのではなく、リスクを軽減する技術を追求する。
日本の製造業の強みは製品開発を通じて潜在的価値（リスクの軽減）と顕在的価値（効果・効能）の両立ができることである。
その特長を活かせないのなら、グローバルマーケットで生き残ることはできない。（機能やコストだけでは勝負はできない。安全や信頼の提供が世界中の顧客の信頼を生む。）

ISO 26262との向き合い方 (8) リスク分析しないでいいの？

2012-01-20T21:35:00.000+09:00

今回の記事はリスク分析、リスクアセスメントについての話題である。

最初に、医療機器ドメインのリスクマネジメントに関する国際規格である ISO 14971:2007
Medical devices — Application of risk management to medical devices のリスク評価の定義について見て欲しい。

リスクは、危害の発生確率（the probability of occurrence of harm）と、危害の重大度（the consequences of that harm, that is, how severe it might be. ）により評価されるというのが ISO 14971 の考え方である。一般的にも、リスク = 発生確率 × 重大度などと書かれる。

例えば、ハードウェア部品の故障による障害などでは、発生確率はすなわち部品の故障率となり、その部品が故障したときの被害の大きさが重大度となる。よって、故障率が非常に低い場合のリスクは低いと考える。

気をつけたいのは、リスク評価 = 発生確率 × 重大度と書いても、リスクの評価は数学的、統計的に計算されるものではないという点だ。

なぜなら、危害の発生確率は部品の故障率のように数値で示すことができないことも多々あり、また、危害の重大度は極めて主観的であり、時代や人々の考え方によって常に変化するパラメータであるからである。

下記のマトリクスを見て欲しい。縦軸には危害の発生確率に相当する半定量的な確率レベルが、横軸に定性的な重大さレベルが表されている。

このマトリクスでは濃い青の部分が半定量的な確率レベルと定性的な重大さのレベルにより、そのリスクは受容できないと判断されたエリアである。薄いブルーの部分は更なるリスク低減を検討すれば受容できるリスク、白い部分は受容できるリスクと判断している。

この表に出てくる「しばしば」や「時々」「わずかに」や、「軽微な」「きわどい」「重大な」といった評価指標は定性的と言いながらも主観的な表現だ。発生確率が定量化できない、重大さのレベルが定量化できないので、半定量的もしくは定性的に評価しているのだ。その判定基準はその組織が積み重ねてきた事故データや判定者の経験的主観に依存している。

実例でリスクを評価してみる

医療機器で実例を挙げてみよう。心拍は心臓右心房付近にある洞房結節から発生される電気的な刺激の発信がトリガーとなって起動される。この自発のペースメーカの機能に欠陥がある患者さんには、ペースメーカが植え込まれる。

ペースメーカにはさまざまな機能があるが、自発の心拍がたまに欠落するような場合は、ペースメーカは心拍が欠落したときにのみ心臓を刺激する。これをデマンドペーシングと呼ぶ。自発の心拍がまったくない場合は固定レートで心臓を刺激するこれを固定レートペーシングと呼ぶ。

リスク(危害)	危害の発生確率	危害の結果（=重大度）	リスクコントロール手段	リスクコントロール後の残留リスク
自発の心拍がないにもかかわらずペースメーカの出力が止まる。	起こりそうにない？	ペースメーカを植え込んだ患者が死ぬ。	バックアップ手段としての固定レートペーシングユニットを追加する。	電源喪失時はバックアップユニットも動かない。
高速走行中にブレーキが効かなくなる。	起こりそうにない？	運転手と車に衝突された人が死ぬ。	ブレーキメカニズムにソフトウェアを使わない。	ハードウェア部品のランダム故障のみが残る。
原子炉が制御不能になる	起こりそうにない？	放射能が拡散し、人体に影響を与える。人が住めなくなる。	原子力発電をしない	残留リスクなし

さて、患者さんに植え込んだペースメーカが動かないというリスクを考えて見よう。ペースメーカの停止が起こった場合のリスクの重大さは患者さんの死を引き起こすので破局的だと考えられる。

では確率レベルはどうだろうか。「時々」や「わずかに」ならペースメーカとして使える訳がない。では「起こりそうにない」のか、または「考えられない」なのか。上記のリスク評価のマトリックスであれば、「破局的」な重大さレベルで、確率レベルが「起こりそうにない」なら、そのリスクは受容できない=すなわち、そのペースメーカは受容できないリスクがあるため販売してはならないし、考えられないレベルであれば更なるリスクの低減策が必要となる。

ではつぎに、車の例で高速走行中にブレーキが効かなくなるというリスクについて考えて見よう。危害の結果について予測されるのは、運転手と車に衝突された人の死、及び、車が衝突することによる固定物の価値の喪失などが考えられる。ではその重大度は、発生確率はどうであろうか。人の死の可能性があるのならば重大さのレベルは「重大な」や「破局的」が予想される。

障害の発生確率はハードウェアの場合部品の故障率で予測できると書いたが、ハードウェアであっても設計上のミスや、ソフトウェアのバグによる障害の発生は、その確率を予測することができない。このような故障、欠陥のことを Systematic Failure / Systematic Fault (決定論的故障/欠陥）と呼び、医療機器の世界では今のところ、Systematic Failure の発生確率は1、すなわち発生確率は考えずに、障害の重大さだけでリスクを評価することにしている。

※ISO 26262 では、リスクの評価に Controllability（ドライバや周辺の人々の障害の回避容易性）を考慮している。

もう一つ、リスク評価の例を考えてみたい。それは、「原子炉が制御不能になる」というリスクだ。不幸にも日本は昨年、「原子炉が制御不能になる」というリスクに対して「放射能が拡散し、人体に影響を与える。周辺に人が住めなくなる。」といった危害の重大度を実体験として経験してしまった。

「原子炉が制御不能になる」というリスクの発生確率は福島の原発事故が起こる前は「考えられない」だったかもしれない。しかし、起こってしまった今の評価はどうだろうか。「考えられない」「起こりそうにない」といった評価を日本国民は許さないだろう。

冒頭でリスクの評価は数式では表せないといったのは、このことだ。どんなに統計的な確率が低かったとしても、甚大な被害が発生してしまえば、リスクの評価は変わる。

一般的に時間がたつにつれてリスク評価は厳しい方に傾く。なぜなら、リスクコントロール手段が普及すると、人々はそのリスクコントロール手段を“当たり前に実装されているもの”と認識するようになるからである。過去に認識されていたリスクは現在ではブロックされていて当然であり、技術の進歩により機器の安全は進化していると考えるのが一般的な消費者の意識だ。機器を使っていて使い勝手の悪さや不具合を見つけると、どうしてこんなことが考慮されていないのかと消費者は怒りをあらわにする。しかし、そのレベルでリスク分析、リスク対策をしたら何千、何万というリスクコントロールを行わないといけないという作り手側の視点に立つことはない。問題が起これば、ユーザーにとってはその問題が今一番優先度の高い関心事なのだ。

起こってしまった問題を追求することはやりやすいが、同じレベルの問題を見つけ出し、発現しないようにする水平展開は簡単ではない。そのドメインに新規参入する企業や、新人の技術者は“当たり前に実装されているもの”の存在やメカニズムを知らないから、危険な製品を作ってしまう可能性がある。皮肉なことに、ユーザーは事故や不具合を体験することで、メーカーのリスクコントロール手段の存在を知ることがよくある。当たり前にできていることは、それが当たり前でなくなったときに、初めてその存在が分かるのだ。

だから、クリティカルな製品を開発する企業は、リスク分析、リスクアセスメント、リスクコントロール手段の設計と実装、検証、妥当性確認を行う義務を負っている。

さて、「原子炉が制御不能になる」のリスク分析に話を戻そう。「原子炉が制御不能になる」のリスク評価は、現実に事故が起こったことで、発生確率の評価は厳しい方向に動いた。結果的に、リスクは受容できないという判断になった。

この場合、この後どうしたらよいだろうか。リスクコントロール手段の一つとして「原子力発電をしない」という選択肢がある。この対策を取れば、「原子炉が制御不能になる」というリスクからは解放される。現在の日本の状況がまさにこれに当たる。「原子炉が制御不能になる」というリスクの場合、重大さのレベルは破局的から下がることはないので、もしも、どうしても原子力発電を続けるのであれば新たなリスクコントロール手段によって、リスクを受容できるようになるのかどうかを判断しなければならない。

リスクマネジメントにより事故を未然に防ぐことができれば一番よいのだが、リスク対策は実際には発生してしまった事故に向き合うことで前進する。安全を本気で実現したいのなら、事故に正面から向き合うしかない。ただ、自組織の体験だけが必要なのではない。世の中で発生してしまった過去の事故、他社の事故も再発防止策を考えるのに役立つ。現実には事故を再発させない、再発させてはいけないという関係者共通の意志がリスクコントロールの進化を後押しするのである。

具体的なリスクを想定しないで部品を作っちゃう人たち

今回、リスク分析、リスクアセスメントを話題にしたのは理由がある。その理由を説明する前に次の2つの ISO 26262 に関連した各企業のプレスリリースを見ていただきたい。

1) 機能安全規格に対応した電子制御ユニット向け車載用マイコンの製品化について
：
車載電子制御ユニットを対象とした機能安全規格「ISO26262」が今年中には発行される見込みです。規格発行後は電子制御ユニットの中核部品であるマイコンに対して、一部の機能が故障しても安全に制御する「フェールセーフ」機能を搭載することが必要となります。
：

2) HEV/EV用モータ制御を効率化する角度センサ（レゾルバセンサ）の特性をプログラマブルに補正できる高性能マイコン「V850E2/PJ4-E」を発売
～機能安全規格ISO2626２にも対応し、HEV/EV用モータシステムの高い安全性かつ低コスト化に貢献～
：
今後自動車業界で適応されるISO26262（注2）に対応するため、高度な故障検出技術を搭載しており、モータ制御など高い安全性が求められるシステムに対応できます。
：
また、これら車の普及促進に向けたシステムコスト低減も強く求められると共に、ISO26262が発行され安全要求への対応が求められております。
：

これらのプレスリリースに強い違和感を感じるのは、これらのマイコンメーカーはおそらく自動車の具体的なリスク分析やリスクアセスメントに基づいてマイコンを設計したのではないだろうという点だ。特に「規格発行後はフェイルセーフ機能を搭載することが必要となります」というくだりはひどい。規格が発行されるから安全対策が必要などというのは、本末転倒も甚だしい。ISO 26262 は自動車メーカやサプライヤが自分達が分析、設計した安全対策を国際標準に基づいて説明するためにある。

このブログの特集記事で常に訴えているように、エンドユーザーに対して安全の責務を負っていない者は平気でそのような発言をする。医療機器ドメインではそんな売り込みのされ方をしたことはないから、自動車開発にまつわる市場の大きさがそういったセールストークを作り出すのだろう。

さて、これらのプレスリリースの前者は、「一部の機能が故障しても安全に制御するフェールセーフ機能を搭載している」と書いてあり、後者はDual Core Lockstep（デュアルコア・ロックステップ）：ロックステップを実行する２つのプロセッシングユニットの結果を随時比較して故障を検出する故障検出技術を搭載していると書いてある。

リスクを想定せずに安全設計はできない。なぜなら、すべてのリスクに有効なリスクコントロール手段など存在しないからだ。「一部の機能が故障しても安全に制御する」「故障を検出する機能を有する」という文言は一見どんなリスクにも効くように見えるが、ECU側でそれらの機能がリスクを低減するリスクコントロール手段になっていなければ意味がない。マイコンサイドはその機能がリスクを低減させると考えているのだろうが、具体的にどのようなリスクを低減することに効果があるのか分析しているとは思えない。

例えば、「高速走行中にブレーキが効かなくなる」というリスクに対してこれらのマイコンはどのように有効に働くのだろうか。カーブを高速走行中にブレーキアイテムに不具合が発生したことが分かったり、緊急処置としての補助プロセスが起動されたりしている間に車のコントロールが効かなくなってスピンし始めても、上記のようなマイコンの機能は車の制御を立て直すことができるのだろうか。そんなことはECUの設計者、自動車システム全体の設計者に聞いてくれと言うのだろう。リスク分析が行われずに、何にでも効くという部品を作っても意味がない。

ところで、前者のマイコンの場合、下記のように書かれているから、ペースペーカが動かないというリスクには有効かもしれない。

専用の監視回路の導入により、内部状態の故障が即時に検出でき、故障発生箇所を絞り込むことが可能となります。そのため当社のマイコンは、最低限の機能を確保しながら動作を継続する「フェールオペレーショナル」が可能な電子制御システムへの組み込みに適しています。

複雑なプログラムであるデマンドペーシングが何らかの原因で効かなくなったときに、最低限の機能で固定レートのペーシングを続けることができるかもしれない。

しかし、よく考えて見て欲しい。そうであったとしてもペースメーカの電源の供給が絶たれれば、そのリスクコントロール手段はまったく意味をなさなくなる。

この話は福島の原発事故とよく似ている。どんなに考え抜かれたリスクコントロール手段を準備していても、補助電源を用意していても、結局「原子炉が制御不能になる」というリスクを回避することはできなかった。まったく電源を使わない状態でも原子炉を冷やす手段は用意されていたが、オペレーションの問題もあって有効には働かなかった。

今回の記事で言いたいのは、リスク分析やリスクアセスメントをしないで、安全に効果があるなどと言うのはやめなさいということだ。部品の信頼性を高めることはできても、安全はリスクを想定しなければ効果を主張することはできない。リスクを想定しないで、安全をうたうのは間違いだ。

機能安全はそもそも、部品単位での信頼性の向上が、システム全体の安全に貢献するかのように受け取られる傾向がある。

クリティカルな製品を作ってユーザーに対する責務を負う立場になれば分かることだが、安全を確保するためには、さまざまなことに気を配らないと目的は達成できない。

例えば、安全を確保するために十分に検証されたコンパイラを使ったとしよう。それで安全が確保されたのか。そんなはずはない、十分に検証されたコンパイラは決して、誤ったコードをはき出すことはないのか、どんなに複雑な条件であっても決定論的故障は起こさないのか。コンパイラの取り扱い説明書に誤記があって、それを信じて誤った使い方をした場合、それはコンパイラの不具合ではないと言うのか。コンパイラが完璧であったとして、ミドルウェアに問題があったらどうするのか。

コンパイラには関係ないユーザビリティに関するリスクは重要ではないのか。電源喪失時のリスクは考慮しないでいいのか。安全を確保するために必要なことを挙げたらきりがない。どんな些細なことも見逃さないように対策を始めたら、時間と工数は無限にかかる。したがって、有限な時間と工数で安全な商品やサービスを提供するためには、リスク分析、リスクアセスメントは欠かせない。ユーザーに対して最もリスクの高い障害のリスクコントロールから順番に対策を取っていかなければ、リスク対策は終わらない。

部品やツールの信頼性の検証活動は、システム全体のリスクコントロールのほんの一部でしかない。それだけに注力を注いでも、大元のリスクが大幅に軽減できるとは限らない。商品やシステムに責任を負うものは、それらをひっくるめてユーザーに降りかかるリスクを受容できるレベルまでコントロールしなければいけない。

自分はたまたまソフトウェアエンジニアでありながら、リスク分析、ハザード分析、リスクアセスメント、リスクコントロール手段の設計などを行いながら、商品の安全性と向き合ってきた。

ISO 26262の特集記事は、それらの経験を踏まえて、本当に安全を確保するにはエンジニアは何をやなければいけないのかを書いていきたいと思う。

【ISO 26262-2:2011 Part 2: Management of functional safety】

今回は ISO 26262-2 機能安全のマネジメント 5.2.2 安全ライフサイクルに関する注釈　を読み進んでいる。下記の図の説明となるので、図を手元に置きながら読んでもらった方がよいと思う。

※用語の定義の邦訳にあたり、ISO 26262 の全体像を説明する図も一部ことばを見直して Ver 1.01 としたので利用して欲しい。(ISO 26262 全体構造図　開くためのパスワードは"guild26262"）

(「セーフティライフサイクルの外観」開くためのパスワードは"guild26262"）

5.2.2 Explanatory remarks on the safety lifecycle
5.2.2 安全ライフサイクルに関する注釈

ISO 26262 specifies requirements with regard to specific phases and subphases of the safety lifecycle, but also includes requirements that apply to several, or all, phases of the safety lifecycle, such as the requirements for the management of functional safety.
ISO26262は、安全ライフサイクルの特定のフェーズとサブフェーズに関しての要求を定めまるが、安全ライフサイクルのフェーズ、機能安全のマネジメントのための要求などのようにいくつかの、またはすべてフェーズに適用される要求も含んでいる。

The key management tasks are to plan, coordinate and track the activities related to functional safety.
キーマネジメントタスクとは、機能安全に関連する活動を計画、調整、追跡することである。

These management tasks apply to all phases of the safety lifecycle.
これらのマネジメントタスクは安全ライフサイクルのすべてのフェーズに適用される。

The requirements for the management of functional safety are given in this part, which distinguishes:

つぎの部分で機能安全のマネジメントのための要求を与える:(部分は識別される)。

- overall safety management (see this clause);
- 全体的なセーフティマネジメント(この箇条を見よ)。

- safety management during the concept phase and the product development (see Clause 6);
- コンセプトフェーズ間のセーフティマネジメントと製品開発(箇条6を見よ)。

- safety management after the item's release for production (see Clause 7).
- 生産(箇条 7を見よ)のためのアイテムのリリースの後のセーフティマネジメント。

The following descriptions explain the definitions of the different phases and subphases of the safety lifecycle, as well as other key concepts:
以下の説明文では異なるフェーズの定義とセーフティライフサイクルのサブフェーズについて他の重要な考えと同様に説明する。:

a) The subphase:
a) サブフェーズ:

item definition
アイテム定義

The initiating task of the safety lifecycle is to develop a description of the item with regard to its functionality, interfaces, environmental conditions, legal requirements, known hazards, etc.
セーフティライフサイクルに関する開始タスクは、機能性、インタフェース、環境条件、法的要求、周知のハザードなどに関してアイテムの説明を作成することである。

The boundary of the item and its interfaces, as well as assumptions concerning other items, elements, systems and components are determined (see ISO 26262-3:2011, Clause 5).
アイテムとそのインタフェースの境界、および他のアイテムに関する仮定、要素、システム、およびコンポーネントは決められている。(ISO26262-3:2011を見よ。箇条 5)。

b) The subphase:initiation of the safety lifecycle
b）サブフェーズ：セーフティライフサイクルの開始

Based on the item definition, the safety lifecycle is initiated by distinguishing between either a new development, or a modification of an existing item.
アイテム定義に基づいて、セーフティライフサイクルは、新規開発か、既存アイテムの変更のどちらであるかを識別することによって開始される。

If an existing item is modified, the results of an impact analysis are used to tailor the safety lifecycle (see ISO 26262-3:2011, Clause 6).
既存アイテムが変更されているなら、インパクト分析の結果は、セーフティライフサイクルをテーラリングするのに使用される。(ISO26262-3:2011を見よ。箇条 6)。

c) The subphase:hazard analysis and risk assessment
c) サブフェーズ：ハザード分析とリスクアセスメント

After the initiation of the safety lifecycle, the hazard analysis and risk assessment is performed as given in ISO 26262-3:2011, Clause 7.

セーフティライフサイクルの開始の後、ハザード分析およびリスクアセスメントが ISO26262-3:2011、箇条7 によって実行される。

First, the hazard analysis and risk assessment estimates the probability of exposure, the controllability and the severity of the hazardous events with regard to the item.

まず最初に、ハザード分析とリスクアセスメントでは、アイテムに関して危険な事象の暴露の確率、コントローラビリティ、および重大度を推定する。

Together, these parameters determine the ASILs of the hazardous events.
これらのパラメータは危険な事象のASILを同時に決定する。

Subsequently, the hazard analysis and risk assessment determines the safety goals for the item, with the safety goals being the top level safety requirements for the item.

次に、ハザード分析とリスクアセスメントは、トップレベルの安全要求であるセーフティゴールとともに、そのアイテムのセーフティターゲットを決定する。

The ASILs determined for the hazardous events are assigned to the corresponding safety goals.
危険な事象のために決定するASILは対応するセーフティゴールに割り当てられる。

During the subsequent phases and subphases, detailed safety requirements are derived from the safety goals.
その後のフェーズとサブフェーズの間、詳細な安全要求がセーフティゴールから派生して得られる。

These safety requirements inherit the ASIL of the corresponding safety goals.
これらの安全要求は対応するセーフティゴールのASILを引き継ぐ。

d) The subphase:functional safety concept
d) サブフェーズ:機能安全コンセプト

Based on the safety goals, a functional safety concept (see ISO 26262-3:2011, Clause 8) is specified considering preliminary architectural assumptions.
セーフティゴールに基づいて、機能安全コンセプト(ISO26262-3:2011、箇条8を見よ)は予備的なアーキテクチャの仮定を考慮して明示される。

The functional safety concept is specified by functional safety requirements that are allocated to the elements of the item.
機能安全コンセプトはアイテムの要素に割り当てられる機能安全要求によって指定される。

The functional safety concept can also include other technologies or interfaces with external measures, provided that the expected behaviours thereof can be validated (see ISO 26262-4:2011, Clause 9).
また、機能安全コンセプトは、妥当性が確認され、予想された振る舞いを提供できるのであれば、外部計測を伴うインタフェースや他の技術を含むことができる。(ISO26262-4:2011を見よ。箇条9)。

The implementation of other technologies is outside the scope of ISO 26262 and the implementation of the external measures is outside the scope of the item development.
ISO26262のスコープの外に他の技術の実装がある。そして、外部計測の実装はアイテム開発のスコープの外側となる。

e) The phase:product development at the system level
e) システムレベルにおける製品開発

After having specified the functional safety concept, the item is developed from the system level perspective, as given in ISO 26262-4.
機能安全コンセプトを明示した後に、アイテムはISO26262-4で与えられるようにシステムレベル見地で開発される。

The system development process is based on the concept of a V-model with the specification of the technical safety requirements, the system architecture, the system design and implementation on the left hand branch and the integration, verification, validation and the functional safety assessment on the right hand branch.
システム開発プロセスはテクニカル安全要求によってVモデルの概念に基づいている。Vモデルの左手の枝にはシステムアーキテクチャ、システム設計、実装が、Vモデルの右側の枝には、結合、検証、バリデーション、および機能安全評価がある。

The hardware-software interface is specified in this phase.
ハードウェア-ソフトウェアインタフェイスはこのフェーズで指定される。

Figure 1 provides an overview of the subphases of the product development at the system level.
図1はシステムレベルで製品開発のサブフェーズに関する概要を提供する。

The product development at the system level incorporates validation tasks for activities occurring within other safety lifecycle phases, including
システムレベルの製品開発は他のセーフティライフサイクルフェーズの中で発生する次のような活動のためのバリデーションタスクを組み入れる。

- the validation of the aspects of the functional safety concept that are implemented by other technologies;
- 他の技術で実装される機能安全コンセプトの側面のバリデーション

- the validation of the assumptions concerning the effectiveness and the performance of external measures;
- 外部計測の有効性及び性能に関する仮定のバリデーション

- the validation of the assumptions concerning human response, including controllability and operational tasks.
- コントローラビリティ及びオペレーションを含む人間の応答に関する仮定のバリデーション

The release for production is the final subphase of the product development and provides the item’s release for series production (see ISO 26262-4:2011, Clause 11).
生産のためのリリースは、製品開発の最終的なサブフェーズであり、連続生産のためのアイテムリリースを提供する。(ISO26262-4:2011を見よ、箇条11)。

f) The phase:product development at the hardware level
f) フェーズ:ハードウェアレベルにおける製品開発

Based on the system design specification, the item is developed from the hardware level perspective (see ISO 26262-5).
システム設計仕様に基づいて、アイテムはハードウェアレベルの見地から開発される。(ISO26262-5を見よ）。

The hardware development process is based on the concept of a V-model with the specification of the hardware requirements and the hardware design and implementation on the left hand branch and the hardware integration and testing on the right hand branch.
ハードウェア開発過程はハードウェア要件の仕様でVモデルの概念に基づいている。左の枝ではハードウェア設計とインプリメンテーションが、右の枝ではハードウェアインテグレーションとテストがある。

Figure 1 provides an overview of the subphases of the product development at the hardware level.
図1はハードウェアレベルで製品開発のサブフェーズに関する概要を提供する。

g) The phase:product development at the software level
g) フェーズ:ソフトウェアレベルにおける製品開発

Based on the system design specification, the item is developed from the software level perspective (see ISO 26262-6).
システム設計仕様に基づいて、アイテムはソフトウェアレベルの見地から開発される(ISO26262-6を見よ)。

The software development process is based on the concept of a V-model with the specification of the software requirements and the software architectural design and implementation on the left hand branch, and the software integration and testing, and the verification of the software requirements on the right hand branch.
ソフトウェア要求の仕様、ソフトウェアアーキテクチャデザイン、およびインプリメンテーションが左手にあって、ソフトウェア統合、テスト、およびソフトウェア要求の検証が右手にあり、ソフトウェア開発プロセスはVモデルの概念に基づいている。

Figure 1 provides an overview of the subphases of the product development at the software level.
図1はソフトウェアレベルで製品開発のサブフェーズに関する概要を提供する。

h) Production planning and operation planning
h) 生産計画と運用計画

The planning for production and operation, and the specification of the associated requirements, starts during the product development at the system level (see ISO 26262-4).
製品開発の間、生産と運用のための計画立案、および関連要求の仕様はシステムレベルで始まる(ISO26262-4を見よ)。

The requirements for production and operation are given in ISO 26262-7:2011, Clauses 5 and 6.
ISO26262-7:2011箇条5と6 で生産と運用のための要求を与える。

i) The phase: production and operation, service and decommissioning
i) フェーズ:生産、運用、サービス、および廃棄

This phase addresses the production processes relevant for the functional safety goals of the item, i.e. the safety-related special characteristics, and the development and management of instructions for the maintenance, repair and decommissioning of the item to ensure functional safety after the item's release for production (see ISO 26262-7:2011, Clauses 5 and 6).
このフェーズは、アイテムの機能安全ゴールに関連した生産プロセスを扱う。すなわち、安全関連の特別な特性、保守や修理、開発、アイテムリリース後の機能安全を確実にするためのアイテムのデコンポジッションのための指示、訓練の開発やマネジメントなど。(ISO26262-7:2011を見よ、箇条5と6)。

j) Controllability
j) コントローラビリティ

In the hazard analysis and risk assessment (see ISO 26262-3:2011, Clause 7), credit can be taken for the ability of the driver, or the other persons at risk, to control hazardous situations.
ハザード分析とリスクアセスメント(ISO26262-3:2011を見よ、箇条7)で、危険な状態をコントロールするためのドライバーや危険に遭遇するその他の人々の技量の信頼度である。

The assumptions regarding the controllability in the hazard analysis and risk assessment and the functional and technical safety concept are validated during the safety validation (see Figure 2 and ISO 26262-4:2011, Clause 9).
ハザード分析とリスクアセスメントにおけるコントローラビリティに関する仮定と機能的でテクニカルなセーフティコンセプトは安全バリデーションの間で妥当性が確認される。(図2と ISO 26262-4:2011を見よ、箇条9)。

NOTE The exposure and the severity are factors that depend on the scenario.
ノート暴露と重大度は、シナリオに依存する要素である。

The eventual controllability through human intervention is influenced by the design of the item and is therefore evaluated during the validation (see ISO 26262-4:2011, 9.4.3.2).
人間の介入の結果として起こるコントローラビリティは、アイテムのデザインによって影響を受ける。したがって、バリデーションの間、評価される(ISO26262-4: 2011、9.4.3.2を見よ)。

k) External measures
k) 外部手段

The external measures refer to the measures outside the item, as specified in the item definition (see Figure 2 and ISO 26262-3:2011, Clause 5), that reduce or mitigate the risks resulting from the item.
外部手段はアイテム定義で示される(図2とISO 26262-3:2011を見よ、箇条5)アイテムから生じるリスクを低減または緩和するアイテムの外側の手段を示す。

External measures can include not only additional in-vehicle devices such as dynamic stability controllers or run-flat tyres, but also devices external to the vehicle, like crash barriers or tunnel fire-fighting systems.
外部手段はダイナミック安定制御装置やランフラットタイヤなどの追加的な車内のデバイスだけではなく、中央分離帯やトンネル消防システムのように車の外部のデバイスも含むことができる。

The assumptions regarding the external measures in the item definition, the hazard analysis and risk assessment and the functional and technical safety concept are validated during the safety validation (see Figure 2 and ISO 26262-4:2011, Clause 9).
アイテム定義、ハザード分析、およびリスクアセスメントにおける外部手段と機能的でテクニカルな安全コンセプトに関する仮定はセーフティバリデーションの中で妥当性が確認される(図2とISO 26262-4:2011を見よ、箇条9)。

External measures can be considered in the hazard analysis and risk assessment.
ハザード分析とリスクアセスメントで外部手段を考慮できる。

However, if credit is taken from an external measure in the hazard analysis and risk assessment, that external measure cannot be considered as a risk reduction in the functional safety concept.
しかしながら、ハザード分析とリスクアセスメントの中で外部手段から信用を得るなら、その外部手段は機能安全コンセプトの中ではリスク軽減と見なすことはできない。

ISO 26262 also applies to those external measures that are in the scope of ISO 26262.
また、ISO26262はISO26262のスコープのある外部手段として適用される。

l) Other technologies
l) 他の技術

Other technologies, e.g. mechanical and hydraulic technologies, are those different from electrical and/or electronic technologies that are in the scope of ISO 26262.

他の技術(例えば、機械技術、流体技術)はISO 26262のスコープの中にある電気的な、そして/または、電子の技術とは異なる技術である。

These can be considered in the specification of the functional safety concept (see Figure 2 and ISO 26262-3:2011, Clause 8), during the allocation of safety requirements (see ISO 26262-3 and ISO 26262-4), or as an external measure.

これらは、安全要求(ISO26262-3とISO26262-4を見よ)の割り当ての間、または、外部手段において機能安全コンセプト(図2とISO 26262-3:2011を見よ、箇条8)の仕様を考慮することができる。

NOTE If an implementation in another technology is specified as an external measure, then it can be useful to repeat the hazard analysis and risk assessment to consider the associated risk reduction, which could potentially result in a reduced ASIL of a corresponding safety goal.

注意もしも、他の技術の実装が外部手段によって指定されているのであれば、セーフティゴールに対応する潜在的に減少されたASILによって関連するリスクの軽減を考慮するハザード分析やリスクアセスメントを繰り返すことに役立つ。

ISO 26262との向き合い方 (7) 自動車ソフトの未来予想図

2012-01-03T14:48:00.000+09:00

正月休みの間、自動車業界が直面するであろう安全ソフトウェアの問題(=自動車ソフトウェアの未来予想図）について二つのシナリオ考えてみた。まずは、これら未来のシナリオを読んでみていただきたい。

シナリオ1 電気自動車時代の不具合

2020年、電気自動車用の充電プラグは家庭やコンビニエンスストアにも普及が進み、郊外には電気スタンドもよく見かけるようになってきた。充電場所が増えるにつれて、それまで聞いたこともない電気自動車メーカー、ブランドの車も数多く現れてきた。電気自動車の販売価格帯は二極化しており、老舗の自動車メーカーの150万円以上のブランド車と、アジアのメーカーの100万円以下の車に人気が集中している。低価格電気自動車は安いものなら50～60万円で買えるようになり、都心の若い世代ではこのような低価格電気自動車を個人で購入するのではなく、電気自動車がシェアカーとして用意されているマンションを選ぶようになってきた。

電気自動車の普及の裏で、困っているのは自動車の新規登録を許可している日本の規制当局だ。申請数が多すぎて数をさばききれない。かといって5年前に締結されたTPP協定によって、外国メーカーの自動車の新規登録が遅れると協定違反となって国際司法裁判所に提訴されるようになったから、手続きを遅らせる訳にはいかない。だから手続きは粛々とこなしていかなければならない。職員は増やしたが経験が追いついていないため、細かい見落としはどうしても増えている。

許認可の問題だけでなく、新規参入の自動車メーカーが作った自動車そのものの不具合が原因の事故も確実に増えている。電子制御のブレーキが突然効かなくなる、アクセルが急加速する、モータが急停止するといった、日本の自動車メーカーが起こしたらトップニュースになるような不具合が当たり前のように起こるようになった。電気自動車では部品をサプライヤから買い集めて組み合わせるだけで簡単に完成品ができるようになり、自動車ドメインでの経験をほとんど持っていない企業の電気自動車製造販売の参入が急増したことが原因だ。アセンブリメーカーはできるだけ安く自動車を作ることが使命であるため、もっとも安くECUを供給できるサプライヤからハード、ソフトを買う。自動車業界ではプラットフォームの共通化が進んだことで、どこのECUを買ってきても表面上は問題なく動くようになった。非常にわかりにくいソフトウェアに起因した不具合があることなど気にもせず、新規参入のアセンブリメーカーは安いECUを供給するサプライヤに次々と切り替えるため、これまで発生していなかった問題がECUの切り替えとともに突然起こったりする。

自動車のソフトウェアの作り方がすり合わせから組み合わせに変わり、規格化された共通インタフェースの部品を共通プラットフォームに接続することで基本的な電気自動車の機能が実現できるようになった。しかし、一つ一つの部品を一から作ったことがない、それどころか一つ一つのデバイスの性能限界もよく分かっていないアセンブリメーカーには、突然発生したソフトウェア制御のブレーキの誤動作やアクセルの急加速といった原因がまったく分からないし、何をどうやって調べればよいのか見当もつかない。したがって、このような原因不明の事故を起こした新規参入の自動車メーカーの車は、最近、日本では急速に販売数を減らしている。日本でも自動車雑誌にリコール情報の分析データがワーストランキングと共に掲載されるようになった。一方アジアの国々では、それでも低価格の電気自動車はまだ人気がある。

事故を起こしたメーカーも ISO 26262 適合というフレコミのECUを使っていた。アセンブリメーカー自身もISO 26262 のプロセス認定を受けている。それでも事故が起こるのはシステム全体に対する安全管理ができていなかったからなのだ。日本の自動車メーカーが当然のようにできていた不具合の原因追及や再発防止策の立案、継続的な改善活動が新規参入のアセンブリメーカーにはできない。しかし、だからといってアセンブリメーカーを市場から排除しようとすると非関税障壁だと訴えられてしまう。そうなると日本の消費者は自分の安全を自分で守るしかなくなる。事故情報を分析することで自動車の価格と自分の安全を天秤にかけるしかない。家庭電化製品と同じように消費者はまず、自動車の安全情報のサイトで事故情報と既存ユーザーの評判をじっくり読んでから、販売店に向かうようになった。2020年、自動車は選択を誤ると安心して運転できない恐ろしい乗り物になった。

シナリオ2 高級車に搭載するインテリジェンス安全機能の落とし穴

早いスピードには危険が伴う

2020年、ハイエンドの自動車にはセーフティに関する要求のさらなる多様化が進んでいる。もう、高級車市場におけるしのぎの削り合いのテーマはアメニティではなくセーフティに変わりつつある。それは、安価な低価格電気自動車がさまざまな事故を起こしていることで消費者のセーフティへの関心や要求が高まっているからだ。しかし、すでに当たり前にできていることの安全性能の向上、信頼性のアップはアピールしてもインパクトがない。カタログを見ただけでは認知してもらえない。事故が他社より少ないことを強調するネガティブキャンペーンのCMは日本では受けが悪いから、消費者からのよい評判を意図的にSNSなどに流しながら安心、安全のブランドイメージを高めるようにしている。

しかし、それだけではライバルメーカーとの競争に勝てないため、自動車の安全性を新しい機能という目に見える形で表し、テレビコマーシャルで宣伝する作戦に出る。例えば、ナビゲーションシステムとブレーキの連動機能だ。

老舗の自動車会社Aは飛躍的に進化したVICSからの情報を使い、車一台一台の正確でリアルタイムな移動情報とナビゲーションシステムを融合させて、これまでにない安全機能を新たな売りとすることにした。前方に迫る十字路をナビゲーションシステムで認知し、左右から来る自動車の存在と速度を進化したVICSの情報から得て、直進する自分の車が横からくる車に追突されそうになったときには信号の赤青にかかわらずブレーキが自動的にかかる機能をナビゲーションシステムのサプライヤと共同開発した。この機能が正しく機能すれば十字路での衝突事故を避けられるようになる。

40代の会社経営者のBは1年前にこの新しい安全機能を搭載した車をA社の販売店から購入した。このオプション機能の搭載により購入価格は50万円もアップしたが、命には代えられない。Bは前の車に乗っていたとき、黄色信号が終わりかけの交差点に高速で進入し、横からきた車と接触事故を起こしそうになった経験がある。その後、家族と会社の部下から、自分一人の命ではないのだから本当に気をつけてくれと言われていたのだ。

この新しい機能があれば、左右がよく見えない信号のない交差点でも安心だ。交差点の手前で速度を落とさなくても、スッーと安全に通過できる。危ないときはこの車が自動的にブレーキをかけてくれるのだ。

その日Bは深夜、午前3時に県道を飛ばしていた。前日の夕方、翌日から始まる自社商品のイベントの準備でトラブルが発生し、急遽自ら陣頭指揮を執り問題の解決にあたらなければならなくなった。トラブルが解決し、イベントの準備がすべてが終わったのが午前2時半だった。眠いし早く家に帰って少しでも多く睡眠を取りたい。郊外の家に着くまであと5キロ。車の通りもほとんどなくなって、車は制限速度を30キロもオーバーしていた。「ああ、交差点の信号が黄色から赤に変わりかけている。」「でも、セーフティ機能があるからぶつかりそうになればブレーキがかかるし、ここはアクセル全開だ。」

その数秒後、交差点に入った瞬間にちょうど青信号になったばかりの左側の道路からきたCが運転する軽自動車に側面衝突した。Bの車のセーフティ機能は働かなかった。

この事故でBとCは大けがをした。もちろんBの信号無視が原因だった。その後自動車会社Aはなぜこの事故が発生したのか原因を突き止めるために、ECUとナビゲーションシステムに記録されていたデータログを徹底的に解析した。

原因はその日のその時間、VICSシステムがメインテナンスのため5時間ほど機能を停止しており、その情報にBが気がついていなかったからだということが分かった。実はナビゲーションシステムの取り扱い説明書にはこのことは注意として書かれており、実際VICSシステムの稼働中アイコンもそのときはナビの画面から消えていた。これまでBはVICSシステムの情報受信のアイコンなど気に留めたことなどなかった。

この件について、自動車会社Aがナビゲーションシステムの供給会社Dに厳しく問いただしたところ「何も間違った情報は送っていない。VICSが稼働中かどうかのステータスは正しく表示しているし、ブレーキシステムにも通信している。取り扱い説明書で表記上の対策もしている、できることはすべてやっているので我が社には過失はないと考えている。」という回答が返ってきた。

自動車会社Aのチーフエンジニアは頭を抱えた。これまでこんなことが起きたことはなかった。ブレーキシステムを担当するサプライヤはその機能と性能を隅々まで把握し、エンドユーザーに対して責任を感じながら完璧な仕事をしてきた。ところが、新しいセーフティ機能を次々に加えていった結果、自動車の安全機能がどんなときにも期待通りに働くのかどうか自信が持てなくなってきた。誰に聞いたら確信が持てるのか分からなくなってきた。それほど、システムは複雑化している。

昔の車作りのチームなら、VICSのサービスが提供されないことのリスクがどんなハザードにつながるのかチーフエンジニアの自分が気がつかなくても、誰かが気がついて対策を取っていた。それが今ではできなくなっている。リスクを分析して一つ一つのハザードに対するリスクコントロールの実装を確認していかないと、安全機能に関する確証が持てない。確実に自動車の作り方は変わってしまった。いや、変えないと安全な自動車を提供できなくなったのだ。事故が起こるたびに何十年もかけて築いてきた信用ががた落ちになる。10年前に導入した ISO 26262 は役に立たない形式的なものだと思っていたが、今初めて真剣に取り組まなければいけないと実感した。

2つのシナリオから考える自動車ソフトウェアの未来予想図

車には子供が乗っているかもしれない

上記の2つのシナリオはあながちありもしない空想ではないと考えている。TPP協定が締結されたら、日本にしかないガラパゴス的な非関税障壁は次々と訴えられる可能性がある。すぐさま国際標準に対応できるほど、日本はしっかりとした基盤を持っていない。言語の問題もあるが、国際標準を教えるよい教材、よいトレーナー、よいコンサルタントが不足しているし、それらに投資するという考え方も組織の中に醸成されていない。

また、欧米のやり方でこれまでの日本製品の品質が実現できるわけではないので、欧米の要求を日本向けにテーラリングしないといけないのに、日本人はそれが大の苦手ときている。

一番目のシナリオは電気自動車の普及にともない部品の組み合わせで自動車ができてしまうという話だった。ブラックボックスの部品の組み合わせで自動車が作られてしまうことで、システム全体としての安全が脅かされるという話は、共通プラットフォーム化、ECUの共通インタフェース化が進めば絶対に増加する。

中身が分からないブラックボックスのソフトウェア部品をハードウェア部品と同じ取り替え可能な部品として使い始めたら不具合は減らない。ISO 26262 への適合を目安にすることはできるが、ISO 26262 の要求に沿って作りましたという ECU ではリスクを回避できない。なぜなら、ISO 26262 はリスク分析の結果から考えたリスクコントロール手段をセーフティマネージャ（自動車メーカー）がサプライヤに要求し、安全を管理することでリスクを回避する。システム全体のリスクを分析しないで、お墨付きがあると差し出された ECU はそもそも想定されたリスクを受容できるまで低減できているという担保がない。どんな事故が起こる可能性があるかを分析しないで、オールマイティなセーフティ機能を実装することはできない。すべてのリスクに効果のあるリスクコントロール手段などない。危ない時に制御を止めなければいけないケースと動かし続けなければならないケースはどちらも存在する。だから、サプライヤだけではリスク分析はできないのだ。人や組織も含めた安全管理やシステム全体のリスク分析抜きに、ソフトウェアをハードウェアと同じように代替えできる部品と考えたら、その時点で安全は脅かされる。そのことにどれだけの自動車メーカーやサプライヤが気づいているかが心配だ。

二番目のシナリオは、安全機能を複雑化させたために起こるディスコミュニケーションの悪影響の結果だ。全体を見通せなくなった時点で古い日本の安全確保の方法論は力を失っていく。しかし、プロセスアプローチだけで安全が確保できるわけではないので、日本のプロジェクト向けの安全へのアプローチを規格をテーラリングしながら考えなければいけない。

このことは、CMMIのレベル5を取った、取らないといった話とは次元が全く違う。CMMI のレベル5を取った組織が、ソフトウェアの不具合を起こしたとしてもクライアントから嫌みを言われるだけだろう。CMMIは営業が仕事を取るための道具にはなっても、プロダクトアウトしたソフトウェアの信頼の証にはならない。

しかし、ISO 26262 への適合は安全や信頼の指標にならなければこの規格ができた意味がない。そうでなければ技術者が苦労して規格に適合するために積み重ねた努力が無駄になる。そして、規格適合が形骸化すれば上記のシナリオのように事故が起きたり人が死んだりするかもしれない。消費者から嫌みを言われて終わるレベルの話ではない。真剣に取り組まなければ人の命に関わる可能性があるのだ。

そういう気持ちを持ってエンジニアは規格適合に取り組んで欲しいと思っている。このことは自動車ドメインのエンジニアだけでなく、リスクを抱えた製品、クリティカルな製品に携わっているすべてのエンジニアに言いたい。2011年3月に日本で発生確率が極めて低いが、発生したときの被害の重大度が極めて大きい事故が起こった。リスクの大きさ = 発生確率 × 被害の重大度という従来の安全工学の考え方を見直さなければいけないかもしれない。（ISO 26262ではハザードの評価において、発生確率と被害の重大度に加え、回避可能性の要素が考慮されている。）

被害の重大度が大きければ、ppmオーダーでもリスクは大きいと考えなければいけないのではないだろうか。また、発生確率が予測できないソフトウェアの不具合の場合、どうやってリスクを制御すればいいのかソフトウェアエンジニアが真剣に考えなければ、誰が安全な製品を作れるのだろうか。

あんな事故があっただけに、2012年、エンジニアはどうすれば事故の再発を防止できるのか、これから起こるかもしれない事故を未然に防ぐことができるのか、自分達の技術は事故の予防や再発防止のどのように役立つのかをよく考えて、安全という同じ目標、同じ価値観をもって日々の仕事に取り組む義務があると考えている。

ISO 26262-1:2011 Part1 Vocabulary(用語の定義）

ISO 26262-1 Part1 Vocabulary（用語の定義）

(「ISO 26262 用語の定義」開くためのパスワードは"guild26262"）

ISO 26262-1 Part 1 Vocabulary では 142の用語の定義が記載されている。用語を正しく理解して規格を読み進むことは重要である。この142の用語の定義を邦訳したので参考にして欲しい。なお、この邦訳は突貫で作ったため間違いや用語同士での説明の不一致があるかもしれない。

そのような箇所を見つけられた方は是非連絡をして欲しい。多くの人のチェックを経て完成度を高めていきたいと思う。また、本資料を利用される方は常にバージョンを確認して欲しい。間違いに気がついたら修正を加えてバージョンを上げていくつもりだからだ。

さて、142の用語を邦訳しながらあることに気がついた。それは、これらの用語はつぎの3種類に分類できるということだ。

【ISO 26262-1 で定義されている用語の分類】

安全・品質工学、規格適合に関する用語（43語）
ソフトウェア工学に関する用語（30語）
自動車ドメインまたはISO26262特有の用語（69語）

邦訳の中では「安全・品質工学、規格適合に関する用語」は赤色に、「ソフトウェア工学に関する用語」は青色に「自動車ドメインまたはISO26262特有の用語」は緑色に色分けしている。

分類は主観によるものなので異論もあるかと思うが、カウントしたら1が43語、2が30語、3が69語あった。これが示すことは何か読者の皆さんは分かるだろうか。

それは、ISO 26262 という規格は、安全工学・品質工学または国際規格への適合に関する知識を有する者、ソフトウェア工学の知識を有する者、自動車ドメインに造詣が深いまたはISO 26262 の規格策定に関わった者の3者が互いに協力しないと完全には理解できないということである。

ソフトウェア工学だけではダメだ

安全工学・品質工学の基礎があり、国際規格や規格適合の監査に慣れている者でも、ソフトウェア工学を深く知るものは少ない。また、ソフトウェア工学、特にプロセス改善の指導を得意とするものは、安全工学の知識を持っている者は少なく、規格適合の監査などの経験も少ないだろう。自動車ドメインの特殊な知識 ECU（電子制御ユニット）の仕組みも詳しくないと思う。一方、自動車ドメインの専門家でソフトウェア技術者の場合、安全工学は専門外だろうし、規格適合の監査は ISO 9001 くらいでしか受けたことがないだろう。（ISO 9001すら取得していない会社もあることだし）

よって、ISO 26262 に本気で取り組もうと思ったら、この3者が一つの目的、一つの目標に向かって協力しなければダメだ。それぞれの専門家が自分の強みを主張して、自分の専門分野に相手を引き込もうとしたり、相手が自分の専門領域のことを知らないことを「そんなことも知らないのか」と心の中で馬鹿にし出したりしたら、バラバラになって空中分解する。ついでに言うと、それまで知らなかったことを新しく知ったことで知ったかぶりをする者が出てきても調和は乱れる。

3者のディスコミュニケーションは相手が認知していない言葉を意識しないで使い始めたときから始まる。自分が知っている言葉を相手が知っているかどうか考えながらしゃべれる人は、主観と客観を自在に操れる人であり、世の中にそれほど多くは存在しない。ほとんどの人は自分が知っている言葉は相手も知っていると思って話をしてしまう。そして、日本人は奥ゆかしいから分からない言葉が出てきたところで、「その言葉の意味が分からないから教えて欲しい」となかなか言わない。

さて、コミュニケーションギャップの可能性を ISO 26262 の用語の例で考えて見よう。例えば、anomaly（異常）、 harm（危害）、 hazard（ハザード）、 severity（重大度）といって何のことだか、ソフトウェア工学や自動車ドメインの専門家はピンとくるだろうか。また、partitioning（パーティショニング）、baseline（ベースライン）、branch coverage（分岐カバレッジ）、 walk-through（ウォークスルー）について、規格適合コンサルタントはその意味を説明できるだろうか。また、ASILデコンンポジション、exposure（暴露）、redundancy（冗長性）について、正確に解説できる者はいるだろうか。

ちなみに、自分は最初の二群はキチンと説明できるが、最後の自動車ドメインや ISO 26262 特有の用語については自信がないところもある。

このように、分からない言葉が出てでて、そのままにしてしまうと人間は思考を停止してしまったり、自分の勝手な思い込みで解釈してしまったり、そもそも自分の専門分野でない、担当分野でないと考えることを放棄してしまったりする傾向がある。

そのような状況が現れ出すと、それは冒頭で紹介したシナリオ1やシナリオ2が始まったことを示す。ISO 26262-1 の用語集が示しているのは、この規格は3つの専門領域を合わせないと規格が目指している目標を達成できないということなのだ。セーフティマネージャが3つの領域を完全に理解することは難しいだろうが、それぞれの領域の担当は他の領域の知識を学習して、より多くのオーバーラップを持つことが求められる。そして、大事なのは安全という共通の目的、安全を確保するというエンドユーザにとっての価値を共通認識とすることだ。

自動車ドメインの場合は、上記の3つの専門領域の区分けとは別に、自動車メーカーとサプライヤという立場があるため、問題はより複雑であり、共通の目的、共通の価値観を持って規格への適合を達成するのはさらに困難を極めると予想される。

自分が考えるうまくいくシナリオは、はやり自動車メーカーにしてもサプライヤにしても、自動車ドメインの技術者が安全工学、品質工学、ソフトウェア工学について学習を重ね、それぞれの専門家からアドバイスをもらいながらも自分達が主導権を取って規格適合を進めていくという流れだ。なぜなら、規格適合を監査する者やプロセスコンサルタントは、なんだかんだ言っても自分達の仕事がエンドユーザーの命に関わっているとは考えていないだろうし、エンドユーザーの命に対してなんら責任もないからだ。しかし、自動車メーカーのエンジニアと、安全に関わるソフトウェア、ハードウェアを納品するサプライヤは違う。自分達には安全に関わる機能・性能に対して責任があると認識して仕事をしているだろう。何か事故が起これば他人からも責められるし、自分自身も責めてしまうのが日本のメーカーとサプライヤのエンジニアだ。その責任の範疇の中にいるのか外にいるのかの差はとてつもなく大きい。中にいる者は人の命を背負っているが、外にいる者はそこまでの責任は感じていない。

別な言い方をすると、そのような責任感が品質の向上に寄与するようなやり方を脱するために作られたのが ISO 26262 なのだが、現実には品質を心配する意識とプロセスアプローチの両方がないと安全は確保出来ないというのが自分の考えだ。ISO 26262 の形骸化が始まったら、安全の確保は危うくなると思っている。

規格適合は役に立たないと考えずに、たましいを入れて取り組くむには、ひとつ見方を変えればよい。ISO 26262 の適合という機会は、自分自身の幅を広げるまたとないチャンスだと考えればよいのだ。自分がブログサイトでこの特集記事を書いているのは、読んでくれる読者がいるからだけれども、それにもまして記事を書くことが自分自身の知識の幅を広げることにつながり、結果的には自分のドメインでも役に立つし、それまで気がついていなかったことがたくさんでてくることが分かっているからだ。

実際、ISO 26262 の用語の定義を邦訳して、医療機器ドメインでの解釈とかなり違うところがあることがわかった。例えば、ISO 26262-1 には validation や software validation に関することばの定義がない。 safety validation ：セーフティゴールが満足され、達成されたことを試験やテストに基づいて保証すること、という簡単な説明しかない。なぜか。おそらく、自動車ドメインではユーザーインタフェースや、ユーザーのオペレーションに起因する不具合や事故がまだ、それほど多くないのだろう。それらが多くなって、ユーザビリティに対する対策の必要性が高まってくると、validation（妥当性確認）の解説はもっと長くなってくると思われる。（いずれくわしく説明をしたいと思う。）

逆に医療機器ドメインでは ASILデコンポジッションのような考え方がまだ確立していない。ハードウェアにしろ、ソフトウェアにしろ安全を確保するためのアーキテクチャに関する研究が進んでいない。

技術者は技術で安全に貢献できることがある

このように専門分野やドメインを超えて知識を深めていくと、今まで気がつかなかったことに気がつき、新しいアイディアが生まれる。そのアイディアが機器の安全につながるのであれば、自分や自分達が作る製品、商品の価値を高めることに貢献する。

そう考えれば、新しい分野を勉強する時間は自分をより高めることに有益であり、決して無駄ではないことが分かる。

2012年の新年を迎えて、まだまだ勉強すべきことは山ほどあると再認識したところである。

ISO 26262との向き合い方 (6) 機能安全のマネジメント2

2011-12-23T07:58:00.001+09:00

今週、下記のような記事が Tech-On! に掲載された。（読むには無料のユーザー登録が必要）

【専門記者が振り返る】要件管理とトレーサビリティ、この1年――ISO 26262適合で日本でもツール基盤の導入進む

変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。

要件管理のツールとして「Rational DOORS」、米PTC社の「Integrity」、フランスDassault Systemes社の「Reqtify」が挙げられており、国内のツールとしては経済産業省から約5億円の助成を受け、組み込みソフトウエア開発ツール・ベンダーのキャッツなどが中心となって、「TERAS」というツール基盤を目下、開発中であると書かれている。

※そういえば Google が検索エンジンのスタンダードになりつつあったときに、経済産業省が主導して国産検索エンジンを作ると言っていた『情報大航海プロジェクト』はいったいどうなったのだろう。

自分は、日本では要件管理ツールは日本のソフトウェアプロジェクトにはなじみにくい、ツールの価格（Integrityはサーバー側で200万円、クライアント側ノードロックで1本40万円。）だけの価値、効果を導き出すことは難しいと思っている。

なぜなら要件管理ツールは要求定義→アーキテクチャ設計→実装というトップダウンの開発に向いており、すでにベースとなるソフトウェアシステムがあって、変更しながらものづくりを進めていくような大量に変更が発生するプロジェクト、また、要求定義を横に置いてまず作り始めてしまうような開発は想定していないからだ。（そうしないことを強制するためにツールの使用を強制するということはあるかもしれないが）

ところが、日本のソフトウェア開発ではこれまでボトムアップで作ってきていて、要求定義が曖昧なままものづくりを進め、ガンガン修正してそれなりの品質のソフトウェアを作ってしまう。

※医療ドメインではUSでAgileをクリティカルソフトウェアに使う場合にどうすれば安全を確保できるかというガイダンスが今作られている。

そのやり方がよいとは言わないが、一つ言えるのは日本ではボトムアップでソフトウェアを作っても、それほどひどい品質にはならない。要求定義をしっかりやって、そこを動かさずに先に進むという開発ができていないのに、なんとかなっているという現状だ。どんなに優れたプロセスやツールが使われている欧米製品よりも、必ずしもそのようなプロセスやツールを使っていない日本製品の方が品質がいいのはなぜなのか、これから先も、そのやり方でこれからも突っ走っていいのかどうかをじっくり考えてから、ISO 26262 を取り入れないと失敗すると思う。

日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識：Awareness: Worrying about Quality の力ではないかと思っている。（これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。）

ユーザー要求はプロジェクトメンバの頭の中にたたき込まれていて、同じメンバが商品や商品群のライフサイクル全般に渡って関わっているので、要求定義を文書化する必要がないのだ。

だから、現場のエンジニアにとって要求分析の結果を文書にすることは「余計なこと」「規格要求のため」「作るのがルールだから」になる。要求管理が本質的な意味で役に立っていない。

これが、例えば製品開発ごとに人がごっそり変わったり、それまで開発経験がまったくないメンバを半分以上投入するようなプロジェクトだったらそうはいかない。トップダウンで粛々と進めていかないとものができてこない。要件管理ツールは、そういうトップダウンの開発にフィットしている。

構成管理や変更管理が日本でも受け入れられているのは、構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。（構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。）

さて、要件管理は製品開発にとって、ユーザーの安全確保にとってなぜ重要なのか。それは、商品の潜在的価値（別な言い方をすれば当たり前品質）に関係がある。

ユーザーは安全は当たり前に確保されていると考えている。商品を使うユーザーはメーカーがキチンと安全設計をしており、多少荒っぽい使い方をしても安全になるように作っていると信じている。特に日本製品には絶大な信頼を寄せている。

余談だが、最近の技術系新人はものづくりを企画立案からリリースまでやりきって他人に提供する経験をしたことがある者が極端に少ない。エンジニアなのに使う側の視点しかなくて、作る側の視点がほとんどない。だから、商品が当たり前にできていること、安全を実現している技術がなんだかまったく分からないし、分かりたいとも思わないし、裏方の技術に感動した経験がない。エンジニアなのに消費する側の気持ちが抜けきれていない。iPad や iPhone のユーザーインタフェースの良さをさかんに強調し、これを取り入れた方がよいと言ったりするが、その裏側にある技術については何にも知らない。このような者たちにはスティーブ・ジョブズの伝記を読んで、iPad や iPhone の誕生の裏側に何があるのか理解し、自分でも同じことができるかどうか考えてみろということにしている。

さて、製品の安全を信じているユーザーに対する保証はなんだろうか。これまでの日本では、それはエンジニアの頭の中の「品質を心配する意識：Awareness: Worrying about Quality」だった。安全を担保している技術は技術者の中にたたき込まれており、組織の中で先輩から後輩へ伝承されてきた。プロジェクトがフラットであるため、問題が起こったときに全員がその問題に対して協力して対処することで、品質に関する意識がプロジェクト全体に醸成された。設計の規範が構築されていくのだ。

誰かに命令されたからではない。エンドユーザーに迷惑をかけたことが技術者として恥じだと思うから、一刻も早く顧客満足を回復したいからプロジェクトが全員で一丸となって対応するのだ。

ところが、前述のように近年商品の当たり前にできていることを支える技術がなんだか分からない技術者が増えてきて、また、ソフトウェアシステムの規模が増大かつ複雑化してくるとユーザー要求や商品の使われ方を熟知しているプロジェクトリーダーであっても、プロジェクトメンバ全員の安全確保の意識やスキルに自信が持てなくなり、そして、商品の安全を確信できなくなってきている。

その状態を回避し、ユーザーの期待（安全は当たり前に確保されているはず）に答えるには、安全に対する要求と、その実現方法、実現の結果（証拠）を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。

要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。

しかし、日本では上記のことがプロジェクトメンバ全員に理解されていなければ、要件管理ツールは必ず形骸化する。要件管理ツールを導入しただけなら、重要な要求も、どうでもいい要求も同じレベルで管理されることになるだろう。そして、日本のプロジェクトではどうでもいいことは、ものすごい勢いで変更をかけるのでツールを使ってもかなりの手間だと感じるに違いない。

だから、要件管理をしっかり実施して、トレーサビリティマトリックスを維持するのなら安全に関わる重要な要件とそうでない要件を分離することが必要になる。要求分析を行う手法としては品質機能展開（QFD）などがあるから、日科技連でしっかり勉強して、重要な安全に関わる要件と、仕様と検証記録を Excel シートで管理してみて、管理工数が一人あたり 40万円を超えるようなら要件管理ツールを使ってみればよい。（Google Document を使えばExcelも買わなくていい）

または、ボトムアップ的な要件管理ツールの使い方なら組込みソフトでも有効な可能性はある。例えば、すでにあるソフトウェアシステムのアーキテクチャを UML で描いて、そのモデルの元となる要求はどんなものかを逆に分析してツールで可視化するというやり方だ。ユースケースをトップにするのではなく、ユーザー要求の分析がトップになるように可視化を進める。

技術者の頭の中にある暗黙のアーキテクチャとユーザー要求を目に見える形にトレースし直して、可視化した後は、明示化した方の要求とモデルを維持する。そして、ソフトウェアシステムのアーキテクチャを表すモデルとユーザー要求とを行ったり来たりしながら、最初に考えたアーキテクチャが崩れないように慎重にソフトウェアシステムに変更を加えていく。これなら現場にも受け入れられる。この方法は、スパークスシステムズジャパンの　Enterprise Architectと RaQuest で実現できる。モデルの描画はEnterprise Architectで、要件管理はRaQuestで、そしてこの二つのツールを組み合わせると要件とアーキテクチャの関係を関連づけることができる。二つ合わせても5万円以下だ。

ソフトウェアは見えにくいからツールの効果も数字で表しにくいが、それでもソフトウェア組織を率いる責任者はツール類に投資した資金がどのように組織に貢献しているのかを定期的に検証しなければいけない。末端のエンジニアはそのツールがそこに当たり前のようにあるものだと思って使っているだろうが、彼らにはそのツールにどれくらいの費用がかかっており、その費用分の効果を出す義務がエンジニアやプロジェクトにはあるのだという意識を植え付けなければいけない。

だから思う。一本50万円とか、100万円する要件管理ツールは、問題が発生したら数十億円規模の損害が発生するような事業、プロジェクトに使う。それは軍事産業や航空宇宙開発、原子力開発などだろう。実際そのようなツールはそういう業界で使われているのであって、自動車業界でペイするのかどうかについては疑問がある。何かあったら、数十億円の損害が出るようなコンポーネントがあるのなら、そのコンポーネントの開発に対して導入して、開発のスタイルをトップダウンの設計に切り替えばよい。しかし、単純に ISO 26262 という規格に適合するために一本数十万円する要件管理ツールを導入するのなら「気前がいいですね」と自分なら言う。また、形骸化していないかどうか3年間は定期的なチェックをお勧めする。3年たって組織内で習慣化するところまでになれば、大丈夫、形骸化はしない、組織の文化として根付くだろう。

要件管理だけでなく、日本のソフトウェアプロジェクトではたましいの入っていない活動（Activity）は必ず形骸化する。アウトプットドキュメントは「言われたから作っているだけ」「役に立たないがルールだから作っています」という代物になる。

それが積み重なっていくと技術者たちは「組織が、無駄なドキュメントを作らせているから開発が遅れる」と言い出す。サプライヤは「何も現実を分かっていないクライアントが作れと言っているので無駄だと思いつつもしかたなく作っている」という状態になる。そうではない。それは嘘だ。その技術者は無駄ではないドキュメントを作るスキルがない、そのドキュメントを作る意味を理解していないことを他人にせいにしているだけなのだ。

ISO 26262 の導入によって、日本では確実に「組織が無駄なドキュメントを作らせているから開発が遅れる」と不満を漏らす技術者が増大する。この台詞を吐く技術者には二通りあって、ひとつはソフトウェア品質に自信があるのに余計なことをやらされていると考える者、もうひとつはスキルもなくやっつけ仕事で書類の作成をしている者。

前者には、ISO 26262 が達成しようとしているユーザーの安全に対して共通の価値観を持てるように徹底的に議論することで道が開ける。後者はどうしようもない。実際に規格要求の求めに対して、まったくたましいの入っていない、うわべだけ取り繕った書類を見たことがある。彼らは要求者から注意を受けない限りうわべだけの書類作りを繰り返す。そいういう場合は、粛々と是正を要求する。そう、このやり方が欧米流のプロセスアプローチなのだ。たましいの入っていない技術者、プロジェクト、組織に対して、ルールとシステムで安全を確保する方法が欧米流のプロセスアプローチであり、ISO 26262 は基本的にはそのやり方だ。

一方、技術者の品質を心配する意識： Awareness: Worrying about Quality に働きかけ、たましいの入った成果物を作って、それがプロジェクト全体に伝搬し、改善を積み重ねていくのが日本流のやり方だ。

自分が自動車業界の皆さんに聞きたいのは、どっちのやり方で ISO 26262 への適合を進めようとしているのかということだ。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、今回は Management of functional safety のOverview of the safety lifecycle を見ていこう。図は前回と同様に、英文をトレースし直したものと日本語にしたものをペアにして PDF にした。

(「セーフティライフサイクルの外観」開くためのパスワードは"guild26262"）

5.2.1 Overview of the safety lifecycle
The ISO 26262 safety lifecycle (see Figure 2) encompasses the principal safety activities during the concept phase, product development, production, operation, service and decommissioning.

ISO 26262 セーフティライフサイクル（図2）は、コンセプトフェーズ、製品開発、生産、運用、保守及び廃棄の間の主要なセーフティアクティビティを包含する。

Planning, coordinating and documenting the safety activities of all phases of the safety lifecycle are key management tasks.

セーフティライフサイクルのすべてのフェーズにおいて、安全活動を計画すること、コーディネートすること、文書化することはキーマネージメントタスクである。

→安全活動の全般において、計画とコーディネイトと文書化が重要といっているということは、すなわち、ISO 26262-6 のソフトウェアレベルでの製品開発だけを切り出して、そこだけの要求を満たそうとしたのでは、セーフティライフサイクルは機能しない、すべてのフェーズにおいてセーフティマネジメントの計画が浸透し、各活動がリンクしていなければ、安全という目的は達成できないということを言っている。このことを分かって活動しているかどうかがとても不安。切り出し始めたら形骸化も始まる。

Figure 2 represents the reference safety lifecycle model.

図2はセーフティライフサイクルのリファレンスモデルを表している。

→この図は是非手元において自分が今やっている活動が全体のどの部分に相当するのか、製品開発のフェーズにいるのなら、コンセプトフェーズの要求を満たしているかどうかをチェックして欲しい。

Tailoring of the safety lifecycle, including iterations of subphases, is allowed.

サブフェーズの反復を含む安全ライフサイクルのテーラリングは容認されている。

→ウォーターフォールモデルのように見えるが、一つ一つの箱または複数の箱を繰り返すようなプロセスにしてもよいということ。セーフティライフサイクルにおいても自組織に合わせてプロセスのテーラリングをした方がよいということだ。概念だけでなく活動の実態に合わせて、テーラリングしたプロセスを可視化しておくのがよいだろう。

NOTE 1 The activities during the concept phase and the product development, and after the release for production are described in detail in ISO 26262-3 (concept phase), ISO 26262-4 (product development at the system level), ISO 26262-5 (product development at the hardware level), ISO 26262-6 (product development at the software level) and ISO 26262-7 (production and operation).

NOTE1 コンセプトフェーズ及び製品開発間のアクティビティ及び、生産のためのリリース後については、ISO 26262-3(コンセプトフェーズ）、ISO 26262-4（システムレベルの製品開発）、ISO 26262-5(ハードウェアレベルの製品開発）、ISO 26262-6(ソフトウェアレベルの製品開発）そして、ISO 26262-7(生産及び運用）に詳しく説明されている。

NOTE 2 Table A.1 provides an overview of the objectives, prerequisites and work products of the particular phases of the management of functional safety.

NOTE2 表A.1 は、機能安全のマネジメントの特定のフェーズの目的、前提条件、及び作業成果物の概要を示している。

→表A.1 は前回の記事『ISO 26262との向き合い方 (5) 機能安全のマネジメント1』にあるのでそれを参照して欲しい。

※今年の ISO 26262 の特集記事はこれで終了になります。また、来年をご期待ください。自動車業界の皆様また、ツールベンダーの方、規格認証機関の方、ご意見、ご質問があれば随時受け付けますので是非お送りください。

ISO 26262との向き合い方 (5) 機能安全のマネジメント1

2011-12-17T10:23:00.000+09:00

ISO 26262 に関するアンケートで　「お金や工数がどれくらいかかるか知りたい。」に5票入っていた。そこで、インターネットでいろいろ調べてみたら、アメリカの KVA という会社が ISO 26262 のトレーニングのオーダーシートを公開しており、そこに金額が書かれているのを見つけた。（KVA のサイトURL http://www.kvausa.com）

↓オーダーシートのURL はこちら
http://www.kvausa.com/sg_userfiles/kVA_ISO26262_Training_Registration_2011_10.pdf

トレーニング項目と金額の部分だけ書くとこうなる。

Day 1: Functional Safety Management Training	$895	約7万円
Days 2 & 3: System and Hardware Level Implementation of ISO 26262 including FMEDA workshop and FMEDA Workbench database tool for reliability calculation according to ISO 26262	$2,095	約16万円
Day 4: Software Level Implementation of ISO 26262	$895	約7万円
Days 1, 2, 3 & 4: Special Bundled Rate	$3,755	約30万円
Days 1, 2, 3 & 4 Plus Qualifying Exam for FSCAE Certification FSCAE examination not available without full 4-day training session	$4,755	約37万円

1日目は機能安全マネージメントトレーニングで、2日目、3日目はシステム&ハードウェア実装、4日目がソフトウェア実装となっている。全部合わせると約30万円、一番下の行にある FSCAEとは Functional Safety Certified Automotive Engineer の略で、この会社が独自に設定した認定資格のことのようだ。この認定資格の試験を入れると総額で約37万円となる。

さて、日本のこのブログの読者の多くが、この価格を高いと感じたと思う。しかし、自分はそれほど驚かない。なぜかというと医療機器の世界でもアメリカでトレーニングを受けようとするとこれくらいの金額が要求されるからだ。

ここでよく考えて欲しい。欧米では安全や信頼はルール/責任、システム/ツールで確保するのだ。一方、日本では品質を心配する意識の強さが安全や信頼の実現に貢献している。しつこいようだが今一度『USとJapanの文化の違いと商品品質との関係』の記事を読み返して欲しい。

欧米では組織内のルール/責任に対する力が強いので、このようなトレーニングを受ける者は教育資格を根拠に組織内で責任と権限を持つ。そして資格を持ったものがトレーニングで得た知識と権限を使って、作業者へ指導をする。機能安全の要求実現に関しては資格保有者が上、作業者が下になる。組織で階層構造ができている場合に有効なアプローチだ。セーフティマネジメントのマネージャは規格の要求事項ができていないと判断したときには是正を要求できる権限を組織から与えられているし、是正を要求された方も粛々と実施する。しかし、定時になればきっちり帰る。後ろめたさはない。問題が発生したのはシステムがきちんと回っていなかったからであり、作業者の資質ではない。スキルが足らないのなら、追加のトレーニングを行う義務は組織にある。このような、是正の指摘を自分の失敗や恥じだとは思わない、考えない階層構造の組織において、品質システムはうまく機能する。

だからこそ、責任を任される者はその責任と権限に見合った知識、スキルを持っていないと上と下から「お前は能力がないから辞めろ」とか「あの上司は能力がないから辞めさせてくれ」と言われるし、逆に実績を積むことができればよりサラリーの高い組織に転職することも可能だ。だからこそ、アメリカではトレーニングに参加する者の知識を習得しようとする意気込みや真剣さが半端じゃない。分からないことは決してそのままにして帰らない。日本人がセミナーに参加する態度とは雲泥の差だ。

自分は日本でやられているほとんどのセミナーは受講者が話を聞くだけの一方的なものが多く、できるようになるまで徹底的にやる「トレーニング」ではないと思っている。トレーニングはできるようになるまでやるからこのように高いのだ。トレーニングする側の能力が低ければ客足はすぐに途絶える。それなり価値と知識やスキルを身につけさせられるという自信がなければ、これだけの金額にはできないだろう。

一方で外資系でも無料のセミナーはある。こういう場合は、その裏側にものすごく高いコンサルテーションやツールの購入を勧めるセールスが含まれていると考えた方がよい。ものすごく高いというのは、例えば1日コンサルテーションしてもらうと30万円とか、ライセンス一本あたり100万円のツールのことだ。このような費用が日本の会社の中で認められるかどうかは、組織上位層の人たちが安全や信頼を実現するための規格適合費用としてそれ相当の金（数百万円から数千万円）を支払う決心をしたときだけだ。日本のエンジニアがタダで安全や信頼を実現できている状況では認められるわけがない。

さて、欧米に比べて日本では役職の違いがありながら、特に技術分野ではフラットに近い組織構造になっており、また、マネージャーがマネージメントだけでなくエンジニアリングもやっていたりする。だから、プロジェクト内のマネージャやマネージャに指名されたベテラン技術者一人が上記のようなトレーニングを受けて、プロジェクトメンバーに「これに従え」と指示を出してもうまくいかないと思う。日本のエンジニアは「なぜ」「なんのために」について納得しないと動かない。逆に根拠も理解せずに今までのやり方を変えてしまうようなら非常に危ない。

日本の技術者はこのような縛りがなくても高い品質のハードウェア、ソフトウェアをアウトプットできる非常に珍しい人種だと感じる。たいしてトレーニングに費用をかけなくても高品質の製品を作ることができる。だからこそ、経営者はトレーニングに上記のようなお金がかかることについてなかなか理解を示さないと思う。

実際、日本では ISO 26262 の要求を社内ルールに取り込んでガイドラインを作り、そのガイドライン通りにものづくりをさせることで、形式的に規格要求を満たしたように見せるという作戦をとるだろうと予測する。いい悪いは別にして、説明責任を果たすためには、まずはそうするしかないのだ。欧米のように、一部の精鋭に資格を取らせて、そのリーダーの権限でヒエラルキーの組織構造の中で規格適合を推し進めるというやり方ではなく、関係者全員が一定の組織内ガイダンスにしたがうことで、降りかかってきた危機に対して全員でフラットに乗り切ろうとすると思う。

このやり方は下手をするとすぐに形骸化する。規格要求を理解せずにアウトプットドキュメントを形式的にそろえることが目的になりやすい。

このブログの特集では欧米流のやり方はうまくいかないということを見越した上で、マネージャもエンジニアもみんな同じ目線でエンドユーザーの安全を確保するために、自分たちが何をし、また、諸外国の人々に自分たちが作った成果物の安全性や信頼性をどのように主張したらよいのかを解説し、活動が形骸化せずに安全という最終目的を達成できることを目指している。

日本の製造業の会社でソフトウェアエンジニア出身の品質保証担当という人にはなかなかお目にかかることがない。電気や機械の出身であったり、純粋に品質畑で上に上がってきた人が多いように感じる。その人たちに、ISO 26262 のソフトウェア開発の要求部分を指導させるには、相当無理がある。だからといって、ソフトウェアQAのような部門、担当を急遽作って勉強させ、権限を与えるのもフラットな組織構造ではうまくいくような気がしない。ソフトウェアの規格適合の部分を外部に丸投げすると、さんざんかき回され、規格の認定を受けているというツールを買わされ、ぐちゃぐちゃになる危険性がある。ルール/責任が明確化されており、システム/ツールを使いこなすのが上手なところでうまくいった方法をそのままテーラリングもせずに日本で実践しようとしても失敗するだけだと思う。

そうならないためには、日本人がアウトプットする成果物の品質がなぜ高く、ルール/責任、システム/ツールを駆使している欧米製品の品質が日本の製品の品質に追いつけていないのはなぜかについて、自分たちの中に答えを持っている必要があると強く思う。その確信がないと、欧米流を受け入れても実質的な安全や信頼は向上しない。

この命題に対する答えのヒントとして言えることが一つあると思う。それは、上記のことはスタンドアロン製品には当てはまるかもしれないが、ネットワーク接続するような製品、複数の機能を組み合わせないと要求を実現できないような製品や機能ではたぶん成り立たないという点だ。

ようするに、特定のエンジニアが商品や商品群全体を見渡すことができ、商品のライフサイクル（開発開始から市場になくなるまで）全体に渡って関わる、責任を持つことができる場合は日本の商品の品質は高いが、他部門や他社のコンポーネントを組み合わせないと商品の重要な機能を動かすことができないようなケースでは、その限りではないということだ。

自動車で言えば、機能と性能が責務分割できていたこれまでは品質を高く維持できてきたが、今後、それらがクロスオーバーしないとユーザーの要求を満たせなくなってくると、それまでのやり方では予測できない不具合に悩まされることになるということだ。そのために、ISO 26262 を使う必要があり、これまでの日本のエンジニアの良さ、高品質を実現できる能力を低下させないようにしながら、ISO 26262 の要求のよいところを吸収していく必要があると思っている。

【ISO 26262-2:2011 Part 2: Management of functional safety】

さて、用語の定義の邦訳はもうしばらくまっていただくとして、今回は ISO 26262-2:2011 Part 2: Management of functional safety の解説に入っていきたいと思う。

以下が　Management of functional safety：機能安全のマネジメントのパートの目次で、「5 セーフティマネジメントの要求」「6 コンセプトフェーズと製品開発間のセーフティマネジメント」「7 製造のためのアイテムリリース後のセーフティマネジメント」が3つの大きな柱となっている。

ISO 26262-2:2011 Part 2: Management of functional safety は、セーフティマネジメント全体に対する要求であり、こういったところはエンジニアには苦手な分野で、品質保証担当や製品開発のプロセスをマネジメントするような人が得意なところだ。

ISO 26262-2 Part2 Management of functional safety		機能安全のマネジメント
	Contents	目次
	Foreword	序文
	Introduction	イントロダクション

1	Scope	スコープ
2	Normative references	基準となる参照
3	Terms, definitions and abbreviated terms	用語、定義、省略語
4	Requirements for compliance	規格適合要求
4.1	General requirements	一般要求
4.2	Interpretations of tables	表の解釈について
4.3	ASIL-dependent requirements and recommendations	ASILに依存する要求及び推奨
5	Overall safety management	セーフティマネジメントの全体像
5.1	Objective	目的
5.2	General	一般
5.3	Inputs to this clause	この箇条へのインプット
5.4	Requirements and recommendations	要求と推奨
5.5	Work products	作業成果物
6	Safety management during the concept phase and the product development	コンセプトフェーズと製品開発間のセーフティマネジメント
6.1	Objectives	目的
6.2	General	一般
6.3	Inputs to this clause	この箇条へのインプット
6.4	Requirements and recommendations	要求と推奨
6.5	Work products	作業成果物
7	Safety management after the item's release for production	製造のためのアイテムリリース後のセーフティマネジメント
7.1	Objective	目的
7.2	General	一般
7.3	Inputs to this clause	この箇条へのインプット
7.4	Requirements and recommendations	要求と推奨
7.5	Work products	作業成果物

Annex A	(informative) Overview of and workflow of functional safety management	（情報提供としての）機能安全マネジメントの概要とワークフロー
Annex B	(informative) Examples for evaluating a safety culture	（情報提供としての）安全文化の評価の例
Annex C	(informative) Aim of the confirmation measures	（情報提供としての）確証対策の目的
Annex D	(informative) Overview of the verification reviews	（情報提供としての）検証レビューの概観
Annex E	(informative) Example of a functional safety assessment agenda (for items that have an ASIL D safety goal)	（情報提供としての）機能安全アセスメントアジェンダの例（ASIL D のセーフティゴールを持つアイテム用）

この手のエンジニアが不得意なパートを理解するためにはコツがあって、まず、Annex や、各工程で作成すべき成果物が何かを見る。日本の技術者はプロセスのインプットが曖昧でもアウトプットのイメージが分かっているとものづくりができてしまう不思議な人種だ。そして、インプットとなる要求の説明をするよりも、アウトプットのイメージを見せてあげると非常に喜ぶ。

逆に言うと、アウトプットの型にはめ込もうとする傾向があるので注意が必要だ。答えは一つではないのに、アウトプットの例を見せるとその一点を目指そうとしてしまう。

下記は ISO 26262-2 Part 2: Management of functional safety の Annex A の機能安全マネジメントの全体像を表す表で、3つの箇条に対するインプットとアウトプットが何かが明確に書かれている。

セーフティライフサイクルに対する要求定義やルールと責任の定義、市場へのリリース後のモニタリングの義務などが定義されている。これらは、ISO 9001 の要求とも一致しているので、品質マネジメントシステムを持っている組織ならそれほど違和感はないと思うが、自動車の場合は製造業者とサプライヤの関係があるのでそう簡単ではないと思われる。

ルールとプロセスは自動車製造業者が作ことになるが、サプライヤに対してルールと安全ライフサイクルの中でサプライヤに委託するプロセスを提示し、セーフティケース等エビデンスの要求を行い、それらの活動が継続的に実施されていることをエビデンスを残さなければいけない。

これは各開発における成果物だけでなく、 ISO 9001 と同様に定期的な内部監査や外部監査を通じたオーディットの実施記録によって示すことになるだろう。

ブログの読者が機能安全マネジメント要求の内容を直感したいのなら、左側の作業成果物を文書化して用意する必要があると考えて見て欲しい。ルールとプロセスは組織承認される必要があり、安全に関わるコンポーネントに関係する製造業者の部門とサプライヤはそのルールとプロセスを知っている必要がある。知っているだけでなく、教育訓練をしてその履歴の残さなければダメだ。そういった履歴を確認することでしか、ルールやプロセスが徹底されていることを証明することはできない。

エビデンスは証拠だから、メモはダメ。きちんと責任と権限を持った者が承認されたものでなければいけない。このような取り組みがまどろっこしいと思っても、日本以外の人たちに安全や信頼を説明するためにはそうするしかないのだ。

**Table A.1 — Functional safety management: overview**
Clause 箇条	Objectives 目的	Prerequisites 事前必要条件	Work products 作業成果物
5 Overall safety management	The objective of Clause 5 is to define the requirements for the organizations that are responsible for the safety lifecycle, or that perform safety activities in the safety lifecycle. Clause 5 serves as a prerequisite to the activities in the ISO 26262 safety lifecycle.	None	5.5.1 Organization-specific rules and processes for functional safety. 5.5.2 Evidence of competence. 5.5.3 Evidence of quality management.
5 セーフティマネジメントの全体像	箇条5の目的はセーフティライフサイクルに責任を持つ、またはセーフティライフサイクルの中で安全活動を実施する組織に対する要求を定義することである。	なし	5.5.1 機能安全の組織承認されたルールとプロセス 5.5.2 適格性の証拠 5.5.3 品質マネジメントの証拠
6 Safety management during the concept phase and the product development	The first objective of Clause 6 is to define the safety management roles and responsibilities, regarding the concept phase and the development phases in the safety lifecycle. The second objective of Clause 6 is to define the requirements for the safety management during the concept phase and the development phases, including the planning and coordination of the safety activities, the progression of the safety lifecycle, the creation of the safety case, and the execution of the confirmation measures.	Organization-specific rules and processes for functional safety (see 5.5.1) Evidence of competence (see 5.5.2) Evidence of quality management (see 5.5.3)	6.5.1 Safety plan. 6.5.2 Project plan (refined). 6.5.3 Safety case. 6.5.4 Functional safety assessment plan. 6.5.5 Confirmation measure reports.
6 コンセプトフェーズ及び製品開発中のセーフティマネジメント	箇条6の目的はコンセプトフェーズ、セーフティライフサイクルの開発フェーズに関してセーフティマネジメンのトルールと責任を定義することである。	機能安全の組織認証されたルールとプロセス(5.5.1) 適格性の証拠（5.5.2) 品質マネジメントの証拠(5.5.3)	6.5.1 セーフティプラン 6.5.2 プロジェクト計画（見直し後の） 6.5.3 セーフティケース 6.5.4 機能安全アセスメント計画 6.5.5 確認手段レポート
7 Safety management after the item's release for production	The objective of Clause 7 is to define the responsibilities of the organizations and persons responsible for functional safety after the item's release for production. This relates to the general activities for ensuring the required functional safety of the item during the lifecycle subphases after the release for production.	Evidence of quality management (see 5.5.3).	7.5 Evidence of field monitoring.
7 生産のためのアイテムリリース後の安全管理	箇条7の目的は生産のためのアイテムリリース後の機能安全の組織と人員の責任を定義することである。これは製品のリリース後のライフサイクルサブフェーズ中のアイテムの機能安全要求を確実にする一般活動に関係がある。	品質マネジメントの証拠（5.5.3)	7.5 市場モニタリングの証拠

次回は、さらに ISO 26262-2 Part 2: Management of functional safety を読み進んでいきたいと思う。

ISO 26262との向き合い方 (4) 用語の定義からのトピックス

2011-12-10T08:08:00.001+09:00

ISO 26262-1:2011 Part 1: Vocabulary を邦訳しようと思ったら用語が142もあって、さすがに一晩や二晩でできる分量ではないことが分かった。用語の定義の邦訳（全体）については正月明けを目標にリリースを目指したいと思っている。

ちなみにVocabularyは用語とか用語集と訳した方が正確かもしれないが、用語の内容を正確に理解することが規格解釈の重要なポイントであることを強調したいためこのブログサイトでは『用語の定義』とした。

用語の定義の翻訳作業をしていてつくづく思ったのが、英語を日本語にすると原文のニュアンスが伝わりにくくなるということだ。例えば、safety architecture を安全構造とか安全方式と訳してしまうと、ソフトウェアには関係ないような印象を与えてしまう。safety validation も安全妥当性確認としてしまうのはイマイチだと感じる。よって今回は、それらカタカナで示すことでニュアンスが伝わりそうな用語はそのまま、セーフティアーキテクチャやセーフティバリデーションと書くようにした。ただし、safety measure （セーフティメジャー）のようなカタカナにすると意味が認識しにくくなる言葉は、「安全対策」と日本語にするようにした。（セーフティ対策は語呂がよくないので安全対策とした）英語のままにしておくか、日本語にするかはこの規格を適用するエンジニアにとってどちらの方が規格要求を正しく理解できるかと考えながら振り分けた。

さて、ISO 26262 の142の用語を眺めてみると、次の3つのグループに分かれることが分かる。

安全工学、品質工学、規格適合に関係することば
ソフトウェア品質工学に関係することば
自動車ドメイン特有のことばまたはISO 26262 特有のことば

例えば、1の安全工学、品質工学、規格適合のことばとしては、assessment:アセスメント、audit:オーディット、harm:危害、hazard:ハザード、failure:故障、failure mode:故障モード、fault:欠陥、residual risk:残留リスク　safety case：セーフティケース、safety measure:安全対策などが、

2 のソフトウェア品質工学に関係することばとしては、statement coverage：ステートメントカバレッジ、branch coverage:分岐カバレッジ、verification:検証、walk-through:ウォークスルー、random hardware failure:ランダムハードウェア故障、systematic failure:決定論的故障、software unit：ソフトウェアユニット、software component：ソフトウェアコンポーネントなどが、

3 の自動車ドメイン特有のことばまたはISO 26262 特有のことばとしては、Automotive Safety Integrity Level:ASIL, ASIL decomposition:ASILデコンボジション、special-purpose vehicle：特別目的車両、single-point failure:シングルポイント故障、dual-point failure:デュアルポイント故障

などがある。この規格には3つの分野のことばが多く使われていることから ISO 26262 全体を理解するには3つの分野を総合的に理解していないとダメだということが推察される。このことは今後の ISO 26262 を適合する現場のエンジニアにとって悩ましい問題になると考えている。

それはどういうことかというと、1. 安全工学、品質工学、規格適合に関する知識は規格適合会社が得意とすることだが、彼らはソフトウェア品質工学や自動車ドメイン特有の知識にはうとい。2. ソフトウェア工学に関する知識は、ソフトウェア系品質コンサルタントが得意な分野であるが、彼らは安全工学、規格適合、自動車特有のドメインの知識、経験があまりない。また、今回 ISO 26262 のために新しく導入された概念、ASILや ASILデコンポジションなどの概念は、ISO 26262 の規格制定に関わった人たちが詳しい。

そこを踏まえたうえで、自動車ドメインの技術者は、自動車ドメインに特化した部分、ISO 26262で初めて導入された概念は自分たちで理解を進めるとして、安全工学、品質工学、規格適合、ソフトウェア品質工学に関する知識に関しては、外部から指導を受ける必要性はあると感じる。このとき、お勧めしたいのは、急に ISO 26262 の適合を看板に掲げたところよりも、それぞれの分野の知識や方法論を昔から、ひたむきに、純粋に教えているところに教えを請うということだ。例えば、安全工学、ソフトウェア品質工学なら日科技連などがお勧めだ。例えば、FMEAやFTAを含む品質管理セミナー、ソフトウェア品質マネジメントセミナーは何十年も前から開催している。

このブログを利用するのも一つの手だが、エンジニアや品質保証担当はこれからたくさん勉強しないといけないということは間違いない。自らの勉強する努力なしに、今後複雑化する安全機能をユーザーに安心して使ってもらうことはできない。現場のたたき上げでここまでやってきたという自負があってもダメだ。その自負だけでは未来の自動車システムの実質的な安全性を確保できないし、諸外国に安全性を証明することができない。

諸外国への安全性の証明という観点から考えると、ISO 26262 を日本語だけで理解してしまうのは危険であると感じる。英語の規格を日本語に訳して、安全性の説明を日本語でして英語の翻訳して外国人に伝えると、二回変換があるので真意が正しく伝わらないかもしれない。よって、自分の仕事に関係する規格原文の箇所は必ず読んでおく必要がある。

【ランダム故障と決定論的故障の違い】

用語の定義は今後、少しずつ紹介していくとして、今回は random hardware failure:ランダムハードウェア故障と systematic failure:決定論的故障について説明しようと思う。

1.92
random hardware failure

failure (1.39) that can occur unpredictably during the lifetime of a hardware element (1.32) and that follows a　probability distribution
NOTE Random hardware failure rates (1.41) can be predicted with reasonable accuracy.

※(1.39)といった記述はその言葉の定義が ISO 26262-1:2011 Part 1: Vocabulary の別の項にあるということ。

ランダムハードウェア故障
邦訳：確率分布に従ったハードウェアエレメントのライフタイム中に予知できずに発生する故障
NOTE：ランダムハードウェア故障率は妥当な正確性で予測することができる。

ランダムハードウェア故障は、後述する決定論的故障の対照的な位置づけにある。ようするにある一定の故障率、歩留まりを持ったハードウェア部品の故障のことで、例えば1万個に3個の確率で故障するとか、10万時間使い続けると故障するといったもの。確率論的に故障を予測できるため、対策も立てやすい。

1.130
systematic failure

failure (1.39), related in a deterministic way to a certain cause, that can only be eliminated by a change of the　design or of the manufacturing process, operational procedures, documentation or other relevant factors

決定論的故障
邦訳：設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障

1.131
systematic fault

fault (1.42) whose failure (1.39) is manifested in a deterministic way that can only be prevented by applying process or design measures

決定論的欠陥
邦訳：プロセスまたは設計対策によってのみ取り除くことができる決定論的に現れる故障の原因となる欠陥

※failure と fault は用語の定義の中で何回もでてくる。 fault：欠陥が原因となって failure:故障が発生すると考えるとよいだろう。

さて、systematic failure/fault をシステマテック故障/欠陥とせずに、あえて決定論的故障/欠陥とした理由は、どっちにしてもその言葉だけではわかりにくい概念であるため、よりわかりにくい日本語の方にして、「この言葉はなんだろう」という疑問を常に持って欲しいと思ったからである。

「設計、開発プロセス、運用手順、ドキュメント、その他の関連する要因の変更{改善}によってのみ取り除くことができる決定論的な故障」という説明でsystematic failure:決定論的故障を理解できる者は何人いるだろうか。

簡単にいってしまえばソフトウェアのバグが systematic fault で、ソフトウェアのバグ、欠陥によって起こる故障、不具合が systematic failure である。(ハードウェアによる決定論的故障もまったくないとはいえないので、ソフトウェアによる決定論的故障は systematic software fault と言うこともある）

ソフトウェアのバグによって起こる不具合を考えてみれば分かるが、ランダムハードウェア故障のようにある一定の確率で起こるようなものではない。例えばめったに通らないプログラムのある箇所を通ったときにのみ発生する不具合だったとする。そして、それが普段あまり行わない複雑なオペレーションの組み合わせによって発生する不具合だったとする。

これはまれにしか行わないオペレーションなのだから、確率で表すことができるだろうか。人間工学的にはできるかもしれない。しかし、安全保障という観点から考えてみて欲しい。ランダムハードウェア故障はある一定の確率で起きるが、今起きるかどうかと言えばほとんどの場合起きない。ユーザーも「めったに起きないがある確率で発生する故障」という状態に理解を示してくれる。

ところが、めったに通らないパスに存在するバグが原因の不具合はどんなに複雑なオペレーションであっても、そのオペレーションを実施すると確実に発生する。だからこそ、systematic：決定論的ということばが使われる。しかし、この不具合は修正したソフトウェアと入れ替えると直ってしまう。被害の大きさにもよるが、直せば直る不具合を放置することをユーザーは許してくれない。

これが、systematic failure/fault：決定論的故障/欠陥の正体だ。ソフトウェア品質工学の世界では長年、決定論的故障/欠陥はレビューやテスト、検証、妥当性確認を含む設計プロセスや設計対策によってのみ防止できると言われ続けてきた。日本人がアウトプットする商品の品質が高い理由はプロセスや設計対策だけが要因ではないという主張はソフトウェア品質論の世界では証明できていない。（詳しくは　『ソフトウェア品質論の歴史的推移』を参照のこと）

さて、ソフトウェアの不具合に起因する危険からユーザーを守ることは、エンジニアや品質保証担当と決定論的故障/欠陥との戦いであると言える。

しかし、ソフトウェアエンジニアは数百万行もあるソースコードのすべてのパスをテストするような完璧なテストを実施することは不可能だし、不具合をたたき出すテストだけで、何も問題はないという安心を得ることなどできるないことはよく分かっている。ソフトウェアは簡単に変更することができるし、たった一行、たった一ビット変えたことでシステムの動作が変わることだってあるし、コンパイラやMAT LAB などのモデルベース設計ツールによりはき出すされたコードに変換ミスがまったくないなどと言える訳がないことは分かっている。

だからといって、ISO 26262 の適用の全体工数、全体費用に対して、ツールやコンパイラの検証に30%以上の工数や費用を割くのはナンセンスだと思う。（あくまでも個人的な見解）

ユーザーの安全確保を第一に考えれば、まずやるべきことはシステムを安全に関わる大事な部分とそうでない部分に分けて印を付けることだ。それが ASIL であり、コンポーネントも分解すれば危ない部分とそれほどでもない部分にわけることができるかもしれない、それが ASILデコンボジションだ。

システムの中の大事な部分、安全を担っている部分をできるだけを機能ごとに凝集し、他のコンポーネントとの結合を疎にして、その大事なコンポーネントに関わる設計や検証に工数や費用を投入するのがよい。そのためにはシステム全体の安全に対する分析を最初に進める必要がある。ISO 26262 の Part で言えば、2, 3, 4, 9 にあたる。

ただし、ハイブリッド車のブレーキシステムのように、多様な安全要求が求められる市場環境を見れば安全機能を一つのコンポーネントだけに集約できないことも予想される。

そのときに重要なのが安全を実現しているアーキテクチャを可視化し、それがシステムの中で有効に働いていて、かつ、決定論的欠陥が含まれていない、またはリスクが受容できていることを明確にすることが大事なのだ。

※用語の定義の邦訳にあたり、ISO 26262 の全体像を説明する図も一部ことばを見直して Ver 1.01 としたので利用して欲しい。(ISO 26262 全体構造図　開くためのパスワードは"guild26262"）

ISO 26262 に関するアンケート結果（投票総数 47, 複数選択可)

44 (93%) もっとこの規格に関する記事を書いて欲しい。
8 (17%) どこから手を付ければよいか分からない。
5 (10%) 技術者がやるべきことが分かりません。
5 (10%) お金や工数がどれくらいかかるか知りたい。
1 ( 2%)　売り込みが多くて困っています。 1 ( 2%) 特に興味ありません。
0 ( 0%) この話題はもういい。

投票ありがとうございました。この結果を記事を書き続けるモチベーションにしたいと思います。

ISO 26262との向き合い方 (3) 規格認証とスコープについて

2011-12-05T21:39:00.001+09:00

ISO 26262 に関する記事をもっと書いて欲しいという意見が多いので、しばらくこのテーマを続けていこうと思う。（引き続き 12/9 まで右上から二番目の投票はお願いします。一番上は本テーマの記事一覧です。）

今後の構想としては、1. 一般的な話題 2. 規格の内容と考察という記事構成で進めようかと思っている。

では

【規格認証について】

ISO 26262 に関して規格適合の認証や“コンサルテーションをやります”という会社が続々と出現している。老舗もあれば、新規参入の会社もある。

製品の安全に対して責任を負うメーカーや、開発の委託を受けるサプライヤによく考えて欲しいことがある。それは規格適合を認証したり、コンサルテーションした会社は、規格適合認定後に発生した安全に関する事故に対してなんら保証はしないということだ。

規格適合を認証した認証機関は、その製品や組織の安全性や信頼性を保証するわけではない。特にプロセス規格、ソフトウェアに関する規格に関して、なんらかの保証を与えることはできない。

一方、電気的安全性に関する規格適合に関しては、それを試験した試験所は試験内容について責任を負っている。試験の判定基準（Criteria）が明確だから、試験結果に対して責任を持つことができる。公正で正しい試験をしていることを証明できる。試験所は ISO/IEC 17025 試験所及び校正機関の能力に関する一般要求事項　の認定を取っているから、いい加減な試験レポートを出していると、試験所としての ISO/IEC 17025 の認定を取り消されてしまうのだ。

ところが、プロセス規格、ソフトウェア規格に関しては白黒が明確に判断できない要求事項だらけなので、規格認証自体の公正性、厳格性を評価することは難しい。CMMIのすごいところはなんだかんだいってそれをやりきったところだが、最近は CMMI のレベルに関する話題をあまり聞かない。ISO 26262 に関しては規格適合の成熟度のような指標はまだない。そうなると「強く推奨する」などという要求に対して適合の公正性や厳格性を問うこと自体意味がない。

よって、プロセス規格、ソフトウェア規格の適合にはかなりの範囲があると言える。はっきり言うと厳しめにも甘めにもできる。正当性を主張することが可能なのだ。ところが、こと外部規格に関しては日本人の技術者は免疫がない（ディベートのような議論のトレーニング経験がない）ため、ノーガードできついパンチを打たれる者が多い。ハタから見ていると打たれるのが好きなのではないかと思うくらい、言われるがままのように見える。

そうではなくて、日本の技術者は自分達の強みややってきたことを自信を持って主張して欲しい。ただ、そのとき相手が要求していることの意味を理解した上で主張して欲しいのだ。

規格認証機関に厳しく審査され、やっと適合を受けたとしても、適合を受けた組織、システム、コンポーネントの安全性が保証された訳ではない。何かあったときの責任を取るのは自分達なのだ。だったら、納得のしてから要求を呑むのが筋というものだ。

USのFDAや日本の厚生労働省などは医薬品、医療機器に関して規制当局としての責任を負う。USではFDAは消費者団体から認定が甘いという批判を受けて、認定を厳しくしたし、日本では注射器を使い回しを禁じていなかったことが原因で広がったB型肝炎、C型肝炎に関する訴訟が起こされ国が責任を問われている。

自動車の場合どうだろうか。規格適合を認定した機関やコンサルタントは規格認定をしたのに事故が発生したらその損害賠償責任を一部負ってくれるのだろうか。安全性を保証してくれる訳ではないし、損害賠償責任を問われることもない。よって ISO 26262 への適合は“安全保証のお墨付き”ではない。

安全に対する責任を負うということは、すなわち人の命に関わる責任を負うということだ。これはメディカルのドメインだけの話だけではない。自動車だって安全に関する機能や性能が期待どおりに動かなかったら、死に至るリスクがある。ブレーキが期待どおりに働かなかったら人が死ぬ危険がある。制動という機能や性能が、自動車の中で走行という機能や性能から完全に独立しているのであれば、制動に対する責務はブレーキのサプライヤに凝集できる。（ブレーキとアクセルの両方を同時に踏まれたときはブレーキを優先するという制御は必要だが）

その場合は、ブレーキを供給するサプライヤのみが安全に対する責務を全うすればよい。そうだからこそ、ブレーキという機能や性能の価値は高まり、ブレーキ安全に対する対価も上がり、安全なブレーキシステムを供給するサプライヤの評価も上がる。

しかし、ハイブリッド車はどうだろうか。制動という機能や性能はブレーキだけに凝集しているだろうか。現状ではドライバーがブレーキを踏んだときに回生エネルギーを回収するため、内部では複雑な機能連携を行っている。そうなったら、制動に関する責務はブレーキを製造するサプライヤだけに集約できない。だからこそ、ISO 26262 のような組織全体、プロジェクト全体に渡る安全管理を継続的に実施する必要があり、安全に関する責務、責任は一つのサプライヤに集約しにくくなってきている。だから、この機能に関しては○○サプライヤに任せておけばよいというアプローチでは安全が確保できない。（安全機能をコンポーネントに集約して、責務を閉じ込めるというアーキテクチャ設計のアプローチは可能で、その状態を可視化することは有効だ）

規格認定機関やコンサルタントは、ユーザーのリスクに対する責任は負わない。ユーザーに対する責任はメーカーが負う。ISO 26262に適合したシステムやコンポーネントを採用したメーカーは、ISO 26262 の認証があるかどうかよりも、認証に使ったドキュメント、エビデンスを評価することになる。規格に適合することのメリットは、共通の規範要求に対するアウトプットを安全管理者がレビューしやすいということにある。そして、絡み合ったコンポーネントで安全機能を実現する場合、その安全を管理する安全管理者はユーザーに対して責任を負う者でなければいけない。（自動車メーカーが担うことになるはず）

ISO 26262 の中では、2. Management of functional safety （機能安全のマネジメント）のパートの中で、開発からリリース後までの安全管理のマネジメント要求が書かれている。この部分を立案するのは、ユーザーに対して安全の責任を負う者でなければおかしい。ようするに自動車メーカーのことだ。制動の例で示したように制動のような自動車の安全に関する責務がコンポーネントに集約しきれない（コンポーネント同士の協調によって安全に関する機能や性能が実現するという意味）のなら、ISO 26262 の Part 2 を自動車メーカーがサプライヤに丸投げすることはできない。

よって、ISO 26262 によって自動車の安全に対する責務を全うするのならば、自動車メーカーは、まず、2. Management of functional safety （機能安全のマネジメント）の指針をサプライヤを含むプロジェクト関係者全体に示す必要がある。もしも、あなたがサプライヤの技術者で、自動車メーカーから 2. Management of functional safety （機能安全のマネジメント）の指針を示されていないのならば、この状況下で右往左往するのではなく、まずは規格要求について理解を深めることをお勧めする。

安全管理者からの指針が末端にまで行き渡っていないという状況は、規格の基本的な理念にこの段階で沿っていないことを示している。

もしも、何から手を付けたらよいのは分からない技術者が、何かしなければいけないと思っているのであれば、自分が作っている、これから作ろうとしているハード、ソフトが自動車の安全という側面から見たときにどのようなリスクを持つのかハザード解析をしてみるとよい。（ 3.7 Hazard analysis and risk assessment )

もしも、自分が関わっている ECU もしくはソフトウェアコンポーネントの、エンドユーザーに対するリスクが分からない場合は、要求された仕様どおりのものを作るしかない。この物づくりの仕方は日本的ではないと常々思っている。インプットに対して正確なアウトプットを出力し、インプットとアウトプットの整合を検証（Verify）するところで留める。そして、この作業者は安全に対して責任を負わない。安全に対する責任を負っているのは、どのようなリスクが存在するのかを知った上で、このコンポーネントの仕様を書いた者、若しくは組織内の品質保証担当である。

自分は、日本人が作る製品の品質の高さはこんなことで実現しているとは思わない。こうではなく、末端の作業者一人一人がエンドユーザーのリスクを意識しながら Awareness: Worrying about Quality 品質を心配する意識を高く持つ物づくりをしているから、安全を確保できているのだと思う。ただ、一人の技術者が全体を把握できないほどシステムが複雑化しているのも事実であり、Awareness: Worrying about Quality 品質を心配する意識だけではこれまでのように安全を確保し続けることはできないことは分かっている。

だからといって、日本人の技術者は自分達の強みを簡単に捨て去るべきではないと思う。だからこそ、日本の技術者は日本人の良さを活かすためにも、自分が作っているものに対するエンドユーザーのリスクについてハザード分析をするべきだと考える。簡単に言えば、エンドユーザーの気持ちになって、どんなリスクがあるのか、どんな障害があり得るのか、事故が起こったらどのような被害を被るのかをリストアップして、重み付けし、それに対する対策を掲げてみるとよい。

まずは、自分達がアウトプットする成果物が自動車の安全の一端を担っているのかどうか、より分けていくことから始めても良い。

繰り返すが、ISO 26262 への適合を目指すのは、適合していることを誰かに自慢するためではない。自分達がアウトプットする製品の安全性を実質的に高め、安全性が高いことを客観的な証拠によって内外に示すためだ。そして安全が確保されたかどうかを示すには、ユーザーリスクが受容できるレベルまで低減できていることを示す必要がある。リスク分析、ハザード解析なしに、設計上の対策だけで安全性の高さを示すことなどできる訳がない。

【ISO 26262:2010 Scope】

ISO 26262-1:2011 の1～9の各パートには Introduction に続いて、Scope で規格の適用範囲についての説明が書かれている。Scope の大部分は各パートでほとんど同じことが書いてあり、最後の数行で各パートに関する説明がある。

ISO 26262-1:2011 Road vehicles -- Functional safety --

ISO 26262-1:2011 Part 1: Vocabulary
ISO 26262-2:2011 Part 2: Management of functional safety
ISO 26262-3:2011 Part 3: Concept phase
ISO 26262-4:2011 Part 4: Product development at the system level
ISO 26262-5:2011 Part 5: Product development at the hardware
ISO 26262-6:2011 Part 6: Product development at the software
ISO 26262-7:2011 Part 7: Production and operation
ISO 26262-8:2011 Part 8: Supporting processes
ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

今回は Scope の共通部分を順に追っていこうと思う。→は規格内容に関するコメント。

Scope （範囲）

ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg.
ISO 26262は車両総重量最大3500kgまでのシリーズで生産される乗用車に実装される一つ以上の電気・電子システムに含まれる安全関連システムに適用することを目的としている。

→トラックやバスは ISO 26262 の範囲外だということ。乗用車以外でも共通のリスクはあると思うのだが、この規格では扱わないらしい。不思議だ。

ISO 26262 does not address unique E/E systems in special purpose vehicles such as vehicles designed for drivers with disabilities.
ISO 26262は、ハンディキャップを持ったドライバーのために設計された自動車のように特殊な目的の車両に搭載される独自の電気・電子システムを扱わない。

Systems and their components released for production, or systems and their components already under development prior to the publication date of ISO 26262, are exempted from the scope.
ISO 26262 の発行以前から開発中のシステムやコンポーネントや、規格発行前に{自動車}製造のためにリリースされていたシステムやコンポーネントは本規格のスコープから外されている。

→すでに開発が終わっているシステムやコンポーネントは対象外ということ。ということは枯れたコンポーネントを使い続けていれば対象外ということか。本当にそれでいいのか。また、規格発行前と後で ECU やソフトウェアの構成を分けて管理できるのだろうか？規格発行前に作ったコンポーネントに対してどんなに関連が強くても、対象外にしてしまっていいのだろうか。疑問は尽きない。

For further development or alterations based on systems and their components released for production prior to the publication of ISO 26262, only the modifications will be developed in accordance with ISO 26262.
ISO 26262 の発行前に生産のためにリリースされたシステムやコンポーネントをベースにした追加の開発や改変においては、変更点のみがISO 26262にしたがって開発される。

→本当にそんなことできるのかなあ・・・

ISO 26262 addresses possible hazards caused by malfunctioning behaviour of E/E safety-related systems, including interaction of these systems.
ISO 26262 は電気・電子安全関連システム、これらのシステムの相互作用を含む故障によって引き起こされる可能性のある障害を扱う。

→この部分が重要。システムの相互作用に関連する不具合を未然に防止するためにこの規格がある。

It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards, unless directly caused by malfunctioning behaviour of E/E safety-related systems.
電気・電子関連システムの故障によって直接引き起こされない場合、電気ショック、火災、煙、熱、放射線、毒性、燃焼製、反応性、腐食、エネルギーの放出等のハザードは扱わない。

→二次的な障害は扱わない。電気、電子システムに関する複雑性を伴う一次故障を扱う。

ISO 26262 does not address the nominal performance of E/E systems, even if dedicated functional performance standards exist for these systems (e.g. active and passive safety systems, brake systems, Adaptive Cruise Control).
ISO 26262はたとえ、これらのシステムのために存在する機能的性能の標準（例えばアクティブ、もしくはパッシブセーフティシステム、ブレーキシステム、適用型クルーズコントロールなど）に専念していても、電気・電子システムの名目上の性能を扱わない。　　

→the nominal performance of E/E systems とは、たとえセーフティシステムであっても、カタログでユーザーに性能をアピールするような部分に関しては範囲外ということではないかと思う。あくまでも安全に関する基本機能に関する部分だけを見るということか。

この後、各パートに関する説明が数行書かれる。この続きはまた後日。

ISO 26262との向き合い方 (2) イントロダクションを読む

2011-12-04T19:20:00.001+09:00

自分は組織内で次の(2)の立ち位置にいる。

(1) 規格適合を求める外部機関→(2) 組織内の規格適合推進者→(3) 現場のソフトウェアエンジニア

(1) と (3) の間にあって、現場には時には厳しく、時にはエンジニアと一緒になって作業をしたり、目的に導くための教育や指導をしている。

ドメインは違うものの自動車ドメインでも (2) の立場の者の活躍なしに規格適合を現場にプラスになる形でやりきることは困難だと予測する。

(3) が日程に追われ、やらなければいけないことが山積みになっていることはよく分かっているつもりだ。だから、(3) の成熟度や安全への本気度に応じて対応を変えている。ただし、ユーザーの安全が脅かされるような危険性があると感じたときは容赦はしない。

日本のエンジニアはこれまでは安全で信頼性の高い製品をアウトプットできてきた。そのベースには Awareness: Worrying about Quality 品質を心配する意識の大きさがある。詳しくは『USとJapanの文化の違いと商品品質との関係』の記事を読んで欲しい。トヨタ自動車とアメリカのGMの両方を経験された吉村達彦氏が感じたのは、日本人技術者は Awareness: Worrying about Quality が大きく、USではそれが小さいということだ。そして、USでは、ルールや責任を重んじ、システムやツールをうまく利用する。日本人は、ルールや責任に重きを置かず、システムやツールの利用もうまくない。しかし、人一倍 Awareness: Worrying about Quality : 品質を心配する意識が強い。プロジェクトメンバの一人一人の品質を心配する意識が、総力となって日本の高品質の製品をアウトプットしてきた。

ISO 26262 は、ルールや責任に重きを置き、システムやツールの利用がうまいが、品質を心配する意識が小さい人たちのための規格であるという印象が強い。熟練した職人を意識した規格ではない。

だから、ツールや責任に重きを置かず、システムやツールの利用がうまくない、日本人技術者は「これまではできてきたのに」「これで本当に安全を確保できるのか」という感覚を持つと思う。 Awareness: Worrying about Quality : 品質を心配する意識がこれまでに高品質を実現してきたのに、それを否定されているかのようにも感じるだろう。だからこの規格は日本では形骸化しやすい。

ではどうすればいいのか。まず、最初にやるべきことは規格が要求している安全の実現という目標に対して価値観を一致させる、すなわち方法論はとりあえず横に置いておいて、規格のコンセプトと対峙し、規格と自分たちが共通の目的の実現を目指しているという認識を持つことだ。

そのためには、規格の前文をよく読む必要がある。規格の前文にはその規格が目指していることが書かれている。それを繰り返し読むことから始めるのがよい。

それでは規格原文のイントロダクションを少しずつ読み進んでいこう。邦訳の間違いについてはコメントで指摘して欲しい。

→は自分の解釈やコメントを示す。

Introduction
イントロダクション

ISO 26262 is the adaptation of IEC 61508 to comply with needs specific to the application sector of electrical and/or electronic (E/E) systems within road vehicles.
ISO 26262は路上を走行する自動車の電気的な、または電子システムの領域のニーズに従うIEC 61508への適合である。

→E/E のような用語の定義は ISO 26262-1:2011 Part 1: Vocabulary に書かれているので Part 1: Vocabulary は手元に置いておく必要がある。ことばの定義はキチンと書かれているので正確に把握しておく。例えば「E/E system は system (1.129) that consists of electrical and/or electronic elements (1.32), including programmable electronic elements. E/Eシステムとは電気的またはプログラマブルな電子構成要素を含む電子構成要素からなる。EXAMPLE Power supply; sensor or other input device; communication path; actuator or other output device.」と説明されている。(1.129)や (1.32)は用語の説明が別にあるということ。これらすべての意味を理解しておく。

→この一文はようするに ISO 26262 は自動車向けの IEC 61508 機能安全規格であるということ。（余談だが、医療ドメインのソフトウェアライフサイクルプロセスの規格 IEC 62304 が IEC 61508 の派生規格であると言ったり、書いたりする人がたくさんいて、見つけるたびに間違いを指摘している。嘘だと思うなら IEC 62304:2006 の本文で functional safety というフレーズを検索してみるとよい。まったく出てこない）

This adaptation applies to all activities during the safety lifecycle of safety-related systems comprised of electrical, electronic and software components.
この適合は電気的、電子・ソフトウェアからなる安全関連システムの安全ライフサイクルの間のすべての活動に適用される。

→自動車における安全に関係するシステムの開発から廃棄まで全期間においてこの規格が適用されるということ。

Safety is one of the key issues of future automobile development.
安全は今後の自動車開発のキーとなる問題点の1つである。

→ここが大事。安全の確保のために必要なことをこの規格は要求している。それを実践することが安全の確保につながるという意識を持つことが大事だ。

New functionalities not only in areas such as driver assistance, propulsion, in vehicle dynamics control and active and passive safety systems increasingly touch the domain of system safety engineering.
{自動車の}新しい機能はドライバーの補助、推進力、車両力学制御、アクティブ、パッシブセーフティのような領域だけでなく、ますます、システム安全工学の領域に踏み込んできている。

→障害物を検知して自動的にブレーキがかかるようなシステムも実用化されている。（スバルのプリクラッシュブレーキのCMで最後に一瞬だけ注意事項の文言が表示されることにお気づきだろうか。このようなインテリジェンスを持った安全機能はメーカーは最大限ユーザーにその効果効能をアピールしたいが、その機能には限界や保証できないことがあるということをよく見て欲しい）エアーバッグシステムも同じだ。

Development and integration of these functionalities will strengthen the need for safe system development processes and the need to provide evidence that all reasonable system safety objectives are satisfied.
これらの機能の開発と統合は、安全システム開発プロセスの必要性と、すべての妥当なシステム安全目標が満足しているという証拠を提供する必要性を強くするだろう。

→安全性を内外に示すためにはその妥当性を証拠・証跡によって示すことが求められる。日本人には苦手な領域ではあるが、これはグローバルマーケットで商売をしている限りやらなければいけないことである。

With the trend of increasing technological complexity, software content and mechatronic implementation, there are increasing risks from systematic failures and random hardware failures.
増強する技術的な複雑さ、ソフトウェア内容、およびメカトロニクスの実装の傾向と共に、決定論的原因故障とランダムハードウェア故障から増加するリスクがある。

→今後 ISO 26262 が必要になる理由はここにある。自動車は安全を実現するための付加価値を次々にユーザーに提供するようになるのだが、これによりシステムはどんどん複雑になり、決定論的原因故障が増加するのは間違いない。この対策を取らなければ利用者の安全は脅かされてしまう。このことには現場のエンジニアも同意してくれるはずだ。『Random Failures と Systematic Failures の違い』を参照のこと。

ISO 26262 includes guidance to avoid these risks by providing appropriate requirements and processes.
ISO 26262は、適切な要求とプロセスを提供することによってこれらの危険を避けるためのガイダンスを含んでいる。

→ISO 26262 はそのリスクを規格要求とプロセスによって回避しようとしている。日本のエンジニアは本当にそれで安全が実現できるのかどうかを納得できるまで考える必要がある。

System safety is achieved through a number of safety measures, which are implemented in a variety of technologies (e.g. mechanical, hydraulic, pneumatic, electrical, electronic, programmable electronic) and applied at the various levels of the development process.
システム安全は多くの安全対策を通して達成される。安全対策は、さまざまな技術(例えば、メカニカルな、水中力学の、空気の作用による、電気の、プログラム可能な電子的な技術)で実装されて、開発プロセスの様々なレベルで適用される。

→自動車の安全は一つの領域では達成できないという主張は同意できる。ハードウェアだけでもソフトウェアだけでもダメで、安全を実現するためのリスクコントロールをすべての領域の総合力によって実施する。よってサプライヤ任せ、各担当任せで安全は確保できない。それぞれが安全に関する情報を共有し合って、納得し合って製品を作り上げなければいけない。

Although ISO 26262 is concerned with functional safety of E/E systems, it provides a framework within which safety-related systems based on other technologies can be considered.
ISO　26262は電気・電子システムの機能安全に関係があるが、それは他の技術に基づく安全関連システムも考慮できるフレームワークを提供する。

ISO 26262:
ISO 26262 は次を提供する

a)　provides an automotive safety lifecycle (management, development, production, operation, service, decommissioning) and supports tailoring the necessary activities during these lifecycle phases;
a) 自動車の安全性ライフサイクル(マネジメント、開発、生産、運用、サービス、廃棄)を前提として、これらのライフサイクル段階の間、必要な活動の実現をサポートする。

b)　provides an automotive-specific risk-based approach to determine integrity levels [Automotive Safety Integrity Levels (ASIL)];
b) 自動車安全インテグリティレベル(ASIL)を決定するため、自動車の固有のリスクベースアプローチを提供する。

→IEC 61508 では SIL という指標があるが、ISO 26262 では自動車用にカスタマイズしている。その内容については ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses に詳しい説明がある。

c)　uses ASILs to specify applicable requirements of ISO 26262 so as to avoid unreasonable residual risk;
c) 合理的でない残留リスクを避けるためにISO 26262の規定要件を指定するのにASILを使用する。

d)　provides requirements for validation and confirmation measures to ensure a sufficient and acceptable level of safety being achieved;
d) 達成される安全の十分で受容できるレベルを確実にするための妥当性確認と判断基準の要求を提供する。

e) provides requirements for relations with suppliers.
e) サプライヤとの関係に関する要求を提供する。

Functional safety is influenced by the development process (including such activities as requirements specification, design, implementation, integration, verification, validation and configuration), the production and service processes and by the management processes.
機能安全は開発プロセス(要求仕様書、設計、実装、統合、検証、妥当性確認、および構成管理のような活動を含んでいる)と、生産と保守プロセスとマネジメントプロセスに影響を受ける。

Safety issues are intertwined with common function-oriented and quality-oriented development activities and work products.
安全問題は一般的な機能指向と品質指向の開発活動と作業の成果物をからめていく。

→機能を実装するのは顕在的価値の実現、当たり前品質を含む品質を作り上げるのは潜在的価値の実現である。システムが複雑になればなるほど、これらは分けて考えられなくなってくる。将来カーナビゲーションの情報（今どこを走っているのかといった情報）が自動車の安全の実現に使われるかもしれない。ブレーキは安全にのみ使われ、カーナビ、オーディオのような機能とはアイソレート（隔絶）されているという時代は終わりつつある。その場合、安全を実現する要素の他の要素との結合度や安全機能自体の凝集度を内外に示せるようにしておく必要がある。今後起こりうる安全問題は機能面と品質面の両方をプロセスで作り上げた証拠によって説明しなければいけない。

ISO 26262 addresses the safety-related aspects of development activities and work products.
ISO 26262は開発活動と作業の成果物の安全に関連する面を扱う。

Figure 1 shows the overall structure of this edition of ISO 26262.
図1はISO 26262のこの版の全体的な構造を示している。

ISO 26262 is based upon a V-model as a reference process model for the different phases of product development.
ISO 26262は製品開発の異なったフェーズのためのから参照プロセスモデルとしてVモデルに基づいている。

Introduction の文章と Overview of ISO 26262 の図は ISO 26262-1:2011 のすべてのパートの先頭に挿入されている。

ISO 26262 の全体像を説明する図は非常に重要であり、常に手元において眺めておく必要がある。原文の図をトレースしなおしたものと邦訳したものをPDFにしたのでダウンロードして利用していただきたい。(ISO 26262 全体構造図　開くためのパスワードは"guild26262"）

12/9 まで引き続きアンケートをお願いします。（ブログの右上）

ISO 26262との向き合い方 (1) 最初に読んで欲しいこと

2011-12-01T17:30:00.000+09:00

まず、自分が ISO 26262 にこだわっている理由を書こうと思う。

自分は医療機器ドメインのソフトウェアエンジニアとしてのキャリアが24年である。そして、約20年前、自分がソフトウェアを担当した製品が、FDA（アメリカ食品医薬品局）の定期査察で査察の対象となり、Warning Letter を受け、約1年間アメリカ向けの出荷が停止された。

その当時、一人で製品のソフトウェアを作っており、システム全体を完全に把握できていたし、ソフトウェアの検証についても我流ではあったが自信があった。実際、その製品でソフトウェアの問題はほとんど起こらなかった。（唯一、たった1ビットの設定ミスでソフトウェアを改変したことがあったので完璧ではなかった）

1990年頃、すでに、FDA は医療機器や医療機器に搭載されているソフトウェアに対して V&V (Validation & Verification）を客観的な証拠によって示すことを要求していた。

自分は個人のファイルとして検証記録を持っていたが、それは組織的な品質マネジメントの一環として実施したものではなかった。すなわち、「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態だった。

それだけの問題ではなかったが、組織的にFDAが要求している品質システムが実施できていないという理由で Warning Letter が発行され、その後、是正できたことを示すための取り組みを苦労しながら実施し、確認の監査をパスした。

その当時、自分は「なぜ、それがダメなのか」「担当製品の検証の証拠があるのになぜ認めてくれないのか」まったく分からなかった。

その後、FDAが公開している要求を読み進むうちに、その理由が分かった。個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。

おそらくこの認識のギャップは、国民性にも大きく関係している。プロジェクトへの人の出入りが多い欧米の企業では、個人的なアクティビティで支えられている信頼や安全は非常に危ういものに写る。製品のライフサイクル全て、また、製品群のライフサイクルのほとんどに同じ技術者が関わるような日本の開発スタイル、品質保証の概念とは状況が異なる。

だからこそ、しっかりやっているはずだった自分の製品への Warning Letter は青天の霹靂だった。ただ、このことは自分の技術者人生の中で大きな分岐点となった。世界標準のやり方でないと通じないことがあることに気がついた。この頃から品質マネジメントシステムとは何か、日本人が品質を作り出すやり方とは何が違うのかについて考え続けている。

この出来事ををきっかけにして、アメリカや国際標準が求める品質マネジメントシステムやソフトウェアの安全設計、品質管理について約20年間取り組んでいる。

自分は品質保証部門出身ではない。いくつかの製品開発の実績を経て、技術者から支援者になった。製品担当、エンジニアの視点と品質保証や規格適合を求める側の視点も持っている。

だから、自動車ドメインで ISO 26262 の適用に関して、現場のソフトウェアエンジニアがこれから苦しむことがどんなことか分かる。実際に医療機器のドメインで20年前に経験済みだから、自動車系のエンジニアがこれからどのようにして階段を上っていかなければいけないのかが見える。

ここ数年で多くの自動車系技術者が青天の霹靂を実感することが分かっている。そして、そのショックが「した方が良い」と書かれていることを「しなければならない」と判断させてしまうことも分かっている。ISO 9001:1997 や CMMI の取得を目指したときのことを思い出して欲しい。規格要求を神のお告げのようにふれ回る者が必ず出てくる。

ISO 26262 は誰のために、何のために作られたのか。それは、自動車を利用するものの安全のためだ。これからの技術者の努力が、いかに大変であろうと自動車の安全に貢献するものであればよい。しかし、自動車メーカーやサプライヤのエンジニアが外乱光で利用者の安全という目標を見失ってしまうのは忍びない。

幸い、医療機器ドメインは市場もそれほど大きくなかったせいか、これまで、そういった外乱光はなかった。アメリカ人は我が道を行くが、基本的にフェアーな精神を持つ。よって、FDAの査察は非常に厳しいがそれで儲けようという考えはない。あくまでもアメリカ国民の安全を確保するために厳しくチェックをする。

そのコンセプトに自分は共感を持っている。あくまでも目的は利用者の安全であり、そのためにやるべきことを要求する。要求とは異なる手段であっても、利用者の安全が確保できる代替え手段があるのならばそれは認められる。

こういった国際標準に対する考え方が分かっていないと、振り回されたあげくに、利用者の安全をかえって脅かすハードウェア、ソフトウェアができてしまう。自分は門外漢かもしれないが、そのことをを非常に恐れているし、技術者、特に日本のソフトウェアエンジニアも規格に適合したら前よりも危ういソフトウェアになってしまったなどという結果は決して望んでいないと思う。

こんな背景から、自分はドメイン違いでありながら、 ISO 26262 に関する記事を書いている。

もしも、このブログの読者がさらなる情報を引き出したいと思うのであれば、このテーマに関する記事を続けていこうと思っている。ブログの右上にアンケートがあるので12/9 までに投票してもらい、反応が多ければ、このテーマの記事を続けたいと思う。

【ISO 26262 の取り組み方その1】

前置きが長くなってしまったのだが、記事一回につき、一つ以上のトピックスを書いていきたい。まずは、その1 「国際規格の読み方」。

国際規格を読む場合、注目して欲しいのは規格番号の後ろに付いている年号である。ISO 26262 の場合、2011年に発行されたので、ISO 26262-1:2011といったように表現される。

なぜ、年号に注目すべきかというと、規格は必ず改変されるという目で見て欲しいからである。時にISO 26262 は新規に制定された規格だから、運用していくうちに問題点がどんどんでてくる。この場合、規格の利用者はその問題点を国際委員に告げて、よりよくしていけばよい。

日本人の多くは国際規格は天から振ってくると思っている。実際にはそうではない。国際規格は各国で意見を出し合って、よりよい方向に修正していくものなのだ。日本人は奥ゆかしいから、文句をなかなか言わないが、おかしいと思うこと、修正した方がよいと思うことはキチンと主張しないと自分達が損するだけだ。

では誰に言えばいいのか。それは各業界には工業会があり、工業会から必ず ISO Technical Committee に代表を出しているはずだから、工業会の代表に問題点を伝え、工業会に参加していないのなら今からでも参加すればよい。自組織に工業会の代表がいるにもかかわらず、その人が情報を発信しない、もしくはその人へ情報を伝達しない技術者がたくさんいる。それでは国際規格を自分達に使いやすいように変えることはできない。まずは、交渉のテーブルに乗る必要がある。

さて、ISO 26262 に取り組むにあたって最初にするべきこと、それは規格を読むことだ。最初に自動車メーカーとサプライヤのエンジニアに警告しておきたいのは、規格を読まずにコンサルタントなど外部の者から知識や支援を一方的に受けては絶対にいけないということだ。

例えば、ISO 26262-6:2011 Part 6: Product development at the software で

Methods for the verification of software unit design and implementation　のセクションの表9に

Control flow analysis と Data flow analysis が ASIL C と D について ++ となっている。

++ の意味は“++” indicates that the method is highly recommended for the identified ASIL;だ。

highly recommend　は強く推奨されるだから、日本語に変換すると、「ASIL C と D のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をすることを強く推奨する」という要求になる。

8.4.5 The software unit design and implementation shall be verified in accordance with ISO 26262-8:2011 Clause 9, and by applying the verification methods listed in Table 9, to demonstrate:

※26262-8:2011 Clause 9 のタイトルは"Verification" で具体的に関係ありそうなのは 9.4.3 Verification execution and evaluation と思われる。

とあるので、表9 に示された検証メソッドを使って ISO 26262-8:2011 箇条9 への一致を示せと言っているが、考えてみて欲しい。電気的安全性に関する要件、例えば「患者漏れ電流が AC/DC 0.01mA 以下」ならば、テストによって確実に合格か不合格かを判定できる。ところが、ソフトウェアの場合、「コントロールフロー分析、データフロー分析をすること」と、利用者の安全は直接は結び付かないし、「コントロールフロー分析、データフロー分析」ができているのかどうかどうか、目的に対して効果を発揮できているかどうかを証明するのも難しい。ようするにに自分達が目的の達成のために有効であることを確信した上で、実施しましょうというのが本質的な要求のはずだ。

※医療機器ドメインでの歴史的経験から考えると、できているかどうか客観的に判定できないことを規格要求にしてしまっているところに ISO 26262 の未熟さを感じる。こういう場合は方法論ではなく、Activity （どのような活動が必要か）を要求してその活動に対するエビデンスがあるかないかをまずチェックし、その次に段階で活動の妥当性(=目的への貢献度）をヒアリングするような仕組みの方がよいと思う。方法論を推奨してしまったら、その方法論が絶対に必要だという話しが一人歩きするのは目に見えている。

これを規格原文の NOTE を含むディテールを読まずに、また規格を適合する側のスタンスが固まっていないうちに外部の者から話しだけ聞くと「自動車のソフトウェアユニット設計では、コントロールフロー分析、データフロー分析をしなければいけない、しないと規格が通りませんよ」となる。人間は、潜在的にそうして欲しいと思うと、表現をより大きくして聞いている者の気を引こうとするからそうなるのだ。

自分ならこう言う。

ISO 26262 では ASIL C と D のソフトウェアユニット設計において、コントロールフロー分析、データフロー分析をすることを強く推奨しています。なぜ、それが必要だと主張しているのか分かりますか。まず、この○○のソフトウェアユニットの ASIL を C と D にしている根拠を説明してください。そのユニットがユーザーに及ぼす危険はどのように回避されるのか、意図しないようなシステマティックフェイラーが起こらないためにどんな分析、設計、検証をしているのか教えてください。

そこで、十分に納得のいく説明ができるるのなら、コントロールフロー分析、データフロー分析以外の手段を使っていたとしても、外部の人間に聞かれたら、それを堂々と説明するように言う。全く何のことかわからないという反応を示したら、方法論ではなく規格のコンセプトや背景をプロジェクトメンバ全員に対してレクチャーする。そのトレーニングから始めなければ手段が目的になる。

手段が目的になってはいけない。目的を達成できるのなら手段は重要ではない。規格が手段を例示しているのは、何をすればいいのか分からない、これから何をすればいいのかの指針が欲しい者にサジェスチョンを与えているのだ。だから、highly recommend と表現しているのだ。highly recommend を「絶対にやらないといけないと規格に書いている」という者は驚くほどたくさんいる。彼らの中には悪気がなく、大事なことを教えて上げようと親切心でそういう者もいる。そう、彼は規格適合を自分の力でやりきった経験がないから、簡単に表現を強くしてしまう。しかし、自分はそれを現場でやりきることがどれだけたいへんかを知っているから、軽々しく highly recommend を「絶対にやらないといけない」などとは決して言わない。

したがって、規格適合を目指しているメーカーとサプライヤのエンジニアは必ず、規格の原文を読み、誰かから「規格要求だから○○をやれ」と言われたら、規格のどこの要求のことを言っているのかを聞く習慣を付けるべきだ。そして、その方法が利用者の安全にどのように貢献するのかを必ず考える。そこに確信が見いだせないのに実践しても意味がない。利用者の安全に貢献するという確信があってこそ、その方法論は生きてくるし、実際にそうなる。エンジニア側の確信なしにコントロールフロー分析、データフロー分析をやって、利用者の安全につながるわけがない。形式的に規格適合を示すことに貢献するだけだ。

ISO 26262 のような国際規格は、多くの場合工業会が和訳して対訳版を日本規格協会が発売する。最近は PDF 版と紙のどちらかを選択して買うことができる。現時点で ISO 26262 は邦訳版ができていないようで、英文のものしか売られていない。（ちなみに ISO の本家からも買うと円高差益の御利益に預かれるのに、日本からアクセスしていることが分かると日本規格協会から買いなさいと怒られる。）

さて、ISO 26262 は下記のようにパート分けされており、それぞれ単独で発行販売されている。FDAがガイダンスを無料で公開しているのに対して ISO 規格はしっかりお金を取る。下記の各パートは日本規格協会で買うとそれぞれ一万円くらいするが、適合を目指すのであれば買うしかない。

ちなみに、自動車系のソフトウェアサプライヤーなら、まずは、Part1, 2, 3, 6 を読んで欲しい。工業会の邦訳を待たずに、英語版を買って組織内で持ち回りで訳しながら勉強会をするとよい。邦訳しながら読むと詳細に理解できる。

ISO 26262-1:2011 Road vehicles -- Functional safety --

ISO 26262-1:2011 Part 1: Vocabulary
ISO 26262-2:2011 Part 2: Management of functional safety
ISO 26262-3:2011 Part 3: Concept phase
ISO 26262-4:2011 Part 4: Product development at the system level
ISO 26262-5:2011 Part 5: Product development at the hardware
ISO 26262-6:2011 Part 6: Product development at the software
ISO 26262-7:2011 Part 7: Production and operation
ISO 26262-8:2011 Part 8: Supporting processes
ISO 26262-9:2011 Part 9: Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyses

自動車メーカーとサプライヤのエンジニアは ISO 26262 が利用者の安全にどのように貢献するのかについて、十分に議論し、確信を得ることから始めなければいけないということを強く主張したい。

この続きを読みたい方は、アンケートの投票（複数回答可）をお願いします。

ソフトウェア系の国際規格はどのように使うのか(2)？ (ISO 26262 が正式発行される）

2011-11-26T17:38:00.001+09:00

前回に引き続き、ソフトウェア系の国際規格（ISO 26262）がどのように使われるのかを解説したいと思う。

自分は自動車ドメインの仕事はしていない。しかし、ソフトウェア系の国際規格には長いことつきあっているので、おそらくこの見解は当たっていると思う。もしも、自動車業界の方で間違っているところに気がついた方は是非お知らせ願いたい。このブログ上で訂正したい。

まず最初に読者に認識して欲しいのは国際規格はそれだけでは法的な拘束力はないという点だ。国際規格と聞くと国際法のように守らないと罰則がある、当局に捕まるというイメージを持っている人が大勢いるようだがそうではない。

国際規格は各国の規制当局が規制に使うと宣言したときに初めて法的拘束力が生じる。日本のトヨタ自動車が ISO 9001 を取得していないという事実は有名だが、だからといって誰からも咎められることはない。トヨタは ISO 9001 に適合てきなくても自分たちのやり方で品質をマネジメントできているからいいのだ。

他の国際規格も全く同じだ。自信がある組織は国際規格を使わない選択肢も取れる。しかし、多くの場合は国際規格に乗っかった方が楽であり、みんなと同じであるとアピールしやすい。さて、では自動車の電子制御系に関する安全規格 ISO 26262 が2011年11月15日に正式発行されたがこれはどうだろうか。

EUとUS（アメリカ）と日本、中国、その他一般海外で分けて考えてみよう。

まず、EU。ISO規格を最も重要視するのがヨーロッパの国々で特にドイツがその度合いが強い。ドイツを筆頭にEUの国々は ISO 規格の策定に積極的に参画するし、策定された暁にはそれらに適合することに精を出す。自分たちでルールを決めてルールを守ろうとする。

そしてドイツには有力な二つの規格認証機関がある。これらの認証機関は世界展開しており、主要各国に拠点を持っている。規格認証機関は規格の策定にも関わり、規格が発行されると、その規格を認証することで利益を得る。規格認証ビジネスは結構儲かる。規格の適合を監査し、適合できていないことが分かると、その規格が何を求めているのかを説明し、適合できるように指導する。監査するときも指導するときも費用が発生するから、厳しく監査してダメだしすればするほど、やるべきことが増えてたくさん指導を受けなければいけない。

ドイツの規格認証機関は特に厳しく規格適合を求める傾向があり、結果として厳しく監査して欲しい対象企業からの信頼が高い。

そういう傾向があるため、ドイツのメーカーは規格適合に積極的であり、ドイツの自動車会社が日本のサプライヤーに対して ISO 26262 への適合を求めるシチュエーションは大いにあり得る。しかし、これは法的な要求ではないことを頭に入れておいて欲しい。ただ、クライアントが規格に適合せよと言ってきたのであれば、サプライヤーはイヤとはなかなかいえない。なぜなら、「イヤなら規格適合している他の会社から調達するか君たちとはサヨナラ」と言われてしまうからだ。

ただし、冷静に考えて欲しいのは、例えばイタリヤやイギリスの自動車メーカーがドイツほど強くISO 26262 への適合を求めるだろうかということである。自分の予想では EU の中でも声高に言ってくるのはドイツの会社だけだと思う。それでなくても、今 EU は大変な状況なのに、規格適合のために莫大な費用をかけたいとは思わないはず。まして、法的な要求でもなんでもない規格への適合に今人と金をかけようと考えるヨーロッパのメーカーとサプライヤがどれだけいるかと思う。

つぎにアメリカの考え方だ。アメリカは国際規格をそれほど重視しない傾向がある。代わりに自分たちで作ったルールが一番だと考え、アメリカ国民の安全を守るために自分たちが決めたルールを守らせる。このルールにはばっちり法的拘束力をもたせる。時にTBT協定違反だと批判されることがあるが、そんなことは気にもせず、我が道を行く。

よって、アメリカの自動車会社がサプライヤに対して ISO 26262 の適合を直ちに要求するとは思えない。アメリカ人はフェアーを重んじるので、アメリカ国内のサプライヤに求めず、国外のサプライヤだけに求めるということはしない。

ただし、アメリカは訴訟社会であるため、事故が起きた時に、自動車に搭載されたソフトウェアの安全性について説明せよと言ってくる可能性はある。そのとき、ISO 26262 に適合してソフトウェアを作っていると主張するのは説得力があるだろう。

つぎに日本。日本は ISO 規格をそのまま規制に使うことはない。まず、日本工業規格 JIS にする。要するに日本語にする。これには結構時間がかかり、2～3年はざらにかかる。通常は工業会が持ち回りで翻訳をし、何回か見直しをかけたあとパブリックコメントを募り JIS 規格として登録される。

ただ、JISになったからといってそれが規制になるわけではない。車ドメインのことは詳しくないが、自動車に関する許認可の権限を持っているのは国土交通省だろう。国土交通省が法律に基づいて自動車に搭載されているソフトウェアの安全性を審査できるかと言えば、できる訳がない。それをやるには法律を改正する必要がある。また、国土交通省が自動車のソフトウェアの安全性を審査できる訳がない。そんなことができる人材も組織もない。何十年も前から取り組んでいるドイツだって難しいと思われるのに、これまでまったく取り組んでいなかった日本でソフトウェアの審査はできないし、仮にやり始めたらとんでもない指摘が飛んでくる可能性がある。例えばソフトウェアに関する知識がまったくない審査官が「このソフトウェアはコードレビューはしているのかね」などと、よく意味も分からず聞いてくるかもしれない。

また、現在自動車のソフトウェアで社会的な問題が頻発しているか。そんな話はないし、日本の自動車は世界一品質が高いと言われている。取り締まりを強化しないと国民の安全が確保できない状況ではない。

よって、日本では ISO 26262 は法的規制になるとは到底思えない。

次は中国。中国は予測がしにくい国だ。どの分野においても国際的なレベルに達したいと考えているため、国際規格への取り組みの意気込みは日本よりは遙かに強い。しかし、国際規格が求めるレベルにすぐに達することができるかどうかという問題もある。よって、周りの国々の様子を見ながら遅れを取らないようにしようとするだろう。おそらく政府として ISO 26262 の要求についての勉強はしていると思うし、中国語への翻訳も始めているかもしれない。ただ、だからといって規格を規制にするかどうかはわからない。中国国内のメーカーがまだ対応できないと見たらすぐには規制用件にはしないかもしれない。

最後に一般海外は、各国の動向を見てみんなが規制するようになったら同調するだろうと予測する。

【誰が何のために ISO 26262 を使うのか？】

これまで解説したように、現時点で ISO 26262 の適合の積極的なのはドイツであり、ドイツの自動車メーカーが日本のサプライヤに対して ISO 26262 の適合を要求する可能性は高い。また、日本の自動車会社が日本のサプライヤに安心材料として ISO 26262 への適合を求める可能性もあるかもしれない。

ただし、ドイツと日本の場合では事情が異なる。ドイツは歴史的に国際規格への適合をチェックするための規格認証機関を持っている。彼らは規格の内容もよく理解しており、監査テクニックも持っている。個人レベル、会社レベルの規格適合コンサルタントもうようよいる。規格適合に関するビジネスモデルができている。

ところが、日本には日本オリジナルの規格認証機関はあまりない。特に、ソフトウェアを監査できる認証機関は存在しない。しかし、ドイツを始めEUでは規格適合ビジネスの市場はあるので、日本でもそのビジネスモデルに乗っかりたいと思う会社はたくさんいる。

でもソフトウェアの監査の経験は皆無に等しいだろうから、最初のうちは規格適合について尋ねている方も答えている方も何を言っているのかわからないという状況が続くだろう。

したがって、ここ数年はドイツを始めヨーロッパの自動車会社が ISO 26262 への適合を日本のサプライヤに対して求めるだろうが、規格への適合を監査できそうなのはヨーロッパ系の規格監査経験の長い規格認証機関に頼むことになる。

そして、ソフトウェアの監査ができる人材は希少なため、本質的な突っ込みを入れることはほとんどできず、結果的に規格適合はチェックシートを埋めるという形式的なものになると予測する。

そこで、サプライヤの皆さんに聞きたい。「誰のために、何のために ISO 26262 に適合するの？」「誰のために、何のために ISO 26262 に適合したいの？」と。

この質問に対して、「クライアントから求められているから」と答えるのならは、それは形式的なことのために人、物、金を投入するのだと考えた方がよい。

「自分たちが作ったソフトウェアが安全で信頼できることを証明するための手段として ISO 26262 を使う」と答えるのならば、その組織は投資が無駄にならないかもしれないし、この不景気な時代に規格ビジネスで金儲けしたいと集まってきて有象無象の輩をかき分けて真の支援者を探し出せるかもしれない。

前者でお金を捨てたくないのならば、まず、規格要求を腰を据えて読むことだ。そして、規格認証機関には規格要求の疑問点を尋ねる。要求の中身を一回も見ないで、規格認証機関やコンサルタントに頼ってはいけない。それは思うつぼで湯水のように形式のためにお金を使うことになる。

そして、技術誌の編集の方たちにお願いしたいのは、ISO 26262 の策定委員に対してのインタビュー記事を多く載せて欲しい、できれば座談会をしたり、それぞれに記事を寄稿してもらって欲しいということだ。国際規格はそれを読んだだけでは、規格の本当の意図が分からないことが多い。そしてそれが分からないと、規格認証機関やコンサルタントが自分たちのビジネスに有利になるように規格を解釈してクライアントに伝える。そうなるとサプライヤは形式に金を使い、本質的な安全にはなかなか近づかないという不幸が訪れる確率が高くなる。

繰り返すが、今一度考えて欲しいのは、誰が何のために国際規格を使うのかという点だ。

※本件に関するコメントを募集していますのでよろしくお願いします。

ソフトウェア系の国際規格はどのように使うのか？ (ISO 26262 が正式発行される）

2011-11-24T17:42:00.001+09:00

自動車の電子制御系に関する機能安全規格「ISO 26262」が、6年間の策定期間を経て、2011年11月15日ついにISOの正式な国際規格となった。

下記が Tech-On! で報じられた記事である。

『クルマの機能安全規格のISO 26262がついに正式発行』

自分は自動車ドメインの仕事はしていないが、メディカルデバイスの世界で国際規格とは20年以上付き合っている。

そこで自動車ドメインの方々にアドバイスをしておきたいと思う。

【ソフトウェア系の国際規格はどのように使うのか？】

自分達がアウトプットしているソフトウェアの安全性や信頼性を外部に対して説明するために使う。
実質的に自社のソフトウェアの安全性や信頼性を高めるために使う。

1の説明責任を果たすためという目的と2の実質的な目的は、同じように見えてかなり差がある。

なぜかというと「説明責任を果たせること」と「実質的に安全であること」は必ずしもイコールではないからだ。特に日本の組込みソフトウェアは、実質的にリコールの件数が少ないが、説明責任を果たせる組織やプロジェクトは非常に少ない。

それは一つは、日本人が元来記録を残す文化が希薄だからだ。嘘だと思う人は40年来のベストセラーとなっている梅棹忠夫氏の『知的生産の技術』を読んでみるとよい。

もう一つの理由は日本人は品質を気にする気持ち Awareness がプロジェクトメンバー一人一人に浸透しているため、開発プロセスを厳格に管理しなくても、安全性や信頼性の高いソフトウェアを作れるという特性を持っているからだ。ソフトウェア系プロセスの国際規格の根幹にはソフトウェア品質はプロセスを管理することでしか測れない、証明できないという主張があり、その主張を覆すことはまだ誰もできていない。

日本人が品質を気にする気持ち Awareness が安全性や信頼性の高いソフトウェアを生み出しているからといって、日本人が作るソフトウェアの安全性や信頼性を外部に説明する責務を放棄することはできない。「日本人が作っているので安心してください」と言っても今や説得力がないからだ。

100万行を超えるようなソフトウェアの規模になってしまった現在では、すべてのソフトウェアが日本製だとは限らないし、一人のソフトウェアエンジニアがシステム全体を把握できない。

だからこそ、ソフトウェアの安全性や信頼性を何かしらの標準を使って外部に説明する必要がある。

そのときに、国際規格を使うと説明の効果が高い。国際規格は各国の代表が原案を審議し投票によって決めた標準であるから、その内容に沿って説明責任を果たすのは合理的だ。仮に、日本のメーカーが作ったソフトウェア搭載製品が事故を起こしたときに、「そのソフトウェアは安全なのか、信頼はおけるのか」と聞かれたら「国際標準に適合しています」と答えることができる。そうでない方法で、説明責任を果たすのは可能かもしれないが非常に難しい。特にソフトウェアの場合は、バグは一つもないと言い切れないからなおさらだ。

よって、ソフトウェアの国際規格に適合していることは、安全性や信頼性を主張するための根拠となりうる。

ただし、ソフトウェアの国際規格とハードウェアの国際規格の間には決定的な相違点がある。それはハードウェアの場合は規格に適合しているかどうかが試験によって判定できるが、ソフトウェアの場合は正当性を試験では判定できないことがほとんどなのだ。

ソフトウェアのつくりかたは千差万別で、ある作り方をすれば確実に安全とか信頼できるとは言えない。また、ソフトウェアの最大のメリットは変更容易性であるから、一度安全性や信頼性を確認しても、たった一行変更しただけで、その安全性や信頼性は崩れる可能性がある。

よってソフトウェアの国際規格では要求に対して、その通りにしていなくても別の代替え手段で説明することが容認されている。要求に対して根拠を持って説明できればそれでもOKとなるのだ。

これが日本の技術者は本当に苦手だ。自分達のやっていること、やってきたことに自信があれば、堂々と説明できるののに、監査等で説明を求められると急にできていないことばかりが頭をよぎり、できていること自信があることを全面に出して主張することができない。

ディベートの訓練をしていないせいもあるだろうが、元来正直者ではったりをかますのが得意ではないのだ。決して嘘を言えといっているのではない、相手の要求を理解した上で、本質的な目的（エンドユーザーに対する安全や信頼）のために日々やっていることを自信を持って主張すればよいのだ。それは毎日の自分の行動に対して根拠を説明できる技術者であればできるし、誰かから言われた通りに日々を過ごしている者にはできない。

後者は、自分ややっていることに自信がないから「この方法論を使うと規格に適合できますよ」とか「このツールを使うと規格に適合できますよ」と言われるとすぐにそれに乗って「よく分からない要求から逃れたい」「楽になりたい」と考える。それは、完全に思うつぼだ。

説明責任を果たす目的を達成したいのなら、まずは国際規格の要求を自分の頭で理解することだ。要求を理解せずに方法論に乗っかろうとしてはいけない。そうすると必ず振り回され、最終的には監査やオーディットの際に「このツールを使っているから規格に適合できています」とか「○○に適合を確認してもらっています」などを答えて早々と「これはダメだ」と烙印を押される。

監査や査察で一番重要なのは、実担当者が規格要求をどれだけ理解しており、その要求に対してキチンと受け答えができるかどうかだ。規格要求の真意を理解もせずに方法論に走ってしまっている場合、実担当者は受け答えができないので、すぐにコンサルタントやQA担当に助けを求ようとする。監査官、査察官はその目の動きを決して見逃さない。

国際規格を使ってソフトウェアの安全性や信頼性を説明したいのなら、まず、規格要求を理解している者を組織内に少なくとも一人は作る必要がある。そして、実務担当者も徐々に理解を深めていく。

2番の「実質的に自社のソフトウェアの安全性や信頼性を高めるために使う」はまたの機会に説明をしたいと思う。

今回の記事に関して、疑問質問がある方はこの投稿にコメントを書いて欲しい。（必ず回答を書きます）

スティーブ・ジョブズの伝記を読んで

2011-11-06T15:56:00.000+09:00

iPad で　Steve Jobs ⅠⅡを読んでいる。現在はⅡの頭の方で、スティーブ・ジョブズが一度 Apple から追い出された後復帰してApple を立て直そうとしているところだ。

この本（電子書籍）を読んでいると、途中で無性に Apple ⅡやMacintosh、ジョブズの演説、有名なCMなどが見たくなる。

電子書籍なのだから写真やリンクを埋め込んでくれればいいのに、本をそのまま電子版にしただけなのでリンクはない。写真は最初に固まってあるが、本当に見たいのはその商品や場面のくだりの部分で見たい。

スティーブ・ジョブズは伝記を書くことを許可したけれども、自分では原稿を読まなかったので、読んでいたら作品としていろいろ注文を付けたのではないかと思う。

さて、Steve Jobs ⅠⅡを読んでいて気がついたことがいくつかあった。一つはアメリカの企業の前に進む進み方が非常にダイナミックだとういことだ。Apple だけの話ではない。企業の吸収や合併、方針の大幅な転換、リストラが当たり前のように行われている。

そして人の移動もダイナミックだ。△△の○○は□□が得意だから連れてこようとかいったシーンがしょっちゅう出てきて、呼ばれた方も一つの会社のCEOをやっていてもそこを抜けてしまったりする。

また、企業のトップ同士のコミュニケーションが頻繁に行われる。スティーブ・ジョブズとビル・ゲイツは犬猿の仲で会ったこともないのかと思ったら、そんなことはなく、水と油ではあるものの業務提携したり、話し合いや交渉もけっこうやっている。

スティーブ・ジョブズがゼロックスのパロアルト研究所(PARC)を訪れた際に、初めてPCがGUIで動くのを見てMacintoshのルックアンドフィールのGUIを思いついたという話は本当のようだが、その後、ビル・ゲイツがWindows を作ったときにスティーブ・ジョブズはビル・ゲイツに「おまえがしているのは盗みだ！信頼しているたというのに、それをいいことにちょろまかすのか！」と言ったそうだ。

それに対してビル・ゲイツは「なんと言うか、スティーブ、この件にはいろいろな見方があると思います。我々の近所にゼロックスというお金持ちが住んでいて、そこのテレビを盗もうと私が忍び込んだらあなたが盗んだあとだった。むしろそういう話なのではないでしょうか」と反撃したらしい。

なにはともあれ、企業と経営者と社員がダイナミックに動き、企業という枠がありながらもその間を人や技術や商品が行き来している。落ち着かない面もあるかもしれないが、思い切ったことができるような気がした。技術者もその枠の中に留まってはいない。技術を請われてあっちに行ったりこっちに来たりする。最初から必要だという気持ちでマーケティングや宣伝にもきっちり予算を付ける。

日本の企業には動かない変わらない良さ、伝統的な技術を継承し続ける強みがあるので、企業のダイナミックな動き方がよいとは言い切れないが、魅力的に見えるのも確かだ。失敗と挑戦を繰り返しても受け入れてくれる土壌がアメリカにはあるように思った。

ただ、だからこそ契約が大事だとういうのも分かった。Steve Jobs ⅠⅡの中で大事な契約がいくつも出てくる。スティーブ・ジョブズが分厚い契約書を数ページに簡素化するよう指示する場面が何回かあったが、それはすなわち企業のトップが契約内容を掌握し、契約によって企業活動を動かしている証でもあると思った。

契約の中には今から考えるとそんなことがあったのかという物もある。Microsoft初のアプリケーションはマック用の Excel と Word だった。Apple にとっても、Excel と Word は重要なアプリだったので、これを引き上げられては困る。そこで、Apple 交渉の過程で GUI を Windows 1.0にライセンスし、その見返りとしてExcel を最長2年間、マック専用とするという契約を交わしている。

日本では、企業間でこんなダイナミックな契約はなされないだろうなと思った。

この本を読んでるとエンジニアはものづくりにかける情熱をなくしたら終わりだとうことがよく分かる。みんなすばらしいものを作って胸を張りたいと思って仕事に打ち込んでいる。リリース前に商品（特にソフトウェア）が完成しておらず、徹夜して何とかしようとする技術者の行動は今も昔も同じだ。その気持ちがなくなったら自分の存在価値がなくなると思った。

下記に示した若き日のスティーブ・ジョブズが行っているMacintoshのプレゼンテーションは、製品のソフトウェアが間に合わずに徹夜して仕上げた後で、プレゼンテーションにインパクトを与えたいと思ったソフトウェアエンジニアたちが最後の力を振り絞って完成させたデモソフトだ。

スティーブ・ジョブズは人間として幸せだったかどうかは分からないが、少なくとも多くの人に感動を当てる商品をもたらした。それを達成した時は関わった人々も含めて技術者として幸せだったと思う。

自分自身の中では Apple の商品の中で初代Macintoshと、iPad が世の中に革命をもたらしたと思っている。そのどちらも自分の手にすることができたことに幸せを感じる。

----------------
この記事の一番後ろに、本を読みながら“見たい”と思った画像、映像をインターネットで探すことができたので貼り付けておく。

2分間で Apple の製品を眺めることができる映像

こっちは、マッキントッシュのプレゼンテーション

有名なCM二つ。

1984

Think Different

技術書の現在と未来

2011-09-19T22:48:00.000+09:00

2006年3月に『組込みソフトエンジニアを極める』を書いてからはや5年が経過した。このブログ自体、この本の読者と双方向で情報交換をするために書き始めたことを思い出す。

第一回目の投稿は今でもここに残っている。

この本が出版されるまでは自分も技術書の一読者だった。それ以降は技術書の出版や雑誌の編集についてその裏舞台も知ることになる。

読む側の立場だとあまり実感がないと思うが、今技術系の雑誌や本は売れない。技術系だけでなく本や雑誌全体が売れていない。2005年から2010年までの約5年間、ソフトウェア特に組込みソフトの雑誌や本が次々と出版された。今はそのブームは去っている。

製造業自体が大幅な落ち込みを見せている訳ではないので、出版業界が「組込みソフト」というキーワードに踊らされていたのかもしれない。

さて、2006年3月に日経BP社から出版された『組込みソフトエンジニアを極める』は初版の4000部がほぼ市場からなくなりかけたところで、増版はされないことが決定された。

理由は過去一年の売り上げのペースから考えると、増版したときのコストが見合わないという判断からだ。

本は出版するときに出版社がかなりのリスクを背負う。本を少しずつ刷るとコストが高くなるので、技術書なら概ね1000部以上は刷らないといけない。本を印刷するまでに、著者への印税の支払いやイラスト作成代、編集者の人件費等もかかり、印刷費用も数十万円はかかる。紙代、インク代も馬鹿にならない。

そして本の場合、日本では再販制度があるため書店はいくら書籍を仕入れても返品が可能で、倉庫代も出版社が持つことになる。

技術書の場合、1万部も売れればヒットの部類に入り、10万部売れれば大ヒットだ。しかし、それだけ売れても著者はその印税だけではとても食べてはいけない。何しろきちんとした本を作ろうとすると時間と労力がかかるので、まったく割に合わない。

しかも、今の技術者はインターネットから情報を仕入れてしまうので、あまり本や雑誌を買わない。技術系の出版社は非常に苦しい状況に立たされていると思う。

それでいいのかと思うが、これが現実だからしようがない。ちなみに電子出版に未来があるかというと必ずしもそうではないようだ。そこら辺の事情を知りたい方はペーパーバックスの『出版大崩壊電子書籍の罠』文藝春秋 800円を読んでいただきたい。

読者のみなさんにアドバイスしておきたいのは、これからは絶版になる技術書も増えてくるので、「これはいい本だな」と思ったらためらわずに今かっておいた方がよいということだ。ネット書店だからといって在庫切れが起こらないとは限らない。中古品もネットで流通するようになったが、市場に出回らなくなってくると中古品でも定価の倍以上の値が付くこともある。

ところで、日経BP社から発売された『組込みソフトエンジニアを極める』は絶版になってしまい、Amazonを見ると中古品も品薄状態になりつつある。

もしも、将来この本を読みたいと思う人が現れたときに買えないのは著者としては非常に残念である。そこで、いろいろな方々に協力してもらいこの本を新刊として再出版することになった。

再出版といっても最初に出版した日経BP社にイラストや編集の権利があるため、自分自身のオリジナル原稿と図表をもとにまた編集を一からやり直した。編集は結果的に8ヶ月かかった。

この本や他の技術書に比べても異常とも言えるくらい図が多い。この図をトレースし直すのに時間がかかっている。

編集は、フレデリック・P・ブルックス Jr. の名著『人月の神話』の翻訳者で株式会社エスアイビー・アクセス社長の富澤昇氏にお願いした。

タイトルは前とは少し変わって『リアルタイムOSから出発して組込みソフトエンジニアを極める』とした。理由は、リアルタイムOSのを使った実際の組込み製品のアプリケーションソフトの開発を題材にした本はあまり見たことがないのと、やはり組込みソフトエンジニアはリアルタイムOSから出発して、システムの時間制約をクリアし、大規模システムのアーキテクトもこなせるようになることがキャリアパスの本流ではないかと思ったからである。

前作と『リアルタイムOSから出発して組込みソフトエンジニアを極める』の違いを示すと次のようになる。

一番大きい変更点。価格を買いやすくするために2800円から1800円に変更した。
ページ数は296ページから260ページに減った。（1ページの文字数が増えた）
本の厚みが2/3ほどになった。（紙が薄くなったから。内容は同じ）
人物イラストは省いた。
5年経過して時代に合わなくなった文言等を修正。

人物イラストは若いエンジニアが成長していく姿をドラマ風に見せるために付けていたのだが、台詞だけでも十分にその雰囲気は伝わるし、やはり技術書なので中身で勝負しようと思い省いた。（イラスト入り外伝はまだ生きているので参考にされたし）

また、若いエンジニアに是非読んでもらいたいという気持ちから2800円だった定価を1800円に下げた。

中身は同じなので前作同様よい評価を得られることを祈っている。

若い技術者の方たちにはもっと本を読みなさいといいたい。もしかすると日本人が日本語で書かれた本を読む時代ではないのかもしれない。英語なら読者の数は一気に増えるので、英語の本を英語のままで読めるようになった方が情報収集の効率はよい。

でも、日本人の気質、日本特有の技術や仕事の進め方は英語の本の中には書かれていることはまれだ。そんな本を書くことを目指している。

ソフトウェアアーキテクチャの改善はなぜ進まないのか

2011-08-14T09:44:00.000+09:00

ソフトウェアエンジニアでない人にはピンとこないかもしれないが、ソフトウェアのアーキテクチャ（構造）を改善するということには意味がある。

家が完成してしまうと外面からはどのようなアーキテクチャ（構造）でその家ができているのかがよく分からなくなってしまうのは実際の建築物もソフトウェアシステムも同じだ。でも、そのアーキテクチャの善し悪しが災害に対する強度だったり、住みやすさに大いに影響する。テレビ朝日の『大改造!!劇的ビフォーアフター』で、古い家屋を骨組みだけにする過程で、基礎がいい加減だったり、支えとなる柱が途中で切られていたりするケースをたまに見かけるが、これらの手抜き工事は外からでは見られないから恐ろしい。

ソフトウェアの場合、アーキテクチャが悪いと、非常にわかりにくいバグを生んだり、ソフトウェアの再利用によく多くの時間と工数がかかる。こちらも、それらの問題がソフトウェアのことに詳しくない人には見えない、理解できないからやっかいだ。

ソフトウェアアーキテクチャの改善（＝ソフトウェアプロダクトラインの導入）は組織のトップからおろしていくのであれば、品質面のメリットよりも、コストメリットや開発期間の短縮のメリットが強調されると思う。ただし、改善の実現には一時的にソフトウェア資産の再構築が必要になるため、成果が現れるまでには2～3回製品を開発するサイクル（1年以上）を回す必要がある。その投資期間をじっと我慢することができれば、その後から劇的な効果が現れる。

日本の組織ではそのようないったん我慢をして後々の利益を取るという判断ができる企業は少ないので、なかなかソフトウェアアーキテクチャの改善に踏み出せない。

そこで考えるのは、プロジェクトやエンジニアにアーキテクチャ改善の重要性を諭して取り組んでもらうというアプローチだ。しかし、それもなかなかうまくいかないケースがあることに気がついてきた。

既存のソフトウェアシステムのアーキテクチャを可視化して問題点を共有しても、思ったより改善に対する気持ちがイマイチ盛り上がらない場合がある。それはそもそも既存のソフトウェアシステムのアーキテクチャ設計を外部の協力会社の技術者に任せているケースだ。建築業界においてハウスメーカーが自社の商品の構造設計を外注することはないと思うが、ソフトウェアの世界ではソフトウェアシステムのアーキテクチャ設計を外部の技術者にゆだねることはよくある。悪い言葉で言えば丸投げだ。

アーキテクトがプロジェクトのメインメンバーの外にいる場合、アーキテクチャの改善は非常にやりにくい。なぜなら、アーキテクチャに問題があることに対してアーキテクトはすぐに理解できるが、プロジェクトのステークホルダには十分に理解できないからだ。協力会社のアーキテクトはアーキテクチャの改善をプロジェクトに進言するということは、これまで納品してきた自分たちのソフトウェアに問題があったことを告げることににもなる。アーキテクチャの改善とはこれまでのソフトウェアシステムの中にある問題点を自ら認め、未来のために一時的な苦労を強いることである。そのためには協力会社のエンジニアを含めたプロジェクト全体で現在のアーキテクチャの問題点について認め合い、目標となるゴールについての認識を一つにしなければいけない。

エンジニア個人としては、アーキテクチャが改善したことでどれくらい自分自身が成長し、仕事が楽になるのか感覚的に分かっていないと改善への第一歩を踏み出せない。

鶏と卵のような関係で、アーキテクチャの改善に必要なトレーニングを与えるのが先か、それともアーキテクチャの改善によるメリットを実感させることが先かは微妙なところだ。前者はメリットが実感できないと学習効果が上がらないし、後者はスキルがないとメリットを実感できないからだ。

日本でソフトウェアアーキテクチャ改善の話題がいまいち盛り上がらないのは、ソフトウェアアーキテクトの存在が組織内で認識されておらず、その職務が不明確で地位が確立していないからではないかと思う。建築業界では建築士という資格によってその地位が認められているが、ソフトウェアの世界では、そのような資格は存在しない。（資格があればいいってもんじゃないが）

ソフトウェアアーキテクチャを改善し、ソフトウェアコンポーネント間の関係がすっきりすると、開発は非常に楽になる。簡単に言えばソフトウェア資産に一切手を入れずにコンポーネントを再利用できるようになるから、資産の再利用のコストは限りなくゼロに近くなる。

かつて作ったソフトウェアの“流用”すると言っておきながら、新規にソフトウェアを開発するのと同じくらいの費用や期間がかかっていることに疑問を持つプロジェクトやクライアントの会社が少ないことに驚きを隠しきれない。ソフトウェアの再利用に成功したことが一度もないから、ソフトウェアはよく分からないが金がかかるものだと思っているのだ。

また、ソフトハウスの経営者としても再利用資産が増えることで工数が削減されることは利益の減少につながるから積極的にアーキテクチャ改善には動かない。しかし、それは発想を変えるべきで、ソフトウェアのアーキテクチャを改善し、再利用性が高まったら、その資産を利用して新たな派生製品を作り、そのアプリケーション開発のための仕事を受注すればよいのだ。前者の考え方は長期的な視点に立てば、コストダウンで開発費を縮小され、少人数で仕事量が増えるから悪循環に陥り、後者は資産の再利用により開発効率が高まるので長い目で見れば好循環につながる。

新しい技術を学びながら、自分のスキルと市場価値が向上し、開発効率が上がって、よりクリエイティブな仕事ができるようになるのに、なぜアーキテクチャの改善に積極的に踏む出そうとするソフトウェアエンジニアが少ないのか自分には理解できない。

その答えの一つは、自分や自分のプロジェクトが作成したソフトウェア再利用資産が他のプロジェクトや他の商品に利用されても、再利用できたことのメリットが表面にでてこないという現実がある。

どんなに自分自身が成長しても、その成果を自分の中だけにとどめておいたのでは自己満足に終わってしまう。組織に認められてこそ、組織貢献を果たすことができ、顧客への貢献につながる。

そんなこんなの問題が山積していることから、ソフトウェアアーキテクチャの改善は難しいのだ。

最後にソフトウェアエンジニアに言いたいのは、これからも続く長いソフトウェアエンジニアのキャリアパスを考えたときに、10年後、20年後に振り返ったら日々忙しくしていた自分しか見えないというのはあまりにも悲しくないかということだ。自分が組織に残したソフトウェア資産やアーキテクチャは「これだ」と言えるようになりたくないのか。一回やってみるとそのありがたみが分かるはずなのに、日々の忙しさを言い訳にして最初の一歩を踏み出せない技術者が多すぎる。

「部下に任せないとダメだ」と考えさせられる一冊（その2）

2011-06-25T17:26:00.002+09:00

小倉広著『任せる技術』を読み進んだので前回に続き感想と思ったことを書こうと思う。

小倉氏は CHAPTER 3 任せる、と伝えるの中で、「人生のビジョンがない部下には任せられない」と書いている。仕事を任せる時には部下に自分からジャンプさせ選ばせる。しかし、そうするためには絶対に必要な条件があり、それが、自分なりの「判断基準」を持っていることだという。そして、その「判断基準」が長期的な「人生のビジョン」であることが必要というのだ。

【CHAPTER 3 「任せる、と伝える」より引用】

部下の立場に立って考えてみよう。上司から仕事を任せたい、と申し出があった。どうやら今よりも仕事が増えそうだ。しかし、すぐに給料が上がるわけではない。目先の損得だけを考えれば、これは間違いなく「損」だ。

「給料が上がるわけじゃないないし、だったら面倒だから断ろう」

このように考えるのがごく普通の判断というものだろう。しかし、もし、彼に将来の夢があったならどうだろう。例えば独立して社長になりたい。もしくは他社からスカウトが来るようなプロフェッショナルになりたい。そんな夢があったら、きっと判断は変わるに違いない。

「将来独立するためには、この経験はプラスになる。自己成長のために是非やらせてもらいたい。」そのように答えが変わってくるだろう。

【引用終わり】

小倉氏は組織人事のコンサルタントだったからこう書いているが、この話しはソフトウェアエンジニアにも全く同じように当てはまる。

ソフトウェアの開発効率や品質を高めるためには、高度なスキルを学んだり、自動化のシステムを構築したり、アーキテクチャを見直したり、プロセスを組み直したりするため一時的に仕事量が増える。日々忙しいのなら、さらに忙しくなるということだ。

ソフトウェアプロダクトライン（ソフトウェアの再利用戦略）もそうだが、最初に再利用資産を構築する際には通常の作業よりも1.5倍くらいは軽く工数も時間もかかる。それを乗り越えて「今やろう」と決断できなければ、その先開発が楽になることはない。エンドレスの悪循環が待ち構えている。

エンジニア個人やプロジェクトにスキルアップや新しい取り組みを進言するとき、必ず聞かれるのは「それをやるとどれくらい工数や時間がかかるのか」だ。目先の損得だけで判断されると大抵は辞退される。だからこそ、エンジニアとしての将来の夢を語りたいのだが、なかなか自分自身がエンジニアとしてどう成長したいのかを頭に描いている人はいない。

新人は夢があっていいのだけれど、職場に配置されて1年もたつと、夢を語らなくなる。上記の引用のように、夢のないエンジニアに仕事を任せても成長のスピードが遅い。

本サイトでよく読まれ低r記事「問題解決能力（Problem Solving Skill)：自ら考え行動する力」の「どうせどうせ子ちゃん」や「評論家君」が多く、「問題解決キッズ」が少ないのだ。

小倉氏は、『任せる技術』のなかで「世の中には、明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たないと思う。これまで3万人の管理職に研修や講演をしてきた僕の実感値では、1～2%がいいところだろう。」と言っている。よって、上司は部下が自分の人生のビジョンを描くお手伝いをする必要があり、そのためには定期的な面談が欠かせないと書いている。

【CHAPTER 3 「任せる、と伝える」より引用】

■ビジョンなし、なら今に集中

実際に部下と人生のビジョンについて面談するとわかることがある。それは何度質問を繰り返してもビジョンが見つからない部下がたくさんいるということだ。これまで彼らは「ベキ論」に縛られて生きてきた。だから突然、「どうしたい？」「どうなりたい？」と聞かれるとうろたえてしまうのだ。「やりたいことが見つからない」。そういう若者が増えているのだという。では、僕たちは彼らに対してどう接すればよいのだろうか？

これまで言ってきたことと矛盾するようだが、僕はその場合は、ムリしてビジョンを描かなくてもいいと思う。今、目の前にある仕事に120%集中するよう導いてあげればいいのではないか。

キャリア・ドリフト理論という考え方がある。キャリアはデザインするものではない。偶然に出会うものだ、という考え方だ。ただし、そのためには条件がある。今、目の前にある仕事に120%集中することだ。「自分には向いていないかもしれない・・・」などと言わずに、その仕事に集中するのだ。そのときに初めて偶然が、幸運が訪れる。

【引用終わり】

「明確な人生のビジョンを持ち仕事に取り組んでいる人は1割に満たない」というのは悲しいことだ。そうなっているのは、人生のビジョンを描く訓練をしてこなかったからだと自分は信じたい。「ベキ論」に縛られることなく、やりたいことをやるにはどうしたらいいのかを考え、実行し、ダメだったらなぜそうなったのかを反省するそれを繰り返していけば、人生のビジョンを描けるようになると思う。

本当ならば、それを学生の時代に訓練しておいて欲しいのだが、その訓練をする機会もなく社会で出てしまった人達は大勢いる。だから、上司は部下に仕事を任せなければいけない。

【CHAPTER 3 「任せる、と伝える」より引用】

■任せる、とういことは、自分の違うやり方に異を唱えないこと

任せた以上は、自分と違うやり方を許容しなくれはならない。
「オレだったらこうするのに・・・」
「そのやり方をすると後で必ず問題が起こるぞ。あ～。やっちゃった・・・」
そう思ったとしても、部下のやり方に異を唱えてはいけないのだ。失敗することも含めて部下に経験させなくてはならない。それが本当の意味での任せる、ということなのだ。

【引用終わり】

もう一つ、重要な教訓。

【CHAPTER 4 「ギリギリまで力を発揮させる」より引用】

■相手に矢印を向ける人は成長しない

先にお伝えした通り、上司が持っていた仕事を部下に任せると、部下には大きなストレス負荷がかかる。能力以上の仕事にチャレンジする部下は思い通りにならない仕事にイライラを感じるのだ。これを心理学の言葉では認知的不協和と呼ぶ。

これは前にも説明したが、そのイライラを解消する時に常に選択肢は二つある。一つは自分に矢印を向ける方法。つまり、問題の原因を自分にあると考え、自分を変えることで問題を解決しようとするアプローチだ。これを選ぶ部下は成長していく。仕事を任せたかいがある、というものだ。

しかし、もう一つの選択肢を選んだ場合はそうはいかない。それが他人に矢印を向けるという方法だ。
「目標達成できないのは不景気のせい」
「期限内に提出物を出せないのは、仕事の量が多すぎるから」
「チームの目標達成率が低いのは、人員を補充してくれない人事部のせい」

そうやって問題をすべて他人のせいにすることで自己正当化する。自分は悪くない、悪いのは他人だ、と言って必死に自分を守るのだ。

当たり前にことではあるが、このタイプの人は成長しない。自分は変わる必要がない。すべては他人が悪いと思っているからだ。

【引用終わり】

相手に矢印を向けずに、「自分に矢印を向ける」ように指導する、これが難しい。どうすればいいかを考えるのも自分の仕事だ。

「部下に任せないとダメだ」と考えさせられる一冊

2011-06-12T18:38:00.000+09:00

いま『任せる技術』という本を読んでいる。プレイングマネージャを自負している方には是非読んでいただきたい一冊だ。まだ最初の方だけしか読んでいないが、とても心に響いている。

【CHAPTER1 ムリを承知で任せるより引用】

そもそも部下の仕事とは「今日」の食いぶちを稼ぐことにある。一方で上司の仕事とは「今日とは違う明日」をつくることである。例えば、業務フローを標準化し改善する。営業戦略を立案し実行する。未来のビジョンを策定し部下を勇気づける。部下育成をする。これまでとは違うやり方を示し、より良い未来へ踏み出すのだ。

部下の仕事を奪っている上司は、これを怠っているということになる。目先の忙しさにかまけて本質的な上司の仕事を一切していないことになるのだ。先に掲げた「高い給与で部下の仕事を奪うこと」が目に見える損失だとすれば、「今日とは違う明日」づくりを放棄するということは目には見えない大いなる損失と言えるだろう。

【引用終わり】

耳が痛い。著者の小倉広氏は組織人事コンサルティング畑の方で、エンジニアではないが、技術者の上司と部下も同じことが言えるだろう。

小倉氏は上司が部下に仕事を任せない理由として次のようなことを挙げている。

部下に任せて失敗することを恐れている。上司の責任になってしまうのが恐い。
部下に任せることで仕事の質が下がり、部署全体の業績が下がることを恐れている。
部下に任せるためには手取り足取り教えなければならない。自分がやった方が早い。
部下に教えられるほどにノウハウが整理体系化されていない。
口べたであり、うまく部下に教えることができない。
部下が自分の仕事が増えることを嫌がり、場合によっては任せられることを拒絶する。
仕事を部下に任せることにより職場にストレスがたまり雰囲気が悪くなる。
部下に仕事を任せることで、上司が楽をしているのではないかと疑われるのが恐い。
上司自身が忙しくなることに快感を覚え、仕事を部下に渡したくない。
部下に任せることによるわずかな品質低下が許せないほどに上司が完璧主義者である。
部下に仕事を任せたいと思っているが、何をどこまで任せていいのかわからない。

まさに図星だ。自分の場合「部下に任せることによる品質低下が最終的に顧客満足を低下させることにつながらないか？」という恐怖が強い。しかし、そのことは自分が戦列を離れたときの顧客満足度の低下については考慮していないということになる。

「自分がいなくなったら？」「そんなことは知ったこっちゃない」ということになり、きわめて自己中心的であり、組織力を弱体化させ、結果的には顧客満足も下げてしまうことになりかねない。

【CHAPTER2 ムリをしなければ脳の筋肉はつかない　より引用】

「小倉さん、今の仕事にやりがいが感じられないのです。転職すべきかどうか迷っています。アドバイスを下さい」と言うのだ。なぜ、やりがいがないの？　と聞くと返ってくる答えは2種類に大別される。

1つ目は「今の仕事が自分には向いていない」というものだ。例えば営業をやっている人は自分には営業は向いていない、と言う。本当にそうであるかは大いに疑問が残るのだが。

2つ目の理由は、「上司や会社に問題がある」というものだ。職場に問題があり、上司に直訴しても変わりそうにない。だからあきらめて転職する、と言うのだ。

僕はその2つを聞くたびにこう思う。

「その状態でどこへ転職しても、絶対にやりがいは見つかりませんよ」と。

「やりがい」とは、楽ちんな仕事を通じては手に入らない。「やりがい」は壁を乗り越えた向こう側にあるものだからだ。決して壁の手前にそれはない。様々な障害やつらさを乗り越えたときに初めて僕たちは「やりがい」に出会い、それを手にすることができる。しかし、先に相談してくる人達のほとんどは壁を乗り越える前に逃げ出そうとしている人ばかりだからだ。

【引用終わり】

部下のモチベーションは維持しなければいけないし、ムリもさせないと基礎体力がつかない。自分自身は若いことムリをした経験がある。今の若い人達には「ムリをさせろ」ということ自体がムリという人がいるが、小倉氏が書いていることはその通りだと思う。障害やつらさを取り越えないで「やりがい」に出会えることなどない。

【CHAPTER3 部下が失敗する「権利」を奪うな　より引用】

失敗が喉の渇きを引き起こす

なぜ人は「任される」と育つのだろうか。

もちろん答えは一つではない。任されるから主体性が育つ。任されるからモチベーションが高まる。任されるから期待が伝わりそれに応えようとする。様々な要因があげられるだろう。

しかし、それらの中であえて一つを選ぶとするならば、僕は真っ先に「失敗の経験」をあげるだろう。つまり「任される」ことで初めて「失敗」を経験し、「失敗」により人は多くを学ぶのだ。「失敗」すれば痛みが伴う。そのとき初めて人は「失敗したくない」と心から思う。「うまくできるようになりたい」と切望する。つまりは、うまくやるための方法という「水」を求めて「喉が渇く」のだ。

そして様々な「試行錯誤」を行う。自分の頭で考えて「工夫」する。やがてうまくいくやり方を見つける。そこで見つけた方法をゴクリと飲み干すのだ。そうして全身にそれをしみ渡らせる。それを繰り返すことにより体で覚えていくのだ。

【引用終わり】

この話を、ソフトウェア開発の世界に投影してみると、何しろ今は「失敗させる機会」が少ない。「渇きを引き起こす」だけの「失敗の経験」を与える機会がない。また、ソフトウェアは失敗作でも一見動いてしまうこともあり、それが失敗であると気づかずに先に進んでしまうこともある。

さらに、大規模プロジェクトでは自分の作ったソフトウェアに失敗（＝バグ）があることを自分ではなく、後工程のメンバーが見つける責務を担っていることもある。作りっぱなしで失敗を見つけるのも他人という環境では渇きが起こらない。

自分の場合は「渇き」は「今よりも美しいソフトウェアを作りたい」「より楽に、より高品質で、クリエイティブな仕事がしたい」という気持ちから生まれていたと思う。

「失敗の経験」により「渇きを引き起こす」ためには、この本のタイトルどおり任せる技術が必要そうだ。「渇きを引き起こす」どころかやる気がなくなってもまずい。

失敗しないように手取り足取り教えてしまうと任せたことにはならず、「渇き」にはつながらない。

コンピュータではなく相手が人間だとこれほどまでに物事をうまく進めるのが難しい。もっと、この本を読み進める必要がありそうだ。

「それは仕様です」とは絶対に言ってはいけない

2011-05-14T19:33:00.000+09:00

浜岡原発の停止に際して、中部電では「（対策が済む）２年後に本当に再開できるのか確証がほしい」（中部電幹部）と、政府に何らかの保証を求めるべきだとの意見が出ているという。

これを聞いて「ああ、やっぱりそういう考え方をする人はいるのだな」と思った。こういう発言をする人はリスクマネジメントの本質が分かっていない。

リスクに対する保証というと生命保険や損害保険などの金銭的保障がすぐに思う浮かぶが、多くの人の命が関わっている場合、話しはそう簡単ではない。

人の命に関わるようなハザードの発現を、防げるのに防ぐための対策を取っておらず、金銭的な保障で備えるという選択肢はない。

よって想定したリスクに対して、リスクを分析しリスクコントロール手段を講じる必要がある。そのときにリスクコントロール手段によって100%リスクを回避できれば、それに超したことはないが、ほとんどの場合は100%のリスク回避などできないため、リスクコントロール手段によってリスクが受容できるレベルまで軽減されているかどうかを確かめる必要がある。

そこに保証という概念はない。リスクコントロール手段を講じる当事者ではない者は誰も保証などはできない。世の中にはそれが分かっていない人が大勢いる。

例えば、契約書や取扱説明書に禁忌・禁止事項を記載して、それをよく読まずに実行してしまったらそれはユーザーの責任だという人がいる。それは正しいが、現代のリスクマネジメントの考え方からすると正しくない一面もある。

社会通念上ユーザーがやってしまっても不思議ではないことに対して、契約書や取扱説明書に禁忌・禁止事項が記載してあったとしても、事故が起これば機器の製造業者やサービス提供者は社会的責任を求められる。

刑事裁判では勝訴しても、民事裁判では負ける、もしくは裁判には勝っても社会的な制裁を受けて、会社は潰れる。そんな事件は世の中でしょっちゅう起こっている。

さて、リスクコントロール手段によって事故の発生を誰も保証してくれないのならば、どうやってGO か STOP かを判断するのか。

それは一にも二にもリスクコントロール手段にの有効性の根拠による。GO か STOP かを判断した結果ではない、根拠が大事なのだ。

よく、クリティカルデバイスのリスクマネジメントに関する判断で最終的な結果を求めてくるエンジニアがいる、というか、ほとんどがそうなのだが、そういうときは最終判断の案と共に判断の根拠を必ず伝えるようにしている。自分がエンジニアに聞きたいのは、結果を受け入れるかどうかよりも、その根拠に同意するのかしないのかだ。

何も考えずに、結果だけを受けているのだけは絶対やめてくれと常に言っている。大事なのはリスクが軽減できると考える根拠だ。もちろん、客観的な証拠、統計的なデータに裏付けられた根拠に基づいた判断がベストだが、ソフトウェアの場合は障害の特徴がランダムではなくシステマティックでることが多いため、客観的な根拠だけではなく、エンジニアの自信の大きさで判断をすることも少なくない。

冒頭の中部電の「（対策が済む）２年後に本当に再開できるのか確証がほしい」（中部電幹部）と、政府に何らかの保証を求めるべきだという意見は、その観点から考えると保証だけを求めていて、「リスクコントロール手段に対して自分達はまったく自信がありません」と言っているのと同じだ。

本来ならば、「これこれのリスクコントロール手段と根拠となるデータを用意したので、これで判断して欲しい」と言うのは正しい。

リスクが受容できるかどうかは、どんなリスクを想定し、どんなリスクコントロール手段を用意し、どんな根拠によるのかを説明しないといけないのだ。

そして、それは誰も保証はしてくれない。ユーザーが納得するかどうかは機器やサービスを提供する側がどれだけ客観的なデータを使って、自信を持って説明できるかどうかにかかっている。

そのことが分かっていないエンジニアやマネージャが多いと感じる。ある講演で自分は「レビューの席で技術者が“それは仕様です”という台詞を発すると心底むかつく」と言った。

実際そのとおりで、「それは仕様です」という言葉は「私はまったく何も考えていません」と言っているのと同じであり、自分はそういう発言をする者はなぜそうなっているかという根拠を説明できない最低のエンジニアだと思っている。

リスクマネジメントでもまったく同じであり、誰かに保証して欲しいという発言は、自分はリスクコントロールに関して何も考えていませんというと言っているのと同じだから、絶対に言ってはいけないNGワードなのだ。

是正・予防駆動のプロセス改善アプローチ

2011-05-08T20:40:00.000+09:00

ソフトウェアの開発をし商品に実装し、その商品を売って対価を得て、最終的にサラリーをもらう。ソフトウェアの一行一行の向こうには、そのソフトウェアを使うユーザー（お客様）がいる。それが医療機器などのクリティカルソフトウェアであった場合、そのソフトウェアは利用者の命を左右する可能性もある。

クリティカルでなくても、危険なエネルギーを制御したり、大切な情報を扱ったり、重要な設備を管理したりするソフトウェアもある。

ようするに職業としてソフトウェア開発に携わっている技術者はユーザーに対して何かしらの責務を負っている。これは、ソフトウェアがハードウェアと違うのは、Systematic Failures/Faults（決定論的原因故障/障害）と呼ばれる障害が多いことだ。Systematic Failures/Faults（決定論的原因故障/障害）は出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。

故障や障害がランダムに発生せず、ある複雑な特定のシーケンスを実行すると必ず発生する故障や障害、それがSystematic Failures/Faults（決定論的原因故障/障害）だ。

Systematic Failures/Faults（決定論的原因故障/障害）は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去する。

そして日本人は開発のプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去のが苦手だ。

どちからというと、問題が発生した時点で修正し、個人個人が是正・予防する方が得意だ。だから、プロジェクトメンバーが入れ替わらなければ、是正・予防を繰り返すことで設計の規範が醸成され、そのプロジェクトからアウトプットされるソフトウェアの品質は徐々に上がっていく。

ところが、最近ではソフトウェアの開発をどんどんアウトソースしてしまうので、ソフトウェアの委託元では設計の規範どころか設計技術自体が醸成されないし、アウトソース先は人が入れ替わるため、是正・予防を繰り返す方法ではソフトウェアの品質は上がっていかない。

日本人が苦手な、Systematic Failures/Faults（決定論的原因故障/障害）をプロセス（工程）、ライフサイクルの中で作り込みを防止し、検証や妥当性確認によって発見・除去するしかない。

しかし、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャなどは感覚だけは昔のままなので、気がついたら修正し、個人個人が是正・予防するマネージメント以外の成功体験がなく、プロセスアプローチによってソフトウェア品質が高まるというイメージがわかない。

その結果、Systematic Failures/Faults（決定論的原因故障/障害）は増加する一方で、昔気質のソフトウェアプロジェクトリーダーやハードウェア出身のプロダクトマネージャはいらだつ。

これが今多くのソフトウェアプロジェクトが抱える悪循環の構図だ。

このままでは、ソフトウェアを使うユーザー（お客様）への責務が果たせない。ではどうすればいいか。

ひとつの解決策として、トップダウンでプロセスアプローチにシフトするのもいいが、日本人の得意な是正・予防で改善を進めるというのはどうだろうか。

問題が起こったら、関係者全員で問題が発生した原因を分析し、どうやったら予防できるのかを考える。これを進めていくと、当然のことながらソフトウェア開発の上流を改善しなければいけないことに気がつく。結局、プロセスアプローチを導入するという結論に至ると思うが、人から押しつけられるのではなく、改善の取り組みの中でプロセスマネージメントの重要性を学ぶ方が日本の技術者には合っていると思う。

問題が起こったときに、エンジニアを責めるのはたやすい。難しいのは問題の原因を分析し、是正、予防し、同じような問題が起こらないようなオペレーションを決断することだ。

結果を批判するだけの評論家はたくさんいるが、未来に起こるかもしれないリスクを皆に知らせ、プロジェクトを止めたり、方向を変えたりするには技術的な裏付けもいるし、何よりも勇気がいる。

ユーザーの顔を思い浮かべて、ユーザーリスクを防止するための決断ができる者こそ、プロジェクトのリーダーとなるべきだと思う。

事故の再発を防止する技術

2011-03-27T17:56:00.002+09:00

3月8日の金曜スーパープライム「池上彰くんに教えたい10のニュース」のラストで3月一杯でTVの仕事から離れる池上彰氏が、「自分が生きている間にベルリンの壁が崩れるなどとは思っていなかった。チュニジアのデモからエジプトのムバラク大統領の退陣までこんなに早いとは思わなかった。時代の変化は早くなっている。今流れているニュースはいずれ歴史になる。そういう目でニュースを見なさい。」と言って去って行った。

3月8日は東日本大震災が起こる前だったから、想像もできなかっただろうが、まさに日本で流れているニュースは今後、歴史に刻まれることになる。

そう考えると、今、乗り越えなければならない問題の解決のプロセスは現在だけのことだけではなく、未来から見た歴史になるという意識で対峙しなければいけない。

品質マネージメントの観点から考えたときに、問題が起こったときに重要なのは、同じような問題が起こらないように予防と是正を行うことだ。

品質をマネージメントする技術者はCAPA （Corrective Action and Preventive Action：是正・予防措置）に注力を注がないといけない。問題が起きたときに犯人を見つけて責任を追及することは容易だが、再発防止の取り組みを築き上げるためには技術もいるし、組織的なマネージメントもいる。

再発防止を実現するためには、何よりもまして、同じ問題を起こしたくないという強い意志がエンジニアやマネージャになければいけない。

日々のビジネスシーンでは、QCD（Quality, Cost, Delivery）のうち、コストや納期が品質よりも優先される、優先しろという指示、圧力がかかることが少なくない。真の技術者は製品やサービスにおいて当たり前にできていることの技術、その品質を維持することの難しさをよく知っている。一方、製品やサービスを表面からしか見ていない者は当たり前にできていること＝潜在的な価値の重要性を常に意識することができない。

潜在的価値が意識されるのは、当たり前品質が当たり前でなくなったときだけだ。すなわち当たり前できているはずのことが、できなくなり故障、障害、事故が起きたときに当たり前品質の重要性と、その潜在的価値を支えている技術が十分出なかったことが分かる。

このときに、組織や社会が認識しなければいけないのは、当たり前にできていることの裏にある技術や、どんなリスクを想定し、どんなリスクコントロールをしているのか、していなかったのかというリスク分析である。そして、品質マネージメントのプロセスに従い、CAPA （Corrective Action and Preventive Action：是正・予防措置）を実施する。そのとき、技術者やマネージャは同じ故障、障害、事故を起こさないという強い意志を持たなければいけない。

エンジニアは事態の収拾でホッとするのではなく、再発防止の取り組みに力を注ぎ、組織はQCD（Quality, Cost, Delivery）の Quality を軽視しない、コストや納期を優先させて品質への意識を忘れてはいけないことを心に誓う必要がある。

実際には、Quality, Cost, Delivery の間にはトレードオフの関係があることが多い。納期やコストを優先させると品質が低下する可能性は高い。しかし、技術力によって QCDのバランスを確保することは可能だ。

例えば、商品群のコアとなるソフトウェア資産を抽出し再利用可能な管理ができれば、品質とコストと納期の要求を満たすことはできる。ソフトウェアプロダクトラインの技術だ。このとき、医療機器などのクリティカルデバイスにおいては、機器を取り巻くリスクに対して、そのリスクを受容可能なレベルまで引き下げるリスコントロール手段（設計上の対策）がコア資産に含まれいるとなお、その資産価値は高まる。（コア資産の顕在的価値と潜在的価値の両方を含めることができるとなお良い）

そのソフトウェア資産の安全性や信頼性を高めることに注力を注ぎ、その後何世代にも渡ってコア資産を再利用することができれば、QCD の要求を同時に満たすことができる。

クリティカルデバイスの開発は、失敗や事故との闘いであるとも言える。失敗や事故を再発されないためのノウハウを製品につぎ込み続けることが当たり前品質を高めることにつながる。だから、新規参入が難しいとも言える。ただし、大規模複雑化したソフトウェアの場合、単純に安全装置としてのソフトウェアを追加し続けると、これまで正常に動いていたシステムをデグレードさせてしまうこともあるから注意が必要だ。

ハザードやリスクがどう変化したのか、見落としていたのかを再評価し、リスクコントロール手段を要求としてとらえ、実現するアーキテクチャを設計する。日本人はこの設計上流の分析や設計がとても苦手に見える。試行錯誤で付け足しや修正をするのは得意だが、上流に立ち戻って再設計するのは下手だ。

障害や事故を再発されないという強い気持ちとリスク分析、リスクコントロールのアーキテクチャ設計ができないとないと、障害や事故はまた起こる。気持ちだけでもダメだし、技術力がなくてもダメだ。

そして、是正・予防措置は、気持ちだけでは進まない、組織に品質マネージメントを仕組みを根付かせ、日々前向きな気持ちで回していなければできるものではない。

そして、ジャーナリズムにお願いしたいのは、障害や事故が起きたとき、その後組織が再発防止の取り組みを続けているかどうかを監視することと、今は起こっていないが何かあったら大変なことになる社会インフラ、重要デバイスに問題が起こったらどうなるのかという視点を持ってもらうことだ。

何か起こってから追求するのは誰でもできるが、これから起こるかもしれない障害、事故を防ぐためには経験や知識、幅広い視点が必要になる。ジャーナリズムには事故を未然に防ぐ技術やマネージメントについての報道を期待したい。

安心・安全を担うソフトウェアを実現するには

2011-03-20T20:36:00.000+09:00

東北関東大震災で被災された皆さまにお見舞い申し上げます。

このブログで自分自身の業務ドメインについてクリティカルデバイスのソフトウェア開発を行ってきたと書いてきました。クリティカルデバイスとは医療機器のことです。これまで、ブログの記事投稿や外部における発表において自分が所属する業務ドメインを明らかにしてこなかったのは、サラリーマンであるにも関わらず、25年間務めている現在の組織のノウハウを漏らしているかのようなあらぬ疑いをかけられるのがいやだったからです。

しかし、今回の震災に東京地区で遭遇し、さまざまな苦難に多くの日本人が自分ができることを考えているのを見て、自分が社会に対してできるのは医療機器ソフトウェア開発で得た経験により、安心・安全を担うソフトウェアはどうすれば実現できるのかについて情報を発信することだと思いました。

もちろん組織内の情報を外に出すことはこれまでも、これからもありませんが、組織の利益以上に、社会への貢献について自分ができることを考えていきたいと思っています。

さて、東京電力福島第一原子力発電所の事故を見て、多くの方達は「なぜ、今回のような事態が起こることを想定しなかったのか」と思われているでしょう。

私は、商品やサービスの価値には「顕在的な価値」と「潜在的な価値」の両面があると思っています。「潜在的な価値」は当たり前品質と言い換えることもできます。できていて当たり前なので、何かのアクシデントが起こると「潜在的な価値」がとたんにクローズアップされます。

世の中の多くの商品やサービスでは表面に表れている「顕在的な価値」、例えばカタログに掲載されているようなスペックに消費者は着目しますが、「顕在的な価値=当たり前品質」に着目する人はそう多くないと思います。

しかし、私のような医療機器のドメインや社会インフラを実現している産業ドメインでは、この「顕在的な価値=当たり前品質」を軽視することは絶対にできません。なぜなら、そこに問題が起こるとお客様に多大な迷惑をかけたり、最悪の場合、健康被害をもたらしてしまう可能性があるからです。

そうならないために、私たちはリスク分析をし、ユーザーリスクを軽減するための対策をハードウェアやソフトウェアにインプリメントするのですが、それでもさまざまな問題は発生します。そして、リスクをコントロールすること以上に重要なのは、問題が起こってしまったことに対する原因の追及と同じ過ちを繰り返さないように是正し、予防する処置を行うことです。

エンジニアは顕在的な価値を高め、期せずして発生してしまった問題に対しては冷静に再発防止の対策を粛々と実行しなければいけません。

日本のエンジニアは長い間同じ商品開発に携わることが多いため、安全や信頼を実現するためのノウハウが技術者個人に蓄積しやすいと感じています。この状況は開発するソフトウェアの規模が小さく、複雑でなく、かつ技術者の安全実現への熱意が強い場合には有効に働きますが、実行コード行数が30万行を超え100万行以上の規模になったソフトウェアでは有効ではありません。

ソフトウェア開発プロセスを組織的に管理し、品質マネージメントシステムのもとで是正、予防も実施していかなければいけません。長い時間エンジニアの熱意や責任感と職場内で継承されてきたノウハウで安全を確保してきた日本のプロジェクトには開発プロセスで品質を確保するというアプローチは受け入れがたいことでもあります。（建前では受け入れつつも本音では役に立たないと思っている者は多いと思っています）

習慣化してしまった日々の仕事のやり方はそう簡単には変えることはできません。そして、プロセスアプローチを強固に推し進めてきた欧米の製品よりも、日本製の製品の方が品質が高いというケースも少なからずあります。しかし、その状況は長くは続きません。ソフトウェアの規模や複雑性が増大し、機器同士がネットワークでつながるようになると、これまでうまく回ってきた日本的なアプローチは徐々にほころびを見せてきます。

しかし、だからといって技術者の安心・安全実現に対する熱意なしに、クリティカルデバイスの品質確保はできないと思います。日本的なアプローチと欧米的なアプローチの両方を推し進めることで、安心や安全が確保できるのです。

話しは変わりますが、2011年2月10日に「ソフトバンク医療分野におけるスマートフォン活用に関するセミナー」、2011年2月28日日経ものづくり主催の「医療機器開発の勘所」セミナーに参加しました。

前者は、医療分野において、iPad や iPhone などの IT機器を導入して、実際に活用している例を、後者は、グローバルマーケットにおいて日本から世界に医療機器を開発・販売していくためにはどのような責務を果たさなければいけないのかについてのレクチャーでした。

IT（ソフトウェア開発の意味も含む）は確実に医療の世界をより便利に、より効率的にすることができると感じました。しかし、使いやすさ、便利さといった顕在的な価値の後ろで、潜在的な価値=当たり前品質を維持し続けなければ、機器やシステムを安心して使うことはできません。

安全や安心にはコストがかかります。私たちは安全や安心のためにそのコストを負担しますが、特に日本人は消費者として厳しい目を持ち、その上で安全や安心に対するコストを支払います。安全や安心にかかるコストを値切ったりすることは少ないと感じています。

だからこそ、安全や安心を担うソフトウェアを開発しているエンジニアはその期待を裏切らないようにいい仕事をしなければいけないのです。私は、最近の技術者は納期のプレッシャーに負けて、安全や安心に対する責任から逃げたいと思う弱い気持ちが大きくなっているように思えてなりません。

そういうときに、私は「何のためにこの仕事をしているのか」ということを技術者に問うようにしています。消費者の皆さんには無理なお願いかもしれませんが、日頃、何事もなく動いているシステムを見たら、「これはどうやって動いているのだろうか」と気に掛け、何事もなく動いて役に立っているシステムを見たら、それらのシステムを作り上げた誰だか分からぬ技術者達にほんの少し感謝の気持ちを持って欲しいのです。

そのほんの少しの感謝の気持ちが技術者のモチベーションを高め、安心・安全をさらに強固にするためのインセンティブになると思っています。

私自身はそのようなシステムを実現するために、日本の技術者やプロジェクトが何をすればよいのかについて、自分自身の25年の医療機器ソフトウェア開発の経験を元に情報発信していこうと思います。

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

2011-01-30T21:28:00.000+09:00

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

【番組ホームページより】

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

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

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

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

詳しくは Wikipedia を見ていただきたいのだが、以下の一節だけ読んでもすごい経歴だ。

東京都小平市で、新聞社勤務の父と小学校教諭の母の間に生まれる。1988年に武蔵高等学校卒業後、1浪して東京大学に入学。児童養護施設のボランティアや映画鑑賞にのめりこんで授業にはあまり出席していなかったが、5回生の夏に一念発起し学者を志して勉学に集中、一時的にボランティア活動から離れた。

さてさて、肝心の『課外授業　ようこそ先輩』の内容に進もう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2011-01-19T21:12:00.001+09:00

クルマ関係の仕事をしている技術者は日経エレクトロニクス　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点に集約されている。

安全性の規格でありながら、定量的な故障検出率といった確率論に重きを置きすぎている。
故障率低減のための複雑な機構の導入が、かえってシステム全体の安全性を損なう危険性に配慮していない。
部品ごとに安全性の認証を与え、認証を得た部品の採用によって安全を担保しようとしている。
バックグラウンドとなる理論的体系や支柱がなく、規格が膨大で分かりにくい。

あー、それだ。そう、何年も前から自分はこの規格を読んでいてそう思っていたのだ。特に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 （決定論的故障）といった問題の起こし方をする。想定しきれなかった、テストしきれなかったバグによって問題は起こる。そのようなバグを完全にゼロにすることはソフトウェアの場合困難であると認識しつつ、ハザードが発現しないためにはどうしたらよいのかを考え、できるだけ完全に近づけようと努力する。

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

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

NHKの「就職難をぶっとばせ！」を見て

2010-12-26T18:59:00.001+09:00

2010年12月25日クリスマスの日にNHKで『日本の、これから「就職難をぶっとばせ！」』という2時間の討論番組がオンエアーされた。

もちろん、超氷河期と言われる就職活動がテーマなのだが番組を見終わって、これは学生の就職という限れれた範囲の問題ではなく、日本の社会全体の問題だと思った。学校で何を教えるのか、企業はどのように人材を採用し、そして社会はどのように人材を流動させる必要があるのかといった社会構造の変革時期に来ているということがよく分かった。

番組は三宅民夫アナウンサーが進行役で進み、就活中の学生（内定あり、就職のための留年を決めた人、既卒者など）や、経営者、人事担当、高校の先生、就職した先輩などが集まっていた。

ゲストは、下記のような方々で、勝間さん、海老原さん、宮本教授がそれぞれの持論を披露し、それについてディスカッションをした。

文部科学副大臣…鈴木寛，株式会社クラレ代表取締役会長…和久井康明，東京大学大学院教授…ロバート・キャンベル，経済評論家…勝間和代，株式会社ニッチモ代表取締役…海老原嗣生，放送大学教授…宮本みち子

勝間さんは次の2点を主張していた。

1. 日本の企業は新卒一括採用をやめて、アメリカのように不定期にエントリーレベルから採用したり、インターンシップによる採用をすべきだ。
2. 企業が社員を解雇しやすくする（=もっと人材を流動しやすくする）ように、セーフティネットを準備し、解雇された後の職業訓練や雇用手当を充実させる。

議論の中で重要だと思ったのは、日本の企業が新卒一括採用をする際のメリットについてである。企業側は新卒一括採用によって、新入社員研修をまとめて実施することができ、かつ、「同期」の意識を高めることで、同期同士での助け合い、競争、情報の共有といういろいろなメリットが生まれるということだった。ようするに企業は新卒一括採用によって新入社員教育のコストを抑えることができるということだった。

しかし、考えてみればアメリカのエントリーレベルのプログラマなどは年収200万円くらいだと聞く。そんな低賃金で雇えるのならば、不定期に個別トレーニングを受けさせてもコストアップにはならないだろう。

問題は、日本式で何十年もやってきた日本の企業がアメリカ式の雇用スタイルには簡単には変われないということだろう。司会の三宅さんは、番組の最後の方で「我々団塊の世代は、小中高大と学校を通り過ぎ、企業に就職して定年まで勤め上げるという、レールに長い間乗ってきた。今、このレールを降りなければいけない時代に来ているようだが、果たして降りられるだろうか。」と言っていた。

まさにそのとおり。日本人が高度成長期にやってきてうまくいっていたシステムを変えるためには、危機感がなければ変わるわけがない。右にならえでやってきて大きく失敗しないでここまでこれたのになんでシステムを変える必要があるのだと思っている経営者や人事担当は山のようにいるはずだ。

でも、いろいろな方面で日本が世界の一番でなくなってきた今、ひとと同じことをやっていてはグローバルな競争には勝てない。韓国や中国やインドの企業に負けて、仕事がなくなって今のポジションを守ろうと考える社員が多くなり、会社が潰れたり、合併されたりしてから問題に気がつく。

どうも、これまでの日本では周り同業他社を見渡しながら同じようなことをコツコツをやっていれば、なんだかんだいって売り上げは上がっていったらしいのだ。国全体が成長期にあったから、そうだったのだが今は違う。今は、日本の中でそんなことをやっていても、同業のアジアの会社には勝てないし、変化のスピードが早いので海外他社の成功を見てから真似しても間に合わない。その状況に日本人の多くが気づいていない。別な番組で、日本にいると SAMSUNG の驚異はあまり感じないが、東南アジアや中東、南米などに行くと明らかにSAMSUNGの台頭に驚くという。日本の平和ぼけは経済においてもボケのようだ。

新卒一括採用という制度は護送船団のように見える。人事部門は他の会社がやっていることを真似していれば大きな失敗もなく、経営者から怒鳴られることもない、学歴で学生を選ぶからひどい人材を採用する危険性も低いが、飛び抜けてユニークな大きな組織貢献をする可能性のある人材の採用もできない。そこから脱することもできるはずなのにみんなが周りを見渡して顔色を伺っているから、だれも動かない。

もう一つ、人材コンサルタントの海老原さんは、学生や親は大企業ばかりに目を向けないで、世界でも有数の技術を持つ中小企業などを探しなさいと主張していた。中小企業が学内でちょっとした飲み会のスポンサーになって、学生と直接話しをする機会を設けたらどうかという話しもしていた。マスコミを通すと中小企業の良さが伝わらないから、直接話しをする機会をできるだけ多く作ろうとう提案だ。

実際、今の学生は大手指向が強く、自ら狭き門に殺到している。従業員数1000人以下、300人以下という企業なら求人倍率は1倍を遙かに上回っている。

日本だけでなく、世界でのシェアも高い卵の選別をする機械を作る会社などは、せっかく採用したのに親に「そんな会社は聞いたことがないのでやめておきなさい」と言われ、内定を辞退する学生が少なからずいるらしい。だから、今では親子に対して会社の説明をする説明会をやるのだとか。

この問題提起に対するディスカッションで、大企業は安定しているし、何はともあれ就活サイトでは大企業の情報しか載っていないという話しがあった。優良な中小企業の情報自体が得られないというのだ。

コメンテーターから毎日新聞各紙を読んでいれば、中小企業の情報も入手できるという指摘があった。自分もそう思う。新聞だけではない、インターネットや業界のニュースサイトからだって情報は得られる。興味のある業界が特定されているのなら、業界新聞やその職種のひとが書いているブログを読むことだってできる。

今なら、PCの前に座って各方面の情報を探ればいくらでも情報は得られるのに、やっていないだけなのではないだろうか。誰かに情報の検索方法を教えてもらっていないから、他の学生はそんなことやっていないからしないのだろうか。

就活サイトという与えられた枠の中だけでしか情報を探していないのではないだろうか。これも右にならえ症候群の影響だろうか。

討論会の中で、就活学生はリスクについて考えた方がよいという話しがあった。大企業に就職した入社二年目の社会人の方がいて、同期が500人もいると自分がやりたい職種があっても希望どうりになる可能性は低い、大企業では会社に入ってからも競争が続くと言っていた。それが大企業のリスクだ。中小企業なら、社長と直接話しをする機会も多く、自分がやりたいことを主張すればその心意気を汲んでやらせてくれる可能性もある。英会話の能力を活かしたいと言えば、海外シェアの高い優良中小企業なら即海外営業担当になれるかもしれない。そこで自信がないと言うようではチャンスは巡ってこない。ただし、給料は安いかもしれないし、もしかしたらブラック企業かもしれない。それが中小企業のリスクだ。

どっちのリスクを取るのかだ。もしも、今自分が就活する学生なら、絶対に大企業のリスクは選択しない。ブラックでない将来性の高い中小企業を探して就職し、やりたいことを思いっきりやって、スキルが徹底的に伸ばし、もしも、その会社の器をはみ出しそうになるくらい成長したら、その実績を引っさげて別の会社に転職する。

討論会の中で悲痛の叫びを口にする学生さん達を見ていて思うのは、彼らは完全に「就職できないかも知れない」という恐怖におびえているということだ。そして、その恐怖を振り払うための方策として、受験勉強で使った方法を使おうとしている。

つまり、中学二年の間に中学三年生までの教科を終わらせて、中学三年生の期間は受験対策をする。大学1,2年から就職活動を開始し、4年生になったら面接のための塾に通ったりする。ようするに高校、大学の難関校を受けるときの戦略そのままだ。

企業には偏差値は付いていないから、よくコマーシャルや全国ニュースに出てくる大企業がいい会社だと考える。

この戦略の大きな間違いは、皆が同じ土俵で闘おうとしている点だと思う。共通テストや私立大学の入学試験は公正を期すために、できるだけ同じ土俵で学生達を闘わせようとしているが、企業は別に同じ土俵で闘う必要はないし、同じでないからこそ生き残れる世界もたくさんある。それなのに自ら競争相手の多い土俵に登りたがる心理が自分には理解できない。

一つは他の人が着目していないような優良な土俵を探すこと、つぎにその土俵で自分が勝つためには何をしなければいけないのかを考えることだ。どちらもひとと同じことをしていたらダメで、ひとがしていないことで自分のやりたいこととのオーバーラップを探す必要がある。日本ではそういう訓練はしてこなかったのだろう。

一昔前は大学への進学率は10～20%。今では50%を越えている。昔は、大学は学問を学びたい者が行っていたのだが、今では大学は限られた若者がいくところではなくなっており、彼らを全部就職させるためには職業訓練的なこともしなければいけないというVTRがあった。

これに対して、大学がアカデミズムの立場を崩すのはよくないという意見があったが、東京大学大学院教授　ロバート・キャンベル氏が、どんな分野であれ、学び、議論し、改善を模索するという行為を大学で学び取ることができればムダではないと言っていた。自分はロバート・キャンベルさんの言うことが好きだ。50%が大学へ進学する時代なら、アカデミズムもあり、職業訓練もありにしなければ結局は不幸な学生がでてくる。

大学では何でもいいから勉強する対象を通して、深く掘り下げて考え、分析したり、理論を打ち立てたり、問題を解決する力を養って欲しい。

そして、変えなければいけないのは学生と親が持つ価値感だ。働くことの意味はなんだ？みんなが知っている安定した企業に就職することか？

20世紀の時代には大企業=安定の式はなりたったかもしれないが、21世紀ではまったく信用できないし、大企業のリスクも存在する。

「みんなと同じ」=「安心」「仲間はずれにならない」

という価値感はそろそろ捨てよう。親は子供に「友達と同じことをするな」「自分だけのオリジナリティを磨け」と言おう。みんなが黒のスーツを着ていたら、自分だけはグレーにしてみなさい。「なぜ、君はグレーのスーツなのか？」と聞かれたらラッキーじゃないか。

ひとと違うことを突き詰めるのは「自分にはムリ」と言うのならば、職業訓練をしよう。学生のうちに、企業が興味を持つ分野のエキスパートになってしまおう。それが自分の好きなことと一致していればそれに越したことはないが、絶対にイヤだというわけではないのなら、何かの道を選んで一流と言われるまでスキルを高めてみたらいい。

『日本の、これから「就職難をぶっとばせ！」』を全部見て一番バカだと思ったのは、世界のトップシェアの中小企業に内定をもらっていながら入社を辞退した学生とその親だ。

本当にその親の顔を見てみたいし、「聞いたことがない会社だから」という理由で断った学生も親も親なら子も子なのだろう。

番組キャスターの三宅さんも言っていたがこの問題は就活学生だけの問題ではない、今一度我々は自分自身に「何のために働いているのか」という疑問を問い掛けてみる必要がある。

そして、その答えと今の社会のシステムにズレがあるのなら、未来の日本をしょって立つ若い人たちのために変える行動をしなければいけない。批判したり、評論したりするだけではだめだ。何かしらの行動をしなければいけない。

行動できなければ、それはひかれたレールから降りられないということだからだ。だれもレールから降りないのなら、さびれたレールは残り続け乗客はいなくなり廃線になるだけだ。

さしあたり、自分ができるのは学生向けにこのブログを通して情報を発信して「みんなと同じ」症候群から脱出する方法を授けることかな。

やっぱり手帳がいい

2010-12-05T21:41:00.000+09:00

斎藤孝氏の著書『15分あれば喫茶店に入りなさい』には、喫茶店に持ち込んではいけないものとしてノートパソコンが挙げられているそうだ。

喫茶店の15分間という時間と空間を作るとアイディアが生まれるという。生まれるというよりは、アイディアを生むための時間を作るということだろう。

時間と空間を作るのなら家でも同じと思うかも知れないが、家には考え事をさせないような誘惑がたくさんある。喫茶店に入ってしまえばコーヒーを飲む間の時間は他のことはできない。

アイディアというものはふと思いついて覚えておけるだろうと思っていても、数時間もすれば忘れてしまうものだ。ということで自分はいつも手帳を持ち歩いている。

そもそも、PDA として SONY の CLIE を持っていたのだが、SONY のPDA市場からの撤退という裏切りとともに結局 PDA は使わなくなってしまった。 CLIE を使わなくなってから、もう一度原点に戻って手帳に切り換えた。この手帳にしてからもう5年になる。

今は iPod Touch があるけれど、これは手帳の替わりにはならない。ふと思いついたアイディアをささっと書き留めるには手帳が一番だ。この手帳を選んだ理由はカレンダーとノートだけのシンプルな作りで、透明のジップ付きのカバーにペンを入れられるからだ。値段も\1000円以下。毎年この時期になると東急ハンズに来年の手帳を買いに行く。

ただ、カレンダーは google カレンダーで情報をクラウド上に共有できるため iPod touch のカレンダーを使うようになった。でも、アイディアを書き留めるノートとしての機能は手帳にはまだまだ勝てない。

いろいろな電子機器を使うようになった今でも手帳は手放せないし、毎年来年の手帳を買いに行くということも考えようによっては楽しいことだ。

P.S.

SONY には CLIE では裏切られたが、薄型テレビの BRAVIA では感心している。起動時間が早い。Linux の立ち上がりには時間がかかっているがテレビを見るだけなら Linux の起動に関係なくすぐに見える。

同様にブルーレイディスクレコーダーの起動も「パッと起動！」とCMで強調している。ユーザーが本当に求めていることカタログスペックには出にくいことに着目して実現してくれた。今のDVDレコーダーの起動時間も遅くてうんざりしている。次に買い換えるときは SONY の Blueray にしようと思う。

新人と就活

2010-11-21T21:50:00.001+09:00

今年の新人達がプレゼンするのを聞いた。ものすごくうまい。本当に信じられないくらいうまい。最近は個人情報ということで、どの大学の何を専攻してきたのか、学卒か院卒かも公開されないからプロフィールがまるでわからないが、プレゼン慣れしているのは確かだと思う。

あまり人前であがらないというのは現代的な特徴かもしれないが、観客が自分をどのように見ているのかを客観的に把握できているように見える。

就活で鍛えたのだろうか？　最近の就職は非常に狭き門となっているらしく就職を控えた学生の諸君は大変だという話しをよく聞く。

『内定の出ない学生は何が間違っているのか～学生、企業、大学、親がすれ違う悲惨な現状』を読めば大変な現状が分かる。

しかし、日本の企業はどうして「新卒」にこだわるのだろうか。これまでずっと同じシステムでやってきたから、いまさら変えることに不都合があるのか。能力主義、成果主義に切り換えたといいながら、実は年功序列が実態なので新卒という枠を外すと問題が生じるのだろうか。

日本の企業は大学、新卒とう枠を設けることで、自分達が欲しい人材がどのような人間であって欲しいか考えることから逃れていると思う。

ようするに新卒であれば世代という観点では同じ評価指標で考えられる。その土俵で人選すれば選びやすい。ところが、新卒という条件を外したら、もっと評価指標が増えるし、また、どのような人材を求めているのかをもっと明確にしなければいけない。

その組織にあった人材ということだけではなく、今、不足している、これから始めようとする事業に有効な能力、ポテンシャルを持った人材を選らばなければいけなくなる。というよりは選べるようになるのだ。

キャリア採用と似ているが、キャリアは十分ではないだろうから、人材を必要とする事業やプロジェクトに投入する際にポテンシャルの高い人を探さなければいけない。今まで以上に人事部門が事業部門と情報を共有し、どんな人材が必要か常日頃からディスカッションしておかねければいけない。

新卒しか採用しないのは、人事部門が新卒という枠でしか技術者を評価できないからではなだろうか。

その組織に、その事業に、そのプロジェクトに必要な人材がどのような者か、どのようなポテンシャルを持っているべきかを考えられるようになれば、新卒にこだわる必要がない。

ちゃんとそのコンセプトを示し、いろいろな経験をした広い範囲から人材を選べるはずだろう。

プレゼンがうまいのがもしも就活のために訓練したのであれば、それもよいが、エンジニアとして組織が求めているポテンシャルが高いのかどうかはそれだけでは分からない。

就職する側の企業が変われば、大学の姿勢や受験も変わるのではないかと思う。現在の就職状況では、一芸に秀でた人材が埋もれてしまわないか、日本ではチャンスは新卒の一回しかないのかどうか心配になる。

ソフトウェア品質を高く保つには哲学が必要

2010-10-27T18:15:00.003+09:00

前回の記事『商品リスクを低減するには哲学的思考が必要』に関して、もう一回同じようなことを書いた文章がありますので、ご一読ください。

誰がどこに書いた文章かはご想像にお任せします。

------
明治大学理工学部に向殿政男先生という方がいます。

著書のひとつ『安全設計の基本概念』

向殿政男
1965年明治大学工学部電気工学科卒業。1967年明治大学大学院工学研究科電気工学専攻修士課程修了。1970年明治大学大学院工学研究科電気工学専攻博士課程修了。明治大学工学部電気工学科専任講師。1973年明治大学工学部電気工学科助教授。1978年明治大学工学部電子通信工学科教授。2005年経済産業大臣表彰受賞(工業標準化功労者)。2006年厚生労働大臣表彰受賞(功労賞)。明治大学理工学部情報科学科教授。明治大学理工学部学部長。明治大学大学院理工学研究科委員長。ISO/TC 199国内審議委員会委員(元主査)。安全技術応用研究会会長。機械の包括的な安全基準に関する指針の改正のための検討委員会委員長。次世代ロボット安全性確保ガイドライン検討委員会委員長ほか(本データはこの書籍が刊行された当時に掲載されていたものです)

その、向殿先生が、日経ものづくり 8月号で日本のものづくりの歴史的背景を次のように語っています。

【日経ものづくり 8月号特集ソフトが揺さぶる製品安全より引用】

信頼性一本やりでは厳しい

明治大学理工学部情報科学課教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いという。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。

「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障がバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だといえる。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）。

だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは厳しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。

そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。

【引用終わり】

この「今後の安全設計には全体最適の発想が必要であり、安全を定義するには社会が許容するリスクとは何かを組織が考えなければならず、そのためには哲学的判断がいる」、というところに強く共感します。

ようするに、ユーザーリスクとその対策は考えれば考えるほど際限がないので、コストや開発時間とのトレードオフでどこまでやるかを決断しなければならず、その決断をするためには安全や品質に対する哲学が必要だということです。

安全や信頼を実現している「当たり前品質」は、カタログやスペックシートには現れないため、長い間商品を使ってもらったときにお客様から伝わってくる「品質がいいね」という感想や、クレームの少なさなどでしか表面に現れてきません。

クリティカルデバイスではそこが命でもあるので、技術者は当たり前に出来ていることの重要性や、リスクを軽減する対策の大切さは言われなくても分かっていました。

それが、近年、リスク分析の結果や取扱説明書を見ていると、表記上の対策で禁忌・禁止事項として書いておけば、設計上の対策はいいやという技術者が増えてきたようにも感じています。そうなってきた理由のひとつは商品が実際に使われる現場の現実を知らない技術者が増えてきたからでもあります。

これだけ複雑化してしまった製品ソフトウェアに対して、安全に対して哲学を持ってどこまでやるかを決断しなければならなくなっているのです。逆に言うと製品の品質や安全に対して無知であったり、哲学（ポリシー）がない技術者が作る商品、ソフトウェアは危険であると言えます。

そして、技術者に哲学（ポリシー）があっても、組織の上位層に安全や品質に対する哲学がなく、商品のリリースの時期だけを何とかしろと言い、技術者の哲学（ポリシー）がポキッと折れてしまったり、考えてもどうにもならず辛いので考えないようにしている人はいると思っています。

簡単に言えば次のような質問に間髪入れずにはっきり答えられる技術者が少なくなってきていると思うのです。

・自分の商品の品質に自信があるか？
・自信の根拠は何か？

これらを聞くと怒り出す技術者はまだましで、しれっと「自分の守備範囲ではないんで」などと言う人が出てきたらもうおしまい。

そういう人たちで構成された組織において、製品の信頼や安全はプロセスや組織的システムのみで確保しなければならず、そのためには責任と権限が明確な組織的階層構造と徹底的な設計管理が必要です。

そうでない、プロセスやシステムだけで日々の仕事をやっているんじゃない組織において、もし、安全や信頼について自信をもって答えられる技術者、管理者が少なくなっているのだとすると、機器やサービスの安全や品質に対する哲学が個人個人に対しても、プロジェクト、部門にも必要です。

安全や信頼に関する哲学が、すでに組織の中に醸成されているのなら、職制で指揮命令するだけで高品質を維持できるかもしれませんが、安全や信頼に関する哲学が醸成されていない、廃れてしまったのなら意識改革から始めなければ高品質は達成できないと考えます。

これはロジックではなく、哲学やポリシーの問題です。なぜなら、当たり前品質という見えない品質を実現するために、どこまでやるかは常に自分との戦いであり、他人から言われた通りにするだけなら、納期のプレッシャーに負けて、品質は低い方向に傾くからです。

「開発が遅れているかどうか」を聞くのもいいですが、それと同じかそれ以上の熱意、頻度で「自分の商品の品質に自信があるか？」と問う人が増えないと高品質を維持していくのはムリだと思います。

以上

商品リスクを低減するには哲学的思考が必要

2010-10-11T10:35:00.003+09:00

日経ものづくり 2010年8月号の特集記事『ソフトが揺さぶる製品安全』の中で明治大学理工学部情報科学科教授の向殿政男氏が次のように語っている。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」

この、「哲学的」というキーワードを見て「なるほど」と思った。もしかすると、これまでなぜソフトウェア開発やソフトウェア品質がなかなかよくならないのか、それはソフトウェア開発には哲学的な判断が必要なのに、それをしない、できない人が増えているからだと思った。

なぜ、ソフトウェアと哲学が関係するのか。安全を定義するには、社会が許容するリスクとは何かを考えそこに線を引かなければならない。商品やサービスの周りにはリスクが無限に存在する。

悪意を持った行為を含む Abnormal Use を除いても、誤使用(Use Error), うっかりミス(Slip), 過失(Lapse), 誤り(Mistake) は必ず起こる。

それらのリスクに対してどこまで企業は対処すべきか。リスクの基となるハザードは危害に発展しなければ表面化しない。だからこそ、作る側と使う側で認識のギャップが生まれる。

正しい使用と異常な使用の間にはグレーゾーン（メーカーが考える正しさ、異常さと、ユーザーが考える正しさ、異常さのギャップ）が存在する。

このグレーゾーンをメーカーが都合のよい解釈で広げていくと、ハザードが危害になる危険性が高まる。メーカーは製造物責任を回避するために大量の警告や注意を取扱説明書に記載することよって、責任を回避できると思いがちだが、世の中はそう甘くはない。

ユーザーが取扱説明書を読まずに禁忌事項を実施した場合は、事故の発生はユーザー側に責任があるから、メーカーは製造物責任を問われることはない。しかし、社会通念上、多くの人の認識と合わないような要求を製品の利用者に強いている場合、適正なラベリングを行っていなければ、製造業者は社会的責任を追求される。

ようするににニュースになるような事故が起こると表記上の対策で刑事責任は逃れられても、設計上の対策=リスクコントロール手段を実装していなけば世間が許してくれず信用ががた落ちになり、企業の対応によっては市場から No を突きつけられるということだ。

そうなると、企業はユーザーの安全のためにグレーゾーンのどこに線を引くのか決断しなければならない。これはそんなに簡単なことではない。数式で計算できるようなものでもない。

その組織やそのプロジェクト、その技術者のポリシーに寄るところが大きい。組織的なポリシーが確立されていれば、商品間、サービス間でのばらつきは少ない。プロジェクトや技術者個人に依存していてば、そのプロジェクトやその技術者が関わった製品のみグレーゾーンのユーザー部分が小さいことになる。

リスクを起こさない仕組み=リスクコントロール手段を実装するにはコストがかかる。ソフトウェアで実施する場合、材料費はかからないが分析や実装の時間を要する。ソフトウェアは常に納期を迫れれているから、納期とのトレードオフでリスクコントロール手段は省略される危険性があり、ソフトは見えにくいので省略してもその事実を確認しにくいという特徴がある。

障害の発生確率が低ければ「どうせ、そんなこと起こらないよ」という気持ちになり、対策を実装しない技術者がいても不思議ではない。そして、障害の発生確率が高くても、納期が迫っていると「どうせ、そんなこと起こらないよ」と考えたい悪魔の気持ちが大きくなっていく。

悪魔の気持ちを抑えるのが、エンジニアの倫理観であり、組織の品質保証の仕組みである。エンジニアの倫理観は、哲学的な思考で鍛えられると自分は思っている。何も考えていなければ、エンジニアの倫理観は醸成されない。1か0ではない物事に対して、何が正しいのか、何を持って正しいと考えるのかについて深く掘り下げていくことで、哲学的な思考能力は高まると思う。

そうなると、前述のグレーゾーンをユーザーのリスクを最小限にするためにかかる工数（行為）と納期やコストとのトレードオフをする際に、なぜ自分または自分たちはその選択をしたのか自信を持って言えるようになる。

それが言えないのなら、その人は組織の言われた通りにものづくりをしているだけなのであって、グレーゾーンはメーカーの都合のよい解釈になっている可能性が高い。

その危険を組織で抑えるか、エンジニアのコンプライアンス教育で抑えるのか、それとも両方かを選択するのは自由だが、技術者がやりたいようにものづくりする方がいいものができると考えているプロジェクトほど、エンジニアの哲学的思考能力は高くないと安全で信頼できる商品は作れない。

自分自身はマイケル・サンデル先生の『これからの「正義」の話をしよう――いまを生き延びるための哲学』と読んで、哲学的思考能力を高めようとしている。

Random Failures と Systematic Failures の違い

2010-09-12T08:19:00.005+09:00

IEC 61508（機能安全）の中に、Random Failures （ランダム故障）と Systematic Failures （決定論的原因故障）の定義がある。

IEC 61508（機能安全）の定義そのものではなく、総合的にどんなことを意味しているのかいろいろ調べて考えてみた。

そうすると、前回の記事『ソフトウェア品質論の歴史的推移』につながるところがあることに気がついた。

■Random Failures （ランダム故障）

構成部品・機器などの多様な劣化のメカニズムの下で時間的に無秩序に発生する故障。
故障率を計測することで統計的に品質を管理する。

まず、ランダム故障は故障率が計測できる故障だから統計的に管理できる。だからこそ、統計的品質管理論によって品質を高めることができる。

つぎに Random Failures （ランダム故障）に相対する Systematic Failures/Faults （決定論的原因故障/障害）はどんなものか見ていただきたい。

■Systematic Failures/Faults （決定論的原因故障/障害）

ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去する。

Systematic Failures/Faults は故障率を予測することが難しい。部品の故障によって発生するのではなく、タイミングや複雑なユーザーオペレーション、まれに発生するイベントなどによって起こる障害である。

となると、部品の故障率を予測して品質を管理する手法が使えない。結果として開発プロセスで抑えるしかないということになる。これがプラグマティズム的品質管理論だと思う。

さらに、ソフトウェアの障害の場合、ユーザーオペレーションに起因する障害（バグ）の場合、障害が発生する手順を繰り返すと確実に障害を再現できる。あるとても複雑な手順を実施しないと発生しないが、その手順を実施すると確実に問題が起こるような場合、その障害の発生確率をどう考えるか。

たぶん、その障害の発生手順を知らない時点では、障害発生手順をやってしまう確率になるが、その障害の発生手順を知ってしまったら、製造業者のソフトウェア改訂責任という観点からすると発生確率は100%と言えるのかもしれない。

ソフトウェアが原因の場合、ソフトウェアを修正することで障害の発生を防止できることから、障害が原因で発生するハザード（潜在危険）の大きさによっては、ソフトウェアアップデートを確実に求められる。発生する状況がまれであるためソフトウェアを改訂しないという選択ができないこともある。

ソフトウェアに起因する障害の特徴でもある Systematic Failures/Faults の防止には、統計的品質管理論は効かず、プロセスアプローチが有効（というよりは他に有効な方法論がなかった）というのが定説だ。

ただ、広島市立大学の大場充先生が言うように商品の価値や顧客満足を重視した品質管理が21世紀のトレンドであるならば、 Systematic Failures/Faults が商品の価値や顧客満足に及ぼす影響度を分析（リスク分析）して、その優先度により、プロセスアプローチのしかたを変えるという方法がクローブアップされるのではないだろうか。

ソフトウェア品質論の歴史的推移

2010-09-05T20:30:00.008+09:00

日科技連主催のソフトウェア品質シンポジウム2010（SQiPシンポジウム2010）で広島市立大学の大場充先生が、ソフトウェア品質論の歴史を解説するセッションがあった。

非常に興味深い内容だったのでここに概要を紹介したいと思う。

■品質という概の推移（概要）

「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
今後の品質概念
「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

■品質という概念の推移１

現在のソフトウェア品質論はプラグマティズム的品質論を元にした理論が主流であるプラグラマティズ的品質論とは米国企業に1980年頃から浸透しはじめた、古典的な経験主義に基づく統計的品質管理へのアンチテーゼとして提案された
興味の焦点は、品質管理の対象としての製品（プロダクト）ではなく、それを生み出しているプロセスにある。
「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。
プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

■品質という概念の推移２

プラグラマティズ的品質論とは「工程の最終段階でのテストによって欠陥を除去し、その情報に基づいてプロセスの状態を知る」というフィードバック方式から、「プロセスの状況を的確に把握し、その情報に基づいて生産されるプロダクトの品質を適切に管理する」フィードフォアワード方式に転換したと言える。
1980年代フェーガンが提案したソフトウェアインスペクション法は、古典的なテストに基づく品質管理と新しいプロセスの実態に基づいて品質を保証しようとする葛藤がにじみ出ている。
その後、ミルズのクリーンルームプロセスの提案に統合されるしかし、結果的に品質保証を底辺で支える新技術の開発が遅れたため、このプラグマティズムに基づく方法は十分な成果を達成できなかった。

■品質という概念の推移３

1990年代センジ（プラグマティズム的組織論者）はプロセスの改善という組織の学習プロセスを管理することで、組織の目的に適合した成果を、効果的に達成できることを主張した。
そのような組織目標を品質改善とすれば「プロセス改善によって品質向上を成し遂げる」という品質論になる。
「要求プロセス」「開発プロセス」「検証プロセス」「品質保証プロセス」「販売プロセス」「保守プロセス」などをそれぞれ独立したプロセスとしてとらえ個別に改善することが従来の考え方であった。
これに対して、それら全てを統合したビジネスプロセスを見ることで全体最適を図ることが重視され、その成果が注目されるようになった。
この思想の影響を受けたものの代表にハンフリーによって発表されたソフトウェア開発プロセスの成熟度評価モデルがある。

■品質という概念の推移４

「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問
仮に市場で最も受け入れられている製品の品質が良い品質とする前提が正しければ、プラグマティズム的品質論に根ざしたプロセス評価を受けた組織がソフトウェアは広く利用され、売れるソフトウェアである。
Microsoft の製品はどうか？
プラグマティズム的品質論は、現実を反映させて、個々の理論の不備を修正しながら時間とともに発展し続けている。その意味でプラグマティズム的品質論の枠組みは強固であると言える。

■品質という概念の推移５

観念論的品質論
1960年代のZero Defect運動は、生産現場における不良撲滅運動であり「不良率の低減が製品品質の向上に直結する」という考え方に基づき「不良をなくすことが、究極的な品質の実現である」とする。これは、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
1980年代後半から普及したシックスシグマ運動は ZD運動と同じ精神を引き継いでいるものの、プログラマティズム的解釈が根底にある。
観念的品質論では、まず普遍的で純粋な品質概念の存在を前提とする。マッコールの提案をユーザの視点から整理し、分類したのが ISO/IEC9126である。

■品質という概念の推移６

日本的品質管理の概念
「当たり前品質」と「魅力的な品質」の相対概念である。
この概念は一見すると経験主義的な品質論に根ざしているように見えるが、本質的には経験を抽象化して獲得された高度に先験的で観念論的な概念である。

■品質論はどこに向かっているか？

1990年代から普及したCS運動
CS (Customer Satisfaction)運動では、顧客（ユーザ）の製品やサービスに対する満足度ことが、効用であり、品質の根源であるとする。
この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
「民主主義的原理に基づく品質論」
「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
開発者視点で重要なのは、そのような評価の結果を開発に結びつけることである。
そこで重要な役割を果たすのが開発プロセスである。
「プロセスは良い品質のソフトウェアを開発するための手段である」
品質論においてプロセスは、目的ではあり得ない。
プラグマティズムの立場から言えば、プロセスのみが、開発者が唯一管理できる対象であり、だからこそ最重要課題である。
しかし、目的論的な立場から言えば、あくまでも手段である。

【感想】

「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。

これは、試行錯誤で作り上げたソフトウェアを叩いて不具合を減らしていくという手法のことを言っているように見える。成熟度の低い組織が真っ先に考えつくのが一度作ってしまったソフトウェアの不良をいかにして取り除くかという観点だ。それだけでは無理と言ってもなかなか聞き入れてもらえない。

「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

この品質論が主流であることは納得できるし、結局、プロセスで品質を確保しようという活動をしているのも事実だ。

「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問

しかし、このことは常に開発現場の経験主義者から突き付けられる。昔は、網羅性の高いシステムテストでバグは潰し切れたし、ユーザーが行うであろうオペレーションのあらゆるパターンを再現できるベテラン技術者がいた。しかし、今ではすべてのオペレーションのパターンなど再現できるはずがない。システムテストでソースコードのテストカバレッジを100%にすることなどできるはずもないのだ。

だから、プロセスで不具合を作り込まない努力、プロセスにゲートをかけることで品質を確保することが必要になってきている。

「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である

今後の品質概念

「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。

評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。

同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

経験主義者を黙らせ、開発プロセスを管理することの重要性を訴えるには、「当たり前品質」や「魅力的な品質」といった日本的品質管理の概念や顧客満足を高めるために必要なプロセス、アクティビティ、タスクが何かという訴えかけが重要になる。

あなたの組織では「不良をなくすことが、究極的な品質の実現である」という古典的な品質論で考えが止まっていないだろうか？

品質に対する考え方は時代とともに変化しているのだ。

プリウスブレーキ制御ソフト改変についての考察（再考）

2010-08-08T22:22:00.013+09:00

日経ものづくりはソフトウェアには関係ないと思っている人も日経ものづくり8月号は単品(1400円）でも買った方がよい。

なぜなら、プリウスのブレーキ制御問題について、これまでになく詳細な情報が掲載されており、問題がなぜ起こったのかを推察できるからだ。

詳しくは日経ものづくり8月号の特集記事『ソフトが揺さぶる製品安全』を読んでいただくとして、この記事のコラム「プリウスに見る、ソフトの落とし穴」の感想を書いてみたい。

まず、このブログの『プリウスブレーキ制御ソフト改変についての考察』の記事でも書いたように、何しろプリウスのブレーキシステムは非常に複雑だ。

これはプリウスだからではなく、現在のハイブリッド車はみな、このように複雑な制御でブレーキの機能や性能を実現しているのだと思う。

何が複雑化というとざっとこんなところだ。

そもそもブレーキペダルを踏むとブレーキオイルの圧力が伝達されブレーキパッドを押し当てると思ったら大間違い。ブレーキペダルとブレーキパッドの間にはさまざまな構造物が間に入っている。
ブレーキペダルを踏むとピストンのような油圧ブースターを押すような構造になっている。
ピストンも密閉されているのではなく、リザーバタンクからブレーキオイルが補給されるようになっており、アキュームレータとポンプが接続されていて、ブレーキの圧力をモータとポンプの制御で高めることができる。
ブレーキオイルの圧力はストローク・シミュレータに送られて、ここでドライバが要求する制動力とペダルに対する反力を計算している。
ようするにドライバがあたかも、ブレーキペダルとブレーキパッドが直につながっているような感覚になるように、油圧を制御しているのだ。
強く踏めばブレーキは強く効き、弱く踏めば弱く効く。そこにタイムラグ（例えば0.5秒）があればドライバは強い違和感を感じるので、ハードリアルタイムの制御が必要となる。

日経ものづくりに掲載されているプリウスのブレーキシステムの構造図を眺めていると、ブレーキががこんなに複雑な構造になっていることに恐ろしさを感じる。車メーカーに全幅の信頼を寄せられなければ恐くて車には乗ってられない。個人的には、電気自動車の時代になっても新規参入してきた会社の車には10年間は乗りたくないと思う。それくらいソフトウェア制御が絡む複雑なブレーキシステムにはノウハウがないと危ないと直感する。

さて、プリウスのブレーキ問題は低速走行で緩やかに減速しているときにアンチロック・ブレーキ・システム(ABS）が動作すると、一瞬制動力が低下し、その結果、制動距離が延びる、または、運転手がペダルを踏み増さなければいけないという問題だった。

この問題が起こった流れを書くと次のようになる。

【新型プリウスのブレーキ問題が起こった背景】

プリウスは燃費を稼ぐために回生ブレーキを利用しジェネレータを回して発電する。（エンジンブレーキのようなもの）
しかし、回生ブレーキの制動力は弱いので、油圧によって制動力を足してやらなければいけない。（だから、構造が複雑になり、制御も複雑になる）
やっていることは超複雑なのに、ドライバには違和感を感じさせないように繊細な制御をすることが要求される。
ABSが作動するときは、回生ブレーキは使わずに油圧ブレーキだけで制動力を確保する。（回生ブレーキでは断続的なブレーキングは不得意だから）
ABSが作動するときは、ブレーキの油圧の供給方法を切り換えてドライバーが踏んだペダルの油圧を使うようにしている。
先代プリウスではペダル油圧ではなくモーターとポンプで作り出すアキュームレータ油圧を使っている。（新型プリウスのブレーキ問題の後トヨタはペダル油圧から先代プリウスで実績のあるアキュームレータ油圧に制御を変えている）
なぜ、先代プリウスではアキュームレータ油圧を使っていたのに、新型プリウスではペダル油圧に変えたのか？
それは、ブレーキングの際に増圧デューティ制御弁から生じる騒音・振動を低減させようとしたからでもある。（先代プリウスでは高価な増圧リニア制御弁を各車輪ごとに使っていたが、新型プリウスではコストダウンのために安価だがノイズの大きい増圧デューティ制御弁に一部変更している）
先代プリウスに比べて新型プリウスではペダル油圧の特性が強化されており、モーターとポンプを使わなくても、ペダルの踏み力でブレーキを動作させやすくなった。
これは、先代プリウスでは電源が故障するとブレーキが効かなくなるときの対策として予備電源のキャパシタを載せていたが、新型プリウスではこのキャパシタもなくしてコストダウンをはかり、電源が壊れていてもペダル油圧だけで制動できるようにした。（電源が死んだときは、ドライバの踏み力でブレーキを作動させやすくなった。）
そして、ABS動作時にアキュームレータ油圧を使うと増圧デューティ制御弁から発生する騒音や振動が目立つ（らしい）。（たぶん、ディーティ型は弁をパタパタさせる周期を変えることで制御をしているのでそのパタパタがうるさいのだろう）
この微妙な乗り心地感を向上させるために、改善したペダル油圧を使うように制御メカニズム（ECUのソフトウェア）を変更した。
ところが、低速で減速しているときのペダル油圧はアキュームレータ油圧よりも若干低い。（そこに落とし穴があった）
この差がドライバに微妙な「スカッ」という抜け感を生じさせてしまった。

ブレーキ制御ソフトの改変後、ABS動作時の制御をアキュームレータ油圧に戻したことから、騒音・振動は大した問題ではなかったのだと想像できる。

99.8% の満足度を 99.9% にするというトヨタの0.1%のコストダウン、乗り心地の改善が、結果的にブレーキシステムという基本性能に問題を発生させてしまった。

コストダウンや乗り心地のよさを追求した結果、すべての機能・性能に問題がないことを精査しきれないほどシステムが複雑になってしまったといえるのではないだろうか。

不具合が発生するメカニズムは分かってしまえば簡単だが、誰かから指摘される前にこのような問題を見つけるのは至難の業だ。特に複雑なシステムでは難しい。だから、メカもエレキもソフトもできるだけシンプルな構造（アーキテクチャ）を採用した方が安全面では有利だ。

シンプルであればあるほど、テストの網羅性を高めるととができる。妥当性を確認するために時間をかければかけただけの安心につながる。しかし、システムを複雑にすると、テストのカバレッジはいつまでたっても100%になならず、妥当性確認の時間は無限に必要になる。

このような　Systematic Failure を防ぐには個別最適の発想ではだめで、全体最適の発想が必要だ。

【日経ものづくり 2010年8月号 p39 図3 製品安全の方針より引用】

明治大学理工学部情報科学科教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いといいう。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。

「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障やバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だという。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）

だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは、難しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。

そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。

ソフトによって「信頼性≒安全」という認識は崩れつつある。ある意味では、本質的な安全に取り組む上で良い機会といえる。そこで重要になるのが「フェイルセーフ」や「フォールト・トレランス」といった概念だ。

フェイルセーフは、構成要素に故障やバグがあっても、安全側に落ち着くようにする設計である。例えば鉄道の踏み切りでは、遮断棒を支持する機構に何らかの故障が発生すれば、遮断棒が自重で落ちてくる。このとき、人や自動車は必要以上に足止めされるので信頼性という点では低下しているが、安全は確保できている。このように信頼性を犠牲にしてでも安全を最優先にするのがフェイルセーフとである。

ただし、製品や使用状況によって、明確な安全状態が存在しなかったり、コストなどの制約でフェイルセーフを盛り込めなかったりすることがある。その場合は、冗長化や多重化といったフォールト・トレランスを検討する。フォールト・トレランスは、信頼性を高めて昨日の継続を目指すという意味ではフォールト・アボイダンスと同じだが、欠陥やバグの存在を前提としている点が決定的に異なる。

構成要素ごとに信頼性を高めることが可能なフォールト・アボイダンスに対し、フェイルセーフやフォールト・トレランスは製品全体（システム）やサブシステムといった、大きな視点で見なければ実現できない。それには、製品開発の在り方を大幅に見直す必要がある。

【引用終わり】

日本のリスク分析の大家である向殿先生の主張が、アメリカの安全設計の大家であるナンシー・レブソン教授と根底でつながっているのはとても興味深い。

「日本の製造業は、欧米で確立された製品の改良設計で成長してきた」というくだりは、まさに目から鱗が落ちた。「だから全体最適や安全アーキテクチャの話しが通じないんだ」と思い当たるふしがある。日本の製造業の歴史的要因があるとなると、根が深いので安全アーキテクチャをシステム開発の上流で分析させるためには、攻め方を変えなければいけない。

全体最適の発想で安全アーキテクチャを考えなければ、どんなにがんばっても大きな問題を抑えきれない時代はすぐそこまで来ている。

ジョン・コッターの企業変革ノート

2010-07-17T20:27:00.002+09:00

ソフトウェアに関する改善活動を行っていると、テクニカルなことでは解決できないことにすぐにぶつかる。そこでいろいろなことを試してみるのだが、つい最近『ジョン・コッターの企業変革ノート』という本に出会った。久しぶりに付箋を手にしながら読んでいる。

この本に書いてあることは至極納得できるし、ここ数年自分がやってきたことにも重なるし、この通りにやってみようかなと思わせる。

『ジョン・コッターの企業変革ノート』のソリューションがうまくいきそうと思わせるには理由がある。この本の教訓は130もの組織の400名あまりの面談から得た情報（成功体験、失敗体験）から体系化されたものであるからだ。そもそも、ヒアリングの対象はアメリカの会社だろうから、そのまま日本の組織に使えないかもしれないが、日本人とアメリカ人の違いの奥にある人間としての共通項に響く部分も多々あると感じている。

まずは、紹介されている多数のエピソードのうちの一つを見ていただきたい。

【『ジョン・コッターの企業変革ノート』－怒れる顧客を映したビデオ－より引用】

■怒れる顧客を映したビデオ　　ティム・ウォラス

ある日、日頃の取引に感謝して得意先を夕食に招待した。当社の主力商品が話題になったところで、納品後に手直しを余儀なくされたと先方がこぼした。この製品は受注生産なので、おかしな話しだ。手直しには時間とカネがかかる。快く思っていないのは当然だ。

私は丁重に詫び、チームを組んでこの問題に早急に対処すると申し出た。誠意は伝わったはずだが、感動している様子はない。「この問題を御社の担当者に一度も話したことがないわけではありません。こちらの言うことは耳を貸してくれないのです」。先方の説明によれば、変更が必要な箇所を見つけたり、変更の方法を説明したりした時には、要求通りにするが、数週間後には元に戻っていると言う。「われわれは変更を何度もお願いしました。担当の方はうなずきはするものの、聞く耳を持たないようです」

この顧客から直接、話を聞いた人間は社内でもごく一握りだろう。しかも、この夕食の時ほど怒っているのは知らないだろう、とわたしは思った。そこで翌日、部下を出向かせるのでビデオで苦情を撮らせてもらえないかと打診した。先方は躊躇したが、わたしは真剣であり、お互いのためになるはずだと説明した。話し合いを重ねた結果、先方は少々、注文をつけたうえで、ビデオを撮ることを承諾してくれた。
翌日、数人の部下がビデオカメラを持って先方を訪ねた。すべてありのまま、包み隠さず喋ってほしいと頼んだところ、概ね、その通りにしてくれた。30分間収録したビデオは若干編集し、15分にまとめた。

工場の会議室に50人あまりの従業員を集めた。画面には、怒れる顧客が映し出された。従業員の反応は興味深いものだった。大半はただただ驚いているようだった。あまり顧客と接したことがなく、こうした強烈で否定的な声を聞いた経験がないのだろう。これは特殊なケースだと思った者もいたようだが、それでも画面に釘付けだった。ぽかんと口を開けている者もいる。当然ながら、顧客の方が間違っていると思う者もいた。「わかっていない」。「教えてやらなければいけない」「その理由は・・・」と口にする。だが、それは少数派だった。

ビデオ上映後、この問題をいかに解決するか、再発を防いで顧客に満足してもらうには何をすべきかを話し合った。次々とアイデアが飛び出した。もちろん、現実的でないものもあった。だが、話し合いは有意義だった。

このビデオは合計で400人あまりの従業員に見せた。ここでも少数ながら、自分が正しいと主張する者がいた。だが、同じ数だけ、「なんとかしなければ。対策を講じなければならない」と言う者がいた。自分たちの非を認めなかった者も、その後は工場に招いた顧客の声にもっと耳を傾けるようになったと思う。

ビデオはその後も撮り続けた。コストはほとんどかからない。これで問題がすべて解決できるわけではないが、改善を妨げる深刻な壁を取り払うのに役立った。この工場はもともと、当社が買収した企業のものだった。その企業は長らく業界をリードする立場にあったため、従業員は自分たちを万能だと考えていたのだろう。たしかに専門知識があり、仕事をよく知っている。だが、顧客を重視していなかった。「言いたいことはわかったから、仕事の邪魔をしないでくれ。われわれはプロで、あなたがたは邪魔でしかないことをわかっちゃいない」という態度をとっていたのだ。こうした態度では、行動を起こし、顧客のニーズに応えることができない。

【引用終わり】

この事例を見て「ああ、これをやってみたい」という衝動に駆られた。顧客満足を高めることは組織の誰もが考える共通の価値だ。だから、この価値を立脚して改善を促すことは正しいし、これまでもそうしてきた。しかし、ロジカルにテクニカルに責めるよりも、「見て、感じて、変化する」というアプローチの方が確実に効果があることを思い知らされた。

ソフトウェアは見えにくいから、この例よりもずっと「問題を見せて、感じさせる」のは難しいが、それができなければ変革は起きないというのは、その通りだという実感がある。

『ジョン・コッターの企業変革ノート』では、変革を成功に導くにはつぎに紹介する8段階を経る必要があると説いてる。第1段階の危機意識を高めるは、霊感商法のような感じもするが、でも、よく考えてみれば危機意識を共有できずに変革などできるはずもない。危機意識を高めるには、誠実な気持ちで本当の解決すべき問題を見せなければいけない。

【『ジョン・コッターの企業変革ノート』 The Heart of Change より引用】

＜大規模な変革を成功に導く8段階＞

■第1段階　「危機意識を高める」

大企業であろうと非営利の端末グループであとうろと、大規模な変革に成功した人びととはまず、関係者の間に「危機意識」を生み出している。ここでいう「関係者」とは、小規模な組織なら5人ではなく100人に、大規模な組織なら50人ではなく1000人に近いはずである。変革が順調に進まなかった事例では、変革リーダーが、5人あるいは50人を目標にするか1人も目標としておらず、現状満足や不安や怒りなど、ほぼ必ず起こる感情・・・変革の足かせとなる感情を容認してしまう。ときに創造的な手段で危機意識を喚起すれば、関係者がソファから跳び上がり、安全地帯から飛び出して、動き出す用意をする。

■第2段階　「変革推進チームをつくる」

危機意識が高まれば、変革の旗手を集め、変革の主導に必要な信頼、スキル、人脈、評判、権限を備えた変革チームをつくる。変革チームは、互いに信頼し、熱意を持って結束して行動する。変革が順調に進まなかった事例では、一人だけに頼ったり、誰も主導しなかったり、タスクフォースや委員会に力がなかったり、複雑な管理体制を築いたりしており、いずれに場合も変革を主導できるだけの地位やスキル、力が欠けている。タスクフォースをつくったものの、変革を生み出すだけの力がないために失敗した事例はきわめて多い。

■第3段階　「適切なビジョンを掲げる」

変革に成功した事例では、変革推進チームが、賢明で簡明で心躍るビジョンや戦略を策定している。変革がそれほど順調に進まなかった事例では、詳細な計画や予算だけを策定している。これらも必要であるが、それだけでは十分ではない。世界市場の動向や自社の状況にそぐわないビジョンを策定している場合もある。変革に失敗した事例では、戦略の動きが鈍く、慎重すぎて、激しく変化する世界にそぐわないものになっている。

■第4段階　「ビジョンを周知徹底する」

次ぎにビジョンや戦略を周知徹底する。シンプルで琴線にふれるメッセージを情報の溢れていない、いくつものチャネルを通して伝える。その目的は、成果を出すのに十分な数の人たちの理解を促し、やる気を引き出し、エネルギーを解放することにある。ここでは言葉よりも行動が重要になる。シンボルの効果は大きい。繰り返しも重要である。変革が順調に進まなかった事例では、効果的なコミュニケーションが不足していたり、下手だったりするが、そのことに気づかない場合が多い。

■第5段階　「自発的な行動を促す」

変革に成功した事例では、自発的に行動する人が増える。ビジョンに基づく行動を妨げていた大きな障害が取り除かれる。変革リーダーが特に重視するのは、部下のやる気をくじく上司の情報の不足、情報システムの不備、各人の心のなかにある自信というカベ、といった障害である。重要なのは、「権限を与えること」ではなく、障害を取り除くことである。権限は袋に入れて渡せるようなものではない。変革が順調に進まなかった事例では、権限を与えられた従業員は、障害だらけのなかで独力で突き進むように求められる。そのため苛立ちが募り、変革は行き詰まる。

■第6段階　「短期的な成果を実現する」

変革に成功した事例では自主性を持った人びとがビジョンに基づいて動くようになると、短期的な成果を生み出す。成果は欠かせないものである。成果が上がれば、変革が信頼され、資源が与えられ、勢いがつく。変革が順調に進まなかった事例では、成果が出るのが遅く、目に見えにくく、価値感に訴えず、成果であるかどうかもはっきりしていない。変革プロセスの管理が不適切で、最初に着手すべきプロジェクトが慎重に選択されず、早い段階で成果が上がらなければ、皮肉屋や懐疑的な者によって変革はつぶされる。

■第7段階　「気を緩めない」

変革に成功した事例では、変革リーダーはさらなる変革を推し進める。最初の成果が上がると、変革に勢いがつく。当初の変革が定着する。次ぎにどんな問題を克服するかを賢明に選択し、変革の波を次々と起こしてビジョンを実現する。変革が順調に進まなかった事例では、多くのことに一度に手をつけようとする。無意識に気を緩める。変革の勢いは衰え、絶望的なほど深みにはまる。

■第8段階　「変革を根づかせる」

変革に成功した事例では、各階層の変革リーダーが、新しい文化を育てることによって変革を根づかせている。新しい文化とは、ある集団で共有される行動規範や価値感であり、成果を生み出す行動が十分な期間続くことによって育まれる。ここでは適切な昇進人事を行ったり、新規採用者向けオリエンテーションを工夫したり、心を動かすイベントを行ったりすることによって違いが生まれる。それ以外の事例では、変革はもろく、表面的なものにとどまっている。伝統という風が吹けば、驚くほど短期間に、それまでの膨大な努力は吹き飛ばされる。

【引用終わり】

ジョン・コッターはハーバード・ビジネス・スクールで教鞭をとっているから、アメリカでは The Heart of Change について学べるということだ。日本ではどこで教えているのだろうか。また、日本の教育の中で、このような変革のメソッドをひとかけらでも教えているだろうかと考えてしまう。

小規模でも中規模でも何とかこの8段階をやり遂げて変革を起こしてみたいと思った。

人財と人罪

2010-07-04T21:58:00.001+09:00

あるセミナーでおもしろい図を見た。「じんざい」を四つの象限で表した図だ。縦軸はモチベーション、横軸はスキル。

モチベーションが高く、スキルもある場合は組織の財産という意味で人財
スキルは高いが、モチベーションが低い場合は単なる材料という意味で人材
モチベーションは高いがスキルが低い場合は、居るだけだから人在
モチベーションも低く、スキルもない場合は居るだけで罪だから人罪

もう一つの図。会社がリストラの必要性に迫られたときに、誰を残すかという指標。縦軸はビジョンを共有。横軸は仕事ができる。

組織とビジョンを共有し、仕事ができる社員は残す。
ビジョンを共有できているが仕事はできない社員も残す。
仕事ができるがビジョンが共有できない者は会社を滅ぼす。
ビジョンも共有できず、仕事もできない者は不要。

【楽に生きていきたいと思っていると楽に生きていけないというロジック】

楽に生きていきたい
責任を負いたくない
会社・相手に責任を転嫁する
信用が落ちていく

楽に生きていきたい
面倒は避けたい
処理が遅れる
信用が落ちていく

楽に生きていきたい
チャレンジする意欲はない
やれることしかやらない
信用が落ちていく

楽に生きていきたい
自分の利益が最優先
他は利用すべきもの
信用が落ちていく

結果として楽に生きていけない。依存型の人間にどのようなよい仕組みを与えても、依存型は依存型としてこれを利用する。

【自立型人材のモデル】

自分を活かして充実して生きていきたい
率先して取り組む
責任は自分が取る
自分への信用が増す

自分を活かして充実して生きていきたい
面倒なことから逃げない
処理が早い
自分への信用が増す

自分を活かして充実して生きていきたい
チェレンジしたい
自ら新たな状況を作る
自分への信用が増す

自分への信用が増すことにより、楽しく充実した人生が送れる。

【コンピテンシーモデル】

職能資格制度の欠陥を払拭するために高業績者の成果達成の行動特性（業績・成果と連動した顕在的能力）を重視したコンピテンシーモデルが有効である。

タワーズ・ペリン社のコンピテンシー ※1

コミュニケーション
チームワーク
顧客志向性
成果達成志向
革新性/創造性
ビジネス感応性
リーダーシップ
自身及び他者の能力開発/育成
意志決定
順応性/柔軟性
問題解決

※1 コンピテンシーの定義の例　「継続的にその職務に求められる達成すべき最終成果責任を生み出すための効果的な行動を選択し、実際に行動に結びつけるという行動にフォーカスした能力で、しかも顕在的で他社から観察しうる行動レベルでの発揮能力」

【達成動機が強い人には成果に対するフィードバックを示すべし】

達成動機の強い人は成功報酬よりも個人的な達成感に関心を示すとともに、難しい問題に取り組んだり、解決すること自体に関心を示す。達成動機の強い人は自分たちの成果に対して具体的なフィードバックを求めることを強調している。

これは同感。解決すべき問題が部門間にまたがっているような場合、ルールやプロセスの変更が素早く承認されると達成感、満足感が生まれる。

ここまでの話し、どう考えても義務教育の学校では教えていないことばかりのような気がする。教えていないところか、正反対の依存型の人材を一生懸命作ろうとしていないだろうか？

改めて問題の根（依存型の社会人が多いという現状）は深いように思った。