FMEAスライドをPowerPointで作る方法(RPN色分けが崩れない組み方)

ある中堅樹脂成形メーカーの品質技術者が、工程チームと木曜の午後いっぱいをかけて射出成形ラインのFMEAを行った。故障モードを8件洗い出し、それぞれ重要度・発生頻度・検出度を1~10点でスコアリングし、一番怖そうに見えた行——荷重下でのウェルドライン割れ——だけを赤く塗って、月曜のステアリングコミッティ向けのPowerPointスライドに貼り付けた。ところが「一番怖そうに見える行」と「実際にリスクが一番高い行」は別の行だった。工場長が「このRPNが2倍近いのに白いままの行は何なのか」と尋ねるまで、誰も気づかなかった。PowerPointで作るFMEAスライドとは、故障モードごとに重要度(S)・発生頻度(O)・検出度(D)のスコアとRPN(リスク優先度数)を計算し、しきい値に応じて色分けし、RPN順に並べた表のことだ。市販テンプレートの多くが触れない部分はここにある——この表は、一度作ったら自動的に何も再計算されない。目分量で行を色付けすれば、PowerPointはその色を、後で数字がどう変わろうと塗った場所にそのまま固定し続ける。

FMEAスライドが本来持つべき情報

故障モード影響解析(FMEA)は、コンサル資料のために生まれた形式ではない。起源は1949年、米軍の調達規格MIL-P-1629にさかのぼる。装置が壊れる前に壊れそうな箇所を洗い出す手法として作られ、1963年にはNASAがアポロ計画で採用し、1970年代にはフォードやGMが自動車の品質システムに組み込んだ——サプライヤー起因の不具合が検査だけでは追いきれない規模になっていたためだ。1990年代にAIAG(自動車業界行動グループ)が自動車品質標準にFMEAを組み込んだ頃には、今も使われているフォーマットがほぼ固まっていた。故障モード、影響、原因、現在の管理策、そして1~10点の3つの評価——重要度(S、影響が顧客に届いたときの深刻さ)、発生頻度(O、原因が起きる確率)、検出度(D、出荷前に現在の管理策が検知できる確率。こちらは逆向きで、1が「ほぼ確実に検知できる」、10が「検知する手段がない」)。この3つを掛け合わせたものがRPN(リスク優先度数)で、1から1,000の範囲に収まる。

ここまではPowerPoint固有の話ではない。PowerPoint固有なのは、このRPNの数字群がFMEAのワークブックを離れて1枚のスライドにまとめられたときに何が起きるかだ——どの行にフラグを立てるか、どの順番で並べるか、そして次に誰かが表を触ったときにその2つの判断がどうなるか、という部分である。

事例:2行を追加するまでは正しく見えた表

樹脂成形ラインの話に戻る。工程チームの最初のパスはブラケット成形工程の故障モード8件をカバーしていた。下の表は、技術者がスライドに貼り付けた内容にほぼ近い——工程を歩いた順に並んだ未ソートの表で、「重要度8点は一番やばそうだ」という直感だけでウェルドライン割れの行だけが赤く塗られている。翌週、別の顧客クレームから見つかった2件の故障モードが下に追加されたが、こちらは何ともチェックされていない。

RPNは重要度×発生頻度×検出度なので、ウェルドライン割れは8×3×6で144になる——注意に値する数字ではあるが、表の中で一番大きい数字ではない。型摩耗による寸法ドリフトは重要度こそ6と低いが、発生頻度(5。前回の生産ですでに型の摩耗が出ていたため)と検出度(7。ドリフトは緩やかで、工程内のゲージチェックでは断続的にしか捕捉できないため)がどちらも高く、掛け合わせると210——表全体で実際に一番高いRPNだが、誰も掛け算をしないままハイライトペンに手を伸ばしたせいで、白いままの行に収まっている。

よくある失敗: シート上で一番大きい数字が重要度だからという理由だけで行を色付けすること。重要度は「これが起きたらどれくらいまずいか」にしか答えておらず、「この表の他の項目と比べてどれだけ心配すべきか」には答えていない。後者の問いに答えるのがRPN、あるいはちゃんとしたAction Priorityであり、ハイライトペンを持つ前に実際に掛け算をして初めて機能する。

