書評「ⅠＳＯ事務局心得帖」（システム規格社刊）
（H18年2月1週号）

Ａ　氏： この本はISO関係の知人からもらった。序文でISO9001のテニオハ的な審査は初期に多くあったとあるが、これは今も散見していて根深いね（このホームページの新着ニュースコーナーの「A社のISO9001:2000審査対応：H17年12月4週号」参照）。
Ｂ　氏： まず、ISO9001の最初の勉強をセミナーや参考書でするのをやめ、最初に原文に接し、これを徹底的に理解し、日本語の意味不明なところを英語にもどって理解するというのは適切だね。だから、JIS訳での審査に否定的なことは理解できる。
ただ、事務局はこれでいいが、幹部全員に最初に規格の研修会をやると頭が痛くなり、拒否反応を起こすことが多いね。「コミットメント」とか、カタカナ英語にアレルギーがある中小企業では特に要注意だよ。日本語の「力量」だって問題だよ。
Ｂ　氏： 規格を英文で読むのはよいが、読むポイントになる英語のshallやshouldの話がこの本では全く出てこないね。残念だね。システムの設計の設計目標は、具体的には2000版の場合、除外を含め136のshall（サブ項目まで含めて230項目）の満足だし、審査員とも136のshall対応だからね。これが最大のポイントだよ。Shallの理解でシステム設計をすれば重たいISO9001システムには、まず、ならないし、審査員とshallで対応すれば、テニオハ審査は起こりえないはずだよ。
Ａ　氏： 問題は、日本文でも英語でも規格を読んで、「何かおかしい」と感ずるセンスだね。それは、やはり、ビジネスのマネジメントセンス、納期・コストの現場経験というのが先にある。経営工学の基礎があれば、より好ましいがね。恋愛小説の理解にはある程度の年齢が必要なように。恋愛経験があればもっとよいがね。
Ｂ　氏： 品質マニュアル作成は、パソコンに「写経」した規格の本文を自社向けに変えていくという方法は賛成だね。品質マニュアルは本来、内外のプロ向けだからね。
Ａ　氏： 品質マニュアルも分業で書くのでなく、一人で書くべきだというのも賛成だね。
ただ、下位文書に管理規定があるとき、これが分業となるとき、要注意だね。
Ｂ　氏： 著者がいう通り、品質マニュアルは、マネジメントシステム設計書だよ。そうなら、規格原文から、参考書なしで自社システムを帳票レベルまで設計する人のオリジナルな設計能力が問題だ。君が管理規定ゼロを考え出したような――。
Ａ　氏： そうだね。エンジン設計には、機械設計のプロとしての基礎能力が必要なようにね。ISO9001:2000の失敗の多くの原因は、その設計者の能力不足と言えるからだ。
それから、能力の１つに、ISO9001の規格を読むとき、「ああ、この部分は当社ですでにやっているこの部分だな。」という発見能力があげられるね。これには、生産管理システムなど、自社現場の全体の実態を知っていることが前提だ。ISO本部の解説のように、大部分の企業はすでに規格で要求している活動をしているので、それを規格に照らして、システムとして基本的に整理すればいいはずだよ。
Ｂ　氏： ISO9001の「原文」で要求している程度のことをしてない企業はつぶれているよ。
Ａ　氏： いや、ISO9001要求通りのシステムの企業でもつぶれることがあるよ。必要であるが、十分でないというためか、「超ISO」が生まれる（このホームページの「基礎知識」コーナーの「『超ISO』へのコメント：H17年7月4週号」参照）。
Ｂ　氏： ISO9001の規格の許容幅は広い。だから、マネジメントシステム設計者が、どういうマネジメント手順の代替案とその正確な評価・選択基準を持っているかがポイントだ（このホームページの統合システムコーナーの「Ⅰ．統合マネジメントシステムを成功させるための前提となる常識（2）」参照）。
Ａ　氏： そうだね。帳票レベルの設計では、設計者が多くの柔軟な代替案を持っていないと、結局、文書番号制度や配布台帳制度などの「ISOの仕事」（この本でいうところのムダな仕事）を新しく導入することになるね（このホームページの９００１項目別分類の「硬直した品質マニュアル作成例：H15年10月4週号」参照）。
Ａ　氏： 品質マニュアルを設計書と考えると、それは設計のアウトプットだね。この本では設計プロセスの重要な点が体系的にふれられていないのが残念だね。具体的には、品質マニュアル作成のプロセスは、ISO9001:2000の「7.3　設計・開発」のマネジメントシステム体系が適用可能だね。
Ｂ　氏： まず、7.3.1の設計・開発の計画だ。ISO9001:2000取得大日程計画作成だ。94年版では、設計者には資格を要求していたね。次に7.3.2のインプットだ。これに136のshall（230項目のサブ項目）要求の満足がインプットされる。また、現システムの情報が含まれ、基本的に現状システムは変えない（「ISOの仕事」を作らない）というインプット制約が入る。そして、代替案を選択するという設計行為をして、マニュアルを書く。7.3.3の設計アウトプットだ。品質マニュアル第1号の完成だ。
Ａ　氏： これから、いよいよ、重要な7.3.4のレビュー、7.3.5の検証、7.3.6の妥当性確認（現場でのトライ）というチェックが入るね。7.3.4のレビューは、インプット段階、設計の途中段階でも計画される。品質マニュアルの修正管理は7.3.7の変更管理だ。
Ｂ　氏： こうして、十分、現場と練った設計アウトプットである品質マニュアルが完成し、設計の手を離れる。施行となる。だから、実行後は、改訂される頻度は少ない。
Ａ　氏： 施行後、改訂が多いのは、7.3.4のレビュー、7.3.5の検証、7.3.6の妥当性確認で、何をやっていたのかとなるね。だから、品質マニュアルは制定日でなくて、施行日・発行日・実施開始日が重要だ（このホームページの９００１項目別分類の「硬直した品質マニュアル作成例：H15年10月4週号」参照）。
Ｂ　氏： この本で言うところの「ISOの仕事」（ムダな仕事）は、品質マニュアル最終版（設計最終アウトプット）で改善削除されるね。そして、7.5の製造段階、すなわち、施行開始だ。この日以降が本番で、審査対象となる。
それにしても、製造（施行）段階で設計ミス（品質マニュアル改訂）が多発するのは、7.3段階で良いISO9001:2000システム設計をしていないでないのと同じだね。