基幹業務システムはどのようにオンプレからクラウドネイティブに変化してきたのか

株式会社ヘンリー VPoTの戸田です。弊社ではクラウドネイティブ型電子カルテをご提供するうえで、オンプレやクラウドリフト、シングルテナントといったシステム構成とクラウドネイティブ型マルチテナントがどう違うのかを説明する機会が多くあります。都度相手に合わせて内容を調整したご説明をしているのですが、一度基幹業務システムの変化について網羅した説明をすることが今後の役に立つと考え、こちらの記事としてまとめました。

なお筆者が基幹業務システムに関わり始めたのは2000年代後半からで、それよりも古いものには伝聞が入っています。もしお気づきの点があれば @Kengo_TODA までコメントいただくか、はてなブックマークなどでコメントいただければ幸いです。

基幹業務システムはこの30年で大きく姿を変えてきました。

メインフレーム（ホストコンピュータ）
拠点内オンプレミス
データセンターでの運用代行
IaaS上へのクラウドリフト
クラウドシフト（クラウドネイティブ化）
そして、シングルテナントからマルチテナントへ

本記事では、これらの変化が「なぜ起きたのか」を、技術とビジネスの両面から整理します。またこうした流れは多くの例外を含むものであり、ここに記載していない事例や動きもあると思いますが、ご理解ください。

※本稿ではメインフレームは目的から離れるため割愛します。

1. クライアントサーバー時代（2層構造）
- 特徴と制約
2. 三層構造とWebアプリの普及
- 何が変わったのか？
3. データセンターでの運用代行
- 何が変わったのか？
4. クラウドリフト（IaaS上でのそのまま移行）
5. クラウドシフト（クラウドネイティブ化）
6. シングルテナントからマルチテナントへ
- APIによる拡張
7. 経済合理性の転換
- クライアント数に応じたライセンス（クラサバ型）
- サブスクリプションモデル（クラウド時代）
まとめ
- 医療情報システムもクラウドネイティブに変化していく

1. クライアントサーバー時代（2層構造）

メインフレームから汎用系に移行した段階では、多くの業務システムはいわゆるクライアントサーバー型（クラサバ型）でした。

Windows上の実行ファイル（業務アプリ）
Oracle Database / IBM Db2 / SQL Server などのデータベース
クライアントが直接SQLを発行

flowchart LR
    subgraph 拠点内LAN
        Client[業務クライアント（exe）]
        DB[データベースサーバー]
    end
    Client -->|SQL| DB
    Client -->|SQL| DB
    Client -->|SQL| DB

特徴と制約

クライアントとDBが頻繁に通信するため、低遅延なLANが前提。たとえば東京にあるDBに大阪から繋ぐような構成では体験が悪くなる。
低遅延を実現するため、サーバーは業務拠点内に設置されることが多い。
端末ごとのインストール・設定作業が必要。端末数に応じた課金体系であることも多いため、利用者間で端末を共有させる力学が働いた。

この構造では、クライアントとサーバーが物理的に同じ拠点内にあることが前提でした。多拠点利用や在宅勤務といった働き方とは相性がよいとは言えません。またクライアントの管理がクライアントのユーザに委ねられているため、古いクライアントが使われ続ける・データベースに破壊的な変更を入れにくいなどの問題もありました。

2. 三層構造とWebアプリの普及

クラサバ型の制約を緩和するために登場したのが、三層構造（Web三層アーキテクチャ）です。国内のERPでは2006年前後の登場だったと思われます。

flowchart LR
    Client[クライアント（専用アプリ / ブラウザ等）]
    subgraph "サーバー設置拠点（拠点内またはDC）"
        Web[Webアプリケーションサーバー]
        DB[データベース]
    end
    Client -->|HTTP| Web
    Web -->|SQL| DB
    Web -->|SQL| DB
    Web -->|SQL| DB

何が変わったのか？

クライアントはHTTPリクエストを送る役割に単純化、人間とのコミュニケーションを担当。
DBとの通信をサーバー側に集約することで、通信回数が増える複雑な機能でも高速に動作。
低遅延なネットワークはデータセンター内でのみ求められるように変化。

これにより、クライアントとデータベースが直接通信する必要はなくなり、物理的な距離の制約が緩和されました。これは今日のSaaSと近い構成だと言えます。

