【IATF16949徹底解説】7.5.3.2.2 技術仕様書｜要求事項の解説と解釈

第7章　支援

7.5.3.2.2 技術仕様書

について解説します。

ISO9001・IATF16949　第7章　支援
7.5.3.2.2 技術仕様書

ISO9001・IATF16949　第7章　支援

ISO9001 及び IATF16949 の第7章は、以下の通りです。ここからが正念場になるので、是非一緒に頑張りましょう！
（下表の ”要求事項” の部分をクリックすると、解説ページにいけます。）

ISO9001:2015	7	支援
ISO9001:2015	7.1	資源
ISO9001:2015	7.1.1	一般
ISO9001:2015	7.1.2	人々
ISO9001:2015	7.1.3	インフラストラクチャ
IATF16949:2016	7.1.3.1	工場、設備及び設備の計画
ISO9001:2015	7.1.4	プロセスの適用に関する環境
IATF16949:2016	7.1.4.1	プロセスの運用に関する環境 – 補足
ISO9001:2015	7.1.5	監視及び測定のための資源
IATF16949:2016	7.1.5.1	一般
IATF16949:2016	7.1.5.1.1	測定システム解析
ISO9001:2015	7.1.5.2	測定のトレーサビリティ
IATF16949:2016	7.1.5.2	測定のトレーサビリティ(注記)
IATF16949:2016	7.1.5.2.1	校正／検証の記録
IATF16949:2016	7.1.5.3	試験所要求事項
IATF16949:2016	7.1.5.3.1	内部試験所
IATF16949:2016	7.1.5.3.2	外部試験所
ISO9001:2015	7.1.6	組織の知識
ISO9001:2015	7.2	力量
IATF16949:2016	7.2.1	力量 – 補足
IATF16949:2016	7.2.2	力量 – 業務を通じた教育訓練 (OJT)
IATF16949:2016	7.2.3	内部監査員の力量
IATF16949:2016	7.2.4	第二者監査員の力量
ISO9001:2015	7.3	認識
IATF16949:2016	7.3.1	認識 – 補足
IATF16949:2016	7.3.2	従業員の動機付け及びエンパワーメント
ISO9001:2015	7.4	コミュニケーション
ISO9001:2015	7.5	文書化した情報
ISO9001:2015	7.5.1	一般
IATF16949:2016	7.5.1.1	品質マネジメントシステムの文書類
ISO9001:2015	7.5.2	作成及び更新
ISO9001:2015	7.5.3	文書化した情報の整理
IATF16949:2016	7.5.3.1 及び 7.5.3.2	7.5.3.1 及び 7.5.3.2
IATF16949:2016	7.5.3.2.1	記録の保管
IATF16949:2016	7.5.3.2.2	技術仕様書

第7章の支援では組織の品質マネジメントシステムが効率的にPDCAサイクルを回すために欠かせない支援プロセスに関しての要求事項が書かれています。

7.5.3.2.2 技術仕様書

当該項目の、IATF16949要求事項のポイントを自分なりにまとめてみました。

組織は、顧客の全ての技術規格／仕様書の改定に対して、顧客より要求されるスケジュールに従って、改定における社内対応のエビデンス（社内レビュー、配布、実施等）を残すための、文書化したプロセスをもたなくてはならない。

技術規格／仕様書の変更によって、製品設計変更に該当する場合は、ISO9001の『8.3.6 設計・開発の変更』の内容を参照する。

技術規格／仕様書の変更によって、製品実現プロセスの変更に該当する場合は、IATF16949の『8.5.6.1 生産治工具並びに製造、試験、検査の治工具及び設備の運用管理』を参照する。

組織は、生産において実施された各変更の日付の記録を保持しなくてはならない。実施には、更新された文書を含める。改定された技術規格／仕様書の社内レビューは、改定版を受領してから10稼働日以内に完了することが望ましい。

注記
技術規格／仕様書の変更は、仕様書が設計記録に引用されている、又はコントロールプラン、リスク分析（FMEAのような）等、生産部品承認プロセス（PPAP）文書に影響する場合は、顧客の生産部品承認の更新された記録が要求される場合がある。

はじめに

製品の性能を担保するためには、技術的な仕様書の確認を迅速に行い、内容を製品に反映することが必要となります。

技術規格や仕様書が変更になった場合、図面やFMEAなどの、PPAP提出書類を改定する必要がある場合は、新たに顧客のPPAP承認を取る必要がでてきます。

【誰でも分かる解説！】品質を高める秘訣、FMEAとは？

