品質システム--一般
あなたのしていることを書きだしなさい
ISO9000の要求事項を充たし、しかも実際に用いられている品質システムが文書で作成され、常に品質マニュアルが更新していることをここで要求している。また、その品質マニュアルが手順書を含むならば、手順書の文書がすぐに分かるように品質マニュアルが整備されていることも求められている。すなわち、品質マニュアルは、品質システムの「道路地図」と考えられるとしている。
ここで、品質マニュアルは、企業の実態に合わせ適切と考えられるものならば、どのような書式であっても支障がないことを指摘している。たとえば、規格の章どりではなく、企業の仕事のプロセスにしたがって作成されても良しとしている。だだし、その場合は、マニュアルと規格との相互参照表を用意することを勧めている。
さらに大事なことは、品質システムは事業の業務に当てはまる章だけでよく、適応しない要求項目を省略できると述べられている。しかし、業務に関係しないことを品質マニュアルに記載しておくを推奨している。
品質システムの手順
手順書を作り、それに従う
手順書とは、業務のやり方のポイントを記述したものではあるが、フローチャートのように非常に単純なものですませることもできるとしている。当然のことではあるが、すでにでき上がっている現有の書類を品質マニュアルに引用することもできる。
手順書は、だれが、何を、どこで、いつ、なぜ、どのように仕事を行うかを文書にすれば良しとしとしている。また、どのように行うかは別の文書、たとえば、作業指示書や設備機械の操作マニュアルを手順書に引用する方法もある。
ここで問題になるのが、手順書はどの程度詳細に記述すればよいのかの判断基準だが、ガイドラインの記述をそのまま転記する。
「使用される方法、必要となる技能、実施される教育・訓練、および監督の程度によって大きく異なります。非常に詳細であるからといって活動が完全に管理できるとは限らないので、過度な詳細さは可能な場合避けるべきです。」
どうすればよいのか明快ではないが、よく教育・訓練をしていれば手順書は簡単なものでよいと解釈するのが正しいと考える。事実、ガイドラインは次のように述べている。
「適切な教育・訓練によって詳細な指示書は不要となる。」
さらに、言葉を使って手順を記述するのが難しい時には、図やビデオを用いたり、写真で示す方が正確に伝えられるともしている。しかも、手順書では経営者や管理者が
「業務はこのようにやってほしい」という希望や期待を込めてたものにしてはならないと忠告している。この点からも、手順書の作成は従業員の参画のもとで進め、「自分のシステム」であることの自覚が得られるようにすべきと思う。
品質計画
それをどのように行うか？
品質計画書の作成が求められているが、その内容がなにかよく理解できない。そこでこれはQC工程表や新製品開発計画書のこととすれば理解できる。
通常、QC工程表、フローチャート、少なくともチェックリストを作成して、それに基づいて制作ないしは製造を行っているので、それに検査項目、合否判定基準などこの章での要求事項を加えることですむ。要は、工程管理が出来ればこの要求を満たすことが出来る。
さらに、同一製品を「日常的に繰り返し」製造・制作されているなら、品質マニュアルと手順書を参照することにすれば良しともしている。いずれにしろ、「定例的」でない長期プロジェクトとして開発計画書が必要な場合を除き、ここで求められている品質計画書は不要である。
契約内容の確認
あなたが顧客の要求事項を理解し、それを満たすことができることを確認してください
ここでの契約とは、注文書、口頭での合意（納期、支払条件など）、または電話による注文のことである。
設計管理--一般
設計開発の業務に対しては各段階で管理出来るような仕組みを作成すること
顧客からの要求事項を満たすために設計管理が確実に行われるように、下記の各段階に別けて手順書を作成することが求められている。すなわち、
設計目的をはっきりと整理し、どのように設計を進めるか、だれが設計を行うかを定め計画書を作成する。
設計を進めるに当たって必要とするすべての情報を文書化によって明確にする。
設計からのアウトプットがどのような形態であるのかを定める、すなわち製品の設計図なのか化学製品の構成内容と製造方法などを例としてあげられる。
設計が終了したときには、求められた製品特性が達成されているかを確認する。
設計業務の途中でさまざまな理由で設計内容が変更されるが、その変更事項を確認し、設計を変更する際の仕組みを取り入れる。
設計および開発の計画
だれが何をするのか？
だれが何をするのかを設計計画書として作成しなくてはならないが、設計活動の進捗に応じて、その設計計画書の更新をすることが求められている。この計画書は、最初の構想を作り上げ、最終製品が完成するまでのすべてのプロセスを管理できるものでなくてはならない。
組織上および技術上のインターフェース
だれとコミュニケーションをとる必要があるか？
中小企業の場合には、小人数であるからコミュニケーション上の問題はあまり重大ではないと思われるが、顧客、下請負業者もしかしたら規制上関係機関との連絡が必要となるかもしれない。このようなことが実態として起こるならば、かならず連絡事項の内容を記録として残すことが大切である。
設計へのインプット
なにを考慮する必要があるか？
当然のことであるが、考慮すべき主たることは顧客のニーズである。しかし、顧客から設計開発をしてほしいものはこれですと、文書で明示してくれることはほとんど無いのが、日本での実態である。その対策は、顧客と直接接触するセールスマンが顧客訪問報告書に出来うる限り正確に顧客の希望を記入し、これを設計部門（担当者）に連絡書として残す仕組みを作っておく以外にない。ここまでは、なんとかできることであるが、問題は規格で述べている「不完全、不明確または矛盾する要求事項」である。これは何を言っているかと言うと、顧客がもっている暗黙の期待、すなわち明記できない製品品質である。たとえば、わたしがアメリカで経験したのは、化学製品の匂いであった。匂いが強いので、採用出来ないと顧客が決定したのだ。この例のごとく、この暗黙のニーズが設計に取り入れられていないために、重大な結果を招くことがあるので、注意する必要性をガイドラインは強調している。そして、製品品質および特性以外に考慮すべきものの事例を挙げているので、下記する。
人体に悪影響を与える安全、衛生、および環境に関する法令や規制
設計からのアウトプット
なにをしたか？
設計からのアウトプットの例の一部を冒頭で述べたが、ガイドラインはさらに下記のものを挙げている。すなわち、
ファッションのデザインでは、スケッチと用いる材料の仕様書
デザイン・レビュー（設計審査）
道筋から外れていないか？
デザイン・レビューとは、マネージメント・レビュウと同じ考えであり、設計・開発を進めている途中で見直しを行うことである。顧客のニーズに沿って設計活動が暗礁に乗り上げていないか、あるとすればその問題はなにか、良い解決策があるのか、などを関係者が集まって正式にチェックすることとなる。ガイドラインは、このような
デザイン・レビューをどの程度の頻度で、またどの段階で行えばよいのかを詳しく述べている。一言でいえば、設計の複雑さによって適時行えばよいとしている。たとえば、単純なエアー・コンディショナーなら設計完了時に一度だけデザイン・レビューを行うことですむが、ソフトウェアの設計では、設計期間中に顧客との折衝を含め多くのデザイン・レビューが必要な場合があるとしている。これに関しては通常に行っていることを踏襲すればよいことである。
もっと大切なことは、だれが参加してデザイン・レビューを行うかである。まず、設計に携わる人達はもちろんだが、製造や在庫・出庫のようにキーとなる人達を加える必要がある。また時には、組織内のみならず顧客や下請負業者のような外部の人を含める方が、効果がある場合も考慮すべきとされている。当然、見直し会議の結果は記録として文書化が求められる。ただ、ガイドラインは、簡単なデザイン・レビューならば、設計計画書に打ち合わせを行ったことを注記して、出席者が署名し、日付を記入するだけでもよいとしているので、この方法を大いに利用されれば良いと思う。
ここでガイドラインは、これから説明をする「設計検証」や「設計の妥当性確認」のそれぞれと「デザイン・レビュー」との関連を図示しているので参考にされるとよい。簡単に述べれば、これら三つの異なった設計のプロセスは相互関係があり、検証や妥当性確認の結果、設計の初段階にもどって設計開発活動を行わなければならないことがあると言っているだけだ。これも従来から企業では実施されているので、目新らしいことではない。
設計検証
正しく行ったか？
設計検証とは、言葉からすぐに理解できるように、設計プロセスの最後の段階で得られた試験や実証検査の結果が顧客の要求事項を満たしているかをチェックすることである。これをやらずに済ませる設計活動はまずなく、だれでも行っていることであり、検証方法は設計対象となっている製品によって大きく異なることも周知のことである。とくに、ガイドラインが指摘していることは、だれが検証を行うか、どのような方法を検証に用いるか、どのような記録を残すかを設計計画書に含めて置くことである。設計計画書の必要事項がこの内容からも明確になってきている。
文書による注文、たとえば、郵便またはファクミシリによって注文を受けたものはそれ自体が「契約の確認」となる。一方、電話やコンピュータによる注文には、少し工夫が必要になる。電話で受けた場合は、メモ帳に注文の内容を記入し、顧客の担当者に対してその内容を反復呼称すればよい。あるいは、メモ帳の内容をファクミシリで顧客担当者に送りかえすことをすれば完全である。コンピュータによる注文の場合は、恒久的にディスクに保存するか、ハードコピーをとる方法を採用すればよい。ここで、注意しなくてはならないことは、注文内容の確認である。注文を受けた後、だれかが内容を納期を含め確認する必要がある。これを行うには通常管理者であるが、確認した人は署名捺印し日付を記入することを忘れてはならない。
契約のための見積書が要求された場合も、同じように文書化と記録が要求される。ここでの注意点は、契約書に記載されている内容と見積書が異なっている場合である。この場合には、その相違点を明確に説明出来る書類が作成されていなくてはならない。
以上を要約すると、刻々と変わる顧客との商談内容が、仕様、価格、納期など顧客の受入条件を含め社内で充分に理解できる仕組みと記録が作成されていなければならないとなる。
設計開発そのものが事業の中心となる場合を除けば、中小企業では小人数で設計開発が行われていることが実際ではないだろうか。その場合、たった一人ならば問題はないが、二人以上（下請負業者もある部分を担当することも含む）が担当することになるならば、それぞれの担当業務を担当者に割り振ることが必要となる。
このように文章にすると、複雑な計画書のように思うかもしれないが、ガイドラインではそれぞれのステップと担当者がはっきりしていれば、フローチャート図のような簡単なものでもよしとしている。フローチャート図は一般的にこのような業務で使われているので、とくに新たにつくる必要は無く、そのフローチャート図を設計計画書とすることを文書化しておけばよい。
市場調査の結果
業界の慣行および規格
顧客および供給者の過去の経験
グラフィックス・アートノデザインでは、出版物の中で使われるレイアウト
食品の設計では調理方法
広告代理店のおける設計では、マーケティングキャンペーンの計画書
この節で重要なことは、顧客からの要求事項が満たされていることをどのように検証できるかを設計計画書の中で文書化されていなければならないことである。たとえば、製品が機械の部品であるなら規格で決められた寸法を測定するなどである。もしも、機械そのものであるなら、試運転となるかもしれない。とくに、法規制で定められている場合は、規定されている性能・特性が遵守できているかはかならず検証が必要になる。すべての検証結果は記録として残すことは、当然である。