ただし三層構造になったからといって、すぐに「ブラウザだけで完結」したわけではありません。2000年代には Java Applet や Silverlightのようなリッチクライアントと呼ばれる技術も試みられていました。これは当時のWeb標準技術だけでは、業務アプリに求められる操作性や表現力が十分でなかったためだと言えます。

その後、

HTML5やシングルサインオン技術などの標準化
JavaScriptエンジンの実行性能の改善
ブラウザやフレームワークの改善、ベストプラクティスの蓄積によるセキュリティの向上
Ajaxなど非同期通信の普及

といったWeb技術の成熟により、ブラウザ単体で高度な業務アプリケーションを実装できるようになりました。現在主流となっているHTMLベースのWebアプリは、こうした進化の結果だと言えます。

この段階で、「サーバーは必ずしも拠点内に置く必要はない」という前提が現実味を帯びてきました。ディザスタリカバリの観点からも複数箇所にシステムやデータを散らせられるなら強みになりますし、遠隔地に置けば土地代電気代をオフィスに置くよりは節約できるかもしれません。しかし遠隔地での保守作業が発生し、これを個社で負担するのは難しいものと思われました。

3. データセンターでの運用代行

次の段階は、事業者が実行環境を引き取るモデルです。専用事業者によるデータセンターでの運用代行そのものは大企業を中心に古くから実施されていましたが、サービス事業者が直接運用代行を提供するようになったのは2012年に提供されたCOMPANY on Cloud Managed Service (CCMS)*2や2013年に提供されたSAP HANA Enterprise Cloud*3からでしょう。

flowchart LR
    Client[クライアント（専用アプリ / ブラウザ等）]
    subgraph "サーバー設置拠点（事業者が管理するDC）"
        Web[Webアプリケーションサーバー]
        DB[データベース]
    end
    Client -->|HTTP| Web
    Web -->|SQL| DB
    Web -->|SQL| DB
    Web -->|SQL| DB

この流れをさらに後押ししたのが、従来暗黙の了解としてあった「社内ネットワークは安全である」という前提の限界が見えたことにあります。2014年以降にGoogleが提唱したBeyondCorp*4では、拠点内ネットワークに依存したセキュリティモデルはもはや成立しないこと、そして「出社して社内ネットワークからアクセスする」ことを前提にしたシステム設計自体が時代遅れになりつつあることが示されています。オンプレミスで拠点内にシステムを置くモデルは物理的な境界を信頼の根拠としていましたが、クラウドサービスの業務利用増加やこれに伴う物理オフィスへの依存低下、リモートワークやモバイル端末の普及、攻撃の高度化などの要因により、その前提が崩れたのです。この流れはこの後のコロナ禍によって加速されることになります。

こうした問題意識は、データセンター移行の合理性を説明するうえでも重要です。物理的な拠点境界ではなく、ユーザーとデバイス単位で信頼を判断する設計へと移行する中で、システムをデータセンター側に集約することは自然な流れだったともいえます。この流れは「所有から利用」とも呼ばれ、ITシステム部門がシステムの面倒を見る役割だけでなく、ITをテコにして業務改革を推し進める役割を深めるきっかけを作りました。

何が変わったのか？

システム構造自体は従来の三層構造のままです。ここでは技術的な革新以上に、ビジネス観点の変化が大きかったと言えるかもしれません。顧客がしたいのはシステムの保守や運用ではなく、そこから得られるアウトカムにこそ関心があるのだということが一般に理解されてきたということです。

筆者はエリヤフ・ゴールドラット博士の著書「チェンジ・ザ・ルール！（原著 Necessary But Not Sufficient）」が好きなのですが、この物語ではまさに運用代行というビジネスモデルが出てきます。これが書かれた2001年前後では大企業を中心とした一部分でのみで運用代行が行われていたようですが、BeyondCorpが出た2014年時点では前述のとおりサービス事業者が手掛けることが基幹業務システムにおいても一般的になっています。実績が認められキャズムを超えて、よりスケールする方法として洗練したタイミングだと言えるでしょうか。

もちろん基幹業務システム事業者から見た場合に、顧客の拠点においてあるシステムよりも自社のインフラで運用されているシステムの方が保守業務とくにハードウェア増強がしやすいという観点もあります。しかしこの時点では基幹業務システムはコードやデータベースに手を加えて（カスタマイズして）使うことが一般的で、システム更新のしやすさという観点ではそこまで大きな飛躍はなかったと考えます。

