システムが経営をロックしている現状

古い基幹システムをお持ちのお客様のシステムリニューアルにお付き合いしているのですが、なんとも無駄な行為ばかりが目立ってしまっています。経営に重大な影響を与えかねないのに、どうしてその道を選んでしまうのか…

現状の課題

未だに30年前のメインフレームのアーキテクチャのまま、基幹システムを動かしていらっしゃるお客様がいらっしゃいます。基幹システムなので、もし動かなくなってしまった時の影響は計り知れません。全世界の物流・生産・会計が止まってしまうからです。
しかし、顧客との接点を持つ現場は、さらなる売上の向上やより良いカスタマーエクスペリエンスの提供を目指し、もっと業務の効率化などを求めています。そこでシステム部門は、現行のシステムに外部から接続して、新しいアプリケーションはオープン環境（つまりLINUXやWindowsベースで動く環境）に構築しようとしています。

ここで問題があります。
何かというと、参照や記録をしなければならないデータベース自体はメインフレーム上にあり、その構造や手続きが煩雑、かつ、性能が出ないなどで、本来やらなくても良い作業が必要です。また複雑性が増すので、品質の低下も懸念されます。しかも、そのようなプロジェクトが十数個も同時に走っています。

原因を考察

なぜそのようなことになるのでしょうか？
根本にあるのは、「基幹システムのリプレイスには多大な費用とリスクが掛かる」という経営視点にあると思います。特に製造業などにおいてはシステムはコストでしかなく、いかに費用を抑えるかしか観点がないのです。そのため、「使えるものは使えなくなるまで更新しない」という方針のもと、ずるずると今に至っています。そして、基幹システムのリプレイスの難易度・コストは当初の見積に対して指数関数的に増大しているため、さらに基幹システムのリプレイスがしづらくなっているのです。

さらに、一つのアプリが構築されて運用され始めると、せっかく作ったのだからということで、更に基幹システムのリプレイスプランは延期になって行く傾向にあります。そう、いつまで経ってもできないのです。

また、経営者や担当役員からすると、「自分が就任している間に大きな事故を起こしたくない」という気持ちが優先し、システム更改に対する良い提案があっても承認しづらくなっているのではないかと推察します。
そして、「システムが経営をロックする」という状態がより強固となり、冒頭に書いた通り、より無駄・リスクが多くなるシステムを増産してしまって負のスパイラルに陥っている、ましてやDXなどうまくいくわけがない状態です。

解決への糸口

この根深い問題の根本にあるのは、「データの性質」です。旧来からシステムにおけるデータは不整合があってはならない、データこそ常に最新であるべきという神話に基づいているものです。そのため、アプリケーションがデータベースに対して「密結合」かつ「完全同期主義」になっています。その状態だとDBに対する負荷は増大する一方ですし、システムを一部切り出しながらマイグレーションを行うことも不可能になってきます。
さらに、アプリケーションはデータの形式にも縛られます。本来設定すべきではない「時刻を文字列として格納する」等で、無期限を9999年99月99日と表現するなど、本来のデータの型としての使い方ではない使い方がされているものですから、エラーを誘発するような表現や変換を余儀なくされているケース等、呆れるくらい数多く見ます。

解決策としてあるのは、「完全同期主義」を止めることと、データベースを業務単位で切り出すことです。
完全同期ではないデータとは、「結果整合性」という考え方を許容するものです。結果整合性が何かというと、ある時間内では整合性は保たれていることを受け入れるということです。
具体的には、人手による作業の記録などを見るのに、1秒遅れたからといって問題が生じることは殆どありません。0.01秒のズレもないような完全同期していなくとも、データが1秒以内に最新に更新されていれば業務は止まらないとするのであれば、非同期処理としてシステムを構築することは可能です。（非同期とはいえ、大概の場合は100ms以内にデータの登録が行われるような場合が殆どです。）
また、集計を行うシステムにおいても、元のデータと集計先のデータが完全同期で処理される必要は無く、データの発生時にデータをコピーしておき、集計は非同期で行っても業務に差し支えはないはずです。

システム的にはQueue（キュー）という、データを一時保管しておくバケツみたいなものを入れることで、疎結合化・非同期化が実現できます。現実世界で言うと、経理にある経費精算書類を入れておくトレーのこと、または郵便ポストみたいなものと思ってください。
ところが、日本の多くのシステムインテグレータで、Queueを提案するところがほぼ無い… なぜなら、完全同期主義にこだわり、Queueの技術をご存じないのです。

また、データを業務単位で切り出すことで、アプリの改修を行いやすくすることが可能です。この際にデータベースのデータの型や意味付けについても再構築することが重要です。この機会を逃すと、データの再構築はまた先延ばしになり、無駄なソースコードを山程作成しなければなりません。
まだある基幹システムとのデータの連携には、上記のQueueを利用したデータ更新技術を使うことで、既存の基幹システムを使い続けながら、少しずつモダナイゼーションすることが可能なのです。

まとめ

マイクロサービス化やDX等が叫ばれているのに、完全同期主義に縛られていると何も生まれません。業務の内容をよく考え、データの鮮度として数秒の時差を許容できるのであれば、非同期処理は積極的に利用すべき技術です。データの型違いにも柔軟に対応できるため、より使いやすい仕組みになります。

海外ではQueueを使った非同期処理は、金融の世界も当たり前になってきています。「結果整合性」を受け入れることで、あらたなビジネスも出てきています。
日本の基幹システムにおいても、「完全同期主義」を捨て、「結果整合性」を受け入れることで、リスクを少なく費用を安く、メインフレームベースの基幹システムから脱却することはまだまだ可能です。無策であり続けて本当にどうしようも無くなる前に、是非、経営層から検討の指示を出すべきと思います。

そろそろ、システムが経営をロックしている状態から開放しましょう。