Home
Coded Chords

NHK vs 日本IBM：89億円案件の破綻を勝手に思考する

NHKが日本IBMに対して54億円の損害賠償を求めて提訴した大型システム移行の失敗。 元IBM社員の視点から、組織管理の問題点、プロジェクトが頓挫した原 因、そして2027年に迫るメインフレームEOLへの対応策を勝手に検討してみました。

By Toshiyuki Yoshida

NHK問題

日本放送協会（NHK）がシステム開発の中止を巡り日本 IBM を提訴しています。以前日 本 IBM に勤務していた経験があり関わりもあったため気になったのでまとめてみまし た。ただし、すでに日本 IBM を離れて 3 年以上経過しており、内部事情を知る立場には ありません。あくまで報道を読んだ第三者としての感想にすぎないことをご了承くださ い。

経緯

日本放送協会（NHK）がシステム開発の中止を巡り日本 IBM を提訴しています。以前日 本 IBM に勤務していた経験があり関わりもあったため気になったのでまとめてみまし た。ただし、すでに日本 IBM を離れて 3 年以上経過しており、内部事情を知る立場には ありません。あくまで報道を読んだ第三者としての見解であることをご了承くださ い。

プロジェクトの背景と計画

  • NHK は富士通製メインフレームで稼働する営業基幹システムの刷新を計画。富士通 製メインフレームが EOL を迎える 2027 年 3 月末までに現行システムを別のプラット フォームに移行する必要があった。
  • 対象となった業務システムは、メインフレーム上を中心に構築された「営業基幹シ ステム（EGGS）」。同システムは受信契約者の契約情報の管理や受信料の請求処理な ど、NHK の受信料関係業務全般を支えている。2001 年 8 月から 20 年以上稼働しており、 度重なる更改を経てきた。
  • NHK はこのシステムをオープン系に移行することを決め、プラットフォームとして Google Cloud Platform（以降、 GCP）を選択。GCP の採用理由は「当協会の別システム で利用実績があった」ためと報道されている。

移行準備と入札

  • NHK は 2020 年 8 月、アクセンチュアの支援を受けて要件定義書の作成に着手。同定義 書によると、移行対象となるプログラムは約 1030 万ステップ。
  • ホスト側のプログラムには、COBOL や JCL（ジョブ制御言語）、ADL（Aim Description Language）、アセンブラーなどが約 790 万ステップ。
  • ホストと接続するクライアント側には、PowerCOBOL や C、C++ で記述したプログラ ム（約 240 万ステップ）などがあった。
  • 2022 年 9 月、NHK は新システムへの移行業務について公開入札を開始。入札したのは 日本 IBM を含む 3 社。2022 年 12 月に委託金額 89 億 5842 万 6004 円（税込み）で日本 IBM が 受注。

プロジェクトの進行と問題発生

  • 日本 IBM は 2023 年 1 月からプロジェクトを開始。2023 年 3 月末までに現行システムの 分析や移行計画の妥当性を判断するアセスメント工程を完了。
  • 日本 IBM は対象システムの「業務管理機能(約 40 万ステップ)」をリライト方式で移 行することとし、2023 年 4 月から 2024 年 2 月末までにアーキテクチャー設計・基本設計 を完了。
  • リライトについて、ハンガリーの FreeSoft も担当することになった。
  • ところが 2024 年 3 月になって日本 IBM は詳細設計に進めず、「最低 16 カ月の延伸が必 要」と NHK に通知。
  • その後代替策を模索するも、2024 年 5 月に日本 IBM は 18 ヶ月の延伸が必須で予定の納 期遵守が難しいことを通告。

契約解除と提訴

  • これを受け、2024 年 8 月に NHK は EOL までに移行はできないと判断し日本 IBM との業務 委託契約を解除。
  • NHK は 2025 年 2 月 3 日付で日本 IBM を提訴。システム開発の業務委託契約の解除に伴う 支払い済み代金の返還と損害賠償を求め、請求額は 54 億 6992 万 7231 円。

クラウド基盤への移行業務を日本 IBM に委託しましたが、上記のようプロジェクトは難航しました。 昨年、納期に間に合わないことが判明し、日本 IBM との委託契約解除に至ります。 NHK は 54 億円の損害賠償を請求し、日本 IBM も真っ向から反論している状況です。

個人的な評価

経緯を整理してみても、責任の所在や意思決定プロセスには不明瞭な点が多く、特に 「誰が移行方式を最終決定したのか」という重要な点さえ判然としません。公開情報 だけでは全体像の把握は難しいものの、この事例から読み取れる教訓と問題点につい て、IT 業界での経験を踏まえて私見を述べたいと思います。

NHKについて

IT プロジェクトに関わった経験がある人であれば、「NHK はプロジェクトを適切に統制できていなかったのではないか」という印象を持つでしょう。

高リスクプロジェクトの体制不備

20 年以上運用してきたメインフレームの業務システムを別のプラットフォームに移 行するという作業は、本質的に高リスクなプロジェクトです。このような移行を成功 させるためには、最低でも以下が前提条件となります。

  • 現行システムの機能要件の完全な把握
  • システム内部構造の詳細な理解
  • 業務ロジックに関する十分な知見