4. クラウドリフト（IaaS上でのそのまま移行）

これはデータセンターでの運用代行と同時期に進んだものと思われます。2006年に登場したAWS EC2のようにインフラストラクチャを画面やAPIから調達できるIaaSが登場すると、既存システムをそのままパブリッククラウド上に移行する「クラウドリフト」が始まります。ランニングコストではデータセンターに劣ることが多いものの、ハードウェアの納品を待つ必要がない・APIによる自動化の幅が大きかったことは大きな魅力でした。特に検証用環境*5は夜間や祝日は不要となるため、従量課金の恩恵を得やすい環境でした。

その後は2013年にRDSが一般公開されるなど、従来オンプレで動かしていたシステムをEC2, S3, EBS, RDSなどを組み合わせて動かせるようになっていき、爆発的に普及していきます。

flowchart LR
    subgraph AWS
        EC2[EC2上のアプリ]
        RDS[RDS / DB]
    end
    User --> EC2
    EC2 --> RDS

IaaSの利点は、何と言っても既存コードが流用可能なことです。今までのアーキテクチャのまま、小さな初期投資だけでクラウド上にサービスを稼働させられます。オートスケールや分散処理のようなクラウドの潜在的な可能性を引き出すには不十分ですが（Ansibleなどを整理しても実装に手を加えなければ効果が薄い）、システム運用をしなければならないという顧客のペインをスピーディに解消するには十分でした。

5. クラウドシフト（クラウドネイティブ化）

クラウドの強みを活かすにはオートスケールや分散処理を活かすためのアーキテクチャでシステムを組み直す必要があります。状態を持たないサーバ、筐体が壊れたら捨てて新しいものに乗り換える仕組み、負荷に応じて計算機資源を追加・削除する自動化、クラウド事業者が提供するプラットフォームを活用することによる運用責任の縮小などを前提にシステムを組むのです。コンテナの活用もこれに含まれます。こうした変化を受け入れてはじめて、次のようなクラウドの恩恵を享受できるようになります：

計算機資源を想定される最大負荷に合わせて調達するのではなく、都度必要な分だけ支払う従量課金
縦方向（筐体の能力向上）だけでなく、横方向（筐体台数の追加）による柔軟な拡張
複数データセンターでの同時サービス運用による高可用性の実現

サービスの更新におけるサービス停止の必要性が下がったのも特徴で、これにより継続的なデプロイが可能になりました。いままではサービス停止を避けるためにマスタや設定の更新で乗り切っていた機能提供や法対応もより素直な方法で行えるようになり、また脆弱性対応もスムーズに行えるため、サービス事業者側の運用コストも下がったと考えられます。

6. シングルテナントからマルチテナントへ

もうひとつの大きな変化がテナントモデルの変化です。従来は顧客ごとに専用環境を構築しており、これが顧客ごとにデータベースやコードを改修すること（カスタマイズ）を可能としていました。またシステムを止めてメンテナンスをするタイミングも顧客が選べていました。

これらは一見便利ですが、カスタマイズがシステムの更新を難しくし脆弱性を生み出したこと、システムが硬直化することで業務の運用も硬直化してしまうこと、新しい技術が採用しにくく結果的に競争力を失うこと、何よりも運用と更新の手間とコストが高いため情報投資効率が上がらないことが課題になりました。

たとえば基幹業務システムに何らかの不具合が見つかったとします。その際はすべての顧客が使っているバージョンを洗い出し、そのバージョンそれぞれに対するパッチの作成とビルド、出荷物の作成及び評価そしてお客様環境での適用が発生します。シングルテナントのシステムでこのコストが非常に高くつくことはご想像のとおりですし、オンプレミスのシステムであればさらに稼働環境の多様性という問題も出てくることになります。

クラウドネイティブ型かつマルチテナントの基幹業務システムであれば、保守するバージョンを少なく保つこともそれを顧客にデリバリーすることも比較的容易にできます。浮いた工数を製品の機能や運用の改善に充てることで、より本質的な価値を顧客に届けることに注力できると期待できます。

APIによる拡張