リスク分析の手法でFMEAというツールがありますが、誰にでも分かるように解説します。生産技術者や製造、品質保証をしている方にオススメの記事です。新入社員の教育にも使える内容になっているので、是非読んでください。

【簡単わかりやすく解説！】自動車産業 IATF16949のコアツール "PPAP" とは？

自動車業界でPPAPという言葉はよく聞くかと思います。今回はそのPPAPについて誰にでも分かるように解説いたします。IATF16949を学び始めの方や、自動車部品メーカーにお勤めの方、必見です。

解説（仕様書に関する文書化したプロセス）

顧客から受領した技術文書（仕様書、規格、図面等々）に関して、顧客からの誰が受け取るのか窓口部門や、組織内部での配付や変更の実施および記録などに関する、業務フローや手順を定めておく必要があります。

このプロセスについて、文書化しておくことが、IATF16949では追加で要求をされています。

私の経験では、顧客都合の仕様変更等は営業部門が窓口として対応しておりました。営業部門が設計統括部門（プロジェクトマネジメント部門）へ、仕様書を引き渡し、仕様書の内容を確認のうえ、妥当な設計開発部門へその内容を落とし込み、開発が行われます。

あまりないケースかと思いますが、顧客都合ではなくサプライヤ側の不具合都合で改定されることも考えられます。

例えば、不具合の対策によって、顧客の仕様書に影響を及ぼしていたりする場合です。

その場合は、不具合対応を行っている部門（品質保証部門や営業部門）が窓口となることも考えられるので、業務フローを検討する場合は、仕様変更のトリガーはどのようなケースが考えられ、どの顧客の部門から当社へ連絡がくるのかを場合分けして、複数のフローを考慮したプロセスを構築することが望ましいでしょう。

解説（設計変更に該当する場合）

技術規格／仕様書の変更によって、製品設計変更に該当する場合は、ISO9001の『8.3.6 設計・開発の変更』の内容を参照する。

ISO9001の解説記事に詳細を記載するので、こちらでは割愛いたします。

仕様書の変更により、製品の設計変更に該当する場合は、ISO9001『8.3.6 設計・開発の変更』の内容に従う旨が、書かれております。

解説（製品実現プロセスの変更に該当する場合）

詳細は【8.5.6.1 生産治工具並びに製造、試験、検査の治工具及び設備の運用管理】に記載するので、詳細は割愛いたします。

製品実現プロセスとは、製品が出来上がるまでのプロセス（過程）を意味しています。

この過程というのは、実際に工場で作られる過程(QC工程図等)ではなく、もっと広範囲の過程を示しています。

例えば、製品が出来上がるまでには、営業部門が商談・受注し、お客様の要求を社内へ展開。要求に見合った製品を設計開発をした上で、正しく製造しなくてはなりません。

このように実際に製品が出来上がるまでの全体の流れをプロセスと呼びます。

IATF16949では、このプロセスにおける有効性を確保するための要求事項が規定されています。

【IATF16949徹底解説】5.1.1.2 プロセスの有効性及び効率｜5.1.1.3 プロセスオーナー要求事項の解説と解釈

ISO9001 & IATF16949 第５章『リーダーシップ』の要求事項として、『5.1.1.2 プロセスの有効性及び効率』『5.1.1.3 プロセスオーナー』という内容がありますが、事例を交え解説してみました。参考にして頂けると幸いです、

解説（変更の確認とその記録）

「変更の日付の記録」は、変更管理の手順や生産に関する記録の中に残しておくことが良いです。製品や工程を変更した日付や、その実施者、承認者など、変更管理におけるエビデンスとして、必要な記録を残しておきましょう。これは、トレーサビリティ観点でも必要な対応となります。

また、「10稼働日以内に完了」は、製品要求事項に適合したものが、顧客への納期を厳守するために、業務をタイムリーに進めるための要求事項となります。

内容のレビューに時間がかかると、開発や変更が後ろ倒しとなり、顧客希望の納期を厳守することが難しくなってしまいます。そのため、仕様書等の技術文書は、顧客が要求してくる日数、又は10稼働日以内での完了が望ましいです。

もし、対応が難しい場合は、事前に顧客へ時間がかかる旨を伝えておく必要があります。これは、顧客の仕様変更を対応する部門と、オーダーを行う部門が異なるためです。更に、両者は他拠点に所属しているケースが多く、顧客内部でもコミュニケーションが取り切れないことも考えられます。想定外の日程でのオーダーがかかり、仕様書の確認（開発や変更の対応）が満足に行われないまま、製品開発が進まないようにするためにも、顧客とのコミュニケーションは頻繁に行いましょう。