LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

直接原因とは、起きた問題を直接引き起こした第一次的な原因のことです。根本原因とは、その直接原因の背後にある要因を掘り下げてたどり着く、本質的な原因を指します。2つの違いは、そこから導く対策にも表れます。直接原因を取り除けば同じ問題の再発は防げますが、根本原因まで手を打っておくと、まだ起きていない別の問題も防げるようになります。

外部のエンジニアと進めた開発や運用でつまずいたときも、「担当者のスキルが足りなかった」という直接原因で振り返りを終えると、委託先を替えても同じ食い違いが繰り返されがちです。本記事では、IPA（情報処理推進機構）のガイドブックをもとに直接原因と根本原因の違いを整理し、外部人材活用の失敗に当てはめた分析の手順と、委託の前に確認したい点をまとめます。

直接原因と根本原因の違い

IPAは2016年に「情報処理システム高信頼化教訓作成ガイドブック（ITサービス編）」を公開し、システム障害から教訓を作る手順をまとめました。ガイドブックは、原因を書くときは直接原因と根本原因が明確に分かるようにし、直接原因は障害事象の第一次的なもの、根本原因は直接原因の背後にある要因を深掘りしたものとする、としています。^*1 なぜなぜ分析（「なぜ」と問いを繰り返して原因をたどる方法）の説明でも、問題を引き起こした直接の原因を見つけ、さらにそれを引き起こした原因を探す手順を繰り返して、本質的な原因である根本原因を見つけ出すとしています。

2つの違いは、そこから出てくる対策に表れます。ガイドブックによれば、直接原因を裏返すと再発防止策になり、これは障害対策としてすでに実施されている場合が多いとされます。根本原因を裏返すと、再発防止策に加えて未然防止策が出てきます。^*1 同じ年に公開された「教訓活用ガイドブック」は、再発防止対策を発生させた障害を二度と発生させない対策、未然防止対策を障害が発生する前にリスク分析を行って立てる対策と説明し、障害が起きると直接原因を修正し修復することで事足りたとしてしまう場合が多いと指摘しています。^*2

表の最後の行は、教訓活用ガイドブックが紹介している事例です。プライベートクラウドのサービスが数時間止まり、直接原因は運用担当者のボリューム割り当てミスでした。根本原因として挙がったのは、仮想サーバー環境での運用要件が整理されておらず、リソース管理と性能監視が不十分で、復旧時の対応方法も十分に把握していなかったことです。対策には、リソース管理と性能監視のプロセスの策定、障害対応マニュアルの整備と要員の教育・訓練が並びました。^*2 担当者のミスで分析を止めていれば、これらの対策は出てきません。

ガイドブックは、教訓をまとめるときに「問題」と「原因」を明確に分けることも求めています。^*1 問題は「何が起きたか」、原因は「なぜ起きたか」で、この2つが混ざると、何を直せばよいのかが読み取れなくなります。

外部人材活用の失敗に当てはめる

ガイドブックの対象はシステム障害ですが、この進め方は外部人材と進めた作業のトラブルにも使えます。たとえば「委託先の報告が遅かった」は直接原因にあたります。そこから「なぜ報告が遅れたのか」「なぜ遅れても自社の側で気づけなかったのか」と問いを重ねると、報告の窓口や時機を決めていなかった、任せる作業の範囲が曖昧だった、といった自社の側の要因が見えてくることがあります。

直接原因で分析を終えると、対策は担当者や委託先を替えることだけになりがちです。根本原因まで下りれば、契約や発注の段階で決めておく事項という、次の案件で使える対策に変わります。

ただし、分析のたびにすべての手順を踏む必要はありません。ガイドブックは、事実を整理した段階で原因や対策がすぐに分かる問題はそこで終え、原因分析は原因が複雑な問題や根が深い問題のときに行うとしています。^*1 委託したエンジニアに渡すはずの資料が1つ抜けていた、というように原因がはっきりしているなら、渡す資料の一覧を直せば足ります。社員の採用がうまくいかなかったときの原因の分け方は「エンジニア採用の採用失敗を3つに分ける原因分析の手順」で扱っています。

公開された事例で見る根本原因

