Quality Management System 品質マネジメントシステムーISO9001:2015



8 業務の運営
8.1 業務運営計画作成と管理


組織は，次に示す事項によって、製品及びサービスの提供に関する要求事項を満たすために必要とされるプロセス（4.4参照），および条項6で決定した取組みを実施するために必要なプロセスの計画を策定し，実施し，かつ，管理しなければならない。
　a)　製品およびサービスに関する要求事項の明確化；
　b)　プロセスに関する基準（criteria）の設定；
　　　1)　プロセス；
　　　2)　製品及びサービスの合否判定；
　c)　製品およびサービスの要求事項への適合性を達成するために必要な資源の明確化；
　d)　基準（criteria）に従ってプロセスの管理を実施；
　e)　次のために、必要とされる程度の，文書化された情報を明確化し、維持し、保持する；
　　1)　プロセスが計画どおりに実施されたという確信をもつ；
　　2)　製品及びサービスの要求事項への適合性を実証する。
　　
　
この計画策定のアウトプットは，組織の業務運用に適したものでなければならない。 　

組織は，計画された変更を管理し，意図しない変更によって生じた結果をレビューし，必要に応じて，不都合な影響を軽減する処置をとらなければならない。 　

組織は，外部委託したプロセスが管理されていることを確実にしなければならない（8.4参照）。

解説:


新規格の標題には新しい用語”業務の運営(operation)”が用いられているが、要求内容は現行規格の”7章　製品の実現”とほとんど同じである。顧客の要求に適合した製品とサービスを提供する組織の中核となる業務部門を対象とした行動規範を定めるための要求事項が納められている。

新規格の冒頭での”4.4項　品質マネジメントシステムおよびそのプロセス”では、組織全体の大枠のプロセスを規定している。一方、この条項は、顧客からの受注業務から始まり出荷・納品までの中核となるプロセスについて言及している。加えて、”6.1項 　リスクと機会に対処するための活動”において決定されたリスクと機会への対応策を具体化するプロセスの確立をも求めている。現行規格の”製品の実現プロセス”に相当するが、必要な資源の決定とリスクと機会への対応まで考慮するとなると、新規参入の製品やサービスを企画する部門のプロセスを定め組み入れる必要がある組織があるやもしれない。計画が変更されたならば悪影響を軽減するための処置をとることは、新しい要求事項である。また、現行規格にはない外部委託のプロセスが追加され強化されている。なお、この条項の多くの部分が共通規格Annex SLの文言を採用しているので、他のマネジメントシステムと統合して一つのマネジメントシステムとして運用することを予定していている組織には有利になるはずである。




品質マニュアル事例文言

9. 業務の運営
8.1　 業務運営計画作成と管理業務
当社は、製品もしくはサービスの実現に必要となるプロセスの計画を作成し、詳しく説明を加える。製品もしくはサービスの実現の計画作成は、マネジメントシステムのその他のプロセスの要求事項と一貫性を持たせている。 このような計画作成には、 製品もしくはサービスの要求事項とともに、 組織のコンテキスト（上記2章を参照すること）、および現有の資源とその能力に関連する情報が考慮される。

このような計画作成は、次のことを行うことで完成される：
　a)製品もしくはサービスに対する要求事項、
　b)プロセスと製品もしくはサービスの許容基準を確立する、
　c)製品もしくはサービスの要求事項に対しての適合性を達成するために求められる資源を決定する、
　d)基準に基づいてプロセスを管理する、
　e)プロセスが計画された通り実行されたことを確信し、製品もしくはサービスの要求事項に対する適合性を明示するために十分な文書化された情報を明確にし、維持管理し、保持する。 　

　業務の運営に対し変更は、文書「変更管理手順書」（未作成）に従って実施される。 　

　外部委託されたプロセスおよび当社が彼らを管理 する手段は、文書「外部委託プロセス手順書」（未作成）に詳細に記述されている。


8.2 製品とサービスへの要求事項の決定
8.2.1 顧客とのコミュニケーション


