「対策したはずなのに、また同じ問題が起きた。」

このような経験は、プロジェクトで珍しくありません。

その原因は、表面的な問題だけを修正し、本当の原因までたどり着けていないことが多いためです。

そこで活用されるのが根本原因分析（Root Cause Analysis：RCA）です。

この記事では、根本原因分析の意味や代表的な分析手法、実務での活用方法までわかりやすく解説します。

一言でいうと

根本原因分析とは、「問題の本当の原因を特定し、再発を防止するための分析手法」です。

根本原因分析とは

根本原因分析（Root Cause Analysis：RCA）とは、不具合やトラブルが発生した原因を深く掘り下げ、再発防止につながる本当の原因を特定するための分析手法です。

単に「何が起きたか」を調べるだけではなく、「なぜ起きたのか」を繰り返し考えることが特徴です。

PMBOK®では、品質マネジメントやリスクマネジメントにおいて活用される代表的な分析手法の一つです。

根本原因分析が重要な理由

表面的な原因だけを修正すると、同じ問題が繰り返し発生する可能性があります。

例えば、「テストで不具合が見つかったから修正した」という対応だけでは、不具合が発生した原因は解決されていません。

設計レビューの不足や要求事項の曖昧さなど、本当の原因まで分析することで、再発防止につながります。

代表的な分析手法

プロジェクトでは、問題の内容に応じて適切な分析手法を選択します。

実務ではこんな場面で活用される

例えば、システム障害が発生した場合を考えてみましょう。

表面的な原因は「プログラムのミス」かもしれません。

しかし、「なぜそのミスが発生したのか」を分析すると、次のような原因が見えてくることがあります。

• レビューが十分に実施されていなかった
• 要求事項が曖昧だった
• テストケースが不足していた
• 開発スケジュールが過密だった

このように、本当の原因を特定することで、プロセスそのものを改善できます。

なぜなぜ分析（5 Whys）の例

問題：本番環境でシステム障害が発生した。

1. なぜ？ → テストで不具合を見逃した。
2. なぜ？ → テストケースが不足していた。
3. なぜ？ → 要件変更が反映されていなかった。
4. なぜ？ → 変更要求の共有が不十分だった。
5. なぜ？ → 変更管理プロセスが整備されていなかった。

この場合、本当の原因は「変更管理プロセスの不足」であり、テストケースを増やすだけでは再発防止になりません。

よくある勘違い

担当者を責めることが目的ではない

根本原因分析は、「誰が悪かったか」を追及する活動ではありません。

プロセスや仕組みに改善点がないかを分析し、再発防止につなげることが目的です。

「なぜ？」を無理に5回繰り返せば良いわけではない

5 Whysは代表的な手法ですが、必ず5回質問することが目的ではありません。

本当の原因にたどり着いた時点で分析を終了します。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、不具合や障害が発生した際に、「どのように原因を分析し、再発防止策を実施したか」が問われることがあります。

午後試験では、「根本原因分析を実施し、レビュー手順を改善した」「変更管理プロセスを見直した」といった具体的な改善策を説明できると評価につながります。

重要なのは、不具合を修正したことではなく、同じ問題を繰り返さない仕組みを作ることです。

PM道場のワンポイント

根本原因分析で本当に改善したいのは、「人」ではなく「仕組み」です。

実務では、「担当者が確認不足だった」という結論で終わってしまうことがあります。

しかし、それでは次回も同じことが起こる可能性があります。

「レビュー時間が確保できなかった」「変更管理が機能していなかった」「チェックリストが存在しなかった」など、仕組みの改善まで踏み込むことが重要です。

優れたプロジェクトマネージャは、不具合を責任追及の材料ではなく、「プロジェクトを成長させる教材」として活用しています。

関連用語

• 不具合（Defect）
• 品質管理（Quality Control）
• 品質保証（Quality Assurance）
• 品質メトリクス
• レビュー
• 教訓（Lessons Learned）
• 変更要求
• 継続的改善

まとめ

根本原因分析とは、問題の本当の原因を特定し、再発防止につなげるための分析手法です。

表面的な問題だけではなく、その背景にあるプロセスや仕組みまで分析することで、継続的な品質向上につながります。

重要なのは、「誰が悪いか」を考えることではなく、「どうすれば同じ問題を繰り返さないか」を考えることです。

関連記事

• 不具合とは？
• 教訓（Lessons Learned）とは？
• 品質管理とは？
• 変更要求とは？

よくある質問（FAQ）

Q. 根本原因分析とは何ですか？

A. 問題の本当の原因を特定し、再発防止につなげるための分析手法です。

Q. なぜなぜ分析（5 Whys）とは何ですか？

A. 「なぜ？」を繰り返し問いかけることで、表面的な原因ではなく、本当の原因を探る分析手法です。

Q. 根本原因分析の目的は担当者を特定することですか？

A. いいえ。目的は責任追及ではなく、プロセスや仕組みを改善し、同じ問題の再発を防ぐことです。

The post 根本原因分析（Root Cause Analysis：RCA）とは？目的や手法を初心者向けにわかりやすく解説 first appeared on PM道場.

「この要求事項は、本当にテストまで確認できているのか？」

プロジェクトが大きくなるほど、このような確認は難しくなります。

要求事項と設計・開発・テストが正しく結び付いていなければ、必要な機能が実装されなかったり、不要な機能を開発してしまったりする可能性があります。

そこで活用されるのが要求事項トレーサビリティマトリクス（Requirements Traceability Matrix：RTM）です。

この記事では、RTMの意味や目的、実務での活用方法までわかりやすく解説します。

一言でいうと

要求事項トレーサビリティマトリクス（RTM）とは、「要求事項が設計・開発・テストまで適切に反映されているかを追跡（トレース）するための管理表」です。

要求事項トレーサビリティマトリクス（RTM）とは

RTM（Requirements Traceability Matrix）は、要求事項と成果物との対応関係を管理するための一覧表です。

要求事項ごとに設計書・WBS・プログラム・テストケースなどを紐付けることで、「要求事項が最後まで実現されているか」を確認できます。

PMBOK®でも、要求事項をライフサイクル全体を通じて管理するための重要な成果物として位置付けられています。

RTMのイメージ

このように、要求事項から成果物までを一貫して追跡できるように管理します。

RTMを作成する目的

• 要求事項の漏れを防ぐ
• 不要な機能の開発を防ぐ
• 変更時の影響範囲を把握しやすくする
• テスト漏れを防ぐ
• 要求事項と成果物の整合性を確認する

つまり、「要求事項が確実に成果物へ反映されていること」を保証するための仕組みです。

実務ではこんな場面で活用される

例えば、顧客から「CSV出力機能を追加してほしい」という要求事項が追加されたとします。

RTMがあれば、その要求事項に対応する設計書、プログラム、テストケースをすぐに確認できます。

また、仕様変更が発生した場合も、影響を受ける成果物を素早く特定できるため、変更漏れを防ぐことができます。

RTMを作成するメリット

• 要求事項の実装漏れを防げる
• 変更時の影響分析がしやすい
• レビューの効率が向上する
• テストの網羅性を確認できる
• 品質向上につながる

よくある勘違い

RTMはテスト担当者だけが使うものではない

RTMは、要件定義から設計・開発・テストまで、プロジェクト全体で利用する管理資料です。

プロジェクトマネージャも変更管理や進捗管理で活用します。

RTMは一度作成したら終わりではない

要求事項が変更された場合は、RTMも更新する必要があります。

最新状態を維持することで、トレーサビリティが保たれます。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、「要求事項の管理」や「変更管理」「品質管理」と関連付けて理解することが重要です。

午後試験では、「要求事項が確実に成果物へ反映されていることをどのように確認したか」を説明できると評価につながります。

RTMは単なる一覧表ではなく、品質保証と変更管理を支える重要な管理ツールです。

