15．マネジメントレビュー

5.6：品質マネジメントシステムが有効に機能しているかを、顧客からの情報、内部監査の結果等をもとに確認することは、経営者の責任である。その確認により経営者は、システムの改善、製品の改善、および経営資源投入の必要性を明確にしなければならない。

企業の社会的責任は外部に対して責任を果たすこと、という理解では十分ではない。
経営者が考えるべき社会には内部の組織も含まれる。従業員、協力会社まで含めて考えるべきである。
経営者のする仕事の大部分が営業であることから、外を飛び回ることが多くなる。外での会食やパーティーで多くの情報や将来についての戦略を学ぶ。同時に自分（自社）がどう評価されているか理解する場でもある。

外部の客観的な目は正しいことが多いが、所詮、外部の目である。現象は正しくとらえても、その原因までとらえている訳ではない。その原因をとらえる場として、内部監査とマネジメントレビューは役に立つ。
ただし、経営者がどこまで本気になって参加しているかによる。経営者は内部監査、マネジメントレビューの必要性と意味を組織にいかに指導しているかである。本物の内部監査であるか、形式的な内部監査であるかは全ての従業員の理解するところとなる。

上位者は内部監査に参画しているか。
マネジメントレビューの結果が組織全体に周知されているか。
被監査側に是正要求を出すだけでなく、監査のやり方も改善されているか。
監査で強い点が明確になっているか。
ISOによる経営基盤の整備に対する方針は明確か。
企業の将来に役に立つ内部監査になっているか。
経営方針や戦略に生かされているか等々
チェックしてみれば、経営者が本気か、関心がないかすぐ分かることである。

特に、マネジメントレビューは組織の内部に経営者の意思を伝達する場でもある。

一方、経営者が無関心なのは、ISOの推進者や内部監査員にも責任がある。もともと優れた能力を持つ経営者に対してありきたりの報告では、見向きもしない。
経営者を動かしたいと思うなら、現状の危機感を論理的、体系的にまとめたレビューすべきである。


マネジメントレビューの目的

ある会社では社長監査が定期的に実施され、社長は「自分に手伝える事は何か」をかならず聞くという。また別の社長は自分の方針がどこまで浸透しているか調べ自分が反省する場にしているという。
経営者が自ら確認する場がマネジメントレビューであるから、あまり形式的な場をつくるべきではない。

上下のコミュニケーションではまず、安心して話せることが大切である。
上の人に対して、気後れがあっては、意見を堂々と述べることができない。
安心感を意味するSECUREは気後れ（CURE）のない（SE）こととデミング博士は説明する。
話す側が気を遣って話す内容を変えるようでは、本当のコミュニケーションはできない。
理解し易いように配慮することは大切だが事実を歪めて話すようでは、「裸の王様」を作ることになる。

近代的経営においては、情報開示と説明責任は当然のことである。ジュラン博士が日本の品質管理を指導された1950年代、責任という言葉は説明責任（ACCOUNTABILITY）を強調していた。
その経営者の責任を果たすため、経営者、経営幹部の管理項目を決めておく必要がある。マネジメントレビューはその手段である。

形式的な内部監査はやめるべきである。
ISOのリハーサルならプレゼンテーションの練習ぐらいの割り切りで進めたほうが気が利いている。
経営者が自ら行うトップ監査を実施すべきである。
日本のものづくりは経営者と現場の距離が近いことで世界一になった。
ISOの導入で経営者を飾り物にするのはよくない。
裸の王様を作ることがISOの目的ではない。

14．コミュニケーションと責任権限

5.5：責任権限を組織に周知すること、および、内部コミュニケーションを良くすること
は経営者の責任である。

活性化した組織においては、責任権限を明確にすることはコミュニケーションを良くすることである。自分の仕事の前工程、後工程がわかり、自分が何をしたらよいか明確になるからである。後工程はお客様」というのは品質管理の基本である。お客様のことを考えて仕事をするのであって、自分の都合で仕事をするわけではない。責任権限を組織に周知することはコミュニケーションを良くするため行うことであり、仕事の基本を教育することでもある。
この基本が理解されてないから、部門間の壁が厚く、部門間連携の悪い組織になる。
くどいようだが基本的な教育の不足である。
この原因は、教育する側に問題があることは言うまでもない。

