生産現場の根本原因分析：5 Whys と特性要因図の実践

By Mirko Peters · 2026-11-11

生産現場での根本原因分析を段階的に解説します。5 Whys と特性要因図（フィッシュボーン図）をいつ使うべきか、原因をどう検証するか、数値を使った設備停止の事例まで扱います。

Automatically translated with AI from the original post. Read the English original

根本原因分析（RCA）は、問題の根本的な原因を特定し、対策によって再発を防ぐための手法です。生産現場では、5 Whys と特性要因図が代表的なツールです。この記事は、今日のライン上の問題を解決し、かつその解決を持続させたい生産管理者を対象としています。明確な進め方、2 つのツールの使い分けの指針、数値を用いた設備停止の事例、そしてよくある間違いの一覧を紹介します。

重要なポイント

• 根本原因分析は問題の根本原因を特定するもので、症状への対処ではなく、再発を防ぐ対策につなげます。
• 因果関係が明確な場合は 5 Whys を使い、複数の原因が絡み合う可能性がある場合は、まず特性要因図を使います。
• すべての「なぜ」には、仮説ではなく観察された事実または計測データで答えてください。また、原因は行動に移す前に検証する必要があります。
• パレート図を用いて最も大きな損失から着手し、ボトルネックを優先してください。ボトルネックでは、失われた時間がライン全体のコストになります。
• 問題が再発していないことを確認して初めて、対策の有効性が証明されます。小さな PDCA の試行として進めてください。

生産現場における根本原因分析とは何ですか。

iSixSigma は、根本原因分析を工程や製品の不良の根本的な発生源を特定する手法として説明しています。まず、不良品やプロセス、観察内容、不良数量、顧客からの説明を含めた、事実に基づく問題の記述から始めることを推奨しています。詳細は Ishikawa diagrams and the 5 whys に関する記事を参照してください。

次の 3 つの用語は混同しやすいので注意してください。

• 暫定処置（Containment） は、たとえば疑わしい部品を選別するなど、今日の顧客やラインを守るための措置です。原因を取り除くものではありません。
• 是正処置（Corrective action） は、原因を取り除くための変更です。
• 根本原因（Root cause） は、取り除いたときに、類似の条件下での再発を防ぐ原因です。

暫定処置だけを行うと、同じ不良や停止が再び発生します。検証されていない原因のまま是正処置に進むと、誤ったところを直してしまう可能性があります。RCA はその両者の間に位置する取り組みです。

5 Whys はいつ使いますか。

ASQ の用語集では、Five Whys を「なぜ？」と繰り返し問いかける手法として説明しています。通常は 5 回程度行いますが、それより多くても少なくても構いません。また、この手法の考案者として豊田佐吉の名を挙げています。そのルールは実務的です。

1. データに裏付けられた、正確な問題の記述を作成します。
2. 問題がなぜ起きたのかを問い、最も近い観察可能な原因を記録します。
3. 各回答に対してさらに「なぜ」を問い続け、事実に基づいた状態を保ちます。
4. 再発防止のために対処可能な原因に到達したら止めます。
5. 根本原因を検証します。それは問題につながるのか、またそれを取り除けば問題を防げるのかを確認します。
6. 対策を実施し、追跡の計測によって問題が再発していないことを確認します。

同ページでは、各回答は「仮説ではなく、観察された事実または計測データ」である必要があると述べています。また、この手法は根本原因が 1 つである単線的な因果連鎖に最も適しており、複雑な問題には特性要因図を使うことを推奨しています。

特性要因図が適しているのはどのような場合ですか。

特性要因図（フィッシュボーン図、石川図）は、仮説を図にしたものです。「3号機でショートショット」などの結果を頭部に置き、そこから枝分かれして考えられる原因を示します。チームは枝を、機械、方法、材料、人、測定、環境といったカテゴリーにまとめることがよくあります。この図により、チームは多くの考えられる原因を一度に見渡し、どれを検証するかを合意できます。

iSixSigmaは、ツールを組み合わせる明確な方法を推奨しています。まず問題の記述を作成してデータを収集し、観測可能な結果を説明する仮説から特性要因図を作成します。次に、最も可能性の高い枝になぜなぜ分析を適用し、各仮説に担当者と期限を設定して追跡します。また、ブレインストーミングで作られた図には寄与しない原因が含まれやすいこと、そして「照明」のような曖昧なカテゴリーは故障への経路をほとんど示さないことも指摘しています。

目安としては、原因の連鎖が明確に1本だけであれば、なぜなぜ分析で十分です。寄与しうる要因が複数ある場合や、チームの意見が分かれている場合は、まず特性要因図を使いましょう。

多くの生産上の問題には、複数の根本原因が同時に関わっています。短時間の停止が、摩耗した部品、確認の抜け、教育の不備が重なって起きることもあります。根本原因を特定するときは、根本原因のひとつを見つけたのか、すべてを見つけたのかを問いましょう。問題の定義を適切に行うことは、答えの半分を得ることに等しいのです。「夜勤の3番工程で停止する」のように範囲を絞った記述は、広い記述に比べて候補となる原因が少なくなります。繰り返し発生する不良の根本原因を突き止めるには、良品の生産と不良品の生産を比較し、違いを書き出します。そのうえで、検証された原因ごとに対策を1つずつ実施し、どれが効果を上げたのかを確認します。これは基本的な問題解決であり、事実を先に確認し、次に仮説を立て、最後に対策を実行するという順序です。