PM道場のワンポイント

RTMは、「要求事項を管理する表」ではなく、「約束を守るための地図」です。プロジェクトでは、要求事項が増えるほど、「この機能は何のために作ったのか」が分からなくなることがあります。逆に、「要求したはずなのに実装されていない」という事態も起こります。

RTMがあれば、要求事項から設計・開発・テストまで一本の線で追跡できます。

優れたプロジェクトマネージャは、RTMを単なる成果物として作るのではなく、「変更時の影響分析」や「レビュー」で積極的に活用しています。

RTMは、要求事項を見える化するだけでなく、プロジェクト全体の品質を見える化するためのツールでもあるのです。

関連用語

• 要求事項
• スコープ
• スコープマネジメント
• 変更管理
• 品質管理
• WBS
• 成果物（Deliverable）
• テストケース

まとめ

要求事項トレーサビリティマトリクス（RTM）とは、要求事項が設計・開発・テストまで適切に反映されていることを追跡・管理するための管理表です。

要求事項と成果物を紐付けることで、実装漏れやテスト漏れを防ぎ、変更時の影響分析も容易になります。

重要なのは、RTMを「作ること」ではなく、「常に最新の状態に保ち、プロジェクト全体で活用すること」です。

関連記事

• 要求事項とは？
• スコープとは？
• 変更管理とは？
• 品質管理とは？

よくある質問（FAQ）

Q. 要求事項トレーサビリティマトリクス（RTM）とは何ですか？

A. 要求事項と設計・開発・テストなどの成果物を関連付け、要求事項が確実に実現されていることを追跡・管理するための管理表です。

Q. RTMを作成する目的は何ですか？

A. 要求事項の実装漏れやテスト漏れを防ぎ、変更時の影響範囲を把握しやすくすることです。

Q. RTMはどの工程で利用しますか？

A. 要件定義だけでなく、設計・開発・テスト・変更管理まで、プロジェクト全体を通じて活用されます。

The post 要求事項トレーサビリティマトリクス（RTM）とは？目的や使い方を初心者向けにわかりやすく解説 first appeared on PM道場.

「作業の流れや判断の分岐をチーム内で共有したい」

プロジェクトを進めていると、このような場面があります。

複雑な作業や業務の順番を文章だけで説明しようとすると、認識のズレが発生したり、全体の流れが伝わりにくかったりすることがあります。

このように、作業や処理の手順を記号と矢印を使って視覚的に表現した図がフローチャートです。

フローチャートを作成することで、業務の流れを一目で理解できるようになり、プロジェクトの標準化や業務改善にも役立ちます。

一言でいうと

フローチャートとは、作業や処理の流れを図で見える化したものです。

作業を順番に並べ、矢印でつなぎ、必要に応じて判断や分岐を加えることで、業務全体の流れを視覚的に表現します。

例えば、システムの処理であれば、

「データを受信する」

↓

「データをチェックする」

↓

「問題がなければ登録する」

という流れを図として表現できます。

文章だけで説明するよりも、どの作業がどの順番で行われ、どこで判断が分かれるのかを理解しやすくなります。

フローチャートとは

フローチャートは、英語のFlowchartに由来する言葉です。

「Flow」は流れ、「Chart」は図表を意味します。

つまり、フローチャートは「流れを図にしたもの」と考えることができます。

業務手順、システム処理、意思決定、障害対応など、さまざまな場面で利用できます。

例えば、業務の流れを文章だけで説明すると、

• 申請書を作成する
• 上司に提出する
• 上司が内容を確認する
• 問題がなければ承認する
• 問題があれば申請者に戻す

という説明になります。

これをフローチャートにすると、作業の順番や「承認されたか？」という判断による分岐を一目で確認できます。

フローチャートを使うメリット

業務の全体像を理解しやすくなる

複雑な業務でも、作業を順番に並べて図にすることで、全体の流れを把握しやすくなります。

特に、新しくプロジェクトに参加したメンバーや新人に業務を説明するときに役立ちます。

認識の違いを発見できる

同じ業務を担当していても、人によって作業の順番や判断方法が異なることがあります。

フローチャートを作成して関係者で確認することで、

• 作業の順番が違う
• 判断条件の認識が違う
• 担当者の認識が違う
• 作業が抜けている

といった認識の違いを発見できます。

業務上の問題を発見しやすくなる

業務を図にすると、文章では気づきにくかった問題が見えてくることがあります。

• 同じ作業を何度も行っている
• 不要な承認が存在する
• 作業が特定の担当者に集中している
• 待ち時間が長い
• 手作業が多い

このような問題を発見することで、業務改善につなげることができます。

フローチャートの基本記号

フローチャートでは、目的に応じてさまざまな記号を使用します。

まずは、基本的な記号を覚えておけば十分です。

開始・終了

処理の開始や終了を表します。

例えば、

• 業務開始
• 処理開始
• 処理終了

などを表現します。

処理

実際に行う作業や処理を表します。

例えば、

• データを入力する
• 申請書を作成する
• メールを送信する
• データを登録する

などです。

判断

条件によって処理が分岐することを表します。

例えば、

• 承認されたか？
• エラーが発生したか？
• 条件を満たしているか？

などです。

「YES」「NO」などの条件によって、異なる処理へ進みます。

矢印

処理が進む方向や順番を表します。

フローチャートでは、基本的に上から下、または左から右へ流れるようにすると、読みやすくなります。

フローチャートの書き方

フローチャートを作るときは、いきなり図を描き始めるのではなく、まず何を整理したいのかを明確にします。

ステップ1：目的を決める

最初に、何のためにフローチャートを作るのかを決めます。

例えば、

• 業務手順を整理する
• 新人に業務を説明する
• システム処理を整理する
• 障害の原因を分析する
• 業務改善のポイントを探す

などです。

目的によって、必要な情報の細かさも変わります。

ステップ2：作業を洗い出す

次に、対象となる業務で実際に行われている作業を洗い出します。

例えば、申請業務なら、

• 申請書を作成
• 申請
• 上司が確認
• 承認
• 申請者へ通知

などを洗い出します。

ステップ3：作業を順番に並べる

洗い出した作業を、実際に行われる順番に並べます。

ここで重要なのは、「本来どうあるべきか」ではなく「実際にはどう行われているか」を確認することです。

特にトラブルの原因分析では、この点が重要になります。

ステップ4：判断や分岐を整理する

途中で判断が発生する場合は、分岐として整理します。

例えば、

「承認されたか？」

という判断がある場合、

• YES → 次の処理へ進む
• NO → 申請者へ差し戻す

というように整理します。

ステップ5：矢印でつなぐ

作業と判断を矢印でつなぎ、業務の流れを完成させます。

矢印が複雑に交差すると読みにくくなるため、できるだけ自然な方向に流れるように配置することがポイントです。

ステップ6：関係者に確認する

最後に、実際の業務を知っている関係者に確認してもらいます。

特に、フローチャートを原因分析に利用する場合は、現場担当者の確認が重要です。

作成者が知らない例外処理やイレギュラーな運用が存在する可能性があるからです。

フローチャートを原因分析に活用する

フローチャートは、トラブルや障害の原因分析にも活用できます。

トラブルが発生したとき、関係者から話を聞くだけでは、

• 記憶が曖昧
• 認識が違う
• 思い込みで判断する
• 人の責任にしてしまう

といった問題が起こることがあります。

そこで、実際に行われた処理をフローチャートにして整理します。

すると、「どの処理で正常な流れから外れたのか」を確認しやすくなります。

正常時と異常時を比較する

例えば、システムの正常な処理が、

• データ受信
• データチェック
• データベース登録
• 完了通知

だったとします。

一方、障害発生時には、

• データ受信
• データチェック
• エラー発生
• 処理停止

