特開 2022-132048 アプリ開発支援システム、アプリ開発支援方法、及びアプリ開発支援プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022132048

(43)【公開日】2022-09-07

(54)【発明の名称】アプリ開発支援システム、アプリ開発支援方法、及びアプリ開発支援プログラム

(51)【国際特許分類】

   G06F 8/34 20180101AFI20220831BHJP

   G06F 21/62 20130101ALI20220831BHJP

【ＦＩ】

G06F8/34

G06F21/62

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2021171883

(22)【出願日】2021-10-20

(31)【優先権主張番号】P 2021031164

(32)【優先日】2021-02-26

(33)【優先権主張国・地域又は機関】JP

(71)【出願人】

【識別番号】398040527

【氏名又は名称】株式会社オービック

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】山下 紘平

(72)【発明者】

【氏名】馬場 健人

(72)【発明者】

【氏名】上野 剛光

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376BC14

5B376BC45

5B376BC80

5B376FA13

(57)【要約】

【課題】アプリケーションを開発する場合に、堅牢かつ柔軟性に富むセキュリティを簡潔に設定することが可能なアプリ開発支援システムを提供することを目的とする。
【解決手段】本発明に係るアプリ開発支援システムは、マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面表示制御手段と、前記設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報設定し、当該マスタページで設定されたロジック情報及びセキュリティ情報を当該マスタページに従属する子画面に継承させる設定手段と、を備えている。
【選択図】図２

【特許請求の範囲】

【請求項1】

制御部を備えたアプリ開発支援システムであって、
前記制御部は、
マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面表示制御手段と、
前記設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報を設定し、当該マスタページで設定されたロジック情報及びセキュリティ情報を当該マスタページに従属する子画面に継承させる設定手段と、
を備えたことを特徴とするアプリ開発支援システム。

【請求項2】

前記子画面では、前記マスタページで設定されたセキュリティ情報の変更が不可に構成されていることを特徴とする請求項１に記載のアプリ開発支援システム。

【請求項3】

前記設定手段は、前記ロジック情報に含まれる処理フローから別のロジック情報を呼び出すためのサブフローに割り当てられたロジック情報に対してセキュリティ情報を設定し、当該サブフローに割り当てられたロジック情報に設定されたセキュリティ情報を、当該サブフローを含む呼び出し元のロジック情報に継承させることを特徴とする請求項１又は請求項２に記載のアプリ開発支援システム。

【請求項4】

前記セキュリティ情報は、起動権限、新規作成権限、修正権限、削除権限、照会権限、実行権限、及び出力権限の少なくとも１つを含むことを特徴とする請求項１～３のいずれか１つに記載のアプリ開発支援システム。

【請求項5】

前記アプリ開発支援システムは、ＧＵＩ操作の定義でアプリケーションを開発可能なシステムであることを特徴とする請求項１～４のいずれか１つに記載のアプリ開発支援システム。

【請求項6】

制御部を備えた情報処理装置に実行させるためのアプリ開発支援方法であって、
前記制御部で実行される、
マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面表示制御ステップと、
前記設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報を設定し、当該マスタページで設定されたセキュリティ情報及びロジック情報を当該マスタページに従属する子画面に継承させる設定ステップと、
を含むことを特徴とするアプリ開発支援方法。

【請求項7】

制御部を備えた情報処理装置に実行させるためのアプリ開発支援プログラムであって、
前記制御部において、
マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面表示制御ステップと、
前記設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報を設定し、当該マスタページで設定されたロジック情報及びセキュリティ情報を当該マスタページに従属する子画面に継承させる設定ステップと、
を実行させるためのアプリ開発支援プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、アプリ開発支援システム、アプリ開発支援方法、及びアプリ開発支援プログラムに関する。

【背景技術】

【0002】

従来、アプリ開発支援システムとして、例えば、特許文献１がある。かかる特許文献１のシステムは、開発環境に接続された端末からの入力に基づいてアプリケーションプログラムを生成し、生成されたアプリケーションプログラムを視覚的に表示するプログラム開発部と、開発環境を利用する複数のユーザ間におけるコミュニケーション機能を提供するコミュニケーション部であって、第１のユーザが利用する開発環境のプログラム開発部によって生成されたアプリケーションプログラムの一部または全部を、第２のユーザが利用する開発環境において利用可能に複製させ、視覚的に表示させるコミュニケーション部と、を有する。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１８－５５５８８号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、上記特許文献では、アプリケーション（「アプリ」と略記する場合がある）を開発する場合に、堅牢かつ柔軟性に富むセキュリティを簡潔に設定することに関して何等記載されていない。

【0005】

本発明は、上記に鑑みてなされたものであり、アプリケーションを開発する場合に、堅牢かつ柔軟性に富むセキュリティを簡潔に設定することが可能なアプリ開発支援システム、アプリ開発支援方法、及びアプリ開発支援プログラムを提供することを目的とする。

【課題を解決するための手段】

【0006】

上述した課題を解決し、目的を達成するために、本発明は、制御部を備えたアプリ開発支援システムであって、前記制御部は、マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面表示制御手段と、前記設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報設定し、当該マスタページで設定されたロジック情報及びセキュリティ情報を当該マスタページに従属する子画面に継承させる設定手段と、を備えたことを特徴とする。

【0007】

また、本発明の一態様によれば、前記子画面では、前記マスタページで設定されたセキュリティ情報の変更が不可に構成されていることにしてもよい。

【0008】

また、本発明の一態様によれば、前記設定手段は、前記ロジック情報に含まれる処理フローから別のロジック情報を呼び出すためのサブフローに割り当てられたロジック情報に対してセキュリティ情報を設定し、当該サブフローに割り当てられたロジック情報に設定されたセキュリティ情報を、当該サブフローを含む呼び出し元のロジック情報に継承させることにしてもよい。

【0009】

また、本発明の一態様によれば、前記セキュリティ情報は、起動権限、新規作成権限、修正権限、削除権限、照会権限、実行権限、及び出力権限の少なくとも１つを含むことにしてもよい。

【0010】

また、本発明の一態様によれば、前記アプリ開発支援システムは、ＧＵＩ操作の定義でアプリケーションを開発可能なシステムであることにしてもよい。

【0011】

また、上述した課題を解決し、目的を達成するために、本発明は、制御部を備えた情報処理装置に実行させるためのアプリ開発支援システムであって、前記制御部で実行される、マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面表示制御ステップと、前記設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報を設定し、当該マスタページで設定されたセキュリティ情報及びロジック情報を当該マスタページに従属する子画面に継承させる設定ステップと、を含むことを特徴とする。

【0012】

