ソフトウェア品質を高く保つには哲学が必要

前回の記事『商品リスクを低減するには哲学的思考が必要』に関して、もう一回同じようなことを書いた文章がありますので、ご一読ください。

誰がどこに書いた文章かはご想像にお任せします。

------
明治大学理工学部に向殿政男先生という方がいます。

著書のひとつ『安全設計の基本概念』

向殿 政男
1965年明治大学工学部電気工学科卒業。1967年明治大学大学院工学研究科電気工学専攻修士課程修了。1970年明治大学大学院工学研究科電気工学専攻博士課程修了。明治大学工学部電気工学科専任講師。1973年明治大学工学部電気工学科助教授。1978年明治大学工学部電子通信工学科教授。2005年経済産業大臣表彰受賞(工業標準化功労者)。2006年厚生労働大臣表彰受賞(功労賞)。明治大学理工学部情報科学科教授。明治大学理工学部学部長。明治大学大学院理工学研究科委員長。ISO/TC 199国内審議委員会委員(元主査)。安全技術応用研究会会長。機械の包括的な安全基準に関する指針の改正のための検討委員会委員長。次世代ロボット安全性確保ガイドライン検討委員会委員長ほか(本データはこの書籍が刊行された当時に掲載されていたものです)

その、向殿先生が、日経ものづくり 8月号 で日本のものづくりの歴史的背景を次のように語っています。

【日経ものづくり 8月号 特集 ソフトが揺さぶる製品安全より引用】

信頼性一本やりでは厳しい

明治大学理工学部情報科学課教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いという。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。

「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障がバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だといえる。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）。

だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは厳しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。

そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。

【引用終わり】

この「今後の安全設計には全体最適の発想が必要であり、安全を定義するには社会が許容するリスクとは何かを組織が考えなければならず、そのためには哲学的判断がいる」、というところに強く共感します。

ようするに、ユーザーリスクとその対策は考えれば考えるほど際限がないので、コストや開発時間とのトレードオフでどこまでやるかを決断しなければならず、その決断をするためには安全や品質に対する哲学が必要だということです。

安全や信頼を実現している「当たり前品質」は、カタログやスペックシートには現れないため、長い間商品を使ってもらったときにお客様から伝わってくる「品質がいいね」という感想や、クレームの少なさなどでしか表面に現れてきません。

クリティカルデバイスではそこが命でもあるので、技術者は当たり前に出来ていることの重要性や、リスクを軽減する対策の大切さは言われなくても分かっていました。

それが、近年、リスク分析の結果や取扱説明書を見ていると、表記上の対策で禁忌・禁止事項として書いておけば、設計上の対策はいいやという技術者が増えてきたようにも感じています。そうなってきた理由のひとつは商品が実際に使われる現場の現実を知らない技術者が増えてきたからでもあります。

これだけ複雑化してしまった製品ソフトウェアに対して、安全に対して哲学を持ってどこまでやるかを決断しなければならなくなっているのです。逆に言うと製品の品質や安全に対して無知であったり、哲学（ポリシー）がない技術者が作る商品、ソフトウェアは危険であると言えます。

そして、技術者に哲学（ポリシー）があっても、組織の上位層に安全や品質に対する哲学がなく、商品のリリースの時期だけを何とかしろと言い、技術者の哲学（ポリシー）がポキッと折れてしまったり、考えてもどうにもならず辛いので考えないようにしている人はいると思っています。

簡単に言えば次のような質問に間髪入れずにはっきり答えられる技術者が少なくなってきていると思うのです。

・自分の商品の品質に自信があるか？
・自信の根拠は何か？

これらを聞くと怒り出す技術者はまだましで、しれっと「自分の守備範囲ではないんで」などと言う人が出てきたらもうおしまい。

そういう人たちで構成された組織において、製品の信頼や安全はプロセスや組織的システムのみで確保しなければならず、そのためには責任と権限が明確な組織的階層構造と徹底的な設計管理が必要です。

そうでない、プロセスやシステムだけで日々の仕事をやっているんじゃない組織において、もし、安全や信頼について自信をもって答えられる技術者、管理者が少なくなっているのだとすると、機器やサービスの安全や品質に対する哲学が個人個人に対しても、プロジェクト、部門にも必要です。

安全や信頼に関する哲学が、すでに組織の中に醸成されているのなら、職制で指揮命令するだけで高品質を維持できるかもしれませんが、安全や信頼に関する哲学が醸成されていない、廃れてしまったのなら意識改革から始めなければ高品質は達成できないと考えます。

これはロジックではなく、哲学やポリシーの問題です。なぜなら、当たり前品質という見えない品質を実現するために、どこまでやるかは常に自分との戦いであり、他人から言われた通りにするだけなら、納期のプレッシャーに負けて、品質は低い方向に傾くからです。

