延びた“そうめん”の固まりのような、旧態依然としたシステムをデジタルトランスフォーメーションに導くための3つのポイント：スパゲティより複雑

デジタルトランスフォーメーションに向けた取り組みでは、エンドユーザーに優れた体験価値を担保するために、フロントエンドのアプリケーションのみならず、そのバックエンドを含めた、“システム全体”にもニーズの変化に即応できる柔軟性が求められる。言い換えると、ビジネスを向上、成長させるためには、システム全体をビジネスに合った形に最適化し続ける「モダナイゼーション」が必要となるのだ。では、旧態依然としたシステムを抱えた企業が、モダナイゼーションに取り組むには、どうすればいいのか？――さまざまな企業の相談に応えてきたレッドハットに聞いた。

[PR／＠IT]

PR

旧態依然としたシステムに見られる3つの特徴

　テクノロジーの力で新しい価値や利便性を生み出す「デジタルトランスフォーメーション」に向けた取り組みでは、エンドユーザーの支持を獲得するために、ニーズの変化に合わせてアプリケーションを改善し続けていくことが欠かせない。優れた体験価値を担保するためには、フロントエンドのアプリケーションのみならず、そのバックエンドを含めた、“システム全体”にもニーズの変化に即応できる柔軟性が求められる。

　言い換えると、ビジネスを向上、成長させるためには、システム全体をビジネスに合った形に最適化し続ける「モダナイゼーション」が必要となるわけだが、「旧態依然としたシステムを抱えた企業は大きく3つの問題に悩んでいます」とレッドハットのテクニカルセールス本部 プリンシパルソリューションアーキテクト BRMSエバンジェリストである梅野昌彦氏は指摘する。

レッドハット テクニカルセールス本部 プリンシパルソリューションアーキテクト BRMSエバンジェリスト 梅野昌彦氏

　「最大の問題は、アプリケーションのメンテナンスに時間とコストがかかり過ぎること。ビジネスのアジリティが低くなるため、何とかして変えたいと思っているのに変えられずにいます。われわれに来る相談の中では、このパターンが最も多い。2つ目はロジックが“スパゲティ”状態になり、手が付けられなくなっていること。既存のロジックに手を付けずに新しいことをやろうとすると影響分析が雪だるま式に増えさらに手が付けられなくなります。3つ目は、これらの結果、新しいアイデアがあってもチャレンジできなくなること。ビジネスチャンスをみすみす逃してしまっています」

　これらの課題に共通する原因は、「データ」「ロジック」「プロセス」「画面」が混然一体になっていることにある。梅野氏によると、何をするにしてもデータベースにあるマスターを参照してアプリケーションを作っていくケースが非常に多いという。この場合、アプリケーションはデータベースに直接クエリを投げる形でコーディングされることになる。しっかりマスターが管理されていればいいが、実際には「新しい業務ルールを加える際に別のマスターを新たに作る」といったことが行われやすい。また、少しの変更で済むという場合は「マスターではなく、コードの中に例外処理を入れてしまう」といったこともよく起こる。

　「このように、データやロジックが少しでも混ざり出すと、そこから一気にスパゲティ化が広がります。だんだん手が付けにくくなり、最終的には、延びた“そうめん”のように固まって1本1本を解きほぐすことすらできなくなります。では、どうすればいいか。そこで重要になるのが、アプリケーションの中の役割である、ルール、データ、プロセス、画面をしっかり分離したアーキテクチャを考えることです」

アーキテクチャのポイントはディシジョンサービスの切り分け

　ルール、データ、プロセス、画面を分離したアーキテクチャとするには、それぞれが持つ役割をサービスとして切り出し、お互いに直接参照させないようにデザインすることがポイントとなる。

　例えば、データは、顧客情報、購買履歴、決済情報などを蓄積しておき、呼ばれたときに情報を返すだけの「データサービス」として切り出す。また、ルールは、データを集計したり、チェックしたりするエンジンに特化した「ディシジョンサービス」として切り出す。ルールを実行する場合は、ルール実行前に、ルール実行に必要なデータをデータベースからあらかじめ収集しておき、ディシジョンサービスにそのデータを使用する形だ。

　「データの役割、意思決定の役割を切り分けて、それぞれのサービスを呼ぶ形にします。キモはディシジョンサービスから直接データサービスを参照させない点。この点だけは心を鬼にして取り組む必要があります。一度でも許してしまうと、このアーキテクチャを採用する意味が何もなくなってしまいます」

　アプリケーション内部で全ての処理を行うと、ルールの更新や追加が行われるたびに新たなパスや参照関係が発生し、アプリケーション自体が複雑になっていく。だが、ビジネスルール部分をルールエンジンを使ったディシジョンサービスとして切り出し、データベース（データサービス）へのアクセスをアプリケーション側で行うようにすることで、アプリケーションは必要なときに必要なサービスを呼ぶだけのシンプルな構成にすることができる。

