（MDMとデータガバナンス研究会リーダー・水谷 哲）
2021年11月26日に開催されたMDMとデータガバナンス研究会では、株式会社アトリス (https://www.atrris.com/)が提供する、基幹システムの要件定義から設計、実装、運用までをトータルに支援するプラットフォーム「PEXA」に関する講演が行われた。PEXAとはどんなプラットフォームなのか。そもそも基幹システムとは何なのか。アトリスの安光正則氏と寺町康昌氏が発表。また解説が詳細にわたったこと、さまざまな方向へとディスカッションが膨らんだことから研究会は3時間48分と、4時間に迫る長さとなった。どんな研究会となったのか。その概要を紹介する。
■基幹システムとは「バック」処理である
まずアトリス 安光氏が「フロント制御、バック業務、PEXA比較」というタイトルでPEXAの概要について発表した。その内容は以下の通り。
PEXAは基幹業務をターゲットとしたローコードオペレーションの開発プラットフォーム。業務にはフロントとバックがあります。業務を文章として捉えるならば、フロントの主語は人や機械。目的語はモノやサービス、回転する、押す/引く、温度を計測するなどが動詞となります。バック処理の主語は役割（ロール）であり、目的語は伝票、そして動詞は伝票に対するCRUD（Create、Read、Update、Deleteの略）となります。
バック処理が基幹システムであり、本質は伝票のCRUDということです。一見、バック処理は簡単に見えますが、実務においては複雑化し、ぐちゃぐちゃになっている事が大半です。
PEXAでは基幹業務を正確に定義するため、CRUDをより詳細化した独自の定義を持っています。Active（作成）、Passive (受領)、Reference、Controlの4つを設け、さらにPassiveはproduce（導出する）、accept（承認する）、Send（送信する）、receive（受信する）、edit（編集する）の5つ、Referenceはsearch（参照する）、portfolio（組み合わせ参照する）の2つ、Controlはactive（マスター登録する）、reference（マスタ参照する）の2つに分けて定義しています。
基幹系のローコード/ノーコード開発ツールは、大きく3種類あります。CRMなど計画系、取引などのトランザクション系、データ集計系です。CRMや計画系の代表はSalesforce、データ集計の代表がマイクロソフトのPower BIやTableauです。
PEXAはトランザクション系の基幹業務を担当します。契約開始から契約終了までの取引データを管理することがスコープです。受注、生産、配送など販売系、および発注、検品、入出庫などの発注系をカバーします。システム構築でデータ集計が必要な場合は無料のPower BIを使っています。
基幹業務のデータベースの持ち方は大きく2つに大別できます。ERPのように全社1つのデータベースで統合したのものと、複数個の部門データベースを人間系で統合するものです。ERP導入企業も含めて、多くの企業では複数個のデータベースを無理矢理統合して使っています。
PEXAは部門データベースを1つにして基幹システムを構築できます。たとえば岸和田製鋼（大阪府岸和田市）の基幹システムは2000画面、データは2万項目ありました。この業務にPEXAを使い、512GBメモリと4TBのSSDで動かしています。
■基幹システムに特化した「PEXA」の特徴
安光氏によるPEXAの概要説明に続いて、寺町氏が「PEXA：基幹業務システムの開発手法」を解説した。寺町氏は東京工業大学や職能力開発大学校などで教授を務めた一方で、安光氏たちと共にPEXAの概念モデルなど設計などを行ってきた。最近は法令工学に基づく法令作成・検証の基盤をPythonで構築するための活動をしているという。寺町氏の発表の概要は以下の通り。
PEXAとは「基幹業務システムに特化したDSL（Domain-Specific Language）」です。ロール、画面、伝票（事務書類）、処理（場面の展開）を、因果関係を保持しつつ記述します。SOX法にも適合しています。
PEXAはデータ中心主義です。業務フローやBPMN (ビジネスプロセスモデリング表記法）といった処理中心主義では、計算機の中最も重要な「情報の流れ」を定義できないからです。
データは一般的な「モデル」という単一のデータ構造で記述します。伝票というテーブル構造だけでなく、事務処理までを包含したのがモデルです。モデル考案にあたって参考としたのはマーチン・ファウラー氏のアナリシスパターンとデザインパターンでした。処理にはインメモリデータベース使用し、永続性のためにRDBMSを併用しています。処理の主体はモデルであり、データベースはリポジトリとしての使用なので、データベースとしての正規化は意識していません。物理項目名は、グローバルでユニークとなるよう命名し、モデルと業務項目とは独立させています。
また業務分析とシステム設計とは一体であり、粒度で線引をするという方法論を持っています。分析ではモデル単位まで、設計では項目まで詳細化します。分析のポイントは、「管理された曖昧性」を制御することです。
PEXAはJavaやCなどのコードジェネレーションをしません。PEXAエンジン上で設計成果物を実行する仕組です。
画面の自動生成は、UMLベースの画面設計ツールを用いています。
システム構築においては、最初に業務分析し、シナリオチャートに記述します。ロールの組合せが、これから構築するシステムの骨子です。シナリオチャートにロールを付与すると、組織とサービスの関係が定義できます。あるロールがモデルに従って伝票を作り、次に承認を受け、承認を基に別の伝票が作られ・・・という処理の流れや、処理が実際の画面としてどう見えるかなどを記述していきます。
こうしてデータ設計と画面設計プロセス設計を進めます。それぞれの自由度が小さいため、構築において大幅に行数を減らすことができます。プロセス設計はプロシジャー（項目値）、スキーマ、ルールという3つで定義します。サービススキーマ（処理）とアサインスキーマ（更新）を定義することで、あとはパラメータ設定によってルールとして動くよう構造にすることが可能です。
PEXAには「残数管理」のFrameworkであるAETが用意されています。銀行のシステムは基本的にAccount管理ですので、AETを用いて構築できます。お金や大量生産品のように個性の無い対象を扱う場合はAETが基本になります。伝票処理について新規・更新の基本処理に残数管理を加えることによりことで業務が成り立ちます。
大阪のある5万人ぐらいの市の基幹業務システムでは、シナリオチャートは約1000枚、シナリオ・ドメイン表が30枚ぐらいになりましたが、業務設計はシンプルに実施することができました
■PEXAについて質疑応答
ここまでの説明で、質疑応答が行われた。
水谷：データを正規化しないのであれば、RDBMSでなくダンプやスナップショットでも良いのでは?
寺町：伝票データであることを一義として、リレーショナルな結合や分割を特に意識しないという意味です。
安光：データ設計の基準がリレーショナルデータベースではないということです。不揮発性のデータ保存容器としてRDBを使っているだけです。主体は独自開発のインメモリデータベースであり、取消しや訂正などのログをすべて取っており、不正などが起きない構造にはなっています。今後、不揮発性のDRAMが出てくるとRDBが不要になるでしょう。
山岸：ローコード開発ツール「WebPerformer」という製品を扱っており、基幹業務系で数社に採用してもらっています。大規模なシステムだと苦手なことが多い。パフォーマンスが出にくいと言う問題がつきまといます。パフォーマンスはどう維持されているのでしょう。
安光 コンピュータメーカー (Sun Microsystems 以下サン)にいたので、ハードウェアをチューニングしてスピードが出るようにしています。メモリDBなので、キャッシュを入れて動かし、ハードのコア数も32コア、64スレッドを2ツ入れると、128論理コアになります。同時ユーザーが多数になってもレスポンスが落ちないようになっています。HDDからSSDに換えると10倍早くなりました。最近はパフォーマンスを気にしなくて済みます。ただ、AzureやAWSなどのクラウドは品質が今ひとつなので、基幹システムには向かないと思います。
水谷 PEXAエンジンがローレベルでチューニングされているので、パフォーマンスが出るという認識で良いでしょうか。
安光 サンのJ2EEにPEXAを乗せており、J2EEがインタープリタのように動いています。
水谷 Javaを作った人たちの強みが生かされているということですか。
安光 マーチン・ファウラーの「アナリシスパターン」を参考に、銀行システムで得た経験を加え、管理会計と財務会計の統合、連結決算、マルチカレンシー、会計基準が変わっても動くような会計用のコンポーネントや部品を作っており、一部は特許申請をしている。
水谷 コンポーネントの作成は会計系だけですか。
安光 会計業務を残数管理として汎用化しました。例えばいくつかの取引から消費税だけを集計するのが残数管理です。勘定科目は残数の入れ物です。これが簿記の概念であり、簿記とは工学そのものです。それを残数管理として実装しました。
水谷 寺町先生は法令工学にも取り組まれているというお話でした。
寺町 JAIST(北陸先端科学技術大学院大学)の元学長の片山先生が提案されている取り組みです。私は東工大時代に片山先生と縁があったことで、アトリスにも来ていただき、法令工学の定義証明系を用いて法律的な内部矛盾がないか確かめることをしました。地方自治体などのシステムは法律をベースに作らないといけませんからね。片山先生は法律をPythonで記述して、検証を行うという方法を提案されています。片山先生は「法律は社会の仕様書。利用しないのはもったいない」と。
アトリスの人事給与のシステム製品は、法令工学をベースに作成したパッケージです。年金機構のシステムも法令工学に基づいてまとめるべく、片山先生をアトリスの顧問に招聘し法令工学の活動も進めています。この分野に興味を持たれる方も増やしていきたいですね。
安光 定理証明系はロジックが正しいかどうかを見るようなソフトがあるのですが、実際にはゲーム会社の人が使ったりしています。ロールプレイングゲームはシナリオが膨大なので、ロジック自体に間違いが無いかは人力では判定できません。定理証明系で矛盾の検査をしています。矛盾検査ロジックは難易度が高いのですが、PEXAで作ったルールへの定理証明系適用プロジェクトも始めています。興味があれば、ぜひ。
伊阪 データと情報の違いは?
寺町 データと情報は用語として特に区別していない。PEXAはシステム構築観点であり、データ抜きの情報は持たない。
伊阪 企業ごと、時には部門によっても情報とデータの定義が異なりトラブルの原因となる。さまざまな聞き手の混ざった研究会ではまず最初に定義を説明してもらえると、わかりやすかったと思います。
伊阪 マルチカレンシーや通貨やタイムゾーンの調整は柔軟に対応できるのでしょうか。
安光 定義によって柔軟に対応します。
■PEXAではどのようにシステム設計していくのか
PEXAの解説を寺町氏が行った。
PEXAではすべての事務書類や伝票を「モデル」という形式で扱う。伝票は詳細な業務項目の列でできています。「発注書」というモデルは年月日や会社名、住所などの業務項目の列で構成されます。項目は業務で使う個々のデータです。データはモデル単位で永続的データとして扱います。
企画・分析の段階では業務を業務の言葉で定義し、設計以降は技術用語で定義し曖昧性をなくします。分析はさらに業務分析と機能分析に分け、業務分析は業務単位で、機能分析では伝票単位で考えます。動きは厳密に定義し、条件設定などは自然言語の曖昧性を残します。曖昧性が残っていることを明らかにすることが重要です。
このような分析結果をPEXAではさらにチェックします。PEXA基幹業務システムのレイヤー構造は以下の図の通りです。
PEXAではモデルの数だけモデルシートを作成します。「ビジネスカタログシート」はptype（業務項目一覧表）、proxy（モデルなどのキー：主キー、外部キー）、Phenomenon（区分値定義一覧）という3つの表を持っており、インメモリーで実装されます。
PEXAでのモデルについて改めて説明します。モデルは「ヘッダー – 明細」
構造を持ち、明細は業務項目でできており、PEXAの基本となる伝票のデータ構造です。トランザクションもマスターデータもモデルです。また伝票とは、業務で利用される書類すべてを指します。
インメモリーで使うのはオブジェクトデータベースです。オブジェクトのうちデータ部分をRDBでリポジトリ管理します。
設計におけるモデルの構造は次のようになります。これは交通費申請書のモデルの構造。この伝票に必要な業務項目を明らかにしてゆくのがモデル設計です。その際設計者としてはその伝票（モデル）の動き（振る舞い）をするかを決定する項目に注意を払う必要があります。
このモデルの内容では無く、ふるまいに注目してパターン化したものが概念モデルと呼んでいます。病院のオーダリングシステムの伝票の振る舞いの例です。非常に多くの伝票が、医師の指示で即実行されるパターンと希少資源を利用するため、Scheduleが必要なパターンに分類できます。このことに気付けばモデル設計は類型化できます。
表示のための画面はシナリオチャートを記述することによって、構築できます。設計だけで、画面のためのプログラムのコーディングは不要です。シナリオチャートでは、業務とは何かを考えて、役割Role（利用者の権限）の、伝票に対する振る舞いのパターンを定義し、業務の流れに沿って記述していきます。申請書を元に仕訳書を作成するなどの流れです。Createなど、順方向に8つ、UpdateやRemoveなど逆方向の流れも記述できます。
シナリオチャートとシナリオ・ドメイン表を作成すると実際に動かすことのできるプロトタイプができます。
更にモデルの項目の詳細と、シナリオチャートを画面設計図として詳細化すると、詳細設計書は自動生成されます。シナリオとドメインの関係、ドメインとロールの関係をシナリオチャートで表現します。ドメインとは業務のことです。目的があって完了して終わるものです。ロールにおいては一つの伝票を作成、変更し、伝票を引き渡して終了します。
大規模なシステムの場合はアサインスキーマを使って、伝票の処理を記述します。必要な伝票を自動的に作成したり、変更したりすることができます。最初にモデル設計をし、画面設計をしつつ、各モデル間の関係になるのかを記述していきます。トリガーとなるソースモデルを元にアサインスキーマで展開、反映、更新といった機能を実現してアサインモデルを作成します。アサインスキーマの構造は次の図の通りです。
■PEXAの効用と優位性
PEXAの効用は
| 1.見える化 | 工学的に定義された業務分析により、業務を定義して可視化 |
| 2.開発の高速性・安定性 |
コードを書かないのでバグが発生しない。開発工期短縮で、レビュー、テストに割く時間を増やせる |
| 3.拡張性 | 業務の拡大、機能追加に優れている。レビュー、テスト時のフィードバックの反映が容易 |
| 4.オープンテクノロジー | PostgreSQL、Javaなど、オープンな技術を多用し、最新のIT標準技術環境に容易に追随可能 |
| 5.豊富な外部連携 | Web APIによる各種Webサービスとの連携が可能。ETL、EDIや各種制御機器との連携が可能。外部向けサーバ設置により、取引先もサポート可能 |
| 6.設計ドキュメント | 開発と設計が同時に作成され、内容が乖離しない。変更時の影響範囲の把握が可能。 |
パッケージに対するPEXAの優位性は、個別の業務への高い適合性および拡張性。スクラッチ開発に対する優位性は、高速性・安定性、視認性およびドキュメント品質。DSLを採用しているので、語彙や文法もの正確性を担保できる。業務の工学的な分析がDSLのベースである。要求分析がそのまま実行可能で、内部無矛盾性が保証されている。
PEXA以外のツールは、語彙制限も文法も明確ではなく、データと処理の粒度の規則もなかったりする。実行可能性や内部無矛盾性に不安がある。
今後の改善事項は画面。見栄え、大量データ入力で使いづらいなどの改善に向けて動いています。
■1時間以上続いた質疑応答タイム
PEXAの解説は終了。この時点で8時半となっていたが、質疑応答が始まった。
伊阪 会社の内部事情は常に変わりますが、そこに柔軟に対応できるのでしょうか。
安光 新たなカラム追加などは、定義によってルールベースエンジンが自動生成します。 変更はすべて追跡できるようになっています。
伊阪 PEXAの項目名が日本語ですが、インタープリタを動かす処理のレベルでは英語なのですね。
安光 その方が情報関係に人にとっては、戸惑いが少ないのではと考えている。
伊阪 久しぶりに「リエントラント」という言葉を聞きました。豊富にメモリもCPUもあるのに、なぜそういう言葉が出てくるのでしょうか。
寺町 開発者がそう名付けだけで、従来のリエントラントの定義とは違います。
伊阪 アトリスではBPMN（ビジネスプロセス モデル＆ノーテーション）のようなノーテーション方法を持っているのでしょうか。BPMNをPEXAに取り込むことはできるのでしょうか。
安光 PEXAからBPMNを自動生成きるような変換ツールは作りました。逆はありません。
伊阪 古くて破綻したBPMNを簡単に移植できるとPEXAの評判が上がるかも知れません。今、破綻しているBPMNが日本には山ほどあると思うので。
水谷 ローコード開発コミュニティの状況について教えてください。
安光 Wagby、WebPerformer、楽々Frameworkは日本製のローコード開発ツールはたくさんあり、それらのベンダーがローコード開発コミュニティ参加してくれています。一番やりたいのは適用範囲の明確化。PEXAは伝票処理と基幹業務だと言っています。ローコードで何でもできるという人もいるので、その辺の調整が難しいところです。
実は「伝票」という言葉もピンとくるのは年配者だけになりつつあります。電子化され、伝票を知らない人が増えたことでモデルの説明に困ることが増えました。
林 伝票で分からなくても「レシート」や「クレジットカードの明細書」が使えます。与信限度額の概念も教えられます。アルバイトでもしていない限り学生に伝票の理解は無理ですね。
安光 若い人たちにもうまい説明があれば良いと思っています。
真野 伝票を分析して、マスター構造とかデータ構造はこうなっているというモデルを書くとおっしゃいましたが、このツールの場合、項目は項目単位で定義して、マスターはマスターで別途定義するのでしょうか。データ分析をどこでやるのか、ちょっとわかりませんでした。
寺町 シナリオチャートを書くことで、どういう動きをするかも含めて、設計していきます。
真野 エクセルシート上でそれらを分析していくと言うことですね。ER図みたいなもので表した方がわかりやすいと思いますが、いかがでしょう。
安光 シナリオチャートでデータモデルと業務項目のクロスリファレンスや、どのデータモデルにアサインメントというルールが紐付いているかが見えるようになっています。それを見れば、分かると思います。
真野 伝票をどう料理していくのかがよく見えないと思うのですか。
安光 集計帳票や財務諸表は伝票ではありません。PEXAではあくまで、基幹業務で情報を移りつつあるモノを伝票という概念で使っています。
水谷 SAPの世界では伝票と明細がまだ現役です。ERPが伝票文化の担い手になるかもしれません。
寺町 ちなみにPEXAではいろんな成果物をWeb上にデータベース化し、モデルカタログとして公開しています。
真野 このようなモデル設計をしていくことも不要だと思っていました。
安光 モデル設計は必要です。以前はER図で表現していましたが、テーブルの数が30を超えると一人の人では対応が難しくなり、2人以上でやると相互の矛盾を引き起こしてしまいます。それが一人でできるのは超優秀な人だけ。そういう人はなかなかいないので、簡単にわかりやすくできるようにしています。
水谷 PEXAはまずお作法を学ばないと難しそうですね。
安光 簡単なモノはER図で表すことができます。大規模なモノは受注から出荷まで1000画面、1万カラムを超えます。ER図ベースでは作れません。PEXAは基幹業務に特化したデータベースを作っているので、このような大規模なものにも対応できます。
水谷 モデルのある一側面がテーブル構造であり、人はテーブルではなくモデルを作っていくということですね。モデルからテーブルにマッピングできる要素があり、振る舞いやロールという要素もある。項目やキーの要素のみをPostgreSQLに入れていくということですね。
安光 RDBでは合計やjoinが計算できます。PEXAでは「外から取ってくる」とだけ定義します。Joinを直接SQLでやると複雑になりますが、PEXAはビルダーがSQLを作成するので人はjoinを気にする必要はありません。PEXAはモデルとルールが密接につながってフレームワークを構成しています。元々は銀行で実証実験をやりました。
水谷 銀行を相手にするとお金や利息の型が個々に決まっており、それらを作らないと進みませんよね。それは1つ一つ作ったのでしょうか。
安光 Javaの型と有効桁数の定義です。1本は1億で、100本だと100億という大きな単位も、10万円などトラベラーズチェックのように単位が小さいモノもあり、どちらもそれを同じように扱いたいという要求には苦労しました。浮動小数点などは使わせてくれません。集計すると誤差も集積されすごい金額になるからです。
水谷 複利計算など桁数の大きい数字をJavaの標準の型だけでは処理が困難と思い、質問しました。
安光 ローコードツールと言っても昔からあるものなんですよね。
水谷 CASEや4GLもなどですね。
真野 WebPerformerも歴史があります。
安光 ローコードやノーコードツールは目的をはっきりさせ、何が適しているかを見極めることが大事だと思います。私たちは、あくまでも基幹業務のため。そのためにフレームワークやモデル設計のエンジンも新しいものに切り替えを行っています。5年前までの画面はSwingというJavaのGUIツールを使っていましたが、今はHTML5に切り替えています。HTML5であれば、マイクロサービスが画面から使えるようになるからです。バックとフロントを分けるところなど、より細かいことについては、会社まで来ていただければ説明いたします。
基幹業務ではデータモデルとルールが密接に絡んでいます。技術者の場合、モデル設計と言われると、データベース設計をイメージするので、ルールが抜けてしまうのです。そこを一体としてどうなるかという議論をしてから取り組むことが大事だと考えています。
水谷 どの業務領域に使うかを明確にした上で話し合うということですか。
安光 契約がたくさん出てくると、ルール分析や整備の難易度が上がります。分析や整備に関しては、アカデミックな人たちとタッグを組んで取り組むのが安全です。大学と一緒にやることが多い。法令工学も同様です。基幹業務システムの刷新で、質が良いのは官庁と金融系。医療はかなり慎重に取り組まないと大変な目に合うと思います。
水谷 私がMDMの世界に入ったのは、超高速開発でもマスターがダメだとうまくいかないからです。業務がモデルに整理できれば自動生成だが、データがモデル通りになるところはTibco EBXなどMDMにマスター専用のルールエンジンやワークフローが有効でした。。
安光 今、マスター以外にも人事給与をやっているが、リプレースのときはデータを移す必要が生じます。それにTibco EBXは使えるのでしょうか。
水谷 使えます。MDMのモデルもリレーショナルなだけのものではなく、ルールを含めたモデルを作ります。業務の構造をからシステムのデータ構造にマッピングすることで、AシステムとBシステム、Cシステム相互のデータ翻訳することができます。
安光 トランザクションデータも残しておかないといけないのでしょうか。
水谷 不要です。マスターが翻訳できればトランザクションの翻訳はほぼ可能だからです。
早川 富士通でデータマネジメントのコンサルティングを行っている早川です。私は元々、人事部門にいて人事システムの大規模移行を2回経験しています。その経験から移行が大変だというのは理解しています。移動する履歴を持ちたいというときは、部署コードが記録として残っており、履歴を持ったマスターがあればできますが、ない場合は逆生成でマスターをつくるしかありません。履歴の使い道は、人別に見たい時だけ。ある一定期間だけより前のモノは文字列として残しておき、最新のものと紐付けて別のデータベースとして管理するという方法もあると思います。
水谷 なるほど。ありがとうございます。社員13万人(過去は18万人)の富士通の専門家からのご意見でした。
安光 人事給与は人数が万の単位になるとワケがわからなくなりますからね。グローバル企業になるとさらに大変。基幹業務は大規模になるとトラブルが生じます。覚悟を決めて取り組むことが必要です。
水谷 AS400上に作り込んだ基幹システムをどうすべきかで悩んでいる企業がいま多いです。ちゃんと動いているから新たに投資する価値を見いだせない。しかしインフラのリスクがある。それで困っています。
安光 RPG (AS400のプログラミング言語)ができる人がいなくなって、システムが動かなくなったら会社が潰れます。私たちのところにもAS400のリプレース案件がたくさん寄せられています。AS400はOSも優れており、RPGという言語はワンティアで、メインフレームとまったく異なります。登録系は素人でも簡単なので、エクセルを組み合わせると高度なことができるんですよ。
水谷 それが解析して他のところで動かすのが難しくて難儀をする話をよく聞きます。まさに25年の崖はこのことを言っているのではないかと私は考えています。
安光 そうでしょうね。
水谷 一つ宣伝を。Power BI使っているとおっしゃいました。複雑、多様、困難なデータ参照要件がある場合は、TIBCOのSpotfireも候補として見当いただけると嬉しいです。
安光 我々のシステムは情報系をターゲットにしていません。したがってPower BIもリアルタイム性が高くて、意思決定する場面で使っているわけではないので。ですが、そういう用途を求められた場合は、候補に入れさせていただきます。
鳴海 以前、用賀のオフィス（サン）で働いていました。1年ぐらいしか働いていませんでしたが、今でもその当時の同期と仕事する機会があります。
安光 アトリスの社員は全員サンの直販部隊であるSE部の出身です。ぜひ、興味があればオフィスにも遊びに来てください。
オンラインでの開催だったが、安光氏、寺町氏はオフィスから参加。話は盛り上がったまま、終電間近ということで、終了した。非常に密度の濃い研究会となった。