マルチテナントが可能になったことは、すなわちカスタマイズ文化を捨てられたことを意味します。ではなぜそれまでは必須だと思われていたカスタマイズをやめられたのでしょうか？その背景にはAPIの普及があります。

ERP界隈では統合型ERPからコンポーザブルERPへの移行と表現されました*6が、サービスに直接手を加えるのではなく、サービスがデータを交換する仕組みを提供することで従来やっていた独自運用を実現できるようになったのです。APIが互換性を維持すれば基幹業務システムの更新とアドオンの更新とは分けて実施ができますから、異なる事業者が提供するシステムを組み合わせて運用を実現することも十分に可能です。

7. 経済合理性の転換

もうひとつ興味深い変化として会計・財務構造の転換があります。

クライアント数に応じたライセンス（クラサバ型）

従来のオンプレミス型、特にクラサバ型では次のような費用感が一般的です。初期投資が大きく、利用者数が増加すると追加ライセンス購入になります：

サーバー購入（固定資産）
CAL（Client Access License）購入
5年程度を前提とした減価償却

特にCALモデルでは、「1ユーザーあたり何ライセンス」という考え方が前提となるため、端末や利用者を柔軟に増やすことが難しい場合がありました。

クラサバ型だった時代にCALが必要とされた背景には、クライアント端末ごとに業者側がメンテナンスコストを負担していたという事情があります。業務アプリはexe形式で配布され、各端末へのインストール、設定、アップデート対応が必要でした。もちろんサポートの負荷も、端末が増えれば増えるほど比例して増加します。そのため「接続する人数分の対価を支払う」という設計は、当時としては合理的でした。

しかしこれは同時に、利用者の利益や利便性と必ずしも一致しないライセンス体系でもありました。利用を広げたい場合でも追加ライセンスの購入や端末設定作業が障壁になり、端末の共有利用を検討することになります。また導入したい端末を見つけてもサービス事業者がサポート外になると言えば採用できません。業務設計の自由度が低い状況だったと言えます。

一方、ブラウザで動作するSaaSでは事情が大きく異なります。ソフトウェアのインストールは不要で、ユーザーはURLにアクセスするだけで利用できます。アップデートもサーバー側で一元管理されます。この構造では、端末ごとに個別メンテナンスコストをかける必要が薄れるため、従来型のCAL的発想は必然性を失っていきました。

サブスクリプションモデル（クラウド時代）

クラウドSaaSでは多くの場合、次のような費用感が一般的です：

サーバー購入不要
利用人数など単位の柔軟な増減
月額／年額課金

このモデルだと利用者の判断で端末やアカウントを追加できるようになり、1人1台以上の業務端末を配布することも現実的になります。端末の共有がやめられるとアカウントや業務の運用設計がシンプルにできるため、DX推進にも良い影響があります。

また会計上の柔軟性も利点のひとつです。5年分の前払いが不要になりキャッシュフローが改善することや、減価償却管理が不要になること、管理会計上で費用として処理しやすいことなどは、動きの早くなったビジネスにおいて重要でしょう。

まとめ

業務システムは次のように進化してきました：

クラサバ型（拠点内前提）
三層Webアーキテクチャ
データセンター運用代行およびクラウドリフト
クラウドシフト（クラウドネイティブ化）
マルチテナント

この進化は複数の技術革新と、ビジネスモデルの変化によって支えられています。システムの保守や運用ではなくアウトカムをこそ顧客に提供するという目的意識を最新技術が支えることで、高い情報投資効率を実現するという構造です。

カスタマイズができない、顧客が具体に関与できないという従来モデルとの違いはありますが、それを乗り越えるための方法もすでに色々と検討され実績があります。むしろカスタマイズという個社ごとの高価な最適化を離れ、アドオンという再利用しやすく安価な方法として業界としての知見やベストプラクティスを蓄積することによって、イノベーションを加速させた面もあるでしょう。

医療情報システムもクラウドネイティブに変化していく

さて医療情報システムを振り返れば、この領域でもクラウドネイティブ化が進んでいくことは弊社note記事でも述べたとおりです。レセプトコンピュータや電子カルテについては既にクラウドネイティブ化が進んでおり、今後は部門システムにおいても同様の方向性を国として目指していることが先月公開された「中小病院向け電子カルテ及びレセプトコンピュータ標準仕様書（基本要件）（案）」でも触れられています：