設計・開発の変更管理についての承認行為に関する疑問
- ISO9001:2000（JIS Q 9001）の要求事項7.3 設計・開発 7.3.7 設計・開発の変更管理では、「変更に対して、レビュー、検証及び妥当性確認を適宜行い、その変更を実施する前に承認すること。」と記載されています。
- 現在の当社の承認行為では、設計担当者はレビュー、検証、妥当性確認を判断し、責任者の承認を得ます。変更後の承認行為では、責任者は変更されたアウトプットの承認のみ行い、設計担当者の判断に委ねます。この方法に問題はあるでしょうか？
- 設計担当者が出図する図面を責任者が承認すれば、「その変更を実施する前に承認」という要求事項を満たすことができるのかどうか知りたいです。
- ベストアンサー
「設計・開発の変更管理」の承認行為について
細かい内容で申し訳けありませんが教えてください。 ISO9001:2000（JIS Q 9001）の要求事項7.3 設計・開発 7.3.7 設計・開発の変更管理で 「変更に対して、レビュー、検証及び妥当性確認を適宜行い、その変更を実施する前に承認 すること。」とありますが「その変更を実施する前に承認」という部分の解釈がいまいち 分かりません。 現在当社では「設計担当者は一連のレビュー、検証及び妥当性確認を必要に応じて行うかど うかの判断をし、責任者の承認を得ること」となっています。 変更後の承認行為に関しては「変更に関して責任者は変更されたアウトプットの承認を行う」 のみとし、一連のレビュー、検証及び妥当性確認を必要に応じて行うかどうかの判断は設計 担当者レベルにしたいと思っています。この承認行為で問題があるでしょうか？ 設計担当者がレビュー、検証及び妥当性確認をした結果の記録と維持は行います。 言い回しがを難しなってしまって申し訳けありません。上記を簡単に言うと、設計担当者が出図する図面をその人以外の責任者が承認すれば、「その変更を実施する前に承認」という要求事項を満足するのかどうか知りたいと思いましたので宜しくお願いします。
- ISO
- 回答数6
- ありがとう数3
- みんなの回答 （6）
- 専門家の回答
質問者が選んだベストアンサー
- ベストアンサー
7.3.1設計・開発の計画c）設計・開発に関する 責任及び権限に対するルールをどのように定めて いますか？ それに従っていれば、ISO要求事項に対しては 適合です。 但し、設計担当者がレビュー、検証及び妥当性 確認の要否を決定して「本当に良いのか」考え直し たいところではあります。
その他の回答 (5)
二年前にＩＳＯ導入の際、文章を理解できず、困りましたが何度も読み直して行くうちに、自身の技術不足を痛切に感じ 1：各担当者の能力不足を明確にし、高い目標を設定 しクリアーして行く。 2：その為の意思疎通の努力を惜しまない。 の二点を念頭に入れました。ＩＳＯの要綱が全員理解できれば、すばらしい技術レベルアップに繋がると感じます。ちなみに当方の部門人数は3名でした。ＩＳＯの確認はそれを言っているのではないかと（回答からそれてしまいましたがお許しを）
言葉足らずの部分があったようです。すみません。 会社のレベルに合ったメリハリのある仕組みという点は、全くその通りだと思います。いくら理想を言っても重たすぎては実行力がありません。 また、担当の能力を高め、良いアウトプットを出せるようになることも当然大切だと思います。 ISOの目的が顧客の品質要求を工程上で作りこむことであるので、担当者の能力が優れているのであれば、担当者だけの判断でも良いかもしれません。ただ、ポカミスなど一人では防ぎきれないミスも時にはあると思うので、それなりのシステムは必要だとも思います。 作り上げたシステムを実際に運用して、結果として品質確保が十分になされるのであれば、それで良いと思います。
お礼
当社も「品質は工程内で作り込む」のはその通りですし、「ムダなコスト低減」「次工程はお客様」など色々良いことを掲げていますが、システムも意識面もレベルはまだまだです。品質確保の基本である Q/C/Dは設計・開発も大きな役割を担っていると思います。だからこそきちんとアウトプットを行い、結果をレビューし継続的に設計・開発のプロセスを改善することが大切だと思います。ご意見ありがとうございました。
一旦承認されたものについて、担当者が”軽微”と思う変更については新たな承認を得ていないが、ISO的に問題ないか？との趣旨と理解しました。 重要な変更については、新たな承認を得るものと思いますが、そうなると重要な変更と軽微な変更の敷居がどこにあるのかを明確にしなければなりませんが、現実的には難しいのではないでしょうか。それに承認行為というダブルチェックによって品質を確保しているはずなので、担当者だけでの変更はよろしくないはずです。 単にISOを通す為だけでしたら何とでも決める事が出来そうですが、そもそもISOというものが顧客に対する品質確保の裏づけとして存在している以上、真っ当な仕組みを作った方が良いと思います。
補足
hasshi様の言う通り「真っ当な仕組み」は自分なりに解釈すれば「会社のレベルに合ったメリハリのある仕組み」ということで会社の体質に合った効果的なシステム作りが必要だと思います。また、承認行為の話ですが、変更に関する新たな承認を得る部分ではアウトプット（出図）段階で全ておさえています。要求事項の意図として、あらかじめ決められた者の承認は必要だと思いますが、チェックとは意味合いが違う気がします。承認行為=ダブルチェックによって品質を確保しているとは言い切れない場合もあります。担当者自身がきちんと内容を確認し品質の良いアウトプットを出せるようなレベルにすることも大切なことだと思います。それが出来なければトリプルチェックも必要になってしまうとになる可能性があると思いますが如何でしょうか。
規模の小さな事業所では、設計・開発に携わる担当者も少なく、一人の場合もありえますが、ＩＳＯ取得がまったく出来ないとは限らないように思います。規模に合ったマニアルを構築し、整合性に問題がなければ いいのではないでしょうか。顧客満足が得られれば、ＩＳＯの趣旨に沿い、又、企業の信頼も出来るとおもいます。
お礼
当社は小さな会社で、日常業務も含め設計・開発担当者は３人です。今のマニュアル内容はもとても重く有効性が感じにくいのが現状です。ここに来て、設計・開発がどういうステップや内容、意図で行われ、最終的にどうなればいいのかが、それぞれの設計担当者にもやっと浸透してきました。判断に迷えば責任者も含め３人が隣り同士の席ですから、顔を横に向ければ話もできます。そういう環境では頑固な手順はいらないと思いましたので適合性を質問させて頂きました。ありがとうございます
図面の出図では、一般的に「製図者」「設計者」「承認」と検印があるかと思いますが、 文面から、設計者＝承認ということですよね。 ISO上はあくまでも規定であって、問題ないと思いますが、業務としては承認が無意味になりますよね。 承認とはあくまでも第三者が行うのが本来の姿と私は思います。
補足
アドバイスありがとうございます。 確かに第三者が行うのが本来の姿と思います。当社の場合、図面の出図承認では、あらかじめ決められたグループの責任者が承認を行い、グループの責任者が出図行為を行う場合は、その上の部長クラスに承認を得ています。「製図者」「設計者」は承認行為をしてません。
関連するQ&A
- ISO13485：2016 設計変更時の妥当性確認
お世話になります。 設計変更時に検証は実施しますが妥当性確認は実施しない軽微変更が多いです。その際、7.3.9では【適切な場合、バリデーションを行う。】とあり、適切ではない場合、つまりバリデーションをしなくても問題ない理由があればしなくてもよいとの理解です。 その理由をいちいち、変更書に記載するのも大変なので『設計・開発手順書』の変更管理のところに、 《使用目的又は効果、性能及び安全性に関する変更が生じる場合は妥当性確認を実施する。》と記載して、それ以外の軽微な変更については実施しないことを明示したいと考えています。この考えて監査は通りますでしょうか？
- 締切済み
- ISO
- 妥当性確認について
製作した機器・装置の「妥当性確認」を行いますが、装置が大きいことや、実環境でないと確認が出来ないことから 現場導入してから「妥当性確認」を行っています。 ISOでは「・・・意図された用途に応じた要求事項を満たし得ることを確実にするために・・・・・・。・・・及び必要な処置があればその記録を維持すること。」とかかれています。 現場で装置（機器）の妥当性確認実施したところ、“要求事項を満たしていない”事が解った場合、「妥当性確認」は完結しないのでしょうか。。？ このように考えられるが、、、どうでしょうか？ １．妥当性確認で“要求事項を満たしていなかった”場合、そこ事を記録として残す。 ＜・・・・・妥当性確認は行った＞ ２．不適合処置or設計変更等を行うプロセスに入る。 ３．不適合処置or設計変更等を行った結果の“妥当性確認”を行う。
- 締切済み
- ISO
- 上司の承認印（内部統制について）
情報システム関係の部署にいます。 開発は、ほぼアウトソースをしており、設計書やテストケースの 承認を弊社でしています。（レビュー結果など） システムもたくさんあるため、システムごとに弊社の担当者がいて その人が承認をしております。 この前、監査指摘で、担当者の上長（役職者）が承認していないと だめだと言われました。 しかし、実際のところ上長がなんでも知っているわけでもないですし、 担当者のほうが内容も理解できているのが現状では、上長の承認は 形だけになってしまいます。 上長の承認が必要な意味を教えてください。 （なにかあったら責任をとるのが上長だとしても承認印が必要なの？） また、担当者、課長、部長といた場合に、せいぜい課長承認だけでは だめなのでしょうか？ いちいち部長まで承認していたら、えらく面倒なことになります。 （押せばいいっていうのなら少しは楽ですが、無意味な感じですし。）
- 締切済み
- 財務・会計・経理
- ISO9001 妥当性確認の真意
ISO9001の中で妥当性確認という文言がでてきますが、ここで解釈に悩んでいます。 例えばある製品を開発しているとして、妥当性確認は下記の段階で行なうものと考えていますが、 ?設計の妥当性確認は．．．製造前に実施 ?製品の妥当性確認は．．．製造後、引渡前 と解釈できると思うのですが、具体的にどのような違いがあるのかよく判りません。 また設計の妥当性確認と設計検証はどうちがうのでしょうか。設計検証も妥当性確認の一部に思えて仕方ありません。どなたかご教授下さい。
- ベストアンサー
- ISO
- 要求事項を満たさない設計を変更する場合の費用負担者
建築士と設計業務委託契約を結び、基本設計、詳細設計、確認申請を行い、工務店と仮契約を行っています。現段階で、設計図では設計者へ依頼した要求事項を満たさないことが判明し、設計の変更を依頼しています。この場合に発生する次のような費用は、それぞれ誰が負担すべきものでしょうか。 1 意匠設計を変更する費用 2 設備設計を変更する費用 3 部材変更によって発生する差額 4 確認申請の計画変更によって発生する費用 例えば、要求事項は、防音性能の確保、駐車場の広さ、入れる物品の大きさ、に関する要求を行っています。これを満たせないことから、遮音にかかる施工・部材の変更、物品を搬入可能にする為のドア・コンクリート躯体への開口部変更が必要となっています。 契約は継続し、竣工まで作業いただきたいですが、費用負担者が誰となるのか教えていただけませんでしょうか。
- 締切済み
- 新築一戸建て
- 【PMBOK知識】承認済み○○○○の見解教えて下さい
PMP資格取得者、学習者、実務者の皆さん、教えて下さい。 私は今PMP資格取得学習をしているものです。 ステークホルダー・マネジメントプロセスのアウトプットで承認済み変更要求と承認済み是正処置がなぜ出てくるのか悩んでいます。 皆さんの見解をご教示下さい。 PMBOKガイドによれば、すべての変更は統合変更管理プロセスでレビュー、承認されることになっているはずです。 そのため多くのプロセスでは、 変更が必要な状況が発生→アウトプットとして要求済み変更（や提案済み是正処置など）→統合変更管理プロセスでレビュー承認→該当プロセスにて承認済み変更要求（や承認済み是正処置など）のインプット→処理→○○○○（更新版）としてアウトプット という流れになると認識しています。 なぜステークホルダー・マネジメントプロセスのアウトプットで承認済み変更要求と承認済み是正処置が出てくるのか？ 皆さんの見解をご教示下さい。
- ベストアンサー
- その他（職業・資格）
- 開発行為
都市計画法での開発行為の定義は4条１２項で『この法律において「開発行為」とは、主として建築物の建築又は特定工作物の建設の用に供する目的で行なう土地の区画形質の変更をいう。』となっています。 では建築行為を伴わない宅地造成は開発行為となるのでしょうか？ その土地は市街化調整区域ですが既存住宅団地内で登記簿上の地目は現在原野です。道路より２ｍの高さの擁壁を設置し盛土整地までの予定です。建築の予定は未定で5年や10年先まで建てるつもりもありません。またこの土地は30年前に住宅団地として開発された一部で土地も区割りもされ道路（市町村道として認定されています）にも接道しています。 人によって言葉や法の解釈が異なり迷っています。詳しい方宜しくお願い致します。 ちなみに開発の許認可権者（都道府県）は開発行為ではないと主張し、当該市町村担当課は既存住宅団地内を宅地造成（建築行為が無くても）するのであれば開発行為だと主張しています。
- ベストアンサー
- その他(住まい)
- 仕様管理ツール
開発時の仕様の管理の自動化について教えてください たとえば、要求仕様を変更すると、それがいろいろな仕様書や検証計画に影響していき、変更をプロジェクト全体に反映させるのにかなりの工数を消費しています。また、ある仕様がどこでレビューされどこで検証されるのかを、ドキュメントを繰って確認するのもかなり大変な作業となります。 このようなことを、Accessのデータベースを使って管理しようとする試みを見たことがありますが、なかなか大変だったようです。 また、ソフトウェアパッケージには変更管理ツールが同梱されているような気もしますが、一般的な機器開発のプロジェクトに使用できるものは、探しても見つかりませんでした。 市販のツールで、このような仕様の管理を自動化、もしくは支援してくれるものをご存知の方がおありでしたらご紹介いただけませんでしょうか。 何卒よろしくお願いします
- 締切済み
- 開発
お礼
「設計・開発」の要求事項で承認行為を求めているのは、アウトプット（次の段階に進める前に）と変更管理（その変更を実施する前に）ですよね。要はアウトプットで承認行為を要求してるのだから、変更に関してもアウトプット時は承認行為をしてくださいねと言う解釈なのですね。「本当にそれで良いのか」に関しては、各々の設計者の判断レベルもありますので難しい所ではあります。ありがとうございました。