LASSIC Media らしくメディア

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

委託したエンジニアとの作業が予定どおりに進まず、振り返りの会議は「担当者のスキルが足りなかった」で終わってしまう。委託先を替えたのに、次の案件でも同じような食い違いが起きる——。外部人材を迎えて開発や運用を進める現場では、こうしたことが起こりがちです。外部人材活用の失敗の原因分析とは、うまくいかなかった出来事を事実の順に並べ、すぐに見える原因から、その背後にある原因までたどって、次の案件で変えることを決める作業を指します。

原因分析を行うと、委託先の選び方だけでなく、自社の側にも見直す点が見つかります。ただし万能ではなく、起きたときの記録が残っていなければ分析はできません。本記事では、外部人材と開発を進めるマネージャーに向けて、直接原因と根本原因の違い、IPA（情報処理推進機構）が公開している分析の手順と事例、記録に残す項目、そして外部に頼むときに確認したい点を整理します。

外部人材活用の失敗の原因分析とは

IPAは、重要インフラなどで実際に起きたシステム障害を分析し、その結果を「情報処理システム高信頼化教訓集」として公開しています。2016年には、その作成で得たノウハウをもとに、自社の事例から教訓を作る手順を「情報処理システム高信頼化教訓作成ガイドブック（ITサービス編）」にまとめました。^*1 対象はシステム障害ですが、関わった人と行動の流れを並べ、原因をたどって対策を決める進め方は、外部人材と進めた作業のトラブルにも使えます。

ガイドブックは、教訓を作る作業を3つの段階に分けています。個々の障害の原因をたどり、ほかの障害にも共通する形にまとめる段階、原因から対策を導いて教訓にする段階、教訓を現場に当てはめて活用する段階です。^*1

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

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

ガイドブックは、教訓をまとめるときの注意として、「問題」と「原因」を明確に分け、原因は直接原因と根本原因が分かるように書くよう求めています。直接原因は障害を直接引き起こした原因、根本原因は直接原因を生んだ背後の原因です。^*1 問題は「何が起きたか」、原因は「なぜ起きたか」であり、この2つを混ぜると、何を直せばよいのかが読み取れなくなります。

2つの原因の違いは、そこから出てくる対策に表れます。ガイドブックによれば、直接原因からは再発防止策を、根本原因からは再発防止策と未然防止策を導きます。再発防止策は、起きた障害と同じものを繰り返さないための対策です。未然防止策は、まだ障害になっていないが、先に手を打っておくべき要因への対策です。

外部人材活用の失敗で、「担当者のスキルが足りなかった」「委託先の報告が遅かった」という説明のところで分析を終えると、対策は担当者や委託先を替えることだけになります。そこから「なぜその作業をその人に任せたのか」「なぜ報告が遅れても自社の側で気づけなかったのか」と問いを重ねると、任せる作業の決め方や、連絡の取り決めといった自社の側の要因が見えてくることがあります。

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

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

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

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

原因分析の進め方

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

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

対策が決まったら、問題、原因、対策、効果、教訓の項目で1件ずつまとめます。ガイドブックは、教訓の概要は短く、「〜しない」ではなく「〜する」の形で書くこと、固有名詞は匿名化することを挙げています。最後に、原因別に件数を集計し、全体に占める割合の大きい原因を取り出して、教訓でその種類の障害を減らせるかを確かめます。1件ごとの分析だけでは、同じ原因が案件をまたいで繰り返されているかどうかが分からないためです。

記録に残す項目

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

分析結果の欄を根本原因、作り込み原因、見逃し原因に分けている点に注目すると使いやすくなります。作り込み原因と見逃し原因を分けて書いておけば、問題が入り込んだ工程と、それを見つけられなかった確認の工程を、別々に見直せます。たとえば委託した作業の不具合が受け入れ時の確認で見つからなかったなら、見逃し原因として自社の確認の手順を見直します。

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

つまずきやすい点

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

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

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

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

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

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

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

まとめ：失敗の原因分析で確かめたい3つの点

外部人材活用の失敗を原因分析するうえで、確かめておきたい点は3つに整理できます。第一に、問題と原因を分け、直接原因で止めずに根本原因までたどること。第二に、委託先と自社の窓口を登場人物に入れて事実を時間の順に並べ、根本原因と関係する外注先を記録に残すこと。第三に、分析には委託先にも加わってもらい、結果を次の契約で確かめる事項として整理することです。この3点を踏まえておけば、「委託先を替えたのに、同じ食い違いがまた起きた」という事態を避けやすくなります。原因分析の進め方や、次の案件を任せる人の選び方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

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

Tweet