特性要因図とは？
特性要因図（cause-and-effect diagram）は、ある結果（特性）に対して、考えられる原因（要因）を体系的に整理した図です。右端に問題を書き、そこへ向かう背骨から原因の枝を出していくので、形が魚の骨に似ています。そのため「フィッシュボーン図」とも呼ばれます。
考案したのは、日本の品質管理の第一人者である石川馨（いしかわ かおる）氏です。英語圏では「石川ダイアグラム（Ishikawa diagram）」の名でも知られています。PMBOK®ガイドの日本語版にも「特性要因図」の名前で載っており、日本ではパレート図と同じく「QC七つ道具」の一つです。
良いところは、原因を思いつくままに挙げるのではなく、分類しながら洗い出せる点です。チームで書くと、一人では気づかない原因が見つかり、原因についての共通理解もできます。
特性要因図の書き方は？
次の手順で書きます。例として「システムのリリース後に不具合が多い」という問題を使います。
リリース後の不具合が多い
人（Man）
テスト経験の浅いメンバーが多い／担当の引き継ぎ不足
方法（Method）
テストの観点が決まっていない／レビューが形だけ
道具（Machine）
テスト環境が本番と違う／自動テストがない
材料（Material）
要求の資料があいまい／テストデータが古い
測定（Measurement）
不具合の数え方が担当者ごとに違う
環境（Environment）
納期が短く、テスト期間が削られた
分類ごとに原因を挙げると、思い込みで一つの原因に飛びつくのを防げる。
架空の例。実際の図では、各分類の下にさらに「なぜ」を重ねて小骨を書く。
- 問題（特性）を決める：右端の魚の頭に、具体的な問題を書く。「品質が悪い」より「リリース後1か月の不具合が20件」のように数字で書く。
- 背骨を引く：左から頭に向かって太い矢印を引く。
- 大骨（原因の分類）を引く：人・方法・道具・材料など、原因の大きな分類を背骨から斜めに出す。
- 中骨・小骨で掘り下げる：各分類について「なぜそれが起きるのか」を考え、具体的な原因を枝として書き足す。
- 有力な原因に印を付け、データで確かめる：話し合いで有力そうな原因を選び、実際のデータで本当に原因かを確かめる。
原因はどう分類する？（4M など）
大骨の分類には、よく使われる型があります。製造の現場で生まれた「4M」が代表的で、必要に応じて項目を足します。
| 型 | 項目 | 向いている場面 |
|---|---|---|
| 4M | 人（Man）・機械（Machine）・材料（Material）・方法（Method） | 製造、作業の工程 |
| 6M（5M1E とも） | 4M に測定（Measurement）と環境（Environment）を足す | 測り方や外部環境の影響がありそうなとき |
| 自分たちで決める | プロセス・ツール・人・要求・コミュニケーションなど | IT やサービス、プロジェクトの問題 |
型にこだわる必要はありません。大事なのは、分類が問題に合っていて、抜けが少ないことです。プロジェクトの問題なら、「要求」「コミュニケーション」「スケジュール」などの分類の方が合う場合もあります。
なぜなぜ分析とどう組み合わせる？
なぜなぜ分析は、一つの原因について「なぜ？」を繰り返し、根本原因までたどる方法です。特性要因図が「原因を横に広く洗い出す」道具なら、なぜなぜ分析は「一つの原因を縦に深く掘る」道具です。
組み合わせると、次の流れになります。
- 特性要因図で広げる：考えられる原因を分類ごとに漏れなく挙げる。
- 有力な原因を選ぶ：データや経験から、影響が大きそうな原因に絞る。件数のデータがあれば パレート図 で偏りを確かめる。
- なぜなぜ分析で深める：選んだ原因に「なぜ？」を重ね、手を打てる根本原因までたどる。
例：「テスト環境が本番と違う」→なぜ？「環境を作る手順が文書になっていない」→なぜ？「環境の担当者が決まっていない」。ここまで来ると、「担当を決め、手順を文書にする」という再発を防ぐ対策が見えます。担当と責任をはっきりさせるには RACIチャート が便利です。
よくある失敗は？
特性要因図は手軽な分、形だけで終わりやすい道具です。よくある失敗と直し方をまとめます。
- 特性があいまい：「品質が悪い」では原因がばらける。数字と範囲で書く（例：「リリース後1か月の不具合20件」）。
- 対策や症状を書いてしまう：「テストを増やす」は対策で、原因ではない。「〜が決まっていない」「〜が足りない」と原因の形で書く。
- 人のせいで止める：「担当者の不注意」で止めると、対策が「注意する」だけになり再発する。仕組みの原因まで掘る。
- 候補を原因と決めつける：図に書いた時点では候補にすぎない。データや現場で確かめてから対策を選ぶ。
- 一つの大骨に偏る：書きやすい分類に原因が集まったら、ほかの分類に漏れがないか見直す。
ほかの品質の道具とどう使い分ける？
特性要因図は、原因を「広げる」道具です。絞り込みや確かめには、別の道具を組み合わせます。
| 道具 | わかること | 使う場面 |
|---|---|---|
| チェックシート | 決めた項目ごとの件数 | データを漏れなく集めたいとき |
| パレート図 | 件数の多い原因・項目の順位 | 対策の優先順位を決めたいとき |
| 特性要因図 | 考えられる原因の全体像 | 原因を広く洗い出したいとき |
| 散布図 | 2つの数値の関係 | 原因の候補と結果の関係を確かめたいとき |
| 管理図 | 工程が安定しているか | ばらつきが偶然か異常かを見たいとき |
よく使われる流れは、チェックシートでデータを集め、パレート図で重点を絞り、特性要因図で原因を広げ、散布図や現場の確認で確かめる、という順番です。
PMP試験ではどう問われる？
PMP 試験で特性要因図の書き方そのものが問われることは多くありません。問われるのは、その背景にある「根本原因を探す」という考え方です。
ECO 2026年版では、Process 領域の品質のタスクに「品質のプロセスと道具を計画する」「継続的改善を行う」が入っています。People 領域のビジョンのタスクには「状況を分解して誤解の根本原因を見つける」も挙がっています。Business Environment 領域の「障害を取り除き、課題を管理する」タスクも関係します。よく出るのは次のような場面です。
- 同じ問題が繰り返し起きている → 症状に対処する選択肢より、根本原因を分析する選択肢を選ぶ。
- 誰かのミスで問題が起きた → 個人を責めるより、プロセスや仕組みの原因を探す。
- チームの作業を妨げる障害がある → 障害の原因を確かめ、取り除くのを支援する（サーバント・リーダーの役割）。
根本原因を問う問題の解き方は PMPの根本原因の問題 で解説しています。チームの障害を取り除く PM の姿勢は サーバント・リーダーシップ が参考になります。この種の問題は 無料模試30問 にも含まれています。
確認問題1
繰り返す問題への対応
（当サイトの独自問題）アジャイルのチームで、ここ3回のスプリント・レビューのたびに、デモ環境が動かずに時間が無駄になっている。毎回、開発者が直前に手作業で直して乗り切っている。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。繰り返す問題は、その場しのぎではなく根本原因を探します。チームで原因を洗い出すと、手順や自動化の不足など、仕組みの問題が見えます。
1：確認を増やしても、壊れる原因は残ります。2：動く成果を見せるレビューの価値が下がります。3：個人の注意に頼る対策は再発を防げません。
確認問題2
原因を広く洗い出す道具
（当サイトの独自問題）顧客から納品物の品質について苦情が続いている。プロジェクト・マネジャーは、考えられる原因を人・方法・道具・材料などの分類ごとにチームで洗い出したいと考えている。最も適した道具はどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：2。特性要因図は、結果に対する原因を分類ごとに整理して洗い出す道具です。
1：管理図は工程が安定しているかを時系列で見る図です。3：ガントチャートは作業の日程を示す図です。4：RACI チャートは役割と責任の分担を示す表です。
確認問題3
分析の後の行動
（当サイトの独自問題）チームで特性要因図を作ったところ、原因の候補が15個挙がった。メンバーはそれぞれ「自分の挙げた原因が一番だ」と主張し、話がまとまらない。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。特性要因図で挙がるのは「原因の候補」です。データで確かめれば、意見の対立を事実で解消でき、効く対策に集中できます。
1：資源が分散し、どれが効いたかもわかりません。2：経験は大切ですが、事実の確認を省いています。4：事実がないまま話し合っても、声の大きさで決まりやすくなります。