となっていたとします。

これをフローチャートで比較すると、データチェックの後に正常な処理から外れていることが分かります。

さらに調査すると、特定のデータ形式でエラーが発生していた、といった原因につながる可能性があります。

このようにフローチャートは、事実に基づいて問題が発生した場所を整理するための道具として活用できます。

フローチャートと根本原因分析

フローチャートは、根本原因分析を行う際にも役立ちます。

ただし、フローチャートだけで根本原因が自動的に分かるわけではありません。

フローチャートによって、

• どこで問題が発生したのか
• 正常時と何が違うのか
• どの判断が分岐点になったのか
• どこに追加調査が必要なのか

を整理し、その後になぜその問題が発生したのかを掘り下げます。

例えば、「データチェックでエラーが発生した」ことが分かったとしても、それだけでは根本原因とは限りません。

さらに、

「なぜそのデータが入力されたのか」

「なぜチェックで検出できなかったのか」

「なぜその運用になっていたのか」

などを掘り下げる必要があります。

このように、フローチャートは原因分析の入口として非常に有効なツールです。

フローチャートを業務改善に活用する

フローチャートを作成すると、現在の業務の問題点が見えることがあります。

例えば、

• 同じ情報を複数回入力している
• 不要な承認を行っている
• 担当者間の待ち時間が長い
• 手作業が多い
• 同じ確認を複数人が行っている

といった問題です。

こうした問題を発見したら、

• 作業を削減する
• 作業を自動化する
• 承認プロセスを変更する
• 担当者を変更する
• チェック方法を変更する

などの改善策を検討できます。

つまり、

業務を見える化する → 問題を発見する → 改善する

という流れを作ることができます。

フローチャート作成でよくある失敗

情報を詰め込みすぎる

一つのフローチャートにすべての情報を入れようとすると、複雑になってしまいます。

必要に応じて、全体フローと詳細フローを分けると分かりやすくなります。

「あるべき姿」を書いてしまう

特に原因分析では注意が必要です。

「本来はこの手順で処理するはずだ」という理想の流れを書いてしまうと、実際に何が起きたのかが分からなくなります。

原因分析では、実際に行われた処理を事実として整理することが重要です。

判断条件が曖昧

「確認する」「チェックする」だけでは、何を基準に判断したのか分かりません。

「金額が100万円以上か？」など、できるだけ具体的な判断条件を記載しましょう。

矢印が複雑に交差する

矢印があちこちに交差すると、処理の流れが分かりにくくなります。

基本的には、上から下、または左から右に流れるように配置すると読みやすくなります。

フローチャートを作成するときのポイント

目的に合わせて細かさを変える

新人教育のためのフローチャートと、システム障害の原因分析に使うフローチャートでは、必要な細かさが異なります。

目的に応じて情報量を調整しましょう。

関係者と一緒に作る

フローチャートは一人で完成させるより、実際の業務担当者と確認しながら作る方が正確になります。

特に、例外処理やイレギュラーな運用は、現場担当者でなければ分からないことがあります。

「実際」と「あるべき」を分ける

業務改善では、「現在の業務フロー」と「改善後の業務フロー」を分けて作ると効果的です。

現在の流れを正確に把握したうえで、改善後の流れを検討することが重要です。

プロジェクトマネジメントでの活用例

プロジェクトマネジメントでは、フローチャートをさまざまな場面で利用できます。

プロジェクトマネージャ試験ではここが重要

フローチャートについては、単に「業務の流れを図にするもの」と暗記するだけではなく、何のために使うのかを理解しておきましょう。

特に重要なのは、

• 業務や処理の流れを可視化する
• 処理の順番や判断を整理する
• 関係者間の認識を合わせる
• 問題が発生した箇所を特定する
• 業務改善につなげる

という使い方です。

また、障害やトラブルの原因分析では、「本来どうだったか」ではなく「実際にどうだったか」を整理することが重要です。

事実を整理したうえで、正常時との差異を確認すると、問題が発生したポイントを特定しやすくなります。

PM道場のワンポイント

フローチャートは「説明するための図」だけではなく、「考えるための図」として使うと非常に便利です。

例えば、トラブルが発生したとき、いきなり「原因は何だろう？」と考えると、関係者の記憶や思い込みに引っ張られてしまうことがあります。

そんなときは、まず、

「実際には、何がどの順番で起きたのか？」

をフローチャートにしてみます。

すると、

• 正常な流れから外れた場所
• 判断が分かれた場所
• 想定外の処理が行われた場所
• 確認が不足していた場所

などが見えてきます。

そこから「なぜ？」を掘り下げていけば、根本原因分析につなげることができます。

つまり、フローチャートは「流れを描くための図」ではなく、「事実を整理して問題を発見するための道具」として活用できます。

関連用語

• 根本原因分析
• 不具合
• インシデント
• 継続的改善
• 品質管理
• レビュー
• プロセス
• 業務改善
• 意思決定
• プロトタイプ

まとめ

フローチャートとは、作業や処理の流れを図として見える化する方法です。

基本的には、処理を順番に並べ、矢印でつなぎ、必要に応じて判断や分岐を加えて作成します。

フローチャートを活用することで、

• 業務の全体像を理解しやすくなる
• 関係者間の認識を合わせられる
• 業務上の問題を発見できる
• トラブルの原因を整理できる
• 業務改善につなげられる

といったメリットがあります。

特にプロジェクトマネジメントでは、トラブルや障害が発生したときに、実際に何が起きたのかを事実ベースで整理するための道具として有効です。

ただし、原因分析を行う場合は「あるべき姿」ではなく「実際の流れ」を整理することが重要です。

フローチャートを使って流れを見える化し、問題が発生した箇所を特定したうえで、さらに「なぜ？」を掘り下げていくことで、根本原因の特定や再発防止につなげることができます。

フローチャートは、業務を説明するためだけではなく、業務や問題を整理し、改善するための重要なプロジェクトマネジメントツールです。

関連記事

• 根本原因分析とは？
• 不具合とは？
• インシデントとは？
• 継続的改善とは？
• 品質管理とは？
• レビューとは？
• 意思決定とは？
• プロセスとは？

よくある質問（FAQ）

Q. フローチャートとは何ですか？

A. フローチャートとは、作業や処理の流れを図として表現したものです。作業の順番や判断、分岐などを視覚的に整理できます。

Q. フローチャートは何のために使いますか？

A. 業務の流れを整理したり、関係者間の認識を合わせたり、業務改善やトラブルの原因分析を行ったりするために使います。

Q. フローチャートの基本的な記号には何がありますか？

A. 開始・終了、処理、判断、矢印などの記号があります。まずはこれらの基本記号を理解しておけば、一般的な業務フローを作成できます。

Q. フローチャートは原因分析に使えますか？

A. はい。トラブル発生時の実際の処理の流れをフローチャートにすることで、正常時との違いや問題が発生した箇所を整理できます。ただし、フローチャートだけで根本原因が分かるわけではなく、その後に原因を掘り下げる必要があります。

Q. 原因分析では「あるべき流れ」を書けばよいですか？

A. いいえ。原因分析では、まず「実際にどう処理されたのか」を整理することが重要です。理想的な流れを書いてしまうと、実際に発生した問題を見つけられなくなる可能性があります。

Q. フローチャートを作るときのポイントは何ですか？

A. まず目的を明確にし、実際の作業を洗い出して順番に並べます。その後、判断や分岐を整理して矢印でつなぎ、最後に関係者と内容を確認することが重要です。

The post フローチャートとは？基本記号の意味やわかりやすい書き方を解説 first appeared on PM道場.

「不具合の原因がいくつもあるが、優先順位をつけたい」

このようなときに役立つのがパレート図です。

パレート図とは、発生した問題や原因を多い順に並べ、それぞれの割合や累積割合を示したグラフです。

