しばらく続いた 「ISO9001 7.3 設計・開発」についてのシリーズも、
今回でいったん一区切りです。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
＜観点２＞ 「何を○○するの？」
◆妥当性確認：2010/2/6の記事でも触れましたが、対象となるのは
「結果として得られる製品」であり、それが
「指定された、意図された用途」に適うかを確認するのが
「妥当性確認」です。
実際に作ったモノをじっくり見てみたら、設計図を描いているときには
なかなか気付かないような不備に気付くかもしれません。
あるいは、それを現場の職人さんが修正した痕跡を見つけるかもしれません。
はたまた、製造技術の限界により、設計者の意図通りに作られてない点が
発見できるかもしれません。
私がISO9001に関わるよりずっと前の、製造業向けCAD・CAMシステムの
営業をしていた頃にによく耳にしたことですが、
設計という作業は、決してお絵描きではありません。
描いて終わりではないのです。
あくまでも、実際に作られる「モノ」こそが大事であり、
設計・開発というのはモノに至るまでの前工程の一つです。
だからこそ、設計・開発の質を評価しようと思ったら、
「現物」なしには語れないのです。
実際に顧客に届けられる製品（やサービス）の品質に対して、
製造現場だけでなく組織全体・全工程がそれぞれの責任を果たす、
というのがISO9001の主旨なのだろうと勝手に解釈しています。
月: 2010年3月
「設計・開発」とは ＜4＞ レビューと検証と妥当性確認 【対象（中編）】
珍しく連続投稿です。
いつもこの筆不精なブログをお読みいただいている皆様、本当にありがとうございます。
妥当性確認は後編に回し、今回の中編では設計・開発の検証（7.3.5）のみを取り上げます。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
＜観点２＞ 「何を○○するの？」
◆ 検 証 ：これは比較的分かりやすい部分です。（少なくとも文意としては。）
設計・開発のアウトプットが、インプットされた要求事項を満たしているかを
確認すればよいだけです。
なお、アウトプットはインプットと対比しやすい形態をとるよう、
7.3.3で求められています。
そのインプットとはどんなものかと言うと、
・その製品の、機能や性能の要求事項
（顧客から明示された機能や性能と、
そうではないが暗黙の了解に基づく機能や性能の両方だと考えられます。）
・関連する法規制など
・過去の類似事例があれば、そこで得られた、今回の設計・開発に有用なノウハウ。
・設計・開発に不可欠なその他の要求事項
の４点から成ります。（7.3.2参照）
アウトプットの条件は、上述の形態に加え、
・インプットされた要求事項を満たし、
・後工程（購買・製造およびサービスの提供）に必要かつ適切な情報であり、
・製品の合否判定基準が分かり、
・製品の安全かつ適正な使用に不可欠な特性が分かる（※）
ことです。（7.3.3参照）
※ たとえば製品の一部に有害物質が含まれている場合です。
最終的には、「取り扱い上の注意点」を取扱説明書に明記しなくては販売出来ません。
しかし、なにもその文面までを設計・開発部門で考えなくてはいけないわけではありません。
まあやりたければやってもいいのですけど、普通は後工程の仕事です。
「有害物質がふくまれていますよ！」という情報が、確実に後工程に伝わればいいのです。
言わずもがな、伝わっていないと大変なことになります・・・
「設計・開発」とは ＜3＞ レビューと検証と妥当性確認 【対象（前編）】
おまたせしました。2010年02月6日の記事の続編です。
気がついたら１か月も空いてしまいました・・・
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
＜観点２＞ 「何を○○するの？」
◆レビュー ：規格には、「設計・開発の結果」が「要求事項」を満たせるかを評価し、
問題があったらなんとかしなさい、とあります。
ここで言う「結果」ですが、一体何を指しているのでしょうか？
また、「要求事項」は何を指しているのでしょうか？
手がかりになるる記述が乏しくISO9001の中でも大変不親切な部分です。
次項の「検証」には、「設計・開発からのアウトプットが云々」という記述があるので、
「結果」は、必ずしも「アウトプット」と同一のものを指すわけではないことがわかります。
同じものを指すのであれば、同じ言葉を使うはずですから。
「設計・開発からのアウトプット」であれば、「（次工程である）製造工程に引き渡すモノ」
（製造業であれば設計図面や試作品など）であることと理解できますが、（7.3.3のb)参照）
それとは別の概念である「設計・開発の結果」とは何でしょうか？
ヒントになると思われる記述が、「妥当性確認」の項にあります。
ここに、「結果として得られる製品が云々」とあるのです。
「製品とは、製造工程の結果なのでは？」という疑問が湧く方も少なくないと思います。
最終的に出来あがる「モノとしての製品」ならその通りでしょうが、
設計・開発工程においても、手では図面を書きながらも、頭の中には
出来上がった製品のイメージがあるはずです。
（そもそも、そうでなければ図面は起こせない。）
設計・開発の途中段階においては、「結果（として作られるであろうの製品）」は
設計者の頭の中にしかありません。
「こんなモノを作りたい」というイメージです。
最初はボンヤリしているでしょうが、スケッチを描いたり試作してみたりして、
徐々にはっきりさせていきます。
その「作りたいモノのイメージ」が「要求事項」を満たしているか、
設計途中でチェックしなさい、と言っているのが「設計・開発のレビュー」だと思います
ではさて、「要求事項」とは何でしょうか？
通常、規格内で要求事項と言う言葉が使われる場合、
「顧客要求事項」や「製品に関連する要求事項」など、何らかの修飾がなされます。
しかしこの7.3.4にはそれがありません。
英語の原文を読んでも、やはり単なる「requirement」とあるのみです。
ということは・・・ あらゆるタイプの要求事項を含んだ概念でしょうか！？
そうすると、全ての規格要求事項も含むことになってしまいますので、さすがに馴染みません。
ここは、「製品に関連する要求事項」に読み代えてよいと思います。
（この部分は、根拠が薄いと言われても仕方ないかもしれません・・・）
なお、製品に関連する要求事項とは、顧客が明示した要求以外にも、
・常識的に考えて満たしていなくてはいけない暗黙の要求
・法令などの規制
・その他、組織が必要と判断したもの全て
が含まれます。（7.2.1参照）
さて、この「設計・開発のレビュー」が規格に盛り込まれた意図は何でしょうか。
設計・開発を進め、技術的な課題と格闘するうちに、
いつのまにか設計者の頭の中で「作りたいモノのイメージ」が
「顧客が望むモノ」からズレていくのを防ぐためだろうと、私は考えています。
レビューだけで長くなてしまったので、検証と妥当性確認については次回に持ち越します。
早めに書くよう心がけます・・・