八重洲テックソリューションズ株式会社 | Decision OS 意思決定判断基盤 & 教育・研修

Why Now

これは一部の失敗ではない。
構造の問題です。

ITプロジェクトの損失は、現場だけの問題では終わりません。

公開情報ベースでも、システム開発の中断、減損、訴訟、検収紛争は繰り返されています。問題は個人の能力ではなく、判断のタイミングと構造です。

判断が遅れた時、損失は一気に経営課題へ変わります。

事案	時期	金額	概要	状態
NHK vs 日本IBM	2025年提訴	約54.7億円	営業基幹システム開発に関する契約を巡る事案。	係争中
日本通運 vs アクセンチュア	2024年提訴	約124.9億円	成果物品質や検収条件等を巡るシステム開発紛争。	係争中
日本通運（NXHD）	2022年	約154億円	システム開発見直しに伴う減損損失を計上。	損失計上
京都市基幹システム刷新	2020年公表	最大約99.9億円	基幹システム刷新プロジェクトの中断に伴う費用が公表。	損失公表

製品詳細を見るお問い合わせ・デモ相談

※各社公表資料、判決文、報道等の公開情報をもとに整理。
※本表は公開情報に基づく事実整理であり、特定企業の評価・批判を目的とするものではありません。

Reality

これは、
業界全体の
構造問題だ。

個別企業の失敗ではありません。大手企業が、一流コンサルが、有名ベンダーが、同じ失敗を繰り返しています。

500人月以上の案件

工期遅れが発生している。予算超過は39.6%、品質不満は29.2%。大規模プロジェクトほど崩れる。

Source: JUAS 企業IT動向調査

賠償請求の最高額

0億円

日本通運がNXHD決算で計上した減損損失。さらに124.9億円の訴訟が並行して進行中。

Source: NXHD 2022年12月期決算

私たちの現場経験

0年

ITプロジェクト管理の実務経験。炎上案件救済の専門家として、現場の失敗構造を知り抜いています。

Representative Director

Law Trend — 2020年以降の判例変化

今や「ユーザー側」も訴えられる時代に入った。

〜2015年頃　ベンダー責任優位の時代。スルガ銀行 vs IBM（約42億円）がその象徴。

2015〜2020年　ベンダーのプロジェクトマネジメント義務が厳格化。

2020年〜現在　ユーザーの協力義務違反も厳しく問われる新フェーズへ。

旭川医大 vs NTT東日本（2020年確定）では、ユーザー側の協力義務違反として14.9億円をユーザーが支払うよう命じられた。野村証券 vs 日本IBM（2021年高裁）では一審の逆転となり、ユーザー側への支払命令が確定。判断を遅らせることが、法的リスクになる時代です。

「判断すべきタイミングに、判断できる構造がなかった」。これが失敗した全プロジェクトに共通する、真の原因です。

Issue

なぜ、多くの
プロジェクトは崩れるのか

Common Root Cause

すべての炎上は
「上流の要求の曖昧さ」から
始まっている。

発注側の要求が、そもそも曖昧だ

自業務しか見えていないまま要求を出す。周辺業務への影響は後になって判明し、大きな手戻りを生む。これがすべての起点。

→ 炎上の根本原因はここにある

SIerの業務知識不足が、要件定義を歪める

発注側の意図を読み取れないまま要件が固まる。後工程になるほど修正コストは膨らみ、小火が大炎上へと変わる。

→ 要件定義のミスが後工程に歪を残す

炎上が始まると、実作業どころでなくなる

デスマーチに入ると判断する余裕すらなくなる。問題が可視化される頃にはすでに手遅れで、損失が経営課題へと変わる。

→ 京都市案件・7年間の迷走の根因

判断の遅れが、法的リスクになる時代

2020年以降、仕様確定・意思決定の遅延はユーザー側の「協力義務違反」として法廷で問われる。判断できない構造が訴訟を招く。

→ 旭川医大・野村証券の逆転判決