ガイドブックの参考資料には、外部の技術者が関わった障害の分析例が載っています。A社は基幹業務システムを、B社が提供するクラウドサービスに移しました。このサービスと負荷分散装置を共同で使う企業にはD社もありました。ある日、オンライン業務の開始時からシステムに障害が起きて業務がまる1日止まり、障害箇所が分かったのは16時でした。直接の原因は、C社製の負荷分散装置（通信を複数のサーバーに振り分ける機器）の既知の不具合です。

機器1台の障害なのに、なぜ1日止まったのか。ガイドブックは根本原因として3つを挙げています。1つ目は、運用時のトラブル管理体制が決まっていなかったことです。B社のSE（システムエンジニア）はA社に常駐していましたが、体制が明確でなかったため、報告、連絡、相談がうまくいきませんでした。2つ目は、A社が役割分担やサービスレベルの不明確な運用委託契約のままサービスを始めていたこと。3つ目は、B社にC社製品の専門家がおらず、C社製品の不具合や修正プログラムの情報を、必要なときに入手できていなかったことです。^*1

再発防止策は3つでした。トラブル管理体制を明確にして報告、連絡、相談を行うこと。適切な契約でサービスのレベルを定義し、責任分界点（どこから先を誰が受け持つかの境目）を明確にすること。B社が関係する他の業者とトラブル対応の体制をつくることです。ユーザーの側も、対応をベンダー任せにせず積極的に働きかけるよう添えられています。^*1 直接原因だけを見れば機器の修正で終わりますが、根本原因からは体制と契約の対策が出てきました。

原因分析の進め方

手順は、障害情報の整理、なぜなぜ分析による原因分析と対策の検討、教訓としてのまとめ、教訓の効果の検証の順です。最初に作る障害状況表には、①登場人物、②誰が何に対してどう動いたかの流れ、③起きた出来事の前後関係を、時間の流れに沿って漏れなく書き出します。^*1 外部人材活用の失敗なら、委託先の担当者だけでなく、自社の窓口や依頼部門、委託先の管理者まで登場人物に入れると、どこで連絡が途切れたかが見えやすくなります。

次に、なぜなぜ分析で問題から直接原因、さらに根本原因までさかのぼります。当事者がいる場合は徹底的に「なぜ」を問い、いない場合はあらゆる想定をもとに掘り下げます。外部人材の場合、分析を始める頃には当事者の契約が終わっていることもあるので、契約の終わる前に聞き取りの時間を取っておくと進めやすくなります。

対策が決まったら、問題、原因、対策、効果、教訓の項目で1件ずつまとめ、原因の欄には直接原因と根本原因を、対策の欄には再発防止策と未然防止策を併せて書きます。教訓の概要は短く、「〜しない」ではなく「〜する」の形で書き、固有名詞は匿名化します。最後に、原因別に件数を集計し、全体に占める割合の大きい原因を取り出して、教訓でその種類の障害を減らせるかを確かめます。^*1 1件ごとの分析だけでは、同じ根本原因が案件をまたいで繰り返されているかどうかが分からないためです。

記録に残す項目

分析の材料になるのは、起きたときの記録です。IPAが2012年に公表した報告書では、聞き取りをした7つの事業者の全てが、システムの障害やインシデント（障害につながりかねない出来事）の記録をとっていました。^*3 報告書は、いくつかの事業者の記録の様式を総合した例も示しています。その中から、外部人材活用の原因分析に関係の深い項目を抜き出すと、次のとおりです。

この例では、分析結果の欄が根本原因、作り込み原因、見逃し原因に分かれています。報告書は語の定義までは示していないため、表の括弧内は語に沿って補ったものです。作り込み原因と見逃し原因を分けて書いておけば、問題が入り込んだ工程と、それを見つけられなかった確認の工程を、別々に見直せます。たとえば委託した作業の不具合が受け入れ時の確認で見つからなかったなら、見逃し原因として自社の確認の手順を見直します。

外注先の欄は、委託先ごとに原因を集計するときにも使えます。ただし、委託先の名前だけを見ていると「委託先を替える」という対策にしかつながりません。根本原因の欄とあわせて読み、自社の任せ方に共通する原因がないかを確かめます。仕様変更の記録の残し方は「外部人材活用の失敗を減らす、仕様変更を4段階で残す記録」で扱っています。

つまずきやすい点

一つ目は、分析を自社だけ、または委託先だけで行うことです。ガイドブックは、教訓を作るメンバーには関係する部門から漏れなく参加し、部門外の第三者も加わるべきだとしています。外部人材が関わった失敗では、委託先の担当者か管理者にも分析の場に加わってもらわないと、委託先の中で何が起きていたかという事実が集まらず、根本原因まで下りられません。

