本日から、品質部門配属になりました 第7回 『品質保証体系』(その3) (2020-06-29)
2020.06.29
全5回に分けてお届けする「第2話 品質保証体系」についての3回目、品質保証体系構築についての後編です.
③品質保証体系図の作成
先週の「①製品・サービス品質の確実な保証のために必要な経営機能(業務)の列挙」で品質保証に必要な経営機能を挙げ,②でその経営機能の運営に必要な組織体制を明確にしましたが,これを組織全体で共有するために品質保証体系図を作成することが多いです.品質保証体系図は,縦軸に経営機能を上から下に向かって流れるように位置付け,横軸に経営機能を担当,関与する部門を取り,各経営機能を果たすためにどの部門がどのような活動をどのような順序で行う必要があるかを四角と矢印で結び付けたフロー図として表したものです.品質保証の英語はQuality Assuranceなので,QA体系図ともいわれます.
このQA体系図で記述すべきことは,下記の4つです.
a)各経営機能を果たすために必要な活動(作業,評価・判断,記録・証明)
b)活動を行うための方法,手順,参考にすべき標準・規格・規準類
c)各活動の相互関係,順序
d)品質保証上,更に記述すべき項目
a)とは上記①で列挙した各経営機能に必要な活動であり,それにはインプットをアウトプットに変換する「作業」や,何らかの「評価・判断」,さらには規定通りの試験を実施し(実施した証明とともに),要求通りの方法で作成された証明書(試験成績証明書など)の添付・提出が,顧客に対する品質保証上,重要な役割を果たす場合もあるので,「記録・証明」を入れました.いずれも□で表現しますが,場合によっては評価・判断を区別するために◇で表現することもあります.b)とは,a)の活動を実施するための方法,手順,参照すべき文書類であり,通常は品質保証体系図の一番右側に「関連規定・規準類」という欄を追加して,「材料受入規格」,「設計・開発管理規定」,「調達管理規定」,「初期流動管理規定」,「QC工程表」など,品質保証体系の各経営機能に関係する規定や規準等の文書名を記入します.これによって,ある経営機能を果たすために参照すべき,具体的な業務のやり方や方法,ルールが明確になります.
a)とb)が明らかになれば,あとはこれらの活動どうしの関係を,矢印を用いてフロー図で表現します.Input-Process-Output(IPO)モデルに基づき,各活動のインプット,アウトプットの関係に着目してフロー図を記述するのがc)となります.a)b)c)により,見た目的にはQA体系図が一応完成しますが,製品・サービスの品質保証をより確実に行うために,このフロー図内にさらに追加で記述・充実しておきたい項目がd)です.これには,
d-1)品質保証のGate機能
d-2)フィードフォワード機能
d-3)フィードバック機能
の3つがあります.
d-1)のGate機能とは,最終的に顧客に品質保証しなければならない製品・サービスの品質特性から逆算して,QA体系図内で表現された一連のフローの中で,どの段階でどのような品質を保証しなければならないか,そのために,何を対象にどのような判断基準で評価・レビューするかを明確に記述することです.通常は,各経営機能の区切りを一つの段階としてGate機能を設けることが多く,商品企画段階でのレビュー,設計段階でのレビュー,製造開始直前の量試段階でのレビューなどが行われ,あらかじめ定めた各段階のレビュー対象,項目,判断基準,参加者の構成などが決められています.これはフロー図上では,とりわけ重要な評価・判断の活動(=Gate機能)として表現され,そのレビュー方法の詳細の参照先は,フロー図の一番右側にある文書欄に関連文書が記載されます.
d-2)のフィードフォワード機能とは,下流の経営機能を担当する部門Bが,上流の経営機能を担当する部門Aの検討会議に参加し,部門Aからの活動成果の正式な引き渡しがなされる前に,そのリスクやや影響を予測し,必要があれば部門Aに提言・修正依頼を行うことを意味します.つまり,設計・開発におけるフロントローリングの概念と同様な考え方です.例えば,設計という活動は当然ながら設計部が行いますが,その評価・判断の場である設計検討会議には設計部だけでなく,その成果を受け取る購買部,製造部,生技部を参加させます.これはフロー図上では,評価・判断に関わる活動を,横軸の部門のどこまでを関与させるかで表現することになります.
最後のd-3)のフィードバック機能とは,下流の経営機能や活動で発生した問題の原因が,上流の経営機能や活動のどこかにある場合に,その行き先を明示することです.例えば,製造段階で発生した不良率が高いという問題の主要な原因の一つが工程条件にあるのであれば,製造工程設計にフィードバックしなければなりませんし,工程条件の変更だけでは限界があり,そもそも作りにくい設計構造であることが根本原因であれば,設計まで立ち戻って考えなければなりません.このようなフィードバック・ループの矢印をあらかじめ決めておくことで,問題が発生した時に迅速に対応でき,早期に問題解決できるようになります.
さらに加えて,当該製品・サービス内でのフィードバックだけでなく,同様なQA体系図を使う予定の「次の新たな製品・サービス開発」へのフィードバックも表現したいです.例えば,設計の重要なインプットの一つに「過去トラ」というものがあり,また重要な過去トラの原因分析によって獲得した設計知識を反映させた「設計基準」がQA体系図の一番右側の関連文書欄に記載されるはずです.つまり,当該製品で起きた様々な問題をその当該製品内に留めず,次の新製品開発で参照する過去トラや設計基準・知識などにフォードバックするループも表現すべきでしょう.ただし,当該製品内と次の新製品開発のどちらにフィードバックするかを区別できるようにするため,実線と点線の矢印を使用する,時計回りと反時計回りのループを使い分けるなど,表現上の工夫を行ってください.
このように作成したQA体系図の横軸にある特定の部門に着目して縦方向(上から下へ)に見ていくことによって,経営機能の各段階でその特定の部署が担うべき業務分掌がわかります.また,その特定の部門に入ってくるまたは出ていく矢印に着目することで,他のどの部門とどのような連携,協業をすればよいかがわかります.もし部門として実施している業務があるのに表現されていないのでしたら,それを追加してください.今度は,縦軸のある特定の経営機能に着目して横軸(左から右へ)に見ていくと,各部門がその経営機能で果たすべき業務の全貌が分かります.ある経営機能を果たすのに必要な業務に不足があるということでしたら,これも新たに追加する必要があるでしょう.
来週に続けます.
(金子雅明)