【NHK vs IBM】54億円訴訟の真相とは？システム開発の落とし穴

Atom | RSS

このサイトを検索 | Search this site

【NHK vs IBM】54億円訴訟の真相とは？システム開発の落とし穴

＊この投稿は、筆者の経験に基づく見解を記したものです。気分を害する表現があったとしたら、先に誤っておきます。m(__)mペコリ

NHKがIBMを提訴

2025年2月12日、NHKは東京・渋谷の本社で定例会長会見を開き、日本IBMに対し、システム開発にかかる業務委託契約の解除に伴う既払金の返還および損害賠償を求める民事訴訟を2月3日に東京地方裁判所に提起したことを明らかにした。（記事）

訴訟の背景と課題

NHKが日本IBMに発注した「営業基幹システム」は既に契約解除されており、訴訟請求額は54億6992万7231円。

日本IBMは外資系のため、日本企業のように馴れ合いで仕事をしない。仕様に書かれていないことは追加費用を要求するのは当たり前の世界なので、今回の裁判に注目している。

強気なNHK会長

investigating — 稲葉延雄NHK会長の見解「これまでの経緯を考えますとNHK側に非はなく、日本IBM社側に責任があると考えております」

NHK会長はシステム開発に関わった経験があるのだろうか。

システム開発において最も重要なのは「要件定義書」であり、これはプロジェクトの根幹を成すものである。プロジェクトマネージャー（PM）は、要件定義書に基づいて工期を設定し、費用管理や工程管理を行う。そのため、発注者と開発者の双方が要件定義書に合意した後は、原則として仕様変更は認められない。

頻繁な仕様変更が発生？

報道によると、要件定義が完了し、システム構築フェーズに入ってからも仕様変更が頻繁に発生していたようである。そのため、開発現場は大きな混乱に陥っていたことが容易に想像できる。

システム開発では、仕様変更が発生すると工程の見直しや追加のコストが必要となり、スケジュールの遅延や品質の低下を招くリスクが高まる。特に、大規模システムにおいて開発途中の変更が繰り返されると、設計の整合性が崩れ、テスト工程にも多大な影響を及ぼす可能性がある。

NHKの入札プロセスとベンダー選定の背景

NHKは準官公庁に分類されるため、大型システムの開発案件は通常、入札によって決定される。今回の案件において、これまでNHKのシステム開発を担当してきた富士通が落札できなかったという事実は注目に値する。次のことが理由として考えられる。

富士通がプロジェクトのリスクを考慮し、入札を見送った可能性
日本IBMが標準積算額を大幅に下回る低価格を提示した可能性

通常、入札では価格だけでなく、技術力や過去の実績も評価基準となる。しかし、過度なコスト削減が優先された場合、十分な開発体制を確保できず、結果的にプロジェクトの進行に支障をきたすことがある。今回のケースでも、適切な要件定義が行われていたのか、また入札時の評価基準が適切であったのか、検証が必要だろう。

また、大型システム開発では、発注者側のITリテラシーもプロジェクト成功の重要な要因となる。NHK側の要件整理や意思決定のプロセスが適切でなかった場合、それが仕様変更の頻発につながった可能性もある。今後、NHKが同様のシステム開発を進める際には、適切な要件定義と厳格な変更管理を徹底することが求められる。

今後の課題と改善策

今回の問題を踏まえ、NHKはシステム開発におけるプロジェクト管理の強化を図るべきである。大規模システム開発は、多くのステークホルダーが関与する複雑なプロジェクトであるため、発注者・開発者双方の緻密な調整と適切なガバナンスが不可欠である。

具体的には、次の対策が考えられる。

要件定義フェーズの段階で、関係者間の認識を徹底的にすり合わせる
仕様変更を最小限に抑えるための変更管理プロセスを明確にする
入札時に価格だけでなく、技術力や開発実績をより重視した評価を行う

富士通はなぜ落札できなかったのか？

question — NHKが発注したのは、受信料関係業務全般を支える「営業基幹システム」の刷新である。つまり、NHKで最も重要な基幹システムの一つと言える。

旧営業基幹システムと新システムの入札結果

リプレース前の営業基幹システムは、富士通が受託し、メインフレーム上で稼働していた。当然ながら、新システムの仕様書作成にも富士通が協力したはずであり、従来のシステムを熟知している同社は、新システムの入札において圧倒的に有利な立場にあったと考えられる。しかし、それにもかかわらず、最終的に富士通が落札できなかったのは不可解である。