二つ目は、分析の結果を次の案件で使える形にしないことです。ガイドブックは、教訓を作ってもなかなか活用されないことが多かったと振り返り、教訓を分類する目的の一つに「調達時の指示・確認」を挙げています。 委託先との契約や発注の段階で確かめる事項として整理しておけば、次の案件の見積りや契約の場でそのまま使えます。

三つ目は、原因分析を現場の担当者だけの作業にしてしまうことです。教訓を共有することが評価される組織の文化を、経営層が主導してつくることも重要です。失敗を報告しても不利にならないことを分析の前に関係者へ伝えておくと、障害状況表に載せる事実を集めやすくなります。

外部に委託するときに確認しておきたい点

原因分析で見つかった根本原因は、次の委託の前に確かめる事項に置き換えられます。先の事例の再発防止策をもとにすると、契約の前に次の点を確認しておくと、同じ種類の失敗を防ぎやすくなります。

• トラブルが起きたときの報告と連絡の窓口、報告の時機（自社側と委託先側の両方）
• 役割分担とサービスのレベル、責任分界点が契約に書かれているか
• 委託先が他の業者の製品や作業に頼っている場合、その業者とのトラブル対応の体制
• 失敗が起きたときに、委託先が原因分析に加わり、記録を提供すること

4つ目は事例の再発防止策には無い項目ですが、契約の段階で取り決めておくと後で頼みやすくなります。複数の委託先に作業を分けて任せる場合の役割の決め方は「SESパートナー複数社のベンダーコントロール｜役割分担を決める」で扱っています。

まとめ：直接原因と根本原因を分けて考える3つの点

直接原因と根本原因の違いと、外部人材活用の失敗への当てはめ方は、3つの点に整理できます。第一に、直接原因は問題を直接引き起こした第一次的な原因、根本原因はその背後にある要因を掘り下げた原因であり、問題そのものとも分けて書くこと。第二に、直接原因からは再発防止策を、根本原因からは再発防止策と未然防止策を導くため、担当者や委託先の力量で分析を止めないこと。第三に、委託先にも分析に加わってもらい、根本原因と関係する外注先を記録に残して、次の契約で確かめる事項に置き換えることです。この3点を踏まえておけば、「委託先を替えたのに、同じ食い違いがまた起きた」という事態を避けやすくなります。原因分析の進め方や、次の案件を任せる人の選び方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：独立行政法人情報処理推進機構（IPA）「情報処理システム高信頼化教訓作成ガイドブック（ITサービス編）」（https://www.ipa.go.jp/archive/files/000051042.pdf）。出典：IPA、2016年。2章（教訓を作成する手順、障害状況表、なぜなぜ分析、なぜなぜ分析による再発防止策／未然防止策の検討、表2.2-1 主要原因分析手法一覧、教訓のまとめ方、効果の検証）、3.1節、4章・5章、参考1（障害事例と教訓G7）を参照（2026年10月確認）
2. *2　参考：独立行政法人情報処理推進機構（IPA）「情報処理システム高信頼化教訓活用ガイドブック（ITサービス編）」（https://www.ipa.go.jp/archive/files/000051041.pdf）。出典：IPA、2016年。1.3 活用メリット（再発防止対策と未然防止対策）、2.2.17 仮想化時の運用管理に関する教訓（T8）を参照（2026年10月確認）
3. *3　参考：独立行政法人情報処理推進機構（IPA）「情報システム障害の再発防止のための組織的マネジメントの調査WG報告書」（https://www.ipa.go.jp/archive/files/000004616.pdf）。出典：IPA ソフトウェア・エンジニアリング・センター、2012年4月5日。調査対象7事業者への聞き取り、2.2(8) 情報システムの障害などの記録、図表2-5 障害やインシデントの記録内容（例）を参照（2026年10月確認）
4. *4　参考：独立行政法人情報処理推進機構（IPA）「障害管理の取組みに関する調査」概要調査報告書（https://www.ipa.go.jp/archive/files/000004666.pdf）。出典：IPA ソフトウェア・エンジニアリング・センター、2012年11月5日。第1部 3.2 障害管理フレームワーク(9) 再発防止の事例を参照（2026年10月確認）

Tweet