日本IBMはどこでミスを犯したのか？　NHKシステム再構築“失敗”から学ぶ：NHKと日本IBMとの訴訟からの教訓（後編）（1/2 ページ）

　その前に、繰り返しで恐縮だが、当事者のどちらかの肩を持つことや訴訟の行方を占うことは本稿の目的ではない。メインフレームを利用してきた企業がITシステムを再構築する際に発生しがちな問題をユーザー企業の経営層やIT部門と共有し、その回避策を本件から学ぶという観点からお話しする。

　念のため申し添えると、報道された情報（注2）（注3）（注4）を参照しているが、契約内容や開発内容について詳細が公開されていないため、筆者の経験に基づく推測で補った部分が多々ある。いわばケーススタディとして本件から教訓を引き出すための論考であり、正確性の追求が趣旨ではないことを了承いただきたい。

　前置きはこのくらいにして、まずは改めて本件の基本的な情報を整理しよう。

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に表明）。

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

超大規模プロジェクトが抱える「構造的課題」

　これらの情報から、本プロジェクトは1000万ステップを超える「超大規模プロジェクト」に該当すると考えられる。また、現行機能を保証する、以前取り上げた日本通運の件同様の高難易度のプロジェクトだと言えるだろう。

　さらに、もともと富士通が担当していたにもかかわらず、他ベンダーである日本IBMが対応しているのだ。

　また、本プロジェクトの重要工程である要件定義書を2年かけて作成したアクセンチュアが実プロジェクトを担当せず、日本IBMが開発している。

　さらに移行後のクラウドとなるターゲットシステムが「Google Cloud Platform」（GCP）であり、日本IBMに十分なノウハウがあるとは言い難いと筆者は考える。

　これらの点から、担当ベンダーである日本IBMの本プロジェクトに対するケーパビリティは高いとは言えないと推察される。

　さらに、あくまでも当事者であるNHKや日本IBMが公開している情報（注5）や報道によるとだが、本件は超大規模にもかかわらず、段階的なリリースを想定していないようだ。つまり一括リリースを選択していることから、リリースのリスクも極めて高いと考えられる。

　ただ、リライトでは「業務管理機能」（40万ステップ）に関してしか言及されていない。業務管理機能以外は、COBOLで構築された現行システムをできるだけそのまま使うことを前提に、最低限の対応に留めているとも考えられる。そういう意味では移行リスクの最小化に努めているように推察される。

　ただその場合も、富士通の固有のデータベースシステムから、GCPで稼働するデータベースシステムの移管などは必要だ。これがそう簡単な作業でないことは申し添えておきたい。

リスクはさらに軽減すべきだった？

　仮定の話として、もし筆者が本件を担当するならどうするだろうか。こうした状況をITシステムの再構築だけで打開するのは難しい。そこで、入札制度の改革や、ITプロジェクトの契約形態や責任範囲の明確化、特に重要なのは顧客との契約、あるいは既存の規制といった法的観点などの制度面を含めた抜本改革を併せて実施することで、ITシステムの移行リスクを最小化するといった解決策を模索するだろう。つまり、制度面を改革することなく、本プロジェクトを成功させるというシナリオ自体を筆者は疑っている。

　さらに、現状の要求仕様では実現が困難だという認識を持っていたがゆえに富士通やアクセンチュアは入札に応じるつもりがなかったのでは……といった穿った見方をしてしまう。