今回の事例では、現行システムの開発・保守を担当し、これらの知見を有していたであろう富士通ではなく、日本 IBM が移行を担当することになりました。このような状況で成功するためには、NHK 自身が十分な知見を持ち、プロジェクトに積極的に関与することが不可欠だったはずです。

しかし経緯を見る限り、NHK は日本 IBM に発注した後、主導的な役割を果たさず「委託して任せる」というスタンスだったのではないかと推察されます。

組織改革の影響

この移行の要件定義と IBM への発注が決まった 2020 年〜2023 年の時期は、前田晃 伸氏が会長を務め、多数のコンサルタントを起用して中期経営計画のもとダウンサイ ジングと構造改革を推進していた時期と重なります。これを考慮すると、以下のよう な懸念が浮かび上がります。

  1. 意思決定の歪み: 移行方式がアーキテクチャー上の合理性よりも、組織内の政治的動向によって決定された可能性

  2. 知識の流出: 50 歳以上の早期退職や管理職の大幅削減（3 割）の結果、以下のような問題が生じた可能性

    • 基幹システムのプロジェクトを適切に統制するノウハウの喪失
    • 各業務に関連した要件を検証するための深い知識の流出
    • システム移行に必要な経験を持つ人材の減少

リーダーシップの問題

前田晃伸氏は富士銀行出身で、最終的にみずほフィナンシャルグループの社長・会長 を務めた人物です。彼の在任中、みずほは 2000 年代に勘定系システムの統合で大規 模な障害を経験しています。 みずほ自身のシステム障害特別調査委員会の報告 や日経クロステックの記事に よると、その障害の主な原因は次の通りとされました。

  • 現行システムに対する知見の欠如
  • 危機的状況に対応できる組織力の欠如
  • 経営層の IT 統制力の欠如

これらの問題点は、今回の NHK の事例にも当てはまる可能性があります。経験豊富なシニア層の人員整理、富士通から日本 IBM への移行担当の変更、そして安易に大胆な移行方針を許容する経営判断というパターンが、みずほの過去の失敗と類似しています。

現在の契約解除により移行計画は頓挫していますが、2027 年の EOL は確実に迫ってい ます。NHK は今後どのような対応をとるのか、注目される点です。

IBMについて

プロジェクトを十分に管理できなかったクライアント側に対してベンダーとして同情すべき点はありますが、日本 IBM 側にも以下のような問題点があったと考えられます。

プロジェクト受注の判断

  • 高リスクプロジェクトの安易な受注: 富士通が開発・保守し、アクセンチュア が要件定義を実施した大規模システムの移行プロジェクトは本質的に超ハイリスクで す。このような状況下でプロジェクトを受注すること自体、リスク管理の観点から疑 問が残る。
  • アセスメント期間の不足: 2023 年 1 月から 3 月末までの約 3 か月間でのアセスメ ント工程は、1000 万ステップを超える大規模システムの分析としては明らかに短すぎ ました。事実、後に要件定義では明らかになっていなかった文書化されていない仕様 や変更が浮上している。

見積りと実行体制の問題

  • 予算の不足: 40 万ステップのリライト方式による移行に対して約 90 億円弱とい う見積もりは、プロジェクトの複雑さを考慮すると低く見積もりすぎた可能性がある
  • パートナー選定の疑問: メインフレームからのモダナイゼーションに実績のあ る TIS などの国内企業ではなく、実績が不明確なハンガリーの FreeSoft を選定した理 由が不明。特に過去にも同様の失敗事例があったにもかかわらず、このような選 択をした判断には疑問が残る

組織的課題

おそらく日本 IBM 内ではコミュニケーションセクターがこのプロジェクトを担当して いたと推測されますが、金融セクターなどと比較すると大型案件の経験が少なく、こ のような複雑な移行プロジェクトに対する十分な経験者も不足していた可能性があり ます。それにもかかわらず、受注に踏み切ってしまったことが、後の問題につながっ たのではないでしょうか。

同時に、移行の複雑さを当初から認識していたにもかかわらず、クライアントに対し て十分なリスク説明や実現可能な代替案の提示が不足していた可能性も否定できませ ん。大規模プロジェクトでは、技術的な実行能力だけでなく、リスクの透明な伝達と 現実的な期待値の設定も成功の鍵となります。

リライト方式の移行について

メインフレームのシステムは富士通の撤退などもあり、多くの企業がライフサイクル終了に向けた対応を迫られています。こうした状況下で、「リライト方式」によるオープン系やクラウドへの移行を実施・計画している企業は少なくありません。

リライト方式とは

リライト方式とは、既存のメインフレームのコードから機能や要件を分析し、現代の 技術、言語、アーキテクチャーを使ってシステムを一から再設計していく手法です。 一般的な流れは次の通りです。

  1. 既存コードの自動分析（パターン認識や AI、機械学習などを利用したツールの活用）
  2. ビジネスルールや処理ロジックの抽出
  3. コード変換ツールを用いた Java などの現代的言語への自動変換
  4. 必要に応じた調整と最適化

