JP2024056296A - ビジネスルール設定装置、ビジネスルール設定方法、及びビジネスルール設定プログラム - Google Patents

Abstract

【課題】画面項目に対して状態制御を行うための設定を開発者が簡易に行うことが可能なビジネスルール設定装置を提供すること。【解決手段】本実施の形態のビジネスルール設定装置は、選択した状態制御のタイプについて、コントロール情報のコントロールを一方の軸、コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御手段と、前記ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を前記テーブルに登録する設定手段と、を備えている。【選択図】図１

Description

本発明は、ビジネスルール設定装置、ビジネスルール設定方法、及びビジネスルール設定プログラムに関する。

例えば、特許文献１では、アプリケーションの開発を高速かつ保守性高く実現することを目的としたアプリケーション開発装置が開示されている。かかるアプリケーション開発装置は、表示部に、状態制御するための関数の内容を設定するためのＧＵＩを表示するＧＵＩ表示制御手段と、前記ＧＵＩでのユーザ操作に応じて、前記状態制御する関数の条件部分と処理部分を設定する関数設定手段と、前記関数設定手段の設定に応じたオブジェクトを作成して前記記憶部に保存するオブジェクト保存手段と、を備えている。

特開２０２１－２０８８号公報

しかしながら、従来においては、画面項目に対してロック、表示等の状態制御を行うための設定を開発者が簡易に行う方法については何ら記載されていない。

本発明は、上記に鑑みてなされたものであり、画面項目に対して状態制御を行うための設定を開発者が簡易に行うことが可能なビジネスルール設定装置、ビジネスルール設定方法、及びビジネスルール設定プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、制御部及び記憶部を備えるビジネスルール設定装置であって、前記記憶部には、コントロール名、プロパティを含むコントロール情報と、動的制御の判定に使用されるものであり、コンディション名、条件式を含むコンディション情報と、設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うかを規定したルールであり、状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報と、を含むテーブルが格納されており、選択した状態制御のタイプについて、前記コントロール情報のコントロールを一方の軸、前記コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御手段と、前記ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を前記テーブルに登録する設定手段と、を備えたことを特徴とする。

また、本発明の一態様によれば、前記状態制御のタイプは、ロック、非表示、又は必須を含むことにしてもよい。

また、本発明の一態様によれば、前記画面制御手段は、フィルタ情報に設定されたコントロールとコンディションに前記ビジネスルール開発画面への表示を制限するフィルタ機能を備えることにしてもよい。

また、本発明の一態様によれば、前記画面制御手段は、前記ビジネスルール開発画面において、一方の軸のコントロールが選択された場合に当該選択されたコントロールのレイアウト画面で設定されている画面情報を表示し、他方の軸のコンディションが選択された場合には、当該コンディションのコンディション設定画面を表示することにしてもよい。

また、本発明の一態様によれば、前記テーブルが公開されることで実行可能となるアプリケーションでは、ロジックフローを全て実行後に各ビジネスルールの判定を行うことにしてもよい。

また、上述した課題を解決し、目的を達成するために、本発明は、制御部及び記憶部を備える情報処理装置が実行するビジネスルール設定方法であって、前記記憶部には、コントロール名、プロパティを含むコントロール情報と、動的制御の判定に使用されるものであり、コンディション名、条件式を含むコンディション情報と、設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うかを規定したルールであり、状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報と、を含むテーブルが格納されており、前記制御部において実行される、選択した状態制御のタイプについて、前記コントロール情報のコントロールを一方の軸、前記コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御工程と、前記ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を前記テーブルに登録する設定工程と、を含むことを特徴とする。

また、上述した課題を解決し、目的を達成するために、本発明は、制御部及び記憶部を備える情報処理装置が実行するためのビジネスルール設定プログラムであって、前記記憶部には、コントロール名、プロパティを含むコントロール情報と、動的制御の判定に使用されるものであり、コンディション名、条件式を含むコンディション情報と、設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うかを規定したルールであり、状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報と、を含むテーブルが格納されており、前記制御部において、選択した状態制御のタイプについて、前記コントロール情報のコントロールを一方の軸、前記コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御工程と、前記ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を前記テーブルに登録する設定工程と、を実行するためのビジネスルール設定プログラムであることを特徴とする。

本発明によれば、画面項目に対して状態制御を行うための設定を開発者が簡易に行うことが可能となるという効果を奏する。

図１は、本実施の形態に係るビジネスルール設定装置の構成の一例を示すブロック図である。 図２は、前提事項を示す図である。 図３は、前提事項を示す図である。 図４は、前提事項を示す図である。 図５は、前提事項を示す図である。 図６は、前提事項を示す図である。 図７は、前提事項を示す図である。 図８は、前提事項を示す図である。 図９は、前提事項を示す図である。 図１０は、前提事項を示す図である。 図１１は、前提事項を示す図である。 図１２は、前提事項を示す図である。 図１３は、前提事項を示す図である。 図１４は、前提事項を示す図である。 図１５は、前提事項を示す図である。 図１６は、前提事項を示す図である。 図１７は、前提事項を示す図である。 図１８は、実行時の画面イメージを示す図である。 図１９は、定義管理テーブル例を示す図である。 図２０は、登録ボタンに割り付いたロジックフローを示す図である。 図２１は、ＡＰＩ管理テーブル例を示す図である。 図２２は、レイアウト開発画面例を示す図である。 図２３は、コンディション開発画面例を示す図である。 図２４は、定義管理テーブルのコンディション情報の例を示す図である。 図２５は、複雑な条件指定を行うコンディション開発画面例及び設定されるコンディション情報の例を示す図である。 図２６は、開発用アプリケーションＤＢの定義管理テーブルのコントロール情報とコンディション情報の例を示す図である。 図２７は、動的更新の対象となるコントロールを説明するための図である。 図２８は、ビジネスルール開発画面例を示す図である。 図２９は、コンディション設定画面への遷移を示す図である。 図３０は、レイアウト画面への遷移を示す図である。 図３１は、定義管理テーブルのビジネスルール情報の例を示す図である。 図３２は、フィルタ機能を追加したビジネスルール開発画面の例を示す図である。 図３３は、定義管理テーブルのフィルタ情報の例を示す図である。 図３４は、フィルタ情報のフィルタ機能を説明するための図である。 図３５は、レイアウト画面例を示す図である。 図３６は、コンディション（税抜金額の場合）の設定イメージを示す図である。 図３７は、ビジネスルールの設定イメージを示す図である。 図３８は、定義管理テーブルのビジネスルール情報の例を示す図である。 図３９は、ビジネスルールを反映するまでのフローチャートを示す図である。 図４０は、図３９のフローチャートの特徴を説明するための図である。 図４１は、ビジネスルールという仕組みを用意せず、ロジックフロー、アクションのような仕組みだけで動的更新を実現しようとした場合を説明するための図である。 図４２は、ビジネスルールという仕組みを用意せず、ロジックフロー、アクションのような仕組みだけで動的更新を実現しようとした場合を説明するための図である。