問題は明確です。情報が足りないのではありません。要件定義の前に、要求を掘り下げる構造が足りないのです。だから同じ失敗が、会社を変えても、案件を変えても、ベンダーを変えても繰り返されています。

Iceberg — 訴訟は氷山の一角に過ぎない

表に出ない損失の方が、
はるかに大きい。

訴訟になるのは、失敗の中でも「争う体力と証拠がある案件」だけです。水面下では、はるかに多くのプロジェクトが静かに損失を計上し、誰の記録にも残らないまま消えています。

Pattern 01

静かなる撤退

経営陣の交代や方針転換を理由に、ひっそりと開発を中止。開発費は全額減損、社内では「勉強代」として処理される。

→ DX/PoC失敗の大半がこのパターン

Pattern 02

塩漬け

稼働はしたが使い勝手が悪く誰も使わない。旧システムとの二重稼働が続き、運用保守費が永続的に垂れ流される。

→ 自治体・レガシー刷新で頻発

Pattern 03

デスマーチの完遂

莫大な追加コストをかけて無理やり稼働させる。ベンダー側は持ち出し赤字、ユーザー側は不具合対応に追われ続ける。

→ 中堅ベンダーとの案件で頻発

Why Not Lawsuit? — なぜ訴訟にならないのか

レピュテーションリスク

訴訟になると「開発に失敗した会社」として株価・採用・取引に悪影響。双方が表沙汰を避けます。

証拠の欠如

アジャイル・準委任契約では善管注意義務違反の立証が困難。争えば負けるリスクがある。

ベンダー依存の継続

現行システムの保守を同じベンダーが握っている場合、訴訟すると運用が止まる。身動きが取れない。

つまり、訴訟件数はこの問題の深刻さを何%も反映していない。表に出た損失の水面下に、何倍もの損失が静かに積み上がっています。「傷口が浅いうちに打ち切る判断」をいかに仕組みとして持つかが、今の経営の最重要テーマになっています。

Approach

解決策は、
上流にある。

"要件定義の前に、
要求を掘り下げる。"

炎上の根本は要件定義ではなく、その前の「要求の曖昧さ」にあります。私たちは要件定義の前にプロトタイプで要求を掘り下げ、全体の大枠を作ることを最善策と考えます。その上流から、見積・進捗・品質・リスク・経営判断まで一気通貫で支えるのが「Decision OS」です。仕組みと人材の両輪で、企業の意思決定構造を設計します。

Upstream

要件定義の前に、要求を掘り下げる。

プロトタイプで全体の大枠を作り、発注側の要求の曖昧さを可視化します。炎上は上流で防ぐ。

Control

小火のうちに、判断する。

見積・進捗・品質・リスクをつなぎ、炎上の予兆を早期に検知。根拠を持って次の一手を判断します。

Embed

判断の構造を、組織に定着させる。

ツール導入で終わらせず、教育と運用支援によって「判断できる組織」を設計します。

BEYOND THE
Failure.

これは一部の失敗ではない。
構造の問題です。

これは、
業界全体の
構造問題だ。

なぜ、多くの
プロジェクトは崩れるのか

見える化だけでは、
もう足りない。

私たちは、3つの入口で支援します。

私たちについて

判断基盤

定着支援

自社データを、
判断につながる構造へ。

BEYOND THEFailure.

これは一部の失敗ではない。 構造の問題です。

これは、業界全体の構造問題だ。

なぜ、多くのプロジェクトは崩れるのか

見える化だけでは、もう足りない。

私たちは、3つの入口で支援します。

私たちについて

判断基盤

定着支援

自社データを、判断につながる構造へ。

BEYOND THE
Failure.

これは一部の失敗ではない。
構造の問題です。

これは、
業界全体の
構造問題だ。

なぜ、多くの
プロジェクトは崩れるのか

見える化だけでは、
もう足りない。

自社データを、
判断につながる構造へ。