組織やシステムを長い間放置しておくと、責任権限を必要以上に複雑にして自分の責任を曖昧にする。システムの官僚化である。この原因は経営幹部の思いつきの組織いじりである。組織を細分化しておいて、指示命令を徹底させるために、どんな細かいことでも報告しろと指示する。「報連相」を自主性に任せるのでなく、上から下に要求するという古臭いシステムである。
これが時に、秘密警官のような機能を果たす。信頼によって組織が成り立つのではなく、不信感が蔓延する。経営幹部の器量と恐怖感がそのまま組織に反映されるからである。
ドラッカーがこのことを指摘していたと思うが、組織がだめになる前兆である。これにもう一つ品質問題隠しが追加されれば、悪循環が組織に蔓延する。

ＩＳＯは本来このようなことをなくすために、システムの継続的改善を要求している。
システム作成段階から、成果のあがるシステムを考えるべきである。
1＋１を２にするだけならシステムはいらない。システムとは部分の和より全体を大きくすることである。シナジー効果をあげるのがシステムの目的である。

たとえば中小企業、少ない人員で仕事をオーバーラップしているから、うまくいく。
組織が複雑になり、責任権限が細分化されたのでは、うまくいくはずはない。こんなあたり前のことが理解されてない。
文書化のみ考えて、取り付かれたように文書を作ると、硬直化したシステムになる。システムは両刃の剣であることを忘れてはいけない。


事例：３ポイント運動から品質保証活動一覧表まで

問題の原因を個人、責任者に特定するのはまだ本質を捉えてない。よく言う「とかげのしっぽ切り」に終わることが多い。問題の本当の原因は部門間にあることが多い。つまり、システムに問題がある。システムは放置しておくと、形骸化、陳腐化、官僚化する。ISOでシステムの改善を強調するのはこのようなことを防ぐためである。このように、宝の山は部門間にある。注意すべきことは、「部門間の問題を会議で解決するな」である。

事例：3(スリー)ポイント運動
　ある工場を案内してもらった時のことである。工場長がしきりに作業者に話しかけてほしいと催促する。「あなたの仕事のポイントはなんですか」と聞いてほしいというわけである。作業を中断させてはわるいと思ったが、何人かに聞いてみた。すると誰もが即座に３つのポイントを答えてくれる。しばらく聞いていて共通のパターンに気がついた。自分の作業の前工程との引継ぎをどうするのか、後工程（次工程）へ何を保証するのか、そのための自分の仕事のポイントは何かという３ポイントである。これはシステムの基本でもある。あまりにも見事に答えてくれるので、作業の連続する何人かに聞いてみた。ラインがコンベアでつながっているのはわかるが、ここでは人の気持ちが３ポイントでつながっていて、ラインが活きているように思えた。また、工場長が日頃の教育効果の確認と現場の人の動機づけに外部からきた客をうまく使うことにも感心させられた。補足しておくが、この工場ではQCサークル活動が活発であった。このような「強い文化」を持つ会社なら当然のことと思える。

前工程、後工程を考え仕事をするのは、基本であるがそれが理解されてないことが多い。
少し複雑なシステムにおいても、インプット、アウトプットそれを結びつける帳票を整理すれば、システムはできる。品質保証システムにおいてそれを整理したものが、品質保証活動一覧表である。
まず、品質保証を大まかな段階にわける。設計、生産準備、製造と言う具合である。大まか過ぎるなら、基本設計、詳細設計、工程設計のように分けてもよい。最終的には個々の品質保証活動の単位まで分ける。このように目的とする仕事の機能を分けることを、品質機能展開という。これができたら、個々の品質保証活動の目的を考え、そのためのインプット、アウトプットを整理すればよい。このようにして、開発から製造、販売、サービスまでの全体をまとめた表を品質保証活動一覧表とよぶ。

責任権限を明確にして、部門間のコミュニケーションをよくするために、まず品質保証活動から着手すべきである。品質保証の現状の問題を明確にし、問題の大きいところから責任、権限を明確にしていけばよい。

13．効果的責任・権限の設定方法

5.5：責任権限が設定され組織に周知されること。これは経営者の責任である。


「責任とは達成すべき目標であり、権限は目標達成のための条件である。」
この定義は非常に明快である。
責任を自覚するためには自分が達成すべき目標が明確でなければならない。
言葉を逆にして考えたほうがよい。
自分の達成すべき目標があれば責任を自覚すべきである。
責任を義務ととらえるか、権利と考えるかは大きな違いがある。
前向きに自分の達成すべき目標があれば、目標達成の障害となる問題があるから、目標意識と問題意識は同じである。問題意識のない人は目標意識もない。

組織で自分の目標があることは、自分の役割や使命感を自覚していることである。
「人間は自分の欲するところのものになる」という言葉があったが、欲するところという目標を持つべきである。しかし、高すぎる目標をかかげるあまり目標の達成をごまかすことのないようにすべきである。自分自身を偽ることは、自分の品位を失うことである。
最近の企業ぐるみのうそは自分自身を偽ることが原因である。

