DX失敗事例の見方｜要件・移行・運用の問題と立て直しの確認点

DXの失敗を振り返る時は、起きた問題、目標との差、原因として確認できた事実、次の対策を分けます。システムの停止、費用超過、利用されない状態、検証後の中止では、必要な判断が異なります。本記事では2026年10月27日に確認した監査・規制当局等の公開資料を基に、実例の読み方、五つの確認観点、立て直しと再開の条件を整理します。確認表と手順は本稿の提案で、失敗の発生率や対策の成功率を示すものではありません。

失敗・目標未達・中止は、判定した範囲と時点を明確にする

最初に、誰がどの基準で問題と判断したかを確認します。顧客が手続きを完了できない障害、処理はできるが品質や費用の目標に届かない状態、計画した効果がまだ測れていない状態では、同じ「失敗」の言葉だけで原因と対応を決められません。本稿では、発生した事象と影響、事前の目標、実績と測定条件、未確認の項目を並べることを勧めます。導入した件数や公開日だけで、業務・経営の成果まで達成したとは扱いません。

確認する状態	判断に必要な情報
業務・サービスの障害	使えない機能、影響を受けた人・取引、発生と復旧の時点
目標未達	事前の評価基準、比較対象、期間、実績と不足した条件
効果が未評価	未計測の指標、データ不足、評価を予定する時点
中止・縮小・方式変更	決定の理由、残る業務、費用と移行・引継ぎの条件

検証の結果、効果が小さい、重要な制約を解消できない、別の方法がよいと分かれば、中止や変更を選ぶ場合があります。その判断まで含めて検証の役割を確認します。一方、本番に必要な条件を確認せず放置したことや、失敗を記録しないまま名称だけ変えたことは、別に検討が必要です。検証で得た情報、進めなかった理由、承認と残る作業を記録し、「PoC止まり」という見出しだけで経営層や現場の問題に帰着させないようにします。

失敗率の数字を読む場合も、分母を確認します。全企業か導入企業か、回答者か案件か、失敗だけか一部未達や効果未評価も含むかで意味が変わります。原因の複数回答の割合を、導入した時に失敗する確率へ置き換えません。本稿では、母数、調査期間、抽出方法、質問と分類の対応を確認できない率を、全国共通の実績や自社の成功確率として載せていません。

原因の振り返りでは、起きた順序と当時使えた情報を残します。後から見れば避けられたという感想と、判断時点で確認を求める仕組みがあったかは別です。議事の記録、変更履歴、テスト、監視、問い合わせと費用の資料を照合し、確認済みの事実、原因候補、追加で調べる点を分けます。個人の注意不足だけにまとめず、同じ条件でも問題を検知し、判断へ上げられる仕組みを検討します。

公開された問題事例から、要件・監督・移行後のサービスを確認する

米国GAOの2014年7月30日公表のHealthcare.gov報告の概要は、主要な技術要件が分からない段階での発注、変わる要件と監督上の不足、追加作業への支出を承認する権限の不明確さを指摘しています。公開準備の重要な確認も遅れ、性能要件を満たしたかを検証しないまま公開したと説明しています。本稿はこの公開概要で確認した当時の問題を扱い、現在の同サービスの状態や、日本の調達・契約制度へそのまま当てはめるものではありません。

この事例で自社に問い直したいのは、未確定の要件を誰が管理し、変更が費用・日程・品質へ与える影響を誰が判断するかです。外部へ発注した後も、受け取る成果物、確認する基準、追加作業の承認範囲を具体化します。すべての要件を永久に固定すべきだという結論にはせず、未確定な点と変更可能な点を明示し、検討と実装の範囲を合意する手順として考えます。

英国FCAが2022年12月20日に公表したTSBのIT移行に関する説明は、2018年4月の移行でデータ自体は移せた一方、新しい基盤で技術的な障害が起き、窓口、電話、オンラインやモバイルのサービスが影響を受けたとしています。規制当局は、移行計画の管理や外部委託に伴う業務上のリスクの管理にも問題を指摘しました。本稿では当局の公開説明の範囲を扱い、現行の英国金融規制の全要件や、全企業の責任をこの事例から判定しません。

ここから本稿が提案するのは、データを移せたかに加え、利用者が移行後に必要な取引を完了できるかを確認することです。接続先、負荷、権限、窓口や問い合わせ、例外、障害時の代替と復旧までを対象にします。試験環境の一部で動いた結果を、本番の全体で継続できる証拠としないようにします。委託先の説明を受け取るだけでなく、自社の判断者が根拠と未確認条件を把握できる形にします。

二つの事例は規模も制度も時期も異なり、DX全体の代表標本ではありません。特定の開発方法や外部委託が必ず失敗するという因果関係を、この二例だけで導くこともできません。本稿では、要件、変更と承認、監督、移行と業務継続という検討の観点を取り出します。自社へ適用する際には、顧客への影響や契約、運用の制約に応じて確認項目を選び、実際の記録と照合して判断します。