問題を「多いものから順番に並べる」ことで、どの問題に優先して取り組むべきなのかを視覚的に把握できます。

特に品質管理や問題分析では、限られた時間やリソースを影響の大きな問題に集中させるために活用されます。

一言でいうと

パレート図とは、「問題や原因を多い順に並べ、重要な問題がどれなのかを見える化する図」です。

棒グラフと累積比率を示す折れ線グラフを組み合わせて表示することが一般的です。

例えば、システム障害の原因を調査した結果、

• 設定ミス：40件
• 操作ミス：25件
• プログラム不具合：15件
• 環境設定：10件
• その他：10件

という結果だったとします。

これをパレート図にすると、どの原因が多くの問題を占めているのかを一目で確認できます。

その結果、まず「設定ミス」や「操作ミス」への対策を優先する、といった判断ができます。

パレート図とは

パレート図は、棒グラフと累積比率を表す折れ線グラフを組み合わせた図です。

一般的には、横軸に問題や原因の種類、左側の縦軸に件数、右側の縦軸に累積比率を配置します。

そして、問題や原因を発生件数の多い順に左から並べます。

このようにすることで、

• どの問題が多いのか
• 上位の問題だけで全体のどの程度を占めているのか
• どこまで対策すれば大きな改善効果が期待できるのか

を確認できます。

パレートの法則との関係

パレート図を理解するうえで、パレートの法則を知っておくと分かりやすくなります。

パレートの法則とは、一般的に「全体の結果の大部分は、少数の要因によって生み出される」という考え方です。

例えば、

「問題の80％が、原因の20％によって発生している」

といった考え方で説明されることがあります。

ただし、実際のプロジェクトや業務で必ず「80％と20％」になるわけではありません。

重要なのは、多くの問題を引き起こしている少数の重要な要因を見つけるという考え方です。

パレート図の構成

パレート図は、大きく分けて棒グラフと累積比率の折れ線グラフから構成されます。

棒グラフ

棒グラフは、問題や原因の発生件数を表します。

通常は、発生件数が多い順に左から並べます。

そのため、左側にある棒ほど大きくなります。

累積比率

折れ線グラフは、左から順番に問題を合計した累積比率を表します。

例えば、全体の問題が100件あり、最も多い原因が40件だった場合、その原因だけで累積比率は40％になります。

次の原因が25件なら、40％＋25％で累積比率は65％になります。

この折れ線を見ることで、上位の問題が全体のどの程度を占めているのかを確認できます。

パレート図の作り方

1．問題やデータを集める

まず、分析対象となる問題や不具合のデータを集めます。

例えば、システム障害について分析するのであれば、過去に発生した障害を原因別に分類します。

2．項目ごとの件数を集計する

次に、分類した項目ごとに発生件数を集計します。

例えば、

といった形です。

3．多い順に並べる

発生件数が多い順にデータを並べます。

パレート図では、基本的に多い項目を左側、少ない項目を右側に配置します。

4．累積件数を計算する

左から順番に件数を足して、累積件数を計算します。

例えば、100件の問題があり、

• 設定ミス：40件
• 操作ミス：25件
• プログラム不具合：15件
• 環境設定：10件
• その他：10件

であれば、累積件数は、

• 40件
• 65件
• 80件
• 90件
• 100件

となります。

5．累積比率を計算する

累積件数を全体の件数で割り、累積比率を計算します。

上記の例であれば、

• 40％
• 65％
• 80％
• 90％
• 100％

となります。

6．棒グラフと折れ線グラフを作成する

最後に、発生件数を棒グラフ、累積比率を折れ線グラフとして表示します。

これでパレート図が完成します。

パレート図を使うメリット

問題の優先順位をつけやすい

問題が大量に発生している場合、すべてを同時に改善するのは難しいことがあります。

パレート図を使えば、どの問題が全体に大きな影響を与えているのかを確認できます。

そのため、改善活動の優先順位を決めやすくなります。

重要な問題を視覚的に把握できる

数字だけを見ていると、どの問題が重要なのか分かりにくいことがあります。

パレート図にすると、棒の高さや累積比率によって、重要な問題を直感的に把握できます。

関係者と問題意識を共有しやすい

プロジェクトでは、メンバーによって「何を優先すべきか」という認識が異なる場合があります。

パレート図を使ってデータを共有することで、感覚ではなくデータをもとに優先順位を議論できます。

プロジェクトマネジメントでの活用例

パレート図は、品質管理だけではなく、プロジェクトマネジメントのさまざまな場面で利用できます。

パレート図と品質管理

パレート図は、品質管理における代表的な分析手法の一つです。

例えば、システム開発で100件の不具合が発生したとします。

不具合を原因別に分類すると、

• 要件定義の誤り：45件
• 設計ミス：25件
• 実装ミス：15件
• テスト不足：10件
• その他：5件

となったとします。

この場合、要件定義の誤りと設計ミスだけで70％を占めています。

そのため、すべての原因に同じだけ対策を行うよりも、まず要件定義や設計の品質を改善することが効果的だと判断できます。

もちろん、件数が少ない問題でも重大な影響を及ぼす場合があります。

したがって、パレート図は「件数が多いものから必ず対応する」ためのルールではなく、改善の優先順位を検討するための材料として利用することが重要です。

パレート図を使うときの注意点

件数だけで重要度を判断しない

発生件数が少なくても、重大な問題があります。

例えば、1件しか発生していなくても、顧客の重大な損失やシステム停止につながる問題であれば、優先して対応する必要があります。

そのため、パレート図だけで優先順位を決めるのではなく、影響度や緊急度、リスクなども合わせて判断することが重要です。

分類方法によって結果が変わる

どのような分類方法を採用するかによって、パレート図の結果は大きく変わります。

例えば、「設計ミス」という大きな分類にするのか、「データベース設計ミス」「画面設計ミス」などに細かく分類するのかによって、見える結果が変わります。

分析の目的に合わせて、適切な分類方法を考える必要があります。

「80％」にこだわりすぎない

パレート図では「80：20」という数字がよく使われますが、実際のデータが必ず80：20になるわけではありません。

重要なのは、全体への影響が大きい項目を見つけることです。

パレート図と他の分析手法

問題分析では、パレート図だけですべてを解決する必要はありません。

目的に応じて、他の分析手法と組み合わせると効果的です。

パレート図と特性要因図

パレート図で「どの問題が多いのか」を特定した後、特性要因図を使って「なぜその問題が発生しているのか」を分析することができます。

パレート図と根本原因分析

パレート図で重要な問題を絞り込み、その問題について根本原因分析を行うという使い方もできます。

例えば、100件の不具合のうち、50件が要件定義の問題だったとします。

そこで、要件定義に問題が集中している理由をさらに分析します。

「なぜ要件漏れが発生したのか？」

「なぜレビューで発見できなかったのか？」

「なぜ顧客との認識に差が生じたのか？」

と掘り下げることで、根本原因の特定につなげます。

プロジェクトマネージャ試験ではここが重要

パレート図については、単に「80：20の法則」として覚えるのではなく、問題の優先順位を判断するために使う分析手法として理解しておくことが重要です。

特に、

• 問題や原因を多い順に並べる
• 棒グラフで件数を表す
• 累積比率を折れ線で表す
• 重要な問題を特定する
• 改善の優先順位を検討する

という流れを押さえておきましょう。

また、件数が少ないから重要ではないとは限らない点にも注意が必要です。

重大度や影響度など、他の情報と組み合わせて判断することが重要です。

PM道場のワンポイント

パレート図は「全部を頑張らないための道具」と考えると分かりやすいです。

プロジェクトでは、問題が一つだけ発生するとは限りません。

不具合、課題、問い合わせ、障害など、さまざまな問題が同時に発生することがあります。