「自分の欲することを為し得ぬ者は、おのれの為し得ることを欲せよ」とはダ・ヴィンチの言葉である。
目標の設定について上位者の指導と支援が必要である。広い意味での教育である。
広義のといった理由は、社会生活を営む上での責任や目標は子供の頃からの家庭教育に根ざしている。この範囲にさかのぼって教育を考えなければならないので大変である。

上位者は部下の能力をいつも把握しており、能力に応じた目標を与えるべきである。
責任の重要性を自覚するには、責任権限の委譲が正しく行われなければならない。
たとえば「誰も手が空かないので穴埋めに頼む」という仕事と「君の能力を見込んでこれを頼みたい」というのでは、責任の重さが違う。責任の受け取り方が違うのである。
誰でも普段見せないが、大きな可能性、潜在的な力を持っている。
いざという時、力が出せるのは俗に言うところの「火事場の馬鹿力」である。

ほんの少しの思いやりと動機付けで、人の能力を引き出すことができる。
このためには、人の気持ちを感じそれに答える能力が要求される。
応答（Response）できる能力（Ability）がRESPONSIBILITY（責任）である。

方針管理や目標管理というものは人を動機付け、人と人の気持ちをつなぐ為にある。
最近技術論が先行し、そのような管理を目標管理規定なる文書を作ればこと足れリとするばか者が増えたので、組織がぎくしゃくするのである。

責任権限を検討することは、部下と上司の双方が動機付けられるコミュニケーションの機会であることを自覚し、たえず実践すべきである。

自分の達成すべき目標が責任、そのため使える条件が権限。責任権限は重要なものから決める。そのため方針による改善活動の結果から責任権限を決める。改善、成果の標準化をおこない、部下に任せたい仕事から権限委譲する。このように品質管理を理解していれば、正しく責任、権限を整理できる。

１２．品質方針の設定と展開

5.3，5.4　品質方針、品質目標を設定し、各部門、階層に展開すること。
また、方針、目標が実施され、成果をあげるプロセス全体を管理すること。

　品質方針は組織の方向を示すものであり、経営者の力の入れ方を示すものである。
時に経営者の人格を反映し、組織の品格決定付けるものである。
誰もが理解できることは大切だが、あたり前すぎて誰も実行しないようでは困る。

方針を作成したらその思いを説明すべきである。
思いや人格がにじみ出た言葉には力がある。
いい言葉には力がある。自分もやってみようという気持ちになる。
組織全員をその気にさせるまで繰り返し説明すべきである。
経営者の熱意から学ぶことは多い。
「学ぶとはまねぶ」と聞いたことがある。
まねぶ技術は生産技術であり、技術がないと真似できないということを、以前、松下の重役から聞いた。「松下工業はまねした工業である」とその重役は自社の生産技術の優位性を強調していた。このような話を聞いて育った社員はうらやましい。松下幸之助さんは神様と言われた人だから、人を育てる名人だったのだろう。

方針が、人を動機付け、発奮させ、経営に参画する意識を植え付けることによって総合力を引き出す力になる。


方針と目標

方針や目標がいつも未達成なのになにも手が打たれてないようなら、方針や目標をすぐに撤去すべきである。
方針や目標は、ないよりある方がいいというものではない。
ある方が悪い場合が多い。このことに気付くことは大切である。

わずかな進歩であっても、望ましい方向に進んでいることが実感できる場合は、人はその方向を目指そうとする。このためには、方針、目標の設定のため現状を良く見極め（現状把握）、目標が達成できる実行計画に展開されなければならない。実行計画はたえず確認されよい方向に向かうための処置がとられなければならない。成果のあがったことは評価され、よい点は水平展開することにより成果をあげることができる。このようなＰＤＣＡのプロセス全体を方針管理や目標管理という。

人は正しい道が示され、動機付けられると想像以上の力を出す。
動機付けというとすぐ教えることを考えるが、良い点を引き出し（教えられ）それを評価して、水平展開することが何よりも大切である。
組織のリーダーは動機付けの名人であって欲しい。

「実現に程遠く、困難な、はるか離れた微かな光を、情熱の炎に燃え上がらせることができる、これは疑いもなく人間の生命源泉における大きな力である」　オルテガ

11．顧客重視で成果をあげる

5.2：　顧客重視とは顧客要求事項が満たされ、顧客満足が向上していることを経営者が確認している状態をいう。

