レガシーシステムの大規模データはバッチ方式で処理するケースが多い。以前のコンピュートリソースではパフォーマンス確保が難しいという性能面の制約があったからだ。また、複数システムから多岐にわたるデータを都度収集するのは、かえって非効率なため、バッチ方式が適していた面もある。

　ただ、レガシーマイグレーションに取り組む際は、この大規模バッチ処理がハードルになりがちだ。「開発から時間が経っており、ドキュメントが残っていないことは理由の1つです。処理ロジックを理解するためにはソースコードを分析する必要があります」とBlueMemeの工藤 忠幸氏は理由を述べる。

　コードが何百万行もある大規模システムの場合、分析に数年かかることもある。しかも、処理内容は分析できても「どのような業務課題を解決するための処理か」を理解するのは至難の業だ。また、長年の間に繰り返された修正で構造が複雑化しているケースも多い。結局、分析するほうが新規でつくり直すよりもコストや時間がかかるという事態が発生しているという。

　このような事態が起こる要因について、工藤氏は「システム開発の上流工程で作成されるべき『ビジネスアーキテクチャー』の不在が主な原因です」と指摘する。

　ビジネスアーキテクチャーとは組織の構造や機能、業務プロセスなど、企業の活動全体を示したもの。「どのような業務のために稼働しているか」を示すものであり、業務システムの要件は、すべてこれに基づいている（図1）。

システムは大きく3階層で成り立っている。最上位がビジネスアーキテクチャーだが、これがドキュメント化されていることは少ない。結果、アプリケーションアーキテクチャーにフォーカスした開発が増えている

　「ビジネスアーキテクチャーがあればドキュメントがなくてもシステムをつくることが可能です。ソースコードを解析して、処理の内容と業務の内容をマッチングさせることもできます」と工藤氏は言う。

　しかし、一般的なシステム開発の要件定義では、主にアプリケーション機能の分析と設計が重視されており、業務機能とアプリケーション機能の区別ができていないことが多い。特にバッチ処理は業務担当者が直接的に触れる画面がないため、ビジネスアーキテクチャーで表現されるべき業務の構造化がほとんど実施されない。必然的に目が向くのが、システムが持つ機能や処理の流れを表現したアプリケーションアーキテクチャーとなるわけだ。

　「『なぜその機能が必要か』『業務上どのような役割を担っているか』が誰も分からない状態になっています。そのため、処理内容と業務をマッチングさせた再現が難しいのです」と工藤氏は語る。

　その点、ローコード・ノーコード開発ツールを用いればアプリケーションアーキテクチャーの開発は大幅に簡素化できる。そこで同社は、これによって生まれるリソースを、上流工程であるビジネスアーキテクチャーの分析・開発に振り向けることを提案している。

　現行業務を分析し、バッチ処理が「何をやっているのか」を業務視点で明確にする。これによりビジネスアーキテクチャーを整備してシステムの再現性を確保するアプローチこそが、大規模バッチ処理を最適化する際の理想像だという考え方だ（図2）。

システムの開発やテストはローコードツールで効率化する。これにより、ビジネスアーキテクチャーの分析やバッチ処理の設計といった上流工程の開発にリソースをシフトできる

　「近年、広く活用されているローコード開発基盤の1つが『OutSystems』です。設計情報が明確になるため、システムの再現性も非常に高い。当社も2012年にOutSystemsを国内で初めて販売開始して以降、多くの企業の導入・活用を支援してきました」（工藤氏）。一方で、OutSystemsにはビジネスアーキテクチャーを定義する機能が存在しない。そこでBlueMemeは、ビジネスアーキテクチャーを扱うことができる別のツールとの組み合わせによる活用を提案している。

　それがインテリジェント・モデルの「ODIP」だ。これは複雑な大規模バッチ処理に特化された、GUIで簡単に構築・運用できるローコード開発ツール。最大の特徴は、自然言語を使ってバッチ処理を設計できることである。

　「データソースが何で、それをどう加工して、どう出力するのか。業務プロセスを細かく分析して、データの構造や種類、業務ルールやそれを実行する処理などを、使いなれた業務用語で記述して定義できます」と工藤氏は説明する。

　複雑な計算や関数を使った業務ルールも、難しいプログラミング言語を使うことなく自然言語で作成・表現できる。ノーコードによるバッチ処理開発が可能だ。「企業独自の業務ルールを業務用語で表現することで、ビジネスアーキテクチャーをベースにしたバッチ処理の設計・開発を簡単に行うことが可能です」と工藤氏は強調する。

　1つの設計モデルから様々なデータベースに対応したバッチ処理を開発できる点も強みだ。具体的には、SQL ServerやPostgreSQL、Oracle Databaseなどの代表的なリレーショナルデータベースはもちろんのこと、テラデータやSnowflakeなどのデータベースでも開発が可能。オンプレミスでも運用できるため、将来的にサーバーリプレースやデータベース変更などが必要になった際にも柔軟に対応させることができるだろう。

　「OutSystemsとODIPを併用することで、ビジネスアーキテクチャー主導の開発へシフトさせることができます。業務の内容や現場ニーズの変化に素早く対応しつつ、システムの再現性を確保した開発を実現できるでしょう」と工藤氏は語る。

　ビジネスを取り巻く環境はめまぐるしく変化している。BlueMemeが提案するOutSystemsとODIPを組み合わせた開発手法は、この状況に対応するための有力なソリューションになりそうだ。