以下に、本発明に係るビジネスルール設定装置、ビジネスルール設定方法、及びビジネスルール設定プログラムの実施形態を、図面に基づいて詳細に説明する。なお、本実施形態により本発明が限定されるものではない。

［１．概要］
（１）課題
従来、項目状態の制御をプログラミングにより行っており、開発者による高度な設定作業が必要であった。制御が複雑化した場合、開発者にも相応の技術力が必要となり、不具合を防ぐために設定やテストにかかるコストが増加する、という課題があった。また、一度設定した仕組みを変更する場合には、相応の時間とコストが必要となることから、業務環境の変化に伴いシステムを柔軟に変更していくことが難しいという課題が存在した。その結果、顧客のニーズに素早く対応できないことで、ユーザの満足度が低下してしまうというリスクが存在していた。

そこで、本実施の形態では、画面項目に対して状態制御を行うための設定を開発者が簡易に行うことが可能なシステムを提供する。

具体的には、本システムは、画面項目に対してロック、表示などの状態制御を行うための設定を、ローコード開発基盤上で実現するための仕組みである。本仕組みによって、複雑化しがちな画面項目の制御をプログラミングなしで簡易的に行うことができる。

業務アプリケーションにおける項目の状態制御は、安定的に業務を進める上で非常に重要な部分であり、その設定を簡素化することができる本仕組みは、設定やテストにかかる工数を低下させ、システムの早期稼働に貢献することができる。また、設定が簡素化したことで、システムの不具合を最小限に抑えることができ、ユーザの満足度を高める効果も期待できる。

（２）背景
業務アプリケーションに必要な項目の動的制御について説明する。一般的な業務アプリケーションでは、業務オペレータによる操作に応じて、画面項目に対して動的に制御（ロック、非表示など）をかけることが一般的である。一例として、０と１という２種類の値を受け付ける項目Ａに対して、値に１が入力されている場合のみ、項目Ｂの情報が必要になる、といった要件を考える。この要件を満たすには、画面項目に動的な制御（例：項目Ａの値が０であれば項目Ｂをロック、値が１であれば項目Ｂをアンロックする）を行う必要がある。

このように、業務上の決まり事（項目Ａの値が１の場合に、項目Ｂの情報を入力する）を業務アプリケーション画面上での具体的な動作として設定に落とし込んだものを、「ビジネスルール」と称する。ビジネスルールの設定が行われない場合、オペレータが業務上必要な情報を入力しない、もしくは不必要な情報を入力してしまうことに繋がり、業務に支障をきたす危険性がある。

従来の開発では、開発者の手作業によるプログラミングを行うことで、項目の動的な制御を実現することが一般的であった。設定が複雑な制御を行う場合には、プログラミングの難易度が上がり、システムの完成までにかかる工数も増加する。また、急な項目の変更などがあった場合に、再設定が難しくなるという問題があった。

（３）解決手段
ローコード開発ツールによって作成された業務アプリケーションでは、様々な処理をアクション処理によって実現している。しかし、項目の動的制御をアクション内の処理で実現しようとすると、設定や考慮すべき制御上の問題が増え、開発コストが増加する。

そこで、本実施の形態では、アクション設定とビジネスルールに係る設定とを明確に分離することで、開発時の設定負荷を下げつつ、意図しない不具合を防ぐことを可能にした。また、ビジネスルールの設定画面にも工夫を設けることで、開発者がビジネスルールの設定を容易に行うことを可能にした。

その結果、システム設定にかかる工数が低下し、ユーザに質の高いアプリケーションを短期間で提供することが可能になった。また、ビジネスの状況によって業務上の決まり事が変化することも考えられるが、本仕組みを使用して都度ビジネスルール設定を最適化していくことで、状況に最適化されたシステムを短期間でユーザに提供することができる。

［２．構成］
本実施形態に係るビジネスルール設定装置１００の構成の一例について、図１を参照して説明する。図１は、ビジネスルール設定装置１００の構成の一例を示すブロック図である。ビジネスルール設定装置１００は、開発者が使用するアプリケーション開発用の装置である。ビジネスルール設定装置１００は、後述する［３．前提事項］、［４．画面項目の動的な更新の設定方法（コンディション及びビジネスルールの設定）］で説明する機能を搭載しており、これらで説明する処理を実行可能に構成されている。

ビジネスルール設定装置１００は、ワークステーション、デスクトップ型パーソナルコンピュータのような据置型情報処理装置、市販されているノート型パーソナルコンピュータなどの情報処理装置であってもよい。

ビジネスルール設定装置１００は、制御部１０２と通信インターフェース部１０４と記憶部１０６と入出力インターフェース部１０８と、を備えている。ビジネスルール設定装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

通信インターフェース部１０４は、ルータ等の通信装置および専用線等の有線または無線の通信回線を介して、ビジネスルール設定装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、ビジネスルール設定装置１００と不図示の開発者端末、サーバ２００等の他の装置とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。なお、後述するテーブル等のデータは、例えばサーバ２００に格納されてもよい。

入出力インターフェース部１０８には、入力装置１１２および出力装置１１４が接続されている。出力装置１１４には、モニタ（家庭用テレビを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置１１４をモニタ１１４とし、入力装置１１２をキーボード１１２またはマウス１１２として記載する場合がある。

記憶部１０６には、各種のデータベース、テーブルおよびファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、および光ディスク等を用いることができる。

記憶部１０６は、定義管理テーブル等を格納する開発用アプリケーションＤＢ１０６ａを備えている。定義管理テーブルは、例えば、定義識別データ（定義ＩＤおよび定義名）と、コントロール情報と、アクション情報と、ロジックフロー情報と、紐付け情報と、コンディション情報と、ビジネスルール情報と、フィルタ情報と、を含んでいてもよい（図１９、図２４、図３１、図３３等参照）。

コントロール情報は、コントロール名、プロパティ等を含んでいてもよい。

コンディション情報は、動的制御の判定に使用されるものであり、コンディション名、条件式等を含んでいてもよい。

ビジネスルール情報は、設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うかを規定したルールであり、状態制御のタイプ（例えば、コントロールのロック、非表示、必須等）、コンディション、反映先のコントロール等を含むことにしてもよい。

フィルタ情報は、ビジネスルール開発画面へのコントロールとコンディションの表示を制限するためのものであり、フィルタ名、コントール要素、コンディション要素を含むことにしてもよい。

制御部１０２は、ビジネスルール設定装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。

制御部１０２は、機能概念的に、画面制御部１０２ａと、設定部１０２ｂと、を備えている。

画面制御部１０２ａは、開発者端末の開発者からのリクエストに応じて、定義管理テーブルの各種情報を設定するための各種設定画面（開発画面）を提供する。