顧客とのコミュニケーションには，次の事項を含めなければならない。
　a)　製品およびサービスに関する情報を提供すること；
　b)　引合い，契約、あるいは注文の処理すること。これらの変更を含む；
　c)　苦情を含めて，製品およびサービスに関する顧客からのフィードバックを取得すること；
　d)　顧客の所有物の取扱い、あるいは管理すること；
　e)　実質的に価値があり妥当な場合には，不測の事態への対応に関する特定の要求事項の設定すること。

解説:
”はじめに顧客ありき”の考え方を採用し、顧客からの要求を明らかにするために顧客との交流プロセスを確立し実行するように規格は求めている。一般的には営業活動や受注担当がこれに相当する。顧客の所有物の取り扱いと緊急事態への対応以外は現行規格と同じで特に変更された内容はない。

顧客とのコミュニケーションを図るためには、次のことが一般的に実施されている。実際に行われいる手順を定めることが求められている。

　ー製品情報のコミュニケーションーー製品カタログ、製品の展示、企業訪問による説明などによって顧客に提供される。営業活動を通じて顧客からの製品情報を収集することもある。
　ー引き合い、契約、注文、注文の変更に関する手続きーーこの中でも、顧客からの変更を速やかに関連部署に連絡する手続きを決めることが求められる。
　ー顧客からのフィードバックーー顧客苦情を含め、顧客の声を関連部署に速やかに反映させることを重視した手順を明確にする。特に、苦情が組織の上部に伝達される仕組み作りが重要となる。これが欠落している組織は、持続可能とは思えない。
　
　緊急事態への対応は、リスク管理の一環として取り扱う必要があろう。自然災害などにより製品やサービスを提供できない事態が生じた場合を想定して、その対応が必要となる組織もあろう。ただし、あくまで該当する場合である。



品質マニュアル事例文言

9. 業務の運営
8.2　 製品とサービスへの要求事項
8.2.1 顧客とのコミュニケーション

当社は、次のことに関連する顧客との効果的なコミュニケーションを実現している：
　a)製品もしくはサービスに関する情報の提供、
　b)引合い，契約、あるいは注文の処理すること。これらの変更を含む、
　c)苦情を含めて，製品およびサービスに関する顧客からのフィードバックを取得すること、
　d)顧客の所有物の取扱い、あるいは管理すること、
　e)妥当な場合には，不測の事態への対応に関する特定の要求事項の設定すること。



8.2.2 製品とサービスに関する要求事項の決定


顧客に提供する製品及びサービスに関する要求事項を明確にするときには，組織は，次の事項を確実にしなければならない：
　a)　次の事項を含めて，製品及びサービスの要求事項が定められている：
　　1)　適用される法令・規制要求事項；
　　2)　組織によって必要であるとみなされたもの
　b)　組織は提供する製品およびサービスに関する要求に応じる能力がある。

解説:
この条項は、現行規格の7.2.1とほとんど同じだが、簡略化されている。一方、現行規格の納入後の活動は次項に移された。
顧客との取引内容は、製品とサービスや顧客の形態によって大きく変わる。たとえば機械部品の加工ならば顧客から図面を受け取り、加工上や検査の注意点、納品のための包装や梱包、納期、支払い条件などを双方が合意すれば、取引が成立する。他方、住宅建設の受託では、顧客との打ち合わせを重ね、幾度かの変更の経て最終的な建設図面と見積書を作り、双方が合意すれば契約書を交わす。このような商品やサービスの取引にかかわる一連の条件を定めることが求められている。場合によっては、顧客は求めてはいないが組織が独自に必要と判断された事項も含めることがある。

製品やサービスを提供するにために遵守しなければならない法令や規制面での要求事項を明確にすることは当然である。製品の危険物表示、食品の表示に関する規制などがこれにあたる。最近は、各国が輸入品に対し多くの規制を課しているので、事前に検討し対応しなければならない。

当然ながら、顧客に提示した製品とサービスの要求事項を満たすことができる能力を組織が有していることが事前に確認されねばならない。また、最後の文言は、現行規格の条項7.2.2の注記にあるインターネット販売での取り扱いに関することである。ネット上で表示している内容を組織が確実に履行できることを前提してネット販売ができることを意味する。



