ユーザー企業がSIerに抱く不信感の“源” 「巨大ITシステムの呪縛」とは：SIerはどこから来て、どこへ行くのか（1/2 ページ）

ユーザー企業とSIerは対等なパートナーであるべきだと言われて久しいが、互いに不信感を抱きがちだ。この相互不信の根底には巨大で複雑になりがちなITシステムの「呪縛」がある。ITシステムの呪縛に開発手法から迫る。

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

この連載について

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

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

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

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

　前回は、ユーザー企業がSIerに不信感を抱く根底に、ユーザー企業にとってITシステムの開発費用は高く、開発期間は長く感じられるという認識のギャップがあることに触れた。

　SIerからすると、深刻なトラブルを発生させないために取った措置だが、ユーザー企業には「ちょっとした機能を追加するだけなのに、なぜこれほど高い費用や長い期間が必要なのか」と感じられる。

　こうした認識のギャップが生まれる背景には、「ちょっとした機能の追加」でも開発にかかるコストや時間が膨れがちな老朽化したITシステムの問題が一つある。

　特に、「一枚岩」を指す「モノリス」を冠した「モノリスシステム」というこれまで主流だった開発手法ではその問題が顕著だ。そこで今回は、モノリスシステムが抱える課題と、それらの課題を解消するための新しい開発手法に触れる。

疎結合は重要　それが分かっていてもなぜか蜜結合システムになる「呪縛」

　「システムは疎結合に作れ」――。筆者は若い頃、先輩方から口酸っぱく言われてきた。

　データベース（DB）はできるだけ物理分割を意識してシステム設計することが、システム設計の肝であり、SEとして腕の見せどころだと考えてきた。

　しかし、一般的にはデータベースを巨大化させ、データベースにアクセスすれば何でもできるようにする方が簡単であるため、広範囲なモノリスシステムにする場合が多い。

　データベースが巨大化すると、データの整合性を保つための処理が特定の部分に集中しやすくなる。データベースアクセス部分の機能は1カ所でなければデータベースの整合性が取れなくなるためだ。このため、この特定部分に修正や変更が集中し、開発のボトルネックになる。さらに、データベースが巨大になると、データが壊れるといった問題が発生した場合、トラブル範囲が広範囲に及ぶリスクの高い構造になる。

　みずほ銀行でかつて起こったトラブルは、振込処理が通常通り実行されないという不具合から始まり、広範囲にわたって深刻な影響が広がったと筆者は認識している。みずほ銀行のシステムはシステムが構築された時期や、金融システムの特性から考えて、データベースを中心とした巨大なモノリスシステムで構築されている可能性が極めて高いと筆者は見ている。

　みずほ銀行のシステムがモノリスシステムで構築されているとすれば、広範囲に影響が及ぶことは容易に推測できる。

なぜ巨大システムは「手がかかる」のか？

　モノリスシステムで構築されているシステムを独立して対応可能な形にするためには、開発のボトルネックとなる部分を直接修正せずに、別の部分で対応することが多くなる。その結果、システムとしての複雑度がますます進んでいく。こうしてますます、「手のかかるITシステム」に“成長”するのだ。

　具体的に説明しよう。本来であれば主要データベースで管理すべき項目を、周辺データベースで管理するとする。すると、他のシステムのデータ項目を追加で参照する場合に、主要データベースと周辺データベース双方へのアクセスが必要になる。このように複数のシステムが周辺データベースを参照し始めることでシステムの複雑度が上がる。

　いずれにしても、筆者が開発してきたシステムは比較的、疎結合システムではあったが、モノリスシステムからの呪縛（じゅばく）から完全に逃れられたわけではない。データベースを共有するという意味で密結合システムであることに変わりないからだ。

オブジェクト指向型開発の歴史と課題

　ここまで、「手のかかるシステム」「トラブルが起こるたびに複雑化するシステム」というモノリスシステムの問題点を見てきた。

　では、なぜ多くの企業がモノリスシステムをこれまで開発してきたのだろうか。