例えば、画面制御部１０２ａは、選択した状態制御のタイプについて、コントロール情報のコントロールを一方の軸、コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる（図２６～３１等参照）。

画面制御部１０２ａは、フィルタ情報に設定されたコントロールとコンディションにビジネスルール開発画面への表示を制限するフィルタ機能を備えることにしてもよい（図３２～図３４等参照）。

画面制御部１０２ａは、ビジネスルール開発画面において、一方の軸のコントロールが選択された場合に当該選択されたコントロールのレイアウト画面で設定されている画面情報を提供し、他方の軸のコンディションが選択された場合には、当該コンディションのコンディション設定画面を表示させることにしてもよい（図２９～図３１等参照）。

設定部１０２ｂは、各種設定画面上での開発者端末の開発者の操作に応じて、定義管理テーブルに各種情報を設定する。

例えば、設定部１０２ｂは、ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を定義管理テーブルに登録する（図２６～図３４等参照）。

状態制御のタイプは、コントロールのロック、非表示、又は必須を含むことにしてもよい。

定義管理テーブルが公開されることで実行可能となるアプリケーションでは、ロジックフローを全て実行後に各ビジネスルールの判定を行うことにしてもよい（図３９及び図４０参照）。

［３．前提事項］
本項目では、本実施形態における処理を説明するための前提事項について説明する。

［３－１．ローコード開発ツールの概要］
（１）ローコード開発とは
ローコード開発とは、システム構築における開発手法の一つである。本明細書で指すシステムとは、企業が業務に利用するための一般的なＥＲＰシステム等を指すものとし、以下、「業務アプリケーション」という。

従来の開発においては、開発者自らがプログラミングよりソースコードを記述し、ＵＩから処理に必要な業務ロジックに至るまで、業務アプリケーション全体の構築を行っていた。一方で、ローコード開発では、一般的にローコード開発ツールを用いて開発を行う。ローコード開発ツールは、設定に基づき、主に業務アプリケーションのＵＩ部分を生成する機能を持つ。

つまり、開発者は、自身がプログラミングを行わなくても、ローコード開発ツールを設定することで業務アプリケーションのＵＩ部分を構築することが可能となる。結果として、開発者自身の作業量を削減し、効率的にシステム開発を行うことができるというメリットがある。

（２）ローコード開発ツールとは
図２は、ローコード開発ツールの全体図を示す図である。以下の説明では、開発者側および顧客となる企業の業務オペレータ側という２種類の利用者を想定している。開発者がローコード開発ツールを用いた業務アプリケーションのＵＩ設定および業務ロジックの作成を行う段階（開発段階）と、業務オペレータが実際にアプリケーションとして利用する段階（利用段階）と、の２つの段階に分けて説明を行う。

開発段階とは、開発者がローコード開発基盤を用いて、業務アプリケーションの設定情報をデータベースに登録する段階である。利用段階とは、ローコード実行基盤が、開発段階で登録された設定情報を解析し、実際の業務アプリケーションへ変換することで、業務オペレータが業務を実行する段階である。本明細書では、ローコード開発基盤およびローコード実行基盤を合わせて、「ローコード開発ツール」と総称する。

ここで、各段階で生成されるデータ管理方法について説明する。統制上の観点から、開発者が開発時にアプリケーション設定を管理するデータベースと、業務オペレータが業務利用時に参照するアプリケーション設定を管理するデータベースとは、明確に分ける必要がある。これは、開発者が、業務用データベースを直接操作することがないようにするためである。以下の説明では、開発者が利用するアプリケーション設定管理用のデータベースを「開発用アプリケーションＤＢ」といい、業務オペレータが利用するアプリケーション設定管理用のデータベースを「業務用アプリケーションＤＢ」という。業務用アプリケーションＤＢとは別に、業務用必要なデータ（マスタデータや仕訳データ等）を管理するデータベースを「業務用ＤＢ」という。アプリケーションからは業務用ＡＰＩを介して業務用ＤＢの情報の取得・更新を行う。

（２－１）開発段階
開発段階は、図２の上半分に示すように、開発者がローコード開発ツール（ローコード開発基盤側）を用いて業務アプリケーションの開発を行う段階である。ローコード開発では、主にアプリケーション画面のレイアウトと、レイアウトを操作した時に行われる一連のイベント処理（アクション、ロジックフロー）の開発の設定を行う。最終的にレイアウトとロジックフローを紐づけることで、業務アプリケーションのＵＩ部分を生成できる。開発段階での主な設定内容は、以下の（Ａ）～（Ｃ）のとおりである。

（Ａ）レイアウト開発
業務アプリケーションの画面レイアウト部分の設定を行う。

（Ｂ）ロジックフロー開発およびアクション開発
業務アプリケーションの処理部分の設定を行う。ローコード開発ツールでは、業務アプリケーションにおける処理を、アクションという単位で設定できる（先述のＵＩ部分と業務ロジックの紐づけも、このアクションを通して行われる）。更に、アクション同士をフローでつなぐことで、一連アクションを処理する順序を設定できる。このアクションの処理順序の設定を「ロジックフロー」という。

業務ロジックを呼びだすための特殊なアクション設定について説明する。ローコード開発において、開発者が個別のプログラミング作業等によって作成するのは業務ロジック部分のみであり、ＵＩ部分はローコード開発ツールの操作によって生成される。このため、ＵＩ側から業務ロジックを呼び出すために、開発者は作成した業務ロジックをＡＰＩ化してＡＰＩマスタに登録しておく必要がある。ＡＰＩマスタに登録したＡＰＩを、ＡＰＩ呼出アクションから呼び出すことで、業務ロジックを実行することができる。

（Ｃ）レイアウトとロジックフローの結合
（Ａ）で設定したレイアウトに対して、（Ｂ）のロジックフローを割り付ける設定を行う。

（２－２）利用段階
利用段階は、図２の下半分に示すように、ローコード開発ツール（ローコード実行基盤側）が登録されている業務アプリケーション設定を解析し、業務アプリケーションへの変換を行うことで、業務オペレータが業務アプリケーションを操作する段階である。

利用段階の画面イメージを説明する。図３は、利用段階の画面イメージを示す図である。一例として、取引先マスタメンテの一覧画面を設定する場合の仕組みについて説明する。画面名は、取引先マスタメンテ（一覧画面）となっている。業務オペレータが登録されている取引先情報を確認するためのジョブである。抽出条件（基準日、取引先ＣＤ（Ｆｒｏｍ、Ｔｏ））を入力した状態で表示ボタンを押すと確認メッセージダイアログが表示される。ダイアログでＹｅｓを選択時は、基準日時点で存在している、かつ、取引先ＣＤが抽出条件を満たす取引先が取引先マスタから読み出されて画面上に表示される。つまり、業務用アプリケーションＤＢから取引先を取得するＡＰＩを呼び出し、取得した情報を画面上にセットする。ダイアログでＮｏを選択時は、何も処理が実行されない。