8.2.3　製品とサービスに関わる要求事項のレビュー
8.2.4 製品とサービスの要求事項への変更


8.2.3.1　組織は，顧客に提供される製品及びサービスに関する要求事項を満たす能力をもつことを確実にしなければならない。 組織は，製品及びサービスを顧客に提供することをコミットメントする前に，次の事項を含めて，レビューを行わなければならない。

　a)　顧客が特定した要求事項。これには引渡し及び引渡し後の活動に関する要求事項を含む；
　b)　顧客が明示してはいないが，特定された用途、あるいは意図された用途が既知である場合，それらの用途に応じた要求事項；
　c) 組織が特定した要求事項；
　d) 製品およびサービスに適用される法令・規制要求事項；
　e) 以前に提示されたものと異なる，契約、あるいは注文の要求事項。
　
組織は，契約、あるいは注文の要求事項が以前に定めたものと異なる場合には，それが解決されることを確実にしなければならない。 　

顧客が要求事項を書面で示さない場合には，顧客の要求事項を受諾する前に、組織はによって確認されなければならない。

注記：インターネット販売のようなある種の状態には、個別の注文に対して正式のレビューは現実的ではない。それに代わって、カタログのような、適切な製品カタログによってレビューが充当される。 　

8.2.3.2　組織は，該当する場合には、次の事項に関する文書化された情報を保持しなければならない。
　a)　レビューの結果；
　b)　製品及びサービスに関する新たな要求事項。
　
8.2.4　製品及びサービスに関する要求事項の変更

製品及びサービスに関する要求事項が変更されたときには，組織は，関連する文書化した情報を変更することを確実にしなければならない。また，関連する人々に変更された要求事項が認知されていることを確実にしなければならない。

解説:
この条項も、納入後の活動を除いて現行規格7.2.2と同じである。
顧客が発注する形態も発注書、FAX、電話での口頭注文、Eメール、 ホームページなど種々雑多である。いずれも顧客の要求している内容が不正確であったり、間違った理解をして受け取ったりすることはよくあることである。このような間違いを犯さないようにするために、顧客の要求事項をレビューするプロセスを設ける必要がある。受注担当者の記録を上司がチェックするなどがそれである。すでに自社なりの方法を作り上げているはずであるから、それをそのまま採用すればよい。

製品とサービスの要求事項のレビューで確認された結果は、文書化された情報として残し記録として保持することが要求されている。とはいえ、確認した証拠として受注書に上司が捺印すれば済むことである。発注が電子媒体で行われた場合には、電子署名が必要かもしれない。

要求事項が変更されことが、速やかに関係部署に伝達されなかったために不適合となることがしばしば見られる。これを避けるためには、作業指示書などの文書を修正し、関連する要員に確実にかつ速やかに通達することができるような手順が肝要となる。電子的な手続きを確立することが望ましい。この変更に関する文書は、文書された情報であり、記録として保管されなければならない。



8.３ 製品とサービスの設計と開発
8.３.1 一般


組織は，以降の製品およびサービスの提供を確実にするために適切な設計・開発プロセスを確立し，実施し，維持しなければならない。

解説:
DISでの条項の文言を下に残した。FDIS案は簡略されていることがわかる。DIS案の注記などがFDIS案の内容を理解するのに役立ちと思う。

組織の製品とサービスの詳細な要求事項があらかじめ確立されていない場合、あるいは顧客またはその他の利害関係者によって明確にされていない場合では、その後の生産やサービス提供に対して十分な形で、組織は設計と開発プロセスを確立し、実施し、維持しなければならない。

注記1 組織は、生産とサービス提供の開発のために8.5項で示されている要求事項を適用することもできる。
注記2 サービスに関しては、設計と開発の計画（次項）は、サービス提供プロセス全体に取り組むことができる。したがって、組織は、8.3項と8.5項の要求事項を合わせて検討することを選択できる。


