DX推進をうたっても老朽システムは放置 経産省のレポートが暴く「不都合な真実」：SIerはどこから来て、どこへ行くのか

経産省らが事務局を務めるレガシーシステムモダン化委員会の「総括レポート」で明らかになったのは、DX推進を掲げながら老朽化したITシステムを放置する企業が多いという点だ。レガシーシステムを放置する企業が直面するリスクとは何か。元IPA参与の著者がレポートのポイントを読み解き、脱レガシー化のための開発手法について考察する。

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

この連載について

　ユーザー企業にとって、SIerはITシステムの導入から運用、故障時の対応や更新などに欠かせない存在です。

　しかし、その関係性はと言うと、対等なパートナーと言うよりも、ユーザー企業はSIerに対して丸投げしがちで、SIerも「お客さまであるユーザー企業の要望は断りづらい」ために、ユーザー企業のITシステム全体の最適化よりも、その場その場のニーズへの対応を重視しがちな「御用聞き体質」が指摘されてきました。

　こうした中、DX案件の増加やIT人材の慢性的な不足、ユーザー企業の内製化志向などのさまざまな環境変化によって、ユーザー企業とSIerとの関係は変わらざるを得なくなりつつあります。

　この連載を通じて、SIビジネスを取り巻く構造的な問題を掘り下げ、ユーザー企業とSIerが目指すべき関係の在り方を探っていきます。

　前回は、マイクロサービスアーキテクチャ（MSA）における品質保証の考え方を掘り下げた。今回はまず、経済産業省・情報処理推進機構（IPA）・デジタル庁が事務局を務めるレガシーシステムモダン化委員会が公表したレポートを取り上げる。

　デジタル庁が事務局に参加していることからも分かるように、レガシー問題は一省庁のマターではなく国全体の課題として位置付けられている。このレポートから、ユーザー企業の経営層やIT部門が押さえるべきポイントを読み解きたい。次に、レガシー脱却の“鍵”となるソフトウェア開発方法論の転換について考察する。

「レガシーシステムモダン化委員会総括レポート」が突き付ける“不都合な真実”

　大企業の74％がレガシーシステムを抱えたままにもかかわらず「既存システムは今のままでいい」と考える経営層は多い――。同レポートが突き付けるのは、DXの成否を分けるのはAIへの投資額ではなく、レガシーシステムに含まれる自社独自の重要データを「使える状態」にできるかどうかだという現実だ。

　2025年5月に公表されたレガシーシステムモダン化委員会の総括レポート『DXの現在地とレガシーシステム脱却に向けて』は、経産省が2018年に発行した「DXレポート」で「2025年の崖」として警鐘を鳴らしたレガシーシステム問題への対応が進んでいない現実を明らかにしている。公表後1カ月程度で1万件を超えるダウンロードがあったという事実は、この問題に対する関心の高さを物語っている。詳しくは同レポートをご覧いただきたいが、筆者が特に注目するポイントを述べたい。

大企業の74%がレガシーシステムを保有

　レガシーシステムを多く抱えているのは、IT化の歴史が長い大企業だ。

　特に社会インフラ事業者はその代表格と言って過言ではない。許認可の関係で新規参入が他産業に比べて難しい時代があり、歴史の長い企業が多く存在するためだ。同レポートでは、大企業の74%が「レガシーシステムを保有している」と回答している。

　経産省が企業のDX推進状況を可視化するために策定した「DX推進指標」でも、不要なITシステムの廃棄が進んでいないという傾向が示されている。以前も述べたように、負債化が進んだITシステムは規模が膨れ上がっているのが特徴だ。規模が大きければ大きいほど、対応に必要なコストや期間、リスクが飛躍的に膨らむ。本格的なITシステム変革を実施するためには、まず改革対象を絞り込み、適正な規模に縮小することが不可欠だ。

　筆者が聞いた話によると、レガシーシステム対策に本格的に取り組んだ企業のCIO（最高情報責任者）は、まずITシステムの廃棄から着手したという。使われていないと思われる帳票や画面を段階的に利用停止にした。すぐに完全に削除するのではなく、表面上は使えないようにしつつ裏側では復旧可能な状態を1年間維持し、問い合わせや業務に支障がないものから順次削除した。この結果、大幅なシステム削減を実現した。

