> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 特性要因図

> 特性要因図（フィッシュボーンダイアグラム）は、問題の潜在的な原因をカテゴリ別に整理する視覚ツールです。根本原因分析への活用方法を学びましょう。

<Info>
  **カテゴリ**: 方法<br />
  **タイプ**: 問題解決テクニック<br />
  **起源**: 石川馨、1960年代、日本<br />
  **別名**: 石川ダイアグラム、因果関係図、フィッシュボーンダイアグラム
</Info>

<Note>
  **先に答えると** —
  特性要因図（フィッシュボーンダイアグラムまたは因果関係図とも呼ばれる）は、問題の潜在的な原因をカテゴリ別に整理する視覚的なブレインストーミングツールで、魚の骨のような形のダイアグラムを作成します。1960年代に日本の品質管理の専門家である石川馨によってトヨタ生産方式の一部として開発され、チームが解決策に飛びつくのではなく根本原因を体系的に特定するのに役立ちます。
</Note>

## 特性要因図とは

**特性要因図**（Fishbone Diagram）は、チームが問題または効果のすべての可能な原因を特定するのに役立つ構造化されたブレインストーミングツールです。ダイアグラムはその形状から名前が付けられています。水平な「背骨」に対角線の「骨」が枝分かれし、魚の骨格に似ています。魚の頭には分析される問題または効果が含まれ、各枝は潜在的な原因の主要なカテゴリを表します。

特性要因図の力は、その構造にあります。そのようなフレームワークがなければ、ブレインストーミングセッションは混沌と化すか、最も声の大きい人に支配されることがよくあります。ダイアグラムは、事前に定義されたカテゴリを提供することで体系的な思考を強制します。通常は「6M」：Man（人）、Machine（機器）、Method（プロセス）、Material（資源）、Measurement（データ）、Mother Nature（環境）です。このカテゴリ分類により、原因が複数の角度から検証され、重要な領域が見落とされるのを防ぎます。

> 「製品の品質はそれを作るプロセスによって創造される。品質を改善するには、プロセスを改善しなければならない。」— 石川馨

ダイアグラムはチーム演習として最も効果的に機能します。多様な視点が1つの視覚に組み合わされると、個人では決して見えないパターンが現れます。各骨にはサブ骨があり、チームが一般的なカテゴリから具体的な寄与要因まで掘り下げることを可能にします。目的は単に原因をリストアップすることではなく、問題がどのように、なぜ発生するかについての包括的な理解を構築することです。

### 特性要因図の3層の理解

* **入門**: 右端に問題文を付けて水平線を描いてください。主要な原因カテゴリ（6M）に対角線を追加してください。この段階では判断なしに各カテゴリの下で原因をブレインストーミングしてください。質より量です。

* **実践**: 予備データを収集した後にダイアグラムを使用してください。特定された各原因に「5つのなぜ」テクニックを適用して、より深いレベルまで掘り下げてください。頻度または影響に基づいて原因を優先順位付けし、証拠で検証してください。

* **上級**: 複雑なシステムのために特性要因図をフォールトツリー分析と組み合わせてください。ダイアグラムを使用して原因だけでなく因果関係とフィードバックループをマッピングしてください。統計分析を適用して、どのブランチが最も重要な寄与要因を含むかを特定してください。

## 起源

特性要因図は、石川馨（1915-1989）によって開発されました。石川は日本の品質管理の専門家であり、現代品質管理の創設者の一人です。石川はW・エドワーズ・デミングの弟子であり、1950年代と1960年代にトヨタ自動車株式会社と広範に協力しました。彼の仕事は、安価で低品質な商品を生産していた日本の製造業を、優秀性の世界的標準に変えるのに役立ちました。

石川は、彼の「品質サークル」の概念の一部としてダイアグラムを紹介しました。品質サークルとは、品質の問題を自主的に特定し解決するために集まる少人数の労働者のグループです。ダイアグラムは、これらのグループに責任を問うことなく問題を分析する構造化された方法を提供しました。それはすぐにパレート図、フローチャート、ヒストグラムなどの他の視覚的問題解決方法とともに、品質管理の7つの基本道具の一つとなりました。

このテクニックは、石川の1985年の書籍「全社的品質管理とは何か：日本のやり方」が英語に翻訳された後、国際的な認知を得ました。今日、特性要因図は製造業から医療、ソフトウェア開発、教育に至るまで、チームが複雑な問題を体系的に分析する必要があるあらゆる業界で使用されています。

## 核心要点

<Steps>
  <Step title="原因ではなく効果から始める">
    常に魚の「頭」に問題または効果を明確に定義することから始めてください。曖昧な問題文は曖昧なダイアグラムを生み出します。具体的になってください。「製造不良率5%」は「品質問題」よりも優れています。
  </Step>

  <Step title="関連するカテゴリを選ぶ">
    6M（人、機器、方法、材料、測定、環境）は標準的な出発点ですが、文脈に合わせてカテゴリを調整してください。サービス組織は人、プロセス、テクノロジー、顧客を使用するかもしれません。ソフトウェアチームはコード、インフラストラクチャ、データ、ユーザーエクスペリエンスを使用するかもしれません。
  </Step>

  <Step title="ブレインストーミング、然后整理">
    まず、評価なしに可能な原因をできるだけ多く生成してください。これは発散的思考です。ブレインストーミングフェーズの後でのみ、原因をカテゴリとサブカテゴリに整理すべきです。時期尚早な批判は創造性を殺します。
  </Step>

  <Step title="行動前に検証する">
    ダイアグラムは仮説を特定するのであって、事実ではありません。各潜在的な原因は、修正を実施する前にデータまたは実験で検証されなければなりません。ダイアグラムに表示される原因が実際に問題に寄与しているとは限りません。
  </Step>