すべての問題を同じ優先度で解決しようとすると、チームのリソースが分散してしまいます。

そこでパレート図を使って、

「今、一番多く発生している問題は何か？」

「上位の問題だけで全体のどれくらいを占めているか？」

を確認します。

そして、影響度や緊急度なども考慮しながら、どこから改善するかを決めます。

つまり、パレート図は「問題を見つけるための図」ではなく、「限られたリソースをどこに集中させるかを考えるための図」として使うと、プロジェクトマネージャにとって非常に有効なツールになります。

関連用語

• 品質管理
• 品質メトリクス
• 不具合
• 根本原因分析
• 特性要因図
• レビュー
• インスペクション
• 継続的改善
• リスク
• 課題
• インシデント

まとめ

パレート図とは、問題や原因を発生件数の多い順に並べ、累積比率と合わせて表示する分析手法です。

問題が大量に発生している場合でも、どの問題が全体に大きな影響を与えているのかを視覚的に確認できます。

そのため、

• 品質管理
• 不具合分析
• 障害分析
• 課題管理
• 業務改善
• 原因分析

など、さまざまな場面で活用できます。

パレート図を使うときに重要なのは、「80：20」という数字を覚えることではありません。

多くの問題の中から、全体への影響が大きい問題を見つけ、限られたリソースをどこに集中させるのかを考えることが本来の目的です。

ただし、発生件数が少ない問題でも重大な影響を与える場合があります。

そのため、パレート図の結果だけで判断せず、影響度や緊急度、リスクなども考慮して優先順位を決めることが重要です。

「すべての問題に同じ力を注ぐのではなく、重要な問題を見極めて、限られたリソースを集中させる」

これがパレート図をプロジェクトマネジメントで活用するポイントです。

関連記事

• 品質管理とは？
• 品質メトリクスとは？
• 不具合とは？
• 根本原因分析とは？
• 特性要因図とは？
• レビューとは？
• インスペクションとは？
• 継続的改善とは？
• リスクとは？
• 課題とは？

よくある質問（FAQ）

Q. パレート図とは何ですか？

A. パレート図とは、問題や原因を発生件数の多い順に並べ、棒グラフと累積比率の折れ線グラフによって、全体への影響が大きい問題を把握するための分析手法です。

Q. パレート図は何のために使いますか？

A. 多くの問題の中から、発生件数が多く全体への影響が大きい問題を把握し、改善の優先順位を検討するために使います。

Q. パレート図は必ず80：20になりますか？

A. いいえ。実際のデータが必ず80：20になるわけではありません。重要なのは、少数の重要な要因が全体にどの程度の影響を与えているのかを確認することです。

Q. パレート図では件数が多い問題から対応すればよいですか？

A. 必ずしもそうとは限りません。発生件数が少なくても重大な影響を与える問題があります。件数だけではなく、影響度や緊急度、リスクなどを合わせて優先順位を判断する必要があります。

Q. パレート図と根本原因分析はどのように使い分けますか？

A. パレート図は「どの問題が多いのか」を把握するために使い、根本原因分析は「なぜその問題が発生したのか」を掘り下げるために使います。パレート図で重要な問題を絞り込んだ後、その問題について根本原因分析を行うという使い方ができます。

Q. パレート図は品質管理以外でも使えますか？

A. はい。品質管理だけでなく、障害管理、課題管理、顧客からの問い合わせ分析、業務改善など、問題を分類して優先順位を決める必要があるさまざまな場面で活用できます。

The post パレート図とは？意味・作り方・活用方法をわかりやすく解説 first appeared on PM道場.

「どこで故障が起こる可能性があるのか整理したい」

「発生する可能性のある問題に、優先順位をつけたい」

このようなときに活用される代表的な手法がFMEAです。

FMEAは、Failure Mode and Effects Analysisの略で、日本語では故障モード影響解析と呼ばれます。

製品やシステム、プロセスなどについて、どのような故障や問題が発生する可能性があるのか、その原因や影響は何かを事前に分析する手法です。

FMEAを使うことで、問題が実際に発生してから対応するのではなく、問題が発生する前にリスクを洗い出し、対策を検討することができます。

一言でいうと

FMEAとは、起こり得る故障や問題を事前に洗い出し、その影響や原因を分析して、優先的に対策すべきリスクを明確にする手法です。

ポイントは、「問題が起きてから分析する」のではなく、「問題が起きる前に分析する」ことです。

例えば、システム開発であれば、

• データが登録されない
• 誤ったデータが登録される
• 処理が途中で停止する
• 通知が送信されない

といった故障モードを想定します。

そして、それぞれについて、

• どのような影響があるのか
• なぜ発生するのか
• 現在の対策で防げるのか
• 追加対策が必要なのか

を整理します。

FMEAとは

FMEAは、製品やシステム、プロセスなどに存在する潜在的な故障モードを分析する手法です。

「故障モード」とは、故障や不具合がどのような形で現れるのかを表したものです。

例えば、

• 電源が入らない
• データが登録されない
• 通信が切断される
• 必要な情報が表示されない

などが故障モードに該当します。

FMEAでは、故障モードだけを見るのではありません。

それによってどのような影響が発生するのか、そしてなぜその故障が発生するのかまで整理します。

さらに、リスクの大きさなどを評価し、どの問題から対策すべきかを検討します。

FMEAの基本的な考え方

FMEAでは、基本的に次のような流れで分析します。

故障モード → 影響 → 原因 → 現在の対策 → リスク評価 → 対策

例えば、システムのデータ登録機能を考えてみます。

このように整理することで、問題が発生する可能性のある箇所と、その影響や対策を体系的に確認できます。

FMEAで整理する主な項目

FMEAでは、分析対象に応じてさまざまな項目を設定します。

故障モード

どのような故障や不具合が発生する可能性があるのかを記載します。

FMEAの中心となる項目です。

影響

その故障モードが発生した場合、どのような影響があるのかを整理します。

例えば、

• 処理が停止する
• 顧客に誤った情報が提供される
• 業務が遅延する
• データが失われる

などです。

原因

なぜその故障モードが発生するのかを整理します。

原因を明確にすることで、どのような予防策が必要なのかを検討できます。

現在の管理・対策

現在、どのような予防策や検出策が存在するのかを整理します。

例えば、

• レビュー
• テスト
• 自動チェック
• 監視
• 承認プロセス

などがあります。

リスク評価

故障モードについて、影響の大きさや発生可能性、検出可能性などを評価します。

評価方法はFMEAの種類や組織によって異なります。

推奨対策

分析結果をもとに、追加で実施すべき対策を整理します。

例えば、

• 設計を変更する
• チェックを追加する
• テストを強化する
• 監視機能を追加する
• 作業手順を変更する

などです。

FMEAの進め方

ステップ1：分析対象を決める

最初に、何についてFMEAを行うのかを明確にします。

例えば、

• 製品
• システム
• 機能
• 業務プロセス
• 製造工程

などです。

対象範囲が広すぎると分析が複雑になるため、目的に応じて適切な範囲を設定します。

ステップ2：機能やプロセスを整理する

次に、分析対象がどのような機能やプロセスで構成されているのかを整理します。

システムであれば、

• 入力
• 処理
• データ保存
• 出力
• 通知

などに分解します。

ステップ3：故障モードを洗い出す

それぞれの機能やプロセスについて、「何がうまくいかない可能性があるか」を考えます。

例えば、データ保存機能であれば、

• 保存されない
• 誤ったデータが保存される
• 重複して保存される
• 一部のデータが欠落する

などを洗い出します。

ステップ4：影響を分析する

各故障モードについて、発生した場合の影響を整理します。

「その問題が発生したら、誰にどのような影響があるのか？」という視点で考えます。

ステップ5：原因を分析する

次に、「なぜその故障モードが発生するのか」を整理します。

例えば、