この要求事項を除くと、現行規格7.3章の条項を置き換えただけの内容になり、全般的には簡略化されている。この条項だけは、新規に策定された。すなわち、 既存の製品とサービスでは、顧客の要求を満たすものはなく、しかも顧客や利害関係者の要求事項が不明確であり、製品やサービスを顧客に提供できない場合には、設計・開発のプロセスを通じて新規の製品やサービスを具現化しなければならい。そのためのプロセスを確立することを求める条項である。

注目しなければならないのは、サービス業や外部供給者に依存するファブレス企業に配慮した二つの注記である。
注記１は、組織には設計・開発プロセスが存在しないならば、この要求事項を除外できることを意味している。4.3項”品質マネジメントシステムの適用範囲の決定”で許容されている除外対象の要求事項が不明だったが、この注記で明瞭になった。たとえば、顧客から図面を受取り製品を製作するような企業では、このプロセスを経ることなく8.5項の生産およびサービス提供に直行することが許される。ただし、外部委託生産業者のように製品の開発は行わないが、部品を購入し組み立て、検査を経て出荷するような高度な生産工程が求められるならば、委託先と共同して生産工程を設計・開発するプロセスが求められるので留意しなければならない。

注記２は、サービスに特化した内容で、その理解には”サービス”とは何かをまず理解する必要がある。”サービス”の定義を下に引用する。

3..48 サービス
提供者と顧客との交流時に必然的に実行された少なくとも一つの活動の結果である不可視のアウトプット

項目”サービス”に対する注記：サービスの提供には、たとえば、次の事柄が含まれる：

　ー顧客が供給した可視できる製品に実行される活動（たとえば、自動車の修理）
　ー顧客が供給した不可視の製品に実行される活動（たとえば、還付される税金を準備するための収支報告書）
　ー不可視の製品の納入（たとえば、知識伝達の文脈においての情報の引渡し）
　ー顧客のための雰囲気を創成すること（たとえば、ホテルやレストランで）

サービスは通常顧客によって体験される。


サービスの実例から分かるように、サービスの内容次第では設計・開発の手順を経ずとも顧客に直接提供するだけでも十分である組織もある。他方、大規模な市場調査を実施して得られた大量で高度な専門知識を顧客に提供しなければならない企業のようなケースでは、”8.3 設計と開発”での開発ステージの概念とともに、”8.5 生産とサービス提供”の両方を活用するのが効果的である場合がある。あくまで、どちらを選択するかはサービスの内容と性質によって組織が決めることになる。



8.3.2 設計と開発の計画作成


設計・開発の段階（stages）及び管理を決定するに当たって，組織は，次の事項を考慮しなければならない。
　a)　設計・開発活動の性質，期間及び複雑さ；
　b)　要求されるプロセスの段階。適用される設計・開発のレビューを含む；
　c)　要求される設計・開発の検証及び妥当性確認活動；
　d)　設計・開発プロセスに関する責任および権限；
　e)　製品及びサービスの設計・開発に必要な内部的資源及び外部的資源；
　f)　設計・開発プロセスに関与する人々の間のインタフェースの管理の必要性；
　g)　設計・開発プロセスへの顧客および使用者の参画の必要性；
　h)　次に続く工程のための製品及びサービスの提供に関する要求事項；
　i)　顧客およびその他の関連する利害関係者によって期待される設計・開発プロセスの管理レベル；
　 j)　設計・開発の要求事項を満たしていることを実証するために必要な文書化した情報。

解説:
この条項は、新製品開発のための手法のひとつである”ステージゲート法”の基本にしているので、以下に、概要を紹介する。

ステージゲート法とは何か？

既に一部大手日本企業の研究開発部門を中心に導入が進んでおり、ご存知の方も多いと思いますが、ステージゲート法とは、技術開発や製品開発テーマをアイデアの創出から市場導入、さらに製品の製造・販売の中止まで、技術や製品の寿命全体をマネジメントする手法です。（但し、重点は、アイデア創出から市場導入までにあります。） 「ステージゲート」という名前がつけられている理由は、全体のプロセスを複数の活動ステージに分割し、ステージ間にゲート（関門）を設け、ゲートでの評価にパスしたプロジェクトのみを次のステージへ進むことを許可するという仕組みとなっているからです。
ほとんどの企業で、程度の差はあれ、実際にはこのようなプロジェクトの進め方をとっていると思います。しかし、外見は同じ、類似していても、ステージゲートは単にゲートとステージがあるというだけでなく、長い歴史を通じて（ステージゲート法は米国を中心に20年以上の歴史があります）考えられてきた工夫が組み込まれています。また今日でもまだステージゲート法は進化しています。（出展先：ベクター・コンサルティング社ホームページ）