また、上述した課題を解決し、目的を達成するために、本発明は、制御部を備えた情報処理装置に実行させるためのアプリ開発支援プログラムであって、前記制御部において、
マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面表示制御ステップと、前記設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報を設定し、当該マスタページで設定されたロジック情報及びセキュリティ情報を当該マスタページに従属する子画面に継承させる設定ステップと、を実行させるためのアプリ開発支援プログラムであることを特徴とする。

【発明の効果】

【0013】

本発明によれば、アプリケーションを開発する場合に、堅牢かつ柔軟性に富むセキュリティを簡潔に設定することが可能になるという効果を奏する。

【図面の簡単な説明】

【0014】

【図1】図１は、実施の形態のシステム全体の構成の概略を示す図である。

【図2】図２は、アプリ開発支援システムの構成の一例を示すブロック図である。

【図3】図３は、業務支援システムの構成の一例を示すブロック図である。

【図4】図４は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図5】図５は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図6】図６は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図7】図７は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図8】図８は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図9】図９は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図10】図１０は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図11】図１１は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図12】図１２は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図13】図１３は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【図14】図１４は、業務支援システムの制御部の処理の具体例を説明するための図である。

【図15】図１５は、業務支援システムの制御部の処理の具体例を説明するための図である。

【図16】図１６は、業務支援システムの制御部の処理の具体例を説明するための図である。

【図17】図１７は、業務支援システムの制御部の処理の具体例を説明するための図である。

【図18】図１８は、業務支援システムの制御部の処理の具体例を説明するための図である。

【図19】図１９は、業務支援システムの制御部の処理の具体例を説明するための図である。

【図20】図２０は、アプリ開発支援システムの制御部の処理の具体例を説明するための図である。

【発明を実施するための形態】

【0015】

以下に、本発明に係るアプリ開発支援システム、アプリ開発支援方法、及びアプリ開発支援プログラムの実施の形態を、図面に基づいて詳細に説明する。なお、本実施形態によりこの発明が限定されるものではない。

【0016】

［１．概要］
本発明のアプリ開発支援システムは、ノーコード系／ローコード系、その他を問わず、少なくともアプリケーションの画面レイアウト・イベント・処理フロー及びセキュリティ設定の範囲をＧＵＩ操作の定義のみでプログラムソースのコーディングを行わなくてもアプリケーションを開発可能なシステムである。

【0017】

ここで、「ノーコード系」とは、ノーコード、コーディングレス、ノンコーディング等をいい、アプリケーション開発者がプログラムのソースコードを一切作成・修正することなくＧＵＩ操作等で既存機能・部品等の配置・組合せにより、簡易・定型的なアプリケーションを作成できる仕組みをいう。「ローコード系」とは、ローコード等をいい、基本的にはノーコードと同様であるが、アプリケーションの柔軟性に欠けるため、必要に応じて部分的にプログラムのコーディングや外部ＡＰＩの利用等を行い、柔軟なカスタマイズまで可能とする仕組みをいう。また、アプリケーション開発支援を行う機能群全般を「基盤、プラットフォーム、又は開発ツール」といい、ここでは、「基盤」の用語を使用する。

【0018】

以下の説明では、アプリ開発支援システムとして、ローコード基盤を一例として説明するが、本発明はこれに限られるものではなく、ＧＵＩ操作の定義でアプリケーションを開発可能な全てのシステムに適用可能である。

【0019】

例えば、企業がＥＲＰシステム等の情報システムに求めるセキュリティ要件の重要性は、近年ますます高まっている。例えば、監査における統制要件では、情報システム内でユーザの権限を適切に管理されているかどうかがチェックの対象となる。また、マイナンバーの管理においては、閲覧／編集などの権限を持つユーザを適切に管理することが法的にも必要とされる。企業が適切に情報を管理し業務を行うためにも、ＥＲＰシステム等の情報システムには、ユーザ毎にセキュリティをチェックし、適切なユーザのみが情報にアクセス、編集できるような仕組みが求められる。

【0020】

経産省のＤＸレポートの中で、数十年以上にわたり稼働し続け老朽化したシステムが、日本の国際競争力の低下や経済停滞をもたらすという問題が指摘されている（「２０２５年の崖」問題）。老朽化を引き起こす背景の一つに、情報システムが企業の業務運用と強く結びついていることから、一度完成したシステムを刷新するコストが大きすぎる、ということが挙げられる。

【0021】

こういった問題の一つの解決策として、ローコード基盤（ツール）を用いて、コストを抑えてシステム開発を行う手法が近年注目されている。出願人は、長年にわたり企業に求められるセキュリティ要件を満たすシステム基盤を構築しており、この強みとローコード基盤の特性を生かしてセキュリティ設定を簡易的に行えるような仕組みを考案した。

【0022】

ローコード基盤では、ユーザがドラッグ＆ドロップでボタンなどのコントロール（以下、ＵＩ）を配置し、別で用意したクリックイベント等（以下、ロジック）をＵＩに割り付けていく。このため、必然的にＵＩとロジックがそれぞれ独立した構成になっていなければならない。従来のプログラミングによるシステム開発では、ＵＩとロジックが一体化しており、ここを分離するというのはあまり一般的ではなかった。

【0023】

ここで、システムの例として、削除ボタン（ＵＩ）をクリックすると、削除処理（ロジック）が実行されるようなケースを想定する。セキュリティを担保するためには、削除権限のないユーザが削除処理を実行できないようにしなければならない。

【0024】

上述したように、従来型システムではＵＩとロジックの２つが独立していなかったため、セキュリティの設定も削除ボタン（ＵＩ）に依存せざるを得なかった。セキュリティ設定がＵＩに依存してしまうと、システムの各画面のＵＩ毎にセキュリティの設定が必要となり、システムが大規模化すると、セキュリティ設定やそれに伴うテストにも大きなコストがかかる。具体的には、削除ボタンの例で言えば、部門マスタメンテ、事業所マスタメンテの削除ボタンそれぞれ（画面毎）にセキュリティ設定が必要となる。

【0025】

また、システム変更時にも常にセキュリティを考慮しなければならないため、システム変更を行うことができるのは高度なスキルを持った人材に限定される。結果として、システム構築後の継続的なシステム改善が難しくなる（システムが硬直化しやすい）という問題がある。こういったシステム設定の複雑化も、前述の「２０２５年の崖」問題の一因に挙げられる。

【0026】

本発明では、ローコード基盤によってＵＩとロジックが分離している状態が実現したことで、ロジックに対してセキュリティをかけることが可能になった。これにより、先ほどの削除ボタンと削除処理の関係でいえば、削除処理だけにセキュリティをかけられるようになった。

【0027】

このＵＩとロジックの分離と、マスタページからのロジック継承の仕組みを組み合わせることで、ローコード基盤を使って開発を行う際に、セキュリティを極力意識せずにシステム構築を行うことができるようになった。なお、ローコード基盤で作成されるシステム（アプリケーション）のことを、本明細書では、説明上、「実行環境」と呼称する。