翌週、表はさらに悪化した。ステアリングコミッティが、別の顧客クレームから見つかった2件の故障モード——ニットライン剥離(RPN140)と低温保管でのスプルー脆化(RPN24)——も評価するよう求め、チームは次回レビューの前に両方を表の下に新しい行として追加した。これ自体はFMEA表を拡張する妥当なやり方だ。起きなかったのは、既存の8行を新しい2行と照らし合わせて見直すことだった。誰もウェルドライン割れのフラグを外さなかった——もう誰もそこを見ていなかったからだ。注目はすべて追加された2行に向いていた。2回目のステアリングコミッティの時点で、スライドは10行になっていた。重要度だけで誤って色付けされた行が1つ、本当に一番RPNが高い行はまだ白いまま、そして新しく追加されたニットライン剥離の行(RPN140)は、上にある未フラグの4行よりも「フラグを立てるべき」側に近い位置にいたが、誰もそれを見直さなかった。

何が本当に壊れているのか

問題は技術者が一度だけ判断を誤ったことではない。PowerPointが、判断の代わりにルールを置く場所をそもそも用意していないことだ。PowerPointの表のセルの塗りつぶし色は静的なプロパティで、誰かが塗りつぶしの色をクリックした瞬間に設定され、クリックされた場所にそのまま残り続ける——セルに入力された内容の関数ではなく、数字が変わっても、行が追加されても、表が並べ替えられても再評価されない。Excelの条件付き書式はその逆だ。「このセルが150以上なら赤く塗る」というルールは、元になる値が変わるたびに自分で再チェックする——これこそ、生きているFMEAの置き場所がスプレッドシートであるべきで、PowerPointの表ではない理由だ。条件付き書式を設定したExcelの範囲を、画像ではなくネイティブな表としてPowerPointに貼り付けても、色はその瞬間の状態のまま貼り付けられ、その後は手動で塗りつぶしたのと同じように固定される。

この一つの事実が、樹脂成形の例で起きた2つの失敗の両方を説明する。1つ目のフラグが間違っていたのは、人間が、スライドが色分けしていると主張している数字を計算せず、目分量で行を選んだからだ。2つ目の失敗——古いフラグが2行の追加と1回のレビューサイクルを生き延びたこと——が起きたのは、スライド上の何も古い行を見直すよう促さないからだ。編集後に注目されるのはたった今変わった行だけであり、ライブな書式を持たない表には、本来色が変わるべきだったのに変わらなかった行を浮かび上がらせる手段がない。

よくある失敗: 色分けを、スライドを出す直前に一度だけ済ませる仕上げ作業だと考えること。実際には、表の何かが変わるたびに——誰も触っていない行も含めて——表全体を通してやり直す必要があるチェックである。

色が本当に数字を意味する表の作り方

樹脂成形の例を直すと、手順は拍子抜けするほど地味になる。それでいい。まず全10行——追加された2行だけでなく全部——のRPNを計算してから、塗りつぶしのメニューを開く。しきい値は、どの行にフラグが立つかを見る前に、一度だけ文書化して決める。このチームは「High:RPN150以上」「Medium:60~149」「Low:60未満」に落ち着いた。これは普遍的な数字だからではなく、その工場の既存是正措置プロセスに合わせて選んだ数字だからだ——別の工場、別の業界、あるいはより厳格な品質システムなら、別の場所に線を引くのが妥当な場合もある(詳しくは後述)。行はRPNの高い順に並べ替える。これだけで、1つもセルを塗る前に、伝えたいことの半分は終わっている——上から下に読むだけで、リスクが降順に並んでいることが色なしでも伝わるからだ。

色を塗るのはRPNのセルだけにして、行全体には塗らない。バランスドスコアカードのスライドもRAGステータス列で同じ選択に直面する——理由も同じだ。行全体を塗りつぶすと、なぜ赤なのかを説明する3つの数字が埋もれてしまう。10~14行あるFMEAの表で、赤とアンバーの塗りつぶしが列を埋めると、情報として読まれる前に「とにかく危なそう」という印象だけが伝わってしまう。RPNの数字そのものに狭く色を塗る、あるいは専用の細い色帯を隣に置くことで、重要度・発生頻度・検出度は普通の文字のまま残り、読み手が計算を実際に検算できる一方、トリアージに使う数字だけは目に飛び込んでくる。