（２－３）開発時の設定について
上記のようなアプリケーションを実現するために、開発者がローコード開発基盤を用いてアプリケーション設定を行う。このアプリケーション設定を「ＵＩ定義」という。このＵＩ定義は、開発用アプリケーションＤＢの定義管理テーブルに登録される。図４は、定義テーブル例を示す図である。定義管理テーブルでは、アプリケーション内のコントロール情報、アクション情報、ロジックフロー情報、レイアウトとロジックの紐づけ情報などを管理している。定義管理テーブル内の用語の意味は、以下のとおりである。

・定義ＩＤ・・・ＵＩ定義作成時に、自動で採番されるＧｕｉｄ文字列。
・定義名・・・ＵＩ定義作成時に、開発者が命名。
・コントロール情報・・・以下の「（１）レイアウト開発」を参照。
・アクション情報・・・以下の「（２）ロジックフローおよびアクション開発」を参照。
・ロジックフロー情報・・・以下の「（２）ロジックフローおよびアクション開発」を参照。
・紐づけ情報・・・以下の「（３）レイアウトとロジックの結合」を参照。

（１）レイアウト開発
図５はレイアウト開発を説明するための図である。開発段階では、開発者がレイアウト開発画面を操作することで、開発用アプリケーションＤＢにコントロール情報を登録するつまり、上述した定義管理テーブルのコントロール情報の列にデータが格納される。例えば、図５の画面例では、基準日を入力するテキストボックスを日付テキストから選択して配置している。配置したコントロールをクリックすると、クリックしたコントロールの種類に応じたプロパティの設定を行うことができる。例えば、日付テキストは、その入力がアプリケーション上必須のものかどうかを示す必須プロパティが用意されている。図５の画面例では必須プロパティがＯＮになっているので、基準日テキストはアプリケーション上、入力必須のコントロールとなる。

利用段階では、開発用アプリケーションＤＢから業務用アプリケーションＤＢへ、定義管理テーブル情報を公開することで、アプリケーションとして実行可能となる。上記例では、基準日が必須となるので、業務オペレータが基準日を入力せずに処理を進めようとした場合に、エラーが表示される。

（２）ロジックフローおよびアクション開発
（２－１）アクション設定について
開発段階では、開発者がロジックフローおよびアクション開発画面を操作することで、開発用アプリケーションＤＢにロジックフロー情報およびアクション情報を登録する（上述した定義管理テーブルのアクション情報及びコントロール情報の列にデータが格納される）。ローコード開発ツールにおけるロジックフロー設定は、処理が開始するための開始アクションと処理が終了するための終了アクションの間でフローがつながっている状態が初期状態となる。この２つのアクションの間に、必要なアクションを図６に示すように組み込むことで、設定を行う。

アクションをクリックして編集することで、各アクションに詳細な設定を行うことができる。アクションごとに、設定できる内容は異なる。例えば、メッセージ表示アクションでは、メッセージの種類や、メッセージの内容を設定できる。図７に示すメッセージアクション設定例では、Ｙｅｓ、Ｎｏ型のメッセージボックスに、「取引先を表示します、よろしいですか？」というメッセージを表示する設定を行っている。

アクション設定で、Ｙｅｓ、Ｎｏ型のメッセージボックスが選択された場合は、ロジックフロー上処理を、Ｙｅｓ選択時、Ｎｏ選択時で分岐させることができるようになる。図８に示す例では、メッセージ（取引先を表示します、よろしいですか？）に対して、Ｙｅｓが選択された場合は、ＡＰＩ呼出アクションで取引先を取得するような処理を行い、これに対して、Ｎｏが選択された場合は、処理が終了する。

（２－２）業務ロジックを紐づけるための特殊なアクション設定について
図９に示す例では、メッセージでＹｅｓを選択後、ＡＰＩ呼出アクションが実行される。先述のように、ローコード開発ツールでは、業務アプリケーションのＵＩ部分のみ生成することができ、業務データの取得および更新といった業務ロジックについては、開発者がプログラミング作業によって開発する必要がある。つまり、業務ロジック自体は、ローコード開発ツールから独立した外部のロジックとなる。ＡＰＩ呼出アクションとは、ローコード開発ツールで作成したＵＩ情報と、開発者が作成した業務ロジックと、をそれぞれ紐づけて実行することができる特殊なアクションのことである。準備として、開発者は、ローコード開発ツールで生成したＵＩ側から呼び出したい業務ロジックをＡＰＩ化し（図１０参照）、ＡＰＩマスタに登録しておく（図１１参照）。

業務ロジックのＡＰＩ化について説明する。図１０に示すように、業務アプリケーション実行時に読み込まれるモジュールに、あらかじめＡＰＩを作成しておく。つまり、実行したい業務ロジックの実処理、後からＡＰＩ呼出時に必要となるキー情報などを管理しておく。図１０の例では、引数に基準日（日付）を指定した場合に、その日付時点で登録されている取引先情報（取引先ＣＤおよび取引先名等）の一覧を返すようなＡＰＩを登録している。

ＡＰＩマスタに登録への登録について説明する。作成したＡＰＩ情報を、図１１に示すように、ＡＰＩ管理テーブルに登録する。

その後、ＡＰＩ呼出アクションの編集画面では、図１２に示すように、開発者があらかじめ登録したＡＰＩを格納したＡＰＩマスタの中から、必要なＡＰＩを選択し、そのＡＰＩの引数や戻り値の設定を行う。

アクション情報について説明する。定義管理テーブルのアクション情報には、図１３に示すように、アクションごとに設定された情報（ＩＤ、名前、アクションタイプおよび各設定等）がセットされる。メッセージ表示アクションの例では、メッセージ種類が３（Ｙｅｓ、Ｎｏ）、メッセージ内容が「取引先を表示します、よろしいですか？」という情報が登録される。ＡＰＩ呼出アクションの例では、ＡＰＩに渡す引数（基準日）の値に、画面上の基準日テキストの値をセットし、結果返ってきた戻り値（取引先ＣＤおよび取引先名等）の値を、画面上の取引先ＣＤテキストセル、取引先名テキストセルにセットしている情報が登録される。

ロジックフロー情報について説明する。定義管理テーブルのロジックフロー情報には、図１４に示すように、ロジックフローごとに設定された情報（ＩＤ、名前およびアクション同士を繋ぐフロー群等）がセットされる。前アクションＩＤは、先に処理されるアクションのＩＤであり、後アクションＩＤは、前アクションが実行された後に実行されるアクションのＩＤである。コールバックキーは、アクション実行時にユーザが何か行ためを選択した場合に、その選択結果を判別するためのキーである。図１４の例では、ユーザがメッセージボックスでＹｅｓを選択した場合はコールバックキーがＹｅｓのフローを特定し、後アクションＩＤにセットされたアクションが実行される。

