前回「クレーム処理の仕組み」の中に、「重要品質問題」に関する記述がありましたが、今回はこの重要品質問題をテーマに取り上げます。

重要な品質問題は、一般の品質問題とは区分して、組織に特別なフォロー体制をもつ管理体制を敷いて対応することが必要です。

重要品質問題は、全社規模の登録をし、必要な場合にはタスクチームを編成し、全社的なプロジェクト活動として位置づけ推進をします。適切な処置と進捗状況の把握に努め、最終的に問題解決宣言を行います。

組織に大きなダメージを与えることのないように迅速に解決し、再発の防止を図ることが肝心です。

 

 

１．重要品質問題とは

 

「重要品質問題」とは、「開発、生産工程や市場において発生する各種品質問題のうち、発生率、内容の重大性、市場に及ぼす影響など、ユーザおよびメーカの双方の立場から、被害の大きさが一定の基準を超えるもの」をいいます。

“一定の基準を超えるもの”、すなわち重要であるか、そうでないかを決める基準は組織が自ら決めておくことがよいと思います。次のような状況と場面において、全社的な観点から重要である場合を想定しておくとよいでしょう。

 

①設計・開発段階での品質トラブル

②新製品の初期流動段階での品質問題

③部品、材料供給元での品質トラブル

④製造部門における品質トラブル

⑤消費者の使用・安全に影響を与えるクレーム

⑥その他社会的インパクトの大きいクレーム

⑦問題解決に部門間の連携、全社的対応が必要な品質問題

 

このような重要品質問題は、組織内で正式に認められた（オーソライズされた）案件として登録され、関係部門が総力を挙げてその対応に取り組まなければなりません。

品質問題に対応する主管部門は、問題の解析、対策の立案、解決策の実施、再発の防止などを行います。

以上のような活動の進捗状況チェック、対策の有効性確認、および対策完了判定、登録解除などの管理も行う必要があります。

 

 

２．全社規模の登録

 

各種品質問題の中で、重要であると認識された問題は全社規模の登録をします。

この登録は、関係部門に問題の重要度をアピールし積極的に関与してもらうために行います。

そうすることで関連部門の業務における優先度を上げる、組織の経済的インパクトを最小限にするなどの効果が得られます。

登録簿に付属する記録綴りには、例えば以下のような項目を記載しておき、プロジェクトの進捗を管理するとよいでしょう。

 

(1) 応急処置

－現品調査または実地調査

－正常状態への復帰

 

(2) 解析

－現象の把握

－現品調査または実地調査

－欠陥原因の究明

 

(3) 是正処置

－原因除去（方法、範囲）の立案

－原因除去及び効果の確認

－類似製品に対する処置

－設計・製造・評価プロセスに対する処置

 

(4) 報告書の作成

－発生から処理完了までの経過（上記(1)~(3)項目）

－再発可能性への言及

－処理時間

－処理費用

 

 

３．タスクチーム編成

 

組織は重要品質問題の原因究明及びその除去を担当する部門を決めますが、場合によってはそれぞれの部門から選出されたメンバーによる解決タスクチームを編成します。

担当する者は重要品質問題の原因に関する固有技術を有している必要があります。

解決タスクチームは、重要品質問題の原因究明を目的として、現品を調査し、また必要なら現地の調査を行ないます。例えば、現品の分解、破損の状態、正常品質との比較、分析・測定などを行ない、重要品質問題の状況観察を詳細に行います。

使用環境などに問題がありそうな時は、現地に出向き詳しく状況を調査します。

重要品質問題が必ずしも再現しないことも多々あります。

解決タスクチームのメンバーは、すべてのことには因果関係があり必ず原因は存在するという強い信念を持って事に当たることが必要です。

問題解決に当たっては、1960~1980年代のTQC（Total　Quality Control：日本式品質管理）において、三現主義といわれた「現物を現場で現実的に観察する」ことが極めて重要です。

事実が何であるかを把握せずに憶測に基づいた行動をとると、思わぬ誤りを犯すことになります。

何が真実なのか、他人の根拠のない主張や噂に惑わされずに、しっかりと事実を把握することが大切です。

 

 

４．プロジェクトマネジメント

 

解決タスクチームを編成した場合は、プロジェクトマネジメントの定石に従って重要品質問題の処理を管理（マネジメント）します。