よくある失敗: 一部だけ色を塗った表が「未完成」に見えるからという理由で、結局行全体を塗ってしまうこと。これは見た目の癖であり、入力した数字同士を比較してほしいというスライド本来の役割とはむしろ逆行する。

RPN順に並べ替え、このチーム自身が決めたしきい値(High 150以上、Medium 60~149、Low 60未満)で色分けした。実際にHighの基準を超えるのは1行だけで、それは重要度だけで選んだ場合とは違う行だ。

樹脂成形チームの2つ目の失敗を実際に防ぐのは最後の一手だ。表が変わるたびに——故障モードの追加、行の再採点、行の削除——その都度、差分ではなく表全体を再計算・再色分けする。これは手作業だと面倒すぎるので、実務的な解決策は根性論ではなく手順の設計にある。生きている採点済みFMEAはExcel側に置く。条件付き書式は行が触られるたびに自動で再計算される。PowerPointの表は、そのシートが「今」言っていることを書き出した完成品として扱う——数式連携ではなく値として貼り付け、並べ替え、色分けのキーをそのたびに新しく適用する。PowerPointの表を直接編集して、古い塗りつぶしがまだ合っていることを祈るようなやり方はしない。AdvisioはMicrosoft AppSourceで公開されているPowerPointアドインで、行が追加・削除・再採点されるたびにRPNの値から色分けキーを再計算するネイティブなPowerPoint表としてこれを作る。ウェルドライン割れの行も寸法ドリフトの行も、どちらが先にクリックされたかではなく、実際の値どおりに色がつく。

よくある失敗: 追加・編集されたばかりの行だけを塗り直し、「古い行はもうチェック済みだから」と考えること。古い行がチェックされたのは、表の他の部分が変わる前のしきい値と行数に対してであり、何かが変わった瞬間にその前提は失われている。

別の現場でも同じ仕組みが壊れる:ITデプロイのFMEA

この話は樹脂成形に限らない。デプロイパイプラインのFMEAを行うプラットフォームチームも、別の角度から同じ壁にぶつかる。「ステージングと本番の設定差分」はS6・O7・D6でRPN252、「不安定な統合テストが安全なデプロイをブロックする」はS4・O8・D3でRPN96、「シークレットのローテーションジョブが静かに失敗する」はS9・O2・D8でRPN144になるかもしれない。3つの故障モードはリスクのプロファイルがまったく違うのに、同じ罠が待っている——直近のインシデントレビューで誰もが覚えている「設定差分」を赤く塗り、重要度9の「シークレットローテーション」は、どこか別の場所にあるもっと大きく見える数字の隣では緊急に見えないまま放置され、実際に一番リスクが高い行がたまたま正しい色になっていたとしても、それは掛け算の結果ではなく運でしかない。

直し方はそのまま持ち込める。塗りつぶしのメニューを開く前に3つのRPNを全部計算する。プラットフォームチーム自身のしきい値を合意する——セキュリティに近いチームは、製造ラインより低いところにHighのラインを引くことが多い。シークレット障害の重要度9と、見た目だけの不具合の重要度9では、結果の重みがまったく違うからだ。そして次のインシデントで新しい故障モードが追加されたときには、今週のポストモーテムの行だけでなく、全行を見直す。12行のプラットフォームFMEAも8行の樹脂成形FMEAも、壊れ方は同じだ。本当に壊れているのはPowerPointの表が何も覚えていないことであって、樹脂成形やデプロイといった分野の問題ではない。

しきい値の決め方と、本物のFMEAの置き場所