【0028】

より具体的には、本発明では、以下のことを実現する。従来型のシステムでは、個々のジョブをプログラミングにより開発する手法が一般的であった。その際、特にセキュリティに関連する部分のプログラムにおいては、セキュリティリスクを防ぐためにも、十分な知見を持った開発者により適切な設定が行われることが望ましい。

【0029】

しかしながら、個々のジョブに対して開発者がプログラム開発を行う従来の開発手法では、システムの規模に応じて、セキュリティの設定にかかる作業量も増加することから、システム全体で適切なセキュリティ設定を保つことは難しくなる。このため、システム全体でセキュリティ設定が正しく機能しているかどうかのテスト作業に大きなコストがかかり、システム構築後の柔軟なシステム変更が難しくなる、という課題があった。

【0030】

ローコード基盤では、ユーザが使用する通常のジョブとは異なり、複数のジョブで共通して使用するような処理を集約したマスタページが存在する。マスタページでは、実行する処理の設定に加えて、実行に必要なユーザ権限のセキュリティを設定することができる。

【0031】

本発明では、マスタページで設定したロジック及びそのセキュリティを、マスタページに従属する子画面に継承させることにより、子画面でもセキュリティ設定が付与された処理を利用できるようにする仕組みを構築することで、開発者はマスタページを継承するだけで、堅牢なアプリケーションを構築することができる。

【0032】

［２．構成］
［２－１．システム全体の構成］
図１は、実施の形態のシステム全体の構成の概略を示す図である。図１において、アプリ開発支援システム（例えば、Ｗｅｂサーバ）１００、業務支援システム（例えば、Ｗｅｂサーバ）２００、開発ユーザ端末３００、業務ユーザ端末４００は、ネットワーク５００に接続されており、互いにデータ通信可能に構成されている。

【0033】

アプリ開発支援システム１００は、開発ユーザ端末３００・・・に、例えば、ローコード基盤プラットフォーム（ツール）を提供するものであり、業務用アプリの定義データ（ロジック情報、セキュリティ情報を含む）を生成するための設定画面（例えば、Ｗｅｂページ）を提供する。定義データは、業務用アプリの元となるデータであり、「オブジェクト」、「パッケージ」、「ソース」ともいう。以下の説明では、アプリ開発支援システム１００を「ローコード基盤」と称する場合がある。

【0034】

開発ユーザ端末３００・・・は、業務用アプリの作成担当である開発ユーザ（「開発者」ともいう）がアプリ開発支援システム１００にアクセスして、業務用アプリの定義データを作成させるためのものである。開発ユーザ端末３００・・・は、例えば、ブラウザを使用して、アプリ開発支援システム１００から提供される設定画面で操作を行う。

【0035】

業務支援システム２００は、アプリ開発支援システム１００のデータベースから業務用アプリの定義データを取得して、取得した定義データをデータ変換して業務用アプリ２０６ａを生成する。業務支援システム２００は、生成した業務用アプリ２０６ａを実行し、業務ユーザ端末４００・・・に業務実行画面（例えば、Ｗｅｂページ）を提供する。以下の説明では、アプリ開発支援システム１００で作成した定義データに基づく業務用アプリを実行する業務支援システム２００を単に「実行環境」と称する場合がある。

【0036】

業務ユーザ端末４００・・・は、業務担当者である業務ユーザ（「ユーザ」ともいう）が業務支援システム２００にアクセスして、業務を実行するためのものである。業務ユーザ端末４００・・・は、例えば、ブラウザを使用して、業務支援システム２００から提供される業務実行画面で操作を行う。

【0037】

［２－２．アプリ開発支援システムの構成］
図１のアプリ開発支援システム（ローコード基盤）１００の構成について、図２を参照して説明する。図２は、図１のアプリ開発支援システム１００の構成の一例を示すブロック図である。

【0038】

アプリ開発支援システム１００は、ワークステーションや市販のデスクトップ型やノート型のパーソナルコンピュータ等である。

【0039】

アプリ開発支援システム１００は、図２に示すように、制御部１０２と通信インターフェース部１０４と記憶部１０６と入出力インターフェース部１０８と、を備えている。アプリ開発支援システム１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

【0040】

通信インターフェース部１０４は、ルータ等の通信装置および専用線等の有線または無線の通信回線を介して、アプリ開発支援システム１００をネットワーク５００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク５００は、アプリ開発支援システム１００と、開発ユーザ端末３００・・・、業務支援システム２００、サーバ６００等とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。

【0041】

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

【0042】

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

【0043】

記憶部１０６は、データベース１０６ａと、セキュリティ設定可能マスタ１０６ｂと、を備えている。

【0044】

データベース１０６ａは、業務用アプリの定義データ（ロジック情報、セキュリティ情報等）等のデータを格納するためのものである。データベース１０６ａは外部に設けられていてもよく、例えば、サーバ６００に設けられていてもよい。

【0045】

セキュリティ設定可能マスタ１０６ｂは、コントロール、アクション、セキュリティ設定可能か否かを示す設定可否フラグを関連づけて登録したテーブル等で構成することができる（図２０参照）。セキュリティ設定可能マスタ１０６ｂは、設定画面でコントロールのアクションについてセキュリティが設定される場合に参照される。

【0046】

制御部１０２は、アプリ開発支援システム１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部１０２は、機能概念的に、画面制御部１０２ａと、設定部１０２ｂと、登録部１０２ｃと、検知部１０２ｄと、マスタメンテ部１０２ｅと、を備えている。

【0047】

画面制御部１０２ａは、開発ユーザ端末３００・・・からのアクセスに応じて、開発ユーザ端末３００にロジック情報やロジック毎のセキュリティ情報を設定するための各種設定画面を提供する。また、画面制御部１０２ａは、開発ユーザ端末３００・・・からのアクセスに応じて、開発ユーザ端末３００にマスタページについてのロジック（処理）と権限の一覧をマトリックス状に表示したセキュリティ設定画面を提供してもよい。また、画面制御部１０２ａは、マスタページ及び当該マスタページに従属する子画面について、設定されたマスタページのセキュリティを一覧で照会（表示）してもよい。画面制御部１０２ａは、開発ユーザ端末３００・・・からのアクセスに応じて、開発ユーザ端末３００にコントロールのアクションのセキュリティを設定するための設定画面を提供してもよい。

【0048】

