前回の記事『
商品リスクを低減するには哲学的思考が必要』に関して、もう一回同じようなことを書いた文章がありますので、ご一読ください。
誰がどこに書いた文章かはご想像にお任せします。
------
明治大学理工学部に向殿政男先生という方がいます。
著書のひとつ『
安全設計の基本概念』
向殿 政男
1965年明治大学工学部電気工学科卒業。1967年明治大学大学院工学研究科電気工学専攻修士課程修了。1970年明治大学大学院工学研究科電気工学専攻博士課程修了。明治大学工学部電気工学科専任講師。1973年明治大学工学部電気工学科助教授。1978年明治大学工学部電子通信工学科教授。2005年経済産業大臣表彰受賞(工業標準化功労者)。2006年厚生労働大臣表彰受賞(功労賞)。明治大学理工学部情報科学科教授。明治大学理工学部学部長。明治大学大学院理工学研究科委員長。ISO/TC 199国内審議委員会委員(元主査)。安全技術応用研究会会長。機械の包括的な安全基準に関する指針の改正のための検討委員会委員長。次世代ロボット安全性確保ガイドライン検討委員会委員長ほか(本データはこの書籍が刊行された当時に掲載されていたものです)
その、向殿先生が、日経ものづくり 8月号 で日本のものづくりの歴史的背景を次のように語っています。
【日経ものづくり 8月号 特集 ソフトが揺さぶる製品安全より引用】
信頼性一本やりでは厳しい
明治大学理工学部情報科学課教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いという。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。
「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障がバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だといえる。
日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。
さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）。
だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは厳しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。
そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。
【引用終わり】
この「今後の安全設計には全体最適の発想が必要であり、安全を定義するには社会が許容するリスクとは何かを組織が考えなければならず、そのためには哲学的判断がいる」、というところに強く共感します。
ようするに、ユーザーリスクとその対策は考えれば考えるほど際限がないので、コストや開発時間とのトレードオフでどこまでやるかを決断しなければならず、その決断をするためには安全や品質に対する哲学が必要だということです。
安全や信頼を実現している「当たり前品質」は、カタログやスペックシートには現れないため、長い間商品を使ってもらったときにお客様から伝わってくる「品質がいいね」という感想や、クレームの少なさなどでしか表面に現れてきません。
クリティカルデバイスではそこが命でもあるので、技術者は当たり前に出来ていることの重要性や、リスクを軽減する対策の大切さは言われなくても分かっていました。
それが、近年、リスク分析の結果や取扱説明書を見ていると、表記上の対策で禁忌・禁止事項として書いておけば、設計上の対策はいいやという技術者が増えてきたようにも感じています。そうなってきた理由のひとつは商品が実際に使われる現場の現実を知らない技術者が増えてきたからでもあります。
これだけ複雑化してしまった製品ソフトウェアに対して、安全に対して哲学を持ってどこまでやるかを決断しなければならなくなっているのです。逆に言うと製品の品質や安全に対して無知であったり、哲学（ポリシー）がない技術者が作る商品、ソフトウェアは危険であると言えます。
そして、技術者に哲学（ポリシー）があっても、組織の上位層に安全や品質に対する哲学がなく、商品のリリースの時期だけを何とかしろと言い、技術者の哲学（ポリシー）がポキッと折れてしまったり、考えてもどうにもならず辛いので考えないようにしている人はいると思っています。
簡単に言えば次のような質問に間髪入れずにはっきり答えられる技術者が少なくなってきていると思うのです。
・自分の商品の品質に自信があるか？
・自信の根拠は何か？
これらを聞くと怒り出す技術者はまだましで、しれっと「自分の守備範囲ではないんで」などと言う人が出てきたらもうおしまい。
そういう人たちで構成された組織において、製品の信頼や安全はプロセスや組織的システムのみで確保しなければならず、そのためには責任と権限が明確な組織的階層構造と徹底的な設計管理が必要です。
そうでない、プロセスやシステムだけで日々の仕事をやっているんじゃない組織において、もし、安全や信頼について自信をもって答えられる技術者、管理者が少なくなっているのだとすると、機器やサービスの安全や品質に対する哲学が個人個人に対しても、プロジェクト、部門にも必要です。
安全や信頼に関する哲学が、すでに組織の中に醸成されているのなら、職制で指揮命令するだけで高品質を維持できるかもしれませんが、安全や信頼に関する哲学が醸成されていない、廃れてしまったのなら意識改革から始めなければ高品質は達成できないと考えます。
これはロジックではなく、哲学やポリシーの問題です。なぜなら、当たり前品質という見えない品質を実現するために、どこまでやるかは常に自分との戦いであり、他人から言われた通りにするだけなら、納期のプレッシャーに負けて、品質は低い方向に傾くからです。
「開発が遅れているかどうか」を聞くのもいいですが、それと同じかそれ以上の熱意、頻度で「自分の商品の品質に自信があるか？」と問う人が増えないと高品質を維持していくのはムリだと思います。
以上
