デジタル庁が向かうDXへの「モダナイゼーション」の在り方
ヴイエムウェアという会社で、公共分野のお客様を担当している中島です。私が考えるDXへのアプローチについて、このような形で発信していこうと思っています。
現在、デジタル庁設立に伴い、行政のDXが進められていくという機運が高まっています。行政に限らず、DXに向けては、考えなければならないことが非常に多くあります。その中でも「継続的改善」を実現することが、行政において最もハードルが高いのではないかと考えています。DXに成功しているケースは、このテーマへのアプローチを欠かしていません。
世の中は常に変わり続けており、一時の正解は存在しても、未来永劫正しいなんてことは非常に稀です。そのため、常にフィードバックを受けて、それを元に改善し続けるということがDXに求められることだと言えます。また、初めから完璧にできることも少なく、徐々に改良していいくことも非常に大切なことです。
このような「継続的改善」を実現し、DXを加速するためには、UI/UXという観点で語られることも多く、それも非常に重要ですが、そこに焦点が当てられ過ぎな場面も多々見受けられます。DXを実現するアプリケーションは、クラウド等のプラットフォームと深く紐付いており、併せてよく考えなければならないと思います。「継続的改善」を遂行していくに当たり、技術の観点からは以下の2点を考えていかなければなりません。
・アプリケーションアーキテクチャ
・クラウドプラットフォーム
「継続的改善」のために、アプリケーションには「マイクロサービス」というアーキテクチャがよく求められます。対義語は「モノリシック」アーキテクチャになりますが、いわゆる1枚岩のようなアプリケーションの作りになっているものを指します。
また、クラウドにおいても、スモールスタートしやすく、スケールもできる「パブリッククラウド」を利用するほうが良いとされています。クラウド事業者がデータセンターからインフラ運用までを行い、そこから切り出されたサービスをネットワーク越しに利用するというイメージになります。その中でもAWSやAzure、Google Cloud PlatformなどのNative Cloudと呼ばれている従量課金制の仕組みを持っているものを指されることが多いと思います。対義語の「プライベートクラウド」は、ほとんどのケースで自社もしくはSIパートナーと一緒に、データセンターを借り、ハードウェア購入から構築・運用までをおこなうことが一般的です。
モノリシック vs マイクロサービス
モノリシックの場合、1つのアプリケーションの中に全ての業務プロセスが包含されています。そのため、1つの間違いがそのアプリケーション内の全てに影響を及ぼしてしまいます。また、処理量の増減に伴い、制御する単位がアプリケーションごとになるため、大きな単位となりがちです。また、少しの修正に対するテストを行う際にも、非常に多くのチェックをしなければなりません。
デメリットばかりのように見えますが、これからお話しするマイクロサービスアーキテクチャのように通信し合うような仕組みではないため、1つの組織でそのアプリケーションのことだけを考えて開発するには適した方法と考えられており、過去のITシステムで稼働してきたアプリケーションアーキテクチャとして一般的でした。
しかしながら、まさにこれがDXにより解決すべき問題ということにもなっています。自身のアプリケーションのことだけを考えて開発されてきたため、システム間で連携して価値を生み出そうというケースにおいては有効な手段かどうかは改めて検討が必要です。
対するマイクロサービスは、業務プロセスごとにアプリケーションを分割することで、影響範囲をその業務プロセス内に留め、求められる業務プロセスだけ、スケールイン・スケールアウトさせることができるようなアーキテクチャです。そのため、テストの範囲も限定化されており、DXに求められる「継続的改善」に適したものと言えるでしょう。
マイクロサービス＝コンテナと捉えられることも多いですが、マイクロサービスのようなことを実現する上では、軽量性・可搬性といった観点でコンテナが適しているということが言えるのではないかと思います。しかし、アプリケーションをどのように分割するのか、分割されたアプリケーション同士をどのように通信し合うのか、開発組織間でどのようにコミュニケーションを取りながら全体統制をしていくのかには、まだまだ技術者の習熟度が追いついていないのが現状と言えます。
こういった観点からも、行政においては、完成品を求める調達方式ではなく、継続した運用開発を前提とした調達をしなければならず、それを現在の調達方法で実行しようとしても難しいため、調達方法を根本から見直すか、行政側に運用開発ができる人材・組織を置くといういわゆる「内製化」を目指すということが求められてくるわけです。
プライベートクラウド vs パブリッククラウド
続いてクラウドについてです。プライベートクラウドは、先述の通りデータセンターのラックを借り、ハードウェアからアプリケーションが動作できる環境を構築運用した状態のものです。自分たちだけの環境となるため、非常に自由度が高く、最も適切な組み合わせを選択して、作り上げることができることがメリットです。その代わり、構築・運用者を雇う、もしくは契約する必要があり、サーバー1台だけ立てたいというようなケースには向いていません。また、一度購入したものを増やすのはまだしも、減らすことはほとんどのケースで難しく、増やす場合でもハードウェアを購入してから届くまでに時間がかかるため、すぐに追加するようなことはできません。
一方、パブリッククラウドはプライベートクラウドの弱い部分を解消するようなものになっています。1サーバーだけ必要なケースから対応しており、少なくともハードウェアを始めとするインフラ構築・運用者というのは不要になります。また、従量課金制度を利用することができ、即時にサーバーを増やしたり、減らしたりすることで、需要が読めないシステムに対して非常に有効です。ただ、携帯電話の従量課金と同様で、固定されたリソースに対して、パブリッククラウドの従量課金で利用する場合と、プライベートクラウドの固定料金で運用したケースで、どちらが安いかについては、どこまでのコストや既存資産・人材を含めて考えるかによるため、一概には言えませんが、単純にインフラという観点のみに絞ると、仕組み上からもプライベートクラウドに分があると考えられます。また、別の記事で詳しく述べたいと思いますが、SLA（サービスレベルアグリーメント）を担保するために、今までのアプリケーションアーキテクチャをパブリッククラウド仕様に改修しなければならないケースも有り、注意が必要です。
DXを実現するためのシステムのモダナイゼーション手法
ご覧いただいたとおり、アプリケーションアーキテクチャの観点でも、クラウドプラットフォームの観点でも、優れているところと考慮すべきところがあります。そのため、判断基準とその度合いから、適切なアプリケーションアーキテクチャとクラウドの最適な組み合わせを選択し、人材、コスト、社会的影響に対して、どのシステムをどのような在り方にしていくかを判断していかなければならないと思っています。
例えば、e-Taxのようなシステムにおいては、確定申告の期間のアクセスが多いものの、その他の期間には負荷が限られているとすれば、一時のアクセス負荷に耐えられるようなシステムをプライベートクラウドで立てつけると多くの無駄が発生するでしょう。
また、改修期間が法律の改正から執行まで数年単位で掛かるアプリケーションに対して、マイクロサービスアーキテクチャに移行したところで、そのために掛けるコストや用意した人材・組織が果たして適切なのかということになります。お金が無尽蔵にあるわけでもなく、人材も溢れかえっているわけでもないので、システムの在り方を考えながら、最適な組み合わせと優先順位を設定する必要があります。
以上のように、DXを実現するにあたり、「継続的改善」というテーマに対して、アプリケーションアーキテクチャとクラウドプラットフォームの選択が非常に重要ということがおわかりいただけたかと思います。今後は、この前提を元に、行政DXの中心にいる「自治体システム標準化・共通化」に対して、どのようなことを考えていくべきなのかについて、述べていきたいと思います。