スタートに当たって、次の各項目を含むプロジェクト計画を作成します。

問題の性質によりますが、比較的単純に解明できる問題と、反対に表面的には簡単に見えても根の深い問題とでは立てる計画は変わってきます。

解決が難航して長引きそうなときには、計画をレビューして立て直す場合もあります。

 

①目的

重要品質問題の処理の目的は複数あります。例えば、原因の解明、欠陥製品の処理、現品の修正、機械設備の点検・修理、設計手順の再検討、市場からの回収、消費者への対応など、重要品質問題の性質によりカバーする範囲も、問題解決に必要とされる専門性も多岐にわたります。それらの中でも最も重要なものを決定します。

通常、最も重要な目的は、問題事象を引き起こした因果メカニズムの全貌解明になると思います。多くの場合、重要品質問題を引き起こした原因が本当に何かを究明することをプロジェクト目的とするとよいでしょう。

 

②概要

プロジェクトの意義，理由及び背景をはっきりさせます。

プロジェクト活動の内容を書きます。例えば、原因の解明にはどんな固有技術が必要となるのか、どんなツール（統計解析、実験計画法、故障解析など）を使用するのかなどです。

場合によっては、シミュレーション、試験、再現実験などの利用も検討するとよいでしょう。再現実験とは、欠陥を意図的に発生させ、どんな条件なら欠陥が発生するのかを確認するために行うものです。

さらに問題のタイプによって以下のような観点も検討して概要に記すとよいでしょう。

 

・物理化学現象なら、再現実験で確認をする。

・ソフトウェアなら、事象発生条件を解明する。

・サービスなら、サービス提供システムの不備・脆弱性の解明をする。

・顧客タイプによって現象に相違があるなら、その解明をする。

 

③制約

プロジェクトを推進する上で、組織内でできることと、組織外（関連する他グループを含む）に依頼することを次の観点から明確にします。

・人の専門性

・試験・分析設備

・費用（予算）　など

また、上記項目の記述において、組織内外を決める条件（境界条件）もはっきりさせておくとよいでしょう。

 

④アウトプット

プロジェクトの最終解決イメージを描きます。できれば、アウトプットの諸要素を含んだ書式をはっきりさせるとよいと思います。ここに描かれた諸要素をアウトプットとして得ること、即ちプロジェクトの目的達成を構成する要素を明確にします。さらにプロジェクト報告書の目次などのあらましも決めておくとよいでしょう。

 

⑤インプット

アウトプット、即ちプロジェクトの目的達成を構成する要素を得るためには、どのようなインプットがなければならないのかを決定します。問題解決の根本的究明のためには、どんな技術、ツール、情報などが欲しいのか、例えば入手済みの技術、ツール、情報などでカバーできるのか、または新たな入手を必要とするのかなどを含めてインプットを決めます。

 

⑥WBS（Work Breakdown Structure）

アウトプットを得るまでにどんな活動、実施事項があり得るのかをツリー構造で明確にします。この場合、上位の活動の目的・目標は、下位の活動をすべて行えば達成できる論理的一貫性がなければなりません。

 

⑦マイルストン

プロジェクトのマイルストンには、解決目標、品質会議等での報告・審議などを入れておくとよいでしょう。プロジェクトの日程計画、工程計画も明確にしておきます。

 

⑧必要リソース

プロジェクトに必要となる人，モノ，カネ，時間、メンバー構成などを明確にします。

 

⑨リスク

プロジェクト計画を立てるときに、心配になることを上げます。いつ、どこで、どのように起きるかは特定できないが、今までの経験から、計画通りにいかないのではないかと漠然と心配になることをリストアップするとよいでしょう。

もしリストアップしたことが起きたならどのようにするのか、その対応構想も検討しておきます。

プロジェクトの実施段階においては、プロジェクト推進途上での問題・課題への適切な対処するため、時にはリソースを追加投入したり、計画を変更したりします。

マイルストンの見直し、場合によっては、日程計画を変更することもあります。それは次のような状況下において実施することが多いと思います。

・問題の原因解析及び原因除去が当初思ったより難解な場合

・プロセス（設計、製造、評価）に対する処置が想定したより複雑な場合

・問題の対象となる製品の量が大幅に増加した場合　など

 

（平林良人）