顧客重視とは、顧客の言いなりになることではない。欧米は契約で買い手と売り手の関係が成り立つから基本的に同等の関係である。そのため顧客の要求に対して約束できる範囲を決めること、つまり確約することが契約の第一歩になる。
ところが日本のような親子や系列の関係ではこれが難しい。
ISOでこれが是正されることを期待したが、無理であった。特に日本の場合、審査員は大会社の出身者であることが多い。審査機関も大手企業が集まり出資している例が多い。
ISOは顧客側から企業に要求できる範囲に限定しているため受身の体制になる。
ISO/TSに至っては規格自体が買い手に偏っているため、顧客重視、売り手無視のようにさえ見える。この関係を直さない限り、大人のISOにはならないのだが、これが難しい。

さて、注文が決まってから納入までの短期間では、技術開発する時間は十分ではない。技術者はこのことを理解しているが、注文を取る営業や売上重視の経営者は、自社の技術力に過剰の期待をする。
短い開発期間にしなくてはならないことは、保有する技術を組み合わせて顧客の要求を満たす最高の品質を設計すること、その品質が設計され、部品が購入され、製造された製品の品質確認・品質保証に十分な時間をとること、等である。

当然こちらの都合だけ主張していては注文は取れない。そのため、無理して注文をとるための不良やクレーム、リコールがあとを絶たない。実力以上の売上重視、利益優先の弊害であろうか。買い手でも、多くの不良やクレーム、リコールの原因がいわゆる「外注部品」に起因することが多いことはわかっている。このため、ISOで学んだ監査の考えを使って
「外注指導を目的とした監査」をおこなう。この監査、もたれあいとだましあいのくり返しである。この悪循環を少しでも是正するのは、審査機関なのだが、審査員にその力や意識のある人はいない。結局のところ、売り手が考えるより手はない。

このような悪循環の品質問題を防ぐため、顧客や市場の変化を予測して、要求に答えられるように技術開発の時間を十分とって検討すべきである。

個別受注生産のＭ造船では、受注から引渡しまでの管理を番船管理とよび、それを支援する技術の開発や改善を部門別管理とよび、両管理を区別して運用していた。番線管理の課題はいかに短期間に品質問題の無い船を作れるかという品質保証を中心とする体制である。なお、品質問題の多くは、品質情報の伝達に問題があることをつきとめ、品質機能展開を開発した。また、部門別管理は方針管理を活用して、従来発生した品質問題の解析により、品質改善や生産技術の改善などに取組んだ。

このように売り手としては事業の重点や特色を考えた管理技術とシステムを開発すべきである。


顧客要求と技術

顧客の要求から組織の経営資源を点検してみる。
顧客要求の達成を目的として、その手段を考える。その手段を目的とするとその目的を達成する手段に展開できる。このように顧客要求を展開するとその目的を達成するための技術に展開できる。技術が多くの目的と関連する場合は技術も展開するとよい。
顧客要求の展開を「要求品質表」と名付けた。
一方、技術の展開を「技術表」とよぶ。技術を設計技術と生産技術に分けて、「技術表Ⅰ」「技術表Ⅱ」のように区別しても良いだろう。

また、要求品質と技術のマトリックスを作ると自社の技術の分布がみえる。
顧客要求の中で今後の動向を予測した場合、自社の保有技術は十分か、不足している技術はなにか。今後の技術開発の重点はどこか、などが整理できる。
ポートフォリオも市場と技術のマトリックスだが、顧客要求、要求品質はもう一段階技術の中に入り込んだ指標である。
このように意味ある比較をすることにより今まで見えなかったものが見えてくる。

設計が図面だけでは表現できない品質保証上の重点をまとめたものを、ＱＡ表とよぶことがある。
自動車のような組立て業の場合は「部品ＱＡ表」「組立てＱＡ表」と区別する場合もある。
ついでこのＱＡ表を製造工程に展開したものが「ＱＣ工程表」である。

このような展開を品質管理では品質機能展開：ＱＦＤとよぶが。これらは問題発見の道具として、まず活用すると多くの問題の発見に役立つ。
蛇足しておこう。ＱＦＤは始め問題発見や問題の予防のために開発された道具である。
しかし、それを形式的に真似るだけでは役に立たないばかりか、余分な仕事が増えるだけのことである。形を作って魂を入れることを忘れてはならない。
「仏作って魂いれず」ではご利益が得られない。

10．事業戦略を品質で見直す

5.1：　経営者は品質マネジメントシステムの構築、実施、継続的改善に対するコミットメントを行うこと。

なぜ事業を品質で管理するのか考えてみよう。
事業で利益を追求するのは当然のことであるが、なぜ利益が必要かを考えてみる必要がある。利益は事業に配分されて目的と結びつく。
最近の事件を考えてみよう。本来手段であるべき利益が目的となり、得られた利益は事業の推進に結びついてない。