（３）レイアウトとロジックの結合
開発段階では、開発者がレイアウト開発画面で各コントロールにロジックフローの割り付けを行うことで、開発用アプリケーションＤＢに紐づけ情報を登録する（図１５参照）。すなわち、上述した定義管理テーブルの紐付け情報の列にデータが格納される。「（１）レイアウト開発」と「（２）ロジックフローおよびアクション開発」でそれぞれ作成したコントロールとフローの割り付けを行う。図１５に示すように、コントロールのプロパティに、イベント項目（ボタンコントロールの場合には、クリックイベント）があり、ここに先ほど登録したフローがプルダウン形式で一覧が表示される。

紐づけ情報について説明する。定義管理テーブルのロジックフロー情報には、図１６に示すように、コントロール（表示ボタン）のＩＤ、イベントタイプおよびロジックフロー（ロジックフロー１）のＩＤという３つの情報が紐づけて登録される。一つのコントロールに対して、複数のイベントに割り付けられるようなコントロールでは、コントロールのＩＤだけでは紐づけが特定できないため、イベントタイプを紐づけ情報に含める必要がある（テキストボックスの検証時処理および脱出時処理等）。

以上の設定を行い、業務用アプリケーションＤＢへ定義管理テーブル情報を公開することで、アプリケーションとして実行が可能となる（後述する「実行時の画面イメージ」を参照）。ローコード実行基盤上で、公開された定義管理テーブル情報を解析し、アプリケーションとして実行する。特に、ロジックフローの実行時は、図１７に示すようなフローチャート処理がローコード実行基盤内で行われる。図１７は、クライアントによるアプリケーション操作～該当アクションの終了アクション完了までのフローチャートである。

［４．画面項目の動的な更新の設定方法（コンディション及びビジネスルールの設定）］
図１８～図４２を参照して、本実施の形態の特徴的な部分である画面項目の動的な更新の設定方法（コンディション及びビジネスルールの設定）を説明する。

本明細書の画面項目の動的な更新の設定方法には、開発段階、実行段階でそれぞれについて特徴がある。

実行段階では、アクション、ロジックフローの処理と、ビジネスルールの処理とを明確に分けることで、それぞれの処理が競合して不正な動作が起きることを防いだ。

開発段階では、アクション、ロジックフローの設定と、コンディション、ビジネスルールの設定とを明確に分けることで、ローコード開発基盤における設定の複雑化を防いだ。また、開発者が直感的にビジネスルール設定できる画面構成にすることで、設定時の不具合を最小限に抑えることを可能とした。

以下、それぞれの特徴について説明を行う。

（１）実行時の画面イメージ
図１８は、実行時の画面イメージを示す図である。例として取引先マスタメンテ画面を設定する場合の仕組みについて説明する。画面名は、取引先マスタメンテ（編集画面）である。ここでは、取引先マスタメンテ画面の編集画面をメインに説明する。業務オペレータが取引先情報を登録するためのジョブについて説明する。取引先ＣＤ、取引先名、改定日、法人区分、法人番号の５項目のみが存在するものとする。取引先マスタメンテ（一覧画面）から取引先マスタメンテ（編集画面）に遷移する。

取引先には法人と個人の２種類が存在し、法人（法人区分＝０）の場合には法人番号の入力が必要で、個人（法人区分＝１）の場合には法人番号の入力は不要となる。このようなアプリケーションを設定するにあたり、法人区分の値に応じて、法人番号のロック状態を動的に切り替えることで、必要な情報が漏れなく登録されるようにしたい。

図１８に示すように、業務オペレータが、法人区分の値を１（個人）に変更すると、法人番号（テキスト）がロックされる。他方、法人区分の値を０（法人）に変更すると、法人番号（テキスト）がアンロックされる。

（２）前提となる定義管理テーブルの情報（コントロール情報、アクション情報、ロジックフロー情報、紐づけ情報）
図１９は、定義管理テーブル例を示す図である。定義管理テーブルには、取引先マスタ（編集画面）の情報として、図１９に示すような情報が登録されているものとする。アクション情報、ロジックフロー情報、紐づけ情報は、簡略化のため登録に関わる部分のみ表示している。

図２０は、登録ボタンに割り付いたロジックフローを示す図である。図２０において、登録ボタンには、ＡＰＩ呼出アクション１が割り付いている。図２１は、ＡＰＩ管理テーブル例を示す図である。ＡＰＩ呼出アクション１では、取引先データ登録処理（ＡＰＩ）が実行される想定である。取引先ＣＤ、取引先名、改定日、法人区分、法人番号の５つの情報を引数に受け取り、引数を元に取引先情報の更新を行う（戻り値は返さないものとする）。

（３）新たに必要な定義管理テーブルの情報（コンディション情報、ビジネスルール情報）
コンディション開発画面、ビジネスルール開発画面は、レイアウト開発画面から遷移することができる。図２２は、レイアウト開発画面例を示す図である。図２２のレイアウト開発画面において、コンディションボタンをクリックすると、コンディション開発画面へ遷移する。また、ビジネスルールボタンをクリックすると、ビジネスルール開発画面へ遷移する。前述のように、取引先マスタメンテには法人番号の動的な制御が必要である。以下、法人番号の動的制御を実現するために、開発者がローコード開発基盤を用いて行う設定について説明する。

法人番号の制御の判定には、法人区分の値が利用される。そのため、まずは法人区分の値を動的制御の判定に必要な条件式（以下、「コンディション」と呼称）として登録する必要がある。

（３－１）コンディション設定について
図２３は、コンディション開発画面例を示す図である。コンディション設定は、画面上の要素を左辺と右辺に値として設定し、比較のための等号（ｏｒ不等号）を組み合わせることで、一つの式として構成される。式に設定する値の例としては数値や文字列のような定数情報の他に、画面上のコントロールの値を設定することができる（どのような値を設定するかは、式ごとにタイプを指定できる）。式の左辺と右辺を比較し、比較結果が真（ｔｒｕｅ）であれば、後述するビジネスルールに基づいて画面情報が更新される。

図２３において、タイプ＝コントロールを指定した場合には、画面上のコントロールを一覧から選択でき、プロパティ（値やエラーの有無など）を式にセットできる。タイプ＝定数を指定した場合には、任意の値（文字列、数値、真偽値）を指定できる。上記の設定例では、法人区分の値に１をセットした場合に、真となる。図２４は、登録される定義管理テーブルのコンディション情報の例を示す図である。図２４では、図２３で設定したコンディション情報が設定されている。

また、一つのコンディション内には式やコンディションを複数含めることができ、それぞれの条件をＡＮＤ、ＯＲで結びつけることで、より複雑な条件指定を行うことが可能となる。図２５は、複雑な条件指定を行うコンディション開発画面例及び設定されるコンディション情報の例を示す図である。図２５の画面例では、式、コンディションを追加するためのボタンが用意されている。図２５の例では、コンディション「テキストボックス１＝１ かつ テキストボックス２＝２ かつ （テキストボックス３＝３ または テキストボックス４＝４）を満たす場合に、このコンディションは真となる。」が設定される。

