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

[室脇慶彦，SCSK株式会社]

基本設計完了後になぜ「その先」に進めなかったのか

　話を元に戻すと、本プロジェクトに対して筆者は幾つか疑問を持っている。

　まず、スケジュールが遅延しながらも基本設計が終了したにもかかわらず、次工程である詳細設計に進めなかった点だ。

　基本設計は、一般的に「外部設計」と「内部設計」の2つに分かれる。

外部設計

　最終的なUI（ユーザーインターフェース）、データベースのデータ項目定義、外部システムとの連携方法の決定など、ITシステムを「ブラックボックス」として捉え、全ての機能を決定する。外部設計の段階でシステムがどのような機能を持つかを決めるため、当然ながら最終決定権はユーザー側にある。

内部設計

　外部設計で定義された内容をITシステムで実現するための設計活動。まさにIT専門家としての技術を発揮する工程といえる。

　外部設計までは基本的に作業そのものを委託する「準委任契約」が多いが、内部設計は成果物の完成を保証する「請負契約」を結び、プロとしてITシステムを稼働させることを保証する場合が多い。

　さらに言えば、内部設計の妥当性の確認をユーザー側に求めても、妥当性を確認できる能力を持つ日本のユーザー企業は極めて少ない。今回のケースでは外部設計と内部設計を一括して契約し、NHKが成果物を承認したとしても、内部設計の品質不良に関してNHKが承認したことの責任を問うのは、こうした事情からIT専門家としていかがなものかと思う。

　また、次工程である詳細設計が実行できないということは、「基本設計書の終了条件を満たした品質である」とIBMが主張するのは無理がある。正しい成果物ができていないから、次工程に進めないのである。

　基本設計終了時の基本設計書は不十分で、大幅な遅延が発生していることもIBMは認識していたはずだ。つまり不良品であることを認識しながら納品し、重大事項を報告していないとみなされても仕方がないと筆者は考える。

　さらに言えば、当初3カ月で現行システムの調査・分析であるアセスメントを実施し、現行システムの分析・移行計画の妥当性を確認しているのだから、この時点でリスクの高い処理方式を洗い出すべきだった。

　問題がある場合は、その対応についてNHKと協議すべきだろう。実際、NHKは次工程でスケジュール変更を2回も容認しているのだから、協議に応じたはずだ。

「業務管理機能」のリライトという難題

　2つ目の問題は、「業務管理機能」のリライト（書き直し）だ。これは現状の本機能をそのまま作り直すということだと認識すべきだろう。

　この仕組みは「ミドルウェア」と呼ばれる。アプリケーションとOSあるいはDBMSなどの基本的なソフトウエア群およびハードウェアの間を取り持つソフトウェアのことだ。OSなどの機能を意識せずに、アプリケーション開発側はソフトウエアを開発できる。

　本件で採用されたクラウドGCPが提供する機能をアプリケーション開発側が意識することなく、従来利用してきた富士通製のメインフレームと同じインターフェースで開発できる仕組みだと考えられる。

　ソフトウェア専業のSIerは、「基盤エンジニア」という極めて専門性の高い技術を持つエンジニアが設計を担当する。アプリケーション側で作成する概要設計書をインプットして設計すべき処理方式を洗い出し、アプリケーション側がシステム基盤を意識せずに開発できるようにするための仕組みを設計開発する。

具体例：「一方分岐」処理の複雑さ

　開発経験のない方には難しい話だと思われるので、ここで具体例を示そう。

　メインフレームが主流だった時代、「一方分岐」という処理方式が取られてきた（少なくとも筆者の前職ではこう呼んでいた）。例えば、端末での処理結果を近くにあるプリンターに出力する仕組みだ。

　一般ユーザーからすれば、端末の近くに紙が出力されるのは当たり前だろう。しかし、システムを開発する場合は、この端末の出力を数多くのプリンターのどれに出すべきかを判断するためには、端末とプリンターがひも付けられていなければならない。現在ではこの機能は、Windowsの印刷機能を活用する。PCとプリンタの設定やプリンターのドライバーソフトウエアのインストールなどはユーザー自身が設定することになっている。

　さらに、プリンターが「こちらにデータを送ってもらえば印刷するよ」と能動的にユーザーに指示するわけではない。そこで、メインフレームがプリンターを一方的に制御し、強制的にデータを送らせるように設計する必要があるのだ。

　これらを実現するように設計、開発するだけでなく、アプリケーション側にはこのようなケースに使われるソフトウェア部品を提供することになる。

　このように、ITシステムを動かすためには、ユーザーからは見えない仕組みがたくさん必要になる。処理方式を洗い出して設計することが、ユーザー要件を満たす条件となる。しかし、ユーザーからこのミドルウェアに必要な機能が提示されることはない。

ミドルウェアが抱える根本的な課題

　本件のミドルウェアは処理方式ごとに、主にアプリケーションとのインターフェースとGCPとのインターフェースの2つの機能から構成されると考えられる。

　アプリケーションとのインターフェースは、今回の場合、基本的には保証する必要があり、現システムの機能をそのまま踏襲することは問題ない。

　ところが、これまでのメインフレームとのインターフェースは、例えばデータベース、オンライン処理、通信手順（FNA：Fujitsu Network Architecture）、さまざまなソフトウェアなどがある。これに対し、GCPが提供する機能がすべて対応しているとは到底考えられない。

　提供された機能でも、富士通が提供する機能範囲とGCPが提供する機能範囲が異なるのが普通だと想定される。例えば、通信手順については、FNA（富士通独自の通信規格）とTCP/IP（インターネット標準の通信規格）とは明らかに異なる。

　従って、GCPとのインターフェース設計は、既存のものとは異なり、当然ながら存在しない機能は新たに設計開発する必要がある。そのためには、現行ITシステムの概要設計レベルの情報を整理しながら、GCPを熟知したシステム基盤エンジニアと富士通基盤を熟知したエンジニアが協力して処理方式を洗い出し、一つ一つ設計する必要がある。

　そうしないと、システム基盤とつながらないミドルウェアになる。つまり、現状のリライト方式では機能は不十分であると考えられる。この想定が正しいとすると、設計範囲が不十分なため問題が後から後から噴出し、収拾のメドがつかないITシステムになってしまうのだ。

課題があるのはNHKや日本IBMだけではない

　本件は、以前取り上げた日本通運の事案よりもさらに厳しい難易度の高いプロジェクトだと推察できる。NHKはただでさえ道のりが険しいプロジェクトの難易度をさらに上げてしまったと言わざるを得ない。

　本プロジェクト最大の被害者は、NHKの“ユーザー”である国民なのかもしれない。前編でも触れたように、自然災害をはじめとする非常時に公共放送であるNHKの報道を頼りにしている国民は多いだろう。

　NHKのシステム更新が失敗して、NHKの事業が継続不可能になるような致命的なトラブルが続出する状況は何としても避けなくてはならない。

　もっとも、こうした前提条件を知りながら放置したITベンダーも罪深いと言わざるを得ない。

　そして、課題があるのは本件の当事者だけではない。ITシステムの構築方式にも問題がある。既存の入札制度も含め、ITプロジェクトの契約形態や責任範囲の見直し、さらには、規制を含めた改革といった、大規模プロジェクトをめぐるITシステムの抜本的な改革を含めた実行可能なプランの策定が求められる。

　そして、このようなレガシーシステムの潜在的なリスクは、さまざまなインフラ産業で静かに進んでいるのではないか。「2025年の崖」について経済産業省やITの有識者が警鐘を鳴らしてきたにもかかわらず、「崖」は、目前まで迫ってきているのかもしれない。