重厚長大型のITシステムからどう脱却する？ 「AI活用で何がどう変わるのか」を解説：SIerはどこから来て、どこへ行くのか（1/2 ページ）

レガシーシステムでは「ちょっとした変更」が不具合発生につながることがあり、ユーザー企業がSIerに不信感を抱く理由の一つになっている。こうした課題をどう解決すべきか。SIerのPM（プロジェクトマネージャー）としてシステム開発に長年携わってきた筆者がユーザー企業に向けて解説する。

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

この連載について

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

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

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

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

　「なぜちょっとしたシステムの変更に莫大なコストと時間がかかるのか」――。前回まで、ユーザー企業がシステム開発を委託しているSIerに不信感の根底に、老朽化したITシステムの「呪縛」があることに触れてきた。

「ちょっとした変更」でシステム全体が影響を受ける理由とは？

　いわゆるレガシーシステムと呼ばれるITシステムは、「一枚岩」を指す「モノリス」を冠した「モノリスシステム」という設計方式で構築されてきた。この方式では、システムの各機能がデータベース（DB）を介して密接に結びついている。この構造によってデータベースの一部（データ項目追加など）を変更すると全体に影響が及ぶため、システム改修のコストやリスクが高くなっている。これは「2025年の崖」と呼ばれる課題の一因にもなっている。

　モノリスシステムが抱える問題の本質は、機能間での独立性が確保しにくい点にある。機能同士が密結合になりやすく、疎結合が実現しにくいことが課題になっている。現状のモノリスシステムでも疎結合を意識したITシステムとそうでないITシステムの間には大きな差が生じている。

　こうした課題を解消するのが「オブジェクト指向」という設計手法だ。この手法では、システムをデータとプロセスを包含した小さな部品（オブジェクト）に分割し、それぞれを独立に設計して動作させることを目指す。この設計により、一部の変更が全体に波及するリスクを低減できる。

　本稿では、筆者が担当した事例を通じて、変更や修正が難しい重厚長大型のITシステムからいかに脱却できるかを考える。ユーザー企業の経営層やDX推進部門、IT部門の方に向けてなるべく分かりやすく具体的に説明する。

モノリシステムの問題点　投資信託の時価計算システムの事例を紹介

　筆者が手掛けた事例を紹介しよう。投資信託の時価を計算するためのITシステムの例だ。

　『日本経済新聞』に掲載されている投資信託の時価は、このようなシステムで算出されている。日本では米国などと異なり、資産運用サイド（アセットマネジメント会社）と投資信託の財産管理を担う信託銀行（主にマスタートラスト銀行）がそれぞれ計算している。両者の計算結果が一致した場合のみ、その値が投資信託の時価として発表される。筆者が担当していたのは、このうち資産運用サイドの時価計算システムだった。

密結合の「縦計算」と、疎結合の「横計算」

　筆者が担当していたITシステムの時価計算は、投資信託（以下、「ファンド」）ごとに構成されているさまざまな株式や債権を計算する仕組みになっている。上場株式であればその日の最終価格（引け値）に該当のファンドが保有する数量を掛け合わせることで投資信託の時価を算出している。こうしたファンドごとの個別計算を並行して実施する方式を「横計算」と呼ぶ。

　一方、信託サイドでは計算手法が異なる。全ファンドが保有する上場株式の特定銘柄（例：SCSK株）の合計株数を基に、該当株式の全体資産額を計算する。全体試算額を基に各ファンドの株式の時価を案分して算出する。つまり、全体の計算の同一部分をまとめて処理し、その後資産単位に計算する方式だ。この手法を「縦計算」と呼ぶ。

　業界では「縦計算と横計算のどちらが優れているか」を巡って論争が起きたこともある。

横計算と縦計算の利点と問題点

　縦計算では計算処理を変更する際、1カ所を修正するだけで対応が可能だ。計算処理の回数が圧倒的に少なく、全体として効率が良いため、ITシステムとして効率的に設計されているように見える。では、縦計算の方が優れているのだろうか。

　実は、縦計算は巨大なモノリスシステムになっている。最初に計算した全体資産額のデータベースは、その後のファンドごとの計算時にも全て参照される仕組みになっている。つまり全体資産額のデータベースを中心とした、密結合の巨大なモノリスシステムが形成されてしまう。

　一方、横計算ではファンドごとに独立したデータベースを持っている。ファンド単位ではモノリスシステムになっているが、巨大なモノリスシステムに比べれば変更が影響する範囲はファンド数分の一に限定される。この違いに着目してみよう。

新しい商品の追加時に起こる「バグ発生問題」

　不動産関連の新しい商品を運用対象として追加する例について考えてみよう。

　縦計算は、全体資産額の処理に新商品の計算処理を組み込む必要がある。もしソフトウェアの初期段階でバグがあれば、追加した計算処理に不正が発生し、全体資産額の処理が正常に終了しない可能性がある。縦計算では密結合の範囲が広いため、1つのバグが引き起こす影響も大きくなり、大きなトラブルになる可能性がある。このため、影響範囲の調査や大規模なテスト、慎重なリリース計画が不可欠となり、リリースに伴うリスクも高くなる。

　一方、横計算では、新商品を扱う該当ファンドの計算処理だけ追加すればよい。他のファンドの計算には影響が及ばず、容易で迅速に対応できる。これが横計算の大きな強みだ。

「想定時間内に時価情報が取得できない」というピンチに対応できる横計算

　ファンドで運用しているのは上場企業の株式だけではなく、価格の把握が難しい商品も含まれる。このため、商品の時価情報が想定時間内に取得できないケースがたまに発生する。

　こうした場合、縦計算では商品の時価情報がそろわなければ全体の価格計算ができないため、個別のファンドごとの計算処理が止まってしまう。

　一方、横計算の場合は、該当の商品を使用していないファンドの計算処理は問題なく進められる。これによってトラブルの影響範囲を抑えられる。この違いは非常に大きい。