仕様書作成の主体とSIerの関与

通常、システム開発における「発注仕様書（RFP）」は発注者が作成する。しかし、NHKはシステム開発を専門とする企業ではないため、自ら詳細な仕様書を作成することは難しい。そのため、富士通や日本IBMなどのシステムインテグレーター（SIer）の協力が不可欠となる。仕様書の策定に関わった企業は、技術的な知見を持つため、基本的には入札において有利な立場に立つが、今回はその常識が当てはまらなかった可能性がある。

大型システムにおける運用保守の重要性

大型システム開発は、単に構築を完了すれば終わりではなく、その後の運用・保守が極めて重要となる。一般的に、50億円規模のシステム案件では、構築を担当したベンダーが運用・保守契約も受託するのが通常の流れである。

この運用・保守契約には、システムの安定稼働を支援するためのオンサイト対応が含まれることが多く、通常、数名の技術者が常駐することが条件に組み込まれている。このため、運用保守フェーズでは一定の固定収益が見込める。つまり、システム構築フェーズで利益が出なかったとしても、運用保守契約の収益で十分に補填することが可能となる。

また、減価償却を5年と仮定すれば、社内稟議が通れば運用・保守契約による5年間の収益を前提に、システム構築費用の積算を柔軟に調整することができる。この結果、落札の確度を高めることが可能になる。

さらに、常駐要員として若手エンジニアを配置し、OJT（オン・ザ・ジョブ・トレーニング）によるスキルアップを図ることで、コストを抑えつつ技術者の育成も進めることができる。

NHKは旧システムの運用保守に不満を抱えていたのか？

今回の入札結果を考察する上で、NHKが旧システム（メインフレーム）の運用・保守に不満を持っていた可能性も考えられる。

もしNHKのシステム部門が、富士通の運用・保守対応に対して不満を抱いていたとすれば、日本IBMが有利になるような仕様を盛り込むよう働きかけるロビー活動（営業努力とも言える）が奏功した可能性もある。

日本IBMはすでにメインフレーム事業から撤退して久しく、今どきNHKがメインフレームを継承してシステム刷新を行う可能性は低い。そのため、新システムはクラウドベース、オンプレミス、またはハイブリッド環境で開発されることが想定される。

とはいえ、日本IBMが入札においてどのような提案を行い、どのような価格を提示したのかは明らかになっていない。仮に、極端に低い入札額を提示したとすれば、その意図についても慎重に検証する必要がある。

発注側のスキル不足とプロジェクトのリスク

大型システム開発案件では、発注者側のITスキル不足が原因で、要件定義の甘さやプロジェクトマネジメントの不備が発生しがちである。その結果、スケジュールの遅延や、納期のずれ込みが頻発する。

今回の案件においても、今後の裁判で明らかになると考えられるが、「要件定義書」に関して発注者と開発者の双方で十分な合意が取れていたのかが大きな焦点となるだろう。もし、要件定義の段階で不明確な点が多かった場合、仕様変更が頻発し、プロジェクトの混乱を招いた可能性がある。

今回のシステム刷新プロジェクトの経緯を詳しく分析することで、今後の公共系システム開発における課題や改善策を見出すことができるだろう。

今後の検証では、次の点がポイントとなる。

どのようなプロセスで要件定義が行われたのか
発注仕様書の策定に関与した企業の影響力
入札時の評価基準とその透明性

発注者のスキル不足とシステム開発の遅延

大型システム開発では、発注者側（今回のケースではNHKのシステム部門）のITスキルやプロジェクト管理能力の不足が原因で、スケジュールの遅延やコストの膨張が発生することが少なくない。今後の裁判で、「要件定義書」が適切に作成され、双方で明確に合意されていたかが明らかになるだろう。

また、発注者が一度確定した仕様を変更したいと希望するケースも多い。

例えば、「入力画面にボタンを追加するだけ」といった一見すると軽微な修正依頼であっても、実際にはプログラムの大幅な変更を伴うことがある。こうした認識のズレが、システム開発のトラブルを引き起こす一因となっている。

「ボタンを1つ追加」は本当に軽微な変更なのか？

一般的に、ボタンを追加するという作業は単純に見えるかもしれない。しかし、実際にはボタンを押した際の処理を新たに設計・実装する必要がある。その処理が重要な業務ロジックに関わる場合、関連するプログラム全体の改修が必要となることもある。