新製品を開発する例を使って説明する。一般的に開発プロジェクトはアイデアの創出から始まり、市場調査のステージに移り、試作品の作成と評価のステージを経て、試験的な市場投入を行い新製品の性能を確認するステージが終われば、本格的な市場参入に入る。これらそれぞれが個別のステージである。あるステージから次のステージに移るには、二つのステージの間に設けられたゲートでの評価による許可が下りないと次のステージに移れない。このゲートが規格では”接点”であり、ゲートの評価が”レビュー”である。レビューで判定を下す門番を誰にするを決め、その責任と権限を決めることが要求されている。この程度の理解があれば、次に続く要求事項を理解することは簡単になる。

規格の原文は、”planning”なので計画を作成することを意味する。要求されている計画作成とは、次の要素を明確化することである：

ー”設計及び開発の段階”ーー製品の仕様や設計図を作成する、
ー”レビュー、検証と妥当性確認”ーー計画された各段階でレビューし、検証し、妥当性確認をどのようにするのかを決める、
ー”責任と権限”ーー設計及び開発プロセスを担当するグループや個人の責任と権限を決める。

製品とサービスの設計及び開発の一般的な段階は、以下のである。

１。顧客ニーズを明確に確立する。
２。顧客ニーズを要求事項として明示的な仕様に変換する。
３。この要求事項を満たすための計画を立てる。
４。要求事項を満たすための資源と材料を手配する、
５。要求事項を完成させるにはどのような可能性があるかの可能性を見つけるための調査を実施する。
６。 多くの可能な解決策の中からもっとも適切な手段を選ぶためのプロジェクト調査を実施する。
７。製品とサービスの特徴と特性の全てを詳細に記述した仕様を作成する。
８。提案された設計に基づいた試作品あるいはモデルを製作する。
９。開発された製品、あるいはサービスもしくはプロセスが設計要求事項と顧客ニーズを満たしているかどうかを見つけるために広範囲の試験を実施する。
１０。製品もしくはサービスがとこの目標に適合するまでデータを設計にフィードバックし再開発作業を繰り返して行う。



8.3.3 設計と開発のインプット


組織は，設計・開発する特定の種類の製品およびサービスに不可欠な要求事項を明確にしなければならない。組織は，次の事項を考慮しなければならない。
　a)　機能及びパフォーマンスに関する要求事項；
　b)　以前の類似の設計・開発活動から得られた情報；
　c)　法令・規制要求事項；
　d)　組織が実施することをコミットメントしている規格、あるいは行動規範；
　e)　製品およびサービスの性質に起因する欠陥によって起こり得る潜在的な結末（の影響）。
　

インプットは，設計・開発の目的に対して適切で，漏れがなく，曖昧でないものでなければならない。 　

設計・開発へのインプット同士の（間で相反するものがあるときは、その）矛盾は解決されていなければならない。 　

組織は，設計・開発へのインプットに関する文書化した情報を保持しなければならない。

解説:


現行規格の"設計・開発の移転"のステージが省略されているが、新製品の生産や新規サービスを顧客に提供する現場に移行するプロセスは実務上重要であるので、開発から現場への移行のためのプロセスは必ず定めなければならない。

組織が新しい製品やサービスの設計あるいは開発するのは、その機能や性能だけではない。顧客が明確な指示を与えない要望や法的な要求事項にも配慮が必要になることがある。たとえば、危険物ならば消防法による危険物表示、PL法による警告ラベル、運送業ならば陸運局通達の遵守などがそれである。規格文言には、それ以外のインプット情報を詳しく列挙しているが、現行規格と本質的にほとんど変わらない。

