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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Random Failures と Systematic Failures の違い

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（SQiPシンポジウム2010）で広島市立大学の大場充先生が、ソフトウェア品質論の歴史を解説するセッションがあった。

非常に興味深い内容だったのでここに概要を紹介したいと思う。

■品質という概の推移（概要）

• 「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
• 「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
• 「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
• 今後の品質概念
• 「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
• 評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
• 同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

■品質という概念の推移１

• 現在のソフトウェア品質論はプラグマティズム的品質論を元にした理論が主流であるプラグラマティズ的品質論とは米国企業に1980年頃から浸透しはじめた、古典的な経験主義に基づく統計的品質管理へのアンチテーゼとして提案された
• 興味の焦点は、品質管理の対象としての製品（プロダクト）ではなく、それを生み出しているプロセスにある。
• 「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。
• プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

■品質という概念の推移２

• プラグラマティズ的品質論とは「工程の最終段階でのテストによって欠陥を除去し、その情報に基づいてプロセスの状態を知る」というフィードバック方式から、「プロセスの状況を的確に把握し、その情報に基づいて生産されるプロダクトの品質を適切に管理する」フィードフォアワード方式に転換したと言える。
• 1980年代フェーガンが提案したソフトウェアインスペクション法は、古典的なテストに基づく品質管理と新しいプロセスの実態に基づいて品質を保証しようとする葛藤がにじみ出ている。
• その後、ミルズのクリーンルームプロセスの提案に統合されるしかし、結果的に品質保証を底辺で支える新技術の開発が遅れたため、このプラグマティズムに基づく方法は十分な成果を達成できなかった。

■品質という概念の推移３

• 1990年代センジ（プラグマティズム的組織論者）はプロセスの改善という組織の学習プロセスを管理することで、組織の目的に適合した成果を、効果的に達成できることを主張した。
• そのような組織目標を品質改善とすれば「プロセス改善によって品質向上を成し遂げる」という品質論になる。
• 「要求プロセス」「開発プロセス」「検証プロセス」「品質保証プロセス」「販売プロセス」「保守プロセス」などをそれぞれ独立したプロセスとしてとらえ個別に改善することが従来の考え方であった。
• これに対して、それら全てを統合したビジネスプロセスを見ることで全体最適を図ることが重視され、その成果が注目されるようになった。
• この思想の影響を受けたものの代表にハンフリーによって発表されたソフトウェア開発プロセスの成熟度評価モデルがある。

■品質という概念の推移４

• 「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問
• 仮に市場で最も受け入れられている製品の品質が良い品質とする前提が正しければ、プラグマティズム的品質論に根ざしたプロセス評価を受けた組織がソフトウェアは広く利用され、売れるソフトウェアである。
• Microsoft の製品はどうか？
• プラグマティズム的品質論は、現実を反映させて、個々の理論の不備を修正しながら時間とともに発展し続けている。その意味でプラグマティズム的品質論の枠組みは強固であると言える。

■品質という概念の推移５

• 観念論的品質論
• 1960年代のZero Defect運動は、生産現場における不良撲滅運動であり「不良率の低減が製品品質の向上に直結する」という考え方に基づき「不良をなくすことが、究極的な品質の実現である」とする。これは、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
• 1980年代後半から普及したシックスシグマ運動は ZD運動と同じ精神を引き継いでいるものの、プログラマティズム的解釈が根底にある。
• 観念的品質論では、まず普遍的で純粋な品質概念の存在を前提とする。マッコールの提案をユーザの視点から整理し、分類したのが ISO/IEC9126である。

■品質という概念の推移６

• 日本的品質管理の概念
• 「当たり前品質」と「魅力的な品質」の相対概念である。
• この概念は一見すると経験主義的な品質論に根ざしているように見えるが、本質的には経験を抽象化して獲得された高度に先験的で観念論的な概念である。

■品質論はどこに向かっているか？

• 1990年代から普及したCS運動
• CS (Customer Satisfaction)運動では、顧客（ユーザ）の製品やサービスに対する満足度ことが、効用であり、品質の根源であるとする。
• この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
• 「民主主義的原理に基づく品質論」
• 「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
• 評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。
• 同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
• 「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
• 開発者視点で重要なのは、そのような評価の結果を開発に結びつけることである。
• そこで重要な役割を果たすのが開発プロセスである。
• 「プロセスは良い品質のソフトウェアを開発するための手段である」
• 品質論においてプロセスは、目的ではあり得ない。
• プラグマティズムの立場から言えば、プロセスのみが、開発者が唯一管理できる対象であり、だからこそ最重要課題である。
• しかし、目的論的な立場から言えば、あくまでも手段である。

【感想】

「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。

これは、試行錯誤で作り上げたソフトウェアを叩いて不具合を減らしていくという手法のことを言っているように見える。成熟度の低い組織が真っ先に考えつくのが一度作ってしまったソフトウェアの不良をいかにして取り除くかという観点だ。それだけでは無理と言ってもなかなか聞き入れてもらえない。

「良いプロセスが実践されているからこそ、良い品質が生み出される」がプラグマティズム的品質論の根幹をなす仮説であり主張である。プロセスそのものを見ることで、（プロダクトを見ることなしに）品質を管理できるという考え方。

この品質論が主流であることは納得できるし、結局、プロセスで品質を確保しようという活動をしているのも事実だ。

「なぜ良いプロセスが実践されることによって、悪い品質のソフトウェアが開発されるリスクを低下させることができるのか」という経験主義者から提示される疑問

しかし、このことは常に開発現場の経験主義者から突き付けられる。昔は、網羅性の高いシステムテストでバグは潰し切れたし、ユーザーが行うであろうオペレーションのあらゆるパターンを再現できるベテラン技術者がいた。しかし、今ではすべてのオペレーションのパターンなど再現できるはずがない。システムテストでソースコードのテストカバレッジを100%にすることなどできるはずもないのだ。

だから、プロセスで不具合を作り込まない努力、プロセスにゲートをかけることで品質を確保することが必要になってきている。

「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である

今後の品質概念

「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。

評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ（利用目的）への適合性（利用目的の達成度）によって決定される。

同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。

経験主義者を黙らせ、開発プロセスを管理することの重要性を訴えるには、「当たり前品質」や「魅力的な品質」といった日本的品質管理の概念や顧客満足を高めるために必要なプロセス、アクティビティ、タスクが何かという訴えかけが重要になる。

あなたの組織では「不良をなくすことが、究極的な品質の実現である」という古典的な品質論で考えが止まっていないだろうか？

品質に対する考え方は時代とともに変化しているのだ。