ＩＳＯでは資源の運用管理という項目がある。品質方針の達成のため、人的資源と作業環境・インフラ整備などの運用管理を実施すべきである。
この事業プロセスを品質で管理するのが品質管理である。品質とは顧客のメリットだから顧客の利益としての顧客要求、顧客満足を重視したシステムを運用すべきである。

品質で事業を見直すことにより、今まで見えてなかった「宝の山」が見えてくる。
利益は定量的に処理できる便利な指標だが、結果の指標である。
品質は利益の先行指標または代用特性として優れている。
不良の多い製造工程からは利益は得られない。
「仏作って魂入れず」という言葉がある。製品という形を作っても、心である品質がその中に込められてなければ、魅力ある製品とはいえない。市場でのクレームやリコールは品質を忘れた設計や製造が原因である。

このような単純なことが理解できてないのは、欲深い裸の王様が自分の貯金通帳を見る時間に追われ現場を見ていないからである。
品質管理をするということは、品質をしっかり見ます、現場から学びますというコミットメントをすることである。これが出来て初めて「事業を品質で見直す」ことが出来る。

規格序文0.1：品質マネジメントシステムを採用することは組織における戦略上の決定とすべきである。・・・・品質マネジメントシステムの構造の均一化又は文書の画一化が、この規格の意図ではない。

9. 品質管理の文書をどこまで書くか

4.2.1：品質マネジメントは以下の文書で構成される。
品質方針と品質目標
品質マニュアル
規格の要求するプロセスの管理の手順

4.2.2：ISOで要求される品質マニュアルは以下の条件を満たすこと。
適用範囲を明確にすること。
品質マネジメントシステムについての文書化した手順を示すこと。
プロセス間の相互関連を示す記述があること。


文書化の世界
「口角泡を飛ばす」という言葉がある。
これでもかというくらいに議論する、言葉や文書にこだわる。欧米の特徴である。
むかし友人の映画監督に教えられた。シナリオを読む。日本の会話は全てを言いきらないそうだ。余韻があるというか余韻を残さないとシナリオにならない。
そこで、韓流、すべてを話してくれるから楽しい。異性からこう言われたいと思っていることを聞く心地よさがある。言い過ぎで恥ずかしい気もするが。
詩人の佐藤春夫が詩を書く心得を聞かれて「言葉は浅くこころは深く」とこたえた。
山頭火「言ひすぎは言ひ足らないよりもよくない」。

日本人は形と心を別のものとは考えない。
長年かけて心を形に変える。茶道、華道などはそれにあたる。
ISOでやたらに文書を作っても決して形はできない。心のないものには形はない。

ではどうしたらよいだろうか。
改善のプロセスを考えてみよう。現状把握して問題の原因を見つけ、それに手を打って成果を確認してから、歯止め標準化する。
当然標準化とは、良い点や問題の再発防止の標準を作ることと、その教育訓練をしてよい状態を維持することである。これが出来たら次の問題を探し改善を繰り返す。
問題を見つけ良くしたいと思うから、心がはいる。

さて、ISOを作ったＥＵのように外国人労働者の多い国では、作業者の訓練のための作業標準のような文書は必要である。スタッフは苦労して標準をつくり、徹底して守らせ、また守る努力をする。「始めに言葉ありき」の世界である。
最近のように、海外の労働者の多い日本で学ぶべきことも多い。
ただし、日本のよさを生かした標準化に取組むことが大切である。

日本には「守破離」という形を学ぶプロセスがある。
まず、形から学ぶ、次ぎに形を破る、そして全てから離れてみる。その後、自分なりの形を作りそのくり返しをするというプロセスである。


文書化のコツ

