NHKシステム再構築はなぜ“失敗”したのか　「メインフレーム大撤退」時代の課題をひも解く：NHKと日本IBMとの訴訟からの教訓（前編）（1/2 ページ）

　NHKの発表によると（注1）、日本IBMの申し出による大幅な契約内容の見直しは容認できないものであり、これが契約解消に至った最大の理由だと筆者は推測する。一方で、2025年2月7日に発表された日本IBMの声明によると（注5）、現行システムの複雑性が判明したため「より確実な移行方式に向けた協議を申し入れたがNHKが応じなかった」としてNHKの訴訟提起に異議を表明している。ただし、日本IBMも大幅な契約変更を提示したこと自体は認めている。

　そういう意味では、日本IBMの対応が当初の契約内容に照らして問題がなかったかどうかが今後の注目点になるだろう。

　まず、今回の訴訟の基となったNHKのITシステム再構築案件（以下、本件）の枠組みを整理しよう。

NHKのITシステム再構築案件に関するスケジュール遅延

2020年8月：　NHKがアクセンチュアの支援を受けて要件定義に着手

2022年12月：　日本IBMが選定され、契約締結（2027年3月納期、5年3カ月のプロジェクト）

2023年3月末：　現行システムの分析・移行計画の妥当性に関するアセスメント工程を計画通り終了

2023年4月〜2024年2月：　基本設計工程開始、2回の延期を経て、当初予定である2023年9月から5カ月遅れで終了

2024年3月：　IBM社から詳細設計工程に進めることができず、16ヶ月以上の遅延が発生することをNHKに表明

2024年4〜5月：　両社で検討するも、5月23日に日本IBMが最低18カ月延伸を正式表明

2024年8月：　EOLまでに移行できないとのことでNHKが契約解除、合計約54億円の代金返還を日本IBMに求める

本システムの規模とプログラミング言語

移行対象は全体で1030万ステップ。対象プログラム言語はCOBOLやJCL、富士通のデータベース生成用言語、アセンブラなど。

本ITシステムの概要と認識

システム全体像から見ると、NHKの基幹システムはさまざまなサーバと接続されており、トラブル時の影響は極めて大きいITシステムだと考えられる。東西で15分のディレードでバックアップされており、大規模災害に対応できる構成になっている。

特にポイントになるところ

業務管理機能（システム基盤と業務アプリケーションの接続システム）40万ステップは、現行機能のままリライト中心で移行（NHKは実現可能性への懸念を日本IBMに表明）。

　　　　　　　　　　　　※当事者の発表内容や報道された情報を基に筆者が作成

　本件は、富士通製メインフレームで稼働する営業基幹システム（EGGS）について新システムを開発し、クラウドに移行する業務委託契約だ。当初の納期は現行システムがEOLを迎える2027年3月末を予定していた。

　NHKのITシステムは富士通のメインフレームで稼働してきた。そのため、富士通のメインフレーム事業撤退による影響が大きいと考えられる。実際に本件は富士通製品のEOL（製品サポート終了）がそもそもの出発点になっている。その意味では、EOLへの対応などに関する契約を双方がどこまで正確に理解していたかが大きな要素になるだろう。

　富士通は2035年度にメインフレームの保守を終了し、2030年度にメインフレームの販売を終了すると発表している。

　これから多くの企業が利用するメインフレームがEOLを迎える中、本件のスケジュールに余裕はなかったと推測される。

　おそらくそのために、2024年3月に日本IBMはスケジュールの「1年半の延伸」をNHKに申し入れた。この変更に加え、当初予定されていた納期である2027年3月末から、2028年9月を納期とする新たなスケジュールが提示された。従って、もともとの2027年3月末納期の日本IBMのコミットメントの度合いも重要なポイントになる。

　実際に日本IBMは「最も期限が短いソリューションで18カ月の延伸が必要だ。それ以上の期間短縮は難しい」とNHKに伝えたとされており、最終的な納期が18カ月以上遅れる可能性を示唆している。

　日本IBMは納期を延伸する理由として「システム品質と性能を確保」を挙げているが、それまでの工程でスケジュールを複数回変更してきた日本IBMをNHKが信頼できないとするのも「無理はない」と筆者は考えている。

システム再構築の本質的課題は？

　先ほども述べたように、今回の案件の中核となっているのが、基幹系ITシステムの再構築だ。日本IBMが申し入れた契約変更がNHKの事業継続に致命的なダメージを与えるのであれば、NHKの判断もやむを得ないと考える向きもあるだろう。

　日本IBMも当然ながら基幹システムが事業継続に関わるものであることは契約時に認識していたはずだ。日本IBMには、開発を請け負うシステムが顧客の事業にとってどの程度の重要性を持つものかを適切に判断して、開発期間や移行期間を適切に設定するというプロとしての見識を求められているというのが今回の教訓だと言える。

　もっとも本件の具体的な契約内容は明らかになっていない。そのため、これ以上言えることはほぼないが、一つ補足するならば、われわれITベンダー業界では日本IBMは契約に関して十分にリスク管理していることで知られている。

メインフレームの衰退とリスク　「待ったなし」の状況

　いずれにしても、日立製作所と富士通のメインフレーム撤退の時期は確実に迫っている。官公庁も含めて大企業を中心に「待ったなし」の状況であることは間違いない。

　保守期間の延長についてある程度交渉できたとしても、メインフレーム技術者の高齢化は進み、技術者の数も減少している。現在でも対応に限界があるだけでなく、今後メインフレームに問題が発生した場合、誰も対応できないという状況が生まれつつある。リスクは既に大きくなっているため、早めの対応が求められる。

　富士通や日立製作所のメインフレームの後継として一般的にはIBMの「IBM Z」シリーズが挙げられるが、実はIBMは「IBM Z」以外のハードウェア事業の多くをレノボ（中国資本）に売却している。今回の趣旨から外れるため、本稿ではこれ以上言及しないが、「メインフレームを使い続ける」という選択肢にはさまざまなリスクがあることを想定すべきだろう。

　本件の内容とはずれるが、EOLが予定されている富士通や日立製作所のメインフレームから「IBM Z」に移行する場合、どのような点がハードルになるだろうか。

　日立製作所と富士通のメインフレームは、IBMのメインサーバーとコンパチブル（互換可能）な機種として市場に導入された。しかし、IBMの機密情報を日立製作所や三菱電機などの従業員が不正に入手しようとしたいわゆる「IBM産業スパイ事件」（1982年）以降、技術の分離は進んでいる。

　通信手順はIBMの「SNA」（Systems Network Architecture）に対し、日立製作所は「HNA」（ Hitachi Network Architecture）、富士通は「FNA」（Fujitsu Network Architecture）で互換性は必ずしも保証されていない。トランザクションマネジャーおよび階層データベースマネジャーはIBMの「IMS」（Information Management System）に対し、日立製作所は「VOS3」であるなど、ソフトウェア製品群も異なっている。データベースの管理システムもIBMの「IBM Dｂ2」に対し、日立製作所は「XDM」（ Extensible Data Manager）だ。

　「COBOL」などのメインフレームで使われているプログラミング言語も、実は各社の製品に合わせて独自の機能拡張や「方言」が存在するため簡単に移植できない。さらにNHKなどの大口顧客に対してはOSやデータベースレベルで個別対応を入れている可能性も否定できない。