fishbone-analysis について
品質問題の潜在原因を体系的に調査する、部門横断チーム向けのフィッシュボーン分析スキルです。6Mの全カテゴリを扱い、証拠に基づいて原因を評価し、確認済みまたは有力な原因を5-Whyで掘り下げます。
主な機能
- 016Mカテゴリ別に原因を整理
- 02評価前に原因をブレインストーミング
- 03証拠に基づいて原因を分類
- 04既存のPFMEAと照合
- 05候補原因を5-Whyへ引き継ぎ
- 06類似工程への展開を確認
活用シーン
- 018D D4のブレインストーミング
- 02CAPAの根本原因調査を開始
- 03複数の要因が考えられる不具合の分析
- 04原因確認後に類似工程を点検
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ rbraga01/ quality-engineering-skills --skill fishbone-analysisインストール後、Claude Code で/fishbone-analysisを入力して読み込まれたか確認します。
同梱ファイルreferences/6m-category-guide.md
詳細
フィッシュボーン(石川)分析
使用するタイミング
5-Why を実施する前に、品質問題の考えられる原因をすべてブレインストーミングするためにフィッシュボーン分析を使用します。視野が狭くなるのを防ぎ、原因カテゴリーを見落とさないようにします。複数の要因が関与する可能性のある複雑な不具合で特に有効です。
一般的な用途:8D D4 ブレインストーミングセッション、CAPA 根本原因調査、初期問題分析。
前提条件
- Is/Is-Not または 5W2H で問題が明確に定義されている
- 部門横断チーム(最低限、品質、生産、エンジニアリング)
- 不具合が発生したプロセス、機械、または製品にアクセスできる
必須のフィッシュボーンチェックリスト
☐ 開始前に問題文を定義し、合意している — 問題文に原因を示す表現を含めない ☐ 6M のすべてのカテゴリーを検討している — 各 M に少なくとも 1 つ記入するか、カテゴリーが該当しない場合はその根拠を記録する ☐ 評価や除外を行う前にブレインストーミングを完了している — 原因を挙げている最中に評価しない ☐ すべての原因を客観的な証拠に基づいて「確認済み」「可能性あり」「可能性低い」に分類している — 意見だけに頼らない ☐ 確認済み=データまたは物理的証拠に裏付けられている、可能性あり=論理的で Is/Is-Not と整合しているが未確認、可能性低い=データと矛盾している ☐ 5-Why に進む前に、確認済みおよび可能性ありの原因を既存の PFMEA の故障原因項目と照合している ☐ 確認済みまたは可能性ありの原因それぞれについて、個別の 5-Why チェーンに引き継いでいる ☐ 根本原因の確認後、水平展開を確認している — 同じ原因が類似部品、プロセス、または製品群に存在する可能性はあるか
6M フレームワーク
フィッシュの主要な「骨」となる 6 つのカテゴリーです。**6 つすべてを検討する必要があります。**カテゴリーが本当に該当しない場合は、次のように記録します。「チームで体系的に検討した結果、このカテゴリーでは原因が特定されませんでした — [理由] により該当しません。」
1. Man(人的要因)
確認する質問:
- 作業を、訓練を受けた適格なオペレーターが実施しましたか?
- 能力が文書化され、最新の状態になっていますか?
- オペレーターは正しい作業手順に従っていましたか?
- 疲労、シフト交代、または注意散漫が影響した可能性はありますか?
- その作業は人間工学的に困難、またはミスが起きやすいものですか?
- 同じ不具合がすべてのシフトで見られますか、それとも 1 つのシフトだけですか?(特定のシフトのみ → オペレーター固有)
2. Machine(設備)
確認する質問:
- 機械は校正されていますか?最後に校正したのはいつですか?校正間隔内ですか?
- 予防保全は予定どおり実施されていますか?
- 既知の逸脱(振動、摩耗、温度ドリフト)はありますか?
- 機械能力(Cp、Cpk)はどの程度ですか?この特性に対して能力がありますか?
- 工具が摩耗または損傷していませんか?
- ジグまたは治具は正しく機能していますか?
3. Method(プロセス)
確認する質問:
- この作業に関する文書化された作業手順はありますか?
- 作業手順は最新のもので、作業場所に備え付けられていますか?
- プロセスパラメーター(温度、圧力、速度、トルク)が規定され、管理されていますか?
- このプロセス工程に対するコントロールプランの項目はありますか?
- プロセスの順序は正しいですか?
- シフトやオペレーターによって方法が異なりますか?
4. Material(投入材料)
確認する質問:
- 不具合は特定の受入バッチまたはサプライヤーロットと関連していますか?
- 材料仕様を満たしていますか(適合証明書、受入検査)?
- 材料は正しく保管されていますか(温度、湿度、FIFO)?
- 材料の原産地まで追跡できますか?
- サプライヤーは最近何か変更しましたか(サブサプライヤー、プロセス、場所)?
5. Measurement(測定システム)
確認する質問:
- 測定システムに能力がありますか(MSA/ゲージ R&R を実施済みですか)?
- ゲージは校正され、校正間隔内ですか?
- 測定方法は標準化されていますか(同じ治具、同じオペレーターの測定手順)?
- 測定誤差によって不具合が見逃される(誤って適合と判定される)可能性はありますか?
- オペレーター間で測定結果に再現性がありますか?
6. 母なる自然/環境
確認する質問:
- 不具合は周囲の温度や湿度と相関していますか?
- 近くに振動源や汚染源はありますか?
- 目視検査に十分な照明がありますか?
- 季節的な傾向はありますか?
- クリーンルーム環境または ESD 環境は要件を満たしていますか?
ワークフロー
ステップ 1 — 図を描く
問題(結果)を図の先端(右側)に記入します。背骨を描きます。6M カテゴリーのラベルを付けた大骨を 6 本追加します。
ステップ 2 — チームでブレインストーミングする
M カテゴリーごとに、「[M]の何が[問題]の原因になり得るか?」と問いかけます。
判断せずに、すべてのアイデアを記録します。まず量を重視し、評価はその後に行います。ブレインストーミング中に評価したり、除外したりしないでください。 最低 30~60 分を確保します。時間的なプレッシャーは、原因を見落とす最も一般的な理由です。
それぞれの原因を、該当する M カテゴリーの小骨として追加します。小骨をさらに分岐させることもできます(原因の原因)。
ステップ 3 — 評価して優先順位を付ける
それぞれの原因に次のいずれかの印を付けます。
- 確認済み(データまたは直接的な物的証拠に裏付けられているもので、意見ではありません)
- 可能性が高い(論理的で、Is/Is-Not パターンと一致していますが、データではまだ確認されていません)
- 可能性が低い(データまたは Is/Is-Not パターンと矛盾しています)
可能性が低い原因は除外します。確認済みおよび可能性が高い原因を調査します。客観的な証拠(測定データ、物理的な実証、再現試験、または直接の記録確認)がなければ、原因を確認済みと分類することはできません。
ステップ 4 — PFMEA と照合する
5-Why に進む前に、確認済みおよび可能性が高い原因を既存の PFMEA と照合します。
- この故障原因は PFMEA にすでに記録されていますか? 記録されている場合、その検出または予防の管理策でこの不具合を防止できるはずでしたか?
- PFMEA にこの原因が記載されていない場合は、そのことを記録します。根本原因が確認された後、PFMEA を更新する必要があります。
ステップ 5 — 5-Why につなげる
確認済みまたは可能性が高い原因ごとに、5-Why チェーンを実施して、体系的な根本原因にたどり着きます。
フィッシュボーンは原因候補を特定します。5-Why はそれらを検証し、さらに深く掘り下げます。
根本原因の確認後、同じ原因が類似部品、プロセス、または製品ファミリーにも存在する可能性を評価します。該当する場合は、横展開の処置を記録します。
出力形式
フィッシュボーンは表として記録します(図より報告書に含めやすいためです)。
| M カテゴリー | 考えられる原因 | 証拠/状況 | 5-Why に進むか? |
|---|---|---|---|
| 人 | オペレーターの訓練不足 | オペレーター 12 の訓練記録がない | はい |
| 機械 | 治具の摩耗 | 摩耗を 0.3mm と測定 — 限度は 0.1mm | はい |
| 方法 | 代替手順の指示がない | 作業指示書を確認 — 存在しないことを確認 | はい |
| 材料 | ロット間のばらつき | ロットとの相関は見つからなかった | いいえ |
| 測定 | ゲージの繰り返し性 | GR&R = 8% — 許容範囲内 | いいえ |
| 環境 | 温度 | 22°C ± 2°C に管理 — 安定 | いいえ |
すべての 6M カテゴリーを表に含める必要があります。構造化されたブレインストーミングの後に項目がないカテゴリーがある場合は、「構造化されたチームレビューの結果、このカテゴリーでは原因が特定されなかった」と記録します。
よくある間違い
- 時間に追われながらブレインストーミングする — 原因を見落とします。最低 30~60 分を確保してください
- 最初のレベルの原因で止める — 「機械の校正がされていない」は原因ですが、小骨を追加して、なぜ校正されていなかったのかを確認してください
- 確認や除外にデータを使わない — すべての原因を単に列挙するのではなく、客観的な証拠に照らして検証する必要があります
- フィッシュボーンを根本原因として扱う — フィッシュボーンは原因候補を見つけ、5-Why は根本原因を見つけます
- カテゴリーを飛ばす — 正当な理由なくカテゴリーを空欄にすると、分析が不完全になり、真の原因を見落とす可能性があります
- チームの意見に基づいて原因を確認済みと分類する — 確認済みとするには証拠が必要です。証拠がない場合は可能性が高いと分類し、検証を計画してください
出力形式
使用を開始するたびに、ユーザーに次のように尋ねてください。
"出力形式はどのようにしますか? A — 構造化された Markdown(表やセクションを整形済みで、そのままコピーできます) B — プレーンな表(Excel や Word 向けの簡易構成) C — レポート形式の文章(正式な文書やメール向けの自然な文章)
デフォルト:A。"
選択された形式に合わせて、すべての出力セクションを調整してください。プラットフォームまたはセッションのコンテキストですでに形式の希望が定められている場合は、この質問を省略してください。
変更履歴
| バージョン | 日付 | 作成者 | 変更内容 |
|---|---|---|---|
| 1.0 | 2026-06-01 | @RBraga01 | 初回リリース |
| 1.1 | 2026-06-04 | @migmcc | 6M カテゴリを改善し、検証基準と 5-Why の統合を追加 |