設定部１０２ｂは、設定画面上での開発ユーザ端末３００の開発者の操作に応じて、マスタページ（親画面）と当該マスタページに従属する子画面のロジック情報及びロジック毎のセキュリティ情報を設定し、その際、マスタページで設定されたロジック情報及びセキュリティ情報を子画面で継承させる。子画面では、マスタページで設定されたセキュリティの変更が不可に構成されていてもよい。設定部１０２ｂは、ロジック情報に含まれる処理フローから別のロジック情報を呼び出すためのサブフローに割り当てられたロジック情報に対してセキュリティ情報を設定し、当該サブフローに割り当てられたロジック情報に設定されたセキュリティ情報を、当該サブフローを含む呼び出し元のロジック情報に継承させることにしてもよい。設定部１０２ｂは、上述のセキュリティ設定画面上での開発ユーザ端末３００の開発者の操作に応じて、マスタページの各ロジックのセキュリティ情報を設定してもよい。

【0049】

なお、業務支援システム２００（実行環境）のセキュリティ種別の設定の対象はユーザとジョブの組合せで、この結果として、ジョブ（画面）に含まれるロジックのセキュリティがユーザ毎の操作権限として反映される（図１４及び図１５参照）。

【0050】

登録部１０２ｃは、設定されたマスタページ及び当該親画面に従属する子画面のロジック情報及びセキュリティ情報を所定のフォーマットのデータ形式に変換して、業務用アプリの定義データとしてデータベース１０６ａに登録する。

【0051】

検知部１０２ｄは、設定画面において、開発者がコントロールのアクションについてセキュリティを設定する場合に、セキュリティ設定可能マスタ１０６ｂを参照して、当該コントロールのアクションの設定が可能か否かを検知する。この場合、検知部１０２ｄは、
セキュリティ設定可能マスタ１０６ｂを参照して、当該コントロールのアクションの可否フラグが設定可能である場合には、設定を許可し、当該コントロールのアクションの可否フラグが設定不可である場合には、エラーを通知することにしてもよい。

【0052】

マスタメンテ部１０２ｅは、セキュリティ設定可能マスタ１０６ｂに対して、データの登録・追加・編集等を行って設定する。

【0053】

［２－３．業務支援システムの構成例］
図１の業務支援システム（実行環境）２００の構成について、図３を参照して説明する。図３は、図１の業務支援システム２００の構成の一例を示すブロック図である。

【0054】

業務支援システム２００は、ワークステーションや市販のデスクトップ型やノート型のパーソナルコンピュータ等である。

【0055】

業務支援システム２００は、図３に示すように、制御部２０２と通信インターフェース部２０４と記憶部２０６と入出力インターフェース部２０８と、を備えている。業務支援システム２００が備えている各部は、任意の通信路を介して通信可能に接続されている。

【0056】

通信インターフェース部２０４は、ルータ等の通信装置および専用線等の有線または無線の通信回線を介して、業務支援システム２００をネットワーク５００に通信可能に接続する。通信インターフェース部２０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク５００は、業務支援システム２００と、業務ユーザ端末４００・・・、アプリ開発支援システム１００、サーバ７００等とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。

【0057】

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

【0058】

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

【0059】

記憶部２０６は、業務用アプリ２０６ａを格納する。業務用アプリ２０６ａは、上述したように、アプリ開発支援システム１００で作成された業務用アプリの定義データをデータ変換したものである。

【0060】

制御部２０２は、アプリ開発支援システム１００を統括的に制御するＣＰＵ等である。制御部２０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部２０２は、機能概念的に、実行部２０２ａを備えている。

【0061】

実行部２０２ａは、業務ユーザ端末４００・・・からのアクセスに応じて、業務用アプリ２０６ａを実行する。具体的には、実行部２０２ａは、業務ユーザ端末４００・・・からのアクセスに応じて、業務実行画面を提供して、業務実行画面上での業務ユーザ端末４００のユーザ操作に応じて処理を行う。ユーザは、業務支援システム２００にアクセスすることで、所定の業務を実行することができる。

【0062】

［４．処理の具体例］
図１～図２０を参照して、本実施の形態におけるアプリ開発支援システム１００の制御部１０２及び業務支援システム２００の制御部２０１の処理の具体例を説明する。図４～２０は、本実施の形態におけるアプリ開発支援システム１００の制御部１０２及び業務支援システム２００の制御部２０１の処理の具体例を説明するための図である。

【0063】

（具体例１：ローコード基盤でのマスタページと子画面の関係性と処理のアドオン方法について）
図４を参照して、ローコード基盤でのマスタページと子画面の関係性と処理のアドオン方法を説明する。アプリ開発支援システム１００の設定部１０２ｂは、設定画面上での開発ユーザ端末３００の開発者の操作に応じて、マスタページ（親画面）と当該マスタページに従属する子画面のロジック情報及びロジック毎のセキュリティ情報を設定し、その際、マスタページで設定されたロジック情報及びセキュリティ情報を子画面で継承させる。子画面では、マスタページから継承したロジックのロジックフロー内の一部（プレースホルダー内）の変更のみが可能となっている。

【0064】

システムにおける各画面のテンプレートの役割を果たす画面をマスタページと呼ぶ。登録処理や、帳票の出力処理など、各画面の特性に合うマスタページを利用することで、各画面での開発コストを下げることができる。マスタページは、各子画面のテンプレート機能に相当する。マスタページ（親画面）と各画面（子画面）は、いわば親子関係になっている。マスタページ（親）側には、「プレースホルダー」と呼ばれる一つ又は複数のエリアが配置されており、子画面側は、そのエリアにのみコントロールを配置可能となっている。

【0065】

具体例１では、マスタページとそれを継承する画面（以下、子画面と呼称）との関係を利用して、セキュリティの設定を行う。

【0066】

図４は、マスタページと子画面の関係性と処理のアドオン方法を説明するための図である。図４（Ａ）は、フロー設定画面、図４（Ｂ）は、フロー設定画面で設定される実行環境を示している。以下では、登録画面マスタページ（登録画面全般から参照されるマスタページ）を一例に挙げて説明する。

【0067】

登録画面マスタページには、登録系の画面（部門マスタメンテなど）で必要とされる新規登録、修正、削除、照会などの共通的な処理が予め設定されている。図４では、簡略化のため、削除処理のみを表示している。

【0068】

ローコード基盤の特性により、削除ボタン（ＵＩ）と削除処理（ロジック）は分離している。ローコード基盤側でマスタページの削除処理の設定を行う画面では、メッセージ表示などの各処理（以下、「アクション」と呼称する）を繋げることで、一連の業務処理をまとめたフローチャート（ロジックフロー）として設定できる。

【0069】

この中でプレースホルダーと書かれたアクションは、マスタページを継承した子画面側で具体的な処理を設定するための特殊なアクションとなる。マスタページを継承する子画面側では、マスタページにある削除処理を呼び出して利用する。

【0070】