以下、文書化のコツをまとめる。
１、「マニュアルは標準語で、その他の文書は方言で書いても良い」
　　ある審査機関の代表者から聞いた。マニュアルはお客様にも見せるので、わかりやすく書くべきである。社内で見る文書は、社内に通用する表現でよいということである。
　　審査と言うと文書のあら探しのようになるが、理解するよう努力するのが審査員の役割である。
２．「である」調で書くと文書がぞんざいになる。「です」調で書くと親切な文書になる。
　　マニュアルはお客様に見せることを考えて、丁寧に書きたい。普段から文書を書きなれている人ならよいだろうが、「である」調で書くと自分が偉くなったような気がして、よい文章がかけないことがある。
３．ＩＳＯ審査の対象になる文書には、すでに出来ていることしか書かない。
当然のことかもしれないが、文書を作成する段階に気付くことは多く、つい必要以上のことも書きたくなる。多くの場合、文書作成者は文書を読む人より理解している人だろうから、つい余計なことまで書きたくなる。この誘惑に勝てないと、実力以上の文書になるため、守りにくい文書になる。
こうしたいと言う文書は別に解説書のような形で書くべきである。
４．解析や再発防止のプロセスを大切にして書く。
　　「始めに文書ありき」はよくない。また、文書にしなくても誰でもできることは、文書にすべきでない。これを守らないとどんな問題がおきるかを中心に書くべきである。
　　解析や改善のプロセスにそって書くのがよい。いわゆるＱＣストーリーが一番わかりやすいはずである。
５．手順はフローチャートで書くとわかりやすい。
　　フローチャートは前後の工程が明確になるし、少し解説を加えれば帳票や記録のインプットとアウトプットの関係がつきやすい。従来から品質管理を実施している会社で使われている、品質保証体系図や品質保証活動一覧表など活用すべきである。
６．誰によんでもらうか考えて書くこと。
　　誰が読んでも理解できること、という考えは捨てたほうがいい。そんなに丁寧に書いたものは、実務に慣れている人が日常使うのにはふさわしくない。
　　誰が読んでもわかるように書くのは教育用のテキストである。
　　実務者に必要なのは、手軽に見られる注意書きでよい。
　　教育用と実務用を混同しないようにしないと、役に立つ文書にならない。
７．一番大切なことは、標準化とは標準を作って終わりではないということである。
　　作ったものは徹底して教育訓練すべきである。もし教育訓練の時間が取れない程度のことの標準など作るべきではない。

8. 品質マネジメントシステムの目的と構成

ＩＳＯ規格は経営革新のマニフェスト（宣言）である。
マネジメントシステムをＩＳＯ規格にしようという発想は品質管理で高度成長を実現した日本にない発想である。ないというよりも及びがつかないことであった。
品質管理の普及を目的とする組織では、それぞれ自分の組織の目的にあわせた事業を推進している。日本規格協会のＪＩＳの普及、日本科学技術連盟のデミング賞、日本生産性本部の品質経営賞などである。日本では本来普及を目的とした賞が企業の差別化の看板になっている。
　
ＩＳＯ規格のすごいところは、企業の目的を問い直したところである。ISO9001では、利益中心の企業の目的に品質を追加したこと、ISO14001では環境重視の経営を奨励したこと。このようにＩＳＯでは品質や環境重視の経営をコミットメント（誓約）することを要求している。先見性と洞察力のある経営者にとっては、自社の利益中心の経営を品質や環境で見直すという経営革新のお手本がＩＳＯ規格であることが、理解できるだろう。

ＩＳＯは、品質を目的とした経営を宣言し具体的活動として実施することを要求している。このことの重要性をもう一度問い直したい。

「品質管理は全ての人の為の仕事だが、誰の為の仕事でもない。」

忘れていた言葉を思い出した。
品質管理の目的を的確に表現した言葉である。
品質管理は顧客も従業員も株主も経営者も含めた全ての人の仕事であるが、決して特定の顧客や経営者だけの仕事ではないということである。
ISO9001や自動車業界に特化したISO/TSなどは顧客や系列の為だけを目的としがちである。
まして、経営者の為にだけあるのではない。

全ての人の為の仕事だから、職業生活の質：QWLの追求も目的となる。
品質目標を個人目標に展開し自分のすべき正しいことをすればよい。
決して受身でやらされ感でとらえるのではなく、前向きに自分がやりたいことを積極的に検討することが出来る。

このように従来利益一辺倒の企業が品質を重視することにより、全ての人の参画と活性化が期待できる。品質管理をするということは、そのようなことであることを忘れてはならない。


4.1：ISO規格の要求事項を満たすこと及び品質方針を達成する目的で品質マネジメントシステムを整備する。その内容は
必要なプロセスを明確にすること。
プロセスの順序と相互関連を明確にすること。
プロセスの運用及び管理のための判断基準と方法を決める。
そのための経営資源と情報が利用できること。
プロセスを監視、測定、分析すること。
目的達成のための継続的改善をすること。

ISO規格の難しいことは説明が逆になっていることである。
本屋で立ち読みして面白そうな本を買おうという時、初めの何行かで読んでみようという気になる本を探す。そんなつもりでISO規格を読んだら、まずこの先を読んでみる気にならないだろう。

さて、ISO9001の品質マネジメントシステムとは次のような要求を満たすシステムですということが、規格の初めの章に書いてある。各章の初めには一般要求事項として各章の総括が書かれている。非常の論理的に書かれているが、「要求事項」として書かれているから解りづらい。とてもシェークスピアを生んだ国の人が書いた文章とは思えない。