ラインで根本原因分析をどのように進めればよいでしょうか。

1. 封じ込め。まず、顧客と生産ラインを守ります。疑わしい製品を隔離し、安全な状態に戻します。
2. 問題を選ぶ。すべてを分析しようとしないでください。パレート図、つまり損失を大きい順に並べたものを使い、最も大きな問題を選びます。まずボトルネック、すなわち生産量を制限している工程に注目してください。ボトルネックで失われた1分は、ライン全体で失われた1分になります。一方、余力のある工程で失われた1分は、コストにならない場合もあります。
3. データで定義する。何が、どこで、いつ、どの程度、何と比べて起きているのかを明確にします。数値で表しましょう。
4. 現地で確認する。現場、日本語でいう「現地現物」の場で、実際の工程を観察します。その場にいたオペレーターに話を聞きましょう。
5. 候補となる原因を洗い出す。なぜなぜ分析または特性要因図を使い、オペレーター、保全、品質、監督者などの部門横断チームで取り組みます。
6. 検証する。推定される原因をテストします。それが本当の原因であれば、取り除くと結果が変わり、再び持ち込むと問題が再発するはずです。
7. 実行し、確認する。対策を小規模に試行し、結果を測定します。PDCAサイクルがこのステップの枠組みを与え、A3レポートを使えば、一連の経緯を1枚にまとめられます。

例：1つのラインの停止時間

この例では想定の数値を使っています。

ライン4は、1日8時間の2交替を5日間稼働しているため、計画稼働時間は80時間です。先週は停止によって14時間を失いました。これは14 ÷ 80 = 17.5%です。

停止のパレート図：

• センサーの誤検知：6.3時間（45%）
• 段取り替えの超過：4.2時間（30%）
• 材料待ち：2.1時間（15%）
• その他：1.4時間（10%）

上位2つの原因で損失の75%を占めています。チームはセンサーの誤検知から取り組みます。

なぜなぜ分析。

1. なぜラインは停止したのか。センサーがワークの位置を誤検知したからです。
2. なぜ誤検知したのか。センサーのレンズに埃が付着していたからです。
3. なぜ埃が付着していたのか。交替中にレンズを清掃する人がいないからです。
4. なぜ清掃しないのか。清掃がオペレーターの標準作業に含まれていないからです。
5. なぜ含まれていないのか。標準作業がセンサーの設置前に作成されていたからです。

根本原因は、センサーの故障ではなく、標準作業の不備です。対策として、始業時の点検手順にレンズの確認を加え、小型のカバーを取り付けます。

想定される効果。センサーによる停止の80%を取り除けるとすると、6.3 × 0.8 = 5.04時間です。新しい停止時間は14 − 5.04 = 8.96時間となり、8.96 ÷ 80 = 11.2%です。2週間後の確認で、実際の結果がこの想定と一致するかを判断します。一致しなければ、チームは特性要因図に戻ります。

原因が正しいことは、どのように確認すればよいでしょうか。

改善に投資する前に、発見した原因を検証しましょう。次の2つの簡単な問いが役立ちます。

• 特定した原因が違っていたら、結果も違っていたでしょうか。
• その原因を取り除けば、似た条件下で同じ障害が再発する可能性は低くなりますか。

対策の前後でデータを収集してください。良い根本原因分析は、測定された結果と変更された標準で締めくくられます。そうして初めて、場当たり的な対応ではなく、継続的改善につながります。また、研修やツールなど、修正しなかった寄与要因も書き留めておいてください。そうすることで、それらが見落とされることを防げます。

「ヒューマンエラー」という表現には注意してください。それ自体が根本原因であることはまれです。作業者がミスをした場合は、なぜプロセスがそのミスを許してしまったのかを問いましょう。指示は明確だったか、ツールは適切だったか、時間は十分あったか。答えはほぼ例外なく、システム側にあります。

よくある間違い

• 最初の「なぜ」で止めてしまう。 最初の答えは、たいてい表面的な症状にすぎません。
• 意見で答えてしまう。 それぞれの「なぜ」には、観察された事実か測定値が必要です。
• 人を責める。 責めることで議論は終わり、本当の原因が隠れてしまいます。
• 小さな問題から分析する。 パレート図で全体を把握し、最も大きな損失から着手してください。
• 検証を省略する。 検証されていない原因に基づく対策は、機能しないことがあります。
• 標準を変えない。 標準作業が同じままであれば、問題は再び発生します。

ソフトウェアの活用

良い分析には良いデータが必要です。ソフトウェアを使えば、停止のたびにその理由を発生時点で記録し、パレート図を自動で作成し、対策後に問題が再発していないかを確認できます。これにより、RCAの初期段階の時間を節約でき、チームは記憶ではなく事実に基づいて議論できます。ただし、ツールが考えてくれるわけではありません。最終的には、人が現場(ゲンバ)に行き、「なぜ」と問いかける必要があります。

次のステップ

先週のラインで最も大きかった損失を選び、数値を含む問題記述を作成したうえで、当時現場にいた作業者と一緒に「なぜなぜ分析(5 whys)」を実施してください。その後、小規模な試行によって原因を検証します。これが、製造現場で根本原因分析を実践する現実的な方法です。