「データが保存されない」

という故障モードに対して、

• データベース接続が切断された
• 入力値が不正だった
• プログラムに不具合がある
• データベース容量が不足している

などの原因を洗い出します。

ステップ6：現在の対策を確認する

現在どのような予防策や検出策があるのかを確認します。

ここでは、単に「対策がある」とするのではなく、本当に故障を防止・検出できるのかを確認することが重要です。

ステップ7：リスクを評価する

洗い出した故障モードについて、リスクの大きさを評価します。

代表的な評価項目として、

• 重大度
• 発生頻度
• 検出可能性

などがあります。

評価方法や尺度は、組織やFMEAの種類によって異なります。

ステップ8：対策の優先順位を決める

評価結果をもとに、どの故障モードから対策するのかを決定します。

すべての問題に同じレベルの対策を行うのではなく、リスクの大きいものを優先することが基本です。

ステップ9：対策を実施し、再評価する

対策を実施したら、再度リスクを評価します。

対策によってリスクがどの程度低減したのかを確認し、必要であれば追加対策を検討します。

FMEAで使われるリスク評価

FMEAでは、故障モードごとにリスクを評価することがあります。

代表的な評価項目が、

• Severity（重大度）
• Occurrence（発生頻度）
• Detection（検出可能性）

です。

これらを数値化し、リスクの優先順位付けに利用する方法があります。

ただし、評価方法や計算方法はFMEAの種類や組織によって異なります。

そのため、「FMEAでは必ずこの計算方法を使う」と考えるのではなく、採用しているFMEAのルールを確認することが重要です。

FMEAの種類

FMEAには、分析する対象によっていくつかの種類があります。

設計FMEA

製品やシステムの設計に潜む故障モードを分析するFMEAです。

設計段階で問題を発見し、製品が完成する前に設計を改善することを目的とします。

工程FMEA

製造工程や業務プロセスなどに潜む問題を分析するFMEAです。

工程の中で発生する可能性のある問題を事前に洗い出し、品質問題を防止します。

システムFMEA

システム全体を対象として、構成要素間の関係やシステム上の故障モードを分析します。

複数の機能や部品が連携するシステムでは、個々の要素だけでなく、要素間の相互作用も考える必要があります。

FMEAとリスクマネジメント

FMEAは、プロジェクトや製品に潜むリスクを問題が発生する前に洗い出すという点で、リスクマネジメントと深く関係しています。

例えば、システム開発プロジェクトであれば、

「本番環境でデータ登録ができなくなる可能性がある」

という問題を想定します。

そのうえで、

• どのような影響があるか
• 何が原因になるか
• 現在の対策は何か
• 追加対策が必要か

を整理します。

これは、プロジェクトにおけるリスクの特定・分析・対応につながります。

FMEAとリスク登録簿

FMEAの分析結果は、プロジェクトのリスク登録簿に反映することもできます。

例えば、FMEAによって、

「特定の処理でデータが失われる可能性がある」

というリスクが見つかったとします。

その場合、リスク登録簿に、

• リスクの内容
• 発生原因
• 影響
• 発生可能性
• 影響度
• 対応策
• 担当者

などを登録し、継続的に管理することができます。

つまり、FMEAはリスクを発見するための分析手法として利用し、その結果をリスク登録簿などで継続的に管理することができます。

FMEAのメリット

問題が発生する前に対策できる

FMEAの最大のメリットは、問題が発生してから対応するのではなく、事前に問題を想定できることです。

早い段階で問題を発見できれば、設計変更やプロセス改善などによって、問題そのものを防止できる可能性があります。

リスクの優先順位をつけられる

すべての故障モードに対して同じ対策を行う必要はありません。

リスクを評価することで、優先的に対策すべき問題を明確にできます。

関係者の知識を共有できる

FMEAは、複数の関係者が参加して分析することで効果を発揮します。

設計担当者、開発担当者、テスト担当者、運用担当者などが参加することで、それぞれの視点から故障モードや原因を洗い出せます。

FMEAの注意点

評価の数値だけに頼らない

FMEAではリスクを数値化する場合がありますが、数値だけを見て判断すると危険です。

例えば、発生頻度が低くても、発生した場合の影響が非常に大きい問題があります。

そのため、数値だけではなく、故障モードの内容や影響を理解したうえで判断することが重要です。

分析を細かくしすぎない

すべての可能性を細かく分析しようとすると、FMEA自体が非常に大きな作業になってしまいます。

分析の目的と対象範囲を明確にし、必要な粒度で分析することが重要です。

一度作って終わりにしない

FMEAは一度作成したら終わりではありません。

設計変更や環境変更、新しい問題の発生などによって、リスクの状況は変化します。

そのため、必要に応じてFMEAを更新し、継続的に改善することが重要です。

関係者を巻き込む

FMEAを一人だけで作成すると、故障モードや原因の見落としが発生する可能性があります。

可能であれば、複数の専門家や関係者の知識を集めて分析することが効果的です。

プロジェクトマネジメントでの活用例

FMEAは製造業だけの手法ではありません。

プロジェクトマネジメントにおいても、将来発生する可能性のある問題を事前に分析するために活用できます。

プロジェクトマネージャ試験ではここが重要

FMEAについては、単に「故障モード影響解析」という名称を覚えるだけではなく、どのような目的で利用するのかを理解しておきましょう。

重要なのは、

• 問題が発生する前に分析する
• 潜在的な故障モードを洗い出す
• 故障による影響を分析する
• 故障の原因を分析する
• リスクを評価する
• 優先的に対策する対象を決める

という流れです。

特に、「問題が発生してから原因を分析する手法」ではなく、「問題が発生する前に潜在的な故障を分析する手法」である点が重要です。

PM道場のワンポイント

FMEAは「未来のトラブルを先に経験するための分析」と考えると分かりやすいです。

プロジェクトでは、問題が発生してから対応すると、スケジュールやコスト、品質に大きな影響が出ることがあります。

そこで、まだ問題が発生していない段階で、

「もしここが壊れたら、何が起きるだろう？」

と考えます。

そして、

「なぜ壊れるのか？」

「壊れたら誰にどんな影響があるのか？」

「今の仕組みで防げるのか？」

を整理します。

このように考えることで、実際に問題が発生する前に、設計やプロセスを改善できます。

つまりFMEAは、「問題が起きた後の対応」ではなく、「問題を起こさないための仕組み」を考えるための手法です。

関連用語

• リスク
• リスクマネジメント
• リスク分析
• リスク対応
• リスク登録簿
• 品質管理
• 品質保証
• 品質メトリクス
• 不具合
• 根本原因分析
• パレート図
• インスペクション
• レビュー
• テスト
• 継続的改善

まとめ

FMEAとは、故障モード影響解析（Failure Mode and Effects Analysis）のことで、製品やシステム、プロセスなどに潜む問題を事前に分析する手法です。

FMEAでは、

• どのような故障が発生する可能性があるか
• その故障によってどのような影響があるか
• なぜその故障が発生するのか
• 現在どのような対策があるのか
• 追加でどのような対策が必要なのか

を整理します。

そして、リスクを評価することで、どの問題から優先的に対策すべきなのかを判断します。

FMEAの重要なポイントは、「問題が発生してから対応する」のではなく、「問題が発生する前に対策する」ことです。

そのため、品質管理だけでなく、システム開発や業務プロセス、リスクマネジメントなど、さまざまなプロジェクトで活用できます。

また、FMEAで洗い出したリスクをリスク登録簿などで管理することで、分析結果を実際のプロジェクトマネジメントにつなげることもできます。

「もし問題が起きるとしたら、どこで、なぜ起きて、どんな影響があるのか？」

この問いをプロジェクトの早い段階で考えることが、FMEAの基本的な考え方です。

関連記事