また、我々が読んでいるのは翻訳された日本語である。ISOとJISの間に取り交わされた翻訳協定の制約もあって、「声をだして読みたい日本語」とは程遠い。

ぼやきはそのくらいにして、ISO規格に沿って品質マネジメントシステムを考えていこうと思う。

規格4.1はこれから勉強することの質問事項ぐらいに考えて先に進みましょう。
品質マネジメントシステムに必要なプロセスとは何ですか
そのプロセスの順序と相互関連はどのようになっていますか
プロセスの管理項目は決めてありますか
管理運営のために必要な経営資源と情報を提供する覚悟がありますか
プロセスは客観的なデータで管理されていますか
継続的改善を本気で行う覚悟がありますか

７．正しい治療のための正しい診断

8.2.2：品質マネジメントシステムが要求を満たしているか決められた間隔で監査する。

優れた技術が在り、優れた人材がいて、その割に成果が出ないという「宝のもちぐされ」が多い。診断、監査の技術が不足しているからである。正しい治療のためには、まず、正しい診断ができなければならない。治療は固有技術であり、診断は管理技術である。
問題に対してとる対策は治療である。問題の原因に合う治療は役立つが、原因に合わない治療で問題の解決はできない。そのため、どの原因に対してどの治療をするかが整理されてなければならない。治療の体系化ができていれば、有効に治療が活用できる。
このようなことを固有技術の標準化という。
固有技術の標準化のためには管理技術が役立つ。固有技術と管理技術は車の両輪の関係にある。固有技術がないところに管理技術は必要ない。管理技術があると固有技術を有効活用できるし、固有技術の発展にも寄与することができる。
　
マネジメントは診断に重点を置いた管理技術であり、「正しくみる技術」、「みるためのプロセス」である。
見る：現象を見て問題を発見する。
観る：問題と原因の因果関係を観察する。
診る：その多くの原因の中から、問題に寄与する原因を診断する。
看る：原因に対策をとり成果を見守る。
このプロセスは品質管理のＰＤＣＡのプロセスであり、問題解決、解析のプロセスである。

問題解決、解析は「見る、観る、診る。看る」で構成される。
1． 正しい現状把握により問題が明確になったか。
2． 問題の原因を解析により正しく求めたか。
3． 原因に対する対策がとられたか。
4． 対策の効果を確認したか。
5． 効果の継続のため標準化したか。
6． 維持管理したか。

大切なことは、何を目的に診断するかである。
強い点を探したか
顧客の要求を意識したか
問題という氷山全体をとらえたか
「間」に重要な可能性をみたか
品質の確約、確保、確認のプロセスで診断したか
などである。

治療ができても診断ができない医者は失敗を犯す「やぶ医者」である。最近、そのような品質管理が増えたので、不良が絶えない。


診断と治療
品質管理は数あるマネジメントの手法の中でも診断に重点をおいた実践的活動である。
ISO以前の品質管理の特色はトップ診断が実施され、経営者が自ら診断することにより、ＰＤＣＡをまわしたことである。誰しも「自分の体のことは自分が一番良く知っている」と思っているが、「医者の不養生」の例えがあるように、過信は禁物である。
もともとマネジメントに苦労した経営者が科学的かつ客観的な診断をするので自社の実力を正しく評価することができる。
「診断」は、自社の強い点や改善すべき点を明確にすることである。「宝のもちぐされ」ともいえる自社の強い点を発見することができる。

品質管理の草創期には産学協同で、日本の製品の品質をどう高めるかに重点がおかれた研究がされた。統計的品質管理を活用したデミング賞の審査も大いに貢献した。
デミング賞の審査は、二つの方法で運営される。
Ａスケジュールとよばれる審査は受診側から品質管理による成果が発表され、その範囲での質疑が行われる。この発表は主に品質保証のような部門間連携の活動の成果を中心に発表する。組織の特色である強い点をアピールしてそれをより強くするための審査をする。
もう一つの審査の方法は、Ｂスケジュールという方法で、これは審査側からの質問を中心におこなわれる。Ａスケジュールが機能別であったのに対し、部門や現場で現状把握するのが目的である。

さて、ISOの監査である。経営者自ら審査するのでなく、内部監査員が監査してその結果を報告するしくみである。経営の実務を知らない監査員がISO規格を基に監査するので、経営という側面より、規格の解釈に追われる。注意しないと形骸化したシステムを作るやりとりが多くなる。

正しい診断がされて、正しい治療ができる。
診断と治療はバランスがとれてなければならない。
診断のみ名人になっても、治療が不十分ではよくならない。
治療方法の開発に役立つ診断が必要である。

６．品質保証のプロセスに注意しよう