子画面上で設定できるのは、（１）親画面（マスタページ）から継承したロジックフローについては、親画面側で設定されたプレースホルダーのアクションのみ、（２）子画面側で新たなロジックフローが作成可能で、それについては、子画面毎に自由に設定可能である。子画面では、フローチャート自体や、セキュリティ設定を行う必要がない。このため、同一のマスタページから継承するページ間ではセキュリティの一貫性が担保される。

【0071】

よって、マスタページを継承して子画面を作成する場合、各子画面の作成者（開発者）はセキュリティについて意識することなく、各画面処理のアドオンのみに専念することができる。セキュリティの詳しい設定方法に関しては、具体例３で説明する。

【0072】

図４（Ａ）において、マスタページの権限設定が子画面に継承される。マスタページ及びその子画面では、実行時、削除権限が必要となる。図４（Ａ）に示す例では、マスタページ削除処理設定画面でフローチャートを設定する。この例では、開始、アクション「メッセージを表示し（削除処理を実行します。よろしいですか？）」、「Ｙｅｓ」の場合のアクション「プレースホルダー：子画面削除処理」、「Ｎｏ」の場合のアクション「処理終了」が設定されている。

【0073】

このフローチャートは、子画面（部門マスタ削除処理設定画面や取引先マスタ削除処理設定画面）に引き継がれる。

【0074】

（具体例２：従来型システム開発とローコード基盤での開発でのセキュリティ設定の違い）
図５及び図６を参照して、従来型システム開発とローコード基盤での開発でのセキュリティ設定の違いを説明する。

【0075】

図５は、従来型システムのセキュリティ設定を説明するための図である。例えば、登録画面Ａ、Ｂでは、新規登録ボタン、修正ボタン、削除ボタン、照会ボタンそれぞれにセキュリティが割りついていること（権限が設定されている）が一般的である。直感的ではあるものの、画面毎にＵＩは異なるため、画面毎に専門の技術者による設定作業が必要となる。すなわち、画面数×権限数の設定作業が必要となる。このように、従来型システムのセキュリティ設定は、システム構築における大きな負担となっていた。

【0076】

図６は、ローコード基盤でのセキュリティ設定を説明するための図である。ローコード基盤でのセキュリティ設定では、マスタページ（親画面）で各ロジックに対してセキュリティ設定を行い、マスタページ（親画面）で設定したロジックを子画面で継承させることで、各画面毎にセキュリティ設定を行う必要がなくなる。

【0077】

すなわち、全ての子画面でマスタページの同一ロジックを使用することができる。さらに、新たに登録画面を新規追加する場合にも、同じ登録画面のマスタページを継承しさえすれば、開発者は各画面固有の処理をアドオンするだけでよいため、セキュリティを意識することなくシステムの開発が可能になる（具体例１参照）。

【0078】

開発者の技術レベルにばらつきがあったとしても、この仕組みを用いることで、セキュリティを担保した開発を行うことができる。図６の例では各ボタン（新規登録ボタン、修正ボタン、削除ボタン、照会ボタン）のクリックイベントにセキュリティの付与されたロジックを割り付けているが、セキュリティの観点から割付先のコントロールは制限される必要がある（具体例５参照）。コントロールの制限については、具体例５で詳細に説明する。

【0079】

（具体例３：ローコード基盤におけるセキュリティの設定方法）
図７～図１１を参照して、ローコード基盤におけるセキュリティの設定方法を説明する。設定部１０２ｂは、マスタページについてのロジック（処理）とユーザ権限の一覧をマトリックス状に表示したセキュリティ設定画面上での開発ユーザ端末３００の開発者の操作に応じて、マスタページの各ロジックのセキュリティ情報を設定する。

【0080】

ローコード基盤では、複数の処理をフローチャートとして設定することができる（具体例１参照）。上述したように、このフローチャートで実行される処理内容に応じて、権限を持ったユーザのみが処理を実行できるようにすることが必要とされる。

【0081】

ローコード基盤では、この設定したフローチャートを一つの単位としてセキュリティの設定を行うことができる（以降、一連のフローチャートを「ロジック」と呼称する）。

【0082】

図７は、セキュリティ設定画面の一例を示す図である。セキュリティ設定画面では、ロジック（新規登録ロジック、修正ロジック、削除ロジック、照会ロジック、起動時ロジック）を縦軸、ロジック実行に必要なユーザ権限（なし、起動、新規、修正、削除、照会、実行、出力）を横軸とした一覧形式となっており、ボックスをチェックすることで権限を設定することができる。

【0083】

図７に示す例では、新規登録ロジックに「新規」、修正ロジックに「修正」、削除ロジックに「削除」、照会ロジックに「照会」、起動時ロジックに「起動」の権限が設定されている。

【0084】

このように、一覧形式で表示することで、全てのロジックに対してセキュリティを一度に設定することができ、セキュリティの付与忘れを未然に防ぐことができる。

【0085】

設定されたセキュリティ設定画面は、照会が可能となっており、マスタページ及びその子画面から照会することができる。

【0086】

またロジック及びセキュリティ権限はマスタ上で管理されているため、開発者が自由にデータをカスタマイズすることができる。

【0087】

図８を参照して、図４と同様に登録画面マスタページの例を説明する。図８の左側は、フロー設定画面（図４（Ａ）と同じ）、右側はセキュリティ設定画面の例を示している。図８では、説明の簡単のために、削除処理のみを示している。

【0088】

図８において、マスタページで設定されたロジックはマスタページ上でのみセキュリティ設定が可能となっている。マスタページのロジックを継承した子画面側では、セキュリティ設定を変更することができない。子画面では、セキュリティ設定画面の照会のみ可能のため、セキュリティの一貫性が担保される。

【0089】

図９及び図１０を参照して、登録されるロジック情報を説明する。設定されたロジックはシリアライズ化されてＪｓｏｎ形式でデータベース１０６ａに保存される。１つの画面が１行のレコードとして登録され、その中に複数のロジックが１：Ｎの関係で紐づいて登録される。

【0090】

ロジック情報の中で、太字で示した部分がセキュリティに関連する情報となる。セキュリティ種別マスタの種別情報がＪｓｏｎに埋め込まれ、実行環境側でこの情報を元にセキュリティ制御を行う。

【0091】

図９は、データベース１０６ａに登録されるロジック情報（図７の一覧表の縦軸部分）の例を示している。図９に示すロジック情報の例では、画面情報、（画面ＩＤ、画面名称）、ロジックデータを含んでいる。

【0092】

図９に示す例では、画面ＩＤ「１」は、画面名称「登録画面マスタページ」、画面ＩＤ「２」は、画面名称「部門登録画面」、画面ＩＤ「３」は、画面名称「取引先登録画面」となっている。また、図９では、ロジックデータの一例を示しており、各画面のロジックデータはＪｓｏｎ形式で保存される。

【0093】