リライト方式の問題点

私はメインフレームでの開発・保守経験と、現代的な言語やフレームワークでの開発 経験の両方を持つ立場から、このリライト方式には以下のような本質的な問題がある と考えています。

暗黙知の喪失

コード分析では、コードに埋め込まれた文書化されていない次のような 「暗黙知」を十分に捉えることができません。

  • ビジネスルールの背景にある理由
  • 例外処理が導入された経緯
  • 特定の実装が選ばれた理由

これらの理解がないまま移行すると、移行後のシステム維持できない可能性があります。

保守性の低下

コード変換ツールによって生成されたコードには以下のような問題が生じがちです。

  • 可読性の低さ（人間による理解が困難）
  • 非効率な構造やアルゴリズム
  • デバッグや修正の困難さ

つまり、移行が完了したとしても、その後の保守作業は極めて難しくなる可能性があります。

技術的負債の継承

現行システムの非効率で古い設計思想がそのまま新しいプラットフォームに移植され てしまいます。これは本来、システム刷新の大きな目的である技術的負債の解消とい う利点を失うことを意味します。

新たな依存性の導入

コード変換ツールはしばしば固有のランタイムやライブラリに依存します。

「メインフレーム」という特定プラットフォームの縛りから逃れるために導入したは ずが、さらに短い寿命、かつ保守が難しい可能性のある別の依存関係を作り出してしまう 矛盾が生じます。

組織的スキルの阻害

要件定義・設計を IT 担当者が経験できず、新しいプラットフォームに対する実践的な 知識やスキルが組織内に蓄積されません。結果として、移行後も組織としての技術的 対応力が向上しない状態に陥ります。

総合的評価

以上を踏まえると、リライト方式は短期的には魅力的に見えるます。 しかし、長期的には割に合わないものと思えます。

  • 移行プロジェクト自体のリスクが高い
  • 移行が成功したとしても、保守性や拡張性に深刻な問題を抱えたシステムになる可能性が高い
  • 組織としての技術力向上や知識蓄積に寄与しない

では、どうすべきか

私は「グリーンフィールド開発」(Greenfield Development)しかないのかなと思います。

グリーンフィールド開発は、具体的には次のようなものです。

  • 既存コードを参照せず、現在のビジネス要件を基に新たに要件定義フェースを行う。
  • レガシーシステムの制約や過去の設計判断に縛られない。
  • 最新技術やアーキテクチャを自由に選択する。
  • ビジネスプロセス自体の見直しや最適化も同時に行う。

「リライト方式」との違いは、リライトが既存システムの機能を基準に再構築するのに対し、グリーンフィールド開発は既存システムの機能にこだわらず、現在のビジネスニーズから改めて考え直す点です。当然、要件定義からやり直すため、より多くの時間とステークホルダーの関与が必要になります。

しかし、以下のように考えてどうでしょう。

  • 企業の競争力の源泉とならないシステム
    • 独自の社内システムは捨て、システム移行でなくカスタマイズしないSaaS などに置き換えるリエンジニアリングで対応する。
  • 企業の競争力を生み出すシステム
    • 要件を理解しておくことは、いずれにしろ企業として必須。ならば、コードから逆算するのでなく、要件をきちんと今のビジネスに合わせて定義したほうがよい
    • 要件定義をゼロから実施することで、要件定義の知見も社内に蓄積される
    • 必要であればリライトで使われる分析ツールを併用して、要件定義の補強として使えば良い
    • 肝は要件定義フェーズを行うことで、アーキテクティングや設計を確実に実施できること
    • アーキテクティングや設計ができれば、あとは普通の開発

どうでもよいシステムでも最初抵抗があるかもしれません。しかし、SaaS などに乗り換え ることでシステムに縛られず身軽になれます。

競争力を生み出すシステムはビジネスからの要求の変化も激しいので、要件定義から開発までスピードを持ってできる対応力が IT にも問われているはずです。これを機にゼロから開発するほうがシステムの文書化、知見やスキルの蓄積もでき結果的にはお手軽に移行するより良い結果を生むと思います。

結論

NHK と日本 IBM の訴訟は、大規模システム移行プロジェクトが孕む本質的な課題を浮き 彫りにしています。長年運用された基幹システムの移行には、組織の体制、プロジェ クト管理の手法、そして技術的なアプローチの全てが適切に機能する必要がありま す。

今回の事例では、NHK 側の要件理解とプロジェクト統制、IBM 側の計画策定とリスク評 価、そして双方のコミュニケーションのいずれにも課題があったように見受けられま す。訴訟の行方はともかく、メインフレーム EOL という避けられない課題に対して、 NHK は今後どのような戦略で対応していくのか注目されます。

システム移行の方法論としてのリライト方式についての考察は、この事例から派生し た 1 つの視点に過ぎませんが、多くの組織が直面している課題にも当てはまるのでは ないと思います。