「開発が遅れているかどうか」を聞くのもいいですが、それと同じかそれ以上の熱意、頻度で「自分の商品の品質に自信があるか？」と問う人が増えないと高品質を維持していくのはムリだと思います。

以上

商品リスクを低減するには哲学的思考が必要

日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』の中で明治大学理工学部情報科学科教授の向殿政男氏が次のように語っている。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」

この、「哲学的」というキーワードを見て「なるほど」と思った。もしかすると、これまでなぜソフトウェア開発やソフトウェア品質がなかなかよくならないのか、それはソフトウェア開発には哲学的な判断が必要なのに、それをしない、できない人が増えているからだと思った。

なぜ、ソフトウェアと哲学が関係するのか。安全を定義するには、社会が許容するリスクとは何かを考えそこに線を引かなければならない。商品やサービスの周りにはリスクが無限に存在する。

悪意を持った行為を含む Abnormal Use を除いても、誤使用(Use Error), うっかりミス(Slip), 過失(Lapse), 誤り(Mistake) は必ず起こる。

それらのリスクに対してどこまで企業は対処すべきか。リスクの基となるハザードは危害に発展しなければ表面化しない。だからこそ、作る側と使う側で認識のギャップが生まれる。

正しい使用と異常な使用の間にはグレーゾーン（メーカーが考える正しさ、異常さと、ユーザーが考える正しさ、異常さのギャップ）が存在する。

このグレーゾーンをメーカーが都合のよい解釈で広げていくと、ハザードが危害になる危険性が高まる。メーカーは製造物責任を回避するために大量の警告や注意を取扱説明書に記載することよって、責任を回避できると思いがちだが、世の中はそう甘くはない。

ユーザーが取扱説明書を読まずに禁忌事項を実施した場合は、事故の発生はユーザー側に責任があるから、メーカーは製造物責任を問われることはない。しかし、社会通念上、多くの人の認識と合わないような要求を製品の利用者に強いている場合、適正なラベリングを行っていなければ、製造業者は社会的責任を追求される。

ようするににニュースになるような事故が起こると表記上の対策で刑事責任は逃れられても、設計上の対策=リスクコントロール手段を実装していなけば世間が許してくれず信用ががた落ちになり、企業の対応によっては市場から No を突きつけられるということだ。

そうなると、企業はユーザーの安全のためにグレーゾーンのどこに線を引くのか決断しなければならない。これはそんなに簡単なことではない。数式で計算できるようなものでもない。

その組織やそのプロジェクト、その技術者のポリシーに寄るところが大きい。組織的なポリシーが確立されていれば、商品間、サービス間でのばらつきは少ない。プロジェクトや技術者個人に依存していてば、そのプロジェクトやその技術者が関わった製品のみグレーゾーンのユーザー部分が小さいことになる。

リスクを起こさない仕組み=リスクコントロール手段を実装するにはコストがかかる。ソフトウェアで実施する場合、材料費はかからないが分析や実装の時間を要する。ソフトウェアは常に納期を迫れれているから、納期とのトレードオフでリスクコントロール手段は省略される危険性があり、ソフトは見えにくいので省略してもその事実を確認しにくいという特徴がある。

障害の発生確率が低ければ「どうせ、そんなこと起こらないよ」という気持ちになり、対策を実装しない技術者がいても不思議ではない。そして、障害の発生確率が高くても、納期が迫っていると「どうせ、そんなこと起こらないよ」と考えたい悪魔の気持ちが大きくなっていく。

悪魔の気持ちを抑えるのが、エンジニアの倫理観であり、組織の品質保証の仕組みである。エンジニアの倫理観は、哲学的な思考で鍛えられると自分は思っている。何も考えていなければ、エンジニアの倫理観は醸成されない。1か0ではない物事に対して、何が正しいのか、何を持って正しいと考えるのかについて深く掘り下げていくことで、哲学的な思考能力は高まると思う。

そうなると、前述のグレーゾーンをユーザーのリスクを最小限にするためにかかる工数（行為）と納期やコストとのトレードオフをする際に、なぜ自分または自分たちはその選択をしたのか自信を持って言えるようになる。

それが言えないのなら、その人は組織の言われた通りにものづくりをしているだけなのであって、グレーゾーンはメーカーの都合のよい解釈になっている可能性が高い。

その危険を組織で抑えるか、エンジニアのコンプライアンス教育で抑えるのか、それとも両方かを選択するのは自由だが、技術者がやりたいようにものづくりする方がいいものができると考えているプロジェクトほど、エンジニアの哲学的思考能力は高くないと安全で信頼できる商品は作れない。

自分自身はマイケル・サンデル先生の『これからの「正義」の話をしよう――いまを生き延びるための哲学』と読んで、哲学的思考能力を高めようとしている。