フィッシュボーン図（Ishikawa）：根本原因分析の解説

何かが問題になったとき、多くのチームは問題に最も近い人を責めます。それは素早くて、論理的に見えます。しかしほとんどの場合、それは間違いであり、問題が再発することが確実になります。フィッシュボーン図はそのような反射的な反応を止め、実際に障害を引き起こしたものについての体系的な思考に置き換えるために存在します。

Six Sigmaプロジェクト、Leanプロセスレビュー、ポストインシデントの振り返りを実施している場合でも、フィッシュボーン図はチームが当てずっぽうのゲームをするのではなく、追うべき体系的なマップを提供します。

フィッシュボーン図とは

フィッシュボーン図（Ishikawa図または特性要因図とも呼ばれる）は、問題の潜在的な原因を魚の骨格に似た体系的な分岐形式で整理する視覚的な根本原因分析ツールです。問題定義が右側の魚の「頭」に置かれます。「背骨」は左に水平に伸びます。主要な原因カテゴリーが「骨」として背骨から分岐し、各カテゴリーの骨から具体的な要因が分岐します。

このツールは日本の品質管理専門家石川馨が川崎重工業の造船所での業務中に1960年代に作成しました。石川は品質欠陥を引き起こす複数の因果関係を視覚化する方法を探していました。フローチャートや単純なリストでは捉えられないものでした。彼が設計した図はTotal Quality Management（TQM）の礎となり、後に世界中のSix Sigma DMAIC（Define、Measure、Analyze、Improve、Control）とLean製造手法に取り入れられました。

フィッシュボーンの力は図を描くことにあるのではありません。図が強制する会話にあります。部門横断チームが一緒にフィッシュボーンを埋めると、誰を責めるかの議論をやめて、システムのどこが壊れているかをマッピングし始めます。

主要事実

• 石川馨は1968年に川崎重工業の造船所で特性要因図を最初に開発しました。後に1985年の著書『日本の品質管理とは何か』（Prentice-Hall）に手法を整理し、世界中の品質サークルの基礎的テキストとなりました。
• 米国品質学会（ASQ）はフィッシュボーン図を品質の7つの基本ツールの一つとして挙げており、このセットには管理図、チェックシート、パレート分析も含まれます。ASQはこれら7つのツールが製造、ヘルスケア、サービス業にわたる体系的問題解決プロジェクトの50%超で使用されていると報告しています。
• International Association for Six Sigma Certification（IASSC）による2019年の調査で、特性要因分析（フィッシュボーン図を含む）は認定実践者によるAnalyzeフェーズプロジェクトで5 Whys手法と統計的工程管理に並ぶ上位3つの最も使用されるツールに入ることがわかりました。

6M：フィッシュボーンの標準カテゴリー

製造とオペレーションで最も広く使用されているフィッシュボーンフレームワークは6Mです。各「M」は潜在的な原因の主要カテゴリーを表します。チームはそれぞれの下に具体的な要因をブレーンストーミングします。

Manpower（人員）

この骨はプロセスの人的要素すべてをカバーします。スキルのギャップ、不十分な教育訓練、不明確な責任、疲労、交替時の引き継ぎの失敗、態度やモチベーションの問題です。チームが真っ先に飛びつくカテゴリーであり、だからこそフィッシュボーンはここに着地する前に他のすべてを検討させます。

Machine（機械・設備）

設備は工具、ハードウェア、プロセスが依存するソフトウェアをカバーします。摩耗、校正のずれ、古いファームウェア、工具の不一致、保全のギャップです。知識労働の文脈では、ソフトウェアのバグ、遅いシステム、統合の欠如にまで及びます。

Method（方法）

この骨は業務の進め方を見ます。文書化された手順、標準作業手順書（SOP）、ワークフロー設計、順序のエラー、欠けているチェックポイントです。プロセス自体が問題であれば、それを実行する人を修正しても役に立ちません。

Material（材料）

材料はプロセスに入る原材料インプットをカバーします。物理的な材料、データフィード、サプライヤー品質、バッチコーディング、ステップ間で引き継がれる情報の正確性です。インプット品質の低さは製造とサービスプロセスの両方で最も診断されにくい欠陥の原因の一つです。

Measurement（測定）

校正エラー、不正確なゲージ、一貫性のないデータ収集方法、主観的な指標はすべてここに属します。プロセスを確実に測定できなければ、行う変更が実際に機能しているかどうかを知ることができません。この骨はサービス業では頻繁にスキップされます。測定の実践は問題が証明されるまで問題ないと思われているからです。

Mother Nature（環境）

環境はプロセスに影響を与える外部条件をカバーします。温度、湿度、照明、騒音、市場の変動、規制の変化、季節的な需要の急増です。サービスや知識労働では、個々のマネージャーの管理外にある組織文化やチームダイナミクスにまで及ぶことが多いです。

代替フレームワーク： サービス業では多くのチームが4P（People、Process、Policies、Plant）またはマーケティング向けの8P（Product、Price、Place、Promotion、People、Process、Physical evidence、Productivity）を好みます。6Mは製造とオペレーションのデフォルトのままです。適切なフレームワークは、チームが実際に一貫して使用するものです。