　こうしたビジネスルール管理システム（BRMS）を適用したアーキテクチャを徹底すると、アプリケーションも非常に見通しの良い構造を持つことになる。下図は、ある申請・承認ワークフローのアプリケーションアーキテクチャを示したものだ。

BRMSを適用したアプリケーションアーキテクチャの例

　このアプリケーションでは、入力画面からの要求に対して、プロセスサービス、データサービス、ディシジョンサービスが切り出されており、それぞれが要求に応じて連携して動作する。データ項目の追加を伴わないルールの修正や追加はルールエンジンの変更だけでよく、データ自身の修正や追加はデータベースに対して行うだけでよい。また、プロセスも、ビジネスプロセス管理（BPM）によってステータスを管理することが中心となる。

サービスの粒度は改変速度と影響範囲で決める

　梅野氏は、BRMSアークテクチャを採用して効果を上げた、ある製造業の調達システムの事例を紹介する。この会社の調達システムでは、発注する部品が1500種類以上あり、それぞれで発注プロセスが異なっていた。利用する部品が変わるたびにプロセスを変えなければならず、非常に手間だったという。そこで、部品ごとに異なるプロセスを1500のルールとして切り出し、プロセス自体を3つにしぼり込んだ。

　「プロセスの更新頻度は、ほとんど変わりません。5年ほど経過して3つのプロセスが5つに増えた程度です。一方、部品を場合分けするためのルールは毎週のように変わっています。このように、ディシジョンルールを切り出し、動的に変更できるようにすることで、ビジネスのスビードに合わせた柔軟なシステムの変更が可能になるのです」

　この事例のように、プロセスやルールの改変速度の違いに注目することは、サービスの粒度の設計に大きく関わってくる。梅野氏は、サービスの粒度を決める際には、変更が速いか遅いか、変更の影響範囲が限定的か広範囲かという2軸で整理すればよいとアドバイスする。

改変の速度に合わせたアーキテクチャ

　例えば「画面」は、デバイスや方式といった新しい技術が次々と投入され、さらにデザインにもはやり廃りがある。かなりの頻度で変更が入るものだ。一方「データ」は、基本的なデータ構造を設定した後は、そう簡単には変更できない。変更してしまうとアプリケーション全体の作り直しに発展する可能性が大きく、それは業務を止めかねない。同じようにして、「他システム連携」は変更が速いが影響範囲は限定的、「認証」は影響範囲がやや広いが更新頻度は少ない、といったようにしてサービスの粒度を決める。その上で、サービスの中の何をルールエンジンによって処理していくかを決めていくという。

　「変更のスピードや影響範囲を基準とした切り分けにすることで、メンテナンスの効率も変わってきます。更新頻度が多く影響範囲が広いものはその分管理が大変です。そこでルールとして切り出し、速やかに変更できるようにするのです。このように、ルール、プロセス、データという3大要素に注目し、アーキテクチャの中でサービスの粒度をしっかりと設計していくことが、変化に追随できるシステムにつながっていきます。変更のスピードと影響範囲を考えることは、DevOpsなどの取り組みにも生かせると思います」

モダナイゼーションを成功させるための3つのポイント

　では、具体的にどうシステムをモダナイゼーションしていくのか。梅野氏はアプリケーションモダナイゼーションで重要なポイントを3つ挙げる。

　1つは「アジリティのあるアーキテクチャに変更すること」だ。これは、これまでに見てきたようなディシジョンサービスを使ったアーキテクチャを採用することを指す。既存のアーキテクチャを見直し、混然一体となったデータ、プロセス、ロジック、画面を分離していく。それぞれを疎結合なサービスとすることで、それぞれの役割に合った変更を行えるようになる。全体がシンプルになることで、何を変更すればよいかが分かりやすくなり、それがアジリティの向上につながる。ビジネスチャンスを逃さないために、ビジネスニーズに合わせた柔軟さを備える必要がある。

　2つ目のポイントは、モダナイゼーションを行う際に「“ごみ”を持っていかない」という点だ。“ごみ”というのは、モダナイゼーション後のシステムに必要のないロジックのことだ。モダナイゼーションでは、ソースコードをコンバージョンする方式が取られることがある。ただ、この場合、必要のないソースコード上の“ごみ”までコンバージョンして新システムに持っていくことになり、せっかくのモダナイゼーションの意味が薄れてしまう。レッドハットの経験からすると、既存のロジックで使われていない“ごみ”は、全体の4割から6割にも達するという。また、システム移行に際して設計書がアップデートされておらず、最新の設計書になっていない場合がある。ルールを管理していることでExit Cost（移行コスト）を抑えることが可能となる。