図９は、セキュリティ種別マスタ（図７の一覧表の横軸部分）の例を示す図である。セキュリティ種別マスタメンテは、セキュリティ種別とセキュリティ名称を関連づけて登録している。図９に示す例では、セキュリティ種別「０」は、セキュリティ名称「起動」、セキュリティ種別「１」は、セキュリティ名称「新規追加」、セキュリティ種別「２」は、セキュリティ名称「修正」、セキュリティ種別「３」は、セキュリティ名称「削除」、セキュリティ種別「４」は、セキュリティ名称「照会」、セキュリティ種別「５」は、セキュリティ名称「帳票出力」となっている。このセキュリティ種別マスタを使用することで、簡易にセキュリティを設定することができる。

【0094】

マスタページのロジック内でセットされたプレースホルダーアクション（具体例１参照）は、子画面上で具体的なロジックとして再定義できる。

【0095】

図１１は、データベース１０６ａに登録される情報の例を説明するための図であり、左側がフロー設定画面の例、右側がデータベースに登録される情報（Ｊｓｏｎ形式）の例を示している。フロー設定画面は、図４（Ａ）と同様である。図１１では、説明の簡単のために、削除処理のみを示している。

【0096】

（具体例３－２：ローコード基盤におけるセキュリティ設定方法（サブフロー使用時））
図１２及び図１３を参照して、ローコード基盤における、サブフロー使用時のセキュリティ設定方法を説明する。設定部１０２ｂは、ロジック情報に含まれる処理フローから別のロジック情報を呼び出すためのサブフローに割り当てられたロジック情報に対してセキュリティ情報を設定し、当該サブフローに割り当てられたロジック情報に設定されたセキュリティ情報を、当該サブフローを含む呼び出し元のロジック情報に継承させる。

【0097】

ロジックの設定フロー（具体例１参照）の中で使用できるアクションの中にはサブフロー呼出アクションという、別のフローチャート自体を呼び出すことができる機能が存在する。これにより、共通部分となるロジックを複数のロジック間で共有することができる。ロジック内でこのサブフローが使用されている場合、セキュリティの設定方法（具体例３参照）が少し変化する。

【0098】

図１２は、ローコード基盤におけるセキュリティ設定方法（サブフロー使用時）を説明するための図である。図１２に示す例では、メイン処理Ａ１では、サブ処理Ｂを呼び出し、サブ処理Ｂでは、サブ処理Ｃを呼び出す。また、メイン処理Ａ２では、サブ処理Ｂとサブ処理Ｄを呼び出す。

【0099】

図１３は、図１２のサブフロー使用時のセキュリティ設定を説明するための図である。ロジック内でサブフローを設定している場合、セキュリティに関しては、メイン処理だけでなくサブ処理にもセキュリティを設定することができる。複雑なフローになると、処理が何重にも入れ子になることが考えられるため、セキュリティ設定画面上では、図１３に示すように、サブで呼び出される処理を呼び出し側のメイン処理の配下（メイン処理の下位層）に表示する。

【0100】

サブ処理のセキュリティ設定を変更すれば、メイン処理配下（メイン処理の下位層）の情報も自動的に変更される。図１３に示す例では、サブ処理Ｂの設定を変更した場合を表記している。処理実行時は、メイン処理とサブ処理に必要な権限を合算し、必要な全ての権限をユーザが持つ場合のみ処理が実行可能となる（それ以外の場合は権限チェックでエラーにする。）。

【0101】

（具体例４：セキュリティ設定に基づく処理実行時の権限チェックフローについて）
図１４～図１８を参照して、セキュリティ設定に基づく処理実行時の権限チェックフローを説明する。

【0102】

業務支援システム２００の実行部２０１ａは、業務ユーザ端末４００・・・からのアクセスに応じて、業務用アプリ２０６ａを実行して、以下のような権限チェックを行う。

【0103】

セキュリティ設定にて登録されたセキュリティ情報を元に、実行環境ではセキュリティの制御を行う（データベース１０６ａに登録される情報に関しては具体例３参照）。

【0104】

図１５に示す情報は、アプリ開発支援システム（ローコード基盤）１００により設定されている情報である。図１４は、業務支援システム２００（実行環境）の設定状況を示す情報であり、アプリ開発支援システム１００とは異なる設定情報である。

【0105】

図１４は、セキュリティ情報の設定例を示す図である。ユーザ権限割り当てマスタは、ユーザ毎にシステム上割り当てられた値（Ｇｕｉｄ値）と、ジョブ毎にシステム上割り当てられた値（Ｇｕｉｄ値）と、セキュリティ種別と、権限フラグ（Ｔｒｕｅ又はＦａｌｓｅ）を関連づけて登録したテーブル等で構成することができる。セキュリティ種別には、セキュリティ種別マスタのデータが適用される。

【0106】

図１５は、ロジック情報の設定例を示す図である。ロジック情報は、画面ＩＤ、画面名称、ロジックデータ、ジョブＩＤ、ジョブ名を含んでいる。各画面（例：部門マスタメンテ）で使用されているロジックデータは、以下のようにＪｓｏｎ形式で保存されている（具体例３参照）。ここからデータを取りだし、セキュリティチェックに使用している。図１５の例では、マスタページから継承したマスタページ削除処理→マスタページ修正処理→…の順でセキュリティチェックを行う。ローコード基盤で作成した画面とジョブの情報を紐付けることで、図１４のユーザ権限割り当てマスタの情報を取得し、操作オペレータ（ユーザ）に権限があるか否かを判定することができる。すなわち、ロジック情報の対象の画面のジョブＩＤをキーとして、ユーザ権限割り当てマスタを参照して、操作オペレータ（ユーザ）に対象のセキュリティ種別（起動、削除等）の権限があるか否かを判定する。

【0107】

図１４及び図１５に示す例では、ユーザ「１１１１－ａａａａ－ａａａａ－ａａａａ－ａａａａａａａａａａａａ」については、部門マスタメンテ画面のジョブ「２２２２－ｂｂｂｂ－ｂｂｂｂ－ｂｂｂｂ－ｂｂｂｂｂｂｂｂｂｂｂｂ」について、起動、新規追加、修正、照会、帳票出力の権限有り、削除の権限無しが設定されている。

【0108】

業務支援システム２００の実行部２０１ａにより実行される権限チェック処理を説明する。画面起動時と処理実行時の２段階に分けて権限チェックを行う。画面起動時には、以下の２種類の点からチェック処理を行い、（１）ユーザにジョブ起動権限があるかどうかのチェックと、（２）画面内のコントロールに割り付けられているロジックを実行する権限があるかどうかをチェックする。

【0109】

