「なぜ問題が起きたのかわからない」
仕事をしていると、このような場面は多くあります。
- システム障害が発生する
- 工程遅延が起きる
- 品質が安定しない
- 開発が思った通りに進まない
このような問題に対して、感覚だけで原因を考えると、本当の原因を見逃してしまいます。
そこで役立つのが「特性要因図」です。
特性要因図を使うと、問題の原因を体系的に整理できます。
この記事では、特性要因図の基本から、IT業界・EPC・新規開発での原因カテゴリの考え方までを、初心者向けにわかりやすく解説します。
特性要因図とは「問題の原因を整理する図」
特性要因図とは、問題の原因を整理するための図です。
魚の骨のような形をしているため、「フィッシュボーン図」と呼ばれます。
特性要因図のイメージ
| 原因カテゴリ | 具体例 |
|---|---|
| 人 | 経験不足、確認漏れ |
| 方法 | 手順不足、レビュー不足 |
| 設備 | ツール不具合、設備故障 |
| 環境 | スケジュール逼迫、作業環境悪化 |
人 ─────┐
方法 ────┤
設備 ────┤── 問題
環境 ────┘右側に問題を書きます。
左側に原因を書きます。
そして、「どのような原因が問題につながったのか」を整理していきます。
特性要因図が重要なのは「真因を見つけやすい」から
問題は、1つの原因だけで発生するとは限りません。
納期遅延の例
- 担当者の経験不足
- レビュー不足
- 仕様変更
- 設備トラブル
- コミュニケーション不足
このように、複数の原因が重なっている場合があります。
特性要因図を使うと、原因を漏れなく整理できます。
原因カテゴリは業界によって変えるべき
特性要因図では、「原因カテゴリ」の設定が非常に重要です。
カテゴリが合っていないと、原因分析が浅くなります。
業界別の特徴
| 業界 | 重視するポイント |
|---|---|
| IT | 要件、システム、マネジメント |
| EPC | 工程間連携、調達、建設 |
| 新規開発 | 不確実性、技術リスク |
品質管理でよく使われる基本カテゴリは4M
まず、基本となる考え方が「4M」です。
4M一覧
| 分類 | 意味 | 具体例 |
|---|---|---|
| Man | 人 | 教育不足、確認漏れ |
| Machine | 機械 | 設備故障、ツール不備 |
| Method | 方法 | レビュー不足、手順不備 |
| Material | 材料 | 部材不良、データ品質不良 |
IT業界で使いやすい原因カテゴリ
IT業界向けカテゴリ例
| カテゴリ | 具体例 |
|---|---|
| 人 | 経験不足、認識齟齬 |
| プロセス | テスト不足、手順未整備 |
| システム | ツール不備、性能問題 |
| 要件 | 要件定義不足、仕様変更 |
| マネジメント | リソース不足、リスク管理不足 |
IT業界の特性要因図イメージ
人 ─────────┐
プロセス ──────┤
システム ──────┤── 障害発生
要件 ────────┤
マネジメント ────┘EPCで重要なのは「工程間のつながり」
EPCでは、設計・調達・建設が連携して進みます。
EPCとは
| 略称 | 意味 |
|---|---|
| Engineering | 設計 |
| Procurement | 調達 |
| Construction | 建設 |
EPC向けカテゴリ例
| カテゴリ | 具体例 |
|---|---|
| 設計 | 設計変更、図面レビュー不足 |
| 調達 | 納期遅延、部材不足 |
| 建設 | 現場調整不足、安全管理不足 |
| インターフェース | 部門間連携不足、情報伝達漏れ |
| マネジメント | 工程管理不足、要員不足 |
EPCの特性要因図イメージ
設計 ─────────┐
調達 ─────────┤
建設 ─────────┤── 工程遅延
インターフェース ───┤
マネジメント ─────┘新規開発では「不確実性」を考慮する
新規開発では、過去事例が少ない場合があります。
そのため、「未知のリスク」が発生しやすくなります。
新規開発向けカテゴリ例
| カテゴリ | 具体例 |
|---|---|
| 技術 | 技術成熟度不足、検証不足 |
| 要件 | 要件未確定、要求変更 |
| 組織 | 意思決定遅延、部門調整不足 |
| リスク | 市場変化、法規制変更 |
| スケジュール | 試験期間不足、バッファ不足 |
新規開発の特性要因図イメージ
技術 ─────────┐
要件 ─────────┤
組織 ─────────┤── 品質問題
リスク ────────┤
スケジュール ─────┘カテゴリは「分析しやすさ」で決める
カテゴリに正解はありません。
大切なのは、「原因を整理しやすいか」です。
カテゴリ設定の考え方
- ITなら「要件」を重視する
- EPCなら「インターフェース」を重視する
- 新規開発なら「不確実性」を重視する
特性要因図は「チームで作る」と効果が高い
特性要因図は、1人で作るよりもチームで作るほうが効果的です。
参加メンバー例
現場側
- 現場担当者
- 設計担当
- 開発担当
管理側
- 管理者
- 品質担当
- PM
立場によって見える問題が異なるため、多面的な分析が可能になります。
まとめ
特性要因図は、問題の原因を整理するための強力なツールです。
この記事のポイント
| 業界 | 重要カテゴリ |
|---|---|
| IT | 要件、システム、マネジメント |
| EPC | 設計、調達、建設、インターフェース |
| 新規開発 | 技術、不確実性、リスク |
特性要因図は、ただの図ではありません。
「問題を構造的に考える力」を鍛えるツールです。
ぜひ、自分の業界に合ったカテゴリを考えながら活用してみてください。
これはCTAサンプルです。
内容を編集するか削除してください。