• リスクとは？
• リスクマネジメントとは？
• リスク分析とは？
• リスク対応とは？
• リスク登録簿とは？
• 品質管理とは？
• 品質保証とは？
• 品質メトリクスとは？
• 不具合とは？
• 根本原因分析とは？
• パレート図とは？
• レビューとは？
• インスペクションとは？
• テストとは？
• 継続的改善とは？

よくある質問（FAQ）

Q. FMEAとは何ですか？

A. FMEAとは「Failure Mode and Effects Analysis」の略で、日本語では故障モード影響解析といいます。製品やシステム、プロセスなどに潜む故障や問題を事前に洗い出し、その影響や原因を分析する手法です。

Q. FMEAは何のために使いますか？

A. 問題が発生する前に潜在的な故障モードを洗い出し、リスクを評価して、優先的に対策すべき問題を明確にするために使います。

Q. FMEAとリスク分析は同じですか？

A. FMEAはリスク分析に活用できる具体的な分析手法の一つです。故障モード、影響、原因などを整理し、リスクを評価することで、対応すべき問題の優先順位を検討します。

Q. FMEAは問題が発生した後にも使えますか？

A. FMEAの主な目的は、問題が発生する前に潜在的な故障を分析することです。ただし、実際に発生した不具合や障害から得られた知見をFMEAに反映し、将来の同様の問題を防止するために活用することはできます。

Q. FMEAでは何を分析しますか？

A. 主に、故障モード、故障による影響、故障の原因、現在の対策、リスク評価、追加対策などを分析します。

Q. FMEAと根本原因分析の違いは何ですか？

A. FMEAは、まだ発生していない潜在的な故障や問題を事前に分析することを主な目的とします。一方、根本原因分析は、実際に発生した問題について「なぜ発生したのか」を掘り下げ、根本的な原因を特定することを目的とします。

Q. FMEAはプロジェクトマネジメントでも使えますか？

A. はい。システム開発、要件定義、設計、テスト、移行、運用など、将来発生する可能性のある問題を事前に検討する場面で活用できます。

The post FMEAとは？故障モード影響解析の意味・進め方・活用方法を解説 first appeared on PM道場.

「一つの原因だけではなく、複数の原因を体系的に洗い出したい」

このようなときに役立つのが特性要因図です。

特性要因図とは、ある結果に対して、どのような原因が影響しているのかを整理して可視化する図です。

見た目が魚の骨のように見えることから、「魚の骨図」や「フィッシュボーンチャート」と呼ばれることもあります。

品質管理や問題解決で広く使われていますが、プロジェクトマネジメントにおいても、問題や不具合の原因を整理するために活用できます。

一言でいうと

特性要因図とは、「ある問題がなぜ発生したのか」を、複数の原因に分解して整理するための図です。

例えば、「納期遅延」という問題が発生した場合、原因として、

• 要件変更が多かった
• 見積もりが甘かった
• メンバーが不足していた
• レビューに時間がかかった
• テストで大量の不具合が発生した

などが考えられます。

特性要因図では、こうした原因をさらに掘り下げながら整理します。

その結果、「問題の原因を漏れなく考えるための土台」を作ることができます。

特性要因図とは

特性要因図は、結果と、その結果を引き起こした可能性のある要因との関係を整理するための図です。

一般的には、右側に分析したい「結果」を置き、そこから左側に向かって原因を枝分かれさせていきます。

その形が魚の骨に似ているため、「魚の骨図」と呼ばれています。

例えば、

「プロジェクトが納期に遅れた」

という結果を分析するとします。

その原因を、

• 人
• 方法
• 環境
• ツール
• 要件

などの観点から整理し、さらにそれぞれの原因を細かく掘り下げていきます。

このように、原因を階層的に整理できることが特性要因図の特徴です。

特性要因図の「特性」と「要因」

特性要因図という名前は、「特性」と「要因」という2つの言葉からできています。

特性

「特性」とは、分析したい結果や問題のことです。

例えば、

• 製品の不良率が高い
• システム障害が多い
• プロジェクトが遅延している
• 顧客からのクレームが多い

などです。

要因

「要因」とは、その結果を引き起こしていると考えられる原因のことです。

特性要因図では、特性に対してどのような要因が関係しているのかを整理します。

特性要因図の目的

特性要因図を作成する主な目的は、問題の原因を体系的に洗い出すことです。

問題が発生すると、人は最初に思いついた原因だけで判断してしまうことがあります。

例えば、プロジェクトが遅延したときに、

「メンバーの作業が遅かったからだ」

と考えてしまうかもしれません。

しかし、実際には、

• 要件が頻繁に変更された
• 作業量の見積もりが不十分だった
• レビューの体制が整っていなかった
• 依存する作業が遅れていた
• 意思決定に時間がかかった

など、複数の要因が関係している可能性があります。

特性要因図を使うことで、一つの原因に決めつけず、さまざまな可能性を整理できます。

特性要因図の作り方

1．分析する問題を決める

まず、何について原因を分析するのかを決めます。

例えば、

「システム障害が多い」

という問題を分析するとします。

ここで重要なのは、できるだけ具体的な問題を設定することです。

「品質が悪い」のように曖昧な表現では、原因も曖昧になってしまいます。

2．特性を図の右側に置く

分析する問題を図の右側に配置します。

これが特性要因図の「特性」です。

例えば、

「システム障害が多い」

を特性として設定します。

3．大きな原因の分類を決める

次に、原因を考えるための大きな分類を決めます。

製造業では、よく「4M」が使われます。

• Man（人）
• Machine（設備・機械）
• Method（方法）
• Material（材料）

必要に応じて、

• Measurement（測定）
• Environment（環境）
• Management（管理）

などを加える場合もあります。

ただし、4Mなどの分類を必ず使用しなければならないわけではありません。

分析対象に適した分類を設定することが重要です。

4．原因を洗い出す

それぞれの分類について、原因を洗い出します。

例えば、「システム障害が多い」という問題であれば、

などが考えられます。

5．さらに原因を掘り下げる

一度洗い出した原因について、さらに「なぜ？」と掘り下げます。

例えば、

レビュー不足

↓

なぜレビュー不足なのか？

↓

レビューの時間が確保されていない

↓

なぜ時間が確保されていないのか？

↓

スケジュールにレビュー工程が十分に設定されていない

というように、原因を段階的に掘り下げます。

6．原因を整理する

最後に、洗い出した原因を整理します。

同じ原因が複数の場所に出ていないか、原因と結果が逆になっていないかなどを確認します。

また、洗い出した原因が本当に「原因」なのか、単なる事象なのかを確認することも重要です。

特性要因図の使い方

問題の原因を洗い出す

最も基本的な使い方です。

問題が発生したときに、考えられる原因を体系的に洗い出します。

特に、原因が複数考えられる問題に向いています。

チームで原因を検討する

特性要因図は、チームで原因を検討するときにも有効です。

一人で考えると、自分の経験や知識の範囲に原因分析が偏ってしまいます。

複数のメンバーで議論することで、異なる視点から原因を洗い出すことができます。

原因の関係を整理する

原因を箇条書きにするだけでは、原因同士の関係が分かりにくい場合があります。

特性要因図では、原因を階層構造で整理できるため、「大きな原因」と「その原因を引き起こしたさらに細かい原因」を把握できます。

特性要因図と5Why

特性要因図と5Whyは、どちらも原因分析に使われる手法です。

5Whyは、問題に対して「なぜ？」を繰り返すことで、原因を深掘りしていきます。

一方、特性要因図は、複数の原因を広く洗い出し、それらを体系的に整理することに向いています。

そのため、両者を組み合わせることもできます。

例えば、最初に特性要因図を使って原因を広く洗い出します。

その後、重要な原因について5Whyを使って深掘りします。

このように、

「広く洗い出す → 深く掘り下げる」