業務支援システム２００の実行部２０１ａは、業務用アプリ２０６ａを実行して、例えば、以下のような処理を実行する。ここでは、部門マスタメンテ画面の起動処理の一例を説明する。図１６は、部門マスタメンテ登録画面の一例を示している。同図に示す例では、部門マスタの内容が、部門「１」が部門名「営業部」、部門「２」が部門名「経理部」、部門「３」が部門名「総務部」となっており、新規ボタン、修正ボタン、削除ボタン、照会ボタンを表示される。

【0110】

図１７は、業務支援システムの実行部により実行される部門マスタメンテ画面の起動処理の一例を示すフロー図である。

【0111】

図１７の処理では、（１）起動権限のチェックで権限なしと判定された場合には、ジョブ起動ができず処理を終了する。（２）権限チェックで、各コントロールで実行できないロジックが割りついていると判定された場合には、当該のコントロールがボタンかどうか判定し、ボタンであれば非表示にする。ボタンを非表示にすることによって、権限を持たないユーザにはその画面で削除処理が実行できることを認識できないため、さらに強固なセキュリティを実現できる。ユーザ権限に関しては、図１４に示すセキュリティ情報を元にして、ジョブ起動時、処理実行時に権限のチェックを行う。図１４の例では、ユーザはあるジョブに対して、削除権限を持たないような設定となっている。起動権限は存在するため、ジョブの起動は可能だが、削除権限が必要なロジックが紐づいたボタンは非表示状態で起動する。

【0112】

具体的には、図１７において、まず、部門マスタメンテ登録画面を起動させる（ステップＳ１）。通常の業務チェックによるコントロールの制御を行う（ステップＳ２）。例えば、業務チェックによるコントロールの制御例としては、伝票の締日を過ぎている場合、締日以前の伝票を修正できないようにボタンにロックをかける制御である。

【0113】

ロジック情報及びセキュリティ情報を参照して、ユーザに部門マスタメンテ画面のジョブ起動権限があるかをチェックし（ステップＳ３）、ユーザに起動権限がない場合には（ステップＳ３の「Ｎｏ」）、ジョブを起動しないで処理を終了し（ステップＳ７）、権限がないというエラーを通知する。なお、図１４及び図１５に示す例では、ユーザ「１１１１－ａａａａ－ａａａａ－ａａａａ－ａａａａａａａａａａａａ」については、部門マスタメンテ画面のジョブ「２２２２－ｂｂｂｂ－ｂｂｂｂ－ｂｂｂｂ－ｂｂｂｂｂｂｂｂｂｂｂｂ」について、起動権限が有りに設定されている。

【0114】

起動権限がある場合には（ステップＳ３の「Ｙｅｓ」）、セキュリティ情報を参照して、マスタページ削除処理に実行権限は存在するか否かをチェックする（ステップＳ４）。マスタページ削除処理に実行権限が存在する場合には（ステップＳ４の「Ｙｅｓ」）、ステップＳ５に移行する。なお、図１４及び図１５に示す例では、ユーザ「１１１１－ａａａａ－ａａａａ－ａａａａ－ａａａａａａａａａａａａ」については、部門マスタメンテ画面のジョブ「２２２２－ｂｂｂｂ－ｂｂｂｂ－ｂｂｂｂ－ｂｂｂｂｂｂｂｂｂｂｂｂ」について、削除権限が無しに設定されている。

【0115】

マスタページ削除処理に実行権限が存在しない場合は（ステップＳ４の「Ｎｏ」）、マスタページ削除処理にボタンが割り付いているか否かを判断する（ステップＳ８）。マスタページ削除処理にボタンが割り付いていない場合は（ステップＳ８の「Ｎｏ」）、ステップＳ５に移行する。マスタページ削除処理にボタンが割り付いている場合は（ステップＳ８の「Ｙｅｓ」）、マスタページ削除処理に割り付けた削除ボタンを非表示として（ステップＳ９）、ステップＳ５に移行する。上記図１４の例では、削除についての権限フラグが「ｆａｌｓｅ」のため、図１６の部門マスタメンテ画面の削除ボタンを非表示とする。

【0116】

このように、ボタンを非表示にすることによって、権限を持たないユーザにはその画面で削除処理が実行できることを認識できないため、強固なセキュリティを実現できる。

【0117】

ステップＳ５では、以下、画面内のロジックを全てチェックし、ジョブを起動する（ステップＳ６）。

【0118】

ボタン以外のコントロールは起動時チェックで権限がなくても非表示にならないため、処理がリクエストされた後に、業務支援システム２００側で処理の実行権限のチェックを行う必要がある。図１８は、この場合の実行時ロジックフローの一例を示す図である。具体的には、非表示のボタンであっても、ユーザが直接、業務支援システム２００側に処理をＰＯＳＴする可能性はあるため、業務支援システム２００側でも処理の実行権限チェックを行う必要がある。そのため、業務支援システム２００側にポストされた処理については再度チェックを行い、権限チェックを堅牢に行っている。

【0119】

図１８において、開発ユーザ端末３００・・・から処理イベントを発火し（ステップＳ１１）、業務支援システム２００側へ処理をＰＯＳＴする。業務支援システム２００は、マスタページ削除処理に実行権限が存在するか否かをチェックする（ステップＳ１２）。実行権限がない場合には（ステップＳ１２の「Ｎｏ」）、処理を中断し（ステップＳ１３）、エラーを業務支援システム２００からクライアントに送信する。実行権限がある場合には（ステップＳ１３の「Ｙｅｓ」）、処理を実行する（ステップＳ１４）。

【0120】

（具体例４－２：サブフロー使用時のセキュリティの設定・判定方法について）
上記図１２及び図１９を参照して、サブフロー使用時のセキュリティの設定・判定方法を説明する。

【0121】

上記図１２に示すように、ロジックの設定フロー（具体例１参照）の中で使用できるアクションの中にはサブフロー呼出アクションという、別のフローチャート自体を呼び出すことができる機能が存在する。これにより、共通部分となるロジックを複数のロジック間で共有することができる。

【0122】

ロジック内でこのサブフローが使用されている場合、セキュリティの判定方法（具体例４参照）が少し変化するため説明する。サブフローを使用するロジックの場合、各ロジック内のサブフローに実行権限があるかどうかのチェックが必要となる。そのため、セキュリティの判定方法も以下のような制御を行う。

【0123】

図１９は、サブフロー使用時のジョブ起動時制御の一例を説明するためのフローを示す図である。図１９において、まず、ユーザにジョブ起動権限があるかをチェックし（ステップＳ２１）、ユーザに起動権限がない場合には（ステップＳ２１の「Ｎｏ」）、ジョブを終了し、権限がないというエラーを通知する（ステップＳ２８）。

【0124】