（３－２）ビジネスルール設定について
ビジネスルールとは、設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うか、ルールを定めたものである。動的な更新の種類として、「ロック」、「非表示」、「必須」の３種類を選択でき、コンディションが真である場合に、設定されたコントロールがロック、非表示、必須状態になる。

ビジネスルール開発画面上では、縦軸にコントロール一覧、横軸にコンディション一覧をとるマトリクス表が表示され、セル上にチェックをつけることができる。開発者がビジネスルールのタイプ（コンディションを満たした際の処理）を指定し、マトリクス表にチェックをつけることで、設定が完了する。

このようにローコード開発基盤では、複雑になりがちな動的な画面更新を、プログラミングなしで容易に設定できるため、設定の負荷や意図しないバグの発生を最小限に抑えることができる。主な特徴は以下の点が挙げられる。

特徴１：値によって判定可能な動的な画面更新を、コンディション、ビジネスルールの設定だけで完結させることができる（ロジックフローの設定で制御を実現しようとすると、設定が煩雑、かつ判定後に値を書き換えられてしまうとアクションの処理順によっては不具合を生む場合がある）。

特徴２：コンディションとビジネスルールの分離により、複雑になりがちな設定をシンプルにすることができる（条件と状態を定義内の別項目としてＤＢ上管理している）。

特徴３：ビジネスルールをマトリクス形式で設定できる（複雑なビジネスルール設定を一つの画面で行うことができる）。

特徴４：マトリクス形式での設定に加えて、設定に必要な情報を確認しやすくすることで、大規模アプリケーションの開発においても、設定コストを最小限に抑えることができる。
１．コンディション（横軸）をクリックすることで、該当のコンディション設定画面に遷移することができる。
２．コントロール（縦軸）をクリックすることで、表示されているレイアウト画面がハイライト表示される。
３．レイアウト画面上のコントロールをクリックすることで、マトリクスの行が選択状態（フォーカス状態）となる。

特徴５：大規模システムにおいては、設定項目の数が多くなりがちなため、フィルタを用いてマトリクス表上に表示するコントロール、およびコンディションの種類を制限することで、開発者の設定ミスを防ぐ。

大規模なアプリケーション画面では、コンディション、コントロールの数が膨大になり、設定作業の負荷がかかるという課題があるが、この特徴を生かして、コンディションやレイアウトを確認しやすくすることで、その負荷を下げることができる。

（Ａ）設定例（ビジネスルール：ロックの場合）
ビジネスルール開発画面では、開発用アプリケーションＤＢのコントロール情報とコンディション情報から、動的更新の対象となるコントロールを抽出し、それぞれ縦軸、横軸に一覧表示する。

図２６は、開発用アプリケーションＤＢの定義管理テーブルのコントロール情報とコンディション情報の例を示す図である。図２７は、動的更新の対象となるコントロールを説明するための図である。図２７において、ローコード開発基盤上では、それぞれのコントロール要素が各ビジネスルールタイプの更新対象かどうかを判定するために、図中の属性テーブルで属性を保持している。属性テーブルは、コントロール要素（テキスト、ラベル、ボタン、ラジオボタン等）が各ビジネスルールタイプ（ロック、非表示、必須）の更新対象か否か（可：更新対象、不可：非更新対象）を規定している。属性テーブルは、記憶部に登録されており、ビジネスルール開発画面を表示する際に参照して、ビジネスルールのタイプ毎に、コントロール情報から設定可能なコントロールを抽出している。この属性テーブルの例では、ビジネスルールタイプがロックの場合、ラベルは対象コントロールの一覧に表示されない。ビジネスルールタイプが非表示の場合、ラベルは対象コントロールの一覧に表示される。

図２８は、ビジネスルール開発画面例を示している。（Ａ）は、ビジネスルールタイプが「ロック」の場合、（Ｂ）は、ビジネスルールタイプが「非表示」の場合の例を示している。

図２８に示すように、ビジネスルール開発画面は、縦軸にコントロール一覧、横軸にコンディション一覧がマトリクス形式の表で表示される。画面例では、簡略化のためテキスト、ラベルのみ表示している。（Ａ）に示すように、ビジネスルールタイプがロックの場合、上記属性よりラベルは対象コントロールの一覧に表示されない。（Ｂ）に示すように、ビジネスルールタイプが非表示の場合、上記属性よりラベルは対象コントロールの一覧に表示される。開発者がビジネスルールのタイプ（コンディションを満たした際の処理）を指定し、マトリクス表にチェックをつけることで、選択したコントロール及びコンディションの組についてのビジネスルール情報を定義管理テーブルに設定することができる。（Ａ）に示す例では、コントロール「法人番号」とコンディション「コンディション１」の組のセルがチェックされている。

図２９に示すように、横軸のコンディションをクリックすると、コンディション開発画面に遷移する。

図３０に示すように、縦軸のコントロールをクリックすると、レイアウト開発画面で設定されている画面情報が表示され、選択されたコントロールの行がハイライト表示される。

図３１は、定義管理テーブルに設定されるビジネスルール情報の例を示す図である。ビジネスルール情報は、ビジネスルール名、タイプ、コンディション、反映先を含んでいる。タイプは、選択されたビジネスルールのタイプで更新される。コンディションと反映先は、チェックＯＮのコンディションとコントローロールの項目の組合せが１つのビジネスルールとして更新される。

同図に示す例では、ビジネスルール名「ビジネスルール１」、タイプ「ロック」、コンディション「コンディション１」、反映先「法人番号（テキスト）」となっている。

（Ｂ）マトリクス画面におけるフィルタ機能について
システムが大規模化するにつれて、画面上のコントロール数や、必要なコンディション数は増加する。その結果、マトリクス表も肥大化するため、開発者による設定の付け忘れや付け間違いなどの設定ミスが発生する可能性が高まる。そこで、本仕組みでは、マトリクス表にフィルタ機能を設けることで、開発者による設定ミスを最小限に防ぐような仕組みを用意した。

図３２は、フィルタ機能を追加したビジネスルール開発画面の例を示す図である。図３２において、ビジネスルール開発画面は、設定中のフィルタを選択する欄と、フィルタを追加ボタンと、備えている。フィルタを追加ボタンをクリックすると、フィルタ追加画面に遷移する。フィルタ追加画面で、開発者がフィルタの名前を設定し、フィルタ対象のコントロールとコンディションをチェックして選択し、登録ボタンをクリックすることで、フィルタ情報が定義管理テーブルに設定される。図３２に示す例では、フィルタ名「取引先用フィルタ」が設定され、コントロール「取引先」、「取引先名」、コンディション「コンディション１」が選択されている。この画面上のコントロール、コンディションの一覧も、開発用アプリケーションＤＢのコントロール情報及びコンディション情報から取得する。

