※2017年12月加筆
多くの企業が取り入れているISO-9001品質マネージメントシステムは、2015年9月15日、7年ぶりに改定されました。今回の改定の大きなポイントは、リスクベース思考（Risk-based thinking）が明示された点です。PDCAサイクルと組み合わさって、プロセスアプローチを支える重要な要素として扱われています[*1]。また「第6章Planning」など様々な条項で、「Risk（と機会）について検討すること」と要件に組み込まれています。以前のISO-9001 2008年度版においても、序文にもリスクという言葉は出てきますし「予防措置」が似たコンセプトだと言えなくもないですが、書きっぷりからして今回追加された新しい概念であると考えるべきです。
しかしながら具体的にどのようにしてリスクに向き合うのか、ISO-9001それ自体では詳しく触れられていません。必須要件でもありませんし、Annex Aに「必要なら他のガイドラインや規格を利用してもよい（しなくてもよい）」程度に書かれているのみです。しかし現代の企業活動において、「わが社では、QMSプロセスに、リスクマネージメントは必要ではない」と断言する方が無理があるでしょう。逆に「どこでも当たり前にやっている」と感じるのが普通です。ではなぜわざわざ大きく書き加えたのでしょう。
ISO-9001 2015版が参照している[*2]、リスクマネージメント規格（ISO-31000 Risk Management）が参考になります。この規格は、ISO-14000環境マネジメント、ISO-27000情報セキュリティマネジメントなど様々なマネジメント規格を包括したリスクマネジメントを目指しています。いずれ企業の各マネジメント体系を統合するときに、カギになる規格です。どのような企業でも、なんらかのリスクマネージメントを実施していることと思いますが、活動に課題はないでしょうか。ISO-31000を活用して確認していただければと思います。[*3]
ISO-31000はもとより機能安全（IEC-61508、ISO-13849）やサイバーセキュリティ対策（IEC-62443、ISO-27001）とも共通するのですが、誰かが決めた「〇〇しなさい」という具体的な要件をいくら並べて強制しても完全ではない（抜け穴ができる。不足する）、という考え方が背景にあります。欧米でのＰＬ（製造物責任）の争いでは、適切に設計製造管理したのか（法令・規範的な要件）という点に加え、開発や設計時に「最大限に安全について考慮したのか」をエビデンスで証明する必要があります。後者をドイツの機能安全のセミナーでは「State of the art」と呼び、様々な知見を集め網羅的にリスクについて検討した経緯を見える形・共有できる形にしておくこととして定義しています。Prescriptive Requirement（規範的な要件）」と「Performance-based Requirement（実績に基づく要件）」が組合わさって、本当の目標が達成できるという意思が隠されています。この後者を支えるのがリスクマネージメントです[*4]。
もちろんどんな企業活動も昔からリスクについての思考や、過去のトラブルの経験測があって目標設定をしてきています。安全設計でも同様です。にもかかわらず、日本における機能安全の審査で最も苦労するのが、そのリスクの共有方法と判断プロセスへの展開手順や長期にわたるエビデンスの管理です。「うちは昔からこの仕様・設計で事故がない」という主張が、欧米人の機能安全審査官と全く噛み合わない部分がここです。はい。全く噛み合いません。
様々な環境が変化する中、過去設定した目標がなぜ今ここでも通用すると判断したのか、あのときは何を根拠にそう判断したのかに立ち戻らなくてもよいのか、関係者で判断を共有できるルールが必要です。当時、想定したけれど発生しないと判断したなら、その根拠も残さなければなりません。将来状況が変化すれば、その排除した想定の発生可能性が高くなるかもしれないからです。設計根拠書がある場合もありますが、それも設計（結果）の出所を示すだけです。どのように網羅的に想定した結果、どうしてそれだけが重要と考えて設計に反映したのかという全体像の記録、およびそれを支える管理ルールを審査官が求めますが、もう果てしなくお互いに判り合えません。
日本人にとってリスクとは、田んぼの稲が虫にやられたり台風にやられるイメージです。来るか来ないかわからない厄災ですが、共通の危機感が根底にあります。そこに対して欧米の審査官が「あらゆる可能性を議論したか、排除した根拠は、そのルールは？」と問われれば、「そんなルールを作るわけがない。なんという意地悪だ。」と多くの日本人は感じます。彼らにとってリスクとは、集団で狩猟をするイメージです。「右の険しい山を越えると獲物がいるのか、左の低い山を越えると獲物はいるのか。」なぜ、ルールや議論がなく集団が納得しあい協力し合うのかがそもそも理解できないようです。日本の集団には暗黙知や危機意識の強い共有があったということでしょう。
しかし最近の会社組織では、暗黙知や危機意識を共有したり継承する機会が極端に減少している気がします。限られた勤務時間では昔話をする余裕はありませんし、聞く余裕もありません。人数の少ない若手にすれば、すごい迷惑です。時間外に先輩が語ったり、ましては飲みに誘うなど、パワハラだと訴えたくもなるでしょう。このような状況が続けば、目標設定の際に行っていたリスク管理に必要な暗黙知や危機意識は、何らかのルールで見える化して意識的に共有する作業が必要になりそうです。いままで無意識にやっていた広い意味でのリスク管理を、意識的にルール化し長期的に維持保守するべき時代と言えそうです。
ISO-9001が範囲とする広い範囲のマネージメント体系では、機能安全のようなリスクマネージメントに関する厳格なエビデンス化やルール化は不要でしょう。大変すぎます。とはいえ前述の通り、QMSプロセスに明示的にリスク管理の方法（リスクの特定や扱いに関するルールを共有し、時々の判断プロセスを記録する手順、およびその維持改善方法）を加えることは、様々な職場がもつベテランや先輩の暗黙知の見える化、後輩への継承に大きく貢献します。後年に後輩が変化に対して判断をするときに必ず役に立つはずです。さらに、実際に発生した事故やトラブルの経験が組み合わさるのが理想です。リスクマネージメントにその企業や組織の知識や経験、本質が蓄積されてゆくと私は考えています。
今回のISO-9001の改定は、『リスク思考を基にした目標設定を「やっている」「やっていない」といえば、みな昔から「自然とやっている」だろうから、細かいことはいちいち書かないけれど、ルールを決めて明示的に位置付けてやるんだよ。』という主張だととらえています。
リスク分析の手法や考え方アプローチについてだけは、機能安全の世界であっても、具体的なことは基本規格（IEC-61508）に書いてありません。自動車なら自動車の、医療なら医療の、プラントならプラントのリスク評価の手法が整備されており、それを使わなければなりません。（基本規格のサンプルは、それらが全くない場合にのみ使用可）リスクマネージメントこそ、その業界の多くの人々の蓄積が詰まっていることの証左です。きわめて範囲の広いビジネス・業務を包含するISO 9001の改定に、リスクマネージメントの具体的な取り組みルールの記載がないことは、当然といえば当然でした。
自分たちのルールは自分たちで作る。その際にISO-31000は役に立ちます。この規格ではルールの全体をフレームワークと呼んでいます。リスクマネージメントのフレームワークが持つべき要素（活動）が整理されています。今の自分たちのルールと比較して改善するなど、上手に活用すれば、よりよい目標設定に役立つだけではなく、組織の暗黙知を長期に大切に蓄積し共有してゆくことができるのではないでしょうか。
[*1] ISO 9001:2015 / Introducton /
0.1General / This International Standard employs the process approach, which incorporates the Plan-Do-Check-Act(PDCA) cycle and risk-based thinking.
0.3.3 Risk-based thinking / To conform to the requirements of this International Standard, an organization needs to plan and implement actions to address risks and opportunities.
[*2] ISO 9001:2015 / Bibliography [19] ISO 31000, Risk management — Principles and guidelines
[*3]日本規格協会 「ISO 31000:2009 リスクマネジメント解説適用ガイド」、日本規格協会「リスクマネジメントの実践ガイド」
[*4] ISO 9001:2015 / Annex A / A.4 Risk-based thinking /
The risk-based thinking applied in this International Standard has enabled some reduction in prescriptive requirements and their replacement by performance-based requirements.