　第2回で述べたように、新たなITシステムの開発方法である「オブジェクト指向設計」の考え方は、1980年代にさかのぼる。

　筆者も当時、当時の主流であった「データ中心設計」に違和感を覚えていた。データ中心設計とは、プロセスよりも安定度が高いデータを中心に設計する考え方に基づいた設計思想だ。しかし、データとプロセスは本来不可分であり同時に設計を進めていくべきだと筆者は漠然と感じていた。そういう意味で、オブジェクト指向設計の、データとプロセスを同時に整理することに強いシンパシーを感じた。

　しかし、オブジェクト指向設計を実際の開発に適用しようとすると、問題が生じた。オブジェクト指向設計では「抽象化」という手法を用いてシステムの構造や要素を整理するが、当時使われていた抽象化の方法は、ある機能や特徴といった一つの性質に焦点を当てて設計を進めるというものだった。このアプローチはあいまいで設計者にとっても理解しづらいものだった

　これはどういうことか。「クルマは4輪車だ」と抽象化した場合、「海外のバスには6本のタイヤを持つものもあるが、バスはクルマではないのか」「ベビーカーはクルマなのか」などの疑問が出てきてしまう。

　そもそも、世の中に存在している事象はさまざまな異なる性質を持っており、一つの性質で抽象化することはどだい無理なのだ。こうしてオブジェクト指向設計は、理論と実践に大きな乖離（かいり）が生じた。

　1つのオブジェクトを設計する場合、オブジェクトが極めて小さい機能である場合は、比較的容易に設計、開発できる。顧客名だけ管理するオブジェクト機能では、「顧客名」そのものが抽象化された概念であり、それ以上は分割できない。

　ところが、顧客属性を管理する大きなオブジェクトを作るためには、「顧客名」「住所」「電子メールアドレス」「電話番号」「性別」「生年月日」など多くから構成される小さなオブジェクトの集合体を作る必要がある。

　つまり、オブジェクトが大きくなればなるほど、全てのオブジェクトを格納できる物理的なメモリーが必要になる。

　1980年代当時、プログラムを実行するためのメモリーの大きさには著しい制限があり、プログラムの非常駐化などを駆使して対応した。つまり、オブジェクト指向設計は、ハードウェアの制限により、理論を実践できない状況にあった。

　また当時、オンラインシステムのデータベースは、ディスク装置に格納されていた。逆に言えば、ディスク装置ができたからこそオンラインシステムが実装可能になったのだ。

　オンライン処理の場合、入力を終えて送信ボタンを押して応答画面が表示されるまでの時間は3秒以内と言われる。この3秒は、「人が遅いと不快に思わない時間」と言われている。この性能要件を実現するために、当時は相当に苦労したものだ。

　外部ネットワークも貧弱で、できるだけ小さなデータに加工して送信しても片道1秒弱、往復だと2秒弱かかる。サーバで処理できるのは、わずかに約1秒。実際のプログラム実行にかかる時間以外にもディスク装置へのアクセスに50ミリ秒を要し、読み書きでさらに100ミリ秒かかる。

　計算処理をするためには、「価格表」などのデータを保存しているデータベースを参照する必要がある。データベースを更新した場合は、システム保全のためにログなどの制御情報を出力する必要がある。これらの作業は全てディスク装置へのアクセスを必要とする。

　そのため、データベースを安易に分割すれば、性能条件を満たすことができない。ではどうすべきか、ここまで読んだ読者はお分かりだろう。

　ハードウェア性能の貧弱さをカバーするために、データベースに多くの項目を集中させ、一度のアクセスで多くのデータ項目を取得する設計とした。必要な処理を集中させて、一度にデータを更新するアーキテクチャを採用せざるを得なかった。

　これが欠点だらけのモノリスシステムが作られ続けた真の原因だと筆者は考えている。つまり、ハードウェアやネットワークの著しい制約の下、苦労し工夫を凝らしてソフトウェアを開発した結果、システムは複雑度を増していったのである。