なぜSIerは「DXの本丸」に切り込もうとしないのか？：SIerはどこから来て、どこへ行くのか（2/2 ページ）

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

2.　既存ITシステムの現行機能を「見える化」し、設計情報を復元する技術

　ここから、2の既存ITシステムの現行機能を「見える化」し、設計情報を復元する技術に触れる。

　再構築を進めるに当たって最大の問題点となるのが、既存ITシステムの設計情報がブラックボックス化していることだ。この問題を解消するのが復元技術である。既存ITシステムの設計情報復元には、膨大なコストと時間がかかる。

　まずは現行のITシステムで不要なものの削除、廃止が必要になる。SIerのPMとしてシステム開発に携わってきた筆者も、新たな機能を開発する場合、よく似た既存のプログラムを修正して対応することが多かった。短期的には、時間とコストを抑えられるからだ。これを「モディファイ新規」と呼ぶ。

　この場合、新たな機能と関係のない機能は全て削除すべきだが、実際は使わないロジックもそのまま残るケースがほとんどだ。こうしてプログラム規模は大きくなっていく。

　システム老朽化の一因は、こうした不要なプログラムロジックの肥大化にある。時間がたつとその規模が膨らみ、実質的な機能の数倍ものソフトウェア資産を抱えるケースも見られる。

「ブラックボックス化」している既存システムをどうする？

　いずれにしても、現行のITシステムで分析する範囲を極小化することが必要だ。その上で、次の3つに仕分けする。

1. 廃止する部位
2. 既存の機能は必要だが、実現方式・機能に関しては既存機能を包含して完全に作り直す部位
3. 既存の機能を忠実に再現する部位

リバースエンジニアリングには限界がある

　1は、技術的には対象外となる。

　2は現行機能の分析が必要になる。一般的には、概要設計の工程で現行機能の保証活動が必要になる。概要設計のキー情報の一つである業務フローに関しては、業務フローにおける各作業に関する現行システム・新システムの機能やデータの対応関係を一覧にした「対応表」を整理し、抜け漏れがないかどうかを確認する。

　また、画面や帳票、他システムのインタフェースデータやDB（データベース）に関しても、現行システム・新システムの対応表を整理し、抜け漏れがないかどうかを確認しなければならない。こうした準備作業を実施することで、既存ITシステムの機能は基本的に抜け漏れなく把握できる。

　システムの再構築を伴うITプロジェクトでこうした作業を実施しなければ、大きな機能の漏れが発生する可能性があり、大きなリスクになりかねない。特に、既存のITシステムを担当していない企業がシステムの再構築を手掛ける場合は、絶対に必要だと筆者は考える。

　特に重要なのは、概要設計のキー情報の情報復元技術だ。これに関して筆者は、IPAのDX実践手引書に詳しく理論を述べた。これは、私が野村総合研究所（NRI）で10年間かけて開発した手法を同社の許可のもと公開したものだ。

　同手法のポイントは、既存のITシステム（マイクロサービスなどで開発されていないシステム）は、基本的に4つのサブシステムの形態（O/L型、B/T型、Web型、GW(ゲートウェイ)型）があり、そのサブシステム形態ごとに概要設計のキー情報が異なる。

　具体的には、O/L型は業務フロー、B/T型はDFD（データフローダイグラム）、Web型は画面遷移図、GW（ゲートウェイ）型は状態遷移図だ。

　これらの情報をプログラム解析や業務マニュアルなどの資料や、現場で保守・開発を担当している技術者、業務で利用しているユーザー部門を対象としたヒアリングなどを通じて得た情報から復元する必要がある。

　プログラムをいくら解析しても、「何をしているか」は理解できても、「何のためにやっているか」という情報は存在しないからだ。概要設計レベルの情報の中には、工程が進むごとに消えていく情報が多く存在する。そのために、どのような情報を復元すべきかを明確化した上で、前述したプログラム解析などを実施して、失われた情報を丁寧に収集することが重要だ。

　リバースエンジニアリングには限界があり、プログラムに存在しない情報は復元しようがないからだ。ただ、現在、業務が実行されている以上、さまざまな手段を用いることで概要設計のキー情報を集めることは基本的には可能だ。

現行機能を保証するために何をすべきか？

　3の「既存の機能を忠実に再現する」は、2に加えて必要になる作業だ。大まかな考え方としては、工程単位で段階的に現行機能を保証することが肝要になる。簡単に言えば、外部設計では項目レベルでの現行システム・新システムの比較が必要になる。必要になる全てのデータ項目が新システムに存在することを保証する必要がある。

　内部設計レベルで作成されるプログラムとその機能が確定される。その時点で、新旧のプログラム単位での対応表を策定し、詳細設計レベルでコード単位に機能が網羅的に新プログラム機能に漏れなく反映されていることを確認する。このように、段階的に旧プログラムレベルの機能を保証する。

　段階的に進めるもう一つの理由は、プログラムレベルで機能を保証するためには、プログラムレベルまで新システムが詳細化されて比較可能になることと同時に、そのレベルで解析する体制が確立している必要があるからだ。プログラムを開発する体制が整わなければ、コードレベルで解析する体制も整備できない。

　このように、これまでの開発に加えてさらに工数とコストが発生する。総合テスト工程では、現行のシステムと新システムに同様の環境で同一のテストケースでテストし、現行機能が正しく反映されているかどうか、新旧のデータベースを比較して証明することが必要であり、そのために必要なテスト環境は大掛かりなものになる。

　総合テスト工程の新データベースが旧データベースとマッチングすることに基づいて、現行機能を保証するプロジェクトもある。しかし、ここまで述べてきた、機能の反映漏れを工程レベルで最小化する作業を実施しなければ、総合テストの期間中に対応できる範囲に絞り込めない。品質保証可能な範囲を工程ごとに定め一歩一歩段階的に品質を確保することで初めて想定のスケジュールで品質を保証できる。これは、ITプロジェクトマネージメントの要諦である。

　次回は、今後主流になるソフトウェア開発方式について解説する予定だ。

著者紹介：室脇慶彦（SCSK顧問）

むろわき　よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長等を経て常務執行役員品質・生産革新本部長、理事。独立行政法人　情報処理推進機構　参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員等、情報サービス産業協会理事等歴任。著書に『SIer企業の進む道』（日経BP）、『プロフェッショナルPMの神髄』（日経BP）など。