　「重要なのは、業務要件仕様書からロジックを再度構築することです。ルール、データ、プロセスを整理して構造をシンプルにします。特に、データベースへのアクセスはロジックに投入する前に集約し、ルールエンジンで実行することを徹底します。ルール化の手法としては、意思決定モデリング（Decision Model and Notation）などの標準手法を用いることができます」

　ある意味、モダナイゼーションは、業務要件仕様書などから新しいシステムを作り直す作業ともいえる。そこで重要になるのが、3つ目のポイントである「テストをしっかり行うこと」だ。旧システムと新システムの整合性を担保するために、既存の処理結果と同じ結果になるまで追い込んでいく。

　そのためには、“リアル”なテストデータをユーザーに準備してもらうことが重要だ。テストというと、ベンダーが用意したサンプルデータで行うことが多いが、この場合、テストを通すためのデータになりがちで、ほとんど意味がないという。

　「そこで、実際に使われた過去のデータを使ってテストします。データを投入して、一致率を算出し、それが100％に近づくように、ルールの開発と改善を繰り返していきます。データの一致率は、進捗（しんちょく）度と読み替えることができます。80％だったものが90％に上がったなどと一致率を見ながら、開発と改善でフォーカスすべき点を決めていくのです。ここで重要なポイントは容易にルールが変更できる環境があるかどうかです。1つのルールを変更するのに時間と手間がかかってしまったら意味がありません」

データの一致率を使ったテストの管理の例

ルールエンジンによるデジタルトランスフォーメーションに向けて

　このようなルールエンジンを使ったモダナイゼーションは、COBOLなどの旧資産をJavaに移行するといったケースに限らない。古いJavaフレームワークを最新環境に移行したり、現場で複雑に発展してしまったExcelシートからWebシステムへ移行したりするときなどにも活用できる。「ルールエンジンはツールにすぎません。ルールを整理することこそが最重要であり、複雑化した業務をシンプルにすることが求められるあらゆる領域に活用できます」

　その意味で興味深いのは、ルールエンジンを使ったモダナイゼーションを、単なるシステム移行にとどめず、新しいビジネス価値を生むシステムへと発展させていった事例だ。

　レッドハットが支援したある自動車部品製造企業では、Perlで内製化していた工場の機器の異常を検知するモニタリングシステムが複雑化し、管理や改変に手間がかかっていた。そこで、ルールエンジンを入れることで複雑化した業務をシンプルにすることに取り組んだ。その結果、それまで変更に2週間ほどかかっていたルールのメンテナンスが1日でできるようになったという。ルールエンジンやルール管理には「Red Hat JBoss BRMS」が採用され、ルールの表記はスプレッドシートで管理されている。

　その成果を受けて次に取り組んだのは、システムのSaaS化と他社への販売だ。サービスはJavaのマルチテナント環境で動作させていたが、ユーザーと処理量が増える中、システムの負荷と管理負荷が高まっていた。そこで、アプリケーションをコンテナ化し、運用の簡素化とデプロイの高速化を図った。コンテナ環境の管理には「Red Hat OpenShift Container Platform」が採用された。これにより、急激なシステムへの負荷に対してオートスケーリングの構成を得られただけではなく、ルール変更に伴う構成変更や新しい顧客へのデプロイがより容易となった。また、他の業務アプリケーションに関しては同じOpenShift環境でDevOpsによる開発、運用を実施することが可能になった。

　さらに、この企業は、サービスの提供によって得られる一時的なモニタリングデータではなく、長期にわたり得られる過去データの提供を顧客から要望される。そのため、一時的な改善ではなく長期で起こる事象に関しても分析したい顧客へデータを販売する新ビジネスを立ち上げようとしている。データをAPI化し、外部からアクセスできるようにした上で、アクセス権限の仕組みやAPI管理の仕組みを構築。ここでは「Red Hat 3scale API Management」を採用する予定だ。

　このように、単体アプリケーションとして稼働していたシステムはルールエンジンによるモダナイゼーションを経て業務の効率化を達成した。さらにコンテナ化することで、さらなる効率化と迅速にサービスを提供できる環境を得て、さらなる新規ビジネスのためにAPI管理の仕組みまでを取り入れていった。まさに劇的なデジタルトランスフォーメーションを遂げることになったわけだ。

　アプリケーションモダナイゼーションを進める上で、DevOpsやアジャイルAPIインテグレーションは、より効率を得ることができる重要なポイントであり、またDevOpsを進めていく上でアジャイルAPIインテグレーションやアプリケーションモダナイゼーションは共に考えるべき項目である。

　「ルールエンジンを使ったモダナイゼーションは、レガシーシステムのマイグレーションだけにとどまる技術ではありません。デジタルトランスフォーメーションに向けて、コアビジネスをどうビジネス化していくか、その課題を解くカギの1つなのです」