ITパスポート 2022年 問48

システム開発の品質マネジメント：根本原因を追究する方法【ITパスポート 解説】

正解の理由

解法ステップ

1. 問題を明確にする
   • まず「問題（現象）」を短く具体的に書く。例：「リリース後、不具合が多発する」。
2. 図の中心線（背骨）を引く
   • 右端に問題を書き、左へ向けて線を引きます。
3. 大分類（主な原因群）を決める
   • 例：人（People：人員・スキル）、工程（Process：作業手順）、ツール（Tool：開発環境）、要求（Requirement：仕様）、測定（Measurement）、環境（Environment）など。ソフトウェアでは「要件」「設計」「実装」「テスト」「運用」などに置き換えます。
4. ブレインストーミングで枝に原因を書き出す
   • 大分類ごとに「なぜその問題が起きたか」を自由に出す。量を重視して書く。
5. 深掘り（階層化）する
   • 各原因に対して「さらになぜ？」を繰り返し、より具体的な要因（根本寄り）まで掘る。ここで「5つのなぜ（5 Whys：繰り返し『なぜ』と問う手法）」を併用すると有効。
6. 検証と優先順位付け
   • 因果が妥当か、データや再現試験で検証する。重要度や影響度で優先順位をつけ、対策を実行する。
7. 対策実施と効果確認
   • 対策後に同じ指標で効果を確認し、必要があれば追加対応する。

選択肢別の誤答解説

• ア: 管理限界を設定し、上限と下限を逸脱する事象から根本原因を推定する。
  • 管理限界とは管理図（control chart）の上限・下限のことです。これはプロセスの異常（特異なばらつき）を検出するのに有効ですが、「原因を整理して根本原因を追究する」ための因果の可視化手法ではありません。発見した異常を起点に原因を探す際には別の手法（例：フィッシュボーン）を使う必要があります。
• イ: 原因の候補リストから原因に該当しないものを削除し、残った項目から根本原因を絞り込む。
  • 要素の削除で絞る考え方は一見合理的ですが、単に除外していくだけでは原因の相互関係や構造（どの要因がどのように影響しているか）が見えにくいです。根本原因を「発見」するためには、候補を整理・構造化して関連性を示す手法（フィッシュボーン等）を使う方が確実です。
• エ: 複数の原因を分類し、件数が多かった原因の順に対処すべき根本原因の優先度を決めていく。
  • これはパレート分析（Pareto図、発生頻度や影響度で優先順位付けする手法）に近い考え方で、有効な優先順位付け手法です。ただし「原因と問題の関連付けを可視化して根本原因を追究する」という目的を直接満たす手法ではありません。頻度が多いこと＝根本原因とは限らないので、因果構造の把握が必要です。

よくある誤解

• フィッシュボーンを書けば自動的に根本原因がわかる
  • 誤解です。フィッシュボーンは「原因の候補を整理するツール」であり、仮説を立てる助けになりますが、実際の根本原因はデータや検証で確かめる必要があります。
• 管理図（管理限界）は原因を特定するツールである
  • 管理図はプロセスが安定かどうか（偶発的変動か特別な要因か）を判定するためのツールで、原因特定そのものの手段ではありません。異常を検出したら、原因分析手法を使います。
• 頻度（件数）が多いものが常に優先すべき根本原因である
  • 頻度が多いと対策効果が大きくなる可能性はありますが、重大な影響を与える稀な原因を見逃してはいけません。頻度（パレート）と影響度の両方で判断することが重要です。

補足コラム

• フィッシュボーン（Ishikawa図）の由来
  • 日本の品質管理の大家、石川馨（Ishikawa Kaoru）氏が考案しました。魚の骨の形に似ていることから「フィッシュボーン」と呼ばれます。英語では "cause-and-effect diagram"。
• 代表的な大分類の例（製造業の6M）とソフトウェア向けの置き換え例
  • 6M（Man：人、Machine：機械、Material：材料、Method：方法、Measurement：測定、Mother Nature：環境）
  • ソフトウェア例：人（スキル）、工程（開発プロセス）、技術（ツール・環境）、要求（仕様）、テスト、管理（スケジュール・方針）
• 実務では併用するのが定石
  • フィッシュボーンで因果を洗い出し、パレートで優先順位を付け、管理図で改善の効果をモニタリングする、という流れがよく使われます。

FAQ