図３３は、定義管理テーブルに設定されるフィルタ情報の例を示す図である。フィルタ情報は、フィルタ名、コントロール要素、コンディション要素で構成されている。図３３に示す例では、フィルタ名「取引先用フィルタ」、コントロール要素「１．取引先」、「２．取引先名」、コンディション要素「１．コンディション１」が設定される。

図３４は、フィルタ情報のフィルタ機能を説明するための図である。登録したフィルタ情報は定義管理テーブル（定義情報）に登録され、ビジネスルール開発画面で、フィルタを選択すると、対象にチェックをつけたコンディションとコントロールが絞り込んで表示される。

図３４の上は、ビジネスルール開発画面の表示例、左下は、フィルタ＝未設定の場合の対象コントロール情報及びコンディション情報の例、右下は、フィルタ＝取引先の場合の対象コントロール情報及びコンディション情報の例を示している。ビジネスルール開発画面上で、開発者が設定時に利用したいフィルタを選択すると、選択したフィルタの条件を満たすコントロール及びコンディションを定義管理テーブルから抽出して、ビジネスルール開発画面に表示し、コントロール、コンディションが絞り込まれて表示される。

図３４に示す例では、取引先用フィルタが選択されて、取引先用フィルタの条件を満たすコントロール「取引先」、「取引先名」、コンディション「コンディション１」が表示されている。

（Ｃ）マトリクス画面の利点について
取引先マスタメンテの例では、一つの条件（法人区分）に対して、一つのコントロール（法人番号）に制御をかけていたが、より複雑なパターンとして、複数のコンディションを利用して、複数コントロールに対して動的なロック制御を行う場合を考える。図３５は、画面例、図３６は、コンディション（税抜金額の場合）の設定イメージ、図３７は、ビジネスルールの設定イメージを示す図である。

図３５の画面例では、税区分、税抜金額、消費税額、税込金額の４つの項目を入力する。この時、税区分の値に応じて、税抜金額、消費税額、税込金額の３つのコントロールをそれぞれ異なる条件でロック制御を行う。

税区分＝０（非課税）の場合、消費税額テキストボックス、税込金額テキストボックスをロックする（非課税・・・税抜金額のみオペレータが入力する方式）。
税区分＝１（外税）の場合、税込金額テキストボックスをロックする（外税・・・税抜金額と消費税額をオペレータが入力する方式）。
税区分＝２（内税）の場合、税抜金額テキストボックスをロックする（内税・・・税込金額と消費税額をオペレータが入力する方式）。

税抜金額、税込金額、消費税額に対して、それぞれロックする条件が異なるため、それぞれコンディションを用意する。
税抜金額は税区分＝２でロック
税込金額は税区分＝０ｏｒ１でロック
消費税額は税区分＝０でロック

上記例のように、複数の画面項目に対して、それぞれ異なる条件で動的更新をかけたい場合に、本仕組みのようなマトリクス形式での設定であれば、１つの画面でコントロールと条件、更新の種類（上記例ではロック）の紐づけを行うことができるため、設定内容の保守性・可読性が高く、開発者にとっての利便性が大きい。

図３８は、上記例により定義管理テーブルに登録されるビジネスルール情報の例を示す図である。

（４）ビジネスルールを反映するまでのフローチャート
以上の設定を行い、業務用アプリケーションＤＢへ定義管理テーブルの情報を公開することで、アプリケーションとして実行が可能となる（「実行時の画面イメージ」を参照）。ローコード実行基盤上で、公開された定義管理テーブル情報を解析し、アプリケーションとして実行する。特に、ビジネスルールを反映する時は、図３９に示すようなフローチャート処理がローコード実行基盤内で行われる。図３９は、ビジネスルールを反映するまでのフローチャートを示す図である。

図３９において、オペレータの画面操作によってイベントが発火すると（ステップＳ１）、ロジックフローが割りついているかを判定し（ステップ２）、ロジックフローが割りついている場合（ステップＳ２の「Ｙｅｓ」）には、ロジックフローの処理を実行して（ステップＳ３）、ステップＳ３に移行し、ロジックフローが割りついていない場合（ステップＳ２の「Ｎｏ」）には、ステップＳ４に移行する。

ステップＳ４では、ロジックフローを実行完了後、判定すべきビジネスルールを抽出する。つぎに、各ビジネスルールについて判定を行う（ステップＳ５）。各ビジネスルールが終了するまでステップＳ５～Ｓ１７の処理をループする（ループ処理）。ループ対象のビジネスルールに割ついたコンディションを抽出し（ステップＳ６）、ビジネスルールのタイプによって分岐する（ステップＳ７）。

タイプが「ロック」の場合は、コンディションを満たすか判定して（ステップＳ８）、コンディションを満たす場合には（ステップＳ８の「Ｙｅｓ」）、反映先のコントロールをロックして（ステップＳ１１）、ステップＳ１７に移行する一方、コンディションを満たさない場合には（ステップＳ８の「Ｎｏ」）、反映先のコントロールをアンロックして（ステップＳ１２）、ステップＳ１７に移行する。

タイプが「非表示」の場合は、コンディションを満たすか判定して（ステップＳ９）、コンディションを満たす場合には（ステップＳ９の「Ｙｅｓ」）、反映先のコントロールを非表示状態にして（ステップＳ１３）、ステップＳ１７に移行する一方、コンディションを満たさない場合には（ステップＳ９の「Ｎｏ」）、反映先のコントロールを表示状態して（ステップＳ１４）、ステップＳ１７に移行する。

タイプが「必須」の場合は、コンディションを満たすか判定して（ステップＳ１０）、コンディションを満たす場合には（ステップＳ１０の「Ｙｅｓ」）、反映先のコントロールを必須状態にして（ステップＳ１５）、ステップＳ１７に移行する一方、コンディションを満たさない場合には（ステップＳ１０の「Ｎｏ」）、反映先のコントロールの必須状態を解除して（ステップＳ１６）、ステップＳ１７に移行する。

ステップＳ１７では、未判定のビジネスルールが存在するか否かを判定し、未判定のビジネスルールが存在する場合には（ステップＳ１７の「Ｙｅｓ」）、ステップＳ５に戻り、未判定のビジネスルールが存在しなくなるまで、ステップＳ４～ステップＳ１６の処理をループし、未判定のビジネスルールが存在しない場合には（ステップＳ１７の「Ｎｏ」）、処理を終了する。

図４０は、図３９のフローチャートの特徴を説明するための図である。画面上の値が変更されるケースには、クライアント側での変更と、サーバ側での変更の以下の２パターンが存在する。（１）クライアント側の変更は、業務オペレータが直接値を変更した場合である。（２）サーバ側の変更は、画面更新アクション（アクションの一つ、画面上の値を更新することができる）が実行された場合である。

