|
|
| １ |
ISO9001
2008年版(追補)
改訂の要点 |
| ５ |
実務の視点による
ISO9001:2000
の解説 |
|
| 今後の予定 |
購買管理
製造及びｻｰﾋﾞｽ提供
内部監査
ﾌﾟﾛｾｽの監視、測定
製品の監視、測定
不適合品の管理
是正処置
予防処置 |
|
| ５ |
実務の視点による ISO9001:2000の解説 |
ISO9001規格に関する国内の解説は、ほとんどすべてが認証審査に合格するために何をしなければならないかの説明であり、規格を組織に対する"要求"を定めたものとの考えで、条文の日本語から"要求"に対応する業務の形式を導き出している。 それも、ISOやTC176の発表する解説や指針文書は参照されず、他との解釈の相違にも触れず、論理が明かされないままでの断定である。これは他の先進国には見られない情景である。
このような解説は審査合格への早道を求める組織にとっては好都合だが、結果的には組織も登録証を利用する社会も規格の狙いの利益を享受することには繋がらない。
拡大する規格や登録証への不信の真の源は、このような規格解釈を基礎とする規格取組みにある。
規格は、1980年代に品質で世界を席巻した日本製造業のﾏﾈｼﾞﾒﾝﾄを下敷きに世界の企業の成功体験を反映した論理の体系である。 規格は組織を発展に導く効果的なﾏﾈｼﾞﾒﾝﾄたるに必要な条件を示している。規格は組織の利益に資されるためにあり、いらぬ負担を課し、又は、その活動を制約する意図はない。
規格についてのこのような実務の視点から、規格の論理に基づいて要求事項について解説する。
詳しくはこちら <35-01-00> |
| 目 次 |
その50 7.5.2項 製造及びｻｰﾋﾞｽ提供に関するﾌﾟﾛｾｽの妥当性確認
その49 7.5.1項 製造及びｻｰﾋﾞｽ提供の管理
その45 7.3.7項 設計・開発の変更管理
その44 7.3.6項 設計・開発の妥当性確認
その43 7.3.5項 設計・開発の検証
その42 7.3.4項 設計・開発の ﾚﾋﾞｭｰ
その41 7.3.3項 設計・開発の ｱｳﾄﾌﾟｯﾄ
その40 7.3.2項 設計・開発の ｲﾝﾌﾟｯﾄ
その39 7.3.1項 設計・開発の計画
その38 7.2.3項 顧客との ｺﾐｭﾆｹｰｼｮﾝ
その37 7.2.2項 製品に関連する要求事項の ﾚﾋﾞｭｰ
その36 7.2.1項 製品に関連する要求事項の明確化
その35 7.1項 製品実現の計画
その34 6.4項 作業環境
その33 6.3項 ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ
その32 6.2.2項 力量、認識及び教育・訓練
その31 6.2.1項 人的資源 一般
その30 6.1項 資源の提供
その29 5.6.3項 ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ からの ｱｳﾄﾌﾟｯﾄ
その28 5.6.2項 ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ への ｲﾝﾌﾟｯﾄ
その27 5.6.1項 ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ 一般
その26 5.5.3項 内部コミュニケーション
その25 5.5.2項 管理責任者
その24 5.5.1項 責任及び権限
その23 5.4.2項 品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの計画
その22 5.4.1項 品質目標
その21 品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ の計画
その20 5.3項 品質方針
その19 5.2項 顧客重視
その18 5.1項 経営者のコミットメント
その17 4.2.4項 記録の管理
その16 4.2.3項 文書管理
その15 4.2.2項 品質マニュアル
その14 4.2.1項 文書化要求事項 一般
その13 4.1項 一般要求事項(3) -アウトソースの管理-
その12 4.1項 一般要求事項(2) -プロセスアプローチの要求事項-
その11 4.1項 一般要求事項(1) -品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑのPDCAサイクル-
その10 要求事項の構成
その９ 品質マネジメントの原則 (マネジメント活動の方法）
その８ 品質マネジメントの原則 (マネジメント活動の実行主体)
その７ 品質マネジメントの原則 (マネジメント活動の方向)
その６ 品質マネジメントの原則 (その意図)
その５ 顧客要求事項
その４ 継続的改善
その３ プロセスアプローチ
その２ 品質マネジメント
その１ 顧客満足
|
|
|
その50. 7.5.2項 製造及びｻｰﾋﾞｽ提供に関するﾌﾟﾛｾｽの妥当性確認 |
<[7.5.2項]の概要>
本項は、製品での検証が不可能な場合の製品の品質保証のあり方を、「製造及びｻｰﾋﾞｽ提供の計画」(7.5.1項)の結果の妥当性の検証を行うこと、及び、「管理された状態」(同項)で実行されるための追加的要件として示している。
<ﾌﾟﾛｾｽの妥当性確認>
「妥当性確認」は、物事の目的に関する要件が満たされていることを客観的証拠で以て明確にすることである。「ﾌﾟﾛｾｽの妥当性確認」とは、「ﾌﾟﾛｾｽの計画活動」の結果で定めた工程条件が実際に所定の製品仕様の製品を生み出すことができるものであることを客観的証拠で以て明確にすることである。
<検証が不可能な製品特性の管理>
品質保証の観点では不適合製品を顧客に出荷又は引渡さないことを確実にする手はずとして、製品を監視測定し合否判定基準を満たしていることを検証する必要がある。
しかし、製品や製品特性の種類によって、製品特性を「容易に又は経済的に検証できないﾌﾟﾛｾｽ」がある。規格はこれを「特殊工程」として区別し、この場合のいわゆる工程保証の考えに基づく品質保証のあり方を要求事項として規定している。
しかし実務においては、製品特性を監視測定できない場合も、そのような特性の品質保証に適用される手段、手法も多種多様である。
不適合製品を顧客の手に渡さないこと確実にするという観点から、製品で監視測定、検証のできない特性は何か、どのような別の方法の適用が可能かを検討するという姿勢が大切であり、本項の要求事項はその検討の要素として活用することができる。
<規格要求事項とその真意>
「製造及びｻｰﾋﾞｽ提供のﾌﾟﾛｾｽの妥当性確認」とは、特定の製造又はｻｰﾋﾞｽ提供工程について定められた工程条件が、その工程の目的の製品仕様の製品を生み出す能力があることを客観的証拠によって明らかにすることである。「妥当性確認」された工程条件で製造又はｻｰﾋﾞｽ提供工程が実行されれば、確実に所定の製品仕様の製品を得ることができる。出荷又は引渡し前に製品の特性を監視測定して検証できない場合は、関係する「ﾌﾟﾛｾｽの妥当性確認」が必須であり、当該工程の業務や作業が定められた工程条件に確実に則ったものとする「管理された状態」で実行されなければならない。「管理された状態」の手はずを確立する際には、7.5.1
a)～f)項に加えて、本項のa)～e)項をも考慮しなければならない。
製品の検証が不可能な場合、製造及びｻｰﾋﾞｽ提供のﾌﾟﾛｾｽの妥当性確認を行う： 製品の特性が監視又は測定で検証することが不可能な場合には、定められた工程条件が所定の製品仕様の製品を生み出す能力があることを客観的証拠によって明らかにすることが必須である。この客観的証拠及び判断に関するﾃﾞｰﾀや文書は、記録として管理することが必要である。
製品の使用、ｻｰﾋﾞｽの提供の後にしか不具合が顕在化しないﾌﾟﾛｾｽを含む： 製品での検証ができない場合と同じ意味。JIS和訳「ｻｰﾋﾞｽが提供されてから」は「ｻｰﾋﾞｽが引渡されてから」の誤訳。
妥当性確認によって、ﾌﾟﾛｾｽが計画どおりの結果を出せることを実証する：「製造及びｻｰﾋﾞｽ提供のﾌﾟﾛｾｽの妥当性確認」の意味を説明している。
これらのﾌﾟﾛｾｽについて、次のうち適用できるものを含んだ手続を確立する： 「手続き」ではなく「手はず」である。製品検証が不可能な製品の品質保証のためには、特別な手はずが必要である。これを含めた「管理された状態」の手はずを整えることが必要である。
ﾌﾟﾛｾｽのﾚﾋﾞｭｰ及び承認のための明確な基準： 「ﾌﾟﾛｾｽのﾚﾋﾞｭｰ及び承認」は、工程実行結果を評価し、合否の判定をすることを意味し、「明確な基準」は、この合否判定基準が明確に定められているという意味である。
設備の承認： この「設備」は、広く物的資源の意味の「ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ」のことであり、更に、ｻｰﾋﾞｽ提供活動では室内装飾、商品展示棚、制服、舞台装置なども含め、原材料、部品、部材なども含めるのがよい。必要な性能や機能を持っていることが明確にされた「設備」が特定の条件で使用されることが必要。
要員の適格性確認： 原英語は“qualification of personnel”であり、「適格性の明確化」の意味である。特定の業務ないし作業を、十分に訓練されて熟達した、又は、特定の専門性や技能を持った要員に委ねることが必須の場合がある。これは2000年版では“competent（力量がある）”に用語が置き換えられ、すべての要員は「力量がある」。製品検証が不可能な工程を委ねる要員には、必要な力量のあることを特に確実な方法で、特に厳密に評価し判断すべきことを指摘していると理解するのがよい。
所定の方法及び手順の適用： 「特定の方法及び手順」は、特定の工程条件のこと。これが定められ、実行されるような手はずが確立し、この下で実行されていなければならない。
記録に関する要求事項： 工程条件の実績は監視測定され、定められた合否判定基準に照らして合否の判定が行なわれる。この合否判定の基となる諸ﾃﾞｰﾀと合否判定の結果は、「記録」として管理されなければならない。
妥当性の再確認： 定めた工程条件に変更が必要な状況が生ずれば、これを見直し、変更された工程条件が所定の製品仕様の製品を生み出す能力があることを、改めて客観的証拠で明確にしなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-50> |
|
その49. 7.5.1項 製造及びｻｰﾋﾞｽ提供の管理 |
<[7.5.1項]の概要>
本項では、製品実現の計画(7.1項)の一環として製造及びｻｰﾋﾞｽ提供工程を計画し、その結果の製造及びｻｰﾋﾞｽ提供の諸業務を「管理された状態」で行なうことの必要を規定し、また、「管理された状態」であるための要件を規定している。
<製造及びｻｰﾋﾞｽ提供のﾌﾟﾛｾｽ>
「製造及びｻｰﾋﾞｽ提供」は、「製品実現」の相互に関連する一連の業務のひとつであるが、それ自身もまた、相互に関連する複数の業務から成っている。
一般には“production”(製造、制作など)だが、ｻｰﾋﾞｽという製品は“service
provision”(ｻｰﾋﾞｽ提供)と表現される。規格は、これを「内部処理」とそれに引続く「ﾘﾘｰｽ」「引渡し」「引渡し後」の各活動に分けている。
内部処理には、ﾌﾟﾛｾｽ及び製品の「監視及び測定」を含み、購買など関連する製造及びｻｰﾋﾞｽ提供工程以外の業務との接点の活動も含む。「ﾘﾘｰｽ」が製品を組織から外に出すことであるのに対して、「引渡し」は製品を顧客に渡すことである。業種や製品によっては、内部処理、「ﾘﾘｰｽ」「引渡し」が区別できない。「引渡し後の活動」は製品を顧客に引渡した後の製品に関して行なう活動であり、別の独立したｻｰﾋﾞｽとして運営されることも多い。これらの活動には、それ自身が製品の顧客満足に影響するものと、その活動に対する顧客の受けとめ方を通じて間接的に影響を及ぼすものとがある。
<製造及びｻｰﾋﾞｽ提供の計画>
「製造及びｻｰﾋﾞｽ提供の計画」活動は、製品実現の計画活動(7.1項)の一環であり、定めた製品仕様((7.1
a)項)の製品をどのように製造又はｻｰﾋﾞｽ提供するかを決定し、その実行の手はずを整えることである。
実務的には、成約又は受注した製品に関して所定の製品仕様を生み出すための工程設計と、所定の納期と数量を満たすための日程設計を行なうことである。
工程、日程設計の結果は、それに基づいて製造及びｻｰﾋﾞｽ提供を実行すれば間違いなく所定の製品仕様の製品が得られるものでなければならない。定めた工程条件の有効性は規格では「妥当性(validity)」であり、適当な方法と厳密さで評価し承認することが必要である。
<製造及びｻｰﾋﾞｽ提供の実行管理>
製造及びｻｰﾋﾞｽ提供の諸業務は、所定の製品の実現を狙いとして、日程を含む定められた工程条件で効果的に実行されなければならない。同時にこれと繋がりのある他の諸業務も定められた通りに実行されることが必要である。
これを図る製造及びｻｰﾋﾞｽ提供の実行管理では、定められた工程条件で間違いなく諸業務が行なわれるような状態を維持し、また、業務実行状況を監視測定しなければならない。規格では前者は「管理された状態」である。後者では、がどのようなものであるかを表す特性の「工程ﾊﾟﾗﾒｰﾀｰ」を定められた方法で監視又は測定し、監視測定の結果は、定められている工程ﾊﾟﾗﾒｰﾀｰの許容範囲に照らして、良否や合否が評価される。これを製品の適合性の監視測定によって評価することもよい。
<規格要求事項とその真意>
94年版の4.9項(工程管理)が、あらゆる業種に適用できる汎用表現で、本項と7.5.2項に分れ、また、他の条項に整理された。
製造及びｻｰﾋﾞｽ提供を計画する： この計画は製品実現の計画活動(7.1項)の一環である。組織のこの手順には、製造及びｻｰﾋﾞｽ提供工程の計画活動をいつ、誰が実行し、製造及びｻｰﾋﾞｽ提供工程の諸業務の実行と管理に関して、何と何を、何に基づいて判断し、決定し、その結果を何にどのように表すかの手順が含まれていなければならない。また、この製造及びｻｰﾋﾞｽ提供の計画活動の手順には、計画活動の有効性を評価し、承認する手順が含まれていなければならない。
製造及びｻｰﾋﾞｽ提供を管理された状態で実行する： 業務は計画活動の結果に則って行なわれなければならない。 計画された通りに効果的に業務が行なわれることを確実にする状態が「管理された状態」である。
製品の特性を述べた情報が利用できる： この「製品の特性」とは、製造及びｻｰﾋﾞｽ提供工程で生み出すべき製品の製品仕様のことである。それぞれの要員、部門、職場では、その時点でどのような製品を生み出すことに携わっているのか、その時点の業務で実現すべきものは何か、が正しく理解できるようになっていなければならない。
必要に応じて、作業手順が利用できる： 所定の製品仕様の実現のためにとりわけ重要な作業、また、複雑な作業、間違いを冒し易い作業については、作業の方法と基準の詳細を規定した「作業手順書*」を、要員が利用できるようにしておかなければならない。
適切な設備を使用している： 個々の製品に対して使用することを決められた設備が間違いなく使用されるようにしなければならない。 表現上は「設備」だが、広く「ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ」(6.3項)のことと理解しなければならない。
監視機器及び測定機器が利用でき、使用している： この「監視機器及び測定機器」は、7.6項の標題と同じく「監視及び測定の手段」の意味である。 業務実行又は製品に関して定められた監視測定手段が使用できるよう、また、使用されるようになっていなければならない。
監視及び測定が実施されている： 定められた監視測定が、間違いなく行なわれるようになっていなければならない。
ﾘﾘｰｽ、顧客への引渡し及び引渡し後の活動が実施されている： 引渡した製品に顧客の所定の満足を得るために必要な「内部処理」以降の活動が定められた通りに実行されるようになっていなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-49> |
|
その45. 7.3.7項 設計・開発の変更管理 |
<7.3.7項の概要>
本項では、設計開発活動中の製品仕様の目標又は確定した製品仕様を変更するための設計開発活動が、所定の顧客のﾆｰｽﾞと期待を満たすものであることを確実にするための設計開発活動の管理の要件を規定している。
<設計・開発の変更>
「設計・開発の変更」は「設計開発活動に関連する変更」という意味合いでの「設計開発活動の変更」であり、設計開発活動中に目標の製品仕様を変更するために設計開発活動の計画を変える、或いは、設計開発活動で確定した製品仕様を変更するために過去の設計開発活動をやり直す、という意味である。いずれの変更も、設計開発活動の結果の製品仕様の変更が目的であるから、「設計開発活動の変更」とは実質的には「製品仕様の変更」である。
<設計・開発の変更管理>
製品仕様の変更のために行なう設計開発活動が、製品仕様変更の所定の狙いの顧客満足を間違いなく、かつ、所定の期間と資源で実現することができるようにするためには、当該の設計開発活動を管理しなければならない。「設計・開発の変更管理」は、このような設計開発活動の管理のことであり、実質的には製品仕様の変更の管理である。
本項は、設計開発活動における妥当性確認が、設計開発活動の結果の製品が実際の使用環境で機能し、問題を起こさないことを確実にするための手段であることを明確にし、そのような妥当性確認についての要件を規定している。
<規格要求事項とその真意>
設計・開発の変更を明確にし、記録を維持する： 実施した設計開発活動の結果の製品仕様の変更を識別し、文書に記述しておかなければならない。 製品仕様の変更を実施した場合には、いつ、どれをどのように変更したのかを、製品仕様書、図面、模型、限度見本、評価試験報告書など当該製品の当該箇所の仕様を表す文書や記録に明示し、その変更が事後の必要に応じて識別できるようにしておかなければならない。
変更に対して、ﾚﾋﾞｭｰ、検証及び妥当性確認を適宜行う： 製品仕様の変更は設計開発活動によって達成される。 この変更のための設計開発活動が効果的、効率的であることを確実にするためには、一般の設計開発活動の管理の手段及び要件(7.3.1～7.3.7項)を適用することが必要である。ただし、初めての設計開発活動ではないので、変更した点と関係ない活動や結果については、検証、妥当性確認、ﾚﾋﾞｭｰ を相応に簡略化又は省略できる。
変更を実施する前に承認する： 設計開発活動の結果の新製品仕様を組織として確定し、権威づけ、関係する業務に使用又は適用する前には、適切であり、問題ないとする責任者による判断と決定に基づく承認が必要である。
設計・開発の変更のﾚﾋﾞｭｰ には、変更が製品を構成する要素及び既に引渡されている製品に及ぼす影響の評価を含める： 製品仕様の変更のための設計開発活動において実施される ﾚﾋﾞｭｰ は、通常の設計開発活動における ﾚﾋﾞｭｰ の場合の問題の評価(7.3.4項)だけではなく、製品仕様を変更したことが出荷済みの製品の適切な使用や使い勝手に悪い影響を及ぼすことがないかどうかの評価を行い、問題があれば必要な処置を決めなければならない。
変更の ﾚﾋﾞｭｰ の結果の記録及び必要な処置の記録を維持する： 変更のための設計開発活動に関する ﾚﾋﾞｭｰ、検証、妥当性確認の記録も、7.3.4, 7.3.5, 7.3.6項のそれぞれの規定に則って管理しなければならない。これに加えて実施した上記3.(4)の ﾚﾋﾞｭｰ ととった処置についての記録も維持することが必要である。
|
| このページの先頭へ |
詳しくは<sub35-01-45> |
| その44. 7.3.6項 設計・開発の妥当性確認 |
<[7.3.6項]の概要>
本項は、設計開発活動における妥当性確認が、設計開発活動の結果の製品が実際の使用環境で機能し、問題を起こさないことを確実にするための手段であることを明確にし、そのような妥当性確認についての要件を規定している。
<設計・開発の妥当性確認>
この原英語は validationであり、産業界においてこのvalidationとverification(検証)とは対をなす用語として広く、また、前者は仕様を満たしているかどうか、後者は目的に適っているかどうかをそれぞれ評価する活動に関して使用されている。規格の「妥当性確認」は、｢客観的証拠を提示することによって、『特定の意図された用途又は適用』に関する要求事項』が満たされていることを確認すること｣であり、「確認する」の原英語の
confirm は、「(とりわけ証拠の提示により) 確かに真実であり又は正しいということを述べ又は示す」という意味であるから、「妥当性確認」とは、客観的証拠によって物事の目的に関する必要を満たしていること、或いは、目的に適っていることを明らかにすることである。
“妥当性の明確化”である。
JIS標題「設計・開発の妥当性確認」は「設計開発活動における妥当性確認」という意味であり、設計開発の結果の製品が実際の必要を満たして機能することを明らかにすることである。この妥当性確認は、94年版で取り入れられた概念と要件であるが、これは、計算機の
ｿﾌﾄｳｪｱ 分野では「計算機の奥深いところで起きる不思議な相互作用」がしばしばあり、特にこの分野に必要な設計開発活動の要素であると考えられたからであると説明されている。
どのような設計開発でも、その製品の用途や使用のされ方はそれなりに決まっており、それに関連する必要事項はすべて設計開発条件としての製品仕様の目標(7.3.2
a)項)に含まれていなければならない。 妥当性確認の目的は、製品の使用又はｻｰﾋﾞｽの引渡しの結果、想定できなかった問題がその使用や引渡しの環境との相性との関係で起きてしまうというようなことを防ぐことである。すべての必要事項が設計開発条件としての「規定要求事項」に織り込まれるなら、設計開発活動の結果(7.3.3項)は検証(7.3.5項)するだけでよく、論理上は妥当性確認は不要である。
<規格要求事項とその真意>
計画した方法に従って、設計・開発の妥当性確認を実施する： 設計開発の計画(7.3.1項)で定められた段階で定められた方法による妥当性確認を実施しなければならない。妥当性確認によって問題が生じる可能性を特定し、必要な処置をとらなければならない。
実行可能な場合にはいつでも、製品の引渡し又は提供の前に、妥当性確認を完了する： 妥当性確認は可能な限り、製品の顧客への引渡し前、又は、顧客が製品を使用する前に行なうことが必要である。
妥当性確認の結果及び必要な処置の記録を維持する： 使用した ﾃﾞｰﾀ などの情報を含む「妥当性確認」の結果の記録は、検証の記録(7.3.5項)と同様、次の設計開発活動に対する技術的引き継ぎであり、設計開発活動の方向づけのための「ﾚﾋﾞｭｰ」の重要な材料である。 また、これらと妥当性確認で判明した問題点と問題解決のための処置の記録も以降の製品使用で生じる品質問題への対応の基礎となる。これらのうち必要な事項の記録は、一連の設計開発記録として維持、管理しなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-44> |
|
その43. 7.3.5項 設計・開発の検証 |
<[7.3.5項]の概要>
本項は、設計開発活動における検証が、設計開発活動の結果が所定の条件を満たしたものであることを確実にするための手段であることを明確にし、この検証に関する要件を規定している。
<設計・開発の検証>
規格の「検証」とは、ある事が所定の要件を満たしているかどうか検討し、満たしていることを客観的事実によって明らかにすることである。
設計開発活動における検証は、設計開発活動の結果がその定められた設計開発条件を満たしたものであることを確実にするために実施される。検証によって、当該の設計開発活動が所定の結果を出したかどうかを判断し、問題があれば所定の結果を出すように必要な処置をとらなければならない。
<規格要求事項とその真意>
計画されたとおりに検証を実施する： 設計開発活動の計画(7.3.1 b)項)で定められた段階で、定められた方法によって検証を実施しなければならない。
検証の結果及び必要な処置の記録を維持する： 検証の記録は、後の設計開発活動に対する技術的引き継ぎであり、設計開発活動の方向づけのための「ﾚﾋﾞｭｰ」の重要な材料である。 設計開発の最終結果(7.3.3項)の検証の記録は、当該製品の有する性能や機能の種類と水準を示しており、以降の製品実現業務や製品使用で生じた品質問題への対応の基礎となる。検証によって判明した問題点と問題解決のための処置の記録で、以後の諸活動で参照する必要が生ずることがあるものについては、一連の設計開発記録として維持、管理しなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-43> |
|
その42. 7.3.4項 設計・開発の ﾚﾋﾞｭｰ |
<[7.3.4項]の概要>
本項は、設計開発活動の方向づけのために設計開発活動の重要な節目で行なう体系的 ﾚﾋﾞｭｰ に関する要件を規定している。
<設計・開発の ﾚﾋﾞｭｰ>
ﾚﾋﾞｭｰ (review)は、見直しや検討をすることの意味であり、規格では「ある事項が所定の目標達成という観点で適当か、十分か、有効かを決定するために行われる活動*」である。
「設計開発のﾚﾋﾞｭｰ」は、94年版が「包括的で体系的な活動」と定義していたが、2000年版でも「体系的なﾚﾋﾞｭｰ」である。
設計開発のﾚﾋﾞｭｰ は、設計開発活動の適当な段階で活動の目標や前提条件、或いは、それまでの進捗や結果に関して、広く関係する種々の観点から評価し、問題があればその解決に必要な処置を決め、計画の変更(7.3.7項)を含む設計開発活動の方向づけを行う活動である。
適切な段階で ﾚﾋﾞｭｰ を行なうことによって、設計開発活動がその計画の通りの期限や資源の範囲内で、顧客満足が得られる製品という所定の設計開発結果を出すことが可能になる。
<規格要求事項とその真意>
適切な段階で、計画された通りに体系的 ﾚﾋﾞｭｰ を行なう： 設計開発活動の計画では、必要な時点で ﾚﾋﾞｭｰ を行うよう計画することが必要である。 ﾚﾋﾞｭｰ (見直し、検討) にはろいろのやりかたがあり、それぞれの ﾚﾋﾞｭｰ の目的に合った方法で行なうべきであるが、「適当な( suitable)段階*」で行なう ﾚﾋﾞｭｰ は本項が規定する「体系的なﾚﾋﾞｭｰ」でなければならない。
次の事項を目的として体系的 ﾚﾋﾞｭｰ を行なう： 本項の規定する体系的な ﾚﾋﾞｭｰ は、次のa), b)項を行なう活動である。
設計開発結果が要求事項を満たせるかどうかを評価する： この「要求事項」は設計開発の目標、つまり、設計開発活動で達成すべき事項であり、「設計開発の結果」は「設計開発の ｱｳﾄﾌﾟｯﾄ 」(7.3.3項)と考えるのがよい。 ﾚﾋﾞｭｰ における評価は、それまでの設計開発活動やその時点での設計開発活動の結果を評価するのであるが、それがどうかということではなく、設計開発活動をこのまま計画通りに進めた場合にどうなるかという観点で評価することである。
問題を明確にし、必要な処置を提案する： JIS和訳「問題を明確にする」は、何か問題と思われることがあればそれを特定する、「提案する」は、問題解決のための処置を計画するという意味である。
ﾚﾋﾞｭｰ の参加者には、対象の設計・開発段階に関連する部門の代表が含まれている： 「関連する部門」とは、その段階の設計開発の目標や結果によって担当業務が影響を受ける、或いは、目標や結果に部分的にでも責任を有する部門という意味であり、「代表 (representative)」とは、ﾚﾋﾞｭｰ で当該部門の担当する業務機能の観点で情報を評価し、意見を述べ、ﾚﾋﾞｭｰ の結論を認めることができる能力と責任及び権限を有する者という意味である。
ﾚﾋﾞｭｰ の結果の記録及び必要な処置があればその記録を維持する： 何をどのように評価し、どのような問題を議論し、どのように問題解決したか、又は、どのような解決策の実施を決めたかを含めて、ﾚﾋﾞｭｰ の結論を記録しなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-42> |
|
その41. 7.3.3項 設計・開発のｱｳﾄﾌﾟｯﾄ |
<[7.3.3項]の概要>
本項は、設計開発の結果に関する要件及び設計開発結果の取扱いに関する要件を規定している。
<設計・開発からの ｱｳﾄﾌﾟｯﾄ>
設計開発ﾌﾟﾛｾｽ の ｱｳﾄﾌﾟｯﾄ とは、ｲﾝﾌﾟｯﾄ (7.2.2項)として与えられた設計開発の条件の下に実行された設計開発活動の結果であり、一連の特性の形で表された製品仕様のことである。設計開発の結果には製品仕様と共に、その背景にある設計開発の意図やｱｲﾃﾞｱ、及び、製品の特徴と適切な使用方法についての説明が付随していることが大切である。また、設計開発の立場から製品実現の諸業務の効果的、効率的な実行のために必要と考える事項を明確にすることも、設計開発活動の責任である。
規格では、これらも設計開発の ｱｳﾄﾌﾟｯﾄ に含めている。
<設計開発結果の確定>
設計開発の結果は、その仕様の製品が設計開発の条件を満たし、狙いの顧客満足を得ることができるかどうかに関して評価され、問題を解決した上で設計開発の責任者によって承認され、正式な製品の仕様として確定する。規格はこの評価の方法として、検証(7.3.5項)、妥当性確認(7.3.6項)、ﾚﾋﾞｭｰ(7.3.4項)を挙げている。設計開発結果の評価と確定をどの段階で、何に基づいて行うかは、設計開発の目的により様々である。確定した製品仕様は、設計開発の目的に応じて、実用化評価、受注活動、工程設計、又は、製造又はｻｰﾋﾞｽ提供のいずれかのために使用される。
<規格要求事項とその真意>
設計開発活動の結果は、次のa)～d)項を満たしていることが必要である。組織は、これらの要件を満たしていることを、評価し、適切であることを確認した上で、製品実現を図る製品の仕様及び関連必要事項であるとして確定する正式の決定を行わなければならない。組織は、設計開発の手順の中の、設計開発結果とその取り扱いに係わる手順が本項の要件を満たすことを確実にしなければならない。
ｱｳﾄﾌﾟｯﾄは、ｲﾝﾌﾟｯﾄ と対比した検証ができるような様式で提示される： 設計開発の結果の特性で表された製品仕様は、設計開発の条件を満たしているかどうかの評価や判断は、与えられた製品仕様の目標と設計開発基準のひとつひとつについて具体的な指標でもって科学的に行われなければならない。 JIS和訳「様式」は設計開発結果の検証記録の書式を伺わせるが、原英語はformatであるから、態様というより広い概念である。評価や判断の方法には、各特性の数値の比較、作成した模型による評価、試食や対面ｻｰﾋﾞｽ試行、ｺﾝﾋﾟｭｰﾀｰｼﾐｭﾚｰｼｮﾝ、一部又は全体機能の試行など様々な方法がある。設計開発の結果は、検証のために必要な態様の情報と共に示されなければならない。
次の段階に進める前に、承認を受ける： 設計開発の責任者は、設計開発の結果が本項のa)～d)項を満たしていることを評価し判断して、問題を解決した上で、製品の仕様を確定し、設計開発結果の製品を組織の供給する製品として正式に決定しなければならない。規格の意図は、適切であることが確認され正式なものと認められた設計開発結果しか、製品実現に適用してはならないということである。
ｱｳﾄﾌﾟｯﾄ は次の状態である： a)項は設計開発条件との関係での必要事項であり、b)～d)項は製品実現及び製品使用に関係する必要事項である。a)項は設計開発の検証(7.3.5項)により確認され、b)～d)項の情報が十分かどうか適切かどうかの評価や判断を行うのは通常、設計開発のﾚﾋﾞｭｰ(7.3.4項)の役割である。
ｲﾝﾌﾟｯﾄ で与えられた要求事項を満たす： 設計開発の結果の構造特性の製品が実際に、設計開発の目標の製品仕様の性能特性を満たしていることは、設計開発結果としての基本条件である。
購買、製造及びｻｰﾋﾞｽ提供に対して適切な情報を提供する： 個々の製品を効果的、効率的に製品実現するために必要な事項、或いは、特に配慮すべき事項、困難な事項などがあれば、それらを設計開発結果の中で明確にしておくことが必要である。 これには、購買、製造又はｻｰﾋﾞｽ提供に加えて包装や輸送、付帯ｻｰﾋﾞｽなど製品の引渡しや引渡し後の活動に関する事項も必要なら含まれなければならない。
製品の合否判定基準を含むか又はそれを参照している： 製品実現の計画では、製品仕様の目標と満たすべき関連仕様を明確にし、製品がそれを満たしているかどうかの合否判定基準を明確にすることが必要である。 設計開発結果の製品仕様の各特性は、それぞれが測定可能な表現となっていなければならず、狙いの顧客満足が得られるための特性のばらつきの許容範囲で示されることが必要である。
安全な使用及び適正な使用に不可欠な製品の特性を明確にする： 製品の問題ない使用のために、又は、使用で狙いの顧客満足を得るために、絶対に必要な製品の特定の使用方法や注意事項等があれば、それも設計開発結果の中で明確にしておくことが必要である。 これには、問題を起こす可能性のある製品の特性と事象、及び、製品性能発揮のための製品の特性の条件などがある。
|
| このページの先頭へ |
詳しくは<sub35-01-41> |
|
その40. 7.3.2項 設計・開発への ｲﾝﾌﾟｯﾄ |
<[7.3.2項]の趣旨>
設計開発の計画では、顧客のﾆｰｽﾞと期待を満たすように製品の仕様が決められることを確実にするよう、設計開発活動の目標と活動の進め方を決めることが必要である。
本項は、設計開発活動の目標と活動の進め方を適切に決めるための要件を規定している。
<設計・開発への ｲﾝﾌﾟｯﾄ>
設計開発の定義から、 ｲﾝﾌﾟｯﾄ とは、顧客のﾆｰｽﾞと期待であり、それらを実現する製品の仕様が
ｱｳﾄﾌﾟｯﾄ である。 設計開発 ｲﾝﾌﾟｯﾄ とは一義的には、製品仕様に関する設計開発活動の達成目標である。しかし、製品の仕様は、当該製品に必要な顧客満足を得るという観点だけでなく、組織の製造又はｻｰﾋﾞｽ提供能力やｺｽﾄなど組織の事業上の都合をも考慮されたものでなければならないし、設計開発活動は、組織の品質方針や設計開発活動の業務効率、或いは、製品の製造及びｻｰﾋﾞｽ提供の経済性や効率性など組織のﾆｰｽﾞを満たして、その目標を達成しなければならない。
設計開発活動の効果的、効率的な実行のために組織が定めた手順や基準、資源もある。
これらも「製品要求事項に関連する ｲﾝﾌﾟｯﾄ」である。設計開発の ｲﾝﾌﾟｯﾄ とは、設計開発される製品仕様に対する目標と共に、その仕様の満たし方、満たす方法論に関する方針や考え方を含む設計開発活動の条件という意味である。
<設計・開発への ｲﾝﾌﾟｯﾄ の決定>
製品仕様の目標は、顧客のﾆｰｽﾞと期待を間違いなく満たす製品であるために、7.2.1項の4つの視点から評価して決定されなければならない。この7.2.1
a)～c)項は、必要な顧客満足が確実に得られることを図る観点であり、d)項はﾌﾞﾗﾝﾄﾞ戦略や製品実現の能力、効率や経済性など組織の都合を織込む観点である。
設計開発活動は新規な製品に関して行われるが、大抵は過去に同様の製品の設計開発を行っているから、常に一から計画し実行するのは効率的ではない。
また、一般に、ある性能特性を構造特性に変換する技術的手段はひとつではなく、設計開発活動の狙いの製品に応じて選択され適用される。
この判断は単に技術的合理性の観点からではなく、顧客満足向上のため及び組織の都合のためという観点を含めた判断でなければならない。
これら過去の経験は設計開発基準として整理、確立するのが望ましいが、出来なければ、過去の設計開発活動の記録を適切に管理し、必要に応じて参照できるようにするのがよい。
<規格要求事項とその真意>
製品要求事項に関連する ｲﾝﾌﾟｯﾄ を明確にする： 組織は、設計開発する製品が必要な顧客満足を得られる製品であることを確実にし、また、設計開発活動の効果的、効率的な実行を確実にするための設計開発活動の条件を決定する手順を確立しなければならない。 設計開発条件を適切に、また、抜けなく決定するには、a)～d)項の観点から検討する必要がある。
記録を維持する： 決定した設計開発条件は、設計開発条件の決定や適切性の ﾚﾋﾞｭｰ において問題になった事項や変更された事項も含め、記録に残すことがのく必要である。
ｲﾝﾌﾟｯﾄ には次の事項を含める： 設計開発条件を決定する場合は、製品仕様の目標をまず、7.2.1 a)～d)項の観点で抜けなく適切に決定し、それと設計開発の進め方に関する必要事項を合わせて、次の a)～d)項の観点から検討し、抜けがないか、適切かを判断しなければならない。
機能及び性能に関する要求事項: 顧客のﾆｰｽﾞと期待とは基本的に、製品の機能や性能、効能、効用に関するﾆｰｽﾞと期待である。構造特性も例えば、極端に大きい、色がけばけばしいなどある一線を越えると問題になることもあり得る。 顧客が製品を使用する環境との相性も顧客満足には重要な要素であり、これに構造特性が関係する場合が少なくない。
適用される法令・規制要求事項： 本項は、意図、内容共に 7.2.1 c)項と同じである。
以前の類似した設計から得られた情報： 過去の個別の設計開発の記録、顧客の苦情の設計開発による解決事例の記録、又は、これらを体系的に整理して設計開発ﾃﾞｰﾀ集、設計開発事例集、更に、確立した設計開発基準を設計開発の指針、基準とすることによって設計開発活動の有効性、効率性を高めることができる。
設計・開発に不可欠なその他の要求事項： 設計開発条件の適切な抜けのない決定のために、 a)～c)項の観点からの検討だけでよいのか、他にもあるなら、それも設計開発条件の決定の手順に織り込まなければならない。
ｲﾝﾌﾟｯﾄ について、その適切性を ﾚﾋﾞｭｰ する： 設計開発条件を正式に決定する前には、それらが適切であるかどうかを、定められた関係者によって検討されなければならない。当該製品の顧客のﾆｰｽﾞと期待が正しく捉えられ、組織の事業上の都合を加味して適切に製品仕様の目標に反映されているかの検討がとりわけ重要である。
要求事項は漏れがなく、曖昧でなく、相反することがない： この「要求事項」は、上記のa)～d)項の「要求事項」を指す。ｲﾝﾌﾟｯﾄ を ﾚﾋﾞｭｰ する際の観点の一部と考えればよい。
|
| このページの先頭へ |
詳しくは<sub35-01-40> |
|
その39. 7.3.1項 設計開発の計画 |
<[7.3.1項]の趣旨>
7.3項は、顧客のﾆｰｽﾞと期待を「特性」の形で製品仕様として確定する活動である設計開発活動が、所定の目標を間違いなく所定の期間、予算で達成できるように、設計開発活動を管理する必要を示唆し、その要件を規定している。
本項では、設計開発活動の効果的な実行管理の基礎として、設計開発の計画を策定する必要、及び、その要件を規定している。
<設計・開発>
顧客のﾆｰｽﾞと期待は顧客要求事項と呼ばれ、その実体は製品に関する必要事項というあいまいなものであるから、組織はそれを基礎に製品を製品仕様の形で決めなければならない。
製品仕様は「そのものを識別するための特徴*」という意味の「特性」で具体的、定量的に表わされる。
製品の設計開発活動は、「要求事項を製品の、規定された特性に、又は、仕様書に変換する一連のﾌﾟﾛｾｽ*」であり、組織が把握し決定した当該製品に対するﾆｰｽﾞと期待から直ちに製品の仕様の「特性」まで具体化ができない場合は、設計開発活動によって「特性」を明らかにしなければならない。
<設計開発活動の管理>
設計開発活動は、考えや必要を具体的なものとして創造する活動である。
未知への旅であるから、予想しない障害に遭遇し進路の変更を迫られることがあり得る。
活動が多岐にわたり、多くの人々が設計開発活動を分担し、また、組織内外に多くの関係者が存在し、予算や日程の制約もある。
設計開発活動が所定の顧客のﾆｰｽﾞと期待を満たす製品を、定められた期間内で間違いなく創造するためには、設計開発活動を管理された状態で実行することが必要である。
規格は7.3項全体で、設計開発活動の効果的な管理のための要素とそれぞれの要件を規定している。
<設計開発活動の計画>
効果的な設計開発活動の管理の基礎となるのが、設計開発の実行計画である。
実行計画では、設計開発活動の範囲と責任を明確にし、そのために必要な種々の個別活動を特定し、それぞれの個別活動の目標と責任者、期間、期限を定め、そして、各個別活動間での業務の引渡しの責任を明確にし、更に、節目節目での全体活動の進捗評価と方向づけの機会を決めておくことが必要である。
これら計画は、設計開発の目的など必要事項と合わせて計画書として文書化することが必要である。
計画書の書式や内容は、設計開発の実行管理の手段として適当なものとして決めればよいが、規格が規定する実行管理の要素が明確になり、また、計画の進捗に応じて必要な書き込みが出来、記録としての体裁を考慮したものであるのが実用的である。
<規格要求事項とその真意>
7.3項では、所定の狙いを所定の期間、資源で完了するよう効果的に設計開発活動を行うために必要な管理の要件が規定されている。 組織は、設計開発の対象を明確にし、設計開発の着手を判断する責任、設計開発を実行する責任を含む、製品の設計開発に関する手順を確立し、その中で、7.3.1～7.3.7項の要求事項を満たすように、設計開発活動を管理する手順を確立しなければならない。 設計開発の活動はこの手順に則って実行され、管理されなければならない。
製品の設計・開発の計画を策定し、管理する： この「計画」も規格の中の他と同じく、「前もって手はずを整えること」の意味だが、この場合は、設計開発の実行を管理する基礎となる実行計画を意味する。組織は、設計開発活動の効果的な管理のために、設計開発活動を計画し、文書に記述する手順を確立しなければならない。 設計開発活動の定められた必要が生じた場合は、定められた実計画書を作成し、これを用いて設計開発活動の実行を管理しなければならない。
設計・開発の計画において、次の事項を明確にする： 効果的な計画であるためには、計画の中で次のa)～c)項を決定し、明確にしなければならない。
設計・開発の段階： 予期せぬ結果や、進捗に障害が生じるなど不確定要素の多い設計開発活動の管理には、設計開発活動を最終目標までの進捗に係わるいくつかの段階に分け、それぞれの段階で機能や目的別に個別の活動に分け、それぞれの日程や期間を明確にする管理の方式が効果的である。
各段階に適したﾚﾋﾞｭｰ、検証及び妥当性確認： 設計開発活動が間違いなく目標を達成するために必要な、設計開発の各段階の実行状況と結果の監視と評価の方法を決めておくことが必要である。 監視と評価の方法には、ﾚﾋﾞｭｰ(7.3.4項)、検証(7.3.5項)、妥当性確認(7.3.6項)がある。
責任及び権限： 設計開発の計画では、定めた個別の活動を初め、各段階で行う ﾚﾋﾞｭｰ、検証、妥当性確認など各業務、活動に関して、実行し、参画し、承認する人々を明確にしていなければならない。
ｸﾞﾙｰﾌﾟ間のｲﾝﾀｰﾌｪｲｽを運営管理する： ｲﾝﾀｰﾌｪｲｽ (interface)は、接点であり、規格の意図は「組織は、設計開発活動を行う異なるｸﾞﾙｰﾌﾟ間の接点の業務を、効果的な情報交換と明確な責任分担を確保できるように管理しなければならない」ということである。
設計・開発の進行に応じて、計画を適宜更新する： 設計開発活動の進捗によって未知の部分が明確になり、また、予想外の問題に遭遇することがあるから、一旦決めた設計開発の計画を詳細化し、又は、変更する必要が生ずる。 当初計画に追加や変更の必要が生じたならば、最新の状況を反映する計画に更新しなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-39> |
|
その38. 7.2.3項 顧客との ｺﾐｭﾆｹｰｼｮﾝ |
<[7.2.3項]の概要>
顧客の製品に関するﾆｰｽﾞと期待を把握し、顧客がそのﾆｰｽﾞと期待を満たして製品を使用するためには、顧客の意向を受けとめ、必要な情報を顧客に伝える情報交換の活動が必要である。
本項は、情報交換活動を実行すべき3つの分野を規定している。
<製品に関する情報交換>
組織が供給する製品に所定の顧客満足を得ることができるかどうかは、組織が顧客の想いを正しく把握し、顧客が製品を正しく理解し、使用することができるかどうかによる。
「ｺﾐｭﾆｹｰｼｮﾝ」は communication であり、これは情報交換活動の意味である。
情報交換の活動の狙いは、① 顧客の必要を見出し、組織が提供できる製品を伝えること、 ② 製品の使用のための情報を提供すること、及び、 ③ 引渡した製品に関する顧客の意見を把握すること であり、具体的な情報交換の活動としては、例えば、製品広報活動、営業活動、顧客ｻｰﾋﾞｽ活動、応札活動、注文受付け活動、及び、顧客からの使用方法照会対応活動、苦情処理活動がある。 また、製品引渡し活動、引渡し後のｻｰﾋﾞｽ活動などでも顧客との間の情報交換を伴う。 情報交換の場として顧客との定期的な会合がもたれ、非公式の会合や対話という形でも情報交換が行われる。
<顧客対応の活動>
情報交換活動は組織と顧客との接点で行われ、情報がやりとりされたというｻｰﾋﾞｽ
のｻｰﾋﾞｽ提供活動とみなすことができる。 例えば、製品使用についての照会に対する組織の応答や体制に顧客が不満を覚えると、製品には問題がなくとも、次の機会には組織の製品を選ばない。
逆に、申立てた製品の苦情への組織の対応が、顧客の抱いた不満を解消させ、組織と製品への信頼を向上させることもある。
顧客との情報交換活動は、製品に関する顧客のﾆｰｽﾞや期待を把握し、顧客のﾆｰｽﾞや期待が満たされるよう製品が使われることを確実にするために効果的に行われることが必要であるが、その活動自身に関する顧客のﾆｰｽﾞや期待に応え、顧客に良い印象を与えつつ行われることも必要である。
<規格要求事項とその真意>
ｺﾐｭﾆｹｰｼｮﾝ を図るための効果的な方法を明確にし、実施する： この原英文は、「組織は、顧客と情報交換するための効果的な手はずを整え、顧客と情報交換を行うこと」と読むのが適切である。 他の条項の表現を借りるなら、情報交換活動を「計画し、実施すること」であり、情報交換活動の手順と資源を用意し、それを基に情報交換を行うことの意味である。 組織は、組織が顧客のﾆｰｽﾞと期待を正しく把握し、顧客が製品を正しく理解し、使用することを確実にするように、a)～c)項に関連して顧客との情報交換の手順と資源を確立し、情報交換を行わなければならない。 同時に、それぞれの情報交換活動に関する顧客のﾆｰｽﾞや期待を満たすような手順と資源で以て行われることが必要である。
製品情報： この情報交換活動には、例えば、広告、ｶﾀﾛｸﾞ供覧、ﾒﾆｭｰ表示、見本展示、店頭の製品説明、製品説明書や製品取扱い説明書の製品への添付、電話相談窓口での応答などがある。 組織の発信する情報は、わかり易く、顧客の知りたいことに対して的確で、正確で、顧客に誤解されないような表現でなければならず、言い違い聞き違いは避けなければならない。 顧客に対応する組織の要員は、必要な情報と業務遂行力(6.2.1項)をもっていなければならない。 新規製品や製品の改善などによる製品情報の変更には、文書管理の手順(4.2.3項)が適用されなければならない。
引き合い、契約若しくは注文、又は、それらの変更： 顧客からの製品の引き合いや申し込みを受付ける部署を明確にし、手段を整備し、手順を確立し、それを組織の製品に興味を抱き又は購入を希望する顧客がわかるようにしておかなければならない。また、 一旦合意した注文や契約が変更される場合の受付けと対応の方法、手順、変更受付可否の基準が明確になっていることが必要である。対応する要員の業務遂行力(6.2.1項)や必要な情報やその他の資源を準備しなければならない。
苦情を含む顧客からのﾌｨｰﾄﾞﾊﾞｯｸ： これは、顧客及び顧客の製品使用に関係する情報を入手するための情報交換活動のことであり、苦情を受付け、対応し、原因と再発防止対策を説明することに関する活動を含む。 顧客ﾌｨｰﾄﾞﾊﾞｯｸ は顧客が発信するものを受け取るだけではなく、組織が収集しなければならない。 組織が顧客ﾌｨｰﾄﾞﾊﾞｯｸ情報の収集に示す強い関心は、顧客の組織への信頼感と製品の顧客満足の醸成の促進につながる。
|
| このページの先頭へ |
詳しくは<sub35-01-38> |
|
その37. 7.2.2項 製品に関連する要求事項の ﾚﾋﾞｭｰ |
<[7.2.2項]の趣旨>
組織は、顧客との取引において製品に関する顧客の意向を誤って受け取ることのないようにしなければならない。本項は、顧客の意志表示を受けとめる種々の機会において、錯誤を防止するための要件を規定している。
<製品に関連する要求事項のﾚﾋﾞｭｰ>
製品の取引では、顧客はある使用目的でこのような製品がほしいとﾆｰｽﾞや期待をもっており、組織がこの顧客の意向を間違って受けとめては、引渡した製品は顧客には異品や不良品であり、そこまででなくとも顧客の満足は得られない。
組織が顧客の意向を誤って受けとめる原因には、顧客の意思表示の誤りと組織の受取りの誤りがある。
錯誤のほとんどは、顧客の引合い、発注又は注文申込みの機会に生じるが、一旦伝えられ又は合意された顧客の意向の変更を顧客が組織に伝えなかったり、伝えられた変更を組織が適切に処理しないことで結果的に生じ、また、契約交渉で当初の顧客の意向が協議され変更されたのにどちらかが変更を適切に処理しないことでも錯誤が生じる。
組織は、顧客の意向を間違いなく特定するのに必要な事項を明確にし、これについて顧客の意思表示を求め、又は、組織が確認することが必要である。これを文書にするとより効果的に確認ができる。
更に、双方又は組織が、この文書で内容を確認し、間違いがないと判断した証拠を残すこと、例えば、契約書を交わすことにより、錯誤の回避を一層確実なものとすることができる。
組織が錯誤防止の手順を確立する場合は、対象の錯誤の生じる業務又は機会を特定し、それ毎に、錯誤の生じ易さ、錯誤の結果で生じる顧客不満足の深刻さ、或いは、錯誤の結果の組織の損害の大きさなどを勘案することが大切である。
<規格要求事項とその真意>
製品に関連する要求事項を ﾚﾋﾞｭｰ する： 製品の取引において顧客の意向把握に錯誤の生じることを防止するために、取引受諾の前に顧客の意思表示に問題ないか、間違っていないかを検討することが必要である。このために、錯誤の可能性のある業務又は機会を特定し、錯誤を効果的に防止できるようにそれらの業務手順を確立しなければならない。 本7.2.2項は、錯誤を効果的に防止するための要件を規定している。 規定の順序や規定間のつながりには意味があるとは考えない方がよいし、業種業態によっては該当しない規定もあるし、或いは、不足している要件や要素があるかもしれない。該当しない規定、つまり、条文は、適用除外すればよい。
ﾚﾋﾞｭｰ は、顧客に製品の提供の ｺﾐｯﾄﾒﾝﾄ をする前に実施： ｺﾐｯﾄﾒﾝﾄ は、取引契約といった正式の約束という意味である。 この取引約束の機会として規格は、新規の製品の引合いと応札、契約や受注、及び、契約や受注の変更を受諾する場合の3つの場合を例示している。
ﾚﾋﾞｭｰ では次の事項を確実にする： 検討は、次のa)～c)項の観点で行うのが効果的である。規格は、a)～c)項の「・・・となっている」状態を「確実にする」こと、という表現で、検討の目的が問題を正すことであることを明確にしている。
製品要求事項が定められている： 「定められている」は are definedであるから、「正確に述べる又は示す」の意味(1)である。 顧客の意向の製品を特定するために必要な製品関連仕様がすべて明確にされているかどうかという確認をすることである。
契約又は注文要求事項が以前と異なる場合には、それについて解決されている： 「契約又は注文の要求事項」とは本項では、どのような製品であるかに関して、組織と顧客が合意した或いは意思表示した内容のことである。「解決されている」は、 are resolved であり、趣旨は「違いが解消されている」ということである。 以前の同じ製品に関する取引があり、組織が当該注文に関する顧客の意向を自分なりに把握している取引では、顧客の意思表示の内容が自らの考える内容と合致しているかどうかを確認することにより、万一の錯誤を防止できる。
定められた要求事項を満たす能力をもっている： 一旦約束したが、技術的、製品実現能力上などの理由で、その製品関連仕様の製品を実現できない、或いは、定められた期限や数量を満たすことができないというような場合があり得る。組織は顧客の意思表示の要件が組織で実現可能なことを取引受諾の前に確認することが必要である。
ﾚﾋﾞｭｰの結果ととられた処置の記録を維持する： 錯誤を防止するために、錯誤防止の定められた手順が効果に実行され、問題なかった、或いは、問題をこのように処理したという記録を残すことが大切である。 記録をとることは、手順が抜けなく確実に実行されるようにするために役に立ち、この記録を維持することは事後に顧客と問題が生じた場合に対処に必要である。
顧客が書面で示さない場合には、確認する： 口頭による契約や注文の受付けと受諾は、双方の認識に錯誤をもたらしやすい。英原文の趣旨は、口頭の顧客の意思表示を組織がどのように受け取ったかについて顧客に確認を求めることが必要であり、それは取引受諾を約束する前に行わなければならないということである。
製品要求事項が変更された場合は、関連文書を修正し、関係者の理解を確実にする： 変更は顧客と組織のどちらからも行われることがある。変更の通知が口頭の場合は、上記(8)に準じ、製品実現の工程にある製品に関する変更は、上記(6)に準じ、変更の経緯と結果の記録の管理は、上記(7)に準じて行う。 業種業態によっては、文書管理の手順(4.2.3項)に製品実現の各業務、部署に発行済みの文書を緊急に変更、差替え、内容徹底する手順が必要なこともある。
|
| このページの先頭へ |
詳しくは<sub35-01-37> |
|
その36. 7.2.1項 製品に関連する要求事項の明確化 |
<[7.2.1項]の趣旨>
組織は、製品が組織の必要とする顧客満足を間違いなく得るように、顧客のﾆｰｽﾞと期待を把握して製品関連仕様を決定することが必要であり、本項はこのために製品関連仕様をどのような観点から検討し、決定することが必要であるかを規定している。
<顧客のﾆｰｽﾞと期待の把握>
事業の発展を図るには、顧客のﾆｰｽﾞと期待を満たす製品を一貫して供給しなければならない。顧客のﾆｰｽﾞと期待は顧客要求事項と呼ばれる。顧客は製品やその製品実現の専門化ではないから、どのような機能や性能、価値の製品が実現できるかがわからない。顧客のﾆｰｽﾞと期待には顧客が自覚するものと、顧客が知らない、考えられないものとがある。
<製品関連仕様の決定>
どのような製品であるかは一連の製品要求事項で表される。この製品要求事項とは製品の仕様の意味であるが、製品の顧客満足に関連する活動の仕様をも含む。これは製品実現の計画では、「製品の品質目標及び要求事項」となる。組織は、製品が顧客に引渡されて必要な顧客満足を間違いなく得ることができるように、製品関連仕様を決めなければならない。この決定は、顧客がその想いとして意思表示するﾆｰｽﾞと期待を基礎として、組織が独自に顧客の想いに係わる他のﾆｰｽﾞと期待を特定し、製品関連仕様を追加することで行われる。顧客の意思表示する仕様を満たすだけでは顧客満足が得られるとは限らず、競合他組織と同じ製品であるから競争優位に立つこともできない。顧客が表明しないﾆｰｽﾞと期待を満たすことで顧客の想いを実現でき、顧客満足が得られる。更に、顧客の思いもよらないﾆｰｽﾞと期待を満たすことで、圧倒的な製品競争力を確立することができる。
<規格要求事項とその真意>
次の事項を明確にする: 組織は、成約、受注又は受付けた個々の製品について、顧客のﾆｰｽﾞと期待を満たして必要な顧客満足が得られるように製品関連仕様を決定する手順を確立しなければならない。これには、顧客の意思表示する事項、顧客と合意する事項が何かを明確にし、これを製品関連仕様に変換する基準が定められていなければならない。新製品を企画、開発して注文を受け付けるような業態では、誰が顧客のﾆｰｽﾞと期待の変化をどのように把握し開発を発議するかの手順の確立も必要である。これら手順には、次のa)～d)項の観点で顧客のﾆｰｽﾞと期待を検討し、製品関連仕様を決定する手順が含まれていなければならない
顧客が規定した要求事項: 顧客が明確に意思表示した又は組織が顧客と合意した製品関連仕様のことである。 顧客が ｶﾀﾛｸﾞやﾒﾆｭｰから特定の製品を指定した場合は、それら又は製品説明書などに記述された製品関連仕様が「顧客が規定した要求事項」に相当することになる。 これには、製品仕様そのものではないが、製品を受け入れる上で顧客が希望し又は関心を抱く関連事項を含む。 顧客の意思表示は顧客の製品に対する想いを伝えるものであり、普通は購買目的に直接係わる事項、とりわけ、機能や性能、価値しか表明されない。顧客が表明しなくとも、そのような製品に当然付随する事項、又は、不可欠な事項などは、それを満たさないと顧客の購買目的は達成されないから、表明されたものとみなされる。
製品の用途に応じた要求事項： 顧客満足の向上を掲げる2000年版では最も重要な規定であるが、 JIS和訳では規定の重みが伝わってこない。組織が顧客の要求( a)項)を満たすことは当然であり、顧客が言わなくとも、その他にもその製品に必要な事項があれば、それを満たす仕様の製品を顧客に供給することが必要である。 a)項の顧客が自覚し、意思表示する仕様を満たしただけの製品は、首尾よく製造又はｻｰﾋﾞｽ提供して顧客に引渡しても、顧客が製品を使用し又は引き取った時に、もう一度買おうと思う満足を感じるかどうかはわからない。 また、他の競合組織の製品と何も変わらないから、組織が競争優位を得ることはできない。これは、如何なる業種、業態にもあてはまる競争社会の現実である。
製品に適用される法令・規制要求事項： 適用される法令その他の規制を満たすことは顧客のﾆｰｽﾞや期待の根底にある。法令による規制でなくとも、JISなどの規格、或いは、業界や組織の行動指針や独自規格、又は、自主的規制や努力目標なども公表し、或いは顧客に約束した場合は、その順守は顧客のﾆｰｽﾞ又は期待となる。 組織は、適用が必要な法令その他の規制が間違いなく製品仕様又は関連要件に反映されるような手順を確立していなければならない。これには、ISO14001の規定と同様、適用必要な法令その他の規制を、その制定や改正の動向を含み、的確に把握する手順を確立しておくことが必要である。製品を海外に輸出する場合は、輸出先の法令その他の規制の管理についても、この手順に含めなければならない。
組織が必要と判断する追加要求事項： これは顧客のﾆｰｽﾞと期待には関係しない、組織自身の必要のための事項のことである。顧客満足向上の追求は組織の事業の発展のためであり、顧客のﾆｰｽﾞと期待を何がなんでも満たさなければならないという訳ではない。この組織の都合には一般には、組織のﾌﾞﾗﾝﾄﾞ
戦略上の観点からの都合と、製品実現の効率性、容易さ、経済性などの観点からの都合があると考えられる。
|
| このページの先頭へ |
詳しくは<sub35-01-36> |
|
その35. 7.1項 製品実現の計画 |
<[7.1項]の趣旨>
本項では、製品実現の計画活動の手順を確立し、成約又は受注した個々の製品に対して製品実現を計画する必要を明確にし、適合製品の顧客への引渡しを確実にするための製品実現の計画活動の在り方の要件、及び、計画活動がとり上げるべき事項とそれらの要件を規定している。
<製品実現>
契約又は受注に始まり、製品を製造又はｻｰﾋﾞｽ提供して顧客に引渡す一連の業務又は工程を総称して製品実現の諸ﾌﾟﾛｾｽと呼ぶ。組織は、成約又は受注した個々の製品について製品要求事項(7.2.1項)を基礎として、どのような製品とするのか、製品の実体と価値の水準を製品実現の一連の業務の狙いたる「製品の品質目標」として決定しなければならない。さらに、これを達成又は実現するために必要な諸業務と順番、手順及び資源を決定し、用意しなければならない。この2つの活動が、製品実現の計画活動（JIS和訳は「製品実現の計画」）である。製品実現の計画活動は、当該製品の製品実現の体制を整えることであり、活動のｱｳﾄﾌﾟｯﾄ、つまり、結果は、確立された手順、用意された要員、設備等の資源であり、大抵は、製品仕様書、手順書、業務実行指示書、計画書、企画書などの文書に表される。
製品実現の計画活動の実行と結果の態様は、組織の製品、業種、業態などにより大きく異なる。組織は、いつ、誰が、何を、何に則って又は用いて決めるのか、結果を何に表し、誰が承認し、それをどのように使用するのかを含む、適当な製品実現の計画活動の手順を確立しなければならない。
<品質保証>
製品実現の体制は、諸業務が定められた手順と資源の下で相互に関係しあいながら実行される業務の体系であり、品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑのﾌﾟﾛｾｽを構成要素とする二次ｼｽﾃﾑとみなすことができる。
製品実現ｼｽﾃﾑは、所定の製品の品質目標を満たす製品を生み出すことが目的であり、不良品を出さないという品質保証の活動でもある。しかし、製品実現ｼｽﾃﾑの適合製品を組織の品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの製品として顧客に引渡した時には、製品の品質目標が顧客のﾆｰｽﾞや期待を満たすように決められていなければ顧客には受け入れられないから、顧客満足という観点で不適合製品である。2000年版の品質保証活動は製品実現ｼｽﾃﾑの不適合製品のみならず品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの不適合製品をも出さないことを確実にする活動である。
<規格要求事項とその真意>
製品実現に必要なﾌﾟﾛｾｽ を計画、構築する： 組織は、製品実現の計画活動の実行のための手順を確立しておかなければならない。普通は製品実現の実行体制があり、計画活動は当該製品の具体的な製品実現の方法や条件を決める「計画する」であることが多いが、これまでにない業務又は工程、手順や要員、設備が必要になる場合には、これらを「開発する(JIS和訳は「構築」)」必要が生ずる。
品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑのその他のﾌﾟﾛｾｽ の要求事項と整合している： 製品実現のための諸業務や手順は、組織の品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑという枠組みの業務や手順であり、規格の関連する条項の要求事項と矛盾があってはならない。
製品実現の計画に当たって、次の該当するものを明確にする： 「明確にする」の原英語はdetermineであるから「決定する」である。組織は、製品実現の計画活動においては、次のa)～d)項の事項を必要に応じて決定しなければならない。
製品に対する品質目標及び要求事項： 組織は、引渡そうとする製品の実体と価値の狙いを製品の品質目標として明確にしなければならない。組織は、これを決定された製品要求事項(7.2.1項)に基づいて決める手順をもっていることが必要である。
ﾌﾟﾛｾｽ、文書の確立、資源の提供の必要性： 決定された製品の品質目標の達成又は実現に必要な業務又は工程を決め、その手順を確立し、手順を必要に応じて文書化し、手順実行に必要な資源を使用できるようにしなければならない。手順や資源などの要件は、7章を中心に規格の該当するそれぞれの条項に規定されている。
製品の検証、妥当性確認、監視、検査及び試験活動、合否判定基準： 組織の製品実現の計画活動は、個々の製品に必要な検証、妥当性確認、監視、検査及び試験の各活動を、製品の合否判定基準と共に決定することを含んでいなければならない。
製品実現のﾌﾟﾛｾｽ及び製品の適合性の実証する証拠の記録： 要求事項への適合及び業務の効果的実行の証拠となる記録(4.2.4項)に加えて、ﾃﾞｰﾀ分析の活動(8.4項)に使用する「監視及び測定の結果やその他の情報源からのﾃﾞｰﾀ」となる記録も必要である。
ｱｳﾄﾌﾟｯﾄは、計画の実行に適した様式である： 計画の結果をどの段階又は時点で、どのような形で表すか、どのような文書を作成するのか等は、組織の事業方法に適した形態であることが必要である。
|
| このページの先頭へ |
詳しくは<sub35-01-35> |
|
その34. 6.4項 作業環境 |
<[6.4項]の趣旨>
本項は、要員に品質ﾏﾈｼﾞﾒﾝﾄの諸業務を効果的に行わせるために業務を行う環境つまり作業環境の整備が大切であること、及び、必要な作業環境の範囲を示唆して、組織が不可欠な作業環境を常に整備、確立していることを確実にする作業環境のﾏﾈｼﾞﾒﾝﾄの必要を規定している。
<作業環境のﾏﾈｼﾞﾒﾝﾄ>
94年版では照度、温度、雰囲気清浄度など物理的、環境的な作業環境の維持の規定であったが、2000年版では社会的、心理的作業環境が加わり、品質ﾏﾒｼﾞﾒﾝﾄの効果的実行のための作業環境の必要を特定し、それを整備し、要員が常に必要な作業環境の下で業務が行えるようにするという作業環境ﾏﾈｼﾞﾒﾝﾄの規定となった。
<物理的、心理的作業環境>
品質ﾏﾒｼﾞﾒﾝﾄの効果的実行のためには、要員には業務遂行力(6.2.1項)、要員の業務遂行を効率的、効果的にするための物的資源(6.2.2項)、及び、要員のやる気と参画意識の基となる「認識」(6.2.1
d)項)が不可欠である。この「認識」の醸成に与る作業環境が、社会的、心理的な観点の作業環境であり、規格は人々の承認欲求に対応する制度や施策、職場風土、また、機械や道具、作業方法、作業環境などを要員の人間としての基本特性に適合したものとするよう要員の生理的、心理的な観点から追究する人間工学的配慮を例示している。
この考えは米国で1950～1960年代に登場した経営管理学説「人間資源論(Human resource theory)」とその経営管理技法である「人間関係管理(Human relations)」に遡るとも言えるが、戦後の日本企業が職場の民主化と明朗化を図り、従業員の勤労意欲の向上、更には、従業員の自発的協力を引き出す手段として、職場の雰囲気を良くし、従業員の満足感、帰属意識、安定感、会社への信頼感を高める種々の制度や施策が取り入れられた。効果的業務遂行にはこのような要員の人間としての側面を重視し、人々のやる気を育む制度、施策、職場の雰囲気の整備、確立が必要とする近年の世界の理解が、2000年版規格で人的な観点での作業環境として採り上げられた。
<規格要求事項とその真意 －作業環境のﾏﾈｼﾞﾒﾝﾄの要件>
製品要求事項への適合に必要な作業環境 ： 6.3項と同じ表現であり、事業繁栄に必要な顧客満足向上の達成、或いは、品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行を可能とするのに必要な作業環境という意味である。
必要なｲﾝﾌﾗｽﾄﾗｸﾁｬｰを明確にし、運営管理する： この英原文は、determine and manage であり、6.1、6.3項とはdetermine (特定する)が同じで、他の用語が異なるが、manage はJIS和訳「ﾏﾈｼﾞﾒﾝﾄ (management)」の動詞形であるから、他の条項より資源のﾏﾈｼﾞﾒﾝﾄ という要件を直接的に表している。つまり、必要な作業環境の下で要員が業務を行うように、必要な作業環境を特定し、それに係わる設備や制度、手順、規則、風土などを確立し維持し、かつ、作業環境の維持、適用を監視し、作業環境の不備が理由となって品質ﾏﾒｼﾞﾒﾝﾄの業務に支障が出ないよう管理することを意味する。これには、新たに必要が特定された作業環境の整備や改善の確実な実行のための管理(制御)や既存の作業環境の所期の水準や決まりの通りに維持、運用する管理(制御)の活動が含まれる。他条項と規定の表現が異なるのには特段の意味はない。なお、品質ﾏﾒｼﾞﾒﾝﾄ の諸業務が効果的に行われ、目指す顧客満足の向上を間違いなく実現するためには、作業環境については物理的、自然環境的な要素だけではなく、人々のやる気を醸成する社会的、心理的要素も考慮することが必要である。
|
| このページの先頭へ |
詳しくは<sub35-01-34> |
| その33. 6.3項 ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ |
<[6.3項]の趣旨>
本項は、要員が品質ﾏﾈｼﾞﾒﾝﾄの諸業務を効果的に行うのに必要な物的資源を常に利用できるようしておくｲﾝﾌﾗｽﾄﾗｸﾁｬｰのﾏﾈｼﾞﾒﾝﾄ
について規定している。
<物的資源>
ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ は infrastructureで、これは「国や組織の円滑な運営に必要な一連の基礎的な施設又は必要を満たす手段であり、例えば、建物、輸送、水、電気」1)の意味であり、規格では「組織の事業活動に必要な一連の施設、設備及び必要を満たすその他の手段」である。規格の意図の
ｲﾝﾌﾗｽﾄﾗｸﾁｬｰとは、人的資源(6.2項)に対する物的資源を意味する。
<ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ のﾏﾈｼﾞﾒﾝﾄ>
組織は人々が利用し、顧客満足向上を目指す業務の効果的実行に不可欠な機能及び性能の物的資源を、常に人々の利用に供するようにしておかなければならない。このために組織は、現在、将来に必要な物的資源を特定し、現在又は将来に不足する物的資源を時宜を得て充足し、充足した物的資源を利用して各業務を行い、物的資源が不足し充足が必要と判断される根拠となった品質ﾏﾈｼﾞﾒﾝﾄの当該業務の実行上の及び結果の問題が解消されたことを確認しなければならない。
物的資源が不足し或いは必要となることは、組織の事業上、業務の実行上の改善、また、長期間使用による性能の劣化、機能の陳腐化などの事由により生じる。物的資源の過不足を常に把握し、不足を充足するための手順、責任、方法、制度を確立することが必要である。不足する物的資源は一般には、購入、工事などにより充足するが、専門業者に業務を外注するなどによって組織内から物的資源の必要をなくすることもある。
<物的資源充足処置の実行管理 及び 保全活動>
ｲﾝﾌﾗｽﾄﾗｸﾁｬｰのﾏﾈｼﾞﾒﾝﾄにおいては、不足する物的資源を充足する活動が確実に計画通りに必要な物的資源を充足することが必要であり、また、既存の物的資源の機能や性能を確実に発揮させる保全活動のが必要である。これらの実行管理(制御)もPDCAｻｲｸﾙの活動でなければならない。
<規格要求事項とその真意 －ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ のﾏﾈｼﾞﾒﾝﾄの要件>
製品要求事項への適合に必要なｲﾝﾌﾗｽﾄﾗｸﾁｬｰ ： 「製品要求事項への適合」とは英文法上、規格の文脈上、組織内部の製品に対する合否判定基準を満たすという品質管理上の問題ではなく、製品が顧客に受け入れられることを意味する品質保証上の問題である。つまり、事業繁栄に必要な顧客満足向上の達成、或いは、品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行を可能とするという意味で用いられており、それに必要なｲﾝﾌﾗｽﾄﾗｸﾁｬｰとは組織が品質ﾏﾈｼﾞﾒﾝﾄを効果的に実行するのに必要なｲﾝﾌﾗｽﾄﾗｸﾁｬｰという意味である。
必要なｲﾝﾌﾗｽﾄﾗｸﾁｬｰを明確にし、提供し、維持する： 94年版では物的資源に関して、製造、据付け、付帯ｻｰﾋﾞｽ用の設備の工程能力維持のための保全活動の必要の規定だけだったが、2000年版では、使用している物的資源が組織発展に必要な顧客満足向上を実現するために十分であるかどうかを評価し、その不足を満たすことを目的とするｲﾝﾌﾗｽﾄﾗｸﾁｬｰのﾏﾈｼﾞﾒﾝﾄについて規定している。組織は効果的な品質ﾏﾈｼﾞﾒﾝﾄの実行のために必要な物的資源が常に利用できるようにしておかなければならない。
ｲﾝﾌﾗｽﾄﾗｸﾁｬｰとは ： 品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行に必要な物的資源には、例えば、 a) 建物、作業場、関連する電気、水、ガス用設備*、 b) 設備、 c) 支援業務がある。
|
| このページの先頭へ |
詳しくは<sub35-01-33> |
| その32. 6.2.2項 力量、認識及び教育・訓練 |
<6.2.2項の概要>
本項では、要員が「力量がある」こと(6.2.1項)をどのように確実にするかの力量ﾏﾈｼﾞﾒﾝﾄの必要条件を規定している。同時に、品質ﾏﾈｼﾞﾒﾝﾄの諸業務の真に効果的な実行には要員が「力量がある」だけでは十分でなく、「認識」も必要であることを指摘している。
<力量ﾏﾈｼﾞﾒﾝﾄ>
品質ﾏﾈｼﾞﾒﾝﾄの効果的実行のためには組織は、業務遂行力を持つ要員にそれぞれの業務を委ねなければならない(6.2.1項)。このためには組織は、組織は現在、将来に必要な業務遂行力を把握し、不足する業務遂行力を時宜を得て確実に充足し、いつの時点でも組織内に必要な業務遂行力があるようにしなければならない。業務遂行力が不足するのは、新分野への進出、新商品、新技術、新設備の導入、或いは、特定の分野や商品の間の生産や販売量移動、製品の増減産など、また、新規採用、退職、職場間の要員異動や役職昇格の場合などである。業務が効果的に実行されない場合、要員の業務遂行力の不足が原因であることもある。不足する業務遂行力は、新規採用や要員の職場異動と教育訓練によって充足し、或いは、業務外注化、手順の変更や標準化、機械化や自動化、ｺﾝﾋﾟｭｰﾀｰｼｽﾃﾑ化によって必要な業務遂行力を軽減して現有で賄えるようにする。これらの処置の実行の後、業務遂行力不足の根拠となった品質ﾏﾈｼﾞﾒﾝﾄの実行と結果の問題が解決されたかという観点で処置の結果を評価する。
同時にこれら処置の実行管理及び充足された業務遂行力を日々の業務に適切に適用する要員配置の実行管理が必要である。両実行管理を含めて、業務遂行力の把握と充足と維持の力量ﾏﾈｼﾞﾒﾝﾄの組織としての再度総合的評価や戦略的決定はﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ(5.6.3
c)項)において行われなければならない。
<認識>
品質ﾏﾈｼﾞﾒﾝﾄの諸業務が真に効果的に行われるためには、要員に「力量」があるだけでは十分ではない。人々の仕事への意欲や責任意識を重視し、人々の能力を組織の様々な業績の改善に活用することは日本的経営の特徴であり、品質で世界を席捲した輸出企業の“ものづくりのﾏﾈｼﾞﾒﾝﾄ”の基本要素である。このことの重要性が欧米で認められ始めたのが1980年代であり、ISO9001では2000年版で初めて「認識」として要求事項として採り入れられた。規格は教育訓練(6.2.2項)、ｺﾐｭﾆｹｰｼｮﾝ(5.5.3項)、作業環境(6.4項)を「認識」醸成手段としても規定している。
<規格要求事項の意図 －力量ﾏﾈｼﾞﾒﾝﾄの要件と「認識」の必要性>
全体 ：
a)～c)項は力量ﾏﾈｼﾞﾒﾝﾄのPDCAｻｲｸﾙを規定している。 また、d)項で「認識」の必要性を規定し、e)項では力量ﾏﾈｼﾞﾒﾝﾄに必要な記録について規定している。
要員に必要な力量を明確にする： 品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行を図るには、必要な業務遂行力を常に組織内にもっていることが必要である。必要な業務遂行力がなければ品質ﾏﾈｼﾞﾒﾝﾄの実行と結果に支障が生ずる。このために組織は、現在又は将来にどのようつまり、どのような業務遂行力が不足するかを適切に判断しなければならない。
必要な力量がもてるように教育・訓練し、又は他の処置をとる ： 不足するとされた業務遂行力を教育訓練、又は、その他の処置によって充足しなければならない。
教育・訓練又は他の処置の有効性を評価する ：不足する業務遂行力を充足する処置をとったなら、その結果で狙った通りの業務遂行力が充足されたかどうかを評価しなければならない。これは処置によって業務遂行力を充足した結果で当該の品質ﾏﾈｼﾞﾒﾝﾄの問題が解消できたかどうかである。
要員が認識することを確実にする ： 要員は、当該業務の業務遂行力をもつだけでなく、その業務が組織の品質目標の達成にどのように関連するのか、どのように重要なのか、また、どのように寄与できるのかを「認識」をしなければならない。規格はこれに寄与するものとして、教育訓練(6.2.2項)、ｺﾐｭﾆｹｰｼｮﾝ(5.5.3項)及び作業環境(6.4項)を挙げている。
教育、訓練、技能及び経験について該当する記録を維持する ： 要員が特定の業務に業務遂行力をもっているかどうかは、履修した学校教育、組織の実施した教育訓練、特定の専門性及び職務経験の４種の事実を用いて評価、判断される(6.2.1項)。要員が特定の業務遂行力をもつことを何で判断したかを示し、適切に判断したことの証拠となる記録が必要である。
|
| このページの先頭へ |
詳しくは<sub35-01-32> |
| その31. 6.2.1項 人的資源 一般 |
<6.2.1項の趣旨>
本項は、経営資源のひとつである人的資源のﾏﾈｼﾞﾒﾝﾄにおいては職務遂行力を指標とすべきことを明確にし、その要件及び対象となる要員の範囲を規定している。
<力量と教育訓練>
「力量」の原英語は competence であり、一般に「何かを満足に、又は必要な程度に行う能力」、事業用語としては「満足に仕事を行う能力」という意味であり、職務遂行力のことである。これは、所定の手順に則って業務を行って所定の結果を出すことの出来る能力のことであり、委ねられた責任及び権限(5.5.1項)を全うする能力とも表現できる。必要な職務遂行力を有していることを「力量がある」と言う。高い能力を意味する一般の日本語の意味とは違う。規格は「力量」の定義において、「力量がある」ことは主観的な判断ではなく、何らかの事実の証明や証拠によって示されたものであることを規定している。
品質ﾏﾈｼﾞﾒﾝﾄに関連する諸業務を担うのは人々である。人々には、担当業務を手順に則って行い、所定の結果を出すことが求められる。各人に必要な「力量」がなければ、担当の業務は効果的に行えず所定の業務結果を出すことができないから、諸業務の総合的結果である品質方針、目標で定めた狙いの顧客満足は実現できない。必要な人的資源の用意とは、人々の頭数を揃えることではなく、「力量」をもった人々にそれぞれの業務を委ねることである。「力量」は人的資源の指標である。
教育訓練とは組織の実施する職業教育を指し、要員が教育訓練を受けた事実は「力量がある」ことの証明のひとつであり、その有無の判断基準のひとつとなる。また、教育訓練は組織に不足する「力量」を充足し、或いは、要員に新たな業務の「力量」の習得させる手段でもある。
<規格の表現における不統一>
職務遂行力のあることを94年版ではJIS和訳「資格がある」の qualified
と表現され、実質的に「力量がある(competent)」と同じ意味を表していた。しかし、competent
も94年版にもあり、qualification が2000年版にも存在する。また、94年版では人的資源を意味するのに、用語「資格がある」による職務遂行力と共に「教育訓練された要員」という表現も用いられていた。このように規格の表現に一貫性が欠けるのは、職務遂行力や教育訓練の概念と表現に関する規格執筆者の理解の確立の過程を反映したものである。
<規格要求事項の意図>
要員は力量があること－人的資源の指標：品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行のためには当該業務を所定の通りに行い所定の結果を出す職務遂行力をもつ要員に委ねることが必要である。
人的資源を用意するとは、要員の頭数を揃えることではなく、必要な各職務遂行力をもった要員を揃え、それぞれに該当する業務を委ねることである。
力量は教育、訓練、技能及び経験を根拠として判断すること－力量有無の判断基準： 要員に職務遂行力があることは客観的に判断されることが必要である。判断基準としては履修した学校教育、組織の実施した教育訓練、特定の専門性及び職務経験の４種の事実を用いるのが効果的である。
製品品質に影響がある仕事に従事する要員は、力量があること－人的資源の範囲： 業務(ﾌﾟﾛｾｽ)の結果は「製品」であるから、製品品質に影響がある仕事の要員とは品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの諸業務を担うすべての要員を指す。これには、製品・ｻｰﾋﾞｽの製造・提供その他の事業活動を直接担う要員のみならず、それら業務の実行管理に当たる ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ以下の管理者も含まれる。
|
| このページの先頭へ |
詳しくは<sub35-01-31> |
| その30. 6.1項 資源の提供 |
<6.1項の趣旨>
本項は、効果的な品質ﾏﾈｼﾞﾒﾝﾄのためには必要な経営資源が間違いなく投入されなければならないことを指摘し、このために品質ﾏﾈｼﾞﾒﾝﾄ活動を経営資源に関するﾏﾈｼﾞﾒﾝﾄ活動と連携させることの必要を示唆している。
<資源>
「資源」はいわゆる経営資源のことである。事業活動は一定の要素を投入し、これを処理して所定の結果を産出するものと捉えられるが、この投入されるものが「経営資源」である。これは普通、人的資源、物的資源、貨幣的資源から成るが、近年では情報と企業文化もこれに含まれる。
規格では、ﾌﾟﾛｾｽ(業務)は入力を出力に変換する活動である。ﾌﾟﾛｾｽを実行する方法が「手順」であり、手順の履行で入力に価値を付加して出力とするのであるが、その原資が「資源」である。品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑでは、相互に関連をもった諸業務(4.1
a),b)項)が、定められた手順と合否判定基準(同 c)項)に従って、「資源」と情報を利用して実行され(同
d)項)、管理される(同 e),f)項)。本項が扱うのはこの「資源」である。
ISO9004は「資源」として、人々、ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ、作業環境、情報、供給者、天然資源、財務資源を例示し、また、設備など目に見える資源と対照させて目に見えない資源として知的財産を挙げ、ﾌﾟﾛｼﾞｪｸﾄﾁｰﾑを含む組織構造、情報技術、力量や管理者の指導力にも言及している。96年版では、経営資源が人的資源に限定されるかの表現(4.1.2.2項)であったが、2000年版表現では、品質ﾏﾈｼﾞﾒﾝﾄのために必要なすべての資源が対象であることが明確になった。
<資源ﾏﾈｼﾞﾒﾝﾄ>
JIS和訳は「資源の運用管理」であるが、英原文では resource management
であるから「資源ﾏﾈｼﾞﾒﾝﾄ」であり、「資源に関して組織を方向づけ、制御する活動*」である。すなわち、品質ﾏﾈｼﾞﾒﾝﾄの効果的実行に関して資源の不足或いは必要を決定し、仕様を計画し、手配し、利用可能にし、使用し、維持し、必要を満たしているかどうかを監視測定、評価するという
ﾏﾈｼﾞﾒﾝﾄのPDCAを回す活動である。
資源ﾏﾈｼﾞﾒﾝﾄは、組織の全体ﾏﾈｼﾞﾒﾝﾄの一部を構成し資源に焦点があてられた活動である。本項の資源ﾏﾈｼﾞﾒﾝﾄは、その内の品質ﾏﾈｼﾞﾒﾝﾄに必要な資源に関係する部分だけである。この部分の諸業務は資源ﾏﾈｼﾞﾒﾝﾄと品質ﾏﾈｼﾞﾒﾝﾄの両方に共通であり、両方の必要を反映した手順となる。実際には大抵の組織では、本項のように人的資源、ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ、作業環境を一括対象とした資源ﾏﾈｼﾞﾒﾝﾄではなく、それぞれに関連の深い人事、設備、安全衛生、福祉など異なるﾏﾈｼﾞﾒﾝﾄに含めている。
<規格要求事項の意図 －品質ﾏﾈｼﾞﾒﾝﾄに必要な資源を特定し、利用可能にすること>
必要な資源を明確にし、提供する： 「明確にする」「提供する」は原英文では
determine、provide であり、それぞれ、はっきりと決める、必要なものを利用できるようにするという意味である。つまり、組織が品質ﾏﾈｼﾞﾒﾝﾄを効果的に行うには、必要な又は不足する資源が何かを決定し、それを準備又は充足し、利用又は使用可能にすることが必要である。この資源ﾏﾈｼﾞﾒﾝﾄ
のPDCAｻｲｸﾙには、準備又は充足した資源が所定の機能の発揮する能力の維持及び能力の監視測定、更に、不足、不良に対する処置や是正処置が含まれなければならない。但し、独立した資源ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの必要を規定しているのではない。
品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ 及び顧客満足向上に必要な資源： 規格の品質ﾏﾈｼﾞﾒﾝﾄ ｼｽﾃﾑの文脈においては、b)項の資源はa)項の資源に包含される。必要な資源をa),b)の2つに分けて規定されていることに対しては、重複する表現と断じる解説もあるが、多くは敢えてこのことに言及していない。2000年版改訂の趣旨を強調することに関連する表現であり、前者が5.4.2項の資源、後者が7.1
b)項の資源を意味するものと理解できる。意図はあくまでも、品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行のために必要なすべての資源ということである。
|
| このページの先頭へ |
詳しくは<sub35-01-30> |
| その29. 5.6.3項 ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰからのｱｳﾄﾌﾟｯﾄ |
<5.6.3項の趣旨>
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰの結論として顧客満足の向上を図るための処置を効果的に導き出すためには、判断と決定が業務の手順、製品の品質、資源の３つの観点で行われることの必要が規定されている。
<ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ のあり方>
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ によってﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄは、組織の現在及び将来の事業展開にどのような顧客満足の実現が必要か、また、そのための課題は何か、どのような方向で問題解決を図るべきか、必要な処置は何かを決める。品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ
は「組織のﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ」(ISO9000; 3.2.2 参考)の一部に過ぎない。ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰの決定は、他の目的のﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ
との関連も考慮にいれた組織全体としての最適解でなければならない。
ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄは、供される業務実績の情報を、目標と計画 (5.4項)と対比評価し、顧客満足と業務能力の実態と今日の必要に対する過不足を判断し、次にこれを変化する内外の情勢の情報と対比評価して、将来の必要に対する過不足を判断する。ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ
は、判断した過不足に対して、品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ が「適当で、十分で、有効である」ようにするための処置を決定する。この
ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ の認識及び結論としての決定は、以降の品質ﾏﾈｼﾞﾒﾝﾄの実行を方向づけるものとなる。方向転換の大きさによっては品質方針や品質目標を変更する必要も生じる。このように、ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰを核として、必要な顧客満足度を得るために品質ﾏﾈｼﾞﾒﾝﾄ
の業務の手順と資源を変更して業務能力を必要なまで改善し続けることが、「品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの有効性の継続的改善」(8.5.1項)である。
<規格要求事項とその真意 －３つの観点からの変更又は改善の処置の決定>
ｱｳﾄﾌﾟｯﾄの決定及び処置：ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄは品質ﾏﾈｼﾞﾒﾝﾄの諸業務が必要な顧客満足の実現に引続き適当で、十分であり、効果的に実行、管理されるための処置を決定しなければならない。この決定を効果的なものとするためには、問題点や課題の抽出及び問題解決の方向づけと処置を次の３つの観点に分けて判断し、決定することが必要である。
品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ 及びそのﾌﾟﾛｾｽ の有効性の改善(a)項)：不足する、将来不足する可能性のある業務能力の改善を図るための業務の実行と管理の手順の変更のことである。狙いの顧客満足の製品・ｻｰﾋﾞｽを確実に実現することに関連する品質保証、品質管理、品質改善、品質計画の業務能力の他、狙い顧客満足度を決定することに関連する顧客のﾆｰｽﾞと期待や内外の諸情勢を把握する業務能力や製品・ｻｰﾋﾞｽの企画、開発の業務能力、或いは、外注政策などにもわたることがある。
顧客要求事項への適合に必要な製品の改善(b)項)：不適合製品の出荷や苦情防止のための製品・ｻｰﾋﾞｽの改善だけでなく、変化する顧客のﾆｰｽﾞと期待を満たすための新製品・ｻｰﾋﾞｽの開発や投入を含み、商品戦略や事業戦略にも及ぶ。
資源の必要性(c)項)：品質ﾏﾈｼﾞﾒﾝﾄ の諸業務が手順の通りに実行されるために必要なものが「資源」であり、6章に規定される人的資源、ｲﾝﾌﾗｽﾄﾗｸﾁｬｰ、作業環境の他、情報、技術、原料や資材、文書や記録、更には、確立した手順、責任と権限、組織構造、供給者との関係もすべて「資源」である。 |
| このページの先頭へ |
詳しくは<sub35-01-11> |
| その28. 5.6.2項 ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ への ｲﾝﾌﾟｯﾄ |
<5.6.2項の概要>
本項は、必要な顧客満足の向上のために適当で妥当で有効な結論を導くために、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ が評価、検討することが必要な事項を規定している。
<ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ のための情報>
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰで効果的な結論(5.6.3項)を出すためには、品質ﾏﾈｼﾞﾒﾝﾄ
に関してその実績及び関係する内外の諸情勢についての2種類の情報を評価することが必要である。前者は日常業務の監視、測定、分析(8章)から得られ、後者は、変化している及び変化が予想される事業環境上、事業上、業務上の動向の情報であるが、どちらも予め計画しておかなければならない(8.1項)。
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰに供する情報は、人の記憶に頼るものではなく記録(4.2.4項)
や数値筑粟 で事ﾀであることが裏付けられているものであることが大切である。また、情報は個別情報、個封ﾁ洌ﾀではなく、それらを分析評価した結果(8.4項)であり、問題点や改善の方向を明らかにした情報であることがよい。また、情報には以前に別の評価に供されたもの、以前に行われたﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄの決定や指示も必要により含まれる。
<規格要求事項とその真意 －ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰで評価、検討すべき事項>
品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑを引続き適当で、妥当で、有効なものとする(5.6.1項)ための決定
(5.6.3項)を行うためには、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ は少なくとも次の情報を評価しなければならない。
監査の結果( a)項): 内部監査(8.2.2項)の結果は品質ﾏﾈｼﾞﾒﾝﾄ の諸業務の実行状況に関する客観的、体系的な情報である。ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰに供するのは、個別の監査報告書ではなく、監査ﾌﾟﾛﾌﾞﾗﾑ
の目的との関連における総合的な結果の情報でなければならない。
顧客からのﾌｨｰﾄﾞﾊﾞｯｸ( b)項): 英原文は、組織の製品の顧客満足度に係わる顧客に関する情報という意味であり、現在及び将来の顧客満足に関係のある諸情報(7.2.3 c)項、8.2.2項)を分析した結果(8.4 a)項)を中心とする情報である。これには、顧客、市場の変化及び競合相手や技術進歩の動向の情報を含む。
ﾌﾟﾛｾｽ の実施状況及び製品の適合性( c)項)： 所定の製品品質が実現しているかどうかに関する情報であり、製品実現のﾌﾟﾛｾｽ(7章)の各業務の実績の監視測定(8.2.3項)の結果、及び、製品の監視測定(8.2.4項)の結果の情報が中心である。また、この情報には必要により資源の維持に関する情報(6.2.2 b)項、6.3項、6.4項)等を含む。更に、改善の品質目標について特別な実行計画によって取り組むことが多いが、この場合はこの状況も含めるとよい。
予防処置及び是正処置の状況( d)項)： 組織の問題解決能力に関する情報である。英原文は「一連の経過の中のある時点での状況」という意味であるから、実施した予防処置(8.5.3項)と是正処置(8.5.2項)が今どうなっているかということである。これらの処置によって全体として不適合の発生がどうなったかの評価の情報も大切である。これは、予防、是正処置のﾚﾋﾞｭｰ (同上 e)項/f)項)の結果の情報が中心となる。
前回までのﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰの結果に対するﾌｫﾛｰｱｯﾌﾟ( e)項): ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰという活動にPDCAｻｲｸﾙ を回すための情報である。以前のﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ の決定及び処置(5.6.3項)が今どうなっているかの情報という意味である。
品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑに影響を及ぼす可能性のある変更( f)項)： ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰは、変化する情勢とその必要を満たすよう現状を変更ないし改善する決定を行うのが目的である。品質ﾏﾈｼﾞﾒﾝﾄ に関係する内外の諸情勢の動向の情報を組織的に収集し、ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰに供することが必要である。これには、事業環境上、事業上、業務上の変化の情報がある。
改善のための提案( g)項)： ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ が評価する情報は、それぞれの分野又は業務に責任と権限を委ねられた管理者が提供する。これには、実績や問題点と実施した対策の報告と共に以降に取組むべき課題と方法についての提案も含まれていなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-28> (修:H19.5.15) |
| その27. 5.6.1項 ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ 一般 |
<5.6.1項の概要>
本項では、ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ という活動の目的と機能及び特質を明確にし、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ
がこれを一定期間毎に行うべきことを規定している。
<過去のﾏﾈｼﾞﾒﾝﾄ活動の総合的検分>
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ の英原文 management review は一般経営用語にはない。
management は、“活動”と “人々”の２つの意味を持つが、規格では 何も修飾語が付かない場合は“活動”を意味するのが原則であるから、“ﾏﾈｼﾞﾒﾝﾄ活動”の意味である。
review は「見直し」であり、management review はこれら2つの名詞からなる群名詞であるから文法的に、“ﾏﾈｼﾞﾒﾝﾄ活動を見直す”の意味である。
実務的な意味では、review は「過去を顧みる」(動詞)、「一定期間の行事としての総合的検分」(名詞)であるから、ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ
は、定期的に一定期間の ﾏﾈｼﾞﾒﾝﾄ活動の実績を顧みて、総合的に検分することである。
<ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ の意義>
規格の定義で「ﾚﾋﾞｭｰ」は、「ある事がその狙いや意図の達成に適当か、適切か、有効かを判定する活動*」であり、本項の場合の“ある事”とは品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ
であり、“狙い”は顧客満足向上である。ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ は、顧客満足向上の課題を見極め、それへの取組みを品質方針(5.3項)に掲げ、その実現を図る諸業務の狙いや到達点を品質目標(5.4.1項)として定め、その達成のための手順を確立し資源を用意し(5.4.2項)、管理責任者(5.5.2項)の補佐を得て各層管理者を指揮し、組織内の日々の諸業務の実行と監視測定、分析、改善(8章)を統括する。しかし、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄは一定期間毎には実行と成果が所期の狙いの通りかどうかを改めて総合的に検分する
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ を行うことが必要である。この結果と顧客の変化するﾆｰｽﾞと期待を勘案して引続く顧客満足の確保のために何が必要かを判断し決定し、それを以降の
ﾏﾈｼﾞﾒﾝﾄ活動で達成を図る。すなわち ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰは、品質ﾏﾈｼﾞﾒﾝﾄ のPDCAｻｲｸﾙ
のAに相当する活動であり、その決定は品質方針や目標の変更を含む問題解決の新たなPとなる。そして、このPDCAの繰返しが品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの有効性の「継続的改善」である。
<ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ の特質>
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰは、PDCAｻｲｸﾙのAの活動であり、“一定期間”の行事で、“総合的”な検分であり、“非日常”な活動である。“一定期間”とは
ﾏﾈｼﾞﾒﾝﾄ活動のPDCAｻｲｸﾙの一巡の期間のことであり、ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰはこの期間の最後に行われる。“総合的”とは、全期間の実績について関連するすべての要素をもれなく取り上げ、必要なすべての視点から全体を評価するという点で“体系的な”という意味でもあり、また、“公式の”とも表現されるから非日常の活動という意味でもある。
<ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰの実務>
事業組織のﾏﾈｼﾞﾒﾝﾄ活動は最終的には貨幣的に認識、測定、評価される。これが会計であり、一般に、年度初めに予算編成、年度末には決算が行われる。決算では項目毎及び全体に関して、予算に実績を対比させ、差異の原因を分析し、取巻く情勢の変化と合わせて次年度の予測と課題を決める。決算は組織の全体ﾏﾈｼﾞﾒﾝﾄの活動の総合的検分であるが、品質ﾏﾈｼﾞﾒﾝﾄに関しての決算に該当する活動が規格のﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ
である。事業年度を設け、年度の方針や到達目標を定める多くの組織では、年度末にはﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄが実績を評価し総括する
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰが、全体として、又は、品質、安全、環境など個別課題について別々に行われている。
<規格要求事項とその真意 －ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰの目的、機能、特質>
定められた間隔で品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑをﾚﾋﾞｭｰする： ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ は、品質ﾏﾈｼﾞﾒﾝﾄのPDCAｻｲｸﾙの期間の最後、通常は事業年度末に、品質ﾏﾈｼﾞﾒﾝﾄ活動の実績を品質方針や品質目標と計画と対比して総合的に検分し、次年度の課題や必要な処置を決定することが必要である。
品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑが適切、妥当、有効であることを確実にするために： 品質ﾏﾈｼﾞﾒﾝﾄは時代の変化によらず一貫して顧客満足の製品を供給することを図る活動であるから、その諸業務は実績や事業環境の変化に応じて改善又は変更されることが必要である。品質方針に始まる品質ﾏﾈｼﾞﾒﾝﾄのPDCAｻｲｸﾙの最後のAとして行う ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ は、諸業務が常に必要な顧客満足を達成するように行われることを確実にするのが目的である。
改善の機会と変更の必要性の評価を行う： 品質ﾏﾈｼﾞﾒﾝﾄの実績が示唆する業務能力の充足と変化する事業環境への対応の両面で、どのような改善又は変更が必要なのかを見極めることが ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ の基本的な機能である。
品質方針、品質目標を含む品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの改善及び変更：品質方針又は品質目標が実現した結果で新たな課題に取組む場合など、ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰにより決定した改善又は変更がそれまでの品質方針や品質目標の範疇を逸脱する場合は、品質方針や品質目標を変更する必要が生じる。この改善又は変更の実行は“品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの有効性の継続的改善”を意味し、品質方針や品質目標の変更は継続的改善の明白な証である。
ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ の結果の記録の維持：ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰの記録は品質ﾏﾈｼﾞﾒﾝﾄの状態とそれへのﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄの意思が表されており、情報伝達の手段として関係者の閲覧に供され、また、組織の品質ﾏﾈｼﾞﾒﾝﾄの歴史として保管されなければならない。
|
| このページの先頭へ |
詳しくは<sub35-01-27> |
| その26. 5.5.3項 内部コミュニケーション |
<5.5.3項の概要>
本項は、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ が経営責任のひとつとして、品質ﾏﾈｼﾞﾒﾝﾄの実行と結果に関する情報が組織内で必要に応じて確実に伝達され或いは交換されることを確実にする必要を規定している。
<情報交換及び意思疎通>
「ｺﾐｭﾆｹｰｼｮﾝ」の原英語は communication であり、これは情報の交換又は考えや意思の共有を意味する言葉であり、規格では「情報交換」と定義される。すなわち、「内部ｺﾐｭﾆｹｰｼｮﾝ」とは組織内での意思疎通或いは共通理解のために必要な情報を相互伝達することを意味する。
品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの諸業務は一般に各機能部門で分担され、それぞれに責任及び権限を付与された各管理者の協働によって成り立っている。従って、品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行には、関連する部門や管理者間でそれぞれの業務の実行と結果に関する情報が共有されることが不可欠である。特に、情報の中でも品質ﾏﾈｼﾞﾒﾝﾄの実行上及び結果の問題点に関する情報が正確に発信され、必要な部門或いは管理者に確実に伝達され把握されることが大切である。また、要員にその業務に関連する組織内の業務実行状況と結果の情報が伝達され、知らされた状態であることが、要員が自らの業務の重要性を認識し(6.2.2
d)項)、持てるすべての能力で業務に取り組むようになる参画意識(ISO9000; 0.2
c))の醸成の基礎である。
<情報交換の方法>
情報交換の手段には、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄや管理者が意向を「方針」(5.3項)の形で、及び、日常業務の中で説明、指導、指示することの他、教育訓練(6.2.2
項)、文書の作成と配付(4.2.3項)や記録の作成と報告(4.2.4項)、業務指示や業務報告、定期的な職場の連絡会、部門内検討会、部門間会議等での報告や議論、組織内LANの運用、eメールの交換、社内報発行、職場掲示などがあり、ﾏﾈｼﾞﾒﾝﾄﾚﾋﾞｭｰ(5.6項)も普通、情報交換の場として活用される。また、要員からの問題提起や改善提案の情報の発信を奨励し、受付ける管理者による対話やその他の方法の確立が参画意識醸成には大切である(ISO9004;5.5.3項)。
<規格要求事項とその真意 －情報交換の必要性と ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄの責任>
JIS和訳はふたつの文章になっているが、英原文では and でつながれたひとつの文章である。すなわち、品質ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑ
の業務が所定の結果を出すように行なわれるための、また、効果的に行われているかどうかに関して、情報交換が行われることが必要である。品質ﾏﾈｼﾞﾒﾝﾄを効果的に行うために
ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄ は、組織内で適切な、つまり、必要で十分な情報交換が確実に行われるような枠組みと手順が確立され、その情報交換が実際に行われるよう監督しなければならない。
<関連する規格要求事項>
JIS和訳の、法令・規制及び顧客要求事項を満たすことの重要性の「周知」(5.1
a)項)、品質方針の「伝達」(5.3 d)項)、責任及び権限の「周知」(5.5.1項)のいずれも原英文では
communicate である。これら規定は 本項の情報伝達の枠組みにおける ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄの情報伝達責任の具体例である。
|
| このページの先頭へ |
H19.3.22 詳しくは<35-01-26> |
| その25. 5.5.2項 管理責任者 |
<5.5.2項の概要>
本項は、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄが、多忙な自らに代わって品質ﾏﾈｼﾞﾒﾝﾄの日常業務を統括する特定の責任者を決めることが、組織の品質ﾏﾈｼﾞﾒﾝﾄの効果的な実行に必要なことを指摘している。
<管理責任者>
「管理責任者」の原英語は management representative であるから、ﾏﾈｼﾞﾒﾝﾄ活動を代行ないし代表する人という意味である。D.Hoyle氏は、どのように代表するかによってISO9001適合のためだけの一種の象徴的存在か、或いは、ﾏﾈｼﾞﾒﾝﾄｼｽﾃﾑの管理者という実務的存在かの2種の考えがあるとしている。しかし、海外の解説書では後者が大半であり、規格執筆者も、品質ﾏﾈｼﾞﾒﾝﾄの業務を指揮監督する人と説明している。つまり、品質ﾏﾈｼﾞﾒﾝﾄの日々の業務をﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄに代わって司る「経営代行者」である。
<実務における経営代行者の必要性>
組織のﾏﾈｼﾞﾒﾝﾄを職務とするﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄの日々の業務は、ﾏﾈｼﾞﾒﾝﾄの各業務の実行を指揮、監督し、とりわけ諸業務の間の関係を調整、制御することである。しかし組織全体のﾏﾈｼﾞﾒﾝﾄを司るﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄは多忙であるから、個別の日常問題に係わる深さには限界がある。このために、組織の業績を左右する重要な問題のﾏﾈｼﾞﾒﾝﾄに関して特定の代行者を置き、ここに一元化された情報とその分析の報告、提言に基づいて、
ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄが組織の業務を統括するような業務体制がとられることは珍しくない。
日本では例えば品質担当執行役員、英米ではQuality Directorなどである。また、一般の機能別組織体制においては、例えば品質部門長は品質に関しては他部門の業務や部門間の業務を調整する責任と権限を有しているのが普通で、ﾄｯﾌﾟﾏﾈｼﾞﾒﾝﾄは各機能部門長によるこのようなﾏﾈｼﾞﾒﾝﾄの一部代行責任の上に立って組織のﾏﾈｼﾞﾒﾝﾄを統括している。規格の意図の「管理責任者」は、このようなﾏﾈｼﾞﾒﾝﾄの一部を代行する管理者のことである。
| |
