「2025年の崖」の先へ。レガシーモダナイゼーションの勘所（１）

＜ビジネス構想力だけでDXの崖は越えられない＞
「2025年の崖」が叫ばれて久しいですが、我が国のデジタル変革は遅々として進んでいるようには見えません。むしろ世間を賑わすのは、巨額のIT投資が失敗に終わるという、聞き飽きたはずの話題です。私たちはいつまで同じ過ちを繰り返すのでしょうか。
私は、DXにはビジネス構想力とシステム構築実践力の両輪が不可欠だと考えています。しかし、昨今のDX界隈の議論は、ビジネスアーキテクチャやビジネスアナリシスといった「ビジネス構想力」に偏重しているきらいがあるようにも感じます。もちろん、ビジネス起点のアプローチが重要なのは論を俟ちません。私もこれまで本コラムでビジネス構想力の文脈で、エンタープライズアーキテクチャやデータ中心アプローチの重要性を語ってきました。しかし、それだけで企業システムが真の価値を創出するには至らないのも真実です。ビジネス構想力とシステム構築実践力はレイヤーが異なる議論です。そして、そのもう一方の車輪である「システム構築の実践力」をどう発揮するかという議論がもっと高まるべきと感じます。こうした思いから、今回は「レガシーモダナイゼーション」というテーマを取り上げたいと思います。

＜絶えない「炎上案件」＞
昨今続出しているのが、プロジェクトの「炎上」です。目についたニュースを取り上げてみましょう。

• 24年4月、江崎グリコで基幹システム切り替え時に大規模障害が発生。「プッチンプリン」などが出荷停止に追い込まれる。
• 25年2月、NHKは構築ベンダーを相手取り約54億円の返還と賠償を求め提訴。営業基幹システムの刷新プロジェクトで、ベンダーが既存システムの複雑性を見誤り、納期延期を申し出たことから泥沼化。
• 地銀でも開発中止が相次ぐ。24年12月の滋賀銀行、25年2月の伊予銀行が、構築ベンダーのパッケージを用いた次世代基幹系システムの開発を中止。「想定を上回るハードルがあった」という言葉が、その困難さを物語る。

これらの事象を単なるプロジェクト失敗談で終わらせるべきではありません。確かにこのような「炎上案件」は過去から絶えませんが、システム構築が複雑化している近年、ますますその「説明責任の所在」が見えにくくなっているように感じます。上流工程から参画するコンサルの責を問う声も多いようですが、構築を担ったチーム（それがベンダー主体だったとしても）にその説明責任がもっと求められて然るべきではないでしょうか。前職時代から永らくアーキテクトとしてIT業界に身を置いてきた一人として、そこに光をあてないとこの状況は変わらないものと考えます。案件炎上によってビジネスの要請に応えることができなかったり、最悪の場合は企業のIT投資が抑制されるようなことがあってはならないのです。プロジェクトが迷走した時にその説明責任を負える人材を開発現場に配置すること、それが重要と考えます。と言っても、決して一人に責任を押し付ける意図ではありません。例えばプラント建設など他業界では、案件規模に応じた技術責任者の配置は常識です。IT業界にその常識は根付いているのかを問いたいわけです。

左図をご覧ください。この図の元となったIPAの資料は2007年のものです。今回これを取り上げたのは、当時も現在もアーキテクトの役割は本質的に大きく変わらないと考えるからです。確かにアーキテクトが対象とするシステムスコープは、特定の業務システムのみならずエンタープライズ全体に広がってきました。しかし、アーキテクト自らが要求者のニーズや要求に対峙し、自らの創造性を発揮して最適なアーキテクチャをデザインし、企業情報システム構築という複雑な難事業を導くというその本質は変わらないはずです。そして今、この役割を本当に果たせているのかがわれわれアーキテクトに問われているのだと感じます。

＜レガシーモダナイゼーションの本質＞
次に、「レガシーモダナイゼーション」に話を移しましょう。
それは単なるコスト削減のためのリホストやプログラム変換といった「レガシーマイグレーション」を包含し、さらに発展させた、競争力強化に向けたシステム基盤の最適化を目指す戦略と言えます。参考として、BTABOK(ビジネステクノロジーアーキテクチャ知識体系)の定義を引用してみましょう。BTABOKとは私が理事を務めるIasa（グローバルコミュニティ）が公開する、全てのアーキテクトが身に着けるべきスキルや知識を体系化したものです。原典はこちらにあります。