序文：ISO9001の品質マネジメントシステムの要求事項は品質保証に加えて顧客満足の向上をもめざしている。
序文　0.2：組織内のプロセスを明確にして、その相互関係を把握して運用管理する。
プロセスアプローチを実践するために、次を実践する。
要求事項を満足させる
付加価値を高めるプロセスをつくる
実施状況と有効性を把握する
プロセスの継続的改善を行う

ISO9001には、「製品実現」について詳しい要求事項がまとめられている。市場調査・設計・購買・製造について必要な項目はほぼ網羅されている。新製品開発管理や事業のプロセスを整理するのに役立つ。これは9001の特色であり、環境管理の14000など他の規格にない特色である。ただし、顧客の要求を中心にまとめられているため、運用にあたっては、組織の現状と実力に合わせて、実現可能な工夫をすべきである。

たとえば、9001の要求事項にそって、現状を考えないでフローチャートを書くととても長いものになる。そのとおり運用しようとしても、忙しい製品開発の時間内では実行できない。その結果が、実務とISOの二重帳簿になる。

自動車業界に特化したISO/TS16949では、運用にあたっての細部の工夫が追加されている。「部門横断的アプローチ」「かんばん」「ＱＦＤ」など過去に開発した手法があげられているが、形だけ導入しても成果が得られるはずはない。注意しないと折角の改善の処方箋が形骸化の道具になることも考えられる。たとえば部門横断的アプローチはコンカレント・エンジニアリングといわれる部門間連携の考えである。ところが部門横断的アプローチは実際には会議体で運営されていることにとどまっている。会議は最終の確認事項を徹底するためにはよいが、具体的作業にはふさわしくない。会議で連携がされていると、ごまかしていてはISO規格にある「プロセスを明確にして相互関連を把握し運用管理する」ということがほとんど実行されないことになる。

ISOで整備しなければならないプロセスは部門内のプロセスよりも、部門間のプロセスである。この部門間、プロセス間の整備がされないISOは役に立たない。


確約、確保、確認
ISOでは品質保証と顧客満足を別にとらえているが、顧客満足のない品質保証はない。
また、顧客の要求のみ満たすシステムを作っても企業内部の役に立つシステムでないなら、実践できるシステムにならない。最近、顧客をだますような程度の低いうそが蔓延するのは、品質保証と顧客満足を分けて考えるからである。顧客も供給者も共に満足するためには、顧客と供給者が同等の関係でなければならないが、顧客のみの満足を考えたシステムは供給者側から考えると無理の多いシステムになる。
従来の日本の品質文化では顧客満足と品質保証という本来、相反する目的の整合性をとりながら一つのシステムに組み込んで運営していた。欧米流の契約社会の品質管理と日本の品質管理の良さを考え直す段階に来ている。現在の世界の矛盾を考えれば、欧米流の契約社会の限界がわかるはずである。

品質保証とは、顧客の要求のうち出来ることを約束（確約）し、それを開発のプロセスや製造工程でつくりこみ（確保）、確約されたことが実現したか確認するプロセスである。この確約、確保、確認の全体を品質保証という。
また、品質保証は多くの活動で成り立っているが、一つ一つの活動に、確約、確保、確認がある。また、目的により結び合わされた活動の全体を品質保証体制とよぶ。日本の品質管理は品質保証を品質管理の目的と考え、品質保証体制の整備をおこなってきた。

品質保証体制は品質保証のフローチャートで表現するが、品質保証活動の相互関連を理解するのによいが、個々の活動の前後関係や活動の詳細であるインプットとアウトプットの関連などは、一覧表にまとめるとよい。これを品質保証活動一覧表とよぶ。
また、インプットとアウトプットは具体的帳票にしたほうが情報の受け渡しの漏れがなくなる。この品質保証に役立つ帳票、品質表、ＱＡ表、ＱＣ工程表、作業標準書などを関連付けることを品質展開：ＱＦＤとよんでいる。当然要求品質の展開だけでなく、技術の展開も同期化しておかないと、目標とする品質の達成はできない。

このように考えていくとシステムが膨大になり実行に無理が生じる。
技術的にも全くの新規を開発する場合と簡単なマイナーチェンジの場合とでは、品質保証活動は区別すべきである。基本とするシステムを製品にあわせてどのように運営するか決め、品質保証計画を作成する。またこのような品質保証のパターンを決めたものを「スキップ標準」などとよんでいる。新製品開発は大きなプロジェクトだからそのＱＣＤの総合管理のために「PERT/QC」と呼ばれる手法が使われることがある。
このように考えただけでもシステムは複雑になるが、企業、開発の実態にあわせて実行可能なシステムを検討すべきである。