「High」に普遍的に正しいRPNのしきい値は存在しない。これは業界が直し忘れた欠陥ではなく、意図的にそうなっている。安全性に関わる自動車部品にとって適切に厳しい150というしきい値は、リスクの低い社内プロセスに当てはめればほとんど何もフラグが立たなくなるし、逆にその社内プロセス向けに緩めたしきい値を自動車ラインに当てはめれば、本当に危険な組み合わせを素通りさせてしまう。色が引き金にするはずの是正措置プロセスに合わせてしきい値を決め、表の横に見える形で書き添え、「半年前のHighが何を意味していたか誰も覚えていない」まま気づけば動いていた、という状態ではなく、変えるときは意図的に変える。

生のRPNには、「普遍的なしきい値が存在しない」というだけでなく、もう一つよく知られた弱点がある。掛け算である以上、まったく異なる入力の組み合わせから同じ数字にたどり着くことがあり、重要度が高く発生頻度が低い故障モードが、些細だが頻発する故障モードよりも低いRPNになってしまうことがある——多くの技術者は、めったに起きないが危険な故障のほうを先にフラグとして見たいはずなのに、だ。この弱点はよく知られているため、AIAGとVDAが共同で出した2019年版FMEAハンドブックは、新規の解析についてRPNベースの優先順位付けをAction Priorityテーブルに置き換えた——重要度を最優先し、次に発生頻度、その次に検出度を見るHigh/Medium/Lowの評価であり、重要度の高い故障が発生頻度の高いだけの故障に埋もれないように設計されている。チームが生のRPNの代わりにAction Priorityを使っても、ここまで説明してきたPowerPoint側の仕組みは何も変わらない——色分けのキーは目分量ではなく値から計算されるべきであり、表が変わるたびに全体を見直す必要がある。変わるのは「何をHighとみなすか」の計算式だけだ。

どちらの採点方式を使うにせよ、FMEAそのもの——改訂履歴と承認付きの採点済みドキュメント——は、Excelか工場が既に使っている品質管理システムに置くべきで、PowerPointのデッキには置かない。スライドは特定の相手、特定の会議のために作るスナップショットであり、通常はRPNかAction Priorityの上位8~12件程度であって、解析全体が対象とする40件以上の故障モードすべてではない。その線より下は、1枚の表に全部収めようとフォントを縮めるのではなく、付録スライドに回す。ステアリングコミッティが実際に読める10行の表のほうが、誰も読まない30行の表より役に立つ。

FAQ

FMEAスライドの色分けに使うRPNのしきい値はいくつにすべきか

普遍的な数字はない。多くのチームは「High」の線を100~200のどこかに引くが、正しいしきい値は色が何の是正措置プロセスを引き金にするかによって決まる。表を作る前に一つ決め、スライド上に見える形でキーとして書き添え、すべての行に同じ基準を適用する。

RPNの色分けは行全体に塗るべきか、セル1つだけにすべきか

RPNのセルだけ、あるいはその隣の細い色帯にとどめるべきだ。10行を超える表で行全体を塗りつぶすと、判定の根拠になる重要度・発生頻度・検出度の数字が埋もれてしまう。バランスドスコアカードのRAG列がKPIの行全体を塗りつぶしてしまったときと同じ失敗だ。

FMEAはExcelとPowerPointのどちらに置くべきか

Excel、あるいはチームが既に承認・改訂履歴の管理に使っている品質システムに置く。PowerPointの表には条件付き書式のエンジンがなく、行が変わってもPowerPoint上のFMEAは何も再計算されない。生きている解析はスプレッドシート側に置き、スライドは今の上位リスクを定期的に書き出したものとして扱う。

1枚のFMEAスライドに故障モードは何件まで載せるべきか

通常はRPNかAction Priorityの上位8~12件程度にとどめる。委員会がリスクの中身を把握するには十分で、数字が読めなくなるほどフォントを縮める必要もない。残りは1枚の表に詰め込まず、付録スライドに回す。

RPNとAIAG-VDAのAction Priority、スライドにはどちらを使うべきか

どちらでもよい。チームとして一つに決め、一貫して適用していることが条件だ。Action Priority(High/Medium/Low)は生のRPNの既知の弱点——重要度が高く発生頻度が低い故障が、頻発するだけで重要度の低い故障に埋もれてしまう問題——を解消するが、スライドの作り方そのものは変わらない。色は値から計算し、表が変わるたびに全体を見直す必要がある、という点は同じだ。