という使い分けができます。

特性要因図と根本原因分析

特性要因図は、根本原因分析を行う際にも活用できます。

例えば、「本番環境で障害が発生した」という問題について、特性要因図を作成します。

すると、

• 設計
• 実装
• テスト
• 環境
• 運用
• 人

など、さまざまな観点から原因を洗い出すことができます。

その後、重要な原因を選び、さらに詳細な分析を行います。

このため、特性要因図は根本原因を探すための最初の整理手段として活用できます。

特性要因図とパレート図

パレート図も、問題分析に使われる代表的な手法です。

ただし、両者には役割の違いがあります。

例えば、まず特性要因図を使って原因を洗い出し、その後、実際の発生件数を集計してパレート図で重要な原因を特定する、といった使い方ができます。

つまり、

特性要因図＝「原因を広く考える」

パレート図＝「どの原因を優先するか考える」

と理解すると分かりやすいでしょう。

特性要因図とFMEA

FMEAは、故障モードやその影響、原因などを事前に分析する手法です。

特性要因図とは目的が異なりますが、組み合わせて利用することができます。

例えば、特性要因図を使って問題の原因を幅広く洗い出し、その原因をFMEAの分析項目に反映します。

これにより、潜在的な故障モードや原因をより多角的に検討できます。

プロジェクトマネジメントでの活用例

特性要因図は、プロジェクトマネジメントでもさまざまな問題の原因分析に利用できます。

このように、特性要因図は品質問題だけではなく、スケジュール、コスト、コミュニケーション、ステークホルダーなど、プロジェクトのさまざまな問題の原因分析に活用できます。

特性要因図を使うメリット

原因を幅広く考えられる

一つの原因に決めつけることなく、複数の視点から原因を洗い出せます。

原因を整理して見える化できる

箇条書きでは分かりにくい原因同士の関係を、図として整理できます。

チームで共通認識を作れる

図を見ながら議論することで、メンバー間で問題や原因についての認識を共有できます。

根本原因分析につなげられる

特性要因図を使って原因を整理した後、5Whyなどを使ってさらに深掘りすることができます。

特性要因図を使うときの注意点

原因を思いつくだけ並べない

特性要因図では、多くの原因を洗い出すことができます。

しかし、思いついた原因を無制限に追加すると、図が複雑になってしまいます。

分析の目的を意識しながら、重要な原因を整理することが大切です。

「原因」と「結果」を混同しない

分析している問題と、その問題を引き起こした原因を明確に区別する必要があります。

例えば、「納期遅延」という問題に対して「作業が遅れた」という項目を置くだけでは、十分な原因分析とはいえません。

「なぜ作業が遅れたのか？」とさらに掘り下げる必要があります。

特性要因図だけで根本原因が決まるわけではない

特性要因図は、あくまで原因を整理するための手法です。

図に書かれた原因がすべて真の原因とは限りません。

実際のデータや事実を確認しながら、原因を検証する必要があります。

先入観に注意する

「おそらくこれが原因だろう」という思い込みで分析すると、原因の見落としや偏りが発生します。

複数の関係者から意見を集め、事実に基づいて原因を確認することが重要です。

プロジェクトマネージャ試験ではここが重要

特性要因図については、単に「魚の骨の形をした図」と覚えるだけではなく、目的と使い方を理解しておきましょう。

重要なのは、

• ある結果に対する原因を整理する
• 原因を複数の観点から洗い出す
• 原因を階層的に整理する
• チームで原因分析を行う
• 根本原因分析につなげる

という点です。

また、特性要因図は原因を洗い出すための手法であり、原因が本当に正しいかどうかを証明するものではありません。

そのため、実際のデータや事実を確認しながら原因を検証することが重要です。

PM道場のワンポイント

特性要因図は「原因を一つに決めつけないための道具」と考えると分かりやすいです。

プロジェクトで問題が発生すると、私たちはつい「これが原因だ」と決めつけてしまいます。

しかし、実際のプロジェクトでは、一つの問題に複数の原因が絡んでいることが少なくありません。

例えば、納期が遅れたとしても、

• 見積もりが不足していた
• 要件変更が多かった
• レビューが遅れた
• メンバーが不足していた
• 意思決定に時間がかかった

など、複数の要因が重なっている可能性があります。

そこで特性要因図を使い、まずは「原因を広く洗い出す」ことから始めます。

そのうえで、5Whyなどを使って重要な原因を深掘りし、実際のデータや事実によって検証していきます。

つまり、特性要因図は「答えを出すための図」ではなく、「正しい答えを探すために、原因を整理する図」です。

関連用語

• 品質管理
• 品質保証
• 品質メトリクス
• 不具合
• 根本原因分析
• 5Why
• パレート図
• FMEA
• レビュー
• インスペクション
• テスト
• リスク
• 課題
• 継続的改善

まとめ

特性要因図とは、ある結果に対して、どのような原因が影響しているのかを体系的に整理するための図です。

魚の骨のような形をしていることから、「魚の骨図」や「フィッシュボーンチャート」とも呼ばれます。

特性要因図を使うことで、

• 原因を幅広く洗い出す
• 原因を分類して整理する
• 原因を階層的に掘り下げる
• チームで問題に対する認識を共有する
• 根本原因分析につなげる

といったことができます。

特に重要なのは、「最初に思いついた原因だけで問題を説明しない」ことです。

特性要因図を使って原因を広く洗い出し、その後、5Whyや根本原因分析、実際のデータなどを使って原因を検証することで、より効果的な問題解決につなげることができます。

また、パレート図やFMEAなどの手法と組み合わせることで、原因の洗い出しから優先順位付け、リスクへの対応まで、より体系的に進めることができます。

「問題が起きたら、すぐに原因を一つに決めつけない。まずは原因を広く洗い出して整理する。」

これが、特性要因図をプロジェクトマネジメントで活用するうえでの重要なポイントです。

関連記事

• 品質管理とは？
• 品質保証とは？
• 品質メトリクスとは？
• 不具合とは？
• 根本原因分析とは？
• 5Whyとは？
• パレート図とは？
• FMEAとは？
• レビューとは？
• インスペクションとは？
• テストとは？
• リスクとは？
• 課題とは？
• 継続的改善とは？

よくある質問（FAQ）

Q. 特性要因図とは何ですか？

A. 特性要因図とは、ある結果や問題に対して、どのような原因が影響しているのかを整理するための図です。魚の骨のような形をしていることから、魚の骨図やフィッシュボーンチャートとも呼ばれます。

Q. 特性要因図は何のために使いますか？

A. 問題の原因を一つに決めつけず、複数の観点から幅広く洗い出し、体系的に整理するために使います。

Q. 特性要因図と5Whyの違いは何ですか？

A. 特性要因図は複数の原因を幅広く洗い出して整理することに向いています。一方、5Whyは「なぜ？」を繰り返して、一つの原因を深く掘り下げることに向いています。両者を組み合わせて使うこともできます。

Q. 特性要因図とパレート図の違いは何ですか？

A. 特性要因図は「どのような原因が考えられるか」を整理するために使います。一方、パレート図は問題や原因を件数順に並べ、「どの問題を優先すべきか」を検討するために使います。

Q. 特性要因図は品質管理以外でも使えますか？

A. はい。納期遅延、コスト超過、システム障害、コミュニケーション不足、顧客満足度の低下など、原因が複数考えられるさまざまな問題に活用できます。

Q. 特性要因図を作れば根本原因が分かりますか？

A. 特性要因図だけで根本原因が確定するわけではありません。特性要因図は原因を洗い出して整理するための手法です。整理した原因について、5Whyやデータ分析などを行い、実際の事実と照らし合わせながら検証することが重要です。

The post 特性要因図とは？意味・作り方・使い方をわかりやすく解説 first appeared on PM道場.