設計及び開発する製品とサービスの機能や性能のみならず、製品によっては消費者の用途についても明らかにする必要がある。あるいは、その他の利害関係者の立場から環境に優しい製品のリサイクルの必要性についても明確にしなければならない場合がある。



8.3.4 設計と開発の管理


組織は，次の事項を確実にするために，設計・開発プロセスの管理を適用しなければならない。
　a)　達成すべき結果を定める；
　b)　要求事項を満たすための設計・開発の結果の能力を評価するために，レビューを行う；
　c)　設計・開発からのアウトプットが，インプットの要求事項を満たすことを確実にするために，検証活動を行う；
　d) 結果として得られる製品及びサービスが，指定された利用、あるいは意図された用途に応じた要求事項を満たすことを確実にするために，妥当性確認活動を行う；
　e)　レビュー，もしくは検証及び妥当性確認の活動中に明確になった問題に対して必要な処置をとる；
　f)　これらの活動について文書化された情報を保持する。
　
注記　設計・開発のレビュー，検証および妥当性確認は，異なる目的をもつ。これらは，組織の製品及びサービスに対して適切であるように，個別に、あるいは組み合わせて行うことができる。

解説:
現行規格では小分けされていた要求事項のいくつかをまとめただけで、内容が変更変されたものは見当たらない。過去には、検証と妥当性確認との違いをえんえんと説明することもあったが、今は常識となりその必要はなくなっているので、このように省略されたと推測する。

設計及び開発プロセスを実行する過程で具体的に何をするのかを決めるだけのことであり、設計及び開発の関係者にとっては通常的に行われていることである。ただ、設計及び開発の担当者は、外部から干渉されることを嫌う性向があるので、ある程度厳格な管理が必要だろう。



8.3.5 設計と開発のアウトプット


組織は，設計・開発からのアウトプットが，次のとおりであることを確実にしなければならない：
　a)　インプットで与えられた要求事項を満たしている；
　b)　製品およびサービスの提供のために次に続く工程のために適切である；
　c)　必要に応じて，モニタリングおよび測定の要求事項，並びに合否判定基準を含めるか，あるいは参照として引用している。
　d)　意図した目的および安全で適切な提供には不可欠な製品及びサービスの特性を規定して定めている。

組織は、設計及び開発プロセスのアウトプットに関して文書化された情報を保持しなければならない。

解説:
開発の最終ステージは、”アウトプットがインプットに合致している”ことを確認することである。難しいことではあるが、これを十分に確認しなかったがために重大な失敗や事故に繋がる可能性があることを考えるともっとも重要である。保持する文書化された情報が、設計と開発のプロセスで発生した情報となっているので、従来と同じようにステージ毎に行われたレビューの結果を記録として残すのが賢明だと思われる。ただし、その内容はついては言及されていないのでの、通常の議事録で十分だろう。

この要求事項から分かるように、設計及び開発の対象には、製品の生産プロセスの観点からの妥当性に対する配慮も含まれている。原材料の入手可能性や製品のライフサイクルにも配慮する必要性なども検討しなくてはならない場合もある。



8.3.6 設計及び開発の変更


組織は，製品およびサービスの設計・開発の間もしくはそれ以降に行われた変更を，要求事項への適合に悪影響を及ぼさないことを確実にするために必要な範囲で明確にし，レビューし，管理しなければならない。

組織は，次の事項に関する文書化された情報を保持しなければならない：
　a)　設計・開発の変更；
　b)　レビューの結果；
　c)　変更の許可委任；
　d)　予期しない悪影響を防止するための処置。

解説:
製品やサービスの設計・開発過程で変更を余儀なくされることはよくある。たとえば、以下のように時である。

　ー顧客が製品やサービスの仕様変更を伝えてきた。
　ー当初計画されたよりもさらに高度な製品やサービスでなければ市場化できないと市場調査によって判明した。
　ー開発のレビューで変更する決定がなされた。
　ー検証と妥当性の確認の結果からインプットとアウトプット条件を満たさないと判明し変更せざるを得なくなった。

規格は、これらの変更を明確にし文書化された情報として記録を保持することを求めている。