　整理整頓の鉄則は「まず捨てること」であり、それはITシステムにも当てはまる。

「既存システムは今のままでいい」は正しいのか？

　にもかかわらず、大企業のCIOの中には、DX（デジタルトランスフォーメーション）と称してAIやWeb関連のユーザー接点部分の改革を声高に叫ぶ一方で、「既存ITシステムは今のままでいい」と断言する人もいる。筆者はこれを大きな間違いだと考えている。

　同レポートが示すシステムモダナイズの最大の目的は、企業の競争力の確保だ。システムモダナイズとは、企業が持つデータをAIが活用できる状態に生まれ変わらせることだと筆者は理解している。以前も述べたように、データが「使える」状態とは、データの精度や鮮度、粒度が適切に保たれていることを指す。さらに、データがその企業独自のものであることが、他社との差別化において極めて重要だ。

　この観点に立てば、レガシーシステムが抱えているデータこそ、企業独自の最も重要な資産になると筆者は見ている。それを活用可能にするためのアプリケーションアーキテクチャがオブジェクト指向技術の適用であり、具体的にはマイクロサービスの適用だ。マイクロサービスはソフトウェア開発の生産性や品質、スピードを桁違いに向上させることにも貢献する。同レポートは、これらを実現することで企業が競争に勝てるということを訴えていると筆者は受け止めている。

ウォーターフォールの基本は変わらない

　ここから、レガシー脱却のための開発方法論に話を移そう。

　以前も述べたように、ウォーターフォールモデルはソフトウェア開発方法論の基本だ。要件を定義し、それを実現するために設計し、設計に基づいて開発し、要件通りにITシステムが稼働するかどうかをテストする――。このサイクルはITシステムに限らず全ての製造業の基本であり、オブジェクト指向開発であっても基本は同じだと筆者は考えている。

　ただし、これまでのモノリスシステムとは異なる部分も当然ある。モノリスシステムではデータベース設計が大きな比重を占めていたが、オブジェクト指向では個々のオブジェクト（機能の単位）の中にデータがカプセル化される。外部から直接データベースにアクセスするのではなく、オブジェクトが提供するAPIを通じてのみデータにアクセスする仕組みだ。このため、データベース設計の比率は極端に下がる。また、従来はITシステム間の接続をする際にトランザクションデータを基本に考えていたが、API接続を前提に考えることになる。複数の処理を一括で確定させる「トランザクション管理」は、モノリスシステムでは比較的容易だった。しかし、サービスが分散するMSAでは、各サービス間でデータの整合性を保つための新たな仕組みが必要になる。このように多くの場面で、適用する技術の違いによって設計手法が変わるのだ。

「外部設計は揺らぐ」問題をどう解消するか

　従来のソフトウェア開発では、SIerに委託することを前提とした工程の区切りが一般的だった。しかし、今後はユーザー企業が設計・開発の各工程で責任を取ることを前提とした開発工程を再定義する必要がある。具体的にはユーザー企業とSIerとの責任分担を見直し、外部設計と内部設計の区切りを再構築すべきだと筆者は考える。

なぜ外部設計工程は「揺らぐ」のか

　筆者は拙著『プロフェッショナルPMの神髄』（日経BP、2016年）で、外部設計工程には「揺らぎ」があることを述べた。

　これがどういうことかと言うと、外部設計までは基本的に要求定義の段階、つまり顧客がやりたいことをまとめるのが主な目的となる。しかし、その要求事項は全て実現できるとは限らない。技術的に実現が困難な場合は、この時点で要求を見直す必要がある。分かりやすく言うと、実現が難しいと思われる機能については、内部設計以降の工程を先行して実施し、実現可能かどうかを見極めなければならないということだ。実現不能であれば要求事項を見直す必要がある。こうしたことから、外部設計工程は「揺らぐ」のだ。

　つまり要件定義とは、顧客の要求事項を満たしつつ、技術的に実現可能な要件に落とし込む作業だ。こうした手順が定着した理由はシンプルだ。SIerが受託契約を結ぶには「この要件なら確実に作れる」という見通しが必要であり、そのために要件の実現可能性を事前に確認する工程が不可欠だったためだ。

ユーザー企業による内製化を前提にすれば「揺らぎ」は解消できる

　ところが、ユーザー企業による内製を前提にする場合、状況は変わる。実現方式をほぼ見極められる内部設計までを含めて「設計工程」とした方が分かりやすい。

