NHK vs 日本IBM：89億円案件の破綻を勝手に思考する
NHKが日本IBMに対して54億円の損害賠償を求めて提訴した大型システム移行の失敗。元IBM社員の視点から、組織管理の問題点、プロジェクトが頓挫した原因、そして2027年に迫るメインフレームEOLへの対応策を勝手に検討してみました。 日本放送協会（NHK）がシステム開発の中止を巡り日本IBMを提訴しています。以前日 本IBMに勤務していた経験があり関わりもあったため気になったのでまとめてみまし た。ただし、すでに日本IBMを離れて3年以上経過しており、内部事情を知る立場には ありません。あくまで報道を読んだ第三者としての感想にすぎないことをご了承くださ い。 日本放送協会（NHK）がシステム開発の中止を巡り日本IBMを提訴しています。以前日 本IBMに勤務していた経験があり関わりもあったため気になったのでまとめてみまし た。ただし、すでに日本IBMを離れて3年以上経過しており、内部事情を知る立場には ありません。あくまで報道を読んだ第三者としての見解であることをご了承くださ い。 クラウド基盤への移行業務を日本IBMに委託しましたが、上記のようプロジェクトは難航しました。 昨年、納期に間に合わないことが判明し、日本IBMとの委託契約解除に至ります。 NHKは54億円の損害賠償を請求し、日本IBMも真っ向から反論している状況です。 経緯を整理してみても、責任の所在や意思決定プロセスには不明瞭な点が多く、特に 「誰が移行方式を最終決定したのか」という重要な点さえ判然としません。公開情報 だけでは全体像の把握は難しいものの、この事例から読み取れる教訓と問題点につい て、IT業界での経験を踏まえて私見を述べたいと思います。 ITプロジェクトに関わった経験がある人であれば、「NHKはプロジェクトを適切に統制できていなかったのではないか」という印象を持つでしょう。 20年以上運用してきたメインフレームの業務システムを別のプラットフォームに移 行するという作業は、本質的に高リスクなプロジェクトです。このような移行を成功 させるためには、最低でも以下が前提条件となります。 今回の事例では、現行システムの開発・保守を担当し、これらの知見を有していたであろう富士通ではなく、日本IBMが移行を担当することになりました。このような状況で成功するためには、NHK自身が十分な知見を持ち、プロジェクトに積極的に関与することが不可欠だったはずです。 しかし経緯を見る限り、NHKは日本IBMに発注した後、主導的な役割を果たさず「委託して任せる」というスタンスだったのではないかと推察されます。 この移行の要件定義とIBMへの発注が決まった2020年〜2023年の時期は、前田晃 伸氏が会長を務め、多数のコンサルタントを起用して中期経営計画のもとダウンサイ ジングと構造改革を推進していた時期と重なります。これを考慮すると、以下のよう な懸念が浮かび上がります。 意思決定の歪み: 移行方式がアーキテクチャー上の合理性よりも、組織内の政治的動向によって決定された可能性 知識の流出: 50歳以上の早期退職や管理職の大幅削減（3割）の結果、以下のような問題が生じた可能性 前田晃伸氏は富士銀行出身で、最終的にみずほフィナンシャルグループの社長・会長 を務めた人物です。彼の在任中、みずほは2000年代に勘定系システムの統合で大規 模な障害を経験しています。 みずほ自身のシステム障害特別調査委員会の報告 や日経クロステックの記事に よると、その障害の主な原因は次の通りとされました。 これらの問題点は、今回のNHKの事例にも当てはまる可能性があります。経験豊富なシニア層の人員整理、富士通から日本IBMへの移行担当の変更、そして安易に大胆な移行方針を許容する経営判断というパターンが、みずほの過去の失敗と類似しています。 現在の契約解除により移行計画は頓挫していますが、2027年のEOLは確実に迫ってい ます。NHKは今後どのような対応をとるのか、注目される点です。 プロジェクトを十分に管理できなかったクライアント側に対してベンダーとして同情すべき点はありますが、日本IBM側にも以下のような問題点があったと考えられます。 おそらく日本IBM内ではコミュニケーションセクターがこのプロジェクトを担当して いたと推測されますが、金融セクターなどと比較すると大型案件の経験が少なく、こ のような複雑な移行プロジェクトに対する十分な経験者も不足していた可能性があり ます。それにもかかわらず、受注に踏み切ってしまったことが、後の問題につながっ たのではないでしょうか。 同時に、移行の複雑さを当初から認識していたにもかかわらず、クライアントに対し て十分なリスク説明や実現可能な代替案の提示が不足していた可能性も否定できませ ん。大規模プロジェクトでは、技術的な実行能力だけでなく、リスクの透明な伝達と 現実的な期待値の設定も成功の鍵となります。 メインフレームのシステムは富士通の撤退などもあり、多くの企業がライフサイクル終了に向けた対応を迫られています。こうした状況下で、「リライト方式」によるオープン系やクラウドへの移行を実施・計画している企業は少なくありません。 リライト方式とは、既存のメインフレームのコードから機能や要件を分析し、現代の 技術、言語、アーキテクチャーを使ってシステムを一から再設計していく手法です。 一般的な流れは次の通りです。 私はメインフレームでの開発・保守経験と、現代的な言語やフレームワークでの開発 経験の両方を持つ立場から、このリライト方式には以下のような本質的な問題がある と考えています。 コード分析では、コードに埋め込まれた文書化されていない次のような 「暗黙知」を十分に捉えることができません。 これらの理解がないまま移行すると、移行後のシステム維持できない可能性があります。 コード変換ツールによって生成されたコードには以下のような問題が生じがちです。 つまり、移行が完了したとしても、その後の保守作業は極めて難しくなる可能性があります。 現行システムの非効率で古い設計思想がそのまま新しいプラットフォームに移植され てしまいます。これは本来、システム刷新の大きな目的である技術的負債の解消とい う利点を失うことを意味します。 コード変換ツールはしばしば固有のランタイムやライブラリに依存します。 「メインフレーム」という特定プラットフォームの縛りから逃れるために導入したは ずが、さらに短い寿命、かつ保守が難しい可能性のある別の依存関係を作り出してしまう 矛盾が生じます。 要件定義・設計をIT担当者が経験できず、新しいプラットフォームに対する実践的な 知識やスキルが組織内に蓄積されません。結果として、移行後も組織としての技術的 対応力が向上しない状態に陥ります。 以上を踏まえると、リライト方式は短期的には魅力的に見えるます。 しかし、長期的には割に合わないものと思えます。 私は「グリーンフィールド開発」(Greenfield Development)しかないのかなと思います。 グリーンフィールド開発は、具体的には次のようなものです。 「リライト方式」との違いは、リライトが既存システムの機能を基準に再構築するのに対し、グリーンフィールド開発は既存システムの機能にこだわらず、現在のビジネスニーズから改めて考え直す点です。当然、要件定義からやり直すため、より多くの時間とステークホルダーの関与が必要になります。 しかし、以下のように考えてどうでしょう。 どうでもよいシステムでも最初抵抗があるかもしれません。しかし、SaaSなどに乗り換え ることでシステムに縛られず身軽になれます。 競争力を生み出すシステムはビジネスからの要求の変化も激しいので、要件定義から開発までスピードを持ってできる対応力がITにも問われているはずです。これを機にゼロから開発するほうがシステムの文書化、知見やスキルの蓄積もでき結果的にはお手軽に移行するより良い結果を生むと思います。 NHKと日本IBMの訴訟は、大規模システム移行プロジェクトが孕む本質的な課題を浮き 彫りにしています。長年運用された基幹システムの移行には、組織の体制、プロジェ クト管理の手法、そして技術的なアプローチの全てが適切に機能する必要がありま す。 今回の事例では、NHK側の要件理解とプロジェクト統制、IBM側の計画策定とリスク評 価、そして双方のコミュニケーションのいずれにも課題があったように見受けられま す。訴訟の行方はともかく、メインフレームEOLという避けられない課題に対して、 NHKは今後どのような戦略で対応していくのか注目されます。 システム移行の方法論としてのリライト方式についての考察は、この事例から派生し た1つの視点に過ぎませんが、多くの組織が直面している課題にも当てはまるのでは ないと思います。
経緯
プロジェクトの背景と計画
移行準備と入札
プロジェクトの進行と問題発生
契約解除と提訴
個人的な評価
NHKについて
高リスクプロジェクトの体制不備
組織改革の影響
リーダーシップの問題
IBMについて
プロジェクト受注の判断
見積りと実行体制の問題
組織的課題
リライト方式の移行について
リライト方式とは
リライト方式の問題点
暗黙知の喪失
保守性の低下
技術的負債の継承
新たな依存性の導入
組織的スキルの阻害
総合的評価
では、どうすべきか
結論