FMEAは運用しているけど……品質管理セーフティネットはどう考えるべき？：PLM導入プロジェクト、検討前に読むコラム（2） （1/2 ページ）
製品ライフサイクル全体を管理するためにはPLMを基軸としたシステム作りが急務。PLM導入・改善プロジェクトを担当する際に事前に知っておくべき話題を、毎回さまざまな切り口から紹介していきます。
品質工学の理論を駆使してもトラブルが発生する理由
製品品質の重要性や品質問題が与える経営に対するインパクトの大きさについては、いまさら語る必要はないと思いますが、日々高機能化する製品の品質を高いレベルで維持することは大変な労力を要します。
製品開発現場では製品の品質向上だけでなく、決められた開発期間と目標コストの達成についても求められており、これら相反する条件を高い次元で実現することが求められています。
設計品質を向上させるための方法としてFMEAやFTA、タグチメソッドやDR（Design Review）、ヒストグラム、管理図、チェックシートなど品質工学や品質管理の世界ではさまざまなツールや手法が開発されてきました。
これらの品質管理ツールはどれも論理的に正しく、多くの企業でも採用され実際に効果を出しています。
日本製の製品は世界で一番品質が良いといわれていますが、それでも「どうしてこんな故障が起こるの？」といった、当たり前に解決されているハズの基本的なトラブルが発生することがあります。
品質にこだわったモノづくりを行っている会社でも見落としがちな、ある視点
日本の製造業では誰もが品質の重要性を認識し、不具合を発生させない仕組みを取り入れているにもかかわらず、なぜこのようなことが起こるのでしょうか？
今回は品質にこだわったモノづくりを行っている会社でも見落としがちな、ある視点について紹介したいと思います。
今日使われている品質管理のツールや手法は、正しく運用すればどれも製品の品質向上に貢献できます。
しかし、共通した欠点も持っています。それはどのツールや手法も正しく運用するには手間が掛かるという点です。
品質を維持向上させ品質管理ツールが効果の上がる仕組みとして運用していくためには、不具合を未然に予防する手法とともに、作業の手間を軽減する仕掛けも併せて準備しないと現場では定着しません。
想定外の問題を気付かせ、対応させる活動
品質管理活動はちょうど自動車の安全運転に似ています。
事故を起こしたいと考えるドライバーはいないわけで、誰もが「絶対に事故を起こさないぞ」と考えながら安全運転を心掛けています。
しかし、特定の条件が重なると事故は起こります。不注意もあると思いますし、予想しないとっさの判断で手順を間違えたり、時には自分に非がなくても事故に遭うことがあります。
多くの自動車事故の発生は、運転の基本手順を間違ったときではなく、運転者が予測していない事象が発生したときに起こります。
品質問題もこれと同様で、ツールや手法（運転で例えるとハンドル操作や目視確認）を正しく使うだけでなく、突発的な事故や受注（運転の場合では突然の飛び出しや急ブレーキ操作）のときにも作業を一連の流れを調和をもって運用できる仕掛けが必要です。
人が行うことですから必ずミスが発生します。ミスや不具合は個々の作業者や手法に非がなくても、製品で表面化してしまうと意味がありません。
個々の品質管理（工学）活動をつなげ、かつ予測できなかった事象や変化が発生したときに気付かせ、対応させる品質管理活動のセーフティネット構築が今日のモノづくり環境に欠けているポイントだといえます。
今回は、FMEAによる故障モードの解析を例に品質管理セーフティネット構築のポイントを紹介していきたいと思います。
未知の事象を検証する
FMEA（故障モード影響解析）とは製品やプロセスに対し、当該製品やプロセスで発生する可能性のある問題（潜在的故障モード）を洗い出し、その原因と影響を想定してリスクを把握して対策につなげる手法です。
しかし、将来発生するであろう事象を漏れなく検討するのは簡単なことではありません。
設計工程における品質の作り込みを実現するためにFMEAを効果的に運用するには、故障モードをきちんと抜け漏れなく洗い出せるかが鍵となるため、FMEAを運用している企業では故障モードを抽出するためにさまざまな工夫を行っています。多くの企業では故障モードを抽出する作業までは時間をかけて実施していますが、その後のRPN（リスク優先度：Risk Priority Number）を改善する作業の実施や改善結果の反映までを一連の作業ルーチンとしてうまく運用できていない例をよく見掛けます。
集合知の活用も有効だが……
故障モードを効率的に抽出するためにDR（Design Review）を開いてさまざまな意見を取り込んだり、有識者や過去の経験値をデータベース化してそこから見つけるようにしたり、あるいは、故障が発生する事象を体系化して分析するなどの方法を用いるなど、故障モードに対する検討内容を網羅的に行えるような工夫を行っています。
また、設計者の個の知識だけに頼ることなく、組織としての集合知を活用して設計のミスや不具合を未然に防ぐ活動なども、多くの企業で取られている施策ですが、この例はFMEAシート作成の作業品質を向上させたにすぎません。
ゴールはどこに
品質を良くする活動のゴールは、最終製品で不具合を発生させないことにあり、品質管理手法1つずつの精度を向上させるだけでなく、設計作業の積み重ねを通して製品に不具合を発生させないようにしなければなりません。
この例でいえば、FMEAを作成するだけでなく、その前工程作業の機能ブロックの検討内容と連動していないと、設計作業を通して見た場合、不具合につながるノイズを蓄積してしまう可能性があります。
例えば、設計作業は作業の後工程で不具合が見つかったり、レビュー時に指摘が入ったりすると、前工程に立ち戻って再度設計をやり直すことになります。
設計フローをキチンと管理していれば機能ブロック図を変更し、その変更内容をFMEAに反映するといった流れを繰り返すのですが、通常は時間に追われて設計しているということもあり、なかなかすべてのドキュメント類を整合性をもって改訂して管理することは大変です。
機能ブロック図に加えた変更内容がFMEA作業者に正しく伝わっていなかったり、FMEA作成者が違うバージョンの機能ブロック図を基に設計しないように管理していく必要があります。
このような事象を防ぐために、設計作業の前工程と後工程をつなげるための仕組みとしてプロセスアプローチが取られています。
プロセスアプローチを簡単に説明すると、作業に対するインプットとアウトプットを定義して、後工程に対して正しい情報を提供するとともに、アウトプットとなる成果物の手法と責任者を明確にして、個々の作業品質を向上させる考え方です。このようなアプローチを取るには必ずこのフローをマネジメントする人の存在が必要となり、プロセスアプローチを実現するための設計フローを管理する工数も無視できません。
Copyright © ITmedia, Inc. All Rights Reserved.