五つの確認観点で、ツール・業務・現場・本番条件・責任を点検する

次の五つは本稿が点検のために整理した観点で、発生頻度の順位や、網羅的な原因分類ではありません。問題は複数にまたがる場合があります。AIを採用したことだけを成果にする、業務を理解せず現行の手順を写す、現場で使う条件を欠く、検証と本番の差を扱わない、責任と保守が曖昧なままにする、といった状態を具体的な資料で確認します。特定の年に急増したという裏付けのない傾向は付けません。

確認観点	起きている状態の例	次に確認するもの
目的と評価	ツールの導入が目標になり、改善したい問題が曖昧	対象者の課題、目指す成果、比較前と評価方法
業務と要件	例外や判断を落とし、転記や承認だけが増える	現行の流れ、不要な作業、入力・出力と例外
現場での利用	権限、時間、教育、問い合わせ先が足りない	実際に使う役割、負担、練習と支援
本番への条件	通常例のデモだけで展開を判断する	データ量、接続、品質、失敗時の代替と復旧
責任と継続	変更・承認・保守を誰が担うか分からない	責任者、判断権限、記録、費用と引継ぎ

厚生労働省のIT業界の働き方に関する解説は、曖昧な要求が手戻りや長時間労働のリスクにつながるとし、目的・必要な機能の明確化、業務を理解する人の参加やプロトタイプ等を挙げています。本稿ではこの要件の確認の考え方を参考にします。同ページの表現を、全国のDX失敗原因の最新順位や、特定の要件定義方法の効果を実測した比較結果とはしません。

現場が使わない場合には、単に抵抗していると決めず、入力の二重化、応答の遅さ、必要な情報の欠落、品質や責任への懸念を確認します。聞き取りだけで終えず、役割に沿った通常処理と例外を試してもらい、どこで止まるかを記録します。教育で解決する問題と、権限や業務設計を直す問題を区別します。個人の利用回数だけで能力や態度の評価へ結び付けないことも必要です。

AIでは、候補の生成、確認、確定、外部への実行を分けます。根拠が欠けた結果、指示の取り違え、接続失敗、同じ処理の再実行をどう扱うかを決めます。「正しい答えが一度出た」と「権限を守り、例外も含め継続運用できる」を別に評価します。失敗した結果を隠して成功例だけ選ばず、対象外と未計測も示し、業務責任者が採否を判断できる材料にします。

立て直しは、影響の把握と判断条件を整えて再検証する

問題が起きている場合は、まず影響を受ける人と業務、継続している処理、データの状態を確認します。必要に応じて対象機能の停止、範囲の縮小、代替手順への切替を判断できる体制を使います。原因が確定するまで利用者への影響を放置しないよう、復旧・問い合わせ対応と原因調査の担当を決めます。記録を残し、緊急の変更も後から何を行ったかを照合できるようにします。

次に、元の目標を据え置いてよいか、前提が変わったかを確認します。未達を数字の定義変更で消さず、品質、確認修正、待ち時間、他部署や顧客へ移った負担、利用・保守の費用を含めて評価します。工数換算をそのまま現金支出の削減とはせず、推定と実績を分けます。すでに使った費用の大きさだけで継続を決めず、これから必要な費用、得られる便益、代替策と残るリスクを検討します。

再検証では、今回確かめる仮説、対象、入力データと評価方法、終了時の判断者を決めます。継続・修正・中止の条件に加え、本番へ移す前に必要な契約、権限、連携、監視、教育、例外と引継ぎを確認します。性能の目標を満たしただけで自動的に本番化せず、未解決条件を一覧にします。再挑戦の回数が増えれば成功率が上がる、特定のパートナーを使えば失敗しない、といった保証は置きません。

他社の良い取組を取り入れる場合も、DXの業種別公開事例と、成果・運用条件の確認点で、対象工程、時点、実績と推定、自社との違いを整理できます。成功例と問題事例のどちらも、全社の結果を一言で評価する材料ではなく、検証すべき前提を見つける材料として使います。再開後も、担当者が交代して運用できるか、同じ問題を検知できるか、効果と費用が続くかを確認します。

renueのFDE支援では、現場の要件整理から設計・実装・運用、KPI設計と成果レビューを相談できます。業務の受渡し、確認・承認画面、変更や実行の記録、例外対応と引継ぎを具体化する範囲です。API、権限、データ形式とセキュリティ条件を確認して支援範囲を決めます。法的責任の判定、規制対応の監査、特定製品の専門移行や障害の完全回避、共通の費用・期間やDX成功を一律に保証する案内にはしません。現在の影響、困っている業務、利用する情報と判断者を整理して検討します。