起動権限がある場合には（ステップＳ２１の「Ｙｅｓ」）、ロジックＡに実行権限は存在するか否かをチェックする（ステップＳ２２）。ロジックＡに実行権限が存在する場合には（ステップＳ２２の「Ｙｅｓ」）、ステップＳ２３に移行する。ロジックＡに実行権限が存在しない場合は（ステップＳ２２の「Ｎｏ」）、図１７と同様な処理を実行する。

【0125】

ステップＳ２３では、ロジックＡにサブフローが存在するか否かをチェックする（ステップＳ２３）。ロジックＡにサブフローが存在しない場合は（ステップＳ２３の「Ｎｏ」）、ステップＳ２６に移行する。ロジックＡにサブフローが存在する場合には（ステップＳ２３の「Ｙｅｓ」）、当該サブフローに実行権限が存在するか否かをチェックする（ステップＳ２４）。当該サブフローの実行権限がある場合には（ステップＳ２４の「Ｙｅｓ」）、ステップＳ２５に移行する。他方、当該サブフローの実行権限がない場合には（ステップＳ２４の「Ｎｏ」）、ロジックＡにボタンが割り付いているかをチェックする（ステップＳ３０）。割り付いていない場合には（ステップＳ３０の「Ｎｏ」）、ステップＳ２５に移行し、割付いている場合には（ステップＳ３０の「Ｙｅｓ」）、ロジックＡに割り付いたボタンを非表示として（ステップＳ３１）、ステップＳ２５に移行する。

【0126】

ステップＳ２５では、以下、ロジック内のサブフローを全てチェックし、画面内のロジックを全てチェックした後（ステップＳ２６）、ジョブを起動する（ステップＳ２７）。

【0127】

（具体例５：セキュリティの割付先コントロールの制御について）
図２０を参照して、セキュリティの割付先コントロールの制御を説明する。アプリ開発支援システム１００の検知部１０２ｄは、設定画面において、開発者がコントロールのアクションについてセキュリティを設定する場合に、セキュリティ設定可能マスタ１０６ｂを参照して、当該コントロールのアクションの設定が可能か否かを検知する。この場合、検知部１０２ｄは、セキュリティ設定可能マスタ１０６ｂを参照して、当該コントロールのアクションの可否フラグが設定可能である場合には、設定を許可し、当該コントロールのアクションの可否フラグが設定不可である場合には、エラーを通知することにしてもよい。

【0128】

図２０は、セキュリティの割付先コントロールの制御を説明するための図である。マスタの削除処理や帳票の出力処理など、一般的なシステムにおいてはセキュリティ設定が付与されるようなロジックを紐づけるＵＩはボタンのクリックイベントが大部分であると考えられる。セキュリティの観点からすると、あらゆるコントロールに対してセキュリティ設定を付与できてしまうことは、意図せずにセキュリティホールを生み出してしまう可能性があり好ましくない。

【0129】

特にローコード基盤においては、システム構築時のセキュリティに知見のない開発者が設定を行う場合がある。極端な例では、そういった専門知識のない開発者が、ラジオボタンのチェック処理に削除処理を割り付けてしまう、などの異常な設定を行う事も考えられることから、セキュリティの割付先はローコード基盤側が極力制限する必要がある。

【0130】

一方で、全てのセキュリティ付ロジックをボタンのクリックイベントのみに割り付けるような強い制限をかけてしまうと、システムの拡張性やユーザビリティを損なうことが懸念される。

【0131】

そこで、セキュリティ付ロジックを割り付けられるコントロールの種類を開発者がマスタに登録することにより、任意で制限することができる仕組みを考案した。これにより、複数の開発者がシステム開発を行うような大規模開発においても、各開発者が特に意識することなく、セキュリティ設定に対する一貫性をシステム全体に持たせることができる。

【0132】

このような例外的なセキュリティ設定をローコード基盤側で制御することはユーザビリティの向上にもつながる。仮に、設定を制限している種類のコントロール（例えば、ラジオボタン）に、セキュリティ付ロジックを付与しようとすると、ローコード基盤でエラーを通知して、開発者が設定を即座に修正することができる。

【0133】

図２０（Ａ）は、セキュリティ設定可能マスタ１０６ｂの一例を示している。セキュリティ設定可能マスタ１０６ｂは、コントロール、アクション、設定可能か否かを示す設定可否フラグを関連づけて登録したテーブル等で構成することができる。同図に示す例では、１行目は、コントロール「ボタン」、アクション「クリック」、設定可否フラグ「１（設定可能）」、２行目は、コントロール「ラジオボタン」、アクション「チェック」、設定可否フラグ「０（設定不可）」、３行目は、コントロール「テーブル」、アクション「クリック」、設定可否フラグ「０（設定不可）」となっている。

【0134】

例えば、図２０（Ｂ）に示す設定画面で、開発ユーザがラジオボタンの実行時に修正権限が必要なセキュリティを設定しようとすると、セキュリティ設定可能マスタ１０６ｂの例では、コントロール「ラジオボタン」は、設定可否フラグ「０（設定不可）」に設定されているので、検知部１０２ｄは、エラーを通知する。

【0135】

また、ローコード基盤上でエラーが発生している場合には、図２０（Ｃ）に示すように、実行環境への変換はできない。このため、セキュリティの堅牢性が担保される。

【0136】

以上説明したように、本実施の形態のアプリ開発支援システム１００によれば、マスタページのロジック情報及びセキュリティ情報を設定するための設定画面を表示させる画面制御部１０２ａと、設定画面上での開発者の操作に応じて、マスタページのロジック情報及びセキュリティ情報設定し、当該マスタページで設定されたロジック情報及びセキュリティ情報を当該マスタページに従属する子画面に継承させる設定部１０２ｂと、を備えているので、アプリケーションを開発する場合に、堅牢かつ柔軟性に富むセキュリティを簡潔に設定することが可能となる。

【0137】

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

【0138】

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

【0139】

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

【0140】

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

【0141】

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

【0142】

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

【0143】

また、アプリ開発支援システム１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

【0144】

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

【0145】

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

【0146】

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

【0147】

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

【0148】

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

【0149】

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

【0150】

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

【符号の説明】

【0151】

１００ アプリ開発支援システム
１０２ 制御部
１０２ａ 画面制御部
１０２ｂ 設定部
１０２ｃ 登録部
１０２ｄ 検知部
１０２ｅ マスタメンテ部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ データベース
１０６ｂ セキュリティ設定可能マスタ
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ 業務支援システム
２０２ 制御部
２０２ａ 実行部
２０４ 通信インターフェース部
２０６ 記憶部
２０６ａ 業務用アプリ
２０８ 入出力インターフェース部
２１２ 入力装置
２１４ 出力装置
３００ 開発ユーザ端末
４００ 業務ユーザ端末
５００ ネットワーク
６００ サーバ
７００ サーバ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】