　これは、かつてユーザー企業がITシステムの内容を十分に理解していた時代の「基本設計」に相当する。当時はユーザー企業が設計内容の妥当性を判断するスキルを持っていたからだ。

　しかし昨今は、「何を作るか」はユーザー企業が決め、「どう作るか」はSIerが責任を負う――という役割分担が一般的になった。そのための苦肉の策として「外部設計は揺らぐ」ことを前提として柔軟に対応せざるを得なかったのが実情だ。

MSA時代の開発の設計工程

　筆者の考えでは、新たな開発方法論における大きな設計工程は、次のように整理できる。

MSA時代の開発工程

概要設計工程：　大まかな要件を定義する

基本設計工程：　概要設計を実現するための設計（外部設計活動と内部設計活動を含む）

開発工程：　基本設計に基づく開発

テスト工程：　開発成果物の検証

　基本設計工程に外部設計活動と内部設計活動が存在し、それぞれの成果物は明確に定義される。ただし、工程としては同一であり、ここで技術的な問題が発生した場合は概要設計に立ち戻って見直す。ウォーターフォールモデルは一つ前の工程に戻ることを許容しているため、「外部設計は揺らぐ」という技術的に難しい対応は不要になる。

大規模開発は終わる　サブシステム単位の設計が基本に

　もう一つの重要な視点は、ITシステムの規模と開発工程の関係だ。

　従来の大規模ITシステムは、一般的に20〜30程度のサブシステムから構成される「機能システム」（部門システム）として成り立っていた。このモノリスシステムでは、機能システムに含まれるサブシステム同士がデータベースを共有する場合が多く、各サブシステムの役割を厳格に定義する必要があった。

　しかし、MSA時代のITシステムは全く異なる姿になる。当初は1つのマイクロサービスで「商品検索」と「レコメンド」を処理していたとする。利用者が増えてレコメンド機能が複雑化すれば、「商品検索サービス」と「レコメンドサービス」に分離し、それぞれ独立して開発・運用できるようにする。このように、ビジネスの成長に合わせてサービスを分割しするのがMSAの特徴だ。自律的に疎結合を維持しながら、企業の組織とともに成長するのだ。必要に応じて既存のマイクロサービスとAPIで接続することになる。

「追認型マネジメント」への転換

　このような環境では、各マイクロサービスを厳格に管理するよりも、チームごとの判断で柔軟にサービスを発展させ、全体としての整合性を事後的に確認する「適応型のマネジメント」が求められる。結果としてどのようなマイクロサービス構成になるかを、ある程度の粒度で把握する「追認型のマネジメント」に変わると筆者は考える。

　事業戦略上の要請から新たにマイクロサービスを開発するケースも当然あるが、それも最終的には既存の枠組みの中に自然と同化するだろう。全体のITシステムをどのような形で構築し管理するかは、筆者にとっても今後検討したいテーマであり、読者の皆さんにもぜひ考えていただきたいところだ。

　こうした変化を踏まえると、具体的な開発方法論が対象とするのは、従来のサブシステム規模が基本になると筆者は考える。従来は「部門全体のシステム」（機能システム）という大きな枠から設計を始め、その中のサブシステムへと段階的にブレイクダウンしていた。新たな開発方法論では、個々のサブシステム単位で直接設計に入ることが前提となる。

　従来の機能システムでは、全サブシステムの機能を設計する「全体編」と、それに基づくサブシステムごとの「個別編」という2つの概要設計が必要だった。新たな開発方法論では、従来の個別サブシステム概要設計からを対象と考える。

　つまり、従来のような大規模ITシステム開発はほとんどなくなり、プロジェクト規模が適正化される。結果として、ITプロジェクトが成功する確率も高まるはずだ。ただ、既存レガシーシステムを移行する場合は、巨大なモノリスシステムの積み木崩しも必要になるため、超大規模なITシステムの方法論も一部必要になるだろう。これについては、システム移行のところでお話しできればと思う。

次回予告

　今回は、レガシーシステムモダナイズレポートが示す課題と、MSAを前提とした開発プロセスの再定義について論じた。次回は要件定義フェーズや基本設計フェーズ、開発フェーズ、テストフェーズについて、それぞれの具体的な考察を進める予定だ。

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

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