さらに、コードを修正するということは、単体テストや統合テスト、運用テストといった検証工程にも影響を及ぼすため、結果的に納期の遅延や追加コストの発生につながる。場合によっては、ボタン1つの変更がプロジェクト全体の進行に大きな影響を与えることもあるのだ。

「ボタンぐらいいいでしょ」という日本的な馴れ合いは通用しない

日本企業では、発注者と開発ベンダーの関係性の中で、こうした仕様変更が曖昧に処理されることが多い。「多少の仕様変更は融通を利かせる」という暗黙の了解が存在し、費用の追加請求が行われないケースもある。

しかし、外資系企業である日本IBMの場合は異なる。彼らは明確な契約に基づき、追加の仕様変更には必ずコストを請求するスタイルを取る。

今回の案件では、発注者と開発ベンダーの間でこうした認識の違いが曖昧に処理され、馴れ合い的に進められた可能性がある。この点が、プロジェクトの混乱につながった一因であると推測される。

日本企業の対応：NTTグループの例

例えば、NTTグループ（NTTデータ、NTT東日本・西日本など）は、要件定義後の仕様変更にも比較的柔軟に対応する傾向がある。NTTグループ自体は製造業ではないノンメーカー系のSIerだが、傘下には富士通、日立製作所、沖電気工業などの協力ベンダーを抱えており、大規模案件においてはそのネットワークを活かした柔軟な対応が可能となる。

さらに、NTTグループは豊富な人材リソースを抱えているため、非常事態が発生した際には、収支を度外視してでも大量のエンジニアを現場に投入できる体制を整えている。例えば、プロジェクトの労務費が表向き10であっても、裏では100の追加リソースを計上せずに投入することも可能だ。

「多少の赤字でも最後までやり遂げる」文化

NTTグループは、プロジェクトの収支がわずかでもプラスであれば、多少のコスト超過が発生してもプロジェクトの完遂を優先する傾向がある。そのため、大型の発注者にとっては、非常に頼りがいのあるSIerであると言えるだろう。

しかし、このような日本的な対応は、外資系ベンダーには期待できない。日本IBMのような外資系企業は、明確な契約ベースで動くため、発注者側の意識改革も求められる。システム開発においては、仕様変更のリスクを最小限に抑えるために、発注者自身もITリテラシーを高め、開発プロセスの理解を深めることが不可欠である。

SIer

PC_programming — 50億円規模のシステム構築が可能な企業。（筆者調べ）

50億円規模のシステム構築になると、日本国内でも数社しか対応できない案件だ。

入札仕様書に「オンサイト保守」と書かれた場合、日本国内に保守拠点を持たない企業は応札できない。保守委託はありだが、富士通ならFJBというようにグループ会社へ委託するのが普通。大規模システムの第三者委託は無理筋なので、保守拠点を持たない外資系のコンサルは応札できない。

超大型プロジェクト（4社連合）

みずほ銀行の新基幹システム「MINORI」は、4500億円超を投じて新たに開発された。（記事）

開発に携わったのは富士通（旧第一勧業銀行）、日立製作所（旧日本興業銀行）、日本IBM（旧富士銀行）とNTTデータの4社。大規模システムはこの4社＋αがメインです。


会社	売上高	概要
富士通	3兆8,577億円	国内最大手のSI企業
NEC	3兆900億円	SI事業とハードウェア製品を組み合わせた高い技術の提供
NTTデータ	2兆2,668億円	官公庁や自治体のシステム納入実績に強み
日立製作所	8,767億円	世界有数の総合電機メーカー、積算が高額になるイメージ
日本IBM	7,309億円	AI、クラウド、量子コンピューティングなどの先進技術を活用（みずほ、トヨタ、ANA、セブンイレブンなどに実績）
野村総合研究所（NRI）	5,012億円	コンサルティング、金融ITソリューション、産業ITソリューション、IT基盤サービスを手掛ける
アクセンチュア	710億ドル	世界最大級のコンサルティングファーム
デロイトトーマツコンサルティング	6,720億ドル	世界四大会計事務所の一つ、＊イオン案件ではやらかした実績あり
KPMGコンサルティング	3,840億ドル	世界143の国と地域に約27万5,000人のプロフェッショナルを擁する