フィッシュボーン図の構築：6ステップ

特別なソフトウェアは必要ありません。ホワイトボード、付箋、または共有デジタルキャンバスすべてが同様に機能します。重要なのは誰が参加しているかです。

ステップ1：問題定義について合意する

問題を魚の頭に書きます。具体的に記述します。「品質問題」は問題定義ではありません。「2026年第2四半期のライン4の欠陥率が1.5%の目標に対して6%を超えた」が問題定義です。曖昧な問題は曖昧な分析を生みます。

ステップ2：背骨を描く

右の問題ボックスに向かって水平の矢印を描きます。これが背骨です。残りの図を視覚的に固定します。

ステップ3：主要な骨を追加する

背骨から斜め線を分岐させ、3本を上、3本を下に描き、各々に原因カテゴリーのラベルを付けます。ほとんどのオペレーションチームには6Mから始めてください。サービスチームには4Pまたはそのコンテキストに合うフレームワークを使用します。

ステップ4：各骨に沿って原因をブレーンストーミングする

各カテゴリーについて、「このエリアのどのような要因が問題を引き起こすまたは貢献しうるか？」と問います。各要因を主要な骨から分岐するサブブランチとして書きます。この段階でアイデアをフィルタリングしないでください。目標は深さではなく幅です。現場の専門家だけでなく、参加者全員から引き出してください。

ステップ5：根本原因に達するまで「なぜ」を問い続ける

特定した各原因について、「なぜ」を問い続けます（ここで5 Whys手法が自然に統合されます）。直接的な症状を超えて掘り下げてください。「機械3が停止した」は根本原因ではありません。「機械3の保全スケジュールが作業指示システムが期限切れのPMを自動的にフラグしないためスキップされた」がより近いです。

ステップ6：優先順位を付ける

すべての骨が同等ではありません。パレート投票または単純なドット投票を使って、チームが問題を最も引き起こしている可能性が高いと考える2つまたは3つの原因を特定します。これらが次の改善フェーズの焦点になります。このステップは高インパクトなムダの源に努力を集中させるLean方式の原則と直接つながります。

実例：製造ラインの高い欠陥率

問題定義を調査する生産チームを考えます。「2026年4月のライン4の欠陥率が1.5%の目標に対して6%に達した。」 完成したフィッシュボーンが各6Mブランチにわたってどのように見えるかを示します。

Manpower（人員）： 夜間シフトの新入社員は標準の5日間ではなく2日間のオンボーディングのみを受けました。交替時の引き継ぎ文書は口頭で行われており、昼間と夜間チーム間で情報が失われています。

Machine（機械）： 機械3は14週間、予定の校正チェックを受けていません。標準インターバルは6週間です。一つのトルクツールは使用年数に対して一致しない摩耗を示しており、定格より重いサイクルで動作している可能性があります。

Method（方法）： ライン4の標準作業手順書（SOP）は18ヶ月前に最後に更新されており、新しいサプライヤーのコンポーネント公差を反映していません。各シフト開始時の標準作業チェックリストがありません。

Material（材料）： サプライヤーBのコンポーネントはサプライヤーAよりも高い寸法変動を示していますが、在庫システムでは両方が同一にコーディングされており、オペレーターはラインで区別できません。3月のバッチが誤ってラベル付けされ、生産に入った可能性があります。

Measurement（測定）： ゲージの繰り返し性と再現性（Gauge R&R）の研究が主要測定ステーションで実施されたことがありません。欠陥のロギングは紙フォームで手動で行われ、何時間後にシステムに入力されるため、検出に遅れが生じています。

Mother Nature（環境）： 生産フロアには湿度管理がありません。データは周囲湿度が65%を超える夏の月に欠陥率が高いことを示しており、既知の材料感受性と一致しています。

この図をマッピングした後、チームはドット投票を実施し、MachineとMethodの骨が最も主要な原因である可能性が高いと特定しました。夜間シフトの再教育にデフォルトするのではなく、まず校正スケジュールとSOPに対して是正処置を開始しました。

この種の体系的な分析は、即時のインシデントを修正するだけでなく再発防止を目指すプロセス管理の実践の中核です。

フィッシュボーン対5 Whys対パレート：いつどれを使うか

これら3つのツールはSix SigmaとLeanプロジェクトのAnalyzeフェーズでよく一緒に登場します。それらは競合するのではなく補完し合います。

典型的な順序は、フィッシュボーンを実施してすべての可能な原因をマッピングし、5 Whysを最も可能性の高い候補に適用して掘り下げ、次にパレートチャートを使ってリソースを解決策にコミットする前にどの原因が欠陥量のほとんどを占めるかを確認するというものです。

バリエーション：4M、4P、8Pのフィッシュボーン

6Mは製造のデフォルトですが、唯一のフレームワークではありません。

4M（Man、Machine、Method、Material）は、ツールに慣れていないチームや環境と測定が変動しにくいシンプルなプロセス問題に取り組む場合の簡略版です。

4P（People、Process、Policies、Plant/Equipment）はヘルスケア、金融サービス、その他サービス業で人気があります。「Machine」と「Material」が業務に明確にマッピングされない文脈で使われます。

8P（Product、Price、Place、Promotion、People、Process、Physical evidence、Productivity and Quality）は、原因カテゴリーが生産ラインとは根本的に異なるマーケティングや顧客体験の問題にまでフレームワークを拡張します。

どのバリアントを使用するかに関わらず、基礎的な構造は同じです。業界とチームの語彙に合うものを選んでください。理論上「最良」のフレームワークを選ぶことよりも、プロジェクトをまたいだ一貫性が重要です。

正式なビジネスプロセス管理またはプロセス最適化の実践の中で活動しているチームには、通常6Mは既存の文書と部門横断の言語によりよく一致します。

フィッシュボーンを実施する際のよくある間違い

図を正しく描くことは、通常何が問題になるかを知ることで容易になります。

• 早く止めすぎる。 チームは第1レベルで原因を追加して完了と見なします。本当の根本原因は通常2から3レベル深いところにあります。結論を出す前にサブブランチをさらに押し進めてください。
• 原因と症状を混同する。 「高い欠陥率」はあなたの問題定義であり、原因ではありません。骨に書くと、問題を二度説明しただけになります。骨の各項目は潜在的な原因である必要があり、影響の再記述であってはなりません。
• 原因カテゴリーを省略する。 チームが2つまたは3つの骨しか埋めず、他を空白にしておく場合、通常は仮定をセッションに持ち込んでいて、新鮮な分析ができていません。すべての骨は除外する前に真剣な検討に値します。
• 解決策に飛びつく。 フィッシュボーンは分析ツールであり、行動計画ツールではありません。根本原因を確認する前に図に解決策を書くことは、プロセス改善サイクルを無駄にする最も一般的な方法の一つです。
• 間違った人が参加している。 フィッシュボーンは実際に業務を行う人を含む部門横断グループで最もうまく機能します。マネージャーだけで構築された図は、ラインや机のレベルで起きていることをめったに捉えられません。
• フォローアップがない。 ホワイトボードに描かれた美しいフィッシュボーン図が是正処置につながらなければ、それは装飾品であり品質ツールではありません。図は優先順位付けされた調査または修正すべき原因のリストにつながるときにのみ価値を提供します。フィッシュボーンを標準作業手順書の更新またはKaizenイベントに結びつけることでループが閉じます。

フィッシュボーン図を使う場面（および他を選ぶ場面）

よくある質問

なぜフィッシュボーン図はIshikawaと呼ばれるのですか？

この図は川崎重工業で1960年代にそれを開発した日本の品質エンジニア石川馨にちなんで名付けられています。石川は統計的なトレーニングなしで工場労働者が品質問題を体系的に分析するために使えるシンプルな視覚ツールを作ろうとしていました。後に品質サークルとTQMのより広範なフレームワークに図を組み込みました。「Ishikawa図」という名称は品質管理の文献で「フィッシュボーン図」および「特性要因図」と同義で使われています。

フィッシュボーン図と5 Whysの違いは何ですか？

フィッシュボーン図は複数のカテゴリーにわたる潜在的な原因を同時にマッピングし、問題がどこから来るかについての幅広い視野を提供します。5 Whysは「なぜ」を繰り返すことで根本原因に達するまで単一の原因チェーンを縦方向に掘り下げます。2つのツールはうまく連携します。フィッシュボーンを使って調査する価値のある原因を特定し、次に各候補に5 Whysを適用して実際の根本原因を見つけてください。5 Whysだけに頼ると、チームが疑問を持たなかったカテゴリーの原因を見逃すリスクがあります。

各骨にはどのくらいの原因が必要ですか？

固定のルールはありません。うまくファシリテートされたセッションでの典型的な骨には3から6つのサブ原因がありますが、複雑なシステムではそれ以上になることもあります。重要なのは、各サブ原因が具体的で実行可能であることであり、特定の数に達することではありません。骨に2つ未満の原因がある場合、そのカテゴリーを十分に深く検討していないことを意味している可能性が高いです。骨に10以上ある場合は、サブ原因が異なる特異性のレベルで書かれており、一部をグループ化すべきかどうかを検討してください。

フィッシュボーン図は製造業以外でも使えますか？

はい。フィッシュボーン図はヘルスケア（患者安全イベント、投薬エラー）、ソフトウェア開発（ポストモーテムとバグ分析）、サービス業（顧客クレーム分析）、マーケティング（キャンペーンパフォーマンスの失敗）で広く使用されています。6Mはサービスには4P、マーケティングには8Pなど、文脈に合うフレームワークに置き換えられることがあります。基本的なロジックは普遍的です。最も近くにいる人を責めるのではなく、システムをマッピングして実際にどこが失敗しているかを見つけることです。

フィッシュボーン図はあなたの問題を解決しません。しかし正しい問題を解決していることを確認します。そしてほとんどのオペレーションの文脈では、その区別はあなたの品質ツールキットのどのツールよりも価値があります。