レガシーモダナイゼーションとは（iasa記事を参考に筆者が翻訳）

全てのシステムにはライフサイクルがあり、ビジネス環境の変化に対応できなくなると「レガシー」となる。レガシーモダナイゼーションとは、こうしたシステムを現代のビジネスニーズに合わせて刷新し、再び価値提供できる状態にするためのプロセスである。

近代化の最大の推進力は、組織の「俊敏性」を高め、競争優位性を確保することにある。変更困難なレガシーシステムはビジネスの足枷でしかなく、サポート終了に伴うセキュリティリスク、技術者確保の困難化、性能限界といった問題は、放置すれば致命傷になりかねない。そのため、技術サポートの終了、変更コストの増大、業務プロセスのボトルネック化といった兆候を早期に捉えることが重要だ。

そして最も重要な進め方の思想は、過去の投資額、すなわち「サンクコストの呪縛」から解放され、システムが現在提供している「ビジネス価値」で判断を下すことである。そのための有効なアプローチが、アプリケーションポートフォリオを「許容(Tolerate)」「投資(Invest)」「移行(Migrate)」「廃止(Eliminate)」に分類し、戦略的意思決定を促す手法である。

レガシーモダナイゼーションは、単なる技術の入れ替えではない。ビジネスの持続可能性を確保し、未来の成長を支えるための、極めて重要なアーキテクチャ活動なのである。

レガシーモダナイゼーションの核心は「アーキテクチャ活動」にあります。その活動とは、ハードウェアやミドルウェアのみならず、アプリケーションのソフトウェア構造を根本から変革することです。なぜなら、旧来の単一技術による密結合なアーキテクチャでは、マルチベンダー、マルチプロダクトが当たり前となった現代の技術多様性に対応できないからです。密結合は“過去の合理”であったかもしれませんが、“現代の合理”は可変性です。グローバル競争の激化により、ビジネスプロセス自体が俊敏に変化することを求められている今、硬直的なシステムは企業の足枷でしかありません。変化対応力を備えたシステムを実現するため、新しいアーキテクチャの思想が求められています。デジタル変革の成否は、このモダナイゼーションにかかっていると言っても過言ではないでしょう。

＜アーキテクトよ、今こそその責務を果たそう＞
レガシーモダナイゼーションの目指すゴールは、変化に対して柔軟性を備えた情報システムを構築し、ビジネス価値創出に寄与することです。一般的に情報システムに変化を要求する理由は、ビジネス要因とテクノロジー要因に大別できます。
ビジネス要因の例は、ビジネス展開に伴う企業同士の連携強化や顧客サービスへの対応などがあります。テクノロジー要因の例は、サーバ製品のサポート切れや新しいテクノロジーの出現があげられるでしょう。柔軟性を備えた情報システムとは、こういった将来起こりうる変化に柔軟に（適正な費用、期間で！）対応でき、適切なタイミングで適切な価値を適切な人へ提供できるような特性を持ちます。
このような「柔軟な」企業情報システムとは行き当たりばったりで実現することはありません。吸収すべき変化とはどういうものかが熟慮されており、そういった変化に対する対応力を備えた情報システムは「何に対して柔軟であるべきか」についての一貫したポリシーが適用されているものです。そしてそのポリシー、すなわちアーキテクチャの全体整合性を担保することこそ、アーキテクトの責務に他なりません。

IPAのデジタルスキル標準では「ビジネスアーキテクト」という人材が定義されています。しかしそれはアーキテクトという役割を見た時に、車輪の片側に過ぎません。同じくIPAのITSSが定義するように、品質、納期、技術、開発手法といった多様な制約の中で、ビジネス要件に応える情報システムの品質（機能性／信頼性／使用性／効率性／保守性／移植性）に責任を持つ専門職としての役割が今こそ重要なのです。レガシーモダナイゼーションという難事業を完遂させる責務はアーキテクトにあるということを再認識いただければと思います。

＊＊＊
今回は、レガシーモダナイゼーションの重要性とアーキテクトの責務について論じました。次回ではより踏み込んで、アーキテクチャ構想とアーキテクチャ設計の各局面でアーキテクトが考慮すべき「勘所」を考察したいと思います。お楽しみに！