図４０（Ａ）に示すように、ステップＳ１において、（１）業務オペレータが直接値を変更した場合は、イベント発火前に値が確定する。ステップＳ３において、（２）画面更新アクションで値を変更した場合は、ロジックフロー処理内で値が確定する。

図４０（Ｂ）は、画面更新アクションを呼び出すロジックフロー例を示している。例えば、画面上の値を更新するアクションで、法人区分を「１」に更新する。

図４０（Ｃ）は、取引先マスタメンテ（編集画面）の例を示している。ロジックフローを実行すると、画面更新アクションによって、画面上の値が更新され、ロジックフローの判定にも影響を与える。

画面更新アクションを呼び出すロジックフロー例のように、画面上の値を更新するようなアクションが含まれている場合、ロジックフロー内のどのタイミングで画面更新が行われるか分からないため、終了アクションが完了するまで画面上の値を確定させることができない。

そのため、必ずロジックフローが完了した後に、ビジネスルールの判定を行っており、この２種類の処理を分離している点が大きな特徴といえる。

（５）動的更新を、アクション処理で実現しようとした場合の管理の煩雑さについて
図４１及び図４２を参照して、ビジネスルールという仕組みを用意せず、ロジックフロー、アクションのような仕組みだけで動的更新を実現しようとする場合について説明する。一般的なローコード開発ではこのケースが多いと思われる。図４１において、ロック、表示非表示といった状態制御を行うアクションを用意し、ロジックフロー内で実行する場合、複数のロジックフローに状態制御のためのアクションが分散することとなる。その結果、開発者にとって一覧性のある開発・保守が難しくなる。複数あるロジックフローの中から、状態制御に係る部分を把握し、適切に管理していくことは難しい。

また、図４２において、前述した画面更新アクションのように、サーバ側で画面の値を書き換えが行われる場合、書き換えた値によっては状態制御の結果が変化する可能性があるため、サーバ側で値が変化するタイミングを把握し適切なタイミングで状態制御を行わなければ、誤った設定を行ってしまうリスクが存在する。

このように、ロジックフロー、アクションだけで処理を完結させようとすると、開発者にとって考慮すべき事項が増え、設定の難しい仕組みとなってしまう。

以上説明したように、本実施の形態によれば、選択した状態制御のタイプについて、コントロール情報のコントロールを一方の軸、コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御部１０２ａと、ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を定義管理テーブルに登録する設定部１０２ｂと、を備えているので、画面項目に対して状態制御を行うための設定を開発者が簡易に行うことが可能となる。

［５．国連が主導する持続可能な開発目標（ＳＤＧｓ）への貢献］
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、ＳＤＧｓの目標８及び９に貢献することが可能となる。

また、本実施形態により、廃棄ロス削減や、ペーパレス・電子化を推進することに寄与することができるので、ＳＤＧｓの目標１２、１３及び１５に貢献することが可能となる。

また、本実施形態により、統制、ガバナンス強化に寄与することができるので、ＳＤＧｓの目標１６に貢献することが可能となる。

［６．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

また、ビジネスルール設定装置１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

例えば、ビジネスルール設定装置１００が備える処理機能、特に制御部にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じてビジネスルール設定装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

また、このコンピュータプログラムは、ビジネスルール設定装置１００に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

記憶部に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、および、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、および、ウェブページ用ファイル等を格納する。

また、ビジネスルール設定装置１００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、ビジネスルール設定装置１００は、当該装置に本実施形態で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。

更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

本発明は、全業種・全業界において利用可能である。

１００ ビジネスルール設定装置
１０２ 制御部
１０２ａ 画面制御部
１０２ｂ 設定部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 開発用アプリケーションＤＢ
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク

Claims (7)

1. 制御部及び記憶部を備えるビジネスルール設定装置であって、
   前記記憶部には、
   コントロール名、プロパティを含むコントロール情報と、
   動的制御の判定に使用されるものであり、コンディション名、条件式を含むコンディション情報と、
   設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うかを規定したルールであり、状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報と、
   を含むテーブルが格納されており、
   選択した状態制御のタイプについて、前記コントロール情報のコントロールを一方の軸、前記コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御手段と、
   前記ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を前記テーブルに登録する設定手段と、
   を備えたことを特徴とするビジネスルール設定装置。
2. 前記状態制御のタイプは、ロック、非表示、又は必須を含むことを特徴とする請求項１に記載のビジネスルール設定装置。
3. 前記画面制御手段は、フィルタ情報に設定されたコントロールとコンディションに前記ビジネスルール開発画面への表示を制限するフィルタ機能を備えたことを特徴とする請求項１に記載のビジネスルール設定装置。
4. 前記画面制御手段は、前記ビジネスルール開発画面において、一方の軸のコントロールが選択された場合に当該選択されたコントロールのレイアウト画面で設定されている画面情報を表示し、他方の軸のコンディションが選択された場合には、当該コンディションのコンディション設定画面を表示することを特徴とする請求項１に記載のビジネスルール設定装置。
5. 前記テーブルが公開されることで実行可能となるアプリケーションでは、ロジックフローを全て実行後に各ビジネスルールの判定を行うことを特徴とする請求項１～４のいずれか１つに記載のビジネスルール設定装置。
6. 制御部及び記憶部を備える情報処理装置が実行するビジネスルール設定方法であって、
   前記記憶部には、
   コントロール名、プロパティを含むコントロール情報と、
   動的制御の判定に使用されるものであり、コンディション名、条件式を含むコンディション情報と、
   設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うかを規定したルールであり、状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報と、
   を含むテーブルが格納されており、
   前記制御部において実行される、
   選択した状態制御のタイプについて、前記コントロール情報のコントロールを一方の軸、前記コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御工程と、
   前記ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を前記テーブルに登録する設定工程と、
   を含むことを特徴とするビジネスルール設定方法。
7. 制御部及び記憶部を備える情報処理装置が実行するためのビジネスルール設定プログラムであって、
   前記記憶部には、
   コントロール名、プロパティを含むコントロール情報と、
   動的制御の判定に使用されるものであり、コンディション名、条件式を含むコンディション情報と、
   設定されたコンディションが真である場合に、設定されたコントロールに対してどのような更新を動的に行うかを規定したルールであり、状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報と、
   を含むテーブルが格納されており、
   前記制御部において、
   選択した状態制御のタイプについて、前記コントロール情報のコントロールを一方の軸、前記コンディション情報のコンディションを他方の軸としたマトリクス形式のビジネスルール開発画面を表示させる画面制御工程と、
   前記ビジネスルール開発画面において、マトリクスのセルを選択することでコントロールとコンディションの組を選択し、選択した状態制御のタイプ、コンディション、コントロールを含むビジネスルール情報を前記テーブルに登録する設定工程と、
   を実行するためのビジネスルール設定プログラム。

Images