</Steps>

## 応用場面

<CardGroup cols={2}>
  <Card title="製造業の品質管理">
    製品が仕様に満たない理由を特定します。一般的なカテゴリには、機器の校正、原材料の品質、作業者のトレーニング、環境条件が含まれます。
  </Card>

  <Card title="医療患者の安全">
    コミュニケーションプロトコル、投薬プロセス、機器の信頼性、人員配置レベルなどの要因を検証して有害事象を分析します。
  </Card>

  <Card title="ソフトウェア開発">
    バグまたはシステム障害の原因を、コード品質、テストカバレッジ、デプロイプロセス、インフラストラクチャ、要件の明確さなどのカテゴリにマッピングします。
  </Card>

  <Card title="プロジェクトの振り返り">
    計画、資源、コミュニケーション、スコープの変更、外部の依存関係を検証して、プロジェクトが期限または予算を超過した理由を理解します。
  </Card>
</CardGroup>

## 事例

2000年代初頭、大手自動車メーカーは人気モデルの一つで突然のエンジン故障に関連する保証請求の急増に直面していました。初期分析は明白な容疑者を指しました。悪い燃料、所有者によるメンテナンス不足です。しかし保証コストは上昇し続けました。

品質チームは、エンジニア、組立ラインの作業者、サプライヤーと共に特性要因図セッションを実施しました。「機器」カテゴリの下で、特定のCNC加工センターに摩耗したベアリングがあり、シリンダー壁の厚さに微小なばらつきを引き起こしていることを発見しました。「方法」の下で、品質管理のサンプリングレートがコスト削減イニシアチブ中に削減されていたことを発見しました。「材料」の下で、新しいサプライヤーの金属合金がわずかに異なる熱膨張特性を持っていたことを発見しました。

根本原因は3つの要素の組み合わせであることが判明しました。加工のばらつき + サンプリングの削減 + 新しい材料が、テストには現れない高温動作下で共振状態を作り出しました。修正には3つの要素すべてに同時に対処する必要がありました。特性要因図の構造化されたフレームワークがなければ、チームは1つの要素のみに取り組み、問題が再発するのを見たかもしれません。

## 境界と失敗モード

<AccordionGroup>
  <Accordion title="終わりのないリストになる可能性がある">
    優先順位付けなしに、特性要因図は扱いにくくなる可能性があります。チームは原因をリストアップするのに何時間も費やしますが、解決には決して至りません。常に検証と優先順位付けのフェーズを含めてください。
  </Accordion>

  <Accordion title="システム的な原因を見逃す可能性がある">
    6Mフレームワークは製造業向けに設計されていますが、他のドメインでの思考を制約する可能性があります。厳格なカテゴリを使用するソフトウェアチームは、組織文化や市場ダイナミクスに関連する原因を見逃す可能性があります。
  </Accordion>

  <Accordion title="ファシリテーションスキルが必要">
    熟練したファシリテーターがいないと、ダイアグラムは上級者の声に支配されるか、責任の割り当てに陥ることがあります。石川はこのツールを非難指向ではないように設計しましたが、グループはその方法を維持するのに支援が必要なことがよくあります。
  </Accordion>
</AccordionGroup>

## よくある誤解

<AccordionGroup>
  <Accordion title="5つのなぜと同じである">
    5つのなぜは掘り下げるテクニックです。特性要因図はブレインストーミングと整理のテクニックです。ベストプラクティス：特性要因図を使用して仮説を生成し、5つのなぜを使用して各ブランチ内の根本原因を見つける。
  </Accordion>

  <Accordion title="ダイアグラム自体が問題を解決する">
    ダイアグラムは思考ツールであり、解決策ではありません。多くのチームは美しいダイアグラムを作成しますが、原因を検証したり修正を実施したりすることはありません。実際の作業はダイアグラムが完成した後から始まります。
  </Accordion>

  <Accordion title="品質問題にのみ使用される">
    品質管理のために開発されましたが、このツールはあらゆる複雑な問題に適用されます。売上高の減少から従業員の離職まで、複数の潜在的な原因を持つあらゆる効果が特性要因図分析の恩恵を受けることができます。
  </Accordion>
</AccordionGroup>

## 関連概念

<CardGroup cols={3}>
  <Card title="根本原因分析" href="/ja/methods/root-cause-analysis">
    は、特性要因図が奉仕するより広範な分野です。RCAは哲学を提供し、ダイアグラムは1つの方法を提供します。
  </Card>

  <Card title="5つのなぜ" href="/ja/methods/five-whys">
    は、リストされた原因から根本原因まで掘り下げるために特性要因図と組み合わせて使用されることが多いテクニックです。
  </Card>

  <Card title="PDCAサイクル">
    [PDCAサイクル](/methods/pdca-cycle) — Plan、Do、Check、Act —
    は、特性要因図分析が通常動作する反復的改善フレームワークを提供します。
  </Card>
</CardGroup>

## 一言で言うと

<Tip>
  特性要因図は答えを見つけません。正しい質問を構造化します。仮説を生成するために使用し、行動する前に証拠で検証してください。
</Tip>
