「同じトラブルが何度も起きる」「対策を打っても効果が出ない」――そんなとき、原因を思いつきだけで挙げていませんか。原因を一つずつ感覚で潰しても、見落としがあれば問題はまた戻ってきます。そこで使われてきたのが、原因を体系的に並べて全体像を見る図解の手法です。
結論から言えば、特性要因図とは、ある結果（特性）に対して考えられる原因（要因）を魚の骨のような形で枝分かれさせ、抜け漏れなく整理する図です。原因を「人・方法・設備・材料」などのカテゴリに分けて広げることで、思い込みで一つの原因に飛びつかず、真因に近い候補をもれなく洗い出せます。
私はAIタスク管理アプリ「するたす」を開発・運営しています。本記事では、特性要因図の基本的な意味と書き方を検索意図に正面から答えつつ、開発者の視点で「特性要因図でつまずく3つのパターン」「使える図にする設計原則」「洗い出した原因を対策タスクへ落とす実践法」を解説します。
原因を「なぜ？」で深掘りする手法は「なぜなぜ分析とは」を、問題を上から枝分かれで分解する考え方は「ロジックツリーの作り方」を併せてご覧ください。仕事のミスが繰り返される構造そのものについては「仕事のミスが多い原因」でも扱っています。
特性要因図とは何か：原因を魚の骨で分解する図
まず検索意図に正面からお答えします。特性要因図とは、解決したい「結果（特性）」を魚の頭に置き、その原因となる「要因」を背骨から伸びる大きな骨・小さな骨として枝分かれさせ、原因の全体像を一枚で見渡せるようにした図です。形が魚の骨に似ていることから、別名フィッシュボーン図とも呼ばれます。
特性要因図の基本構造と呼び方の由来
この図は、品質管理の分野で古くから使われてきた整理手法のひとつです。右端の魚の頭にあたる部分に「特性（＝なくしたい結果や達成したい目標）」を書き、左から背骨を引きます。背骨に向かって斜めに伸びる「大骨」が原因の大分類、大骨から枝分かれする「中骨」「小骨」がより具体的な原因です。
この見た目から、別名フィッシュボーン図（魚の骨の図）と呼ばれます。英語でもfishbone diagramと表記され、考案者の名前からイシカワ・ダイアグラムと呼ばれることもあります。呼び名は複数ありますが、指しているものは同じで、原因を骨の形に枝分かれさせて整理する図のことです。本記事では以降、文脈に応じて「この図」「フィッシュボーン図」とも呼びますが、いずれも同じものを指しています。
なぜわざわざ魚の骨という形にするのか。理由は、原因を頭の中で考えているだけだと、思いついた順にバラバラに並び、どこまで挙げたかが自分でも把握できなくなるからです。骨の形に固定すると、「この大骨の下はまだ枝が少ない」「ここは深く掘れている」といった偏りが一目で分かります。原因分析の抜け漏れは、たいてい考えた量の差ではなく、考えた領域の偏りから生まれます。形を決めて視覚化することが、その偏りに気づく仕掛けになっているのです。
原因の大骨によく使うカテゴリ
大骨をいきなり自由に考えると、原因がばらつき抜け漏れが生まれます。そこで、原因の大分類にあらかじめ定番のカテゴリを当てる方法が知られています。製造現場でよく使われるのが「4M」と呼ばれる切り口です。
- 人（Man）：担当者のスキル不足、引き継ぎ漏れ、確認の習慣がないなど
- 方法（Method）：手順が曖昧、ルールが共有されていない、チェック工程がないなど
- 設備（Machine）：使う道具やシステムの不備、自動化されていない手作業など
- 材料（Material）：元になる情報やインプットの欠け、前工程からの受け渡し不足など
事務やデスクワークの問題に使うときは、この4Mを「人・仕組み・ツール・情報」のように読み替えても構いません。大切なのは、原因を思いつき順に並べるのではなく、いくつかの視点で分けてから掘り下げることです。視点を分けておくと、特定のカテゴリだけ原因が空っぽになっていることに気づけ、見落としていた領域が浮かび上がります。
💡 洗い出した原因を「動ける対策タスク」に変えたい方へ
このページ下部の体験フォームで、対策にしたい原因を入れるだけでAIが「今日動ける最初の一歩」まで分解します。図で終わらせず、実行に移せます。登録不要・無料です。
特性要因図でつまずく3つの失敗パターン【開発者視点】
ここからが本記事の核心です。AIタスク管理アプリ「するたす」を開発する立場から、ユーザーが「整理したのに動けない」と感じる場面を分析する中で見えてきた、この図がうまく機能しなくなる典型的な3つのパターンを率直に整理します。いずれも図の描き方そのものより、その前後の扱い方の問題です。
失敗パターン1：特性（結果）が大きく曖昧なまま描き始める
魚の頭に置く特性が「業務がうまくいかない」のように大きすぎると、そこから伸びる原因もぼんやりした抽象論ばかりになります。「コミュニケーション不足」「意識の問題」といった、誰も具体的に手を打てない大骨だけが並ぶ図になりがちです。
この図は、特性を絞れば絞るほど原因も具体的になります。「業務がうまくいかない」ではなく「請求書の送付ミスが月に数件起きる」のように、結果を一点に定めてから描くことが先決です。問題を一段ずつ具体化していく考え方は「ロジックツリーの作り方」が参考になります。
失敗パターン2：原因を挙げただけで真因まで掘り下げない
大骨・中骨まで書いて満足し、そこで止まってしまうケースです。「確認漏れ」という中骨を挙げても、なぜ確認が漏れるのか――手順書がない、チェック欄がない、急かされて飛ばす――という小骨まで降りなければ、対策の打ちようがありません。表面的な原因に対策しても、真因が残っていればまた再発します。
この「掘り下げ不足」は、図がきれいに見えるほど起こりやすいという厄介さがあります。大骨・中骨が整然と並ぶと、それだけで十分に分析した気分になり、そこで手が止まる。けれど本当に対策できる粒度は、もう一段か二段下の小骨にあります。枝の数ではなく、各枝がどこまで具体的な行動に落とせる深さまで降りているかが、分析の質を決めます。形を整えることと、真因に届くことは別物だと意識しておくと、途中で満足せずに済みます。
ここで相性が良いのが、ひとつの原因を「なぜ？」で繰り返し掘り下げる手法です。特性要因図で原因の全体像を横に広げ、気になる枝をなぜなぜ分析で縦に深掘りする。横の広がりと縦の深さを補い合わせると、真因にぐっと近づけます。この2つは競合する手法ではなく、相補的に使うのが王道です。
失敗パターン3：図を描いて終わり、対策タスクに落ちない
これが最も多く、最ももったいないパターンです。きれいな図ができあがると、それだけで問題を解決した気分になります。けれど図は原因を見える化しただけで、現実は何も変わっていません。「どの原因に、いつ、何をするか」という具体的な行動に落ちて初めて、問題は動き始めます。
厄介なのは、対策にすべき原因ほど「手順を整える」「仕組みを作る」のように大きく曖昧な行動になりやすいことです。大きく曖昧なタスクは着手のハードルが高く、結局あと回しになります。せっかく真因を突き止めても、対策が動かなければ図は飾りで終わります。原因が繰り返しミスを生む構造については「仕事のミスが多い原因」でも詳しく扱っています。
この3つに共通するのは、いずれも「分析」と「実行」の間に断絶があるという一点です。この図は原因を整理する強力な手法ですが、それだけでは行動になりません。図を実行につなぐ最後の一歩が抜けると、せっかくの分析が成果に変わらないのです。
使える特性要因図にするための設計原則
では、どう描けばこの図は実際に効くのか。形だけ整えた図と、真因にたどり着き対策まで動く図とでは、得られる成果がまったく変わります。まずは両者の違いを整理します。
飾りの図 vs 動く図の比較
| 観点 | 飾りの特性要因図 | 動く特性要因図 |
|---|---|---|
| 特性（結果） | 「うまくいかない」と大雑把 | 一点に絞った具体的な結果 |
| 原因の出し方 | 思いつき順に並べる | カテゴリで分けて抜け漏れを防ぐ |
| 掘り下げ | 大骨・中骨で止まる | 小骨＝真因まで降りる |
| 分析後の扱い | 図を描いて満足する | 対策する原因を絞り込む |
| 行動への接続 | 図のまま放置される | 動ける対策タスクに落とす |
違いは明確です。使える特性要因図にするには、原因を網羅するだけで満足せず、真因を絞り込み、そこから対策の行動までを一本の流れにつなぐことです。
設計原則1：特性を一点に絞ってから原因を広げる
魚の頭に置く結果は、できるだけ具体的に一点へ絞ります。「ミスが多い」ではなく「どの作業で・どんなミスが・どのくらい起きるか」まで言い切る。特性が具体的になるほど、そこから伸びる原因も具体的になり、対策に直結する小骨が出やすくなります。図の精度は、最初の特性の絞り込みでほぼ決まります。
設計原則2：横の広がりと縦の深さを両方確保する
この図の強みは、原因を横へ網羅的に広げられることです。一方で、一つの原因を深く掘る力は弱い。そこを補うのがなぜなぜ分析です。まず原因のカテゴリを横に広げて全体像をつかみ、影響が大きそうな枝を選んで「なぜ？」を繰り返し縦に掘る。横の網羅と縦の深掘りを組み合わせると、見落としと浅さの両方を防げます。2つの手法は相補的だと覚えておくと使い分けが楽になります。
設計原則3：対策する原因を絞り、行動に変換する
洗い出した原因すべてに同時に手を打つことはできません。影響が大きく、自分でコントロールできる原因から優先して選びます。そして選んだ原因を「何をするか」という行動の言葉に置き換える。ここで原因が大きく曖昧なままだと着手できないので、「今日できる最初の一歩」まで割っておくことが、図を実行に変える鍵になります。分析・整理は人間が行い、その後の実行＝タスク分解をAIに手伝わせる、という役割分担にすると摩擦が一気に減ります。
🎯 図で終わらせず「動ける対策」にするのが「するたす」です
- ✅ 入力は対策したい原因だけ → AIが今日動ける小ステップに自動分解
- ✅ 分析は人・実行はAIが補助 → 図と行動の断絶をなくす
- ✅ 今日やる最初の一歩に絞れる → 大きく曖昧な対策で止まらない
※登録不要で体験フォームが使えます
📱 PCの方はスマホで読み取り
特性要因図を実務で使いこなす実践ステップ
設計原則を、今日から回せる手順に落とします。難しい道具は要りません。紙とペン、あるいはホワイトボードがあれば描けます。順番に並べるだけで、この図が分析で終わらず行動に変わります。
- 特性（なくしたい結果）を一点に絞って書く：魚の頭に、具体的な結果を一文で置く。
- 原因のカテゴリ（大骨）を立てる：人・方法・設備・材料など、視点を分けて抜け漏れを防ぐ。
- 各カテゴリに中骨・小骨を書き出す：気になる枝はなぜなぜ分析で真因まで深掘りする。
- 対策する原因を絞り、行動に変える：影響が大きく動かせるものを選び、今日できる一歩まで割る。
この4ステップのうち、多くの人が止まるのは4の「行動に変える」工程です。原因の整理までは進むのに、対策が大きく曖昧なまま放置される。この図を成果に変える分かれ目は、ここで対策を動ける粒度まで分解できるかどうかにあります。面倒な分解をAIに任せると、図から実行への橋渡しが軽くなります。
原因を上から枝分かれで構造化する考え方は「ロジックツリーの作り方」、原因を縦に深掘りする手法は「なぜなぜ分析とは」で扱っています。これらと組み合わせると一段と強力になります。
特性要因図に関するよくある質問（FAQ）
Q1. 特性要因図とフィッシュボーン図は違うものですか？
同じものです。特性要因図は、原因を魚の骨のように枝分かれさせて整理する図で、その見た目から別名フィッシュボーン図（魚の骨の図）と呼ばれます。英語のfishbone diagramや、考案者の名前にちなんだ呼び方もありますが、いずれも指している図は同じです。
Q2. 特性要因図となぜなぜ分析はどう使い分けますか？
2つは競合ではなく相補的です。特性要因図は原因を横に広げて全体像を網羅するのが得意で、なぜなぜ分析は一つの原因を縦に深く掘るのが得意です。まずこの図でカテゴリごとに原因を広げ、影響が大きそうな枝をなぜなぜ分析で真因まで掘る、という組み合わせが王道です。
Q3. 原因のカテゴリ（大骨）は何を立てればいいですか？
製造現場では「人・方法・設備・材料」の4Mがよく使われます。事務やデスクワークの問題なら「人・仕組み・ツール・情報」のように読み替えても構いません。大切なのは固定のカテゴリ名ではなく、複数の視点で分けてから原因を掘ること。視点を分けると、原因が空っぽのカテゴリに気づき、見落としを防げます。
Q4. 図を描いても問題が解決しないのはなぜ？
図を描いた段階では原因が見える化されただけで、現実はまだ何も変わっていないからです。解決には、対策する原因を絞り込み、「いつ・何をするか」という具体的な行動に落とす必要があります。対策が大きく曖昧なまま放置されると図は飾りで終わります。今日できる最初の一歩まで割るのが、図を成果に変える鍵です。
Q5. AIは特性要因図の作成に使えますか？
原因を分析・整理する判断そのものは人間が行うのが基本です。どの原因が真因かを見極めるのは現場を知る人にしかできません。一方で、洗い出した原因を「動ける対策タスク」に変える工程はAIが手伝えます。対策にしたい原因を入れれば、今日できる小ステップに分解してくれるので、図と実行の断絶を埋める道具として使うのが現実的です。
まとめ：特性要因図は「原因の網羅」から「対策の実行」へ
- 特性要因図とは、結果（特性）に対する原因（要因）を魚の骨の形で枝分かれさせ、抜け漏れなく整理する図。別名フィッシュボーン図
- 原因は思いつき順でなく「人・方法・設備・材料」などのカテゴリで分けると見落としが減る
- つまずきは 特性が曖昧・真因まで掘らない・図で満足して対策しない の3つ
- 横に広げる特性要因図と縦に掘るなぜなぜ分析は相補的。組み合わせると真因に近づく
- 最後は対策する原因を絞り、今日できる一歩まで割って実行に変えることで成果が出る
🚀 「するたす」を無料で試す
特性要因図で洗い出した原因を、動ける対策へ。原因を入れるだけで、AIが今日できる最初の一歩まで自動分解します。
📱 PCの方はスマホで
この記事をシェア：
著者：藤岡 拓也（Takuya Fujioka）
AIタスク管理アプリ「するたす」開発者・運営者
タスク分解の”摩擦